ダイナミックDNSを卒業して自前DNSサーバーを構築

この コンテンツ では、初心者向けの 公開サーバー 構築を前提としていますから、

「非固定 IPアドレス 契約 の元で 、 ダイナミックDNS を利用する 。」

という一般的で安価なインターネット接続環境でのサーバーの運用方法を前提に解説をしています 。

さて、 で説明したとおり、 DNS はインターネット空間で

「 コンテンツ の所在地情報を誰もが簡単に利用できるようにするために。」

そして

「 サーバー 運営する側が ノード を効率よく柔軟に運用するために。」

存在する非常に重要なシステムです。

ダイナミックDNSを利用すれば、その難解な仕組みが完全に理解できていなくても、自宅に設置した サーバー で比較的簡単に公開サーバーの運用が可能になります。ですからダイナミックDNSは公開サーバー入門者にとってはまさにうってつけのシステムといえるでしょう。

ところがダイナミックDNSには、安価で便利であるが故の避けられない問題がいくつかあります。

１．IPアドレスが変化してから、FQDNとIPアドレスの対応情報の書き換えがインターネット空間に反映されるまでの間は、クライアントからサービスが利用できない。

つまりIPアドレスが変化すると３０分〜１時間程度は公開サーバー機能が停止し、公開しているホームページが外部から閲覧できなくなったり、メールの送受信ができなくなったりします。

この頻度が数日に一回程度ならばまだいいのですが、日に何回もIPアドレスが変化するような接続環境では利用に耐えないかもしれません。実際、 ISP や接続契約の種類によってはそういうことも稀ではないようです。

２．ダイナミックDNSの状況次第で、サービスの快適性が左右される。

自宅の通信環境がいくら良くても、 WAN 空間の DNSサーバー が確実にレスポンス良く 名前解決 してくれなければ、快適なサービスを提供することはできません。

一般的にダイナミックDNSを担うDNSサーバーは非常に多くの ドメイン名 と FQDN の名前解決を担っているうえ、IPアドレスの変化に対して可能な限り短時間で追随しなけばならないために DNSキャッシュ の寿命が短く設定されていますから動作負荷は非常に大きいのが普通です。

従ってダイナミックDNSのサーバーはトラブルに見舞われがちなうえ、通常のDNSサーバーに比べると概してレスポンスは悪くなりがちです。

３．設定可能なパラメータが制限される。

公開サーバーの運用に慣れてきて、「あれもやりたい！、これもやってみたい！。」という欲求が募ってくると、 Webサーバー や メールサーバー などでたくさんの バーチャルホスト の運用が必要になってくるでしょう。

ところがダイナミックDNSでは設定可能な ホスト名 の数に制限があるのが普通ですし、メールサーバーを便利に運用するための MXレコード については設定そのものができないケースも珍しくありません。

公開サーバーの運用を始めて間もなくはホームページを閲覧する人も少なく、メールサーバーの利用頻度も大したことはないでしょうから、これらの欠点はあまり気にならないかもしれません。

しかし公開サーバーの利用者が増え、運営が活発になればなるほど、この欠点の影響は無視できなくなるでしょう。「あのページは楽しいけど、よく繋がらないことがあるから．．．。」というレッテルは貼られたくないものです。

だとしたら、多少お金はかかるにしても自分自身でDNSサーバーの運用を行い、WAN空間に自分のFQDNの名前解決情報を発信してもっと自由に公開サーバーを運用してしてみたくなりますよね。

関連セクション・ 自宅内DNSサーバーの構築

関連ページ・ 名前解決とネームサーバー

DNSサーバーを運用できる固定IPアドレス契約とは

構築中のLinuxサーバー で、 WAN 空間に対して 「権威あるDNS情報」 を発信する DNSサーバー を運用するには、 ルートサーバー から 構築中のLinuxサーバー を、

「 "obenri.com"に基づく FQDN を正式に配信するDNSサーバー。」

としてWAN空間に案内してもらわなければなりません。

そしてそのためには、そのDNSサーバーのFQDNと、 構築中のLinuxサーバー の グローバルIPアドレス を NIC(Network Information Center ) などの管理組織に登録する必要があります。

ということは、このような正式なDNSサーバーを設置するためには、最低限、

・DNSサーバーに付けるFQDNを設定するための ドメイン名 を持っていること。

・自宅のインターネット接続環境が 固定の グローバルIPアドレス であること。

という条件が必要になります。

DNSサーバーに付けるFQDNについては、既に取得しているドメイン名があればそれを利用することが可能ですから大した問題ではないでしょう。

一方の固定のIPアドレスについてはご利用の ISP のオプション契約を利用するか、ご利用のISPに固定IPアドレスを供給する契約オプションがない場合は別のISPと契約しなおす必要があるかもしれません 。

ただ、これが意外に簡単ではありません。

まず注意が必要なのは、この「固定IPアドレス契約」の内容はISPによって様々で、場合によってはDNSサーバーの設置が出来ないケースもあるということです。

一般的にいうと固定IPアドレスの供給をISPから受ける場合、 プレフィックス長 "/32"、つまりIPアドレス1個だけのプランの他に、"/29(IPアドレス8個)"、"/28(IPアドレス16個)"、などのプランも用意されています。

"/29"や"/28"などの複数の固定IPアドレス契約は、利用者が自分自身でグローバルIPアドレスの サブネット を構築して運用することが前提になっています。

従ってこういうオプション契約では自前でDNSサーバーを運用するのが前提になりますから何の問題もありません。しかし複数個の固定IPアドレスの契約は月額１万円以上の出費は覚悟しなければなりませんから個人の趣味の範囲ではないでしょう。

だとすれば、個人で契約可能な"/32"の「固定IPアドレス一個」というオプション契約を選択することになるわけですが、ISPにとって「一個の固定IPアドレスを供給する」という契約は、 「IPアドレスを固定することで拠点間を途切れなく接続できるインターネット環境を提供する」 という意味合いが強く、必ずしもそのIPアドレス上で 公開サーバー の運用を勧めるためのものではないということに注意してください。

そのため、ISPによっては供給するグロバールIPアドレスについて、正引き、逆引きの両方の 名前解決 をISPが管理していて、DNSサーバーをはじめとしてすべての公開サーバーの運用を認めていないケースなどがあります。

契約してしまった後ではこれはもうどうにもならないので、オプションを申請する前にDNSサーバーを自分で設置することが可能かどうかを必ず確認してください。

そのほか、DNSサーバーの設置は認めるもののISPが管理できるドメイン名以外の利用は認めていないケースなど、規約や条件はISPによって様々です。

従って、自分でDNSサーバーを運用する目的で固定IPアドレスの接続契約を行うときはきちんと利用規約を確認し、更にサポートセンターに「自前のDNSサーバーの運用が可能かどうか。」を確認する必要があります。

一般に多くのISP(特に大手)では、固定IPアドレスの供給に対しては 「そういう要望に応えるために仕方なくオプションプランとして準備している。」 というおざなりなサービスである場合が多く、ISPの担当者自身が契約内容に精通しているとは言い難いケースがあります。

そこで、電話での確認は後で「言った言わない」の水掛け論になる可能性がありますので、利用条件に関する問い合わせについてはできるだけ郵便やメールなど「文面としてやりとりの内容を確認できる方法」で行い、きちんと保管しておくことをおすすめします。

ISPとの通信契約はパソコンの売り買いなどと違って、担当者の思い違いなどを信じて契約してしまったからといって、簡単に解約、返金、というわけにはいきませんから、慎重に行うようにしたいものです。

さて、個人向けの固定IPアドレス契約で最も多いのは、そのグローバルIPアドレスについて、

逆引きの名前解決はISPが行い、正引きの名前解決だけをユーザーに任せる。

というパターンです。

逆引きの名前解決は一般的な公開サーバーの運用ではあまり重要ではなく、またこの部分の管理までユーザーに任せてしまうと悪用されてもISPがチェックしにくくなるという事情からそうなっているわけです。

これをユーザーの立場からみると、面倒な逆引きの設定を行う必要がなく、個人でのDNSサーバーの運用環境としてはベストだと思われます。

関連セクション・ 自宅内DNSサーバーの構築

関連ページ・ 名前解決とネームサーバー

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

スレーブDNSサーバーをどうするか

自分で自由に FQDN を設定可能な ドメイン名 と、固定の グローバルIPアドレス 契約のインターネット接続環境を手に入れたら、次に自宅で運用する DNSサーバー のバックアップである スレーブDNSサーバー をどうするかを決めなくてはなりません 。

実際のところは、 .org .info .biz などの一部の特別な TLD のドメイン名を除けば、必ずしもスレーブDNSサーバーを設置する必要はないのですが、 レジストラ によっては他のドメイン名についても二つ以上のDNSサーバーを指定しなければならないケースもありますから、なんとかしてスレーブサーバーを設置したいところです。

その手段の選択肢については で簡単に触れていますが、どの手段も一長一短がありますから「これがベスト」というものはありません。

ただ、ここで思い出して欲しいのは、これから設置しようとしているDNSサーバーはあくまで自宅内の 構築中のLinuxサーバー が外部に向けて発信する公開サービスについて、それを裏方で支えるための 名前解決 担うためものだということです、

つまり、 ISP のDNSサーバーのように「他の場所に設置してある 公開サーバー の名前解決を仕事として担うものではない」ということです。

例えば、 のように ルーター の ポートフォワーディング を利用してDNSサーバーを単独の サーバー機 で稼動させるケースは別として、 BIND を 構築中のLinuxサーバー で他の サーバー アプリケーション と一緒に稼動させるケースでは、

「サーバー機に不具合が起こってしまえば、DNSサーバーは他のサーバーアプリケーションと一緒に使えなくなる。」

ということになります。つまり一蓮托生というわけです。

結局、どんなにしっかりとしたスレーブDNSサーバーを設置してみたところで、それが役立つシチュエーションでは肝心の Webサーバー や メールサーバー 自体が使えなくなっている訳ですから、こういう運用形態におけるスレーブDNSサーバーは、

「必要なものではあるけれども、実際にはほとんど働く場面のない形だけのDNSサーバー。」

ということがいえるでしょう。

だとすれば、わざわざISPなどにお金の払ってまでスレーブDNSサーバーの設置を設置するのはもったいない話です。

かといって、スレーブDNSサーバーを請け負ってくれる友人を見つけるのも簡単なことではないでしょう。

そこでこの コンテンツ では、 フリーのスレーブDNSサーバー を利用することをお勧めします。

国内ではなかなか見当たらないのですが、海外にはこういうサービスいくつもありますから利用しないテはありません。

こういったスレーブDNSサーバーはレスポンスが悪かったり、時々つながらなくなったりすることがあるのですが、前の説明のとおり、

「とりあえずスレーブDNSサーバーとして利用できればそれでかまわない。」

という条件であれば何ら問題はないはずです。

いかがでしょうか？。

関連セクション・ 自宅内DNSサーバーの構築

関連ページ・ 名前解決とネームサーバー

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

ダイナミックDNSからの切り替え手順

ところで今、あなたの自宅 サーバー の 名前解決 の環境はどうなっているでしょうか。

「まだ 公開サーバー の構築を始めたばかりで、名前解決についてはこれから。」

という場合はゼロからのスタートになりますから、ある程度試行錯誤で手続きや構築を進めていっても問題は少ないでしょう。

ところが既に外部の DNSサーバー に名前解決をやってもらっている、あるいは ダイナミックDNS を使って既に公開サーバーとして継続稼動しており、それなりのサービスを配信中であるならば注意が必要です。

こういう場合は「利用する DNS を、外部のものから自宅のものに切り替える」という作業になるわけですから、手続きや構築の手順を間違えると「名前解決できない空白期間」が発生し、長期間に渡ってサービスを停止しなければならない恐れがあります。

この危険を回避する方法は、

「 ドメイン名 のDNS情報の変更を必ず一番最後に行う。」

という手順を守ることに尽きます。

「でも、それではDNSサーバーの動作チェックができないのでは？。」

と思われるかもしれませんが、それは思い違いです。

ここでもう一度「権威のあるDNSサーバー」の意味を思い出してください 。

例えば 構築中のLinuxサーバー で、 BIND を使って "obenri.com" に関するDNS情報を作成したとします。

しかし ルートサーバー 上に

「"obenri.com"という ドメイン名 に関する名前解決情報は、 IPアドレス △△△△で稼動しているDNSサーバー(つまり構築中の自宅サーバー)が管理しているから、そこに問い合わせに行きなさい。」

という情報が登録されるまでは、外部のDNSサーバーが 構築中のLinuxサーバー に問い合わせに来ることはありません。

ところがあなただけはそのIPアドレスもFQDNも知っているわけですから、ルートサーバーにその情報を登録していなくても、 クライアント機 の参照DNSサーバーを手動で設定し、動作確認を行うことができます。

換言すれば、

「DNSの動作チェックを行うのに、自宅のサーバーをDNSサーバーとして登録する必要も、ルートサーバーに"obenri.com"に関する「権威あるDNSサーバー」として登録する必要もない。」

わけですから、まずは構築作業と動作確認を先に行い、管理機関への諸々の登録作業は一番最後に行うのが理想、ということになります。

従って、「やらなきゃいけない手続きは始めにやっておこう。」とばかりに レジストラ などへの登録変更を先にやってしまうようなことがないように注意してください。

さて、DNSサーバーの構築については、もう一つ覚えておいたほうがよいことがあります。

DNSサーバーの構築が難しいといわれる本当の理由は、DNSの仕組みや設定ファイルの記述の難しさにあるのではなく、実は常に DNSキャッシュ を意識しなければならないところにあるといってよいかもしれません。

に詳しく説明しているとおり、DNSは特定のサーバーへの一極集中を防ぐ 分散システム になっていて、個々のDNSサーバー、 ルーター 、 クライアント などは、一つのゾーン情報 について一定時間(TTL=DNSキャッシュの保持時間 )は 「権威あるDNSサーバー」 にアクセスしなくても独自に名前解決できるようなシステムになっています。

ということは、例えばTTLの値を ６時間 と設定したままゾーン情報を WAN 空間に流してしまうと、レコードの書き間違いに気が付いて急いで修正を行っても、WAN空間では最大６時間、間違った情報が生き続けることになります。

つまりBINDは Apache などを扱う場合と違って、設定ファイルを書き換えて プロセス の再起動を行っても、 すぐには変更した情報が行き渡らない という性質を持っているため、手順を間違えると長時間のサービス停止を余儀なくされる恐れがあるというわけです。

DNSサーバーに関する手続きや設定はこのように外部のDNSの仕組みと連動していますから、安易に扱うと痛い目を見ますので、常に DNSキャッシュの存在を意識して 作業を行うように心掛けてください。

関連セクション・ 自宅内DNSサーバーの構築

関連ページ・ 名前解決とネームサーバー

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト