EDNS0 と DANE を併用する設定：大きな DNSSEC 応答を通すリゾルバと MTA の構成

EDNS0 と DANE は、どちらか一方を選ぶものではなく、DANE を動かすために EDNS0 が正しく働いている必要がある、という関係です。DANE の TLSA レコードは DNSSEC の署名つきで受け取る必要があり、署名を要求する印（DO ビット）と大きな応答を受け取るための仕組みが EDNS0 だからです。この記事では、TLSA を公開する権威サーバー側、DANE を検証するメールサーバー側、その間のネットワークのそれぞれで、EDNS0 を前提にした設定と確認方法を説明します。

TLSA と証明書が合わない、といった DANE そのもののトラブルは、別記事（DANE のトラブルシューティング）で扱っています。こちらは「DNS の通り道」の設定に絞った内容です。

なぜ DANE には EDNS0 が要るのか

もともとの DNS は、UDP で運べる応答を 512 バイトまでに制限していました。EDNS0（RFC 6891）は、問い合わせに OPT という疑似レコードを付けて「この大きさまで UDP で受け取れる」と伝え、あわせて DNSSEC の署名を要求する DO ビット（RFC 3225）を運ぶための拡張です。

DANE で使う TLSA の応答には、レコード本体に加えて署名（RRSIG）が付きます。検証の過程では DNSKEY や DS も取得するため、512 バイトを超える応答は珍しくありません。EDNS0 が使えないと、署名を要求できないか、大きな応答を受け取れないため、DNSSEC の検証が成り立たず、結果として DANE も働きません。

応答が相手の申告したサイズを超える場合、サーバーは TC（切り詰め）フラグを立てて短い応答を返し、クライアントは TCP で問い合わせ直します。ここで TCP の 53 番が塞がれていると失敗します。また、大きな UDP パケットは途中で断片化され、断片を落とす機器があると届きません。こうした問題を減らすため、2020 年の DNS Flag Day では、EDNS のバッファサイズを 1232 バイト程度にすることが推奨されました。最近の主要な DNS ソフトウェアは、この値を既定にしているものが多くなっています。

権威サーバー側：TLSA を公開する側の設定

TLSA を公開する側では、次の3点を確認します。

1. ゾーンが DNSSEC で署名され、親ゾーンに DS が登録されている
2. EDNS の UDP サイズが過大でない（1232 前後）
3. UDP と TCP の両方で 53 番を受け付けている

BIND で明示的に設定する場合の例です。お使いの版で既定値が 1232 になっているなら、書かなくても動作は同じです。

// named.conf の options 内（例）
options {
    edns-udp-size 1232;
    max-udp-size 1232;
};

Knot DNS や PowerDNS にも同様の設定項目がありますが、名前と既定値は製品と版によって異なります（2026年10月現在）。各製品のリファレンスで「UDP の最大ペイロード」に当たる項目を確認してください。マネージド DNS を使っている場合、この部分は事業者が管理しています。

ファイアウォールでは、UDP の 53 番だけを開けて TCP を閉じている構成がいまも見られます。TC フラグからの TCP 再送が成立しないと、大きな応答だけが失敗するので、TCP の 53 番も受け付けるようにします。

権威サーバーの応答を確かめる

権威サーバーに直接、署名つきの TLSA を問い合わせて、サイズと TC フラグを確認します。

# EDNS バッファ 1232 で、署名つきの TLSA を権威サーバーに直接聞く
dig @ns1.example.com _25._tcp.mx1.example.com TLSA +dnssec +bufsize=1232 +norecurse

# TCP でも同じ応答が返るか
dig @ns1.example.com _25._tcp.mx1.example.com TLSA +dnssec +tcp +norecurse

# 小さいバッファを申告したとき TC フラグが立つか（+ignore で TCP に切り替えずに表示）
dig @ns1.example.com example.com DNSKEY +dnssec +bufsize=512 +ignore +norecurse

1つ目の出力の末尾にある MSG SIZE rcvd が応答の大きさです。OPT PSEUDOSECTION に EDNS: version: 0 と udp: の値が表示されていれば、サーバーが EDNS0 に応答しています。3つ目で flags: に tc が付けば、切り詰めと TCP への切り替えの仕組みが期待どおりに働いています。2つ目の TCP の問い合わせがタイムアウトする場合は、ファイアウォールを見直します。

送信側メールサーバー：検証するリゾルバを手元に置く

DANE を検証するのは、メールを送る側の MTA です。ここでの要点は、MTA が使うリゾルバが DNSSEC を検証し、その結果（AD フラグ）を MTA まで正しく届けることです。MTA は自分では署名を検証せず、リゾルバの AD フラグを信用します。そのため、リゾルバは同じサーバー上（127.0.0.1）に置くのが推奨されます。遠くのリゾルバの AD フラグは、途中で書き換えられても気づけないからです。

Unbound を検証リゾルバとして置く

# /etc/unbound/unbound.conf の例（配布パッケージの既定ファイルと重複する項目は調整する）
server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    edns-buffer-size: 1232

auto-trust-anchor-file はルートゾーンの鍵（トラストアンカー）を自動更新するための設定です。Debian 系などでは、パッケージがすでに同等の設定を入れていることがあるので、二重に書かないよう既存の設定ファイルを確認してください。edns-buffer-size も最近の Unbound では 1232 が既定です。

resolv.conf で AD フラグを通す

見落とされやすいのがこの点です。glibc 2.31 以降は、resolv.conf に trust-ad オプションがないと、リゾルバから受け取った AD フラグをアプリケーションに渡す前に消してしまいます。これでは MTA から見ると「どの応答も検証されていない」ことになり、DANE が使われません。

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

systemd-resolved や NetworkManager が resolv.conf を自動生成している環境では、直接書き換えても上書きされます。OS の方法に従って、ローカルの Unbound を参照し、かつ trust-ad が付く構成にしてください。

Postfix で DANE を有効にする

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

smtp_dns_support_level = dnssec で、Postfix は DNSSEC の検証結果を求める問い合わせ（EDNS0 の DO ビット付き）を行います。smtp_tls_security_level = dane で、相手先に検証済みの TLSA があればそれに従って証明書を照合し、なければ通常の日和見的な TLS（使えれば暗号化）で送ります。設定後は postfix check で構文を確認してから postfix reload で反映します。Exim など他の MTA にも DANE の設定がありますが、設定方法は各 MTA のドキュメントを確認してください。

動作を確認する

まず、ローカルのリゾルバが検証して AD フラグを返しているかを見ます。

# ローカルの Unbound で、DNSSEC 署名つきのドメインを引く（ad が付くか）
dig @127.0.0.1 _25._tcp.mx1.example.com TLSA +dnssec

# 署名を意図的に壊したテスト用ドメインで SERVFAIL になるか
dig @127.0.0.1 dnssec-failed.org A

1つ目で ad が付き、2つ目で SERVFAIL になれば、リゾルバは検証しています（2つ目のテスト用ドメインの提供状況は変わる場合があります）。そのうえで、Postfix 付属の posttls-finger を -l dane 付きで実行すると、送信側から見た TLSA の取得と証明書の照合を試せます。

有効にしたあとに気をつけること

smtp_tls_security_level = dane にすると、TLSA の設定を誤っている相手先へのメールは、送れずにキューにたまります。これは DANE が意図どおりに働いた結果ですが、WordPress の通知メールやフォームの自動返信がローカルの Postfix 経由で送られている場合、一部の宛先だけ届かない、という形で表に出ます。有効化の直後は postqueue -p でキューを確認し、ログの理由を読んで、相手側の問題か自分側の問題かを切り分けてください。

切り分けの際に「EDNS を無効にすれば通る」という対処を見かけることがありますが、EDNS を止めると DO ビットも送れなくなり、DNSSEC の検証と DANE がまとめて止まります。問題のある経路や相手を特定して直すのが本筋です。

設定変更の前には main.cf と unbound.conf のバックアップを取り、可能ならステージング用の MTA で数日動かしてから本番に反映すると安全です。

まとめ

• DANE は DNSSEC の検証済み TLSA を前提とし、その DNSSEC は EDNS0（DO ビットと大きな応答）を前提とする
• 権威サーバー側は、EDNS の UDP サイズを 1232 前後にし、UDP と TCP の両方で 53 番を受け付ける
• 送信側は、検証リゾルバを 127.0.0.1 に置き、resolv.conf に trust-ad を付けて AD フラグを MTA まで通す
• Postfix は smtp_dns_support_level = dnssec と smtp_tls_security_level = dane の組み合わせで DANE を使う
• 有効化後はメールキューを監視し、EDNS を無効にして回避するような対処は避ける

• dig コマンドで DNS の問題を調べる方法
• BIND で DNS サーバーを構築する方法