要約
- ZDNSのレジストリ機能、権威DNS、二重スタック経路、複数都市への依存は公開記録から追えるため、ネットワークと論理サービスの証拠評価は「中」と判断できる。
- 北京の設備資料にある732ラックや懐柔の1,000超キャビネットは受け入れ施設全体の値であり、ZDNSの所有量、割当量、空き容量、障害時に使える余力を示さない。
- 耐障害性を調達判断に使うには、拠点別機能・実装量・平常負荷・最大拠点喪失試験・経路撤回・復元・緊急署名・エスクロー検証の、日付入り実績が必要になる。
公開範囲で答えられる問いと、まだ答えられない問い
ZDNSを評価するとき、最初に分けるべきなのは「サービスが存在し、世界から見えているか」と「そのサービスが重大障害後にも必要量を処理できるか」である。前者には、レジストリサービス事業者としての申請、権威DNSの委任、AS38345からの経路広告、複数都市を記したデータセンター添付資料が役立つ。後者には、各拠点に置かれた機器、回線契約、通常時と繁忙時の使用率、切替後の残存能力、復旧に要した時間が必要だ。公開資料は前者を相応に支えるが、後者を数量で閉じるところまでは届かない。
この違いは言葉遊びではない。DNSの応答が近くから返ること、経路収集点に多数のプレフィックスが見えること、受け入れ先の建物に多数のラックがあることは、それぞれ別の観測である。これらを足し合わせても、ZDNSが何台を運用し、どの都市にどれだけ負荷を置き、一つの都市を失った後に何件の問い合わせをさばけるかは算出できない。物理設備の全体値を同社の容量へ置き換えたり、販売上の最大値を実測された余剰能力へ置き換えたりすれば、評価は実態より強く見えてしまう。
本稿の中心的な問いは、ZDNSの世界的に見えるレジストリ機能と権威DNSサービスのうち、どれだけを帰属可能な物理資産、実際に使える切替容量、実施結果のある復旧へ結び付けられるか、である。結論を先取りすれば、論理サービスとネットワーク面の輪郭はかなり読める。一方、ZDNS固有の物理容量と、障害時にも残る余力の輪郭は弱い。二つの証拠評価を一つの総合的な「大容量」という表現に丸めてはならない。
「容量」という一語を四つの異なる問いへ分解する
第一の問いは、物理的に何が実装されているかである。対象になるのは、ZDNS自身に帰属するか、同社が契約上使用できるサーバー、記憶装置、署名装置、ネットワーク接続、電力などである。受け入れ施設に置けるラック総数は、この問いの周辺条件にはなるが、実装済み資産の答えではない。空のラック、他の利用者のラック、将来契約できるかもしれない空間を数えれば、現在の提供能力を水増しすることになる。
第二の問いは、論理サービスがどれほどの処理を行えるかである。署名、登録情報の参照、DNS応答では、処理の性質とボトルネックが違う。同じ機器台数でも、問い合わせの構成、データ更新、署名処理、通信量によって結果は変わる。このため、製品説明に掲げられた最大値には、測定条件と対象機能が必要になる。物理資産を確認できても、処理性能を自動的に導けないし、性能値を見ても資産の所在地と所有関係は分からない。
第三の問いは、障害時に使える余力がどれほど残るかである。これは総能力から平常負荷を引くだけでも求められない。最大の拠点が失われれば、その拠点にあった処理能力も同時に消える。残存拠点へ通信を運ぶ回線、追加負荷を受ける装置、更新を続けるデータ系、監視と運用要員がすべて必要になる。予備機があっても設定されていなければ即時には働かず、計算上の空きがあっても攻撃通信で埋まれば通常問い合わせには使えない。余力とは、特定の障害条件の下で実際に利用できる能力である。
第四の問いは、壊れた状態から正常な状態へ戻せるかである。経路を別拠点へ向けることと、破損データを復元すること、署名鍵を安全に切り替えること、失敗した預託を検査して再作成することは別の作業になる。残存拠点が一時的に応答を続けても、原本の修復に失敗すれば長期的な継続性は確保できない。反対に、優れた復元手順があっても、切替直後の問い合わせを受ける容量がなければ停止は避けられない。
この四つを分けると、公開資料の役割が明瞭になる。施設別紙は物理的な受け入れ環境の一部を語り、経路観測と委任情報は論理サービスの外部可視性を語り、販売資料は処理能力の主張を語り、申請添付資料は復旧手順の設計を語る。どれも無価値ではないが、別の問いの空欄を自動的に埋めない。強い評価には、各資料を正しい欄へ置き、欄と欄の間を日付入りの実測でつなぐことが必要である。
名称の綴りと沿革から断定できる範囲
企業の同定には小さく見えて重要な注意点がある。APNICのAS38345に関するRDAP記録は、保有者名に「Resrarch」という綴りを残している。これに対し、ZDNSのMain RSP申請では訂正された法的名称と、事業上の名称であるZDNSが使われる。ZDNSの連絡先ページも現在の組織を確かめる手掛かりになる。ディレクトリの表記は登録記録を忠実に保存すべきだが、この一文字列の差だけで別会社が存在すると推定する根拠にはならない。
時系列にも空白がある。ZDNSの会社紹介が示す2013年の設立より前からAS38345の登録は存在し、APNICのWhois検索記録には古いKNETの連絡先が残る。ここから言えるのは、ネットワーク登録の時系列と現在の会社説明が単純には重ならないということまでだ。買収、前身組織、資産移転、所有権の連鎖は、公表された事実がなければ補えない。古い連絡先を見つけたことと、法的な承継関係を証明したことは別である。
この留保は、以後の資産評価にも効く。AS番号の登録、会社名、施設利用、設備所有は異なる法的・運用上の関係を表す。名称を同定できても、経路上で観測された機器の所有権までは確定しない。同様に、ZDNSが利用すると説明する施設を特定できても、その建物のラックや発電設備を同社資産として計上することはできない。名称の整合を丁寧に扱うことは、過大な物理帰属を防ぐ最初の段階になる。
審査で認められたサービス種別と、日々の実装は別である
ICANNの2026年評価済みRSP申請一覧では、ZDNSはMain、DNS、DNSSEC、Proxyの各サービス種別と国際化ドメイン名への対応について、申請評価を通過した事業者として記録される。ICANNの2026年RSP制度説明は、この評価が新しいgTLD申請ラウンドにおける制度上の位置付けを持つことを理解するための基準になる。ただし、申請が認められたことは、あらゆる顧客環境の設備、負荷、保守状態を継続的に認証することではない。
サービス面の広さは確かにある。ICANNの基本レジストリ契約が置く制度的な枠組みの下で、第一者資料はレジストリ機能、データエスクロー、DNSSEC、WHOISとRDAP、権威DNSを説明する。ZDNSのTLD基盤ページにはレジストリ向け機能と性能表示があり、クラウドDNSの説明にはGSLB、HTTPDNS、BGPとエニーキャストを含む提供面が示される。さらに、中核機器の製品ページは、利用者側へ配備できる機器系統を別に扱っている。
ここで、少なくとも三つの運用面を混ぜないことが重要だ。第一は、レジストリの共有登録システムやデータ保管、署名などの機能である。第二は、世界へ公開される権威DNSと、その経路制御である。第三は、顧客の施設に置かれ得る配備型機器である。同じ会社の製品群であっても、障害領域、法的管理者、更新手順、必要な復元対象は一致しない。一つの製品ページから得た性能値を、別の運用面の残存能力へ転用してはならない。
したがって、申請評価が与える強い情報は「ZDNSがどの役割を提供対象として説明し、審査を通過したか」である。与えない情報は「特定日の全配備が何台で、どの顧客がどの設備に割り当てられ、最大拠点喪失後にどの性能を保つか」である。制度上の適格性と運用中の全環境に対する連続的な保証を区別すれば、評価済みという言葉を過大に読まずに済む。
8行の所在地一覧は8つの独立障害領域を意味しない
ZDNSのデータセンター添付資料には、所在地または接続先として8行が並ぶ。北京のCSNET、北京の酒仙橋、成都、香港のHKIX、そしてCogentに関係するロサンゼルス、シカゴ、フランクフルト、ニューヨークである。このうち北京、香港、ロサンゼルス、シカゴ、フランクフルト、ニューヨークはエニーキャストに関連付けられ、酒仙橋と成都はユニキャストのサービスに関連付けられている。
この一覧は、世界的な配信面を評価するうえで価値がある。HKIXの公開運用情報は香港で参照される交換点の性格を確かめる材料であり、Cogentのネットワーク地図は複数の海外都市が同一ネットワークへの依存として記載される背景を読む材料になる。少なくとも、ZDNSの説明が北京の単一所在地だけで完結していないことは分かる。
しかし、行数をそのまま独立した物理ノード数へ変換することはできない。資料は、各行に何台のサーバーがあり、どのレジストリ機能を担い、どの回線と電源を共有し、通常時にどれほどの負荷を受けているかを示さない。都市が違えば地理的には離れていても、同じ上流ネットワーク、同じ運用制御、同じ設定配布、同じ鍵やデータ源へ依存する可能性は残る。逆に、一つの行の背後に複数装置があっても、それを公開表から数えることはできない。
「8拠点」という短い表現は、所在地一覧の要約としてなら使える。だが、「8つの独立した処理拠点」「8重の冗長性」「一拠点を失っても7拠点分が残る」という意味にはならない。独立性を判断するには、施設、電力、構内配線、上流回線、経路方針、制御系、データ複製、鍵管理の共有関係が必要だ。添付資料が示すのは依存先の名前とサービス方式の一部であって、一行ごとの故障境界ではない。
732ラックは受け入れ施設の全体値であり、ZDNSの設備量ではない
同じ添付資料には、北京M5第3期に関する認証別紙の値が含まれる。対象は3室の732ラック、能力3,517キロワットの冷却機2基、84立方メートルの冷水槽2基、2,500キロボルトアンペアのディーゼル設備5基である。数字が具体的であるほど、ZDNSの設備規模だと読みたくなる。しかし、これらは受け入れ施設全体の値であり、同社が所有する数量、契約上割り当てられた数量、実装済みの数量、障害時に利用可能な空き数量ではない。
さらに、認証の対象範囲からネットワークと配線が除外されている。冷却、蓄冷、非常用電源の総量が示されても、ZDNSが使うラックまでの給電経路や通信経路、その冗長性を同じ証明から推定することはできない。施設全体に大きな設備があっても、個別利用者への割当、保守中の状態、同時故障の条件、燃料や回線の継続性が分からなければ、当該利用者の可用容量は計算できない。
懐柔についても同じ原則が当てはまる。CNICの機関概要と関連する施設説明からは、およそ2万平方メートル、1,000を超えるキャビネットという規模が示される。だが、これは施設の総体的な属性であり、ZDNSに予約されたキャビネット数ではない。北京M5の732ラックと懐柔の1,000超キャビネットを合算することも、片方を同社の主設備とみなすこともできない。
物理容量として調達台帳へ載せられるのは、少なくともZDNSに帰属または割当可能だと確認でき、現在実装され、必要な回線と電力が接続され、負荷を受けられる部分である。施設紹介の総面積、ラック総数、冷却機総能力は受け入れ環境の特徴を示すが、その条件を満たさない。Uptime Instituteの階層概要も、施設設計や運用上の考え方を理解する参考にはなるものの、個々の利用者に割り当てられたサーバー台数や余力を代わりに証明するものではない。
したがって、732という値は「ZDNSが依存先として挙げる施設について、相応の受け入れ設備を記した別紙がある」という証拠である。「ZDNSは732ラックを持つ」「732ラック分をいつでも使える」「732ラックがDNSを処理している」という証拠ではない。この一線を守ることが、本稿で最も重要な会計上の留保である。
AS38345が示すのは生きた二重スタックの経路面である
調査時点のAS38345には、IPv4の/24が24本、IPv6の/48が12本、経路広告として観測された。RIPEstatのAS概要、広告プレフィックス一覧、経路状態を組み合わせると、二重スタックの経路面が稼働し、広い収集点から見えていることを確認できる。Cloudflare RadarのAS38345経路表示も、別の公開視点からその到達面を読むための資料になる。
この観測は「紙の申請だけで、ネットワーク上に何も見えない」という状態を否定するには有効だ。IPv4とIPv6の双方でまとまった経路が告知され、複数の収集点へ届くなら、少なくとも外部から観測可能なルーティング面がある。論理サービスとネットワークの証拠評価を「中」とする主要な理由の一つはここにある。
ただし、プレフィックスの本数はサーバー台数ではない。広告が見えることは、問い合わせが正常に処理されたこと、期待する遅延を満たしたこと、攻撃時の処理能力が残っていること、都市ごとに物理機器が分散したことを示さない。一つのプレフィックスを多数拠点で告知することも、一つの拠点に集約することも技術的にはあり得るため、経路数から施設数を逆算できない。
経路上の関係も慎重に読む必要がある。RIPEstatのAS近隣情報と経路整合性情報は、外部ネットワークとの接続や広告の見え方を調べる助けになる。だが、隣接ASが見えることは、独立した引込経路、別々の構内配線、特定容量の契約、障害時に予約された帯域を証明しない。ネットワークの可視性は重要だが、物理的な多様性と余剰能力は別途立証しなければならない。
委任情報は権威DNSの共有パターンを映すが、設置場所を明かさない
IANAの委任記録では、「.baidu」の記録、「.icbc」の記録、「.unicom」の記録が、ZDNSを技術連絡先として示し、共通性のある権威DNSの接続先パターンを外部へ見せている。これはZDNSのサービスが実際の委任関係へ現れていることを示す、申請資料とは異なる種類の証拠である。
選んだ権威DNSアドレスの経路起点を調べると、AS38345だけでなくAS4837、AS56048、AS24149からの観測が得られた。個別の手掛かりは、203.99.24.1のネットワーク情報、116.169.54.111の情報、223.72.199.37の情報、2401:8d00:2::1の情報に分かれている。複数の起点が見えることは、権威DNSの公開面が単一のAS番号だけでは説明し切れないことを示す。
それでも、起点ASはサーバーの所有者や契約関係を確定しない。通信事業者のアドレス、顧客向け割当、外部の配信先など、複数の関係が経路として見え得る。別ASから見えた二つのアドレスが、必ず別建物、別電源、別導管、別運用班に置かれるとは限らない。逆に、同じASから見えるアドレスが同じ建物にあるとも限らない。経路起点は論理的な到達経路の証拠であって、所有権と物理独立性の証書ではない。
委任情報から顧客分離の度合いも分からない。複数のトップレベルドメインに共通する接続先パターンがあるとしても、処理装置、設定、署名鍵、データ複製、障害領域をどこまで共有するかは公開委任記録に現れない。したがって、委任の存在はサービス実在性を強めるが、一顧客の障害が他顧客へ及ぶ範囲や、顧客別の予約容量までは示さない。
RPKIの二標本を全体評価へ拡張してはならない
経路起点の認証状態については、二つの標本が対照的だった。150.242.156.0/24のRPKI検証結果は有効を返し、1.8.1.0/24の検証結果は不明を返した。この結果は、調査時点に選んだ二つのプレフィックスについて述べるには十分だが、AS38345の全広告を恒久的に格付けするには足りない。
「不明」は、その経路が乗っ取られているという意味ではない。有効な経路起点認可と照合できなかったという観測を、直ちに悪意ある起点や誤配信の証拠へ読み替えるべきではない。また、一方の標本が有効だからといって、全プレフィックスが同じ状態だとも言えない。認証情報と経路広告は時間とともに変わり得るため、重要な契約判断では対象集合と観測時刻をそろえた全体確認が必要になる。
RPKIは経路起点の正当性を扱う一層であり、DNS応答の内容、署名鍵の保全、データベースの完全性、拠点の電源状態を扱わない。経路が有効でも、応答装置が不健全な設定を配信する可能性はある。逆に、認証状態が不明でも、直ちにDNSが停止しているとは限らない。経路の安全性、サービスの正常性、物理設備の可用性をそれぞれの証拠で評価する必要がある。
この二標本は、公開観測の限界を示す好例でもある。数値や状態表示は明快に見えるが、その対象範囲を越えて一般化すると結論が変質する。本稿では、有効一件、不明一件という事実だけを保持し、「全面的に保護済み」「危険な経路がある」といった広い宣言には使わない。
販売上の性能値から拠点別の余剰能力は計算できない
ZDNSは、毎秒3,000件の署名処理、1万5,000組の鍵、毎秒1万6,000件から2万7,000件のWHOISまたはRDAP問い合わせ、1日20億件のDNS名前解決、99.999パーセントを上回る可用性を掲げる。これらは提供対象の規模感を知るには有用であり、小規模な試験用途だけを想定した説明ではないことが分かる。しかし、公開表示には、測定日、負荷の構成、要求と応答の定義、使用機器、同時実行条件、観測期間、拠点ごとの割当が伴っていない。
特に、「1日20億件」を最大処理能力と解釈してはならない。それが実績量、設計目標、処理可能量のどれを指すかが明示されなければ、毎秒の持続能力や繁忙時の余力へ変換できない。日次の合計が同じでも、問い合わせが均等に来る場合と短時間に集中する場合では必要設備が異なる。さらに、正常な問い合わせと攻撃通信、キャッシュされやすい名前と更新の多い名前、IPv4とIPv6など、負荷の中身によってボトルネックも変わる。
99.999パーセント超という表示にも同様の問題がある。何を利用可能と判定し、どの地点から測り、計画停止をどう扱い、どの期間を分母にしたかがなければ、買い手が自らの目標と比較できない。世界全体の平均が高くても、特定地域、特定顧客、特定機能で同じ結果になるとは限らない。レジストリ書込み、RDAP、権威DNS応答、DNSSEC署名は別の依存関係を持つため、一つの可用性値で全機能を代表させることもできない。
そして最も大きな欠落は、通常時の使用量と、最大拠点を失った後の残存能力である。総処理能力が大きくても、平常時にほぼ使い切っていれば切替先の余地は小さい。反対に、表示上の最大値が控えめでも、拠点ごとに十分な未使用能力があり、実際の切替試験を通っていれば耐障害性は高い可能性がある。販売値は能力候補を示すが、使える冗長性を証明しない。
「少なくとも二つの独立施設」という申告に数量の裏付けが足りない
Main RSP申請は、Tier IIIまたは同等水準の独立したデータセンターを少なくとも二つ用いること、バックアップ、監視、復旧管理、24時間のオンコール対応を説明している。この申告は、単一施設だけに全機能を置く設計ではないという重要な情報を与える。手順面の意図と統制も読み取れる。
一方、「独立」がどの層まで及ぶかは、公開記録だけでは数量化できない。別の建物であっても、同じ通信経路、同じ電力供給上の弱点、同じ管理面、同じデータ不整合、同じ鍵管理の誤りに影響されることがある。施設等級または同等性は、ZDNSが各施設で何台の装置を持ち、どのポート容量を契約し、どれだけの攻撃緩和余力を確保したかを示さない。
少なくとも二施設という条件から、負荷が半分ずつだと仮定することもできない。一方が大半を処理し、他方が限定機能だけを担う構成もあれば、多数の配信点が少数の中枢機能に依存する構成もあり得る。公開資料には、最大拠点が総負荷に占める割合、停止後に残る問い合わせ処理量、データ更新を継続できる量、攻撃を受けながら切り替える場合の余地がない。
したがって、この申告は設計上の冗長化方針を支えるが、実装済みの予備機、空きポート、予備回線、予備電力、残存処理能力の台帳にはならない。必要なのは、拠点名と機能を対応させた表、実装済みと予備の機器数量、平常時と繁忙時の負荷、最大拠点停止後の測定結果である。それがなければ、「二施設」は構成の入口であって、可用容量の答えではない。
エニーキャストは切替の手段であって、復旧そのものではない
エニーキャストでは、複数地点が同じ宛先を広告し、経路選択によって利用者の問い合わせをいずれかの地点へ導ける。RFC 4786のエニーキャスト運用指針は、その運用上の性質と注意点を理解する基礎になる。障害地点が健全に経路を撤回し、残る地点に十分な処理能力があれば、通信を別地点へ寄せる有力な手段になる。
ただし、障害地点が不健全なまま広告を続ければ、問い合わせはそこへ引き込まれ続ける可能性がある。経路の撤回が正しくても、残る地点が急増した負荷を受け切れなければ、切替は到達性を保っても性能を保てない。また、全地点へ誤った設定が同時配布された場合、破損したデータが複製された場合、署名状態を失った場合、経路だけを変えても正常な応答は戻らない。
RFC 2182のセカンダリDNSに関する指針が強調する分散の考え方も、名前だけ違うサーバーを並べることと、本当に別の故障条件を持たせることの違いを考える助けになる。地理、上流接続、管理、データ源が過度に共通なら、台数や都市名が増えても同時障害の範囲は狭まらない。逆に、適切に分離され、更新と監視が成立していれば、少数の拠点でも有効な冗長性を持ち得る。
よって、エニーキャストの採用を可用性の完成証明にしてはならない。確認すべき実績は、障害を検知してから経路が撤回されるまでの挙動、主要な観測地点での収束、残存拠点の応答率と遅延、復帰時の経路安定性である。さらに、健全性判定が誤った場合や、一部の地点だけに古いデータが残った場合も試す必要がある。方式名ではなく、失敗時の実測が耐障害性を決める。
DNSSEC、エスクロー、復旧手順は設計されているが、直近成績は見えない
ZDNSのKSK管理添付資料は、年次および緊急時の鍵署名鍵切替、ハードウェアセキュリティ装置と侵入検知による監視、通常系とは別の連絡、机上演習、事後検討の設計を記す。鍵事故を単なるサーバー交換として扱わず、連絡と判断を含む手順として考えている点は、復旧統制の証拠になる。
Main申請は、レジストリの完全なエスクロー預託を毎日行い、失敗した預託を再試行すると説明する。定期的な外部保全を前提にしていることは重要だ。しかし、預託が毎日走ることと、その日の全データが欠落なく含まれることは同じではない。暗号化された預託物を必要時に復号できること、別環境へ読み込み、整合性を確かめ、所定時間内にサービスを再開できることも別の証明を要する。
公開資料から不足しているのは、直近に実施した結果である。緊急鍵切替について、いつ、どの条件で、どれほどの時間を要し、委任側との調整を含めて何が成功し、何を改善したかは示されていない。エスクローについても、抽出、移送、復号、検査、復元の各段階を通した結果や、実際に達成した復旧時点目標を確認できない。机上演習は意思決定を鍛えるが、実データと実装置を用いた復元とは異なる。
また、全顧客が同じ法的事業者、同じ鍵保管先、同じ預託関係に置かれると推定してはならない。提供するサービス種別が複数あり、顧客側へ配備する機器もある以上、責任分界は契約と構成によって変わり得る。買い手は、自らが利用する機能について、誰が鍵を保持し、誰が預託し、どの環境へ復元し、誰が復旧宣言を行うかを個別に確認する必要がある。
設計文書があることは「弱い」の一言で退けるべきではない。監視、別経路の連絡、演習、事後検討まで記述されている点は、復旧を考慮した運用の証拠である。ただし、その証拠の種類は手順設計であり、実行成績ではない。本稿が求める「実証済みの復旧」へ結び付ける最後の一歩は、日付、対象範囲、開始状態、達成時間、残った問題を伴う結果記録である。
近いDNS応答は、データと鍵の所在地を証明しない
権威DNSには世界へ公開されるデータ面がある。エニーキャストや複数ネットワークによって、利用者から比較的近い経路で応答を受ける場合もある。しかし、応答地点の近さから、レジストリの登録データ、問い合わせ記録、バックアップ、署名鍵、監視、管理機能まで同じ国や地域にあるとは判断できない。
DNS応答に必要な情報が配信点へ複製されていても、原本の更新、署名、設定配布、監査記録、復元用データは別の場所に置かれ得る。逆に、登録データが特定地域に保管されていても、公開応答は世界の複数地点から返り得る。公開データ面の地理と、保存・制御面の地理を一枚の地図へ重ねるには、機能ごとのデータ流通と保管先が必要になる。
この区別はデータ主権の評価で特に重要だ。「自国から低遅延で名前解決できた」という試験は、利用体験と経路の局所性を示す。一方、「自国の法域内だけで登録データとログが保存される」「鍵が国外へ出ない」「管理操作が指定地域で完結する」という要件は、別の契約証拠と技術証拠を必要とする。応答元アドレスだけでは、バックアップや管理面の所在は追えない。
買い手が確認すべき地理情報は、都市名の一覧だけではない。レジストリ書込み、権威DNS配信、ログ収集、鍵生成と保管、バックアップ、監視、運用者アクセスの各機能について、保存先、複製先、通常の管理元、緊急時の移転先を対応させる必要がある。そのうえで、委託先と法的管理者を重ねれば、ネットワーク上の「近さ」と、法的・運用上の「所在地」を別々に評価できる。
ZDNSの公開資料は、世界的な公開DNS面を支える。一方で、全サービス層のデータ所在地を閉じた形で示さない。したがって、グローバルな応答能力の証拠を、そのまま地域内保管または地域内統制の証明として用いることはできない。
影響を受けるのは一種類の「ユーザー」ではない
ZDNSに依存し得る主体には、レジストリ運営者、レジストラ、登録者、再帰DNS運用者、企業DNSの顧客、その先で名前解決を使う人々がいる。各層が必要とする機能と、障害時に受ける影響は異なる。権威DNSの応答停止は既存名の到達性に関わり、レジストリ機能の停止は登録や更新に関わり、RDAPの停止は登録情報の参照に関わる。DNSSECの障害は、単なる遅延ではなく検証失敗として現れる可能性がある。
このため、顧客数や管理ドメイン数を「影響を受ける人数」へ変換することはできない。一つのドメインが多数の人に使われる場合も、ほとんど使われない場合もある。重要な公共・企業サービスと、限定的な用途を同じ一件として数えることもできない。再帰DNSのキャッシュによって短時間は影響が緩和される場合があっても、名前や設定ごとの条件が分からなければ持続時間を一般化できない。
耐障害性の評価は、利用者層ごとに重要な操作を定義すると明確になる。レジストリ運営者なら、新規登録、更新、移管、データ預託、署名が継続するか。レジストラなら、必要な書込みと参照が成立するか。再帰DNS運用者と末端利用者なら、権威応答が正しく返り、検証可能か。企業DNS顧客なら、自社の設定変更と配信がどの設備に依存するか。全層を一つの稼働率へ畳むと、重大な一機能の失敗が平均値に隠れる。
公表値がなくても、影響を誇張しないことはできる。「多数の利用者が必ず止まる」と断定する代わりに、どのサービス層が、どの依存関係を通じて、どの操作を失う可能性があるかを示す。これは慎重さだけでなく、復旧優先順位を決めるためにも有用である。権威DNS、登録処理、署名、参照サービスでは、必要な証拠と復旧試験が異なるからだ。
買い手が求めるべき九つの運用実績
第一に必要なのは、拠点と機能の対応表である。8行それぞれについて、権威DNS、レジストリ書込み、RDAP、署名、監視、バックアップのどれを担うかを明らかにする。単に「利用中」と記すのではなく、平常時に処理する機能と、障害時に引き受ける機能を分ける必要がある。
第二は、実装済み機器と直ちに使える予備機器の数量である。施設全体のラック数ではなく、ZDNSに帰属または契約上割り当てられ、電力、ネットワーク、設定がそろった数量を示す。倉庫にある未設定機器や、施設に空きがあるだけの状態は、即時の切替容量とは別に扱う。
第三は、通常時と繁忙時の負荷である。問い合わせ数だけでなく、処理能力に対する割合、機能別のボトルネック、攻撃緩和を含む回線使用、主要拠点の分担率をそろえる。販売上の最大値ではなく、同じ測定条件で得た実運用値が必要だ。
第四は、経路撤回と収束の実績である。意図的に一地点を停止し、健全性判定から広告停止までの挙動、複数の観測地点で到達先が変わる様子、応答欠落、遅延、復帰時の安定を記録する。不健全な地点が広告を続ける条件も含めなければ、きれいな停止だけを試した結果になる。
第五は、最大拠点喪失試験である。最大の処理割合を持つ地点を失わせ、残る地点が通常問い合わせと高負荷の双方をどこまで処理できたかを測る。単に「切り替わった」ではなく、失敗率、遅延、残存余力、制限した機能、必要だった手作業を示すべきである。
第六は、データベース復元である。バックアップまたはエスクローの抽出物から、隔離した環境へデータを読み込み、完全性を確認し、サービスが利用可能になるまでを通して実施する。預託が成功した時刻だけでなく、復元後にどの時点までのデータが戻ったかを記録する。
第七は、DNSSEC緊急対応である。鍵の破損、漏えい疑い、装置喪失など明確な想定を置き、別経路での連絡、承認、緊急切替、委任側との調整、検証回復までを測る。年次手順の存在ではなく、最後に実行した日と結果が必要になる。
第八は、エスクローの内容検査である。毎日の預託回数だけでなく、欠落、復号可能性、形式の整合、別環境への読込みを確認する。再試行が行われる設計なら、失敗の検知から再預託完了までに要した時間も、実際の保護間隔を知るうえで重要だ。
第九は、達成した復旧時間目標と復旧時点目標である。目標値の宣言だけでなく、各試験の開始条件、復旧と判定した条件、実測時間、戻せたデータ時点、未解決事項を残す。機能ごと、最大拠点喪失時、データ破損時で結果を分ければ、買い手は自らの許容停止時間と比較できる。
これら九項目を同じ日付と対象範囲でそろえれば、ネットワークの広がり、物理資産、余力、復旧を別々に検証できる。逆に、所在地一覧、施設総数、販売性能、手順文書だけでは、どれか一つを代替できても、全体を閉じることはできない。現時点で確認した公開資料には、九項目を一式で満たす日付入り結果はない。
証拠を更新するときも対象と時点を固定する
公開資料は一度読んで終わりではない。経路広告、RPKIの状態、委任情報、申請一覧、製品表示は、それぞれ異なる理由と頻度で変わり得る。将来の観測が現在と違っても、直ちに過去の記録が誤りだったとは限らない。反対に、過去に確認できた状態を現在も続くものとして扱うこともできない。評価には、何を、いつ、どの対象集合で確認したかを残す必要がある。
経路については、AS全体、選んだプレフィックス、選んだ権威アドレスを区別する。あるプレフィックスの起点認証が有効でも、別のプレフィックスへ広げない。ある権威アドレスが一つのASから見えても、同じ名前サーバー群すべての物理配置へ広げない。観測点による見え方の違いもあるため、到達したという結果と、世界の全利用者が同じ経路を使うという主張を分ける。
所在地資料が更新された場合も、行の追加や削除だけを容量増減へ読み替えない。新しい都市名が加わっても、既存装置の移設、接続先の表記変更、配信点の追加など複数の意味があり得る。容量の変化を述べるには、機器数量、割当、負荷、回線が同じ基準で比較できなければならない。逆に、行数が変わらなくても、内部の装置更新や負荷配分変更によって耐障害性は変わり得る。
販売上の数値を比較するときは、値そのものより定義の継続性が重要になる。問い合わせの種類、測定期間、成功判定、負荷条件が変われば、数字の増減を設備増強や性能低下と断定できない。可用性も、対象機能、測定地点、除外時間が同じで初めて時系列比較に耐える。新しい大きな数字が出たことだけでは、最大拠点喪失時の余力が増えたとは言えない。
復旧証拠では、手順の改訂日と、実施結果の日を別に残す。文書が新しくても、訓練や復元が旧版の条件で行われていれば、現構成での有効性は未確認である。実施記録には、対象機能、開始時の障害、参加する役割、用いたデータ、終了判定、達成時間、改善事項が必要になる。次回の試験で改善事項が閉じたかまで追えば、単発の成功報告ではなく、復旧能力の維持を評価できる。
こうした時点管理は、ZDNSだけに厳しい特別条件ではない。世界へ公開されるDNSとレジストリは、論理面が外から観測しやすい一方、物理割当と内部余力が外から見えにくい。だからこそ、観測可能な事実を過度に拡張せず、非公開部分には契約上の証拠を求める必要がある。現在の評価が将来の保証ではないことを明示しながら、将来の更新でも同じ物差しを使うことが、公平で再現可能な判断につながる。
証拠評価は二つに分けて結論づける
ネットワークと論理サービスの証拠評価は「中」である。根拠は、2026年のRSP申請評価で複数のサービス種別が確認できること、第一者資料がレジストリ、権威DNS、DNSSEC、RDAPなどを説明すること、IANA委任にZDNSの役割と権威接続先の共通パターンが現れること、AS38345にIPv4とIPv6の経路広告が観測されること、複数都市の依存先が資料化されていることである。異なる種類の公開記録が、サービスの存在と外部可視性について相互に輪郭を与えている。
ZDNSに帰属可能な物理容量と、実際に使える切替余力の証拠評価は「弱」である。732ラック、冷却機、蓄冷槽、ディーゼル設備は受け入れ施設の総量で、同社への割当がない。懐柔の面積と1,000超キャビネットも施設属性にとどまる。8行の所在地は機器数と負荷を示さず、販売上の性能値には測定条件と拠点別内訳がなく、最大拠点喪失後の結果もない。設計上の冗長性を示す記述はあっても、残存能力を数える台帳がない。
復旧については、年次・緊急の鍵切替、監視、別経路連絡、机上演習、事後検討、毎日の完全預託と再試行という手順設計が確認できる。これは無証拠ではない。しかし、直近の実行日、復号と復元の成否、最大拠点停止時の切替、達成した復旧時間と復旧時点が公開されていないため、「実証済み」とは評価できない。エニーキャストも、健全な経路撤回と十分な残存能力があるときに働く手段であり、その条件を自動的に保証しない。
最終的に、二つの評価を一つへ平均してはならない。世界から見える経路とサービスの証拠が「中」であることは、物理容量と余力の証拠を引き上げない。物理容量の証拠が「弱」であることも、公開経路や委任の実在を消さない。ZDNSを採用する買い手は、前者をサービス候補としての信頼材料にしつつ、後者については拠点・機能表、割当資産、負荷、最大拠点喪失、復元、緊急署名、エスクロー検査の実績を契約前に求めるべきである。
732ラックという数字の正しい位置付けも、ここで明確になる。それは、ZDNSが名前を挙げる受け入れ先に大規模な施設設備があることを示す依存先の証拠である。ZDNSのラック数、処理能力、予約済み余力ではない。大きな数字を同社の容量へ算入しないことによって初めて、公開資料が本当に支える強さと、なお開示を要する弱さを同時に保てる。
検索向け情報
検索タイトル：ZDNSの8拠点と732ラックを検証する――DNSクラウドの物理容量と復旧証拠
メタ説明：ZDNSのレジストリ機能、権威DNS、AS38345、8行の所在地、北京施設の732ラック、販売上の性能値、エニーキャスト、DNSSECとエスクローを検討し、ネットワーク上の可視性と同社に帰属する物理容量・切替余力を分けて評価する。