要約

  • 現在のccTLD地図は27行のCSVを読み込み、全行をホスト済みとして扱うが、委任名にafrinicを含むのは24件だった。
  • 残る.so、.ng、.mlには、AFRINICが公開するNS2のIPv4・IPv6プレフィックス内のアドレスがあり、アドレス層では27件すべてを確認できた。
  • 地図には、ホスト名、アドレス、サービス・プレフィックス、観測時刻を結ぶ「ホスト関係の受領記録」が必要だ。契約や拠点、稼働率、ゾーン内容の権限まで証明したことにしてはいけない。

数字が正しくても、その根拠が見えるとは限らない。AFRINICのDNSプログラムは、25を超えるアフリカの国別トップレベルドメインに権威DNSを提供していると説明する。リンク先の分布地図はさらに具体的で、現在のCSVに27の国とccTLDを収録している。画面を作るコードは、CSVから来た各行にisHosted: trueを付け、配列の長さを統計値にする。

名前から数える方法は、24件までは簡単だ。ns-bi.afrinic.netのような委任名には、関係する組織がそのまま現れる。ところが.so、.ng、.mlの委任されたネームサーバー名にはafrinicという文字列がない。ここで検証を終えると、地図が3件多く数えているように見える。

その結論は誤りだ。必要なのは一段深い照合である。

3件をつなぐアドレス

.soではd.nic.soが鍵になる。9月12日に固定したDNSスナップショットでは、196.216.168.54と2001:43f8:120::54に解決された。IANAの現在の委任記録にも同じIPv4とIPv6が載る。

.ngではns5.nic.net.ngが196.216.168.41と2001:43f8:120::41を使う。.mlのd.nic.mlは196.216.168.37と2001:43f8:120::37だった。この2件もIANAの委任ページと一致する。

AFRINICの導入ガイドは、NS2をAS37177のサービスとして示し、IPv4に196.216.168.0/24、IPv6に2001:43f8:120::/48を公開している。3組のアドレスはいずれも該当範囲に入る。同じ検査をCSV全体に広げると、27ゾーンすべてで、少なくとも一つのネームサーバー・アドレスが両方の公開プレフィックスに確認できた。

したがって、27という件数を「誤り」と呼ぶ根拠はない。問題は、その件数を支える照合が地図から読めないことだ。

ホスト名は運用主体の名札ではない

ccTLD運営者が自らの命名規則を保ったまま、外部のセカンダリDNSを利用するのは不自然ではない。全サーバー名に提供者の名称を入れさせても、DNSの耐障害性は高まらない。むしろ、ブランド表示と技術的関係を混同する。

アドレスは有力な手掛かりだが、万能な証明でもない。エニーキャスト・プレフィックス内にあるという事実から、応答した物理拠点は分からない。遅延、稼働率、契約条件も分からない。特定時点のBGPオリジンを確認するには別の観測が要る。

さらに、ゾーン内容を決める権限とは切り離さなければならない。AFRINICのDNS Support Programは、自らをスレーブまたはセカンダリの提供者と位置付ける。データは管理者のマスター／プライマリから複製され、AFRINICはゾーンも内容も管理しない。応答を運ぶことと、国別ドメインを統治することは別の権限である。

地図の裏に短い記録を置く

CSVの列は国、ccTLD、旗だけだ。行ごとの確認日時、委任名、アドレス、照合したプレフィックス、状態履歴はない。コードも「稼働中」「準備中」「終了」「一時停止」を分けず、ファイルにある行をすべてホスト済みとする。

表示を軽くする設計には合理性がある。しかし、変更が起きたときに弱い。サーバー名だけが変われば、文字列監視はサービス終了を誤報しうる。アドレスがプレフィックスから外れても、終了なのか移行なのか、単なる更新待ちなのかを地図だけでは判断できない。

必要なのは巨大な運用台帳ではない。各行から開ける、日付付きのホスト関係記録で足りる。ccTLD、AFRINICサービスに使う委任名、観測したIPv4とIPv6、該当するサービス・プレフィックス、情報源、時刻、状態を示す。初回確認、最終確認、状態変更の日付も残すべきだ。

訂正窓口と限界も同じ場所に書ける。契約書、内部連絡先、ノード座標を公開する必要はない。サービス品質を保証する記録でもない。「なぜこのゾーンを現在の合計に含めたのか」を再現可能にするだけだ。

現行地図への最も強い反論ならぬ擁護は、分かりやすさと検査結果である。一般の利用者に毎回ルート委任とアドレス空間を読ませるべきではないし、固定時点では27件すべてに技術的な接続があった。ただ、簡潔な画面は証拠を隠す理由にはならない。折り畳んだ詳細なら両立できる。

.so、.ng、.mlは例外処理の失敗ではなく、共有インフラの本質を示す例だ。名前は地域に残り、アドレスは共通サービスへつながり、地図はその関係を一つの数字にする。信頼を生むのは同じ名前ではなく、照合をやり直せることだ。

情報源