ネットワーク面接：DNS over HTTPSの説明と使いどころ

質問の意図と適用場面

この質問は、ネットワーク、セキュリティ、バックエンド、SRE、セールスエンジニアリングの面接で出題されます。優れた回答では、DNS over HTTPS（DoH）を単なる「証明書付きのDNS」としてではなく、プロトコルの境界として扱います。DoHは、DNSクエリとレスポンスをHTTPS通信の内部で伝送します。このトランスポートにより、クライアントとDoHリゾルバの間の通常の経路上にいる第三者からクエリが隠蔽されますが、リゾルバ自体はクエリを受信するため、ログ記録やフィルタリングが可能です。採用の判断は、誰がDNSを参照する必要があるか、どのようなポリシー制御が求められるか、そしてクライアントがリゾルバに確実に到達できるかに依存します。

面接官が評価しているポイント

• DNSメッセージのセマンティクスと、HTTPステータスおよびトランスポートの挙動を明確に切り離して考えられるか。
• プライバシーの境界を提示できるか（選択されたリゾルバへの暗号化は匿名性を意味しない）。
• GETとPOSTの違い、Content-Type、キャッシュの挙動、ブートストラップを理解しているか。
• デプロイの管理者、可観測性、レイテンシ、ポリシーの観点からDoH、DoT、通常のDNSを比較できるか。
• 暗号化によってあらゆる結果が自動的に改善されると主張するのではなく、フォールバックとテストを定義できるか。

最初に確認すべき事項

クライアントとリゾルバを誰が管理しているか、企業によるフィルタリングや監査ポリシーの強制を維持する必要があるか、ネットワークがアウトバウンドのHTTPSやUDP/TCP DNSをブロックしているか、目的がローカルネットワークに対する機密性確保、アプリケーションレベルのAPIアクセス、改ざん防止のいずれであるかを確認します。ブラウザ、オペレーティングシステムのリゾルバ、または管理対象エージェントのどれがクエリを発行するかを明確にします。また、許容レイテンシ、キャプティブポータル、スプリットホライズン名、DNSSEC検証、ログの保持期間、および選択したリゾルバに到達できない場合の許容可能なフォールバックについても確認します。これらの回答によって、エンタープライズ管理のリゾルバ、アプリケーションのDoHクライアント、DoT、通常のDNSのいずれが適しているかが決まります。

30秒で答えるフレームワーク

DoHは、各DNSクエリ・レスポンスのペアをHTTPSリクエストおよびレスポンスに対応させ、通常はapplication/dns-messageメディアタイプを持つDNSワイヤフォーマットを使用します。クライアントからリゾルバまでのホップを暗号化し、HTTPSを許可するネットワークを通過できますが、リゾルバ側では依然としてクエリが可視化されるため、ポリシー上承認されたエンドポイントが必要になる場合があります。GETはキャッシュ効率を高められますが、POSTはエンコードされたクエリがURLに含まれるのを防ぐため、機密性の高いリクエストに適しています。明確なプライバシー要件やAPI要件がある場合にDoHを選択し、管理対象リゾルバと明確なトランスポート分離が重要な場合はDoTと比較検討し、展開前にブートストラップ、キャッシュ、スプリットDNSの挙動、フォールバック、テレメトリの最小化、テストを定義します。

ステップごとの詳細解説

1. プロトコル層のマッピング

DNSの問い合わせ自体はDNSメッセージのままです。RFC 8484は、1つのクエリ・レスポンスのペアを1つのHTTPトランザクションに対応させ、バイナリ表現としてapplication/dns-messageを定義しています。HTTPSは接続にTLSの機密性と完全性を提供し、HTTPはメソッド、ステータスコード、接続の再利用、キャッシュ制御を提供します。DNSのNXDOMAINやSERVFAILは依然としてDNSレスポンスコードであり、HTTP 2xxレスポンスの内部に含まれて届くことがあります。HTTP 4xxや5xxはHTTP通信自体が失敗したことを意味し、元のDNS回答を含まないため、クライアントはHTTPの障害処理を個別に適用する必要があります。

2. GET、POST、およびキャッシュの適切な選択

RFC 8484では、DoHサーバーがRFCメディアタイプに対してGETとPOSTの両方をサポートすることを求めています。GETはBase64URLエンコードされたDNSメッセージをdnsクエリパラメータに配置するため、通常のHTTPキャッシュの再利用性を高めることができますが、それらの領域が管理されていない限り、クエリがURLログ、中間機器、ブラウザの履歴に露出することになります。POSTはバイナリメッセージをContent-Typeとともにボディで伝送します。機密性の高い名前解決には、POSTまたは厳格に管理されたGETパスを選択し、ヘッダーを最小限に抑え、DNS TTLポリシーと矛盾するキャッシュの鮮度判定が発生しないようにします。GoogleはRFC 8484エンドポイントと個別のJSONエンドポイントを公開していますが、これらは異なるAPI仕様です。

3. プライバシーとポリシーの境界の定義

DoHは、保護されたホップ上でローカルの観測者が平文のDNSパケットを読み取るのを防ぎますが、リゾルバは依然としてクエリ、クライアントのメタデータ、タイミング、および選択されたポリシーコンテキストを参照できます。HTTPS自体はDNS回答の正当性を検証しません。リゾルバのDNSSECの挙動とクライアントのトラストモデルが引き続き重要です。管理された企業環境では、承認されたリゾルバ、カテゴリフィルタリング、スプリットホライズンゾーン、保持制御、監査証跡が必要になる場合があります。すべてのアプリケーションが任意のパブリックリゾルバを選択できるようにすると、通信が暗号化されていたとしても、これらの制御がバイパスされる可能性があります。

4. ブートストラップ、障害、フォールバックの処理

クライアントは、同じサービス経由でDoHサーバーを解決する前に、まずDoHサーバーのアドレスを検出する必要があります。ブートストラップには、設定済みのIP、信頼できるリゾルバ、または別のプロビジョニングチャネルを使用できますが、いずれの経路でも証明書の検証とローテーションが必要です。HTTPエラー、DNSレスポンスエラー、タイムアウト、キャプティブポータルのインターセプト、ポリシーによる拒否は、別個の結果として処理します。リゾルバの停止時に承認されたトランスポートへフォールバックすることはあり得ますが、信頼されていないリゾルバへのサイレントフォールバックはプライバシーやエンタープライズポリシーに違反する可能性があります。デフォルトで完全なクエリ内容を保持することなく、どのリゾルバとトランスポートが応答したかを記録します。

5. デプロイの選択肢の比較と検証

従来のDNSはシンプルでネットワーク管理者から可視化されますが、平文トランスポートのため経路上でクエリが露出します。DoTは専用のTLSサービスでDNSを暗号化し、オペレーティングシステムのリゾルバにとって扱いやすい場合が多いです。DoHはDNSをHTTPSに統合し、既存のHTTPインフラ、ブラウザAPI、ポート443の到達性を活用できますが、HTTP層のポリシーと可観測性の複雑さが増します。制御されたテストによるパケットキャプチャ、リゾルバ側のDNSおよびHTTPステータスログ、キャッシュヒットとTTLの挙動、スプリットDNSのケース、DNSSEC障害、キャプティブポータル、リゾルバ停止、証明書ローテーション、フォールバックポリシーを用いて選択を検証します。平均レイテンシだけでなく、名前解決のp50/p95/p99、障害分類、クエリの漏洩を測定します。

優れた回答の例

DoHは、DNSのクエリとレスポンスをHTTPS通信の中に配置するプロトコルです。DNSメッセージは通常の意味を維持し、HTTPSはクライアントと選択されたリゾルバ間のホップを保護し、HTTPはメソッド、ステータスコード、接続の再利用、キャッシュの挙動を提供します。したがって、DNSのNXDOMAINはHTTP 2xxレスポンス内で伝送されることがあり、HTTP 5xxはDNS回答を含まないトランスポートまたはサービスの障害を意味します。アプリケーションレベルのアクセスが必要な場合や、ローカルネットワークに対する機密性が求められ、かつ承認されたリゾルバを指定できる場合にDoHを使用します。機密性の高い名前にはPOSTを優先し、ヘッダーを最小限にし、リゾルバポリシー、DNSSEC処理、スプリットホライズンゾーン、ログ保持を明確に定義します。ブートストラップは設定済みまたは信頼できる名前解決を通じて実行される必要があり、フォールバックは承認されたポリシーの範囲内にとどめる必要があります。ロールアウト前には、キャッシュとTTLのセマンティクス、GETにおけるURLログの露出、キャプティブポータル、証明書ローテーション、リゾルバ停止、DNSSECエラー、そしてパケットやログによって意図したリゾルバ以外にクエリが漏洩していないかをテストします。

よくある間違い

• 「HTTPSによってDNSが匿名になる」と述べる → 選択されたリゾルバは依然としてクエリとメタデータを参照できるため、保護される正確なホップとリゾルバの信頼境界を明記する必要があります。
• DNSのNXDOMAINをHTTPエラーとして扱う → DNSレスポンスコードはHTTP 2xxの内部に含まれる可能性があるため、HTTPとDNSのステータス層を個別に解析する必要があります。
• URLログについて触れずに機密データに対してGETを選択する → エンコードされたクエリが履歴や中間ログに残る可能性があるため、POSTを使用するか、制御されたキャッシュおよびロギングポリシーを適用します。
• DoHが常にDoTより優れていると主張する → デプロイの管理者、ポリシー、到達性、可観測性が異なるため、まずは具体的な環境を比較検討する必要があります。
• 同じ未解決のリゾルバを通じてDoHホスト名のブートストラップを行う → クライアントに循環依存が発生するため、アドレスを直接プロビジョニングするか、信頼できるブートストラップ経路を用意します。
• タイムアウト後に任意のパブリックリゾルバへフォールバックする → 機密性やエンタープライズフィルタリングがバイパスされる可能性があるため、承認されたトランスポートとエンドポイントのみにフォールバックを制限します。
• 平均レイテンシのみを測定する → 停止、キャッシュミス、クエリ漏洩が見落とされるため、p95/p99、障害の分類、TTLの挙動、リゾルバの識別情報を細分化して測定します。

関連する質問と回答

DoHはDNS回答が真正であることを検証しますか？

いいえ。TLSはクライアントによって選択されたHTTPSサーバーを認証するだけです。DNS回答の真正性はリゾルバの検証動作と、そのリゾルバに対するクライアントの信頼モデルに依存します。DNSSECとHTTPSは別の関心事です。設計時には、検証が必要かどうか、また検証の失敗をどのように表面化させるかを定義しておく必要があります。

なぜHTTP 200に失敗したDNSルックアップが含まれることがあるのですか？

HTTP通信自体は成功し、有効なDNSメッセージを伝送したためです。DNSメッセージにはNXDOMAIN、SERVFAIL、またはその他のDNSレスポンスコードが含まれている可能性があります。クライアントは両方のレイヤーを解析し、DNSの有効な否定応答（Negative Response）をHTTPリクエストが失敗したかのように再試行しないようにする必要があります。

DoTがより適した選択肢となるのはどのような場合ですか？

OSやエンタープライズのリゾルバがトランスポートを管理し、専用のDNSポートとシンプルなネットワークポリシーを求め、ブラウザ向けのHTTP APIを必要としない場合にはDoTが適しています。既存のHTTPS到達性やアプリケーションAPIが必要な場合はDoHが適しています。この判断は、単なる「暗号化されている方が良い」という一律のルールではなく、管理権限とポリシーに基づいて行います。

キャプティブポータル上でDoHリゾルバに到達できない場合はどうすべきですか？

ポータルの存在または繰り返されるTLS/HTTP障害を検出し、リトライの増幅を停止した上で、設定されたポリシーに従います。承認されたフォールバックを使用するか、ユーザーに復旧手順を提示して名前解決を一時停止するか、あるいはポリシーで許可されている場合にのみネットワークから提供されたDNSを一時的に使用します。無制限なフォールバックはすべてのクエリを漏洩させる可能性があるため、ロールアウト前にこれをテストしてください。