DNS インフラストラクチャ

あるプロバイダーの DNS 管理 API が成功を返したにもかかわらず、ある地域のユーザーは古いアドレスに解決されてしまう。トラブルシューティングを行う際には、管理画面をチェックするだけでなく、コントロールプレーンの公開、権威サーバーのレプリカ、再帰キャッシュ、アプリケーションキャッシュの順に階層ごとに確認する必要がある。DNS の分散型メカニズムは拡張性を高めるが、「変更がコミットされた」と「ユーザーが切り替わった」の間には、複数の観測可能なフェーズが存在する。

ルートサービス：13 個の名前であり、13 台の物理マシンではない

ルートゾーンには、a から m までの 13 個の名前付き権威サービスが設定されており、各運用者が多数のインスタンスをデプロイしている。インスタンス数とサイトは絶えず変化するため、日付なしの数値をアーキテクチャの定数として記述するのは不適切である。root hints はルートサービスの名称とアドレスを提供し、再帰サーバーの起動を助けるが、それは完全なルートゾーンでもなく、DNSSEC のトラストアンカーでもない。IANA：ルートネームサーバー

ルートゾーンには、トップレベルドメインの委譲、対応するアドレス、DNSSEC などのデータが含まれるが、ルートヒントファイルはルートサーバーを見つけるためのものであり、完全なルートゾーンと等価ではない。サイズが必要な場合は、実際のバージョン/フォーマットを明確にして測定し、ヒントファイルのサイズを完全なゾーンの規模として扱ってはならない。IANA：ルートゾーンとファイル

ルートサーバーは通常の再帰サービスを提供しないが、ルートゾーン自身のデータまたはそれに対応する不存在（NXDOMAINなど）に対して回答することは可能であり、リファラルのみを返すわけではない。RD=1 が設定されていても、必ずしもリクエスト元の代わりに再帰を行う必要があるわけではない。再帰サーバーは priming によってルート NS などの現在情報を取得し、起動情報が古くなっていることと、ルートゾーンの信頼チェーンにエラーがあることは、2つの異なる問題である。RFC 8109：ルート初期化クエリ

Anycast：ルーティングの選択は地理的な距離のソートに等しくない

複数の場所で同一のサービスプレフィックスを宣告し、ネットワークは到達可能性、ルーティングポリシー、および各種メトリクスに基づいてパスを選択する。AS_PATH は BGP の候補要因の一つに過ぎず、LOCAL_PREF などが結果をより早く決定する可能性がある。「最近接」とは、AS 数が最少であること、キロメートル数が最短であること、RTT が最低であることを直接意味するものではない。RFC 4786：Anycast 運用

1つの観測ポイントから同一の IP にアクセスしても、ルーティングの変化に伴って別のインスタンスに切り替わる可能性がある。複数のインスタンスが同一の /24 を一貫して宣告しても、永続的なセッションスティクシーが保証されるわけではない。むしろ、同一プレフィックスが複数箇所で宣告されているため、選択はアップストリームのルーティング状態に依存する。

短い UDP クエリは再試行しやすいが、DNS は TCP、TLS、HTTPS、QUIC などの接続状態を保持する転送媒体も使用する。パスが突然切り替わった場合、新しいインスタンスには古い接続状態がない可能性があり、適切なルーティングの安定性、状態処理、または再接続ポリシーが必要である。「DNS は毎回独立しており、Anycast は完璧で無代价である」と一般論で語ってはならない。

サービスの障害が必ずしもリンクや BGP セッションの障害につながるわけではない。インスタンスが正しく回答できないにもかかわらずルーティングを宣告し続ける場合、トラフィックはブラックホールに流れ続ける可能性がある。ヘルスチェックとルーティング撤回の連携、撤回のタイミング、およびカバーされるプレフィックスの設計が必要である。一方で、頻繁な撤回はジッターを引き起こすため、一時的なタイムアウトごとにサイト全体のルーティング撤回をトリガーしてはならない。

権威の冗長性：複数の NS 名が独立した障害域を意味しない

2つの NS が同じデータセンター、アップストリーム、アカウント、または公開パイプラインを共有している場合、それらは同時に障害を起こす可能性がある。設計では、サービス面と管理面の共通依存関係を考慮し、宣告されている権威がすべて必要なデータに正しく回答できることを確保する必要がある。

primary/secondary は AXFR/IXFR などで同期できるが、マネージドサービスでは内部データベースを使用して公開することもできる。どのようなメカニズムを採用する場合でも、各権威の実際の結果を観察するべきである。SOA serial は一部のデプロイメントのバージョンを確認するのに役立つが、署名の有効性、レコードの内容、および全ノードでのロード結果も照合する必要がある。

外部向け権威は、通常、誰に対しても再帰を開放すべきではない。BIND の views、アクセス制御、再帰オプションは異なるポリシーを表現できるが、そのマッチング順序と具体的なセマンティクスは使用しているバージョンに応じて照合する必要がある。「53番ポートをリッスンしている」からといって、役割の分離が正しいとは限らない。BIND 設定リファレンス

再帰容量：キャッシュヒット率がアップストリーム負荷を決定する

サービスが 10000 クエリ/s を受信し、そのうち 90% が対象のキャッシュ層でヒットすると仮定すると、約 1000 クエリ/s がさらに処理を必要とする。未命中ごとに平均 3 回のアップストリームトランザクションが発生する場合、平均アップストリーム負荷は約 3000 回/s となる。ヒット率が 50% に低下すると、これは 15000 回/s に上昇する。ここで言う「3」は例示のための測定仮定であり、実際のエイリアス、委譲キャッシュ、DNSSEC、失敗時の再試行はこれを変更する。

平均アップストリームトランザクションが 3000/s、平均在途時間（in-flight time）が 20 ms の場合、安定したシステムにおけるリトルの法則により、在途量の平均は約 60 となる。これは、コールドスタート、権威サーバーのタイムアウト、再試行のテールなどが平均値を大幅に上回る可能性があるため、接続プールやメモリの唯一の容量指標としては使用できない。

複数の再帰インスタンスを再起動すると、ホットキャッシュが同時に失われ、アップストリーム負荷が増幅される可能性がある。ネガティブキャッシュ、リクエストのマージ、プリフェッチ、serve-stale にはそれぞれ用途と正しさの境界があり、ヒット率の数値を最大化することだけを追求してはならない。

ヒット率が 10 ポイント減少すると、アップストリームはどれほど忙しくなるか？

未命中あたりの作業量を一定に保ったまま、ヒット率を 90% から 50% に下げると、アップストリームは 3000 から 15000 回/s に変化し、これは「40% 増」ではなく 5倍である。その後、レイテンシが伸びるだけでアップストリームレートは変わらず、在途量は増加し続ける。これがリトルの法則における2つの因子の役割分担である。

$${\lambda }_u={\lambda }_q(1-h)k,L_u={\lambda }_u{W}_u$$

CDN と ECS：権威サーバーは通常、再帰サーバーを先に認識する

通常のクライアントはクエリを再帰サーバーに委ねるため、CDN 権威サーバーが認識する送信元 IP は通常、エンドユーザー自体ではなく再帰サーバーのものである。地理ベースのポリシーはアドレスデータベースと運用データに基づいて判断を行い、レイテンシベースのポリシーでは、過去の測定値や集計推定値を使用することもある。すべての DNS クエリがリアルタイムで候補エッジすべてを ping すると仮定してはならない。

ECS（EDNS Client Subnet）により、解決器はクライアントサブネット情報を付与でき、権威サーバーはこれに基づいて回答を細分化し、scope などのルールを使用してキャッシュの再利用を制限できる。送信元プレフィックスの長さは、プロトコルで IPv4 を /24、IPv6 を /56 と強制するものではない。露出精度、サービスサポート、設定のすべてが結果に影響を与える。RFC 7871：EDNS Client Subnet

本来、1つの名前/タイプに対して1つの回答のみをキャッシュすればよかったものが、100 の関連サブネット範囲を導入すると、範囲付きのキャッシュエントリが複数必要になり、再利用率が低下する。ECS は「より正確な地理的ポジショニング」を追加するだけでなく、他のコストも伴う。プライバシーとキャッシュの動作も変更される。

Route 53 の latency routing は、その遅延データに基づいて構成されたリージョンのリソースを選択するものであり、リクエスターから各具体的なアプリケーションエンドポイントまでの瞬時の最小レイテンシーを保証するものではない。地理的に近くても、ネットワークの相互接続が悪ければ、より遅くなる可能性がある。AWS：レイテンシールーティング

DNS 負荷分散：回答の選択は、各リクエストのルーティングに等しくない

A レコードの RRset に2つの IP を列挙しても、それは単に複数のアドレスがあることを示すだけで、weighted round-robin に使用される重みフィールドは含まれない。マネージドサービスでの重み付けポリシーは、回答を生成する際に設定に基づいてレコードまたはレコードグループを選択するものである。クライアントが多アドレスをどのように使用するか、接続が再利用されるかどうか、そして失敗時の再試行は、次の層の動作である。AWS：重み付きルーティング

例えば、解決器 R1 が A にキャッシュした結果、10000 のビジネスリクエストが発生し、R2 が B にキャッシュした結果、100 のリクエストしか発生しなかったとする。これら2回の DNS 選択が数の上で 1:1 であっても、アプリケーション負荷は約 100:1 となる。したがって、DNS の重みは、バイト量、接続数、またはトランザクション数が正確な比率で分配されることを保証するものではない。

ヘルスチェックに失敗すると、新しい回答は障害エンドポイントを回避できるが、古いキャッシュや既存のロングコネクションはすぐに「取り消し」されない。TTL を短縮すると、将来のキャッシュウィンドウは変更されるが、クエリ負荷も増加し、クライアントの再試行、アプリケーションの健全性、接続移行の設計に代わるものにはならない。

Split DNS：ビューの選択とアップストリームルーティングの明確化

同じ名前でも、内部ではプライベートアドレスを返し、外部ではパブリックアドレスを返すことができる。また、特定のサフィックスを持つ名前のみを内部 DNS に委譲することもできる。サーバー側の views と、クライアントがサフィックスに基づいて解決アップストリームを選択することは、異なる実装位置にある。どちらの場合も、どの種類のリクエストがどのポリシーに入るかを明確にする必要がある。

例えば、dashboard.example.com. は内部では 192.168.31.8 に解決され、外部ではドキュメントの例示パブリックアドレスに解決される。内部ユーザーがブラウザの独立した DoH を使用してシステムルーティングをバイパスした場合、外部結果を取得する可能性がある。VPN が切断された後、内部キャッシュが残っていると、到達不能になる可能性がある。これは A レコードの構文エラーではなく、クエリパスとキャッシュコンテキストの問題である。

キャッシュは、あるビューの結果を区別なく別のビューに提供してはならない。内部と外部で同じ DNSSEC 署名付き名前空間を使用する場合、内部の権威と検証の関係を設計する必要があり、ローカルでの恣意的な上書きと公開 DS チェーンが互いに競合しないようにする必要がある。

検索ドメインは短縮名を候補絶対名に展開し、ルーティングドメインはアップストリームの選択を助ける。概念と具体的な実装セマンティクスはそれぞれ照合する必要がある。内部 DNS を設定しても、すべてのアプリケーションがそれを使用するわけではない。アプリケーションの実際のパスから検証する必要がある。

1回の変更公開：段階的な観察

通常レコードの変更では、権威の公開、署名、レコードキャッシュに主に注目する。NS 委譲の変更では、親ゾーンの NS/glue と新旧権威サーバーの重複にも注目する必要がある。DS の更新では、DNSSEC の親子ゾーンチェーンおよびキーキャッシュが関与する。これら3つを、「TTL を待つだけでよい」という同じ言葉で概括することはできない。

診断には、dig @<権威アドレス> <名前> A +norecurse を使用して権威サーバーと照合し、その後、使用している再帰サーバーでクエリを実行する。dig +trace はツールが独自にイテレートしたパスを示すが、アプリケーションが設定した再帰、DoH、または VPN パスに等しくない。観察方法を変更することは、実験条件を変更することでもある。本稿では実際の外部プローブは実行していない。

ローカル容量と負荷モデル

query_rate = 10000
upstream_per_miss = 3
warm = query_rate*(1-.9)*upstream_per_miss
cold = query_rate*(1-.5)*upstream_per_miss
assert round(warm)==3000 and cold==15000
assert round(warm*.020)==60
# 2つのキャッシュがそれぞれ1回選択するが、背後にあるアプリケーション負荷は異なる。
requests = {'A':10000,'B':100}
assert requests['A']/requests['B']==100
assert 10000/(10000+100)>.99
# 限定された状態における負荷の例示のみであり、実測容量や固定キャッシュモデルを代表するものではない。
print('キャッシュミス負荷、平均在途トランザクション、DNS/ビジネス比率の違いチェック通過')

これらは明確な仮定に基づく計算例であり、プロバイダーのパフォーマンス実測値ではない。ルートヒント、公開委譲、権威レコード、または解決器のビューは変更していない。

継続的な参照

• DNS プロトコルと解決：TTL、ネガティブキャッシュ、委譲。
• DNSSEC と DNS セキュリティ：DS と署名チェーンの公開依存関係。
• DNS プライバシー：異なるアプリケーションの解決パスと信頼。
• ルーティングと BGP：Anycast パス選択と収束。