なぜ「DNSの浸透」は問題視されるのか (2)

((1)の続きです)

DNSキャッシュサーバは、まず「www.example.comのIPv4アドレスを教えて！」とルートサーバ(DNS Root Server)に問い合わせます(2)。 すると、ルートサーバは「.comは○○に委任している」と応えます(3)。

次にDNSキャッシュサーバは「com」のDNS権威サーバに「www.example.comのIPv4アドレスを教えて！」と問い合わせます(4)。 すると「com」のDNS権威サーバは「example.comは××に委任している」と応えます(5)。

DNSキャッシュサーバは、さらに今度はexample.comのDNS権威サーバに「www.example.comのIPv4アドレスを教えて！」と問い合わせます(6)。 するとexample.comのDNS権威サーバは、「www.example.comは△△だよ」といって対応するIPアドレスを返してくれます(7)。

www.example.comのIPアドレスを得たDNSキャッシュサーバは、ユーザPC内にあるDNSクライアントに結果を通知します(8)。

実際には「com」のような頻繁に参照される名前については、キャッシュが有効に機能するため、ルートサーバへの問い合わせが毎回行われるわけではありません。

このように、名前に対応する結果を得るために、複数のDNS権威サーバに対して同じ内容の問い合わせを繰り返し送信する手法は「反復検索」と呼ばれています。 また、このときのルートサーバを頂点とする木構造は委任ツリーと呼ばれます。

2. DNSキャッシュの仕組みとTTL

このように、委任ツリーに沿って名前解決が行われる「全体像としてのDNS」ですが、ユーザが利用するDNSキャッシュサーバと、最終的な応答をしているDNS権威サーバは、基本的に1対1の関係にあります。

DNSにおいて情報を更新した場合、反復検索の場合と同様に更新情報も委任ツリーに沿って上位ゾーンから順番に伝わって行くと誤解されていることもありますが、DNS情報の更新は「伝わって行くもの」ではありません。

「DNSでの更新情報が反映されていない」というのは、単に「古いキャッシュが残っている」というだけの話なので、その古いキャッシュが消えれば情報は更新されます。 そして、その古いキャッシュが生き残れる期間を設定しているのは、DNS情報を管理しているそれぞれのDNS権威サーバです。

このことを理解するには、DNSのプロトコルを知る必要があります。 今度は、先ほどの反復検索をプロトコル的な視点で見ます。

2.1. 反復検索をもう少し詳しく

先ほどの反復検索の仕組みをもう一度見てみると、「ここに聞くといいよ！」つまり「○○は××に委任しています」とDNS権威サーバを探している部分と、DNS権威サーバが管理するレコードそのものがDNSキャッシュサーバに返される部分があります。

以下の図の緑色の部分が、委任先を伝えている部分で、最後にIPv4アドレスを答えている部分が実際の応答を返している部分です。

各応答に含まれる内容を比較すると、上記図の緑色の部分は主にNSレコードをやり取りしています。 最後のDNS権威サーバからの応答では、主にAレコードのやり取りを行っています。

このように、反復検索の途中段階でのやり取りと、最後のやり取りでは扱っているメッセージが異なるため、DNSキャッシュサーバにキャッシュされる情報も異なります。 緑色部分のやり取りによってDNSキャッシュサーバにキャッシュされるのは、「この部分に関しては○○に聞いて下さい」という答えに含まれているNSレコードで、最後の段階では「この名前に対応しているのは、このIPv4アドレスです」というAレコードです(各返答で同じ種類のレコードが結果内に複数含まれることもありますし、「付加情報(Additional)」も含まれています。詳細な情報が必要な方は「実践DNS」を読んで下さい。いい本です。)。

2.2. パケットに含まれる情報を見る

これらのやり取りをさらに詳細に見てみると以下のようになります(DNSルート自身を取得する部分は割愛)。

DNSプロトコルは行きと返りで同じフォーマットとなっています。 DNSパケットは、Header、Question、Answer、Authority、Additionalの5つの「セクション」に別れており、必要に応じて各セクションがパケットに含まれます。

まず、(2)のDNSキャッシュサーバがDNSルートサーバに対して問い合わせるところは、以下のようなメッセージになります。 このメッセージは、宛先ポート番号が53番のUDPパケットとして送信されます。 (4)と(6)の部分も問い合わせ先が違うだけで同じメッセージが送信されます。

Header	QPCODE=QUERY
Question	QNAME=www.example.com. QCLASS=IN QTYPE=A

(2)の名前解決要求のパケットは、HeaderとQuestionの二つのセクションから構成されていますが、Header内で「このパケットが含んでいる内容はQueryです」と述べつつ、Questionで、その内容が記述されています。

(続く：次へ)

最近のエントリ

• 「ピアリング戦記」の英訳版EPUBを無料配布します！
• IPv4アドレス移転の売買価格推移および移転組織ランキング100
• 例示用IPv6アドレス 3fff::/20 が新たに追加
• ShowNet 2024のL2L3
• ShowNet 2024 ローカル5G
• ShowNetのローカル5G企画（2022年、2023年）

過去記事

過去記事一覧