DoT (DNS over TLS) への切り替え手順｜Linux サーバー・Android・ルーターで名前解決を暗号化し、元に戻せる形で移行する

DoT（DNS over TLS）に切り替えると、端末やサーバーから DNS リゾルバーまでの問い合わせが TLS で暗号化され、途中の経路で内容を読まれたり書き換えられたりしにくくなります。この記事では、切り替え先のリゾルバーの選び方を確認したうえで、Linux サーバー（systemd-resolved と Unbound）、Android、ルーターでの切り替え手順と、平文の DNS が残っていないかの確認、問題が出たときの戻し方を説明します。WordPress を動かしているサーバーで外向きの名前解決を暗号化したい場合にも、そのまま使える内容です。

切り替える前に決めること

DoT で守れる範囲

DoT（RFC 7858）は、DNS の問い合わせを TCP の 853 番で TLS に包んで送る方式です。守れるのは「端末からリゾルバーまで」の区間だけで、リゾルバーから先の権威 DNS サーバーへの問い合わせは、多くの場合いまも暗号化されていません。また、問い合わせの内容はリゾルバーの運営者には見えます。DoT は通信路の暗号化であり、応答の内容が正しいことを保証する DNSSEC とは役割が違う点も押さえておきます。

切り替え先のリゾルバー

DoT に対応した公開リゾルバーには、次のようなものがあります。いずれも IP アドレスと、証明書の検証に使うホスト名の組で指定します。

• Cloudflare：1.1.1.1 / 1.0.0.1（ホスト名 cloudflare-dns.com または one.one.one.one）
• Google Public DNS：8.8.8.8 / 8.8.4.4（ホスト名 dns.google）
• Quad9：9.9.9.9（ホスト名 dns.quad9.net）

提供内容やフィルタリングの有無、ログの扱いは各社のポリシーに書かれています。問い合わせ先を変えることは、閲覧先の情報を渡す相手を変えることでもあるため、切り替えの前に目を通しておきます。社内に自前のリゾルバーがある場合は、そちらを DoT 対応にする選択肢もあります。

「厳格」か「日和見」か

多くの実装には、TLS が使えないときに平文へ戻る「日和見（opportunistic）」と、戻らずに失敗させる「厳格（strict）」の2つの動作があります。日和見は止まりにくい反面、通信を妨害されると気付かないうちに平文へ戻ります。最初は日和見で動作を確かめ、問題がなければ厳格に移す、という順序が無理のない進め方です。

Linux サーバー：systemd-resolved で切り替える

Ubuntu など systemd-resolved を使うディストリビューションでは、設定ファイルを1つ追加するだけで切り替えられます。作業前に、いまの設定を resolvectl status で控えておきます。

# /etc/systemd/resolved.conf.d/dot.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
FallbackDNS=
DNSOverTLS=opportunistic

sudo systemctl restart systemd-resolved
resolvectl status
resolvectl query wordpress.org

# の後ろは証明書の検証に使うホスト名です。resolvectl status の出力に DoT が有効であることを示す表示（+DNSOverTLS など）が出ていれば反映されています。表示の形式は systemd のバージョンで異なります。

つまずきやすいのは、DHCP などから受け取ったリンクごとの DNS サーバーが残っている場合です。systemd-resolved はリンクごとの DNS も併用するため、そちらに平文で問い合わせが流れることがあります。netplan を使っている環境なら、インターフェースの設定で DHCP の DNS を使わないようにします。

# /etc/netplan/50-cloud-init.yaml の該当インターフェース（例）
      dhcp4: true
      dhcp4-overrides:
        use-dns: false

netplan を書き換えたら sudo netplan try で適用します。一定時間内に確定しないと元に戻るため、SSH でつないでいるサーバーでも締め出されにくくなります。また、/etc/resolv.conf が systemd-resolved のスタブ（127.0.0.53）を指しているかを ls -l /etc/resolv.conf と cat /etc/resolv.conf で確かめます。別のファイルに置き換わっていると、設定しても使われません。

動作に問題がなければ、DNSOverTLS=yes に変えて厳格な動作にします。

Linux サーバー：Unbound をローカルのリゾルバーにする

キャッシュをサーバー内に持ちたい場合や、systemd-resolved を使っていない環境では、Unbound を DoT の転送役にする構成が扱いやすくなります。

# /etc/unbound/unbound.conf.d/forward-dot.conf
server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow
    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: 1.0.0.1@853#cloudflare-dns.com

sudo unbound-checkconf
sudo systemctl restart unbound
dig @127.0.0.1 wordpress.org +short

tls-cert-bundle は CA 証明書のバンドルのパスで、Debian・Ubuntu の例です。RHEL 系では /etc/pki/tls/certs/ca-bundle.crt など別のパスになります。指定がないと証明書を検証できず、問い合わせが失敗します。Unbound は転送先に対して日和見の動作を持たないため、TLS が通らなければ名前解決が止まります。確認が済むまで、元の /etc/resolv.conf は残しておきます。

Unbound を使うと決めたら、/etc/resolv.conf の参照先を 127.0.0.1 に変えます。systemd-resolved と同時に動かす場合、Unbound を 0.0.0.0 などすべてのアドレスで待ち受けさせるとポート 53 がぶつかることがあります。上の例のように待ち受けアドレスを絞り、どちらか一方を名前解決の窓口にします。

Android・iPhone・ルーター

• Android。 設定のネットワーク関連の項目にある「プライベート DNS」で、リゾルバーのホスト名（例：dns.google）を指定します。項目の場所や名前は機種と OS のバージョンで異なります（2026年10月現在）。Android の自動モードは日和見、ホスト名の指定は厳格の動作に当たります。
• iPhone・Mac。 OS の設定画面に DoT を直接入れる項目はなく、構成プロファイルや対応アプリで設定します。社内で配る場合は、MDM でプロファイルを配布する方法が一般的です。
• ルーター。 OpenWrt などでは、Unbound や stubby を入れて LAN 全体の問い合わせを DoT で転送できます。家庭用ルーターの対応は製品ごとに異なるため、メーカーの説明を確認してください。

切り替わったかを確かめる

設定が反映されていても、平文の問い合わせが別の経路から出ていることがあります。サーバーでは、外向きの 53 番を観察すると確かめられます。

# 平文の DNS が外へ出ていないか（数分眺めて、出ていなければ切り替わっている）
sudo tcpdump -ni any '(udp port 53 or tcp port 53) and not host 127.0.0.1 and not host 127.0.0.53'

# DoT の通信が出ているか
sudo tcpdump -ni any 'tcp port 853'

ブラウザが使える端末では、Cloudflare の https://1.1.1.1/help を開くと、Cloudflare のリゾルバーを DoT で使っているかが表示されます。ほかの事業者も同様の確認ページを用意している場合があります。

ファイアウォールで外向きの TCP 853 番を閉じている環境では、DoT はつながりません。クラウドのセキュリティグループや社内のプロキシで外向きの通信を絞っている場合は、853 番の許可を先に入れておきます。

WordPress サーバーで気を付けること

WordPress は更新の確認や外部 API の呼び出しで頻繁に名前解決を行います。DoT では TLS の接続を張る分だけ、キャッシュに無い名前の初回の問い合わせが遅くなることがあります。Unbound のようにキャッシュを持つ構成にすると、2回目以降はローカルで応答できるため影響は小さくなります。

同じサーバーでメールを送っている場合、DANE の検証には DNSSEC を検証するリゾルバーが必要です。転送先を変えたことで DNSSEC の検証結果が届かなくなっていないかを、dig +dnssec の応答の ad フラグで確かめておきます。Postfix を chroot で動かしている構成では、chroot 内の resolv.conf が古いままのこともあります。

問題が出たときの戻し方

• systemd-resolved： 追加した /etc/systemd/resolved.conf.d/dot.conf を削除して systemctl restart systemd-resolved を実行します。netplan を変えた場合は元のファイルに戻して netplan apply を実行します。
• Unbound： /etc/resolv.conf を元の内容に戻せば、Unbound を経由しない名前解決に戻ります。
• Android： プライベート DNS を「オフ」または自動に戻します。

名前解決が止まると SSH の接続やパッケージの更新にも影響します。リモートのサーバーで作業するときは、コンソール接続など別の経路を確保してから始めると安心です。

まとめ

• DoT は端末からリゾルバーまでの区間を TLS で暗号化します。リゾルバーの運営者には内容が見えるため、ポリシーを確かめて切り替え先を選びます。
• Linux サーバーでは systemd-resolved の DNSOverTLS か、Unbound の forward-tls-upstream で切り替えられます。最初は日和見で試し、問題がなければ厳格に移します。
• DHCP から受け取った DNS や /etc/resolv.conf の置き換わりで、平文の問い合わせが残ることがあります。tcpdump で 53 番を観察して確かめます。
• 外向きの TCP 853 番が通るか、メールサーバーの DNSSEC 検証に影響がないかも合わせて確認します。

• パブリックDNSに切り替える手順
• DoT (DNS over TLS) と DNSSEC を併用する設定