要約

  • 権威サーバーを一台から二台にした後、平均クエリー数はテスト当たり3.43から2.57に減り、一回だけ観測されたテストは58%から71%へ増えた。
  • APNIC Labsは因果を特定していない。公開IPの背後にディスパッチャーと複数の再帰エンジンがあるという説明は、検証すべき仮説である。
  • 一回の名前解決を監査するには、クライアント要求、振り分け先、キャッシュ、権威宛て送信、応答、再試行理由、完了を同じ記録鎖で結ぶ必要がある。
観測値 権威サーバー一台 権威サーバー二台
テスト数 254,894,985 150,221,951
総クエリー数 875,316,423 385,725,364
テスト当たりクエリー数 3.43 2.57
クエリー一回のテスト 58% 71%
反復したテストの平均反復数 3.80 2.56

答えは同じでも、到着の仕方が変わった

APNIC Labsの実験で加えられた変更は限定的だった。対照側の実験ゾーンには、IPv4とIPv6を持つ権威サーバー名が一つあった。次の構成では、別のサーバー名と、そのIPv4、IPv6アドレスが追加された。応答は肯定応答のままである。

一台構成では約2億5500万回のテストに対して8億7500万件のクエリーが届いた。二台構成では約1億5000万回に対して3億8600万件だった。反復が生じたテストだけを見ても、平均反復数は3.80から2.56へ下がっている。

ここから「二台なら常に速い」とは言えない。二つの標本は規模が異なり、権威側の観測点は利用者から回答までの全状態を見ていない。確実なのは、権威側の選択肢を増やした後、到着したパケットの分布が変わったという一点である。

タイムアウトだけでは説明しにくい時間帯

反復の大半は早い。権威サーバー一台では重複の約85%が最初の一秒に、二台では約75%が一秒以内に到着した。どちらも五秒までには約90%に達した。一台構成の山はおよそ100、310、800ミリ秒、二台構成では50、100、310、370、750、800ミリ秒付近に見える。

差が大きいのは10〜70ミリ秒、とりわけ10〜40ミリ秒である。一般的な単一UDP問い合わせのタイムアウトより短く、単純な「待って、失効して、同じ処理が再送した」という説明には収まりにくい。10ミリ秒未満の連射型反復も約17%から12%へ減った。

APNICの別の失敗応答実験では、肯定応答が3.43件だったのに対し、SERVFAILは51.73件、無応答は83.46件だった。こちらは失敗の種類とキャッシュ、再試行増幅を扱う。本件は肯定応答を維持したまま権威トポロジーを変えた。二つを混同すると、未解明の部分を消してしまう。

安定した入口の後ろに複数の時計がある

APNICが示した一案は、フロントエンドが複数の再帰バックエンドへ仕事を配る構成だ。クライアントは一つの公開IPへ送る。別々のバックエンドが同じ論理要求を受け、それぞれが必要なキャッシュ状態を持っていなければ、権威側には近接した同一クエリーが届き得る。出口側でアドレスが集約されれば、送信元も同じに見える。

dnsdistの公式マニュアルは、この可能性を具体化する。dnsdistは問い合わせを受け、下流サーバーを選び、応答を返す。未処理数、ハッシュ、重みに基づく選択ができ、複数の受信・応答スレッドも構成できる。ただし、これは実装可能性の証拠であり、APNICが観測したサービスの実装証明ではない。

Anycast、負荷分散、NAT、スレッドプール、キャッシュ同期にも同じ注意が要る。IPアドレスは配送先として機能する。しかし、それをクライアント、実行エンジン、論理解決の三つすべてのIDとして使う根拠はない。

クエリーの一致は、仕事の一致ではない

RFC 9520はサーバー、アドレス、トランスポートを別々に扱い、QNAME、QTYPE、QCLASSでクエリーを区別する。RFC 1035の16ビットIDは、要求側が応答を未完了の問い合わせへ対応づけるための値である。

それでも論理的な名前解決の境界は見えない。ディスパッチャーはIDを書き換え得る。別のエンジンが同じIDを選ぶこともある。キャッシュヒットは権威へ届かない。権威ログは、元のstub要求、選ばれたバックエンド、失効したタイマー、再試行を許した判断、完了を宣言した時点を知らない。

必要なのは、推測した主体ではなく連結した実行記録である。入口は要求と期限を記録する。ディスパッチャーはバックエンド選択を、再帰エンジンはキャッシュと委任状態を記録する。外向き試行にはサーバー名、アドレス、トランスポート、クエリー組、送信時刻を付ける。応答には種別と検証結果を、再試行には起点となったエラーかタイマーを、完了にはクライアントへ返した結果を結び付ける。

全記録を一組織が持つ必要はない。だが、公開IPを不足した情報の代わりに使えば、観測できなかった関係を、存在した関係として扱ってしまう。

冗長性の原則と、観測の原則

RFC 2182は複数の権威サーバーとネットワーク・地理的分離を求める一方、増やし過ぎによる運用負担にも触れる。APNICの結果はその原則を「二台の方が速い」という標語に置き換えるものではない。

サーバー選択、アドレスファミリー、フロントエンドの親和性、キャッシュ共有、並行実行など、複数の説明が残る。測られた変化は明確で、原因は未確定である。この二つを同時に保つことが、障害分析の出発点になる。

出典