ナビゲーション全体を読み込み中です。

Elevate 2026へのカウントダウンが始まりました。 今すぐ登録 シカゴ、ロンドン、またはシドニーで私たちと一緒に過ごしませんか。

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

HTTP/3とHTTP/2の比較

DNS over HTTPSとTLSの比較 ― 主要概念、実装ガイドライン、および推奨事項。

DNSクエリはデフォルトでは依然として平文で送信されるため、ネットワーク経路上の盗聴者に閲覧履歴が漏洩する可能性があります。DoHとDoTはこの問題を解決しますが、暗号化のアプローチは異なります。どちらかを導入する前に知っておくべきことを以下に説明します。

10〜15分
デントン千倉

章

    ニュースレター

    最新情報のメール配信を登録

    最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

    シェア

    クイックダウンロード:

    DNS over HTTPS（DoH）とDNS over TLS（DoT）はどちらもDNSクエリを暗号化して傍受を防ぎますが、使用するポート、ネットワーク管理者による検出可能性、最適な環境において大きく異なります。

    • 標準のDNSはUDPポート53でクエリを平文で送信するため、ネットワークレベルの盗聴者に閲覧アクティビティが漏洩する可能性があります。DoHとDoTはどちらもTLSを使用してDNSチャネルを暗号化することでこの問題を解決しています。

    • DoTは専用ポート853を使用するため、暗号化されたDNSトラフィックをネットワーク管理者が識別および管理することが可能になり、DNSの可視性とフィルタリングが必要な企業環境において重要な利点となります。

    • 暗号化されたDNSのセキュリティ上の利点を維持しながら、レイテンシを改善するために、QUIC上のDNS（DoQ）を検討してください。

    ウェブサイトにアクセスすると、ブラウザに表示される鍵マークのアイコンは、アクセスしているウェブサイトが安全かどうかを示しています。これは、ブラウザとウェブサーバー間でデータ交換が行われる前に、両者間で暗号化メカニズムについて合意しているためです。これにより、銀行やソーシャルメディアサイトとの通信がインターネット上で安全に保たれます。 

    しかし、従来見落とされがちだった通信の先行ステップの一つに、DNS解決があります。ドメインネームシステム（DNS）は、インターネットの電話帳のような役割を果たし、読みやすいウェブサイト名を数値のIPアドレスに変換します。ブラウザにウェブアドレスを入力すると、設定されたDNSサーバーのチェーンを通してDNSクエリが送信され、関連付けられた宛先IPアドレスが特定されます。 

    DNSサーバーとの通信は依然としてほとんどが平文で行われており、悪意のある第三者がこの情報を傍受する可能性があります。この記事では、ドメインネームシステム（DNS）に関連するプライバシー上の懸念に対処するために導入されている新しい標準規格について解説します。

    DNS over HTTPSとTLSに関する主要な概念の概要

    DNS オーバー TLSHTTPSを介したDNS
    仕組みクライアントはDNSデータを直接TLSにカプセル化する。DNS通信はまずHTTPリクエストとして準備され、その後TLSを使用して転送されます。 
    推奨される使用例ネットワークの可視性が必要な場合プライバシーが重大な懸念事項となる場合。
    パフォーマンスDoHよりも比較的速いDoT と比べて遅い。遅延の差はごくわずかだが、それでも存在する。 追加のプロトコルオーバーヘッド HTTPSの。
    プライバシーDNSネットワークトラフィックが見えるため、プライバシーレベルは低くなります。DNSはHTTPS内で伝送されるため、プライバシーレベルが向上します。
    検閲回避検閲回避の可能性が低くなる可能性がある。より高度な検閲回避。
    ネットワークポート853443

    従来のDNSとその脆弱性

    現在、DNS通信は主に平文チャネルで行われています。コンピュータがDNSクエリを実行する際、プライバシー上の懸念を引き起こす2つの重要な情報、すなわちQNAME（アクセスしようとしているサイト）と送信元IPアドレスが共有されます。 

    QNAME は DNS クエリの開始点であり、検索対象のドメイン名またはサービスを表します。要求されたサービスまたは情報の種類に応じて、 DNSクエリはさまざまなレコードタイプを検索します。 例えば、

    • 記録—直接IPアドレス解決
    • MXレコード - メール配信
    • SRVレコード—VoIPまたはディレクトリサービス

    あなたのコンピュータとDNSリゾルバ間のネットワーク経路にアクセスできる人物は、ネットワークに侵入し、あなたの情報を傍受して、あなたの意図を推測することができます。例えば、攻撃者はあなたが特定のウェブサイトにアクセスしているのか、メールを送信しているのか、特定の種類のサービスを要求しているのかを判断できます。

    DNSのセキュリティ脆弱性

    こうしたプライバシー問題に対処するため、インターネット技術タスクフォース（IETF）は、暗号化された伝送メカニズムを強化することでDNS標準の改善を提案している。IETFがこの目的のために提案した最も注目すべき標準は、DNS over HTTPSとDNS over TLSである。

    DNS オーバー TLS

    DNS over TLS（DoT）は、DNSクエリをトランスポート層セキュリティ（TLS）暗号化でラップすることでセキュリティを確保します。TLSは、セキュアソケットレイヤー（SSL）の後継技術です。IETFはRFC 7858でDNS over TLSを規定しています。 

    TLSとその仕組み

    TLSは、対称暗号化と非対称暗号化の両方のメカニズムを使用してデータ転送を保護します。以下に説明するこのプロセスは、TLSハンドシェイクとも呼ばれます。

    1. クライアントが開始する クライアント こんにちは サーバーへのメッセージには、クライアントがサポートする最高レベルのTLSバージョンが含まれます。
    2. サーバーは次のように応答します。 サーバーこんにちは メッセージと選択されたTLSバージョン。
    3. クライアントとサーバーは、セッション中にデータの暗号化と復号化に使用される共通の秘密鍵について合意する。
    4. サーバーは、サーバーの公開鍵を含むデジタル証明書をクライアントに送信します。 認証局（CA） 信頼します。
    5. クライアントとサーバーは、共有シークレットからセッションキーを生成します。

    これらの鍵は、クライアントとサーバー間のデータの暗号化と復号化に使用されます。セッション鍵は、通信セッションが終了すると破棄されます。

    TLSハンドシェイク（ソース)

    DNS overTLSのしくみ

    ポート853は、DoTサービス用に指定された標準ポートです。DoT対応DNSサーバーは、このポートでクライアントからの接続を受け付け、受信DNSクエリに対応するように構成されています。専用ポートを使用することで、DoTトラフィックを他のネットワークトラフィックと区別でき、暗号化されたDNSクエリの管理が容易になります。ネットワーク構成上、特定のポート経由でトラフィックをルーティングする必要がある場合（ファイアウォール通過、ポリシー適用、その他の理由など）、クライアントとサーバーは合意の上、別のポートを使用できます。デフォルトポートを変更するには、両方の設定を再構成する必要があります。

    DNSクライアントがドメイン名を解決する必要があるとき、ポート853でDoT対応のDNSサーバーとの間でTCP（Transmission Control Protocol）セッションを確立します。このプロセスにはTLSハンドシェイクが含まれ、その間にクライアントとサーバーは暗号化された情報を交換します。その後、クライアントは暗号化されたDNSクエリをサーバーに送信し、サーバーは暗号化された応答を返します。

    パフォーマンスを向上させるため、クライアントは同じTLSセッション内で複数のDNSサーバーへのクエリをパイプライン処理できます。これにより、TCP接続とTLSセッションを繰り返し確立する際のオーバーヘッドを回避できます。

    DoTトラフィックはネットワーク上で暗号化されているため、その内容を読み取ることはできませんが、これは必ずしもISPによるあらゆる形式のDNSトラッキングを阻止するものではありません。クライアントとサーバーは通常、特定のポート853を介して通信するため、DNSトラフィックとして識別可能です。

    HTTPSを介したDNS

    DNS over HTTPS（DoH）は、HTTPSプロトコルを介してDNS解決を実行するプロトコルです。つまり、DNSクエリはHTTPSをトランスポート層として使用してリゾルバに送信され、他のHTTPSトラフィックと同様に暗号化されます。IETFはRFC 8484でDNS over HTTPS（DoH）を規定しています。 

    HTTPSの仕組み

    ハイパーテキスト転送プロトコル（HTTP）は、インターネットの主要な通信プロトコルです。HTTPプロトコル自体は、ヘッダーとペイロードが人間が読めるため、セキュリティを提供しません。そのセキュア版（HTTPS）は、TLSを利用して公共インターネット上でのデータ交換を安全に行います。 

    クライアントブラウザがサーバーからウェブページを要求すると、クライアントコンピュータはまずサーバーとのTCP接続を確立し、次にクライアントとサーバー間でTLSセッションを確立します（前述のとおり）。TLSハンドシェイク後、クライアントブラウザはTLSセッションを使用してウェブサーバーへのHTTPリクエストを暗号化します。ウェブサーバーは同じTLSセッションを使用して、必要なデータで応答します。

    HTTPSの仕組み（ソース)

    DNS over HTTPSの仕組み

    DoHは、同じポート443上で標準的なHTTPSプロトコルと同様に動作するため、ネットワーク上では通常のHTTPSトラフィックと区別がつきません。

    DoH 運用の中核となるのは、DoH サーバーを指す URI (Uniform Resource Identifier) の指定です。この URI は、例えば、 https://dns.server.net/dns-queryは基本的にDoHサービスのウェブアドレスであり、DNSクエリがサーバーの名前空間内のどこに送信されるべきかを指定します。

    エンドユーザーは、多くの場合、ブラウザまたはDNSクライアント内でDoH URIを設定できます。Firefox、Chrome、Edgeなどの最新のブラウザでは、プライバシーポリシー、パフォーマンス、管轄区域などの基準に基づいて、ユーザーが優先するDoHサーバーのURIを入力できる設定が用意されています。組織ネットワークでは、ネットワーク管理者が特定のDNS解決ポリシーを適用するためにDoH URIを設定します。ISPまたはDNSサービスプロバイダは、動的ホスト構成プロトコル（DHCP）を使用してDoH URIの設定を自動化することもできます。 

    定義されたURIを使用して、クライアントはHTTP GETまたはPOSTメソッドを使用して、DoHサーバーから必要なDNSクエリを解決できます。HTTPボディはDNSリクエストを次のように表します。 メディアタイプ application/dns-messageクライアントとサーバーは、安全なTLS接続を介してDNSリクエストとレスポンスを交換します。

    DNS over HTTPSとDNS over TLSの実装

    パブリックなDoTまたはDoHリゾルバを選択する前に、選択したサービスプロバイダのプライバシーおよびセキュリティポリシーを理解しておく必要があります。DNSトラフィックはエンドクライアントとDNSサーバー間で暗号化されますが、DNSサーバーはクライアントのIPアドレスを識別し、クライアントによって解決されたクエリを記録することができます。

    DoHとDoTをサポートするDNSプロバイダー

    以下は、DoTおよびDoHをサポートする、よく知られたオープンリゾルバのリストです。

    プロバイダーIPアドレスTLSポートDOH URL
    CloudFlare1.1.1.12606：4700：4700 :: 1111 853https://cloudflare-dns.com/dns-query
    Quad99.9.9.92620：fe :: fe853https://dns.quad9.net/dns-query
    グーグル8.8.8.82001：4860：4860 :: 8888853https://dns.google/dns-query

    DoHおよびDoTをサポートするオペレーティングシステム

    DoTとDoHは比較的新しい規格であり、これらのプロトコルを有効にするには、ほとんどの場合、クライアント側で手動設定を行う必要があります。 

    オペレーティングシステムドットしないNotes
    Apple macOS 11 (Big Sur 以降)はいはいネットワーク設定において、DoTとDoHの両方をネイティブでサポートしています。
    Apple iOS（14以降）はいはいDoTとDoHの両方に対するネイティブサポートは、DNSプロファイルまたはアプリを通じて利用可能です。
    Google Android（9以降）はい（限定）はいAndroid 11以降では、DoTをネイティブでサポートし、開発者向け設定でDoHのオプションを限定的に提供しています。
    Windows 11とWindows Server 2022限定的はいDoHのみネイティブサポート。DoTはサードパーティツールを通じて限定的にサポートされる場合があります。
    Linuxディストリビューション（種類は様々）はいはいサポート状況はディストリビューションや構成によって異なります。通常はsystemd-resolvedなどのツールを使った手動設定が必要です。

    DoHのブラウザサポート

    ブラウザ コメント
    Firefoxのバージョン62以降（2019年以降）https://support.mozilla.org/en-US/kb/firefox-dns-over-https
    Chromeバージョン83以降（2020年以降）https://blog.chromium.org/2020/05/a-safer-and-more-private-browsing-DoH.html
    ブロマイト版67.0.3396.88https://github.com/bromite/bromite/wiki/DNS-over-HTTPS

    PowerDNS DNSDISTを使用して独自のDoTおよびDoHサーバーを実装します。

    PowerDNS DNSDISTアプリケーションを使用すれば、既存のDNSリゾルバを変更することなく、組織向けにDoTとDoHを実装できます。DNSDISTはオープンソースのDNSロードバランサーで、任意のDNSリゾルバの前にデプロイでき、標準DNS、DoT、およびDoH機能を提供します。PowerDNSは、一般的なLinuxディストリビューション向けのソフトウェアリポジトリを提供しています。リポジトリ経由でDNSDISTをインストールする手順は、以下のリンク先で確認できます。 PowerDNSリポジトリ サイト。

    インストール後、アプリケーションの設定が必要です。DNSトラフィックの負荷分散とフェイルオーバー機能を提供するために、複数のバックエンドサーバーを定義できます。ファイルを編集してください。 /etc/dnsdist/dnsdist.conf 以下の構成で。

    -- define downstream servers, aka backends
-- https://dnsdist.org/guides/downstreams.html
newServer("1.1.1.1")
newServer("2606:4700:4700::1111")
newServer("8.8.8.8")
newServer("2001:4860:4860::8888")

    次に、DNSDIST のリスニング サービスが標準 DNS ポート 53 で接続を受け入れるように設定する必要があります。DoT と DoH を有効にするには、適切な設定を提供する必要があります。 CA署名証明書 そしてキー。以下の設定をDNSDIST設定ファイルに追加します。

    -- accept plain DNS (Do53) queries on UDP/53 and TCP/53
addLocal("0.0.0.0:53")

-- accept DNS over TLS (DoT) queries on TCP/853
addTLSLocal('0.0.0.0:853', {"/etc/ssl/domain-cert.pem"}, {"/etc/ssl/domain-cert.key"})

-- accept DNS over HTTPS (DoH) queries on TCP/443
addDOHLocal("0.0.0.0:443", {"/etc/ssl/domain-cert.pem"}, {"/etc/ssl/domain-cert.key"}, "/dns-query")

    設定後、DNSDISTサービスを（再）起動する必要があります。これで、独自のDoTおよびDoHリゾルバが利用できるようになります。

    DNS over HTTPSとTLSの比較 

    DoTとDoHはどちらも、クライアントとDNSサーバー間のDNSトラフィックを、公共インターネット上の第三者の覗き見から保護するために設計されています。この目的のために、両者ともTLSのセキュリティおよび暗号化メカニズムに依存しています。また、どちらのプロトコルもTCP伝送層上で動作します。しかし、両者の主な違いは次のとおりです。

    • DoTでは、クライアントはDNSデータを直接TLSにカプセル化する。
    • DoHでは、DNS通信はまずHTTPリクエストとして準備され、その後TLSを使用して転送されます。 

    DoTとDoHを実装すると、暗号化されていないUDP DNSクエリと比較して、DNS解決プロセスのレイテンシが増加します。DoHでは、DNS通信をHTTPでカプセル化してTLS/TCP経由で転送するという追加の手順により、 わずかに遅延が大きい DoTよりも。  

    ユースケース

    ネットワークの可視性と制御が求められる組織では、DoTが好まれます。DoTは専用ポート（853番）を使用するため、ネットワーク管理者はDNSネットワークトラフィックを監視できます。ただし、組織が独自のDoTまたはDoHリゾルバを実装しない限り、DNSの内容は依然として見えません。

    プライバシーを重視する場合、DoHが推奨されます。DoHはHTTPSトラフィックと同じポート（443番ポート）を使用するため、Webブラウジングアクティビティ内でDNSクエリを効果的に隠蔽できます。また、DoHは特定のDNSリゾルバに対する制限を回避できるため、DNSベースの検閲を実施している地域でユーザーが制限を回避するのに役立ちます。

    また、DoTとDoHは主にエンドユーザーのプライバシー保護を目的として設計されていることにも留意する必要があります。そのため、ペアレンタルコントロールやマルウェア対策のためにDNSベースのフィルタリングを実装する組織にとっては課題となる可能性があります。暗号化によってユーザーのDNSトラフィックが不可視になるため、組織はこれまで持っていた可視性と制御を失うことになります。 

    DNS over HTTPSおよびDNS over TLSの改善 

    DoHとDoTの両方において、以下の改善が必要である。

    レイテンシ

    DNS解決の遅延を改善し、同等のセキュリティとプライバシー機能を提供するために、RFC 9250で新しいプロトコル標準であるDNS over QUICが提案されました。QUICプロトコルはTLS 1.3の暗号化機能を利用しますが、トランスポート層通信の効率化のためにTCPではなくUDPを使用します。TLS 1.3における多重化の最適化と改良により、遅延はさらに低減されます。

    多層セキュリティ

    DoTおよびDoHプロトコルは、DNSクライアントとDNSリゾルバ間の通信に暗号化とプライバシー保護を提供します。しかし、DNSリゾルバと権威サーバー間の通信は、依然として標準的な暗号化されていないDNSプロトコルで行われます。実験的なRFC 9539が提案されていますが、まだ標準的な実装はありません。 

    これらの2つのプロトコルは、DNSスプーフィングやキャッシュポイズニングといった他のタイプのDNS脅威から保護することはできません。このような攻撃から保護するために、データ発信元認証とデータ整合性保護を提供するDNSセキュリティ拡張（DNSSEC）が標準化されています。DNSSECはDNS応答にデジタル署名を追加し、クライアントはこの署名を使用して、データが正当なゾーンから送信され、転送中に改ざんされていないことを認証できます。ただし、DNSSECは応答を暗号化しないため、転送中は平文のままとなり、DoT/DoHの代替手段にはなりません。

    青い線は暗号化されていない DNS トラフィックを示し、緑の線は暗号化された DNS トラフィックを示します (ソース)

    トレーシング

    ユーザーにとってDNS解決の速さは、ブランドとの第一印象を左右します。 DNSの問題 正しい解決レベルに戻すのは通常面倒な作業です。LogicMonitor は、DNS に問題があるかどうか、また解決チェーンのどのレベルで問題が発生したかをすばやく判断するのに役立ちます。解決レベルに関係なく、DNS 階層内のどこでも問題を特定できます。また、DNS 応答時間に即座にアクセスできます。 ネットワークレベルの指標 ―エージェントを一切インストールする必要はありません。

    最終的な考え

    本稿では、標準的なDNS解決プロセスに関連するプライバシー上の懸念事項と、それらの課題に対処するために設計された新しいDoTおよびDoHプロトコルについて解説しました。両プロトコルは暗号化レイヤーを共有していますが、ネットワークの可視性とプライバシーレベルにおいてそれぞれ異なります。 

    これらはオリジナルのDNS標準よりも比較的新しいプロトコルですが、その実装はまだ広く普及していません。また、DoTとDoHにはパフォーマンスに影響を与える可能性があり、これはさらに新しい提案プロトコルであるDoQで対処されています。

    プライバシーを保護しつつ可視性を維持するために、暗号化されたDNS監視を実装します。

    DoTとDoHのどちらを選択するにしても、パフォーマンスとセキュリティのためにはDNSインフラストラクチャの監視が不可欠です。LogicMonitorは、DNS階層全体にわたる解決時間の追跡や問題の特定に役立つ包括的なDNS監視機能を提供します。

    よくあるご質問

    組織内でDNS over TLSとDNS over HTTPSを同時に使用することは可能ですか？

    はい、PowerDNS DNSDISTのようなソリューションを使用すれば、両方のプロトコルを同時に実装できます。このソリューションは、DoT用のポート853とDoH用のポート443の両方でリッスンできます。これにより、異なるクライアントやアプリケーションがそれぞれ好みのプロトコルを使用しながら、DNS管理を一元的に行うことができます。ただし、個別のリスナーを設定し、証明書が両方のサービスに対して適切に設定されていることを確認する必要があります。

    DoTまたはDoHを導入した場合、既存のDNSセキュリティツールはどうなりますか？

    平文のDNSトラフィックを検査する従来のDNSセキュリティツールは、DoTまたはDoHを導入すると可視性を失います。組織は、可視性を維持するために独自のDoT/DoHリゾルバを導入するか、ログ機能を提供するDNSサーバーを使用するか、指定された検査ポイントで暗号化されたDNSトラフィックを復号化して検査できるセキュリティソリューションを導入する必要があります。

    企業ネットワークにDoTとDoHのどちらを導入するか、どのように選択すればよいでしょうか？

    ネットワークの可視性と制御を維持する必要がある場合は、専用ポート（853番）を使用するDoTを選択してください。ファイアウォール経由での監視と管理が容易です。プライバシーを最優先事項とし、DNSトラフィックと通常のHTTPSトラフィックを区別したくない場合は、DoHを選択してください。DoTはプロトコルのオーバーヘッドが少ないため、パフォーマンスも若干優れています。

    従来のDNSから暗号化されたDNSに切り替えることによるパフォーマンスへの影響は何ですか？

    DoTとDoHはどちらも、TCP接続の確立とTLSハンドシェイクのため、従来のUDPベースのDNSクエリに比べてレイテンシが増加します。DoHはHTTPプロトコルのオーバーヘッドが加わるため、DoTよりもレイテンシが若干高くなります。しかし、どちらのプロトコルも接続の再利用とクエリのパイプライン処理をサポートしており、パフォーマンスへの影響を最小限に抑えています。レイテンシに敏感なアプリケーションの場合は、暗号化を維持しながらUDPトランスポートを使用する、新興のDNS over QUIC（DoQ）プロトコルを検討してください。

    デントン千倉著

    テクニカルライター

    デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。

    免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

    © LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。