要約
- 無応答の116,050,253テストに対し、APNIC Labsの権威サーバーは9,685,775,212件を観測した。公開値から計算すると1テスト当たり83.46件で、正応答は3.43、NODATAは3.93、NXDOMAINは4.40、REFUSEDは11.47、SERVFAILは51.73だった。
- この差は、実験内で応答状態と負荷が結びついていることを示す。一方、端末、stub、フォワーダー、再帰エンジン、リゾルバーファームのどこが反復を生成したかは特定しない。
- 本文と集計表には二つの平均値の不一致がある。件数から算術は検証できるが、執筆者の意図までは決められない。運用判断には、分母、式、構成、観測できなかった因果層を残す必要がある。
最後の観測点から上流の意思決定は見えない
9月4日の報告で最も大きい値は9,685,775,212である。権威サーバーが何も返さない条件で到着したクエリの総数だ。表のテスト数116,050,253で割ると83.4619になる。
数字は精密でも、主体は精密にならない。
オンライン広告内のスクリプトが、端末に固有のランダム名を引かせた。質問はローカルのstubから、設定された複数の再帰サービスへ向かった可能性がある。その先にフォワーダー、フロントエンドの分配器、複数の再帰エンジンがあり、サーバーアドレスやトランスポートの選択もある。各層が仕事を作り、同一要求を束ね、再送し、別経路へ振り分け得る。
APNICのログは、その連鎖の末端で到着分を数える。各パケットに上流判断の履歴が付くわけではない。したがって「一つのリゾルバーが83回聞いた」とは言えない。「83回の再送」という表現も広すぎる。現代の端末は同じ名前についてA、AAAA、HTTPSを別々に問い合わせるからだ。
公開された単位は固有のテスト名であり、利用者の一操作でも、アプリケーションの一解決でも、stubや再帰の一トランザクションでもない。得られたのは権威境界の負荷台帳であって、再試行を命じた層の台帳ではない。
六つの状態は六つの負荷を作った
ランダム名のため、同じ名前の既存キャッシュは使えない。ゾーンはDNSSEC署名なし。一つのデュアルスタック権威サーバーがUDPとTCPを受け、DoTとDoHは提供しない。応答は短く、切り詰めもない。広告が動いてから24時間以内の到着が集計された。
公表された総数を同じ式で計算すると、次のようになる。
| 権威側の状態 | テスト | 観測クエリ | 1テスト当たり | 正応答比 |
|---|---|---|---|---|
正のA/AAAA応答 |
254,894,985 | 875,316,423 | 3.43 | 1.00倍 |
NOERROR/NODATA |
115,571,398 | 454,213,932 | 3.93 | 1.14倍 |
NXDOMAIN |
115,750,503 | 509,410,787 | 4.40 | 1.28倍 |
REFUSED |
115,415,259 | 1,324,355,211 | 11.47 | 3.34倍 |
SERVFAIL |
138,643,924 | 7,171,673,166 | 51.73 | 15.06倍 |
| 無応答 | 116,050,253 | 9,685,775,212 | 83.46 | 24.30倍 |
単純な肯定対否定ではない。正応答と、意味の確定した二種類の否定はおおむね四件に近い。REFUSEDは明確に増え、SERVFAILと無応答は別の帯に入る。
意味との整合性はある。NXDOMAINは名前が存在しないと答える。NODATAは名前はあるが指定型がないと答える。REFUSEDは方針上の拒否を示す。SERVFAILは処理できなかったことだけを示し、別サーバー、別アドレス、別トランスポート、後刻の成功余地を残す。無応答では、タイマーが次の行動を決める。
しかし、行動を誘発し得る意味と、行動した実装の特定は別である。表には製品別、設定別、キュー別、要求結合別の内訳がない。平均の背後の分布もない。51.73や83.46は、この実験で得られた値であり、RCODEごとの普遍定数ではない。
基準件数は最初から一ではない
NXDOMAINの試験では、端末の48%がAとAAAAの双方を、51%がAだけを、1%がAAAAだけを問い合わせた。さらに39%がHTTPSを生成した。この構成で各型を一度だけ尋ねるなら、APNICの推計は2億1800万件になる。
実測は509,410,787件だった。差の291,919,927件が反復と分類された。115,750,503テストのうち67,316,541は、使用した各型について一件以下で完了した。残る48,433,962テストに反復が集まり、その部分の平均は6.03件である。
この基準がなければ、三つの正当な型の問い合わせを三回の再試行と誤認する。逆に最終成否だけを見れば、約2億9200万件の追加仕事が消える。
標本範囲も分母に含めるべきだ。端末はGoogle Adsが到達する地域から集められ、報告はロシアを大きな例外として挙げる。広い観測ではあるが、全インターネット利用者の無作為標本ではない。一台のデュアルスタック機は統制された測定器であり、複数NSや複数事業者による通常の権威構成そのものではない。DNSSEC、暗号化、切り詰めを外したことは変数を減らすが、それらを加えた場合の結果を確定しない。
本文と表のずれは消さずに計算する
SERVFAILの本文は、テスト当たり51.29件、反復条件で51.59件と記す。しかし7,171,673,166を138,643,924で割ると51.7273で、表の51.73と一致する。反復のない3,702,576テストを引いた134,941,348を分母にし、6,920,490,780を割ると51.2852となり、表の51.29に一致する。
無応答の本文では、テスト数が11,6050,253、平均が82.6と印字されている。表は116,050,253と83.46である。9,685,775,212を表のテスト数で割れば83.4619になる。反復の平均83.38も、9,466,474,491を113,531,062で割れば再現できる。
本文の数字を無批判に採るべきではない。同時に、このずれだけで実験全体を退けるべきでもない。元の件数と式があれば、転記やラベルの誤りを測定の誤りから分離できる。どの表現を意図したかは執筆者だけが答えられるが、公表値から何が導けるかは読者も確認できる。
平均には、分子、分母、除外、式、版を付けるべきである。完成した数字という見た目に、根拠以上の権限を与えないためだ。
2019年の仮説は2026年の帰属先ではない
APNICの2019年調査はNXDOMAIN反復の時間間隔を詳しく見た。同一に見えるリゾルバーアドレスからの反復や、共通プレフィックス内の複数アドレスからの集中を観測し、Happy Eyeballs、パケット損失、短いタイマー、フォワーダーの集中、リゾルバーファームを検討した。IPv4の/24、IPv6の/48によるまとめ方は近似とされた。
どの仕組みも候補にはなるが、2026年集計の空欄を埋める確定情報ではない。一つの可視アドレスが複数エンジンを隠し、複数アドレスが一サービスに属することがある。端末が別々の再帰アドレスへ送っても、同じ後段に集まるかもしれない。先の処理中に重複要求が別キューへ入る場合もある。質問と回答のどちらが失われたかも外側からは分からない。
2026年の報告自身が、再帰実装の問題か、前段分配と後段エンジンの複雑な構造か、と問いを残している。報道側がその疑問符を削ってはならない。
Microsoftの公式資料は一つの具体例を示す。Windowsクライアントは無応答時にタイマーと設定済みサーバー数に応じて問い合わせを広げ、Name Errorを得れば止まる。だがAPNICは標本がWindowsであるとも、その時系列に従ったとも立証していない。仕様例は可能性を示すだけで、別実験の未観測欄を埋めない。
RFCの抑制規則も遠隔帰属はしない
RFC 9520は、同じ質問を同じサーバーアドレスへ同じトランスポートで送る場合、初回後の再試行を二回までに制限する。解決失敗は少なくとも一秒、最長五分キャッシュし、一致する新要求がその間に上流仕事を発生させないよう求める。
故障ストームを抑える規則としては明確である。だが権威サーバーに、到着した各パケットを一つの規範判断へ対応させる能力は与えない。別アドレスや別トランスポートを試す余地があり、複数クライアントを一つに束ねる場合も、一つの動作が複数システムへ広がる場合もある。
RFC 2308はNXDOMAINとNODATAの負キャッシュを定め、従来のサーバー障害キャッシュにも境界を置く。RFC 8914のExtended DNS Errorは診断を詳しくできるが、RCODEの処理を変えてはならない。説明可能性は高まっても、観測していない原因層が現れるわけではない。
負荷を減らすために偽のNXDOMAINやNODATAを返すことは許されない。応答の真偽を流量調整に従属させれば、名前の証拠を壊す。タイマー、経路選択、要求結合、失敗キャッシュを所有する層が、利用者の成功、遅延、回復とともに自らの変更を検証すべきである。
次の測定が持つべき最小記録
開始と終了、誘発経路、地理的な欠落、測定単位をまず明示する。使用予定の型ごとの基準を示してから、余剰を反復と呼ぶ。応答のワイヤー形式、サーバー数、アドレス族、anycast、対応・観測トランスポート、DNSSEC、サイズ、切り詰めも残す。
平均には総数、式、丸め、分布を添える。観測していない層は空欄のままにする。stub、フォワーダー、再帰エンジンを別々に計測していないなら、それぞれの寄与は不明である。
管理下の経路なら、受信クライアント要求、結合された群、再帰トランザクション、同一アドレス・トランスポートへの再試行、代替経路の試行を分けて数えられる。プライバシーを守った有界な識別子で十分だ。その連結証拠が得られなければ、結論は権威境界で止める。
APNICは費用差を無視できなくした。次に必要なのは「ストーム」をさらに強く呼ぶことではなく、どの層がどの再試行権限を使ったかを示せる観測である。
出典
- APNIC Blog — What part of ‘No!’ is so hard for the DNS understand?
- APNIC Blog — No!(2019年測定)
- Microsoft Learn — DNS client resolution timeouts
- RFC 1035 — Domain names: implementation and specification
- RFC 2308 — Negative Caching of DNS Queries
- RFC 8914 — Extended DNS Errors
- RFC 9520 — Negative Caching of DNS Resolution Failures
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
ストラテジックサークル限定
ストラテジックサークル
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
ストラテジックサークルに参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加





