DNSSEC は EDNS0 なしでは動きません。署名付きの応答は大きくなるため、EDNS0 で扱える UDP サイズを適切な値（目安は 1232 バイト）にそろえ、収まらない応答は TCP で取り直せるようにしておくことが、併用設定の中心です。この記事では、EDNS0 と DNSSEC の関係を押さえたうえで、権威 DNS とリゾルバの設定例、ファイアウォールで起きがちな問題、dig を使った確認方法を説明します。DNSSEC の署名を有効にする手順そのものは別の記事の範囲とし、ここでは「署名した後に応答が届かない・遅い」を防ぐ転送部分に絞ります。
EDNS0 と DNSSEC の関係
元の DNS 仕様では、UDP の応答は 512 バイトまでに制限されていました。EDNS0（RFC 6891）は、問い合わせに OPT という疑似レコードを付けて「この大きさまでなら UDP で受け取れる」と相手に伝える拡張です。DNSSEC で使う DO ビット（署名を返してほしいという合図）も、この OPT レコードの中に置かれます。つまり EDNS0 を通さない経路では、DNSSEC の署名を受け取ることができません。
DNSSEC を有効にすると、応答に RRSIG（署名）が付き、DNSKEY の問い合わせでは公開鍵の一覧が返ります。特に RSA の鍵を使っている場合や、鍵の交換中で鍵が複数並んでいる場合には、応答が 1,000 バイトを超えることも珍しくありません。
UDP サイズを大きくしすぎない理由
以前は EDNS0 のバッファサイズとして 4096 バイトが広く使われていました。しかし、経路の MTU を超える UDP パケットは IP フラグメントに分割され、フラグメントは途中の機器で落とされやすく、偽のフラグメントを差し込む攻撃にも使われます。そこで 2020 年の DNS Flag Day では、フラグメントが起きにくい 1232 バイトが推奨値として示されました。近年の BIND、Unbound、PowerDNS などの主要実装は、既定値をこの付近に変えています（2026年10月現在）。正確な既定値と変更された版は、各ソフトのリリースノートで確認してください。
1232 バイトに収まらない応答は、TC（切り詰め）フラグ付きで返され、問い合わせ側は TCP で取り直します。このため、併用設定では「UDP サイズを控えめにする」と「TCP 53 番を通す」がセットになります。
権威 DNS 側の設定
自前で権威 DNS を運用している場合の設定例です。変更前には設定ファイルをバックアップし、構文チェックをしてから再読み込みしてください。
BIND の例
options {
// 自分が送る UDP 応答の上限
max-udp-size 1232;
// 自分がリゾルバとして問い合わせるときに広告するサイズ
edns-udp-size 1232;
};sudo named-checkconf && sudo rndc reconfig新しめの BIND では既定値がすでに 1232 になっているため、明示しなくても同じ動作になることがあります。明示しておくと、将来の既定値変更や設定の引き継ぎで意図がはっきりします。
マネージド DNS の場合
Cloudflare、Amazon Route 53 などのマネージド DNS では、EDNS0 のサイズや TCP 対応は事業者側で管理されており、利用者が設定する項目は基本的にありません。利用者側でできるのは、署名アルゴリズムを選べる場合に小さな署名で済むものを選ぶこと、後述の確認コマンドで実際の応答を見ることです。
応答を小さく保つ工夫
- 署名アルゴリズムに ECDSA P-256（アルゴリズム番号 13）や Ed25519（15）を使う。RSA より署名と鍵が短く、応答が小さくなります。
- 鍵の交換は長引かせない。新旧の鍵が並ぶ期間は DNSKEY 応答が大きくなります。
- 1つの名前に大量の TXT レコードなどを並べない。
リゾルバ側の設定
社内やサーバー上で DNSSEC を検証するリゾルバを動かす場合も、同じ考え方です。Unbound の例を示します。
server:
edns-buffer-size: 1232
# DNSSEC 検証を有効にする（パッケージによっては別ファイルで設定済み）
module-config: "validator iterator"
auto-trust-anchor-file: "/var/lib/unbound/root.key"sudo unbound-checkconf && sudo systemctl reload unboundtrust anchor ファイルの場所はディストリビューションのパッケージによって異なり、Debian 系では別の設定ファイルで有効化されていることがあります。二重に指定するとエラーになるため、既存の設定を確認してから追記してください。
ファイアウォールと経路で起きる問題
EDNS0 と DNSSEC の併用で起きる障害の多くは、DNS ソフトではなく途中の機器が原因です。起きやすい順に挙げます。
- TCP 53 番が閉じている: 「DNS は UDP だけ」という前提でルールを書いていると、TC 付きの応答の後の取り直しが失敗します。権威 DNS とリゾルバの両方で、TCP 53 番の受信と送信を許可します。
- 大きな UDP パケットや OPT 付きパケットを落とす機器: 古いファイアウォールや DNS 検査機能の中には、512 バイトを超える DNS パケットを不正とみなすものがあります。機器の DNS 検査設定やファームウェアを確認します。
- IP フラグメントの破棄: バッファサイズを 4096 のままにしていると、フラグメントが落とされて応答が届かず、タイムアウトを待ってから再送する動きになります。体感では「ときどき名前解決が数秒遅い」として現れます。
dig で確認する
以下はすべて、自分のドメインに置き換えて実行します。権威サーバーへ直接問い合わせる場合は @ns1.example.com のように指定します。
# 1) EDNS0 と DO ビット付きで問い合わせ、OPT の内容と応答サイズを見る
dig +dnssec +bufsize=1232 example.com DNSKEY @ns1.example.com
# 2) 切り詰められたときに TCP で取り直さず、TC が付くかだけを見る
dig +dnssec +bufsize=512 +ignore example.com DNSKEY @ns1.example.com
# 3) TCP で問い合わせできるか
dig +dnssec +tcp example.com DNSKEY @ns1.example.com1つ目の出力では、OPT PSEUDOSECTION に EDNS: version: 0, flags: do; udp: 1232 のような行が出ること、末尾の MSG SIZE rcvd が応答の大きさであることを確認します。2つ目で flags に tc が付けば、小さなバッファでは収まらない応答だと分かります。3つ目が失敗する場合は、TCP 53 番が経路のどこかで止められています。
検証するリゾルバ経由での確認には、dig +dnssec example.com A @1.1.1.1 の応答で flags に ad が付くかを見ます。SERVFAIL が返り、+cd（検証を無効にする指定）を付けると答えが返る場合は、署名そのものか DS の登録に問題があります。その場合は DNSViz などで信頼の連鎖を可視化すると原因を絞り込みやすくなります。
まとめ
- DNSSEC の DO ビットは EDNS0 の OPT レコードに載るため、EDNS0 を通せない経路では DNSSEC が働かない
- UDP バッファサイズは 1232 バイトを目安にし、4096 のような大きな値によるフラグメントを避ける
- 収まらない応答は TCP で取り直すので、TCP 53 番の許可は欠かせない
- 署名アルゴリズムは ECDSA P-256 や Ed25519 を選ぶと応答が小さくなる
- dig の
+bufsize・+ignore・+tcpで、サイズ・切り詰め・TCP の3点を順に確認する