2026年6月16日

DANE と DoT (DNS over TLS) を併用する設定｜送信メールサーバーの名前解決を DoT で暗号化しつつ、DNSSEC の検証を手元で行う

DNS・名前解決

DANE と DoT を併用するときの要点は、「DoT は問い合わせの経路を暗号化するもの、DNSSEC の検証は手元のリゾルバーで行うもの」と役割を分けることです。メールサーバーと同じホストに DNSSEC を検証する Unbound を置き、上流への問い合わせだけを DoT で送り、Postfix にはその Unbound を参照させる構成にすると、DANE の照合に必要な検証結果（AD ビット）を正しく受け取りながら、宛先ドメインの問い合わせを経路上で読まれにくくできます。この記事では、その構成の設定、AD ビットが Postfix まで届かない典型的な原因、動作の確認方法を説明し、最後に DoT サーバー自身の証明書を TLSA で公開する話にも触れます。

2つの仕組みの役割を整理する

DANE（SMTP では RFC 7672）は、受信側のメールサーバーの証明書や公開鍵の指紋を、DNSSEC で署名された TLSA レコードとして公開し、送信側に照合させる仕組みです。送信側のメールサーバーにとっては、「TLSA レコードが本物であることを、DNSSEC の検証で確かめられること」が前提になります。

DoT（RFC 7858）は、DNS の問い合わせと応答を TLS で暗号化する仕組みです。経路上の第三者から問い合わせの中身を読まれたり、書き換えられたりするのを防ぎます。ただし、DoT は「接続先のリゾルバーとの通信路」を守るだけで、応答の内容が本物かどうかは保証しません。

つまり、DoT は DNSSEC の検証の代わりにはなりません。DANE を使うなら DNSSEC の検証は欠かせず、DoT はそこに「どのドメインにメールを送っているかを経路上で見られにくくする」効果を足すものです。この記事で扱うのは、主に送信側のメールサーバーでの併用です。

構成の全体像

Postfix ── 127.0.0.1:53 ── Unbound（DNSSEC 検証・キャッシュ）── TCP 853（DoT）── 上流のリゾルバー

検証を Unbound で行うのは、上流から届いた AD ビットをそのまま信じるより、自分のホストで検証したほうが信頼の範囲がはっきりするためです。Unbound は、上流へ転送して得た応答も、トラストアンカーが設定されていれば自分で検証し、成功したときだけ AD ビットを付けて Postfix に返します。逆に、トラストアンカーを設定していない Unbound は検証をしないため、上流が AD ビットを付けていても Postfix には届きません。

Unbound の設定

作業前に既存の設定ファイルをバックアップします。次の例では、上流に公開リゾルバーの DoT を使っています。上流のアドレスと TLS の認証名（# の後ろ）は、利用する事業者の案内で確認してください（2026年10月現在の例です）。

# /etc/unbound/unbound.conf.d/dane-dot.conf（例）
server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow
    # DNSSEC 検証のトラストアンカー（配布パッケージで設定済みのことが多い）
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    # DoT の上流の証明書を検証するための CA 証明書
    tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"
    # 大きな DNSSEC 応答に備える
    edns-buffer-size: 1232

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 9.9.9.9@853#dns.quad9.net
    forward-addr: 149.112.112.112@853#dns.quad9.net

設定のポイントは次のとおりです。

トラストアンカー：Debian や Ubuntu の unbound パッケージでは、auto-trust-anchor-file が別のファイルですでに設定されていることがあります。二重に書くとエラーになるため、/etc/unbound/unbound.conf.d/ の既存ファイルを確認してから追加します。
**tls-cert-bundle**：これがないと上流の証明書を検証できず、DoT の接続に失敗します。パスはディストリビューションによって異なります。
認証名：@853 の後ろの #dns.quad9.net が、上流の証明書と照合するホスト名です。省略すると、通信は暗号化されても相手が本物かどうかを確かめられません。
上流は複数並べる：DoT の上流に接続できないと、平文の DNS には戻らず名前解決が失敗します。メールの配送が止まらないよう、複数のアドレスを指定します。

sudo unbound-checkconf
sudo systemctl restart unbound

Postfix の設定

送信側で DANE を使うには、main.cf に次の2行を設定します。

# /etc/postfix/main.cf
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

smtp_dns_support_level = dnssec は、Postfix が DNS の応答の AD ビットを見て、検証済みの情報かどうかを区別するための設定です。smtp_tls_security_level = dane は、相手が TLSA を公開していれば DANE で照合し、公開していなければ通常の日和見的な TLS で送る指定です。

sudo cp /etc/postfix/main.cf /etc/postfix/main.cf.bak.$(date +%F)
sudo postfix check && sudo postfix reload

AD ビットが Postfix に届かない典型的な原因

設定したのに DANE が効かない場合の多くは、AD ビットが途中で失われていることが原因です。次の順に確認します。

1. resolv.conf が Unbound を向いていない

Postfix は OS のリゾルバーの設定（/etc/resolv.conf）に従って問い合わせます。systemd-resolved が動いている環境では、/etc/resolv.conf が 127.0.0.53 を向いていることがあり、その場合 Postfix の問い合わせは Unbound を通りません。systemd-resolved を経由すると AD ビットが期待どおりに渡らない場合があるため、Postfix からは Unbound（127.0.0.1）を直接参照させるのが分かりやすい構成です。systemd-resolved と Unbound が同じポートを取り合わないことも確認します。

2. glibc の trust-ad オプションがない

glibc 2.31 以降では、/etc/resolv.conf に options trust-ad を書かないと、アプリケーションに AD ビットが渡りません。Postfix の文書でも、この設定の必要性が説明されています。

# /etc/resolv.conf
nameserver 127.0.0.1
options trust-ad

/etc/resolv.conf を別の仕組み（NetworkManager や netplan、systemd-resolved など）が自動生成している場合は、直接書き換えても上書きされます。その仕組みの設定から変更してください。

3. chroot 内の resolv.conf が古い

Debian 系の Postfix は、一部のプロセスを chroot の中で動かす設定になっていることがあり、その場合は /var/spool/postfix/etc/resolv.conf が使われます。ホスト側の /etc/resolv.conf を変更したら、chroot 内のファイルにも反映されているかを確認します。Postfix の再起動時にコピーされる仕組みのことが多いですが、環境によって異なります。

動作を確認する

まず Unbound 単体で、検証と DoT の転送が働いているかを確かめます。

# 検証に成功していれば flags に ad が付く
dig @127.0.0.1 +dnssec _25._tcp.mail.example.org TLSA

# わざと署名を壊してあるテスト用ドメインでは SERVFAIL になるのが正しい動作
dig @127.0.0.1 dnssec-failed.org A

# 転送先の一覧を表示する
sudo unbound-control list_forwards

テスト用ドメインは第三者が提供しているもので、提供状況が変わることがあります。unbound-control を使うには、事前に unbound-control-setup などで制御用の設定を有効にしておく必要があります。上流との通信が暗号化されているかは、外向きのインターフェースで sudo tcpdump -ni eth0 'port 53 or port 853'（インターフェース名は環境に合わせる）を実行し、外へ出る DNS の通信が 853 番だけになっているかを見ると確かめられます。

次に、Postfix の立場で確かめます。posttls-finger に DANE 対応のドメインを渡すと、TLSA の取得と照合の結果を表示します。

posttls-finger -c -l dane example.org

実際の配送ログでは、DANE で照合できた接続は Verified TLS connection established のように記録されます。DNSSEC の検証結果を受け取れていない場合は、起動時や配送時に、DNSSEC の検証が使えない可能性があるという趣旨の警告が出ることがあります。文言は Postfix の版で異なるため、dnssec や DANE で絞り込んでログを探します。

補足：DoT サーバー自身の証明書を TLSA で公開する

自分で DoT のリゾルバーを提供している場合、そのサーバーの証明書を TLSA で公開する方法もあります。DoT の認証方法を定めた RFC 8310 は、認証の手段の1つとして DANE を挙げています。

; DoT サーバーの公開鍵を TLSA で公開する例（値はダミー）
_853._tcp.dns.example.com. 3600 IN TLSA 3 1 1 aaaa...

ただし、DoT の接続時に TLSA で証明書を照合するクライアントは限られています（2026年10月現在）。多くの端末は通常の CA による証明書の検証を行うため、TLSA を公開する場合も、公開 CA の証明書は引き続き使います。TLSA を公開したら、証明書の鍵を替えるたびに TLSA も更新する必要がある点に注意してください。

まとめ

DoT は通信路を暗号化するもので、DNSSEC の検証の代わりにはならない。DANE の前提となる検証は手元の Unbound で行う
Unbound にトラストアンカーと tls-cert-bundle を設定し、上流を認証名付きで複数指定して DoT で転送する
Postfix は smtp_dns_support_level = dnssec と smtp_tls_security_level = dane を設定し、Unbound を直接参照させる
AD ビットが届かない原因は、resolv.conf の参照先、glibc の trust-ad、chroot 内の resolv.conf の順に確認する
dig の ad フラグ、posttls-finger、配送ログの Verified の記録で、検証と照合が働いているかを確かめる