要約

  • APNIC PING は 9 月 3 日、通常のルート問い合わせとローカルなルートゾーンの維持通信を比較した 2026 年 1 月の実験を紹介した。
  • 4 日間の平均は、IXFR を使う BIND がリゾルバー 1 台あたり日量 4.35 MB、DNS 版 Unbound が 3.93 MB、HTTPS でほぼ 1 日 1 回更新する Knot Resolver が 2.65 MB だった。
  • HTTPS 版 Unbound の 105.12 MB は、2.19 MB の全ゾーンを 30 分ごとに取得した結果である。報告書は確認済みの不具合として扱っており、HTTPS 固有の費用ではない。

実験環境では、毎日 12 時 06 分ごろに全ゾーンを取得するリゾルバーがあった。二つはシリアル番号の変化を待って差分を受け取った。もう一つは変化の有無にかかわらず、30 分ごとに全ファイルを取得した。

どれも「ルートをローカルで提供する」と呼べる。それでも通信量は同じではなかった。

9 月 3 日の APNIC PINGは、George Michaelson が研究者 Ilyas Rahimi と NLnet Labs の Willem Toorop に聞く形で、この差を取り上げた。論点はローカルコピーが DNS ルートの権限を得るかどうかではない。日常の小さな問い合わせをゾーン配布に置き換えたとき、通信がどのような更新義務に変わるかである。

実装ごとに異なる更新費用

Rahimi の研究報告書は、双方をリゾルバー 1 台あたり 1 日の MB に換算した。通常方式は 1 月 1 日から 7 日までの RSSAC002 データを使う。F-root の 11.18 MB を除けば、各ルート文字は 0.67 から 1.34 MB に収まる。ローカル側は 1 月 20 日から 23 日まで、制御された仮想環境でパケットを記録した。

試験した構成 観測した更新挙動 日量 MB/リゾルバー
BIND、DNS IXFR シリアル変更後に転送、1 日 2-4 回 4.35
Unbound、DNS IXFR シリアル変更後に転送、1 日 2-4 回 3.93
Knot Resolver、HTTPS 約 1 日 1 回の全更新 2.65
Unbound、HTTPS 30 分ごとに全ダウンロード 105.12

BIND の差分は 1 回約 1.45 MB、DNS 版 Unbound は約 1.31 MBだった。4 日間の更新回数は 2、3、4、3 回で、日量は実際の変更回数に沿って動いた。

Knot は異なる取引を選んだ。試験構成は 1 日 1 回の全取得で平均 2.65 MBだった。これは今回のローカル構成では最小だが、一般的な優劣を証明しない。頻度を抑えれば、変更を直ちに反映しない時間も生まれる。通信量と鮮度は別々に最適化できない。

105.12 MB にはさらに注意が必要だ。Unbound の HTTPS 構成は、シリアル変更を先に確かめず、2.19 MB の全ファイルを 1 日 48 回取得した。報告書は開発者との確認を経て不具合と記し、修正後は変更時だけ全取得する設計を想定している。APNIC の記事も同じ境界を示す。これは HTTPS の性質ではなく、更新ロジックの測定結果である。

導入判断までは測っていない

選んだ期間では、すべてのローカル構成が論文の通常方式の基準を上回った。しかしローカル測定は 4 日、比較側は 7 日である。遅延、DNSSEC 検証の計算量、障害復旧、運用の複雑さ、外部ルート経路への依存を減らす価値は測っていない。バイト数だけで導入の可否は決められない。

規模の分母にも仮定がある。RSSAC002 のユニーク送信元アドレスをリゾルバーの近似値として扱うため、NAT や IPv6 集約は一対一対応を崩す。約 5914 万台へ乗算した TB/日の図は線形な拡大を説明する例であり、実ネットワークの予測ではない。

安定した基準は残る。RFC 8806は、完全で最新かつ DNSSEC 検証可能なコピーと、古いデータを提供する前の非ローカル経路への切り替えを求める。新しい個人 Internet-Draft 第 07 版は、全ゾーン取得前の状態確認と効率的な HTTPS 配布を論じる。ただしファイル名に bcp が残っていても、編集注記は BCP として進めないと明記する。現行 IETF 方針ではなく作業中の提案である。

結論は控えめでよい。ローカルなルート提供は、多数の小さな問い合わせを更新義務に変える。その義務が効率的か、最新かは、シリアル確認、転送方式、1 回のバイト数、回数、検証結果、コピーの年齢を見なければ分からない。