答えは、一秒で返ってきた。
金色のIPアドレス札。
その下に、緑の文字が光る。
キャッシュに記録あり。すぐ配送できます。
イトが小箱へ巻こうとした瞬間、ユイが名前札を二枚に分けた。
video.blue.example.
video-blue.example.
速い答えが返ったのは、下の名前だった。
イトが届けたいのは、上の名前だ。
配送許可は一回。残り五十秒。
点一つと横線一つは、同じ名前ではない
二枚は、離れて見るとよく似ている。
けれどドットで区切ると、構造が違う。
video.blue.example. は、video、blue、exampleという三つのラベルが並ぶ。
video-blue.example. は、video-blueとexampleという二つのラベルだ。
RFC 1034では、DNSの名前空間を木構造として扱い、ドメイン名を対象ノードからルートまでのラベル列で表す。表示では、具体的な側からルートに近い側へ、左から右に書く。
末尾のドットは、ルートまで含む完全な名前であることを示す。
イト
見た目が近くても、棚の場所は別なんだ
ユイ
点で区切った一つずつが違えば、問い合わせる名前も変わります
ピコ
そう。DNSは『だいたい似ている方』を探す仕組みではないよ
ここで使う .example は、説明と練習のための特別な名前だ。RFC 6761で例示用として予約されており、この物語の練習問い合わせを公開DNSへ送ってはいない。
DNSは、一冊の住所録ではない
イトは、上の名前札を配送門へ直接入れた。
門は動かない。
ドメイン名は人が扱いやすい名前だが、IPパケットの宛先欄へそのまま入れるものではない。
名前に結びつく情報を、DNSへ問い合わせる必要がある。
ピコが三つの役を見えるようにした。
- 端末から名前を受け取る リゾルバー
- 問い合わせを引き受け、答えか次の案内を探す 再帰リゾルバー
- 担当範囲の正式なデータを持つ 権威サーバー
実際の構成や呼び方には細かな違いがある。
この街では、端末側の入口、問い合わせを進める役、担当データの出どころを三つのカウンターに分けている。
RFC 1034は、DNSを分散して管理される名前空間、名前サーバー、リゾルバーから成る仕組みとして説明している。一台のサーバーが世界中の答えを全部持つ設計ではない。
速い答えは、別の名前には正しかった
緑のキャッシュ箱を開くと、記録の見出しが見えた。
video-blue.example.
答えは有効期限内だ。
偽物でも、壊れた記録でもない。
ただし、イトが尋ねたい名前とは違う。
キャッシュは、以前得たDNSの情報を一定時間再利用し、問い合わせを速くする。
DNSのリソースレコードにはTTLという値があり、キャッシュに残せる時間の目安になる。RFC 1035は、TTLをリソースレコードを再照会せずキャッシュできる時間として定めている。
イト
近道が悪いんじゃなくて、別の名前の近道だったんだ
マコト
早さだけを見て、質問を取り違えたらいけないね
ユイ
キャッシュを見るときも、何の名前に対する答えかが先です
残り三十八秒。
イトが選べる三つの道
案内台に、三つの方法が現れた。
- 一秒で返った別名のキャッシュを使う
- 第4話で覚えたIPアドレスを直接使う
- 完全な名前を確かめ、その名前でDNSへ問い合わせる
一つ目なら速い。けれど、別の名前に結びついた宛先だ。
二つ目ならDNSを待たなくていい。しかし、第4話で見たように、IPアドレスは現在も同じとは限らない。
三つ目は時間がかかる。残り時間内に、担当の答えへ着く保証はない。
イトは二枚の名前を、ドットごとに指で区切った。
上は三つのラベル。
下は二つのラベル。
「ぼくが聞きたいのは、上の完全な名前」
イトは、速い別名キャッシュのふたを閉じた。
video.blue.example. の名前札だけを、リゾルバーへ渡した。
答えではなく、次の案内が返る
再帰リゾルバーは、まず自分のキャッシュを探した。
対象の完全な名前に使える答えはない。
そこで、名前空間の上から順に案内をたどる。
最初のカウンターは、最終IPアドレスを返さなかった。
代わりに、次に尋ねる担当を示す。
二つ目も、その下の担当を示す。
このように「答えはここではなく、次はこちら」と返す案内を リファラル と呼ぶ。
再帰リゾルバーは利用者の代わりに、その先へ問い合わせを進めた。
残り二十六秒。
example側の案内。
残り十八秒。
blue.exampleを担当する案内。
残り十一秒。
対象名のデータを持つ権威サーバーへ着いた。
権威サーバーは、自分が担当する範囲の情報から答える。
今回求めたのは、IPv6アドレスに結びつく AAAAレコード だ。
IPv4アドレスなら、主にAレコードを使う。
DNSはIPアドレス以外にもさまざまなリソースレコードを扱うが、今日は名前から配送先を得るところだけを見る。
残り四秒のAAAA札
残り四秒。
権威サーバーから、金色のAAAA札が返った。
札の見出しは、イトが送った完全な名前と一致している。
再帰リゾルバーは答えを端末側へ返し、TTLと一緒にキャッシュへ控えた。
イトは、そのAAAA札を青い映像パケットへ巻く。
配送門が開いた。
パケットは video.blue.example. の練習受取台へ届いた。
一秒で答えた video-blue.example. の道は、閉じたままだ。
夕焼けの一枚は、上の名前に結びついた受取台だけに現れた。
時計がゼロになった。
イトは、閉じた別名キャッシュと、届いた映像を見比べた。
イト
速い答えより先に、何を聞いた答えかを見る
ピコ
うん。DNSは名前を勝手に似たものへ直す案内じゃない
ユイ
完全な名前を問い合わせ、必要なら案内をたどり、担当のデータから答えを得るんですね
DNSが答えたあとにも、残ること
今回のAAAA札にもTTLが付いている。
期限内なら、同じ問い合わせへキャッシュから早く答えられる場合がある。
期限が過ぎれば、もう一度現在の情報を確かめる。
ただし、DNSで名前がIPアドレスへ正しく結びついたことだけで、その相手の内容や安全性まで保証されるわけではない。
また、DNSが返したのは宛先の情報だ。
「アニメの続きを送ってほしい」という依頼までは入っていない。
練習受取台には、夕焼けの一枚だけがある。
その先の映像は、まだ届かない。
イトの前に、空の封筒が現れた。
宛先は書ける。
中身は空だ。
「住所が分かっただけじゃ、何をしてほしいか伝わらない」
イトは空の封筒を開いた。
「次は、この中にお願いを書くの？」
封筒の向こうで、リクエストとレスポンスを分ける二つの扉が開いた。
次回：お願いの言葉はどう届く？
DNSでは、ドットで区切られた完全な名前を問い合わせる。
リゾルバーはキャッシュを使い、必要なら案内をたどって担当のデータからAやAAAAなどの答えを得る。
速さより先に、どの名前に対する答えかを確かめる。
次回、ピコルート第6話。
お願いの言葉はどう届く？
DNSの基本を図でも整理するなら、DNSの仕組みへ進めます。