要約

  • 2013年2月の RFC 6761 は IANA の特別用途ドメイン名登録簿を設けた。新しい名前を指定する仕様には、利用者から登録機関まで七種類の当事者がどう扱うかを明記させる。
  • 最初の登録簿には従来の予約名とプライベートアドレスの逆引きゾーンが入った。同じ「特別」でも、localhost はループバック、invalid は否定応答、私有逆引きはローカルネットワークでの処理という具合に、答えも担当者も異なる。
  • 2017年の RFC 8244 は IETF と ICANN の正式な調整手続きが欠けていること、「技術的利用」の範囲が定まらないことを記録した。登録簿の行は指定の証拠であり、現場のリゾルバーの応答記録ではない。

登録簿は問い合わせに答えない

開発者が試験用のホスト名をプログラムへ渡したとする。アプリは名前解決ライブラリを呼ぶ。ライブラリはキャッシュを持つDNSサーバーへ問い合わせ、その先で権威サーバーが関わるかもしれない。登録業者は別の場所で、その名前を販売できるか判断する。文字列は同じでも、各段階にある判断権は別だ。登録簿に「特別用途」と載せただけで、この鎖全体の設定が変わるわけではない。

1999年の RFC 2606 は、試験、文書の例、失敗を予定した名前、ローカルホストのために一部の名前を予約した。作り物の例が実在するドメインとぶつかる危険に向き合った仕事だった。RFC 6761 が2013年に問うたのは、その予約済みの名前をどの機械がどの時点で見分け、どう答えるかである。名前を売らないという決定と、端末が正しい応答を返すことの間には実装が横たわる。

RFC 6761 が作った IANA登録簿 には、従来の予約名と私有アドレスの逆引きゾーンが最初に並んだ。各行は動作を定める文書を指す。リゾルバーが問い合わせのたびに一覧を読みに行く仕組みではない。表は約束の索引であり、実際の応答は端末、サーバー、運用設定の中で生まれる。

七つの問いを誰に向けるか

新しい特別用途名には、IETFの Standards Action または IESG の承認を受けた仕様が必要だ。対象となる名前を明確にし、「ドメイン名予約に関する考慮事項」で七つの役割に答える。人間の利用者は特別だと意識すべきか。アプリケーションはどうか。名前解決APIとライブラリはどうか。キャッシュDNSサーバー、権威DNSサーバーはどうか。サーバー運用者に何を知らせるか。登録機関は申請をどう扱うか。

七者が同じ処理をするという意味ではない。たとえば 10.in-addr.arpa のような私有アドレスの逆引きゾーンでは、アプリと名前解決APIは通常どおり設定済みキャッシュサーバーに問い合わせる。一方、キャッシュサーバーは既定では外部の権威サーバーへ探しに行かず、ローカルに答えるべきだ。私有ネットワークが権威サーバーを用意している場合の設定も考慮される。アプリからDNSパケットが出たという観測だけでは、規則違反かどうかは分からない。判断する役は次の段階にいる。

localhost のアドレス問い合わせなら、APIやキャッシュサーバーはループバックを返す。invalid なら存在しないという即時の応答が求められる。両方とも「予約済み」と呼べるが、返すものも、止める場所も異なる。公開リゾルバー一台だけを試しても、端末のライブラリが手前で答えたかは見えない。登録簿だけを読んでも、どの設定が走っているかは分からない。

現在の IANA一覧 には localhost、invalid、local、onion、home.arpa、私有逆引きゾーンなどが、それぞれ別の参照文書とともに載る。DNSの内部で特別なキャッシュ処理をするものも、ローカルな解決やアプリ側の文脈を要するものもある。RFC 6761は全件をトップレベル名に限っていないし、全件がDNSを迂回するとも定めていない。一覧の統一感は、動作の統一を意味しない。

名前だけが別のネットワークへ行く

ローカルな名前をメールに貼り付けると、元の環境と名前が離れる。受け手が別のネットワークで同じ文字列を使えば、違う先を指すか、どこにも届かない。RFC 8244 は、こうした文脈のずれを特別用途名の問題として扱った。文字列を共有できても、その意味を決める設定まで共有できるとは限らない。

2017年10月の RFC 8244 は解決策ではなく問題の整理だった。IETF と ICANN には連絡の関係があっても、特別用途名の割り当てを正式に調整する手続きはなかった。「技術的利用」の範囲にも明確な合意がない。両機関が名前空間に関わっていても、第三者が許可を求めずに名前を使い始めるのを止める力はない、と文書は記した。

さらに、内輪だけで使うつもりの名前が外へ漏れる、非公式な利用が後の正式な割り当てと衝突する、開発者が手続きを知らないといった筋道も列挙した。どの製品で実際に起きたかを決めるには、当時の設定と問い合わせ記録が必要だ。IANA の行だけで個別の障害を説明することはできない。

この話の皮肉は、きれいな登録表が七か所に分かれた現場を前提にしていたことだ。2013年の仕様は、名前を載せる前に各持ち場の仕事を書き出させた。2017年の文書は、その登録を誰と調整するのかという入口の問題まで明るみに出した。