DNSサーバーを設置する意味とは

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

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

そして

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

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

ただしDNSは、例えば Webサーバー や メールサーバー のように、「ユーザーにとって直接的に有益な情報を扱う」ものではなく、それらのサーバーを効率よく運用させるための 裏方 に過ぎません。

また、通常の クライアント 用途としてのインターネット接続契約の場合には、クライアントは ISP や キャリア が運用している DNSサーバー を利用しますが、それも契約時にパソコンや ルーター に対して一度設定をしてしまうだけですから(しかも多くの場合その意味を全く理解せずに)、普段DNSの存在を意識することはまずありません。

そのためDNSは、非常に重要なシステムでありながら軽視されがちです。

しかし自分で 公開サーバー を構築し、運用するのであればDNSに関する知識は不可欠です。

もしDNSに関する知識が欠如しているとすれば、例えば通信トラブルに遭遇したとき、 IPアドレス に関する設定が原因なのか、それともDNSが正常に働いていないことが原因なのか、そういった最低レベルの問題点の切り分けすら容易ではありません。

外部の ダイナミックDNS を利用する今回のようなケースでは、実際のところは必ずしも自分でDNSサーバーを設置する必要はありませんが、敢えてこれを行うことで今後様々な面でプラスになることは間違いありません。

また以下に示すように、現在構築中の LAN には、実は意外な問題点があります。この問題を解決する最もスマートな手段としてもDNSサーバーの構築は有効となります。

関連セクション・ 固定IPでDNSサーバー構築

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

NAT+IPマスカレードの問題点について

DNSの具体的な説明の前に、まずはネットワークと 名前解決 の流れを説明しながら、 自宅ネットワークの弱点とその解決方法 を説明します。

一つの サブネット 内に 公開サーバー 機と クライアント機 を含む、現在構築中の LAN 構成を以下に示します。

現在構築中のLAN構成の一例

これは最も安価で、かつ最もシンプルで一般的なLAN構成ですが、実は大きな問題をひとつ抱えています。それは、

「LAN内の サーバー には、同じLAN内の他の クライアント機 から FQDN でのアクセスができない。」

ということです。

その理由を詳しく説明しましょう。

普通、任意のクライアント機(パソコン)からFQDNで外部のサーバーへアクセスする場合、次のようなステップで行われます。

一般的なFQDNの名前解決とサーバーへの接続の流れ

例えば上の図の中で、パソコンから "www.uheuhe.com" というホームページを見に行く場合を考えて見ましょう。

まずパソコンは、 "www.uheuhe.com" が指し示す IPアドレス を調べるために、まず WAN 空間上に設置された ISP の DNSサーバー に問い合わせを行います( (1) → )。

問い合わせを受けたISPのDNSサーバーは独自に ルートサーバー への問い合わせなどを行って、

「"www.uheuhe.com"の所在地のIPアドレスは"210.135.138.21x"。」

という名前解決を行い、その情報を問い合わせ元のパソコンに返します( (2) → )。

DNSサーバーから情報をもらったパソコンは、IPアドレス "210.135.138.21x" のサーバーに対してアクセスを行い( (3) → )、その要求に対して "www.uheuhe.com" が コンテンツ をパソコンに送り返して通信完了( (4) → )、ということになります。

では、現在構築中の ダイナミックDNS を利用した自宅サーバー "www.obenri.com" への、宅外のパソコンからのアクセスの仕組みを見てみましょう。

外部から自宅サーバーへの接続の流れ

ダイナミックDNSを利用して自宅のサーバーの名前解決を行う場合 、まず自宅サーバー "www.obenri.com" 上で稼動させている DiCE から、その自宅サーバーのサブネットのWAN側のIPアドレス情報が、 "ns0.oraora.net" へと送られ、 "ns0.oraora.net" 上で

という名前解決情報が作成されます。

そして、宅外のLAN空間に設置されたパソコンから "www.obenri.com" へのアクセスが試みられた場合には、そのパソコンはいつもと同じようにWAN空間に設置されたISPのDNSサーバーに、 「"www.obenri.comのIPアドレスは何ですか？」 という問い合わせを行います( (1) → )。

問い合わせを受けたISPのDNSサーバーは、ルートサーバーを通じてその名前解決の情報元を探し、 "obenri.com" に対する 権威あるDNSサーバー である "ns0.oraora.net" へ問い合わせを行い( (2) → )、

「"www.obenri.com"の所在地のIPアドレスは"210.182.220.16x"。」

という名前解決情報をもらい( (3) → )、更にその情報を問い合わせ元のパソコンに返します( (4) → )。

すると名前解決情報をもらった宅外のパソコンは、 "210.182.220.16x" に、つまり ルーター のWAN側に、 ポート番号 80番 (つまり HTTP )でwebコンテンツの要求を行います。

すると、 の設定に従って、ルーター上での NAT + IPマスカレード 更に ポートフォワーディング 処理を経て、その要求は "www.obenri.com(192.168.100.11)" へと送られます( (5) → )。

そして、 "www.obenri.com" は要求に応えて情報を発信し、ルーターで元のIPアドレス(WAN側の210.182.220.16x)からの応答として、要求元のパソコンにwebコンテンツのデータを送り届けることになります( (6) → )。

ところが、同じ要求を "www.obenri.com" と同じサブネットにあるパソコンから行うとどうなるでしょう。

LAN内部のパソコンから自宅サーバーへの接続の流れ

この場合、名前解決の流れである (1) 〜 (4) までは、前のケースと全く同じですが、 (5) のステップで問題が発生することにお気づきでしょうか。

つまり、自宅のLANに設置されたパソコンは、 "www.obenri.com" にアクセスする際に、外部のDNSサーバーから得た名前解決情報

「"www.obenri.com"の所在地のIPアドレスは"210.182.220.16x"。」

を利用することになりますが、同じサブネット内の ホスト機 同士では、NATもIPマスカレードも無関係ですから、 "www.obenri.com" にアクセスするには

「"www.obenri.com"の所在地のIPアドレスは"192.168.100.11"。」

でなければならないことになります。つまりWANに設置されたDNSサーバーを利用すると、同じサブネット内のパソコンからは "www.obenri.com" を見つけることができないというわけです。

変な話ですが、自宅サーバーのコンテンツは同じ宅内のパソコンから最も近いところにあるにも係わらず、アクセスすることができない、という不思議な現象が起こってしまうことになります。

関連セクション・ 固定IPでDNSサーバー構築

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

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

問題を解決するいくつかの方法

WAN空間のプロキシサーバーを利用する

制約や問題はありますが、「とりあえず使える」のは、 WAN に設置された プロキシサーバー を利用するという手段です。

プロキシサーバーを利用すると、通信は以下のような流れになります。

プロキシサーバーを利用した自宅サーバーへの接続

要は、 名前解決 の要求からweb コンテンツ の送受信まで、すべてをプロキシサーバーに依存し、 サブネット 内での直接アクセスを行わないことで、同じサブネット内の ホスト機 同士が、あたかも「違うサブネットに存在する」かのように振舞わせるということです。

この方法の問題は、 パケット が非常に複雑な経路を通るためにエラーが起こりやすく、通信が全般に遅くなることです。特に、本来最も高速であるはずの LAN 通信のメリットが全く生かせなくなってしまいます。

また、利用可能なプロキシサーバーを見つけなければならないという大きな問題がありますから、プロキシサーバーを廃止する ISP が多い昨今では、これが一番の問題かもしれません。

LAN内では常にプライベートIPアドレスを利用する

要は FQDN と IPアドレス との関係に問題があるわけですから、 LAN 内ではFQDNを使わない、つまり

「LAN内のホストから"www.obenri.com"にアクセスするときは名前解決に頼らずに、常に プライベートIPアドレス で直接指定する。」

という手段をとるのが最も解りやすい方法です。

例えば、 Webブラウザ で

を見るときは

で見る、という具合です。 メールサーバー も FTPサーバー も SSHクライアント からのアクセスも、同様にIPアドレスで指定します。

だたし、この方法の問題点のひとつは、 構築中のLinuxサーバー 上で、 「一つのIPアドレスで複数のFQDNを運用するケース」 、つまり サブドメイン や バーチャルドメイン を運用する場合には、どれか一つのFQDNに対してしかアクセスできないということです。

例えば、 構築中のLinuxサーバー 上の Webサーバー で、

を同時に運用する場合、

で見ることができるのはどちらか一方ということになってしまいます。

この方法のもう一つの問題は、LAN内の クライアント機 を外部に持ち出して使用する場合に、通信関係の アプリケーション の設定をすべてプライベートIPアドレスからFQDNに変更しなければならないということです。

そのクライアント機がデスクトップパソコンであって、屋外に持ち出す可能性がほとんどないということであれば話は別ですが、持ち歩きが中心のノートパソコンの場合は結構面倒かもしれません。

クライアント機の"hosts"ファイルを利用する

WindowsOS や MacintoshOS は、 WBEL や CentOS と同じく hostsファイル に IPアドレス と FQDN の対応を記述することで、 DNSサーバー より優先的に 名前解決 を行うFQDNを指定することができます 。

hostsファイルを利用した自宅サーバーへの接続

例えば上の図のように、各 クライアント機 のhostsファイルに、

のように記述しておけば、これらのFQDNにアクセスを行う場合にはDNSサーバーが参照されませんから、そのクライアント機と "www.obenri.com" が同じ サブネット 内にあることを特に意識することなく運用できます。

またこの方法には前に説明した、「常に プライベートIPアドレス を利用する」場合の「 サブドメイン や バーチャルドメイン を扱うことができない。」 という問題もありません。

ただし、そのクライアント機を外部に持ち出して使用する場合には、当然そのhostsファイルの記述は無効にしなければなりません。

しかしながら、プライベートIPアドレスを直接利用する場合と違って、 アプリケーション 毎に設定を変更する必要はなく、hostsファイルの内容を書き換えるか、 LAN 用と WAN 用の二種類のhostsファイルを予め準備しておき、必要に応じて差し替えれば良いだけですから、この方法のほうがずっと実用的です。

ただし、hostsファイルはLAN内の全てのクライアント機に設定しなければなりませんし、 サーバー のFQDNを変更した場合には、それらのすべてのhostsファイルを修正する必要がありますから、全く面倒がない、ということではありません。

LAN専用のDNSサーバーを構築する

この コンテンツ でお勧めする方法です。

それなりに知識と手間はかかりますが、 LAN 内の クライアント機 には手を加える必要がなく、外部にクライアント機を持ち出しても通信設定の変更が不要で、 サーバー の FQDN に変更が行われても各クライアント機の設定をどうにかする必要もありません。

LAN内にDNSサーバーを構築した場合の流れ

上の図のとおり、 パケット の流れは非常にシンプルです。

"www.obenri.com" は Webサーバー などと同時に "*.obenri.com" に関して 「権威ある DNSサーバー 」 として稼動させておきます。

そしてLAN内のすべてのクライアント機には、 WAN 空間にある ISP の DNSサーバー に対してではなく、LAN内に設置されている 構築中のLinuxサーバー に対して名前解決を依頼するように、 ルーター の DHCPサーバー を設定します。

すると、 "*.obenri.com" に関する名前解決はルートサーバーに問い合わせるまでもなく 構築中のLinuxサーバー が自分で「権威ある」回答をしますから、

という情報を持たせておけば、確実にLAN内でのアクセスが可能になるわけです。

また、LAN内のクライアント機が "*.obenri.com" 以外の名前解決を依頼してきた場合、 構築中のLinuxサーバー はWAN空間の ルートサーバー に問い合わせを行って名前解決情報をクライアント機に返します。

そして 構築中のLinuxサーバー は同時に DNS の キャッシュ サーバー として動作しますから、ISPのDNSサーバーを利用するのと何ら変わりなくインターネットを利用できるわけです。

もちろん、DNSの設定を変更すればLAN内の全てのホスト機に対して自動的に変更が通知されますから、 hostsファイル の書き換えのような個別の設定は必要ありません。

関連セクション・ 固定IPでDNSサーバー構築

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

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

hostsファイルか自前DNSサーバーか

このサイトでは、この 「LAN内の名前解決の問題」 に対して、 hostsファイル の記述による対処方法と、 構築中のLinuxサーバー に DNSサーバー を構築する二種類の方法を解説します。

ファイトのある人はいきなりDNSサーバーを設置しても構いませんが、DNSサーバーの構築はややこし過ぎる割に地味すぎて、正直なところ「憂鬱な」作業です。

まずは簡単なhostsファイルの設定で「とりあえず問題なく運用できるように」しておいて、それからあまり憂鬱ではない他の サーバー アプリケーション を構築してみて、そして気が済んだところでDNSサーバーに取り掛かってもいいかもしれません。経験的に。

関連セクション・ 固定IPでDNSサーバー構築

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

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