DoT（DNS over TLS）で障害が起きたときは、「影響範囲の確定」「どの層で失敗しているかの切り分け」「暫定対応で名前解決を戻す」「原因を直して再発を防ぐ」の順に進めると、混乱せずに復旧できます。DoT は TLS で守られている分、証明書や TCP の接続が原因で止まることが多く、平文の DNS とは見る場所が違います。この記事では、社内向けなどに DoT のリゾルバーを運用している人と、systemd-resolved などで DoT を使っているサーバーの管理者に向けて、障害発生時の手順を説明します。
導入したばかりで最初から動かない場合はトラブルシューティングの記事が向いています。ここでは「昨日まで動いていたものが止まった」場面を想定します。
初動：影響範囲を確定する
最初の数分で、次の3つを確かめます。これだけで、原因の候補がかなり絞れます。
- 誰が困っているか。 全員なのか、特定の端末の種類（Android だけ、Linux サーバーだけ）なのか、特定のネットワークからだけなのか。
- 平文の DNS は動くか。 同じリゾルバーの 53 番に問い合わせて応答が返るなら、問題は TLS か TCP 853 番の経路にあります。53 番も駄目なら、リゾルバー本体か後段の問題です。
- いつから、何を変えたか。 証明書の更新日、ファイアウォールやネットワークの変更、ソフトウェアの更新、サーバーの再起動の記録を見ます。障害の多くは、何かを変えた直後か、証明書の期限の日に起こります。
影響が広い場合は、調査を始める前に関係者へ「名前解決の障害を調査中」と一報を入れておきます。
切り分け：どの層で失敗しているか
外側から順に、1層ずつ確かめます。以下の dns.example.com は自分のリゾルバーに置き換えてください。
# 1. TCP 853 番に届くか
nc -vz -w 3 dns.example.com 853
# 2. TLS の検証が通るか（期限と検証結果を見る）
openssl s_client -connect dns.example.com:853 -servername dns.example.com </dev/null 2>/dev/null \
| grep 'Verify return code'
echo | openssl s_client -connect dns.example.com:853 -servername dns.example.com 2>/dev/null \
| openssl x509 -noout -enddate
# 3. DoT で名前解決できるか（証明書をホスト名で検証する）
kdig @dns.example.com +tls-ca +tls-hostname=dns.example.com example.com A
# 4. 平文で名前解決できるか（比較用）
dig @dns.example.com example.com A +time=3 +tries=11 で失敗すれば経路かサーバーの待ち受け、2 で失敗すれば証明書、3 だけ失敗すれば DNS の応答そのもの、という具合に、どこで止まったかが原因の層を示します。BIND 9.18 以降の dig なら +tls でも DoT で問い合わせられますが、既定では証明書を検証しない版があるため、証明書の確認には openssl か kdig を使います。
クライアント側が systemd-resolved なら、次の情報も集めます。
resolvectl status # どのサーバーに DoT で接続しようとしているか
resolvectl query example.com
journalctl -u systemd-resolved --since "30 min ago"原因と対処（起こりやすい順）
1. 証明書の期限切れ、または更新後の反映漏れ
最も多い原因です。手順2で Verify return code が 0 以外、または期限が過ぎていれば該当します。証明書ファイルは新しいのに古い証明書が返っている場合は、更新後に DNS サーバーが読み直していません。
- 対処：証明書を更新し、サーバーを再起動（または読み直し）します。certbot を使っているなら
certbot renewのログ（/var/log/letsencrypt/）で、更新とフックの実行が失敗していないかも見ます。 - 確認：手順2の出力で新しい期限が返ることを見ます。
2. TCP 853 番が途中で止められている
手順1で接続できない、または特定のネットワークからだけ失敗する場合です。サーバー側のファイアウォールの変更、クラウドのセキュリティグループ、利用者側のネットワークで 853 番の外向き通信が遮断された、といった変化が考えられます。DoT は専用のポートを使うため、ネットワーク側で止められやすい方式です。
- 対処：サーバー側の許可設定を確かめ（
sudo ss -ltnp | grep :853で待ち受けも確認）、利用者側のネットワーク管理者にも 853 番の扱いを確認します。 - 確認：許可したネットワークと外部の両方から手順1を実行します。
3. ホスト名や証明書チェーンの不一致
Android の「プライベート DNS」（項目名は機種や版で異なります）や systemd-resolved の DNS=IPアドレス#ホスト名 の書式のように、ホスト名で証明書を検証するクライアントでは、証明書の名前とクライアントに設定したホスト名が一致しないと接続できません。証明書の更新で SAN（サブジェクト代替名）の内容が変わった、中間証明書を含まない証明書ファイルに切り替わった、といった変化で起こります。
- 対処：サーバーには中間証明書を含む fullchain を指定し、SAN に利用者へ案内したホスト名が入っていることを確かめます。
- 確認：
openssl x509 -noout -ext subjectAltNameで SAN を表示して比べます。
4. 後段のリゾルバーや上流の障害
手順1と2は通るのに、手順3で SERVFAIL やタイムアウトになる場合です。DoT の入り口（dnsdist など）の後ろにあるリゾルバーが止まっている、上流への通信が失敗している、DNSSEC の検証で失敗している、などが考えられます。平文の 53 番でも同じ結果になるなら、DoT 固有の問題ではありません。
- 対処：後段のリゾルバーのプロセスとログを確かめます。特定の名前だけ SERVFAIL になるなら、その名前の DNSSEC の状態を外部のツールで確認します。
5. 同時接続数や資源の不足
利用者が増えた、クライアントが接続を張りっぱなしにする、といった理由で TCP の接続数が上限に達すると、新しい接続が受け付けられず、一部の利用者だけがタイムアウトする症状になります。Unbound では incoming-num-tcp（スレッドあたりの TCP 接続数）や tcp-idle-timeout が関係します。既定値は版で変わるため、手元のドキュメントで確認してください（2026年10月現在）。
# 853 番の確立済み接続の数
ss -tn state established '( sport = :853 )' | wc -l- 対処：接続数の上限を見直し、アイドル接続を早めに閉じる設定にします。上限を上げるとメモリの使用量も増えるため、少しずつ変えて様子を見ます。
6. サーバーやクライアントの時刻のずれ
時刻が大きくずれていると、有効な証明書でも「まだ有効でない」「期限切れ」と判定されます。仮想マシンの復元直後や、時刻同期が止まった機器で起こります。timedatectl で時刻同期の状態を確かめます。
暫定対応：名前解決を先に戻す
原因の修正に時間がかかる場合は、まず名前解決を戻します。ただし、どの暫定対応にもトレードオフがあります。
- 予備の DoT サーバーへ切り替える。 systemd-resolved の
DNS=に複数のサーバーを書いておけば、自動で切り替わります。最初から複数台を用意しておくのが、最も影響の少ない備えです。 - 証明書を前のものに戻す。 更新した証明書に問題がある場合で、前の証明書の期限が残っているときに使えます。
- クライアントを opportunistic モードにする。 systemd-resolved の
DNSOverTLS=opportunisticは、DoT が使えないときに平文へ戻ります。名前解決は戻りますが、その間は通信が暗号化されません。社内の方針で暗号化を必須にしている場合は、責任者の判断を仰いでから行い、戻す時期を決めておきます。
# /etc/systemd/resolved.conf.d/dot.conf（暫定。復旧後に yes へ戻す）
[Resolve]
DNS=192.0.2.53#dns.example.com 198.51.100.53#dns2.example.com
DNSOverTLS=opportunistic変更後は sudo systemctl restart systemd-resolved で反映し、resolvectl status で設定が変わったことを確かめます。WordPress のサーバーで名前解決が止まると、プラグインの更新や外部 API との通信、メール送信などが一斉に失敗するため、Web サーバー側のエラーログもあわせて確認しておくと影響を把握しやすくなります。
復旧の確認と再発防止
復旧したら、切り分けで使った手順1〜3を、許可したネットワークと外部の両方から再度実行し、暫定で変えた設定を元に戻します。そのうえで、次の対策を検討します。
- 証明書の期限を外から監視する。 ファイルではなく、853 番で実際に返る証明書の期限を定期的に確かめ、残り日数が少なくなったら通知します。
- 合成監視を置く。 一定間隔で DoT の問い合わせを実際に送り、応答の有無と時間を記録します。HTTP や TCP の死活監視だけでは、DNS の応答の異常に気づけません。
- 変更の記録を残す。 ファイアウォールや証明書の変更日を記録しておくと、次の障害で「いつから、何を変えたか」にすぐ答えられます。
- 振り返りを書く。 時系列、原因、気づくまでの時間、暫定対応の判断を短くまとめておくと、手順の改善につながります。
まとめ
- 初動では、影響範囲、平文の DNS が動くか、直前の変更、の3点を確かめます。
- 切り分けは TCP 853 番、TLS の検証、DoT での名前解決、平文との比較の順に行います。
- 原因は証明書の期限切れや反映漏れが最も多く、次いで 853 番の遮断、ホスト名やチェーンの不一致、後段の障害、接続数の不足、時刻のずれが続きます。
- 暫定対応では予備サーバーへの切り替えを優先し、平文へ戻す opportunistic モードは判断と期限を決めてから使います。
- 再発防止には、外からの証明書監視と、DoT の問い合わせを実際に送る合成監視が有効です。