DoT の検証は、「853番に届くか」「証明書が正しく、名前の照合で弾くべきものを弾くか」「DNS の問い合わせとして正しく応答するか」「端末が本当に DoT を使っているか」の4層を、下から順に確かめるのが近道です。この記事では、自分で運用する DoT サーバーを公開する前や設定を変えた後、あるいは利用する公開リゾルバーの DoT を導入前に確かめるときの手順を、openssl・kdig・dig・tcpdump を使って説明します。
DoT が動かないときの原因探しは同じサイトのトラブルシューティング記事で扱っています。この記事は、正常に動いていることを確かめ、記録に残すための手順です。
検証の前に決めておくこと
最初に、検証の対象と期待する状態を書き出しておきます。後で「何を確かめれば合格か」がぶれないようにするためです。
- サーバーの名前とアドレス：例
dns.example.com（203.0.113.53）。端末に設定するのはこの名前です。 - 使う認証の方式：DoT の利用の仕方には、証明書と名前を照合する厳格な方式（RFC 8310 の Strict Privacy）と、照合に失敗しても暗号化だけで続ける日和見的な方式があります。公開するサーバーなら、厳格な方式で接続できることを合格の条件にします。
- DNSSEC の扱い：サーバーが DNSSEC の検証を行うのか、上流の結果を運ぶだけなのか。
手順1：853番に届くかを確かめる
nc -vz dns.example.com 853接続に成功すれば、名前解決と TCP 853番の到達性に問題はありません。失敗する場合は、サーバー側の待ち受け（ss -tlnp | grep 853）、ファイアウォール、クラウドのセキュリティグループの順に確認します。IPv6 でも提供するなら、nc -6 -vz で同じように確かめておきます。
手順2：TLS と証明書を確かめる
openssl s_client -connect dns.example.com:853 \
-servername dns.example.com \
-verify_hostname dns.example.com \
-verify_return_error </dev/null出力で次の点を確認します。
- Verify return code: 0 (ok)：証明書の連鎖がシステムの CA で検証でき、名前も一致しています。
-verify_return_errorを付けているので、検証に失敗すると接続自体が止まります。 - プロトコル：TLSv1.3 か TLSv1.2 で接続されているか。古い版が有効になっていないかは、
-tls1_1などを付けて接続が拒否されることで確かめられます（手元の openssl がそれらの版に対応していない場合もあります）。 - 中間証明書：
-showcertsを付けると、サーバーが送っている証明書の連鎖が表示されます。中間証明書が抜けていると、手元の環境では成功しても端末によっては失敗します。
有効期限は次のように確認できます。
openssl s_client -connect dns.example.com:853 -servername dns.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -enddate証明書を自動更新している場合は、更新後に DoT のサービスが新しい証明書を読み込み直しているかも確かめておきます。Web サーバーだけ再読み込みされ、DoT 側は古い証明書のまま、という漏れが起きやすいためです。
手順3：DNS の問い合わせとして確かめる
Knot DNS の kdig は DoT の検証に向いています。
# 証明書をシステムの CA で検証し、名前を照合して問い合わせる
kdig @203.0.113.53 +tls-ca +tls-hostname=dns.example.com example.com A応答が返り、出力の冒頭に TLS のセッション情報が表示されれば成功です。ここで大事なのは、失敗すべきときに失敗するかも確かめることです。
# わざと違う名前で照合する。接続が拒否されれば正しい挙動
kdig @203.0.113.53 +tls-ca +tls-hostname=wrong.example.net example.com A違う名前でも成功してしまう場合は、kdig のオプションの指定が誤っているか、照合が働いていません。厳格な方式で使う端末を守れるかどうかは、この確認で分かります。
BIND の dig も、9.18 以降の版では +tls で DoT に問い合わせられます。証明書の検証には +tls-ca や +tls-hostname を併用します。これらのオプションは版によって対応状況が異なるため、dig -h の表示で確認してください（2026年10月現在）。
dig +tls +tls-ca +tls-hostname=dns.example.com @203.0.113.53 example.com ADNSSEC の扱いを確かめる
サーバーが DNSSEC の検証を行う設定なら、署名されたドメインで AD ビットが付くことと、検証に失敗するドメインで SERVFAIL になることの両方を確かめます。
kdig @203.0.113.53 +tls-ca +tls-hostname=dns.example.com +dnssec example.com SOA
kdig @203.0.113.53 +tls-ca +tls-hostname=dns.example.com dnssec-failed.org A1つ目でフラグに ad があり、2つ目（検証失敗の確認用として知られるドメイン）が SERVFAIL になれば、検証が働いています。2つ目に通常の応答が返る場合は、サーバーが検証をしていません。
パディングを確かめる
DoT では、暗号化されていても応答の長さから内容を推測されることを防ぐため、EDNS0 のパディング（RFC 7830、RFC 8467）を使うことが推奨されています。kdig の +padding を付けると、問い合わせにパディングを付け、応答の OPT レコードに PADDING が含まれるかを表示で確かめられます。Unbound などは既定でパディングに対応していますが、版や設定によって異なるため、表示で確認してください。
手順4：端末が DoT を使っているかを確かめる
サーバー側が正しくても、端末が平文の DNS に戻っていては意味がありません。
Linux（systemd-resolved）
# /etc/systemd/resolved.conf（例）
[Resolve]
DNS=203.0.113.53#dns.example.com
DNSOverTLS=yes# の後ろは証明書と照合する名前です。設定後に sudo systemctl restart systemd-resolved で反映し、resolvectl status で該当のインターフェースに +DNSOverTLS が表示されるかを確かめます。証明書の検証の扱いは systemd の版によって異なるため、手元の版の resolved.conf のマニュアルも確認してください。
Android
設定の「プライベート DNS」にサーバーの名前（dns.example.com）を入力します。名前の照合に失敗すると接続できない旨が表示されるので、手順2の証明書の確認が済んでいることが前提です。項目名は端末のメーカーや OS の版によって異なります。
平文の DNS が出ていないかを見る
sudo tcpdump -ni eth0 'port 53 or port 853'名前解決をいくつか行い、外向きの通信が853番だけで、53番が出ていなければ DoT が使われています。53番の通信が残っている場合は、アプリケーションが独自に DNS を引いている、別の設定が優先されている、などを確認します。
検証結果を記録する
最後に、次の項目を検証の記録として残します。設定変更や証明書の更新のたびに同じ項目を繰り返すと、差分に気づきやすくなります。
- 853番への到達性（IPv4・IPv6）
- 証明書の発行者・対象の名前・有効期限、Verify return code
- 正しい名前で成功し、違う名前で失敗すること
- DNSSEC の AD ビットと、検証失敗のドメインでの SERVFAIL
- 端末側の設定と、平文の53番が出ていないこと
本番のサーバーで設定を変える場合は、変更前の設定ファイルをバックアップし、できればステージング環境で同じ手順を通してから反映してください。
まとめ
- DoT の検証は、到達性・TLS と証明書・DNS の応答・端末側の利用、の順に下の層から確かめる。
- openssl s_client で Verify return code と証明書の連鎖、有効期限を確認する。
- kdig で正しい名前なら成功し、違う名前なら失敗することを確かめると、厳格な方式で使えるかが分かる。
- DNSSEC を検証するサーバーなら、AD ビットと検証失敗時の SERVFAIL の両方を見る。
- 端末側は設定の表示と tcpdump で、平文の53番が出ていないことを確かめ、結果を記録に残す。