DNS用語集

DoT(DNS over Transport Layer Security)とは?

Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
主なポイント要点はAIの支援により生成されています。自動生成された要約には、時折誤りがあったり、重要な文脈が抜け落ちたりする場合があるため、完全な情報を得るには、必ずブログ記事の全文をご参照ください。

DNS over Transport Layer Security(DoT)は、RFC 7858で定義されているように、TCPポート853上のTLSを使用してクライアントとリゾルバー間のDNSトラフィックを暗号化するネットワークプロトコルであり、経路上の傍受者がクエリを読み取ったり改ざんしたりすることを防止します。 DoTは、標準的なDNSメッセージを暗号化されたTLSセッションで包むことで、クライアントからリゾルバーへのホップを保護しますが、リゾルバーによる権威サーバーへのその後のルックアップを保護するものではなく、DNS応答の検証も行いません。これらの機能はDNSSECによって別途処理されます。 ゲストネットワーク、支社、およびリモートワーカーを管理する企業環境において、DoTは専用ポートとファイアウォール制御の容易さを通じて、DNS over HTTPS(DoH)に比べて運用上の利点を提供します。ただし、導入を成功させるには、慎重な証明書管理、明確なリゾルバーポリシー、および厳格モードとオポチュニスティックモードの設定を適切に処理し、暗号化されていないクエリへのサイレントフォールバックを回避する必要があります。

  • DoTはTCPポート853上で専用チャネルを使用して動作するため、ネットワーク管理者は、ポート443上の標準的なHTTPSトラフィックに混在するDoHとは異なり、シンプルなファイアウォールルールを通じてDNS暗号化ポリシーを特定、監視、および適用することができます。
  • 厳格モードでの証明書検証では、リゾルバーの証明書が設定された名前と一致し、信頼できるCAへのチェーンが確立されている必要があります。有効期限が切れた証明書や中間証明書の欠落は、解決の停止を引き起こすため、積極的な監視と有効期限管理が求められます。
  • TLSハンドシェイクに失敗したオポチュニスティックモードのクライアントは、ユーザーに気付かれることなく、平文のDNSクエリに静かにフォールバックする可能性があり、その結果、内部DNSフィルタリング、ロギング、および内部ゾーンに対するスプリットホライズン応答を迂回する恐れがあります。

DNS over TLSの概要

AttributeValue
Full nameDNS over Transport Layer Security
CategoryNetwork protocol
Defined inRFC 7858, with usage profiles in RFC 8310
Protocol and portTCP port 853
OSI layerApplication layer, carried over TLS and TCP
Primary useEncrypting DNS queries and responses between a client and a recursive resolver
Related termsDNS over HTTPS, DNS over QUIC, DNS resolver, Transport Layer Security, DNSSEC

DNS over TLSの仕組み

DoTは、通常のDNSメッセージを平文ではなく、暗号化されたTLSセッションを介して送信します。DNSメッセージの形式は変更されず、変更されるのは転送方法のみです。

  1. TCP接続の確立:クライアントは、RFC 7858でDoT用に予約されているTCPポート853を介してリゾルバーに接続します。
  2. TLSハンドシェイクを完了する:クライアントとリゾルバーがTLSパラメータをネゴシエートし、リゾルバーが証明書を提示します。RFC 8310のユースケースプロファイルに応じて、クライアントはリゾルバーの身元を検証するか(厳格モード)、認証されていないセッションを受け入れるか(機会主義モード)のいずれかを行います。
  3. クエリの送信:クライアントは、DNS over TCPと同様に、2バイトの長さフィールドを先頭に付加した標準的なDNSメッセージを、暗号化されたセッションを通じて送信します。
  4. 応答の受信:リゾルバーは、同じセッションを通じて DNS 応答を返します。経路上の観察者は、暗号化されたトラフィックしか確認できません。
  5. セッションの再利用または終了:クライアントは接続を開いたままにし、その接続を介してさらなるクエリを送信することができます。これにより、検索のたびにハンドシェイクを繰り返す必要がなくなります。

DoTが保護するのは、クライアントとリゾルバー間のホップのみです。リゾルバー自身が権威サーバーに対して行うルックアップは別の経路であり、DoTの対象外となります。また、DoTは応答の妥当性を検証しません。その役割はDNSSECが担っています。

企業ネットワークにおいてDNS over TLSが重要な理由

従来のDNSクエリは平文で送信されるため、ネットワーク経路上の誰でも、デバイスがどの名前を検索しているかを確認でき、応答を改ざんすることも可能です。DoTは、クライアントからリゾルバーへの経路におけるこの脆弱性を解消します。企業にとって、これは経路を直接制御できないゲストWi-Fi、支店間のリンク、およびリモートワーカーの接続において重要です。

DoTは、RFC 8484で定義されているDNS over HTTPS(DoH)とよく比較されます。どちらも同じトラフィックを暗号化します。 運用上の主な違いは、DoTが専用のポート853を使用するのに対し、DoHは通常のWebトラフィックとポート443を共有する点です。専用ポートがあれば、ネットワーク管理チームは簡単なルールでDoTを識別、監視、ルーティング、またはブロックできます。一方、DoHはWebトラフィックから分離しにくく、クライアントが独自のリゾルバーを選択した場合、企業のDNSポリシーを迂回される可能性があります。

管理が不十分だと、どちらの方向でも問題が生じます。計画なしにファイアウォールでDoTをブロックすると、ストイックモードに設定されたクライアントはホスト名の解決に失敗します。一方、クライアントが外部リゾルバーに暗号化されたクエリを送信すると、内部ゾーンの解決が停止し、DNSベースのセキュリティフィルタリングやロギングが迂回されてしまいます。 リゾルバーには、有効な証明書、有効期限の監視、およびどのクライアントがどのリゾルバーを使用できるかに関する明確なポリシーが必要です。

DNS over TLSと関連用語の比較

DNS over TLS 対 DNS over HTTPS (DoH)

DoTは専用のポート上でDNSメッセージをTLSで直接カプセル化しますが、DoHはそれらをTLS内のHTTP通信として伝送するため、DoHトラフィックは通常のWebトラフィックに溶け込むことができます。DNS over HTTPSとは何ですか?

AttributeDNS over TLSDNS over HTTPS (DoH)
StandardRFC 7858RFC 8484
Default portTCP 853TCP 443
Transport layerTLS directly over TCPHTTP inside TLS
Visibility to network teamsEasy to identify, filter or allow by portHard to separate from other HTTPS traffic
Typical enforcementAllow or block port 853 at the firewallNeeds resolver address lists or application-level controls
Protocol overheadLower, with no HTTP framingHigher, because of HTTP headers and framing

DNS over TLSの一般的な問題

多くのファイアウォールやゲストネットワークでは、送信元のTCP 853ポートへの通信が遮断されるため、DoTクエリはタイムアウトします。厳格モードでは、クライアントがホスト名の解決に失敗する可能性があり、機会主義モードでは、何も通知せずに平文通信にフォールバックする可能性があります。

厳格モードでは、リゾルバーの証明書は、設定された名前と、信頼されたCAへの証明書チェーンと一致している必要があります。有効期限が切れた証明書、中間証明書の欠落、またはクライアントから信頼されていない内部CAがあると、ハンドシェイクエラーや解決機能の停止が発生します。

TLSセッションを確立できない「オポチュニスティックなクライアント」は、警告なしに暗号化されていないクエリを送信する場合があります。ユーザーはDNSが保護されていると信じていますが、経路上の監視者は依然としてその内容を読み取ることができます。

外部リゾルバに送信された暗号化されたクエリは、内部のDNSフィルタリング、ロギング、およびスプリットホライズン応答をバイパスします。内部のホスト名に対してはNXDOMAINが返されるか、クライアントが承認されたDoTリゾルバに誘導されるまで、ポリシー制御はスキップされます。

DoTを終了させるリゾルバーは、多くの長期にわたるTCPおよびTLSセッションを開いたままにしておく必要があります。接続制限が不十分だったり、アイドルタイムアウトが短すぎたりすると、リクエストが集中する際にリセットが発生し、遅延が増大します。

統合型DDIがネットワーク運用をいかに簡素化するかをぜひご覧ください

自動化、可視性、制御機能が組み込まれた単一のプラットフォームから、DNS、DHCP、IPアドレスを管理できます。

DNS over TLS FAQ

関連用語

Network visualization showing IP addresses and interconnected nodes representing IPAM infrastructure and data flow

組織のネットワーク向けに、ガバナンスが確立され、監査対応可能なIPAMワークフローおよび承認モデルを構築する

ガバナンスが確立され、監査対応が可能なIPAMワークフローを実現するIP管理ソリューションをご覧ください。企業ネットワークチーム全体で、範囲を限定した承認と完全な監査証跡を実現します…

Read more
コンテンツハブ

OSIモデルの理解:7層構造におけるDNSとIPアドレスの位置づけ

OSIモデルの7つの層と、DNSおよびIPアドレスがそれらにどのように位置づけられるかを理解しましょう。BlueCatでネットワークアーキテクチャの基礎を学びましょう。…

Read more
Fiber optic cables with glowing blue and cyan light points representing high-speed network data transmission and connectivity

IPv6 およびデュアルスタック企業ネットワーク向けの DNS および IPAM のスケーリング

デュアルスタック企業ネットワーク向けに DNS および IPAM を拡張します。Micetro が、統合された DNS、DHCP、および IPAM…

Read more
Hand holding digital pen interacting with holographic network diagrams and data visualization on laptop screen, representing

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

Read more
ポッドキャスト

ポッドキャスト:AIがエンタープライズソフトウェア開発をどう変えているか

AIはネットワークの自動化を変革しますが、安全な導入には、サービス停止を防ぐための堅固なソフトウェア開発手法、テスト、およびドメインの専門知識が必要です。…

Read more
ポッドキャスト

ポッドキャスト:ネットワーク運用においてオープンプラットフォームが重要な理由

オープンプラットフォームとAPIファーストのアーキテクチャにより、ハイブリッド環境の企業全体で、インテリジェントなネットワーク運用、自動化、そしてAI駆動のワークフローが実現されます。…

Read more
Network engineer reviewing LiveNX flow and telemetry data visualized across server racks in a hybrid multicloud environment

LiveAssistを活用して、すでに保有しているLiveNXのデータから答えを引き出しましょう

LiveNX用のAI搭載アドオン「LiveAssist」が、ネットワークデータを迅速で分かりやすい回答に変換し、わずか数日でその価値を実感できる仕組みについてご覧ください。…

Read more

関連記事