【図解】DNSクエリの仕組み,通信フロー 〜グルーレコード,コンテンツ,キャッシュ,フルリゾルバ,フォワーダ,ルートヒントについて～

一般的なDNSクエリ/レスポンスの通信フロー

ホームネットワークの構成例

ホームネットワークでの一般的なDNS通信フローを以下に示します。

PCから見たとき（赤文字・赤線）は1往復だけですが、その背後にはキャッシュ状況に応じて、色々とクエリ/レスポンスが発生していることが分かります。（なお、PC内でのキャッシュもありますので、その場合は当然DNSサーバにも聞きに行きません。)

PCのような『DNSサーバに聞きに行くだけ』のDNSクライアントを『スタブリゾルバ』、その問い合わせ先のような『名前解決を責任もって最後まで実施してくれる』DNSサーバを『フルサービスリゾルバ（フルリゾルバ）』と呼びます。

フルリゾルバは内部に『ルートヒント』と呼ばれるDNSサーバのIPアドレスを持っています(通常はLinuxのbind等のDNSサーバのインストール時に含まれます。https://www.internic.net/domain/named.root でも確認可能)。

なので、まったくキャッシュが無い場合はこのルートヒントへの問い合わせからスタートします。

上図にあるように、ルートヒントから .com ゾーンのDNSサーバへ、そして .com ゾーンのDNSサーバから nesuke.com ゾーンのDNSサーバへ、と聞いて回答を得ては、その回答にあるサーバへさらに問い合わせていく、というのを繰り返すことを『再帰問合せ』と呼びます。『フルリゾルバを有効にする設定＝再帰問合せを有効にする設定』と考えても良いでしょう。

フルリゾルバは(CPUリソースを消費するので)普通は一般公開しませんが、ぷらら等のISP事業者や、Google等のITリーダー企業は、善意で無償で使えるフルリゾルバを用意しています。Google は 8.8.8.8 と 8.8.4.4 という覚えやすいDNSフルリゾルバを用意しているため、とても有名です。

また、フルリゾルバが問合せに行っているDNSサーバはいずれも『コンテンツサーバ(もしくは権威サーバ: AUTHORITY SERVER)』と呼ばれます。AレコードやNSレコード等のレコード情報が設定されているサーバのことです。

インターネットに公開するコンテンツサーバで、再帰問合せを有効にしていると、不特定多数のクライアントからDNSサーバのCPUリソースを無駄に使われてしまい、DoS攻撃によりサーバダウンの危機に晒されます。このような状態をオープンリゾルバと呼びます。

なのでコンテンツサーバの設定として『再帰問合せはOFF』、もしくは、『再帰問合せを受け付ける送信元IPの範囲を自身の企業内のIPに限定』という設定にすべきです。

エンタープライズでのDNS サーバの設計パターン例

エンタープライズの場合は、自身が持つWebサーバ等を名前解決するためのDNSコンテンツサーバを自身で構築していることが多いです。それもインターネット公開するものと公開しないものを同じドメインで管理する場合も多く、管理が煩雑です。

例えば企業Aが、ISP業者BからGlobal IP 8個付きのインターネット回線を契約し、example.com というドメイン名を『お名前.com』等のサイトから購入したとします。

また、インターネットへ公開(企業内部からも閲覧可)するWebサーバのURLを www.example.com (IP=200.200.200.200) とし、企業内部からのみ閲覧可能なWebサーバのURLを www2.example.com (IP=10.10.10.10) とします。

企業内部からのみ閲覧可能なWebサーバのDNS登録

内部からのみ閲覧可能なWebサーバをインターネットに公開するわけにはいきません。

なので内部用のexample.comゾーンを管理するコンテンツサーバを構築し、そこに www.example.com のレコードを登録します。

そして自身のドメイン管理外(つまりexample.com 以外のドメイン)の問い合わせについては、『DNSフォワーダー』の設定によりフルリゾルバへフォワードします。

インターネットから閲覧可能なWebサーバのDNS登録

インターネットから閲覧できるためには、インターネット用のexample.comゾーンを管理するコンテンツサーバを別途構築し、そこに www.example.com のレコードを登録します。下記の例は、Linux BINDでの設定書式になります。

そして次にこのDNSサーバの情報を上位DNSサーバに登録する必要があります。

例えば構築したインターネット向けDNSサーバが『ホスト名：ns.example.com , IP：200.200.201.201』だった場合、.comドメインのDNSサーバに、『example.comのNSレコード=ns.example.com』と『ns.example.comのAレコード=200.200.201.201』という2つのレコードを登録してもらうよう申請します。

このような問い合わせ先を上位ドメインから下位ドメイン(サブドメイン)へぶん投げる行為を『権限委譲(Delegation)』と呼びます。

NSレコードはホスト名を指定するので、ここで example.com ドメインのホスト名を使う場合は、そのホスト名のAレコードだけは上位のDNSサーバへ登録してもらいます。このように、本来サブドメインのレコードである『ns.example.com の A レコード =200.200.201.201』を親ドメインの .com ゾーンDNSサーバに登録するようなレコードを『グルーレコード(glue record)』と呼びます。

なお、DNSサーバをたくさん立てるのもコストが掛かるので、通信の効率性も含め、このインターネット用コンテンツサーバを、企業内部のIPアドレスからのみが使える『フルリゾルバ』としても動作させます(bind では allow-recursion で設定)。

ところがこれだけでは1つ問題が残ります。企業内部からこの www.example.com にアクセスできないのです。これは、内部用のDNSコンテンツサーバが『example.com』のドメインを管理しているにも関わらず、www.example.com のレコードが無いためです。

内部用のDNSコンテンツサーバは、『example.com』以外のゾーンの問い合わせはインターネット用のコンテンツサーバ兼フルリゾルバへ問い合わせをフォワードしますが、自身の管理範囲である『example.com』のゾーンに関する問合せは、自身に存在していなかったら自信を持って『無い！』と回答するのです。

なので内部用コンテンツサーバにもレコードを追加する必要があります。

IT/インフラエンジニアの地位とスキル向上のために

【年収UPの体験談】あなたの IT/インフラエンジニアとしての価値

IT 技術の進化はとどまることを知りません。矢継ぎ早に新たな技術が出てきたり、数...

milestone-of-se.nesuke.com

【パケットキャプチャ】はNWエンジニアの価値を大きく高める

nesuke の考える NW エンジニアの2つの道 ネットワークエンジニアには ...

milestone-of-se.nesuke.com