要約

  • APNIC の表1では、権威側が受けた問い合わせは SERVFAIL で1テスト平均51.73件、無応答で83.46件だった。NXDOMAIN は4.40件、NOERROR/NODATA は3.93件、正常応答は3.43件である。
  • 観測点は実験用の権威サービスであり、stub、フォワーダー、再帰サービスの前段・後段、代替サーバー、通信損失を一続きに計装したものではない。発生源は原著者自身が今後の課題としている。
  • RFC 9520 は解決失敗のキャッシュと再試行の上限を求める。ただし、別アドレスや別トランスポートへの切替えは残る。必要なのは総 QPS ではなく、層ごとの予算と追跡可能な台帳だ。

DNS の「分からない」は行動命令になる

存在しない名前への NXDOMAIN は、そこで探索を終えられる情報である。名前はあるが対象型がない NOERROR/NODATA も、問いに対する確定的な否定だ。REFUSED は方針上の拒否であり、SERVFAIL は現在答えを作れないという告白である。何も返らなければ、判断するのは応答ではなくタイマーになる。

Geoff Huston が9月4日に公開した APNIC Blog の分析は、この意味の差を受信パケット数に置き換えた。オンライン広告内のスクリプトに、実験用ゾーン配下のランダムな名前を解決させ、APNIC Labs の権威基盤へ到着した問い合わせを数えた。

表1の勾配は明瞭だ。正常応答は1テスト平均3.43件、NOERROR/NODATA は3.93件、NXDOMAIN は4.40件だった。REFUSED は11.47件へ上がり、SERVFAIL は51.73件、無応答は83.46件になった。

一つのブラウザー動作が一つの DNS パケットとは限らない。A と AAAA、さらに HTTPS が並行して走る。stub が再送し、家庭内フォワーダーが別の再試行を持ち、再帰サービスの入口が別のエンジンに割り当て、エンジンが別の権威アドレスやトランスポートを選べる。局所的に妥当な動作が、全体では大きな増幅になる。

数表を採る。誤植がなかったことにはしない

原文の本文と表には二つの不一致がある。SERVFAIL の段落は平均問い合わせ数を51.29とするが、表1は51.73で、51.29は平均反復数の欄にある。無応答の段落はテスト数を 11,6050,253、平均を82.6と記す一方、表は116,050,253と83.46である。本稿は集計台帳である表の値を使い、不一致も明記する。

SERVFAIL では138,643,924テストに対して7,171,673,166件が届き、そのうち6,920,490,780件が反復だった。使用した各型につき1件だけで終わったテストは3,702,576にすぎない。無応答では9,685,775,212件が届き、9,466,474,491件が反復に分類された。

この規模は現象の存在を強くするが、原因の名札にはならない。権威ログが見るのは、多くの場合、再帰システムから来たパケットである。それだけでは、ブラウザーの stub、端末近くのフォワーダー、再帰のフロントエンド、バックエンド、パケット損失、別のクライアント事象を区別できない。

原稿も「再帰実装なのか、フロントエンドとバックエンドから成る複雑な DNS システムなのか」と問い、別の研究に持ち越した。したがって51.73は SERVFAIL の普遍定数でも、特定製品への判決でも、世界全体の費用推計でもない。

基準値の中にも正当な複数問い合わせがある

NXDOMAIN 実験は2026年8月5日から11日まで、Google Ads で集めた115,750,503端末を対象にした。原文は地理・プラットフォームの広がりを述べつつ、主要な例外としてロシアを挙げる。

48%の端末は A と AAAA の両方、51%は A のみ、1%は AAAA のみを問い合わせた。39%は HTTPS も生成した。観測された各型を一度ずつ問い合わせた場合の推計は約2億1800万件だが、実際は509,410,787件だった。差分291,919,927件が反復である。57%の端末は各型1件以内で完了し、反復した群では平均6.03件の反復があった。

名前はランダムなので、そのテストと同じ名前の応答は事前キャッシュにない。ゾーンは DNSSEC 署名されておらず、RFC 8198 の NSEC/NSEC3 証明による積極的な否定応答合成は使えない。権威サービスは UDP と TCP を受け、DoT/DoH は提供せず、短い非切断応答を返した。広告表示後24時間に届いたパケットが対象である。

これらは再現条件であると同時に限界でもある。権威側に DoT/DoH がないことから、端末と再帰の間の方式は推定できない。また NOERROR/NODATA が3.93で NXDOMAIN の4.40より小さくても、交通量だけで意味を入れ替えてはならない。RFC 2308 は両者の否定キャッシュを定め、RFC 8020 は NXDOMAIN を名前以下の探索打切りに使えるようにする。正しい答えが先である。

RFC 9520 の上限は「同じ宛先、同じ方式」

RFC 9520 は、SERVFAIL、到達不能、DNSSEC 検証失敗などの解決失敗をキャッシュすることを必須にした。初期保持は少なくとも1秒、最大5分を推奨し、設定可能な最小値とバックオフを求める。同一サーバーアドレスかつ同一トランスポートへの再試行は、最初の問い合わせ後2回までとする。

背景には、Dyn で通常の10倍を超えた retry storm、ルート KSK ロールオーバー時の80倍の DNSKEY、2021年の実験で約50 qps が SERVFAIL により60,000 qpsへ増えた例、Facebook 障害中に .COM/.NET が7,000から900,000 qpsへ上昇した例がある。

一方、別のサーバー、アドレス、トランスポートへの試行は禁じられていない。クライアント側から来る別の反復もこの上限の外だ。未完了の同一質問をまとめる仕組みがなければ、各ループが上限を守っても全体は膨らむ。

RFC 8914 の Extended DNS Error は SERVFAIL の背景を伝えられるが、診断情報であり DNS 処理を変更してはならない。原因説明は有用でも、失敗を確定的な不存在に変えない。

APNIC 掲載と APNIC の意思決定は別である

記事は Geoff Huston 個人の署名で、著者の見解は必ずしも APNIC の見解ではないとの注記がある。APNIC は媒体を、APNIC Labs は観測基盤を提供した。この出所は重要だが、分析をレジストリ方針に変えるものではない。

再現実験、時間分布の確認、RFC 9520 実装の点検には十分な根拠である。特定運用者の非準拠や、負荷削減のための誤った応答コード選択を正当化する証拠ではない。