DNSの下線付き枝に衝突防止の登録簿ができた

要約

2019年3月の最良現行慣行 RFC 8552 は、親ドメインの下に下線付きラベルの枝を置き、汎用DNSレコードの解釈範囲を絞る慣行を整理した。DNSルートに最も近い下線付きラベルが大域的な名前となる。
IANAの登録簿は「RR種別と大域ラベル」の組が重複しないようにする。専門家審査は組の一意性と説明の明瞭さを確認し、その下のラベルは当該プロトコルの仕様が管理する。
同月の RFC 8553 は古い文書、特にSRVとURIの命名ひな型を統合登録簿へつなぎ直した。既存のソフトウェアと運用は維持した。登録は場所の割り当てであり、あるサービスが実際に何を公開しているかは権威DNSの応答とクライアントの問い合わせで確かめる。

TXTという型だけでは足りない

DNSの基本規則は、名前の各部分に世界共通の意味を与えない。特定の名前の下にどのレコード種別を置けるかも一律には制限しない。この自由があったから、プロトコルごとに新しい型を作らずTXTやSRVなどを再利用できた。だが、汎用の型に異なる用途が増えれば、親ドメインの同じ場所へ雑多な値が集まる。クライアントは目的の値を他の用途から探し出さなければならない。

RFC 8552 が説明した解決策は、データの型を変えるより置き場所を分けることだった。例えば親ドメイン example.org の下に _name.example.org を置き、その枝に特定のプロトコルのレコードを公開する。情報の対象は親ドメインのまま、問い合わせ先だけが細くなる。返るレコードの型は変わらず、枝の名前がその型をどう読むかの範囲を示す。

先頭の記号は普通のホスト名との見分けにも役立つ。RFCが参照するホスト命名規則では、下線付きラベルを合法な通常のホストラベルと区別できる。属性のための枝を作っても、そこに新しいホストがいるふりをしなくて済む。DNSパケットを作り直す変更ではない。既存の木の中で、解釈する場所を明示する約束だ。

先行例として、2000年2月の RFC 2782 はSRV問い合わせの _Service._Proto.Name 形式を定めた。サービス名とプロトコル名に記号を付け、自然に現れるホスト名との衝突を避けた。DNSを使ったサービス発見も後にこの慣行を使った。ただし、2019年の問題は「サービスをどこで見つけるか」ではない。互いに独立した仕様が、同じ大域的な下線付き位置を別々の意味で予約しないようにすることだった。

競合するのは根に近い位置

下線付きの枝が複数段になる場合、DNSルートに最も近いラベルが大域的なものとして扱われる。その下の名前は、その大域ラベルを定義した仕様の範囲に入る。異なるプロトコルの設計者が同時に取り得る入口は最上段だ。下段の細かな棚は自分の仕様で決められても、同じRR種別の同じ大域ラベルを別用途のために無断で使うと意味が衝突する。

そこでRFC 8552はIANAの「Underscored and Globally Scoped DNS Node Names」登録簿を作った。列はRR種別、ノード名、参照文書。重複を防ぐ鍵はRR種別と大域ラベルの組である。同じTXTでもラベルが違えば別の場所になる。同じラベルでもRR種別が違えば別の組になる。すべての下線付き名前を禁止する制度でも、各プロトコルの下位ラベルを全部IANAへ差し出す制度でもない。

新規登録は専門家審査を受ける。審査対象は、登録に必要な説明が明確か、指定した組が既存の行と重ならないかだ。RFCは、プロトコル全体の技術的な良し悪しをこの審査の対象から外している。空き棚の番号が取れたからといって、サービスが優秀である証明にも、あるドメインがそのレコードを公開した証明にもならない。防げるのは一つの場所への二重割り当てだ。

現在の IANA DNSパラメータ表から、大域ラベルを定めた文書へ進める。下位ラベルの並べ方はその文書を読む。特定ドメインの公開内容は、その権威DNSへ問い合わせる。表、仕様、実際のゾーンは別々の問いに答える。表の行だけで通信障害の原因を決めると、空の棚を満杯だと思い込む。

先に使われ、後で受付ができた

下線付きの名前は統合登録簿より前から使われていた。各RFCが必要な位置を定め、全体の取り合いを調べる場所はなかった。RFC 8552と同じ2019年3月の RFC 8553 は、既存文書を新しい仕組みへつないだ。SRVとURIの命名ひな型も改め、これからの大域ラベルは一つの登録簿を経由させた。

RFC 8553は既存のソフトウェアと運用慣行を維持すると明記した。登録簿の開設を理由に稼働中のゾーンを一斉に改名させたり、DNSの通信形式を変えたりしたわけではない。古い文書を読む人には現在の割り当て先を示し、新しく名前を作る人には衝突を調べる窓口を与えた。先に走っていた技術へ、後から管理の目印を付けた形だ。

この順序はSRVの歴史との違いをはっきりさせる。SRVはクライアントがサービスの行き先を探すための規則だ。RFC 8552と8553は、複数のサービスが共用するDNSの名前空間で、最上段の属性ラベルを誰が割り当てるかを扱った。行き先を選ぶ仕組みと、質問する場所が二重に定義されないようにする仕組みは別物である。

IANAの役割は必要な境界で止まる。下位ラベルはその大域ラベルの仕様が扱い、実際のレコードはゾーンの運用者が置き、回答の解釈はクライアントが担う。登録簿は共有する入口だけを調整する。そこまで絞ることで、どの当事者が何を示せばよいかも明確になる。

公式文書で確認できるのは命名規則、登録の鍵、既存仕様の更新である。名前の挙がるサービスが本当にその位置を使っていたと示すには、日付のある権威ゾーンの記録と、クライアントがその名前とRR種別で問い合わせた記録が要る。登録簿は所在を示し、実際のDNS応答が使用を示す。