EDNS0 が原因の障害は、「特定のドメインだけ名前解決が遅い・失敗する」「DNSSEC を使うドメインだけ SERVFAIL になる」という形で現れることが多く、全体が止まるわけではないため気づくのが遅れがちです。対応の流れは、影響範囲と直前の変更を確かめる初動、dig でのオプションを変えた比較による切り分け、バッファサイズと TCP の経路を整える暫定対応、監視と変更管理による再発防止の4段階です。この記事では、キャッシュDNS（リゾルバー）や権威DNSを運用している人が、障害発生時に順に進められる形で手順をまとめます。
症状から原因を探す一般的なトラブルシューティングは同じサイトの別記事で扱っています。ここでは「障害として起きている最中に、どう動くか」に重点を置きます。
EDNS0 で何が壊れやすいのか
EDNS0（RFC 6891）は、DNS メッセージに OPT レコードを付けて、UDP で受け取れるサイズ（バッファサイズ）や DNSSEC の DO ビットなどを伝える拡張です。DNSSEC の署名を含む応答は大きくなるため、EDNS0 は今の DNS に欠かせません。
壊れやすいのは主に次の3か所です。
- 大きな UDP 応答の断片化：応答が経路の MTU を超えると IP フラグメントに分かれ、途中のファイアウォールや NAT で落とされることがあります。
- TCP へのフォールバックの遮断：応答が大きすぎると TC ビット付きで切り詰められ、クライアントは TCP 53番で再問い合わせします。TCP 53番が閉じられていると、ここで失敗します。
- EDNS0 を正しく扱えない機器・サーバー：OPT レコード付きの問い合わせに応答しない、または FORMERR を返す古い権威DNSや、DNS を検査するセキュリティ機器が該当します。2019年の DNS Flag Day 以降、主要なリゾルバーはこうした相手への回避策を取りやめているため、相手側の問題がそのまま名前解決の失敗として表れます。
手順1：初動で確かめること
最初の数分で、次の3点を確かめます。慌てて設定を変える前に、状況を記録しておくことが後の切り分けを楽にします。
- 影響の範囲：すべてのドメインが引けないのか、一部だけか。一部なら、そのドメインに共通点（DNSSEC で署名されている、同じ DNS 事業者を使っている、応答に多数のレコードを含む）があるかを見ます。
- 影響を受けている場所：特定のリゾルバーやネットワークからだけ起きているのか。社内のリゾルバーでは失敗し、公開リゾルバーでは成功するなら、自分たちの側の経路や設定が疑わしくなります。
- 直前の変更：ファイアウォールのルール、ネットワーク機器のファームウェア、リゾルバーの版、VPN やトンネルの導入、DNSSEC の鍵の追加など。EDNS0 の障害は、応答サイズや経路の MTU を変える作業の直後に起きやすい傾向があります。
ここで分かったことは、時刻とともに障害記録に書き留めておきます。
手順2：dig のオプションを変えて切り分ける
失敗しているドメインについて、権威DNSに直接、条件を変えながら問い合わせます。比べることで、どの層で落ちているかが見えてきます。
# 権威DNSの一覧を確認
dig +short NS example.com
# 1. 標準的な EDNS0 付きの問い合わせ（再帰なし）
dig +norec @ns1.example.com example.com SOA
# 2. EDNS0 を付けない問い合わせ
dig +norec +noedns @ns1.example.com example.com SOA
# 3. DNSSEC 付きで大きめの応答を受ける
dig +norec +dnssec +bufsize=4096 @ns1.example.com example.com DNSKEY
# 4. 同じ問い合わせをバッファ 1232 で
dig +norec +dnssec +bufsize=1232 @ns1.example.com example.com DNSKEY
# 5. TCP で問い合わせる
dig +norec +dnssec +tcp @ns1.example.com example.com DNSKEY結果の読み方は次のとおりです。
- 1 が失敗し 2 が成功する：相手の権威DNSか経路上の機器が EDNS0 を扱えていません。相手側の問題である可能性が高く、手順3の「相手側の問題だった場合」に進みます。
- 3 がタイムアウトし 4 が成功する（または TC ビット付きで返る）：大きな UDP 応答が経路で落ちています。断片化したパケットがファイアウォールや NAT で破棄されている典型的なパターンです。
- 4 で TC ビットが立ち、5 が失敗する：TCP 53番が経路のどこかで閉じられています。
- すべて成功するのに、リゾルバー経由だと失敗する：リゾルバー自身の設定（バッファサイズ、上流への経路）を疑います。
EDNS のバージョン処理を確かめたい場合は dig +edns=1 を使います。正しく実装されたサーバーは BADVERS を返します。応答が無い場合は、EDNS0 の扱いに問題のあるサーバーです。
パケットの段階で確かめるときは、リゾルバー上で tcpdump を使います。
# DNS の通信と、IP フラグメントを表示する
sudo tcpdump -ni eth0 'port 53 or (ip[6:2] & 0x3fff != 0)'大きな応答の最初のフラグメントだけが届いて続きが来ない、TC ビットの後の TCP 接続が SYN だけで終わる、といった様子が見えれば、落ちている場所の見当がつきます。
手順3：暫定対応
自分のリゾルバーや経路が原因だった場合
作業前に設定ファイルをバックアップし、変更内容を記録してから進めます。
- バッファサイズを 1232 にする：断片化を避けるため、DNS Flag Day 2020 で推奨された 1232 バイトに合わせます。Unbound なら
edns-buffer-size: 1232、BIND ならoptionsの中でedns-udp-size 1232;とmax-udp-size 1232;を指定します。新しい版では既定値が 1232 になっていることもあるので、まず現在の値を確認してください（2026年10月現在）。 - TCP 53番を開ける：リゾルバーから外向き、権威DNSなら内向きの TCP 53番を許可します。DNS は UDP だけで足りるという前提の古いルールが残っていないかを見直します。
- 経路上の機器の DNS 検査を見直す：ファイアウォールの DNS インスペクション機能が、OPT レコードや大きな応答を不正とみなして落としていることがあります。機器の設定や版を確認し、必要ならベンダーの情報を参照します。
変更後は、手順2の dig を同じ順に再実行し、結果が変わったことを記録します。リゾルバーのキャッシュに失敗の結果が残っている場合は、対象ドメインのキャッシュを消してから確かめます（Unbound なら unbound-control flush_zone example.com など）。
相手側の問題だった場合
相手の権威DNSが EDNS0 を正しく扱えないときは、自分の側でできることは限られます。BIND には server 文で特定のサーバーに EDNS を使わない指定（edns no;）がありますが、DNSSEC の応答が受け取れなくなるなどの副作用があるため、あくまで一時的な措置にとどめます。基本は、相手のドメインの管理者や DNS 事業者に、dig の結果を添えて連絡することです。
自分の権威DNSの応答が大きすぎる場合
自分のドメインが一部のリゾルバーから引けないときは、応答サイズを減らす方向で対処します。BIND の minimal-responses yes; で余分なレコードを省く、DNSSEC の署名アルゴリズムを署名の小さい ECDSA（アルゴリズム13）にすることを中長期で検討する、などが選択肢です。アルゴリズムの変更は鍵の入れ替え作業を伴うため、障害対応の場では行わず、計画を立ててから実施します。
手順4：再発防止
障害が収まったら、同じことが起きたときに早く気づけるよう、仕組みを整えます。
- 監視：重要なドメインについて、
dig +dnssec +bufsize=1232とdig +tcpを定期的に実行し、失敗やタイムアウトを通知する監視を入れます。DNSSEC で署名された大きめの応答（DNSKEY など）を対象に含めるのがポイントです。 - 変更管理：ファイアウォールや VPN、ネットワーク機器の変更の確認項目に「大きな DNS 応答と TCP 53番が通ること」を加えます。
- 記録：初動から復旧までの時刻、原因、行った変更、効果を障害記録として残します。次に似た症状が出たときの手がかりになります。
まとめ
- EDNS0 の障害は「一部のドメインだけ」に出やすい。初動で影響範囲・影響を受けている場所・直前の変更を確かめる。
- dig で EDNS0 の有無、バッファサイズ、TCP を変えて比べると、相手側・断片化・TCP の遮断のどこが原因かを絞り込める。
- 自分の側の原因なら、バッファサイズを 1232 に、TCP 53番を開ける、経路の機器の DNS 検査を見直す。
- 相手側の原因なら、一時的な回避にとどめ、結果を添えて相手に連絡する。
- 監視と変更管理の確認項目に、大きな DNS 応答と TCP の経路を加えて再発を防ぐ。