DNS over HTTPS/TLS (DoH/DoT) の技術詳細

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

DNS over HTTPS/TLS (DoH/DoT) の技術詳細

背景

従来のDNS (Domain Name System) は、その設計上の特性からいくつかの課題を抱えていました。主に、DNSクエリが暗号化されていないため、通信経路上で盗聴、改ざん、トラッキングの脅威に晒される可能性がありました。また、UDPポート53を使用することが多いため、ファイアウォールによるフィルタリングや、特定のネットワーク環境下での通信遮断が容易でした。これらの課題は、ユーザーのプライバシー侵害、情報検閲、およびセキュリティリスク増大を招きます。

これらの問題に対処し、DNS通信のプライバシーとセキュリティを向上させるために提案されたのが、DNS over TLS (DoT) と DNS over HTTPS (DoH) です。これらは既存の強固なセキュリティプロトコルであるTLS (Transport Layer Security) を利用してDNSクエリを暗号化し、信頼性を高めることを目的としています。

設計目標

DoH/DoTの主要な設計目標は以下の通りです。

  • プライバシーと機密性: DNSクエリとレスポンスを第三者から保護し、盗聴やトラッキングを防止します。これはTLSによる暗号化によって実現されます。

  • 完全性と認証: DNSメッセージが通信途中で改ざんされていないこと、および通信相手が正規のサーバーであることを保証します。TLSの認証機能を利用します。

  • 検閲耐性: HTTPS (ポート443) やTLS (ポート853) を利用することで、一般的なWebトラフィックや既存のTLSベースのサービスと同じポートを利用するため、ネットワークレベルでのフィルタリングやブロックを困難にします。

  • 既存インフラの活用: WebブラウザやHTTPプロキシ、TLSライブラリなど、既存の広範なエコシステムを再利用することで、導入と展開を容易にします。

  • パフォーマンス: TCP/TLSのオーバーヘッドを最小限に抑えつつ、特にHTTP/2やHTTP/3 (QUIC) の多重化機能を活用して効率的なクエリ処理を実現します。

詳細

プロトコルスタックの概要

DoHとDoTは、それぞれ異なるトランスポートとアプリケーション層のプロトコル上にDNSメッセージをカプセル化します。

graph TD
    A["アプリケーション"] --> B["DNSクライアント/リゾルバ"]
    B --> C{"DNS over TLS/HTTPS"}
    C --> D1["DNS over TLS |RFC 7858, 8310|"]
    C --> D2["DNS over HTTPS |RFC 8484|"]
    D1 --> E["TLS |RFC 8446|"]
    D2 --> F{"HTTP/1.1, HTTP/2, HTTP/3 |RFC 911x|"}
    F --> E
    E --> G1["TCP |RFC 793|"]
    E --> G2["UDP |RFC 768|"]
    G2 --> H["QUIC |RFC 9000|"]
    G1 --> I["IP |RFC 791|"]
    H --> I

DNS over TLS (DoT)

DoTは、DNSクエリ/レスポンスを直接TLSセッション上で送信するプロトコルです (RFC 7858, RFC 8310)。標準ではTCPポート853を使用します。

  • ハンドシェイク: クライアントとサーバーはまずTCPハンドシェイクを完了し、その後にTLSハンドシェイクを実行してセキュアなチャネルを確立します。

  • DNSメッセージフォーマット: TLSセッション確立後、各DNSメッセージは、ネットワークバイトオーダーの2バイトの長さフィールドが先行する形で送信されます。これにより、複数のDNSメッセージが単一のTCPストリーム上で多重化されることなく、明確に区切られます。

DNS Message Length:16 bits (network byte order)
DNS Message (RFC 1035):variable bits

DNS over HTTPS (DoH)

DoHは、DNSクエリ/レスポンスをHTTPメッセージペイロードとして送信し、そのHTTPメッセージをTLSセッション上で保護するプロトコルです (RFC 8484)。標準ではTCPポート443（HTTPSの標準ポート）を使用します。

  • HTTPメソッドとメディアタイプ: DoHはHTTPのGETまたはPOSTメソッドを使用します。

    • GETメソッド: DNSクエリがURLパラメータとしてエンコードされます。通常、application/dns-message または application/dns-json のAcceptヘッダと組み合わせて使用されます。

    • POSTメソッド: DNSクエリがHTTPリクエストボディとして送信されます。Content-Type: application/dns-message ヘッダを使用します。

  • HTTPバージョンの利用:

    • HTTP/1.1: 従来のHTTPプロトコルであり、各DNSクエリが独立したTCP接続またはKeep-Alive接続上の独立したリクエストとして処理されるため、ヘッドオブラインブロッキング (HOL blocking) が発生しやすいです。

    • HTTP/2 (RFC 9113): TCP多重化を利用し、単一のTCP接続上で複数のDNSクエリを並行して送受信できるため、HOL blockingを緩和し、効率を向上させます。HPACKによるヘッダ圧縮も利用されます。

    • HTTP/3 (RFC 9114): UDPベースのQUICプロトコル (RFC 9000) 上で動作します。QUICはストリームレベルでのHOL blocking回避、0-RTT接続確立、より堅牢な輻輳制御、コネクションマイグレーションなどの機能を提供し、DNSクエリのパフォーマンスをさらに向上させます。

TLS 1.3 ハンドシェイクとDoH/DoTクエリ

TLS 1.3 (RFC 8446) は、従来のバージョンに比べてハンドシェイクを高速化し、セキュリティを強化しています。

sequenceDiagram
    participant C as クライアント
    participant S as サーバー
    C ->> S: |TCP SYN|
    S ->> C: |TCP SYN-ACK|
    C ->> S: |TCP ACK|
    C ->> S: |TLS ClientHello|
    S ->> C: |TLS ServerHello, ChangeCipherSpec, EncryptedExtensions, Certificate, CertificateVerify, Finished|
    C ->> S: |TLS ChangeCipherSpec, Finished|
    activate C
    activate S
    C ->> S: |DoH/DoT DNS クエリ|
    S ->> C: |DoH/DoT DNS レスポンス|
    deactivate S
    deactivate C

0-RTT (Zero Round-Trip Time) Resumptionの利用 (TLS 1.3): 0-RTTは、過去にセッションを確立したことのあるクライアントが、再度接続する際に以前のセッション情報を利用して、サーバーへの最初のパケット（ClientHello）に暗号化されたアプリケーションデータ（Early Data）を含めることで、ハンドシェイクを1-RTTに短縮する機能です。DoH/DoTにおいて、これによりDNSクエリのレイテンシを大幅に削減できます。

sequenceDiagram
    participant C as クライアント
    participant S as サーバー
    C ->> S: |TCP SYN|
    S ->> C: |TCP SYN-ACK|
    C ->> S: |TCP ACK|
    C ->> S: |TLS ClientHello (PSK, Early Data: DoH/DoT DNS クエリ)|
    activate C
    S -->> C: |TLS ServerHello, ChangeCipherSpec, EncryptedExtensions, Certificate, CertificateVerify, Finished|
    S ->> C: |DoH/DoT DNS レスポンス (Early Data処理後)|
    C ->> S: |TLS ChangeCipherSpec, Finished|
    deactivate C

再送の例: トランスポート層での再送は、ネットワークの信頼性や品質に依存します。TCPではSYN/SYN-ACK/ACKの再送、データパケットの再送が行われます。QUICもUDP上で独自の信頼性メカニズムを持ちます。

sequenceDiagram
    participant C as クライアント
    participant S as サーバー
    C ->> S: |TCP SYN|
    S ->> C: |TCP SYN-ACK|
    C ->> S: |TCP ACK|
    C ->> S: |TLS ClientHello|
    S -- "X C": |TLS ServerHello (パケットロス)|
    C ->> S: |TLS ClientHello (再送)|
    S ->> C: |TLS ServerHello, ...|
    C ->> S: |TLS Finished|
    S ->> C: |TLS Finished|
    C ->> S: |DoH/DoT DNS クエリ|
    S -- "X C": |DoH/DoT DNS レスポンス (パケットロス)|
    C ->> S: |DoH/DoT DNS クエリ (再送)|
    S ->> C: |DoH/DoT DNS レスポンス|

相互運用

DoH/DoTの相互運用性には、クライアントとサーバー間のTLSバージョン、暗号スイート、HTTPバージョンの合意が不可欠です。

  • クライアント/サーバー機能: 両者がサポートするTLSバージョン（最低TLS 1.2、推奨TLS 1.3）、HTTPバージョン（HTTP/2、HTTP/3対応）、および特定のDNSレコードタイプや拡張（EDNS0など）に対応している必要があります。

  • ミドルボックス: ファイアウォールやIDS/IPS (Intrusion Detection/Prevention Systems) は、従来のDNSトラフィックとは異なるポートやプロトコルを使用するDoH/DoTをブロックしたり、検査不能として扱ったりする可能性があります。特にHTTPSポート443を使用するDoHは、Webトラフィックとして扱われるため、通過しやすい傾向があります。

  • サービスディスカバリ: クライアントがDoH/DoTリゾルバをどのように発見するかは重要な課題です。DNS-SD (Service Discovery) や、DNS SVCB/HTTPSリソースレコード (RFC 9460, RFC 9461) を用いた発見メカニズムが標準化されつつあります。これにより、特定のドメインに対してDoH/DoTサービスを提供しているサーバーを自動的に発見・利用できるようになります。

セキュリティ考慮

DoH/DoTはDNS通信のセキュリティを大幅に向上させますが、いくつかのセキュリティ考慮事項が存在します。

  • リプレイ攻撃 (Replay Attack):

    • 特にTLS 1.3の0-RTT Early Dataは、同じ暗号化キーで再送される可能性があるため、リプレイ攻撃に対して脆弱です。RFC 8446では、0-RTTデータは冪等 (idempotent) なリクエストに限定することを推奨しています。DNSクエリは通常、情報取得（GETリクエストに相当）であり冪等ですが、万一副作用のあるクエリが0-RTTで送られると問題になり得ます。サーバー側は、0-RTTで受け取ったデータに対して厳密なリプレイ検出メカニズムを実装し、特に冪等でない操作は受け付けないようにする必要があります。

  • ダウングレード攻撃 (Downgrade Attack):

    • 攻撃者が意図的にクライアントとサーバー間のTLSバージョンや暗号スイートをより強度の低いものにダウングレードさせようとする攻撃です。TLS 1.3 (RFC 8446) は、ハンドシェイク時にすべてのバージョン情報をハッシュに含めることで、この種の攻撃に対して強力な耐性を持っています。クライアントとサーバーは、可能な限り最新で強力なTLSバージョンと暗号スイートの利用を強制すべきです。

  • キー更新 (Key Update):

    • 長期にわたるセッションでは、セッションキーが漏洩した場合のリスクを低減するために、定期的なキー更新が重要です。TLS 1.3は、ハンドシェイクが完了した後でも、KeyUpdateメッセージを使用してセッションキーを更新するメカニズムを提供します。DoH/DoTの長期間維持される接続では、この機能が利用されるべきです。

  • 0-RTTの再送リスク:

    • 前述のリプレイ攻撃と関連しますが、0-RTT Early DataはTLSハンドシェイク完了前にサーバーに到達し処理されるため、ネットワーク途上で傍受・再送された場合、サーバーが意図しない処理を行う可能性があります。DNSクエリは通常読み取り専用であるため、重大な副作用は少ないとされますが、サーバーはこれらを慎重に扱い、同一のEarly Dataが複数回処理されないように識別子やタイムスタンプの検証を行うべきです。

実装メモ

プロトコル実装に際しては、以下の点に特に注意が必要です。

  • MTU/Path MTU:

    • DoHでHTTP/3 (QUIC) を利用する場合、基盤となるUDPのMTU（Maximum Transmission Unit）は非常に重要です。IP層での断片化は性能を低下させるため、Path MTU Discovery (PMTUD) を適切に実装し、送信パケットサイズを経路上のMTUに合わせる必要があります。TCPベースのDoTやHTTP/2 DoHでは、TCP層で断片化が処理されますが、大きなDNSレスポンス（例: DNSSECレコード）を扱う場合は、不必要なオーバーヘッドを避けるためPMTUDの考慮は有効です。

  • HOL blocking回避:

    • HTTP/1.1ではTCP接続のHOL blockingが問題となります。HTTP/2は単一TCP接続上でのストリーム多重化によりこれを緩和しますが、TCP自身のHOL blockingは依然として存在します。HTTP/3 (QUIC) はUDP上に複数の独立したストリームを実装することで、真の意味でのHOL blockingを回避し、ネットワーク遅延やパケットロスに強い特性を持ちます。効率的なDoHクライアント/サーバー実装には、HTTP/2またはHTTP/3の積極的な利用が推奨されます。

  • キュー制御:

    • 高負荷下でのDNSクエリ処理では、リクエスト/レスポンスキューの適切な管理が不可欠です。クライアント側では、未処理のクエリ数を制限し、リゾルバへの接続数を調整することで、システムリソースの枯渇を防ぎます。サーバー側では、受信したクエリを効率的にバックエンドのDNSリゾルバに渡し、レスポンスをクライアントに送り返すためのキューイングとスケジューリングが必要です。

  • 優先度:

    • HTTP/2およびHTTP/3は、ストリームに対して優先度を割り当てるメカニズムを提供します。DNSリクエストの中には、Webページのレンダリングに不可欠なものや、バックグラウンドでの更新など、緊急度が異なるものがあります。これらの優先度をHTTP層で適切に設定することで、クリティカルなクエリの解決を早め、ユーザー体感を向上させることが可能です。

まとめ

DNS over HTTPS (DoH) と DNS over TLS (DoT) は、従来のDNSが抱えていたプライバシーとセキュリティの課題に対し、強力な解決策を提供します。TLSによる暗号化と認証は、DNSトラフィックの盗聴、改ざん、トラッキングを防ぎます。特にDoHはHTTP/2やHTTP/3 (QUIC) の多重化機能を活用することで、パフォーマンスの向上とHOL blockingの回避を実現し、既存のWebインフラストラクチャとの高い親和性を示します。

実装においては、TLS 1.3の0-RTT利用時のリプレイ攻撃リスク、ダウングレード攻撃への耐性、セッションキーの適切な更新といったセキュリティ考慮事項が不可欠です。また、MTU、HOL blocking回避のためのプロトコル選択、キュー制御、クエリ優先度設定といった実装上の注意点も、安定した高性能なDNSサービス提供には欠かせません。これらの技術詳細を理解し、適切に実装することで、よりセキュアで高速なインターネットの実現に貢献できます。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました