DNS用語集
DoH（DNS over HTTPS）とは？
DNS over HTTPS（DoH）は、DNSクエリと応答をHTTPS接続内に封入することで暗号化するネットワークプロトコルです。RFC 8484で定義されており、ポート443を介してDoHサーバーにDNSメッセージを送信するため、リゾルバーのトラフィックは経路上の監視や改ざんから保護されます。
主なポイント要点はAIの支援により生成されています。自動生成された要約には、時折誤りがあったり、重要な文脈が抜け落ちたりする場合があるため、完全な情報を得るには、必ずブログ記事の全文をご参照ください。DNS over HTTPS（DoH）は、RFC 8484で定義されたネットワークプロトコルであり、DNSクエリと応答をポート443上のHTTPS接続内にカプセル化して暗号化し、リゾルバのトラフィックを監視や改ざんから保護します。 企業にとっての主な運用上の課題は、独自のDoHサーバーを使用するアプリケーションやブラウザが内部リゾルバーをバイパスし、その結果、DNSフィルタリング、スプリットホライズンレコード、クエリのログ記録、および脅威検知機能が機能しなくなることです。 DoHを効果的に管理するには、組織が内部のDoH対応リゾルバーを承認し、クライアントポリシーを適用するとともに、不正なDoHサーバーへの接続を監視またはブロックして、DNSの可視性とセキュリティ態勢を維持する必要があります。
DoHの仕組み
DoHクライアントは、通常のDNSメッセージをHTTPSリクエストでカプセル化し、それをDoHサーバーに送信します。サーバーは、HTTPSレスポンスとしてDNSの応答を返します。
- DoHサーバーの特定：クライアントには、DoHサーバー用のURIテンプレートが設定されています。必要に応じてサーバーのホスト名を解決し、URIで別のポートが指定されていない限り、ポート443へのTCP接続を確立します。
- TLSの確立：クライアントとサーバーがTLSセッションをネゴシエートし、クライアントがサーバー証明書を検証します。これによりサーバーの認証が行われ、その後のすべての通信が暗号化されます。
- クエリの送信：クライアントは、DNSクエリを標準のワイヤ形式でエンコードし、GETまたはPOSTメソッドを使用したHTTPリクエストとして送信します。メッセージには、media-typeとして「application/dns-message」が使用されます。
- 応答の返却：サーバーはホスト名を解決し、HTTPレスポンスの本文にDNS応答を返します。クライアントは、これを他のDNS応答と同様に利用します。RFC 8484では、推奨される最低限のHTTPバージョンとしてHTTP/2を指定しており、これにより複数のクエリで1つの接続を共有することが可能になります。
セッションは暗号化されているため、経路上のデバイスはDoHサーバーへのTLS接続しか認識できず、クエリ名を読み取ったり変更したりすることはできません。DoHはクライアントとリゾルバー間のホップのみを保護します。リゾルバーから権威サーバーへのトラフィックは暗号化されず、リゾルバーの運用者は依然としてすべてのクエリを把握しています。
DoHの一般的な問題点
独自のDoHリゾルバ設定を持つブラウザやアプリケーションは、クエリを内部リゾルバを経由せずに直接パブリックサーバーに送信します。その結果、内部ゾーンはNXDOMAINエラーまたはタイムアウトとなり、スプリットホライズンレコード、フィルタリングポリシー、およびクエリのログ記録は、そのクライアントに対して適用されなくなります。
ポート53のトラフィックを検査または記録するセキュリティツールは、DoHクライアントからの通信を一切検知できません。ブロックリスト、シンクホール、およびレスポンスポリシーゾーンは機能せず、調査担当者はそれらのホストに関するクエリ履歴に欠落があることに気づきます。
DoHはTLSに依存しているため、システムクロックの誤り、信頼できない証明書チェーン、またはTLSを検査するプロキシが存在すると、クライアントがDoHサーバーへの接続に失敗する可能性があります。設定によっては、クライアントは暗号化されていないDNSにフォールバックするか、または解決処理が停止します。
DoHはWebトラフィックとポート443を共有しているため、HTTPSを無効にしない限り、このポートをブロックすることはできません。既知のDoHサーバーアドレスをブロックしているチームでも、新しいサーバーや自己ホスト型のサーバーが依然として通過してしまうため、リストの継続的なメンテナンスが必要となります。
一部のクライアントは、DoHサーバーに接続できない場合、暗号化されていないDNS経由で再試行を行います。ポリシーをテストしているエンジニアは、ポート53でのクエリを確認し、DoHが無効になっていると誤解する可能性があります。実際には、クライアントが単にフォールバックパスを使用しているだけなのです。
関連用語
組織のネットワーク向けに、ガバナンスが確立され、監査対応可能なIPAMワークフローおよび承認モデルを構築する
ガバナンスが確立され、監査対応が可能なIPAMワークフローを実現するIP管理ソリューションをご覧ください。企業ネットワークチーム全体で、範囲を限定した承認と完全な監査証跡を実現します…
コンテンツハブ OSIモデルの理解：7層構造におけるDNSとIPアドレスの位置づけ
OSIモデルの7つの層と、DNSおよびIPアドレスがそれらにどのように位置づけられるかを理解しましょう。BlueCatでネットワークアーキテクチャの基礎を学びましょう。…
IPv6 およびデュアルスタック企業ネットワーク向けの DNS および IPAM のスケーリング
デュアルスタック企業ネットワーク向けに DNS および IPAM を拡張します。Micetro が、統合された DNS、DHCP、および IPAM…
Embedding DNS, DHCP, and IPAM into Ansible and Git-based infrastructure-as-code pipelines
Embedding DNS, DHCP, and IPAM into Ansible and Git-based IaC pipelines with Micetro turns address and record changes into versioned, reviewable steps
ポッドキャスト ポッドキャスト：AIがエンタープライズソフトウェア開発をどう変えているか
AIはネットワークの自動化を変革しますが、安全な導入には、サービス停止を防ぐための堅固なソフトウェア開発手法、テスト、およびドメインの専門知識が必要です。…
ポッドキャスト ポッドキャスト：ネットワーク運用においてオープンプラットフォームが重要な理由
オープンプラットフォームとAPIファーストのアーキテクチャにより、ハイブリッド環境の企業全体で、インテリジェントなネットワーク運用、自動化、そしてAI駆動のワークフローが実現されます。…
LiveAssistを活用して、すでに保有しているLiveNXのデータから答えを引き出しましょう
LiveNX用のAI搭載アドオン「LiveAssist」が、ネットワークデータを迅速で分かりやすい回答に変換し、わずか数日でその価値を実感できる仕組みについてご覧ください。…
