要約

  • 9月13日の観測では、.psのルートグルーがRIPE NCCのネームサーバーの現行IPv6アドレスと一致していた。8月に指摘された残り3件は一致していない。
  • RIPE NCCによれば、ccTLDの連絡先から承認を得ない限り、IANAは申請を処理できなかった。4件は一つの修正バッチではなく、それぞれ独立した委任手続きである。
  • 障害は確認されていない。各委任には別のIPv6グルーと複数のIPv4グルーがあった。改善すべきは承認、技術確認、最終結果を案件別に結ぶ公開可能な記録である。

運用上の残件を数えるとき、合計値はしばしば仕事の姿を歪める。4件が3件になれば25％進んだように見える。しかし今回の変化が教えるのは進捗率ではない。そもそも4件を一つの作業と見なすべきではなかった、ということだ。

8月15日、Patrik WallstromはRIPE DNSワーキンググループで、ne.cctld.authdns.ripe.net、ps.cctld.authdns.ripe.net、sd.cctld.authdns.ripe.net、tj.cctld.authdns.ripe.netについて、ルートゾーンに古いIPv6グルーが残っていると報告した。RIPE NCCは1月、AuthDNSのIPv6リナンバリングを完了し、旧/48を完全に撤回し、大部分の後処理を終えたと発表していた。

8月20日のRIPE NCCの回答は、残件の権限構造を明らかにした。同組織は電子メール、電話、地域の連絡経路を使い、IANAにも申請を出した。しかしccTLD側の連絡先による承認がなければ、IANAは処理できなかった。ルートの委任情報を維持する責任は各TLD管理者にある。

これは単なる遅い事務処理ではない。ネームサーバー運用者が新しいアドレスを最もよく知っていても、別の管理者が責任を負う委任を一方的に変更できない。その制約自体がルートの保護である。

一つだけ一致した

観測は9月12日17時14分UTC、日本を含む東アジアでは9月13日に行った。a.root-servers.netとb.root-servers.netのリファラルを取得し、1.1.1.1と8.8.8.8がネームサーバー名に返したアドレスと比較した。

.psでは、二つのルートサーバーがともに2a13:27c0:30::105をグルーとして返した。二つの再帰リゾルバーもps.cctld.authdns.ripe.netに同じAAAAを返した。IANAの.ps委任ページもこの値を掲載し、ページ全体の更新日は9月8日だった。

他の三つは異なった。.neはルートの2001:67c:e0::101に対し名前の現行応答が2a13:27c0:30::101、.sdは2001:67c:e0::109に対し2a13:27c0:30::109、.tjは2001:67c:e0::117に対し2a13:27c0:30::117だった。IPv4はそれぞれ193.0.9.101、.109、.117で一致した。

ここから言えるのは、8月の4件の差異が観測時点で3件になったということまでだ。.psの変更を誰が申請・承認したのか、いつルートで提供され始めたのかは分からない。IANAページの更新日も、変更された項目を特定しない。それでも結果が分かれた事実は、RIPE NCCが説明した委任別の承認経路と整合する。

冗長性は障害の主張を退けるが、修正を不要にはしない

RIPE NCCは、4件の委任すべてに少なくとも別の稼働中IPv6グルーが一つあり、さらに複数のIPv4グルーがあるため、リゾルバーは委任をたどって名前を解決できると説明した。古いグルーが一つあることだけで、ccTLDが停止したとは言えない。

今回の調査は旧IPv6アドレスにパケットを送っていない。到達性、再試行遅延、利用者への影響は測定していない。lame delegation、DNSSEC障害、リゾルバー障害、権威サービス喪失を示す証拠もない。代替経路があることは重要だが、すべてのリゾルバーが同じ経路を遅延なく選んだという証明でもない。

つまり、連続性と正確性は別々に扱う必要がある。撤回済みプレフィックスへの参照は収束させるべきだが、その速度を上げるためにTLD管理者の承認を迂回すれば、より大きな安全機構を壊す。

2025年の終了記録を現在の待ち行列にしない

IANAの2025年7月ルート運用監査には、4ホストすべてに関係するネームサーバー変更申請が記録され、7月18日にAdministratively Closedとなっている。公開表には各終了理由がない。これは過去の結果であり、RIPE NCCが後に説明した申請の現在状態ではない。.psが今回一致した理由も説明しない。

公開資料は別々の瞬間を映す。監査表は古い申請の終わり、委任ページは現在掲載されるデータ、DNS観測はある時点の応答である。申請者の立場、管理者の承認、技術確認、終了理由、ルート上の結果を一つの案件として結ぶ情報が欠けている。

委任ごとに変更レシートを出す

必要なのは私信の公開ではない。TLD、ネームサーバー名、旧アドレスと申請アドレス、申請者の役割、公開して安全な申請識別子を記録する。管理者の承認状態と時刻、技術確認の結果、実施・撤回・終了・後続申請への移行といった最終状態、理由区分を続ける。

さらにルートゾーンのシリアルまたは観測時刻、現在提供中のグルー、次の行動、後続申請を結べば、「承認待ち」と「技術要件を満たさない」と「取り下げ」を区別できる。担当者の氏名や連絡内容は不要である。

RIPE 91のDNSワーキンググループ議事録は、リナンバリングを運用改善として説明し、旧IPv6アドレス停止後に届くクエリを捕捉して追跡に使う計画を記している。トラフィック観測は旧経路が使われる場所を示す。案件別レシートは、その参照を終わらせるための権限と判断を示す。

数字は3になった。しかし管理対象は最後まで4つの委任である。

情報源