要約

  • RFC 10001はRFC 3901を廃止し、ゾーンにIPv4到達可能な権威サーバーを二つ以上、IPv6到達可能なものを二つ以上要求する。各ファミリーの委任は他方に依存せず、両方が同等のDNSデータを返さなければならない。
  • A/AAAAやNSの存在だけでは、完全な委任鎖も稼働中のリスナーも証明できない。単一ファミリーの外部観測点から、親、グルー、兄弟ゾーン、UDP/TCP、経路、応答内容まで保存する必要がある。

変更審査のチェック表には、NSが二つ、Aが二つ、AAAAが二つと記録されていた。形式上は申し分ない。だが、IPv6だけで反復解決を行うと、NS名を収容する別のゾーンがIPv6で解決できず、最終権威へ進めなかった。チェック表はノードを数えたが、辺を検証していなかった。

二重スタックの監視ではこの不備が見えにくい。IPv6の試行が失敗してもIPv4で答えを得れば、最終メトリクスは成功になる。利用者の一部だけが名前を失い、運用側は「再現しない」と判断しやすい。

2026年8月にBCP 91として公開された RFC 10001 は、この状態をアドレスファミリー差による名前空間分断として扱う。リゾルバーはルートから参照をたどるが、自分が使えないファミリーでしか到達できない権威集合に着くと、そこで解決が終わる。

検証対象はゾーンファイルより大きい

NS名が委任対象ゾーン内にある場合、親は必要なグルーを返す。子側のA/AAAAも再検証時に整合していなければならない。NS名が兄弟ドメインにあるなら、その兄弟自身の親子鎖が同じファミリーで解決可能でなければならない。さらに、ルートまでのすべての親がそのファミリーで到達可能である必要がある。

RFC 10001は、レコードが欠ける場合だけでなく、レコードのアドレスでDNSサービスが応答しない場合も挙げる。したがって静的検査が確認できるのは公開状態までである。パケットを送って応答を得る検査が、実行状態を確認する。

親は参照とグルーを支配し、子は権威データとリスナーを支配する。兄弟ゾーンは別の運用主体かもしれない。ネットワークは経路、フィルタ、MTUを支配し、リゾルバーは選択と再試行を支配する。この分散した権限を一つの「DNS担当」に押し込むと、変更責任も復旧責任も曖昧になる。

RFCが引用する2023年の研究 How Ready Is DNS for an IPv6-Only World? も、AAAAの存在ではなく委任鎖全体を測った。壊れたIPv6委任が少数のDNS運用者に集中する構造も示した。数値は当時の測定であり、2026年の普及率ではない。しかし、一つの上流グルー変更が多数のゾーンに影響するという依存関係は、変更審査に直接関係する。

2004年の片側防護から対称な検証へ

RFC 3901 は、IPv6権威がまだ実験的だった2004年に、既存のIPv4名前空間を壊さないことを優先した。少なくとも一つのIPv4到達可能な権威を求め、IPv6-only再帰は二重スタックへの転送で補う形だった。

RFC 10001はその非対称性を廃止する。各ゾーンはIPv4で到達可能な権威を二つ以上、IPv6で到達可能なものを二つ以上備えなければならない。一台の二重スタックサーバーは各列で一度数えられる。IPv4の委任はIPv6接続に、IPv6の委任はIPv4接続に依存してはならない。両経路は同等のデータを返す。

ただし、アドレス数と障害領域数は違う。RFC 2182 が求めるトポロジーと運用の多様性は残る。同じ事業者、同じエニーキャスト基盤、同じ変更系に属する四アドレスは、一回の誤設定で同時に失われ得る。

データ同等性も独立した試験項目である。二つのファミリーでポートが開いていても、異なるゾーン版やRRsetを返せば、到達性の分断を内容の分断に置き換えただけだ。応答コード、SOA、RRset指紋、DNSSEC結果を照合する必要がある。

MTUは正しい委任を無効にできる

DNSSEC応答などが実効PMTUを超えると、UDP断片が黙って捨てられることがある。TCPでもPMTU通知が遮断されたり誤っていたりすれば、実経路より大きいセグメントを送って停止する。

RFC 10001は RFC 9715 に基づき、断片化を避ける。UDPには1400オクテット、より保守的には1232オクテットの上限を示し、TCPには送信MSS 1388または1220という対応を示す。RFC 9210 に従い、権威サーバーは断片UDPだけに頼らずTCPフォールバックを提供する。

これは無料の安全策ではない。小さいUDP上限はTCP接続を増やす。文書は3〜5%という測定を引用するが、各運用者に自環境の負荷測定を求める。変更前後でEDNS値、実サイズ、TC、TCP接続、MSS、遅延、CPUと接続状態を残すべきである。

例外経路にも所有者が要る

再帰リゾルバーは原則として二重スタックが望ましい。一方、IPv6-only環境がNAT64でIPv4権威へ到達したり、単一スタックで解けない問い合わせを二重スタック再帰へ送ったりする構成も許される。

NAT64で合成されたIPv6アドレスは、独立したIPv6権威ではない。PREF64、翻訳器、IPv4宛先に依存する。RFCは安全なPREF64発見について RFC 9872 を参照する。検証結果はネイティブ、翻訳、転送を区別しなければならない。

転送設計では、IPv4-onlyとIPv6-onlyの二台が相互に未解決問い合わせを返してはならない。両方で解けないゾーンに対して無限ループになる。転送先は自ら両ファミリーを完了でき、送り返さないことが条件である。

スタブ側にも選択の圧縮がある。実装によって保持できる再帰サーバー数は少なく、追加アドレスが予測不能に無視される。DHCPやルータ広告が配った一覧ではなく、端末が実際に採用した一覧を観測する必要がある。

変更証跡を経路単位にする

重要ゾーンごとにIPv4-onlyとIPv6-onlyの外部観測点から反復試験を行う。時刻、リゾルバー版、全参照、NS、A、AAAA、グルー、兄弟依存、接触した権威アドレス、UDP/TCP結果、EDNSサイズ、受信バイト、タイムアウト段階、DNSSEC、RRset指紋を一組として保存する。

アプリケーションが選んだアドレスと接続結果は別に保存する。DNS応答はアプリ利用を証明せず、接続成功は両ファミリーのDNS正常性を証明しない。

IANAの権威ネームサーバー技術要件 も自動更新されたわけではない。RFC 10001にIANAアクションはなく、既存の手続に従って更新を検討すべきだと述べる。BCP、手続文書、実際の受付検査は別状態である。

Heng Luのランニングコード優先に従えば、公開文書やレコードだけで採用を認定できない。最小初期仕様と自発的採用の枠組みでは、共通に強制すべきものは相互運用に必要な決定的規則であり、実装、調達、ロールバックは各運用者が実行証拠で決める。

AAAAがあるかではなく、その経路で権威が応答したかを承認する。