名前からアドレスへ — DNSは巨大な委任の木

ここまでの第2期は、「宛先IPアドレスは分かっている」という前提で進めてきました。フレームの区切り方、IPアドレスの割り方、ルータの経路選択——どれも宛先IPが決まった後の話です。今回はその前段、人間が打った名前がIPアドレスに変わるところを扱います。

DNSを「階層構造の名前空間」と説明した図はよく見ます。右から左へ、jp → ad.jp → iij.ad.jp と絞り込んでいく木の絵です。間違いではありませんが、この絵はDNSでいちばん大事なことを描けていません。

大事なのは、木が深いことではなく、各ノードで権限そのものが別の組織に移っていることです。

RFC 1034 §4.2.1 は、委任の境界(カット)の周りにあるNSレコードについて、はっきりこう書いています。それらは親ゾーンの "NOT part of the authoritative data"——親の権威データの一部ではない、と。親は子の中身を持っていません。持っているのは「この先は別の担当だ」という道案内だけです。

この構造だと、.jp の運用者は日本国内のドメインの中身を一切知らずに済みます。ある会社がサーバのIPアドレスを変えても、.jp に届け出る必要はありません。変更が権限の境界の内側で閉じるからです。

さきほどの出力で、追加セクションにネームサーバのIPアドレスが一緒に入っていました。これをグルーレコードと呼びます。なぜ、わざわざアドレスまで付けてくるのでしょうか。

RFC 1034 §4.2.1 の説明が見事なので、そのまま引きます。委任先のネームサーバの名前が、その委任先のゾーン自身の中にある場合——

in order to learn a name server's address, we should contact the server using the address we wish to learn

「ネームサーバのアドレスを知るためには、まさにそのこれから知ろうとしているアドレスを使って、そのサーバに問い合わせなければならない」。

iij.ad.jp の担当は dns0.iij.ad.jp です。その dns0.iij.ad.jp のアドレスを知るには iij.ad.jp に聞く必要があり、iij.ad.jp に聞くには dns0.iij.ad.jp のアドレスが要る。完全な循環です。

DNSの解説でいちばん多く出会う混乱が、ここです。「再帰サーバ」「反復サーバ」という言い方が広まっているせいで、サーバに2つの種類があると思い込みやすくなっています。

そうではありません。RFC 9499 §6 は、再帰的問い合わせ(recursive query)を次のように定義しています。

A query with the Recursion Desired (RD) bit set to 1 in the header.

RDビット(Recursion Desired)が1になっている問い合わせ、それが再帰的問い合わせです。つまり再帰か否かは、問い合わせる側が1問ごとにヘッダのビットで指定するモードであって、サーバの属性ではありません。

端末のスタブリゾルバは、RFC 9499 の定義では "cannot perform all resolution itself"——自分だけでは解決を完遂できないものです。だから設定されたフルサービスリゾルバにRD=1で丸投げします。

受け取ったフルサービスリゾルバは、自分が再帰モードで処理を引き受け、その内部ではルート・jp・iij.ad.jp へとRD=0で問い合わせて紹介を辿ります。この1台が、下流に対しては再帰、上流に対しては反復をやっているわけです。

フラグを見れば一目で分かります。同じサーバに同じ名前を尋ねても、RDビットの有無でフラグ表示が変わります。

$ dig @8.8.8.8 www.iij.ad.jp
;; flags: qr rd ra ad;  QUERY: 1, ANSWER: 1
            ~~ RD が立っている = 再帰を依頼した
 
$ dig @8.8.8.8 +norecurse www.iij.ad.jp
;; flags: qr ra ad;     QUERY: 1, ANSWER: 1
            RD が無い = 再帰を依頼していない

ここで必ず出てくるのが、「13なのは、DNS応答が512バイトに収まるようにするためだ」という説明です。すらすら読めて、いかにも根拠がありそうです。

しかし、これを現在形で書くと事実に反します。 実際に測ってみます。

読み取れることは2つです。

1つ目。NSレコード13本自体は、512バイトに収まっています。 ここまでは512バイト説と矛盾しません。

2つ目。しかし13台ぶんのアドレスは収まりません。 a.root では A が7本・AAAA が6本まで、k.root では A が13本・AAAA が2本まで。合計本数すら違います。どれが残るかは、たまたま応答したインスタンス次第なのです。

これは実測だけの話ではなく、RFC 8109 §4.2 も「AとAAAAのRRセットの合計サイズは元の512オクテットのペイロード上限を exceeds(超える)」と明言しています。

最後に、キャッシュの話をします。DNSが現実的な速度で動いているのは、同じ問いを何度もルートから辿り直さないからです。各レコードにはTTL(生存時間)が付いていて、その秒数のあいだ再利用されます。

なお、ここで言うTTLは秒数です。第2期で既に出てきたIPヘッダのTTLとは別物なので、混同しないでください(この2つの違いは第26週で改めて扱います)。

見落とされがちなのは、「見つからなかった」という結果もキャッシュされることです。これをネガティブキャッシュと呼びます。そして否定応答には2種類あり、混同されがちです。

種類        意味                              RCODE
NXDOMAIN    名前そのものが存在しない          Name Error   (§2.1)
NODATA      名前はあるが、そのタイプが無い    NOERROR      (§2.2)

NODATA の RCODE は NOERROR です。 エラーではありません。RFC 2308 §2.2 の表現では「RCODEがNOERRORにセットされ、関連する回答が無い」状態です。実際に引き比べると違いがはっきりします。

$ dig @8.8.8.8 nonexistent-xyz-987654.iana.org
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
;; ANSWER: 0, AUTHORITY: 1        ← 名前自体が無い
 
$ dig @8.8.8.8 a.root-servers.net MX
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; ANSWER: 0, AUTHORITY: 1        ← 名前はある。MXが無いだけ
;; AUTHORITY SECTION:
root-servers.net. 86400 IN SOA ... 14400 7200 1209600 3600000

では、この「無かった」をどれだけキャッシュしてよいのでしょうか。ここにも広く流布した誤りがあります。

RFC 2308 §3 は、SOAの MINIMUM フィールドと、SOAレコード自身のTTLの、小さい方と規定しています。MINIMUM だけを見る説明をよく見ますが、それでは不正確です。

jp.    86400    IN  SOA  z.dns.jp. root.dns.jp. 1789295402 3600 900 1814400 900
     ~~~~~                                                              ~~~
     SOA自身のTTL = 86400                              MINIMUM = 900
 
     → 小さい方は 900。ネガティブTTLは 900 秒

実際に存在しない jp 配下の名前を引くと、返ってくるSOAのTTLはちょうど 900 でした。規定どおりです。

なお RFC 2308 §5 は運用上の目安として、「1〜3時間の値がうまく機能することが分かっている」「1日を超えるのは問題含み」とも述べています。