要約

  • RFC 5855はIPv4とIPv6の逆引きゾーンに専用のネームサーバー名前空間を与え、親ゾーンのglueと合わせて別々のサーバー群で運用できるようにした。
  • RFCは運用者を分けるよう求めていない。選定はIANAの機能に属し、異なる名前だけでは経路や障害領域の独立性を証明できない。

逆引きDNSは、アドレスから対応する名前を探す仕組みとして説明される。しかしPTRを尋ねる前に、リゾルバーは対象となる逆引きゾーンの権威サーバーを発見しなくてはならない。サーバーのアドレスを解決できなければ、その手前で検索が止まる。ここにも、サービスを支える依存関係がある。

RFC 5855『Nameservers for IPv4 and IPv6 Reverse Zones』が扱ったのは、その発見経路だった。2010年5月にBest Current Practiceとして公開され、Joe AbleyとTerry Mandersonが共同執筆した。RFCが記録する当時の構成では、IN-ADDR.ARPAはルートサーバーの一部が提供し、IP6.ARPAはAPNIC、ARIN、ICANN、LACNIC、RIPE NCCが運用するシステムが提供していた。

提案は二つの逆引きツリーに、それぞれ安定したサーバー名の空間を与えた。IPv4はIN-ADDR-SERVERS.ARPAの下、IPv6はIP6-SERVERS.ARPAの下に置く。親にあたるARPAゾーンには、それぞれへ到達するIPv4とIPv6のglueを載せる。リゾルバーは委譲を受け取った段階でサーバーのアドレスを知ることができ、IP6.ARPAのサーバー名を解くための再帰検索を別に始めずに済む。

RFCにある問い合わせ例を見ると、この差は単なる表記ではない。従来のIP6.ARPAの委譲では、追加セクションにglueが含まれない場合があった。そのときリゾルバーは、逆引きゾーンに問い合わせる前に、列挙されたサーバー名の一つを解決しなくてはならない。RFC 5855は専用の名前と親ARPAのglueによって、その依存を委譲の段階で扱う。変更点は小さくても、すべての逆引き検索が通る道筋に作用する。

文書は名前の符号化サイズも比較している。付録の歴史的なIPv6例ではNS名の符号化が74バイト、IP6-SERVERS.ARPAを使う提案側では39バイトだった。これはDNS形式上の長さであり、実際の遅延や失敗率を測った数字ではない。共通の接尾辞を頻繁な委譲情報の中で圧縮できること、そして次にたどるべきサーバーの住所を明確にできることを示す比較だ。

名前を分けた設計は、運用も分けられるようにする意図を持つ。RFCはIPv4とIPv6の逆引きゾーンを別々のサーバー群へ委譲でき、一方の障害が他方の検索を損なう危険を減らせると説明する。ただし、これは可能性であって義務ではない。別会社、別施設、別のトランジット事業者や経路を指定してはいない。同じアドレス族の中では、サーバー名の空間と対応する逆引きゾーンが同じ障害に遭うこともあり得る。名前上の境界は選択肢を作るが、ネットワークや物理設備の独立性までは示さない。

残る判断の所在は、RFC自身が明記している。IANAの節は新たな委譲とglueを記録する一方、運用者の選定は文書の範囲外であり、IETFとICANNの覚書に基づくIANAの機能だとしている。つまりRFC 5855は技術的な接点と責任の受け渡しを定めた。今日の各サーバーを誰が運用し、サーバー群がどれほど独立しているかを認定したわけではない。

Mandersonの経験は、この境界の両側に記録されている。彼はRFCの共同執筆者であり、IETF Datatrackerにも同RFCが掲載されている。後年のRSSAC沿革によれば、彼は2013年にICANNのDNS Operations部門の管理を引き継ぎ、2014年にはチームがICANN ITに移りDNS Engineeringへ改称した。ICANNのインタビューも彼を当時の責任者として紹介する。これらは運用経験を裏づけるが、彼が単独でRFCの運用者を設計・選定・配置したことを示すものではない。

その線引きがあるからこそ、このRFCは分析に使いやすい。プロトコルが名前を与えられる範囲と、運用者間で決めるべきことを分けている。IPv4とIPv6の逆引きが本当に別々に失敗するかを知るには、稼働中のNS群、glue、ホスティング、経路、応答を調べる必要がある。規格に異なる接尾辞が二つあるだけでは答えにならない。

参考資料