要約

  • DNSOP は draft-jabley-dnsop-zone-cut-to-nowhere-01 の採択呼びかけを 2026 年 9 月 14 日まで行っている。Datatracker の状態は、採択済み文書や RFC ではなく、合意前の呼びかけである。
  • 草案は空のターゲットを持つ単一の NS レコードで、子ゾーンが別の DNS 名前空間にあることを親側から示す。そのレコードは到達可能な権威サーバーを示さず、公開解決や利用権限を決めない。

DNS の短い合図が有用なのは、言わないことまで正確に限定しているからだ。

企業や組織の DNS は、文字列としては同じ接尾辞を公共と内部で共有できる。公共の EXAMPLE.COM は誰でも問い合わせられる一方、CORP.EXAMPLE.COM は社内ネットワークのリゾルバーだけが答える、といった構成である。ノート PC が社外と社内を移動すれば、外部で得た否定応答と内部で得た肯定応答がキャッシュの中で衝突する。DNSSEC を意識するリゾルバーでは、外部からの署名済み否定応答が、後の内部応答を不正と扱う契機にもなり得る。

草案の狙いは、内部名を外へ露出することではない。親ゾーンが「子ゾーンはあるが、親が属する名前空間では使えない」と記録できるようにすることだ。これを zone cut to nowhere と呼ぶ。親には NS .、すなわちターゲットが空の NS レコードを一つ置く。そこには IP アドレスも到達可能なホスト名も含まれない。空白の後ろに秘密の宛先があるという意味でもない。

草案は似た見た目の構成を同一視しない。NS の RRSet に通常のサーバー名が一つでも加われば、空ターゲットが混ざっていても delegation to nowhere ではない。実サーバーを含むセットは別の運用上の意味を持ち得るため、草案は勝手な読み替えをしない。この境界がないと、実際の委任を「行き先なし」と取り違えたり、行き先のない合図を不完全な公開委任と誤解したりする。

RFC 1034 の通常の referral は、求める情報を持つ名前サーバーへの手掛かりを要求者に渡す。今回の空ターゲットはその手掛かりを渡さない。したがって、公共側の親が私的子ゾーンの接続案内所になるわけではない。外部の利用者は、この信号から内部サーバーの所在、サービスの稼働、ネットワークへの入場、契約上の利用可能性を推論できない。信号を普通の referral と読むことは、境界を表すための仕組みを架空の経路に変えてしまう。

DNSSEC についても同じ慎重さが必要だ。親の管理者が子の署名鍵を知っている場合、secure delegation to nowhere を置くことができる。正しい名前空間のサーバーから署名済み応答を受けた時に使う信頼アンカーを、利用者が保持できるためだ。しかし名前空間ごとの子が異なる署名を使う場合、または未署名の場合には、草案はこの手法を使わないよう求める。鍵に関する事実は、どのリゾルバーやアプリケーションにも同じ結果を義務づける普遍的な方針ではない。

DNSOP のチャーターは DNS の配備・運用上の考慮、プロトコルの保守と拡張を対象にする。キャッシュ、分割 DNS、検証の問題を検討するには適切な場である。そこに参加する運用者や関心を持つ人々は、障害の形や相互運用性の問題を示せる。ただし、参加したことだけで、内部ネットワークの停止損失を負担する組織の代理人になるわけではない。技術的な討議は根拠になり得ても、他者のサービスを拘束する委任状にはならない。

手続上の位置付けも過大にしてはならない。Datatracker はこの文書を DNSOP の候補となる個人 Internet-Draft とし、WG 状態を Call For Adoption By WG Issued、IESG 状態を I-D Exists とする。締切日や個々の賛成意見は、WG の合意、WG 文書、IESG の行為、RFC の公表を先取りしない。それぞれには別の主体、別の日付、別の根拠が必要である。

この草案が守ろうとしているのは、公共 DNS が私的 DNS の代弁者にならないことだ。親は自らの管理する名前空間に関する限定的な事実を伝える。子の運用者は、内部サーバー、リゾルバー、鍵、アクセス、障害対応を管理し続ける。外部のリゾルバーは不正確な「不存在」より良い情報を得るが、私的サービスを使えるという約束を得るわけではない。

実装する組織には、名前空間境界のローカル記録が必要である。親ゾーンの版、対象名の分類、変更承認者、影響するリゾルバー、鍵を知るという条件、試験日、見直し日、戻す権限を残す。内部アドレスや機密名称を公開する必要はない。目的は NS . が将来、故障、公開委任の欠落、あるいは暗黙のサービス提供と誤読されないようにすることだ。

資料は特定企業がこの草案を使っていること、全リゾルバーが同じ処理をすること、採択が決まったことを示していない。確認できるのは、DNSOP が、別空間にある子の存在を親が記録しつつ、その子を公開・管理・到達できるとは主張しない方法を検討しているという点である。

情報源

  1. DNSOP の採択呼びかけ
  2. draft-jabley-dnsop-zone-cut-to-nowhere-01
  3. DNSOP チャーター
  4. IETF Internet-Draft のストリーム状態
  5. RFC 1034: Domain Concepts and Facilities