DNS over TLS（DoT）

概要

DNS over TLS（DoT） は、DNS クエリを TLS（Transport Layer Security）で暗号化し、専用のポート 853 で送受信するプロトコルです。RFC 7858（2016年5月）で標準化されました。従来の DNS は UDP ポート 53 で平文のクエリを送受信するため、経路上の第三者がどのドメインを問い合わせたかを傍受できます。DoT はこの問題を解消し、スタブリゾルバーと再帰リゾルバー間の通信を暗号化します。

DoT は DNS over HTTPS（DoH、RFC 8484、2018年）より 2 年早く標準化されました。両者は DNS 通信を暗号化するという目的は同じですが、使用するポートとブロック耐性が大きく異なります。DoT は専用のポート 853 を使うため、ネットワーク管理者がポート番号で DoT トラフィックを識別してブロックできます。DoH は HTTPS と同じポート 443 を使うため、通常の Web トラフィックと区別がつきません。

企業ネットワークのように DNS トラフィックの可視性を維持しつつ暗号化したい環境では、DoT が適しています。Android 9 以降は「プライベート DNS」設定で DoT をネイティブにサポートしており、モバイル環境での利用が広がっています。

仕組み

DoT のプロトコル構造、Strict / Opportunistic の 2 つの接続モード、DoH や DNSSEC との違いを説明します。

プロトコルの構造

DoT は TCP ポート 853 上で TLS セッションを確立し、その中で従来の DNS ワイヤーフォーマットをやり取りします。RFC 7858 では次の仕様が定められています。

1. クライアントがサーバーのポート 853 に TCP 接続を開始する
2. TLS ハンドシェイクを行い、暗号化セッションを確立する
3. TLS セッション内で DNS クエリ・応答をやり取りする
4. DNS メッセージは 2 バイトの長さプレフィックスに続いて送信される（TCP DNS と同じフォーマット）

DoH が HTTP/2 のフレーミングを使うのに対し、DoT は TLS 上で直接 DNS メッセージを送る構造です。プロトコルスタックの層が 1 つ少ないため、実装がシンプルになります。

接続モード

RFC 8310（2018年）は、DoT クライアントの接続モードを 2 種類定義しています。

Strict モード は、サーバーの TLS 証明書を厳密に検証します。証明書の検証に失敗した場合、DNS クエリを送信しません。セキュリティは高いですが、証明書の問題で名前解決が停止するリスクがあります。

Opportunistic モード は、TLS 接続を試みますが、失敗した場合は平文 DNS にフォールバックします。「使えるなら暗号化する」というアプローチで、接続性を優先します。Android の「プライベート DNS」設定で「自動」を選択した場合は Opportunistic モードで動作します。

DoH との比較

項目	DoT（RFC 7858）	DoH（RFC 8484）
使用ポート	853（専用）	443（HTTPS 共用）
プロトコル層	TLS 上の DNS	HTTP/2 + TLS 上の DNS
トラフィックの識別	ポート 853 で識別可能	HTTPS と区別困難
ブロック耐性	低い（853 だけ塞げる）	高い（443 を塞ぐと Web も停止）
ブラウザー対応	ブラウザーは非対応（OS レベル）	主要ブラウザーが標準対応
モバイル対応	Android 9 以降でネイティブ対応	Android 13 以降で対応拡大

DNSSEC との違い

DoT と DNSSEC は保護する対象が異なります。DoT はクライアントとリゾルバー間の「通信経路」を暗号化します。DNSSEC は DNS レコードの「データの完全性と出自」を署名で保証します。DoT で通信経路を暗号化しても、リゾルバーが受け取る DNS データ自体の正当性は検証されません。逆に DNSSEC で署名検証をしても、通信は暗号化されません。両者は補完関係にあり、併用することで DNS クエリの全行程を保護できます。

設定例

Android、Linux（systemd-resolved）、Unbound での DoT 設定手順を示します。

Android のプライベート DNS 設定

Android 9 以降では、設定画面から DoT を有効にできます。

設定 → ネットワークとインターネット → プライベート DNS
  - 自動（Opportunistic モード）
  - プライベート DNS プロバイダーのホスト名（Strict モード）
    例: dns.google
    例: 1dot1dot1dot1.cloudflare-dns.com

ホスト名を指定すると Strict モードで動作します。「自動」の場合は Opportunistic モードとなり、DoT が使えるリゾルバーでは暗号化し、対応していないリゾルバーでは平文にフォールバックします。

Linux（systemd-resolved）での設定

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes

DNSOverTLS=yes で Strict モード、DNSOverTLS=opportunistic で Opportunistic モードになります。# の後はサーバーの TLS SNI（Server Name Indication）に使用するホスト名です。

Unbound での設定

# /etc/unbound/unbound.conf
server:
  tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 1.1.1.1@853#cloudflare-dns.com
  forward-addr: 8.8.8.8@853#dns.google

確認方法

DoT 接続の動作確認には、TLS 接続を確立してから DNS クエリを送る方法が使えます。

# openssl で DoT サーバーへの TLS 接続を確認
openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com

TLS ハンドシェイクが成功し、証明書情報が表示されれば DoT サーバーへの接続は正常です。

kdig コマンド（knot-dnsutils パッケージ）は DoT に対応しています。

# kdig で DoT 経由の DNS 問い合わせ
kdig @1.1.1.1 +tls example.com A

dig コマンドは DoT に対応していません。dig は常に平文 DNS（UDP/TCP ポート 53）で通信します。

Android の DoT 動作を確認するには、Cloudflare の接続チェックページ（1.1.1.1/help）をブラウザーで開き、DoT の状態を確認します。

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。名前解決の結果は DoT・DoH・平文 DNS のいずれでも同じです。

curl "https://labee.dev/api/dns?domain=example.com&type=A"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "A": [
        { "address": "93.184.216.34", "ttl": 3600 }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 45 }
}

よくある問題

DoT 固有の問題はポート 853 のブロック、TLS 証明書の検証失敗、初回接続時の遅延に集約されます。

ポート 853 がファイアウォールでブロックされている

企業やホテルのネットワークでは、ポート 853 がブロックされていることがあります。Strict モードの場合、DoT 接続に失敗するとフォールバックせず名前解決が停止します。Opportunistic モードであれば平文 DNS にフォールバックします。

ポート 853 がブロックされる環境で暗号化を維持したい場合は、ポート 443 を使う DoH への切り替えが有効です。

TLS 証明書の検証失敗

Strict モードでは、DoT サーバーの TLS 証明書が有効でなければ接続を拒否します。クライアントの時刻がずれている場合や、CA 証明書バンドルが古い場合に検証失敗が発生します。openssl s_client で証明書の有効期限と発行者を確認し、原因を特定してください。

DoT を有効にしたら特定のネットワークで遅延が増える

DoT は TCP 接続と TLS ハンドシェイクが必要なため、初回クエリでは平文 DNS より数十ミリ秒の遅延が加わります。ネットワーク品質が低い環境（高遅延のモバイル回線、衛星回線など）では影響が顕著になることがあります。TCP Fast Open（RFC 7413）と TLS 1.3 の 0-RTT 再開（RFC 8446）の組み合わせで、再接続時のオーバーヘッドを軽減できます。