EDNS0 まわりの不具合は、「特定のドメインだけ名前解決に数秒かかる」「DNSSEC を使うドメインだけ SERVFAIL になる」「SPF の TXT レコードだけ引けない」といった、一部だけがおかしい症状として現れます。原因の多くは、TCP の 53 番の遮断、大きな UDP 応答の断片の破棄、経路上の機器による DNS の検査の3つで、dig の結果を3通り比べると、どこに問題があるかをかなり絞り込めます。この記事では、困っている側（サーバーや社内のリゾルバーの運用者）の立場から、症状の見方、ログと通信の読み方、原因ごとの確認と対処を、起きやすい順に説明します。
権威 DNS が EDNS0 を規格どおりに扱うかを一通り検証する手順は別の記事で扱っているため、ここでは「いま起きている不具合を直す」ことに絞ります。
EDNS0 の不具合が起きる仕組み
EDNS0（RFC 6891）は、DNS の問い合わせに OPT という疑似レコードを付け、512 バイトを超える UDP 応答を受け取れることや、DNSSEC の署名がほしいこと（DO ビット）を相手に伝える拡張です。現在のリゾルバーは、ほぼすべての問い合わせに EDNS0 を付けます。
応答が申告したサイズに収まらない場合、サーバーは TC（切り詰め）フラグを立てた短い応答を返し、リゾルバーは TCP で問い合わせ直します。つまり、正しく動くためには次の3つが成り立っている必要があります。
- OPT 付きの問い合わせと応答が、経路上の機器で捨てられたり書き換えられたりしない
- 申告したサイズの UDP 応答が、断片化されても届く（または断片化しないサイズに抑えられている）
- TC が返ったときに、TCP の 53 番で問い合わせ直せる
以前は、EDNS0 に正しく答えない相手に対して、リゾルバーが EDNS0 を外して再送する回避策を持っていました。2019 年の DNS Flag Day で主要なリゾルバーがこの回避策をやめ、2020 年には UDP のバッファサイズを 1232 バイト前後にする方針が示されています。そのため、昔は「遅いけれど引けていた」環境が、ソフトウェアの更新をきっかけに「引けない」に変わることがあります。
まず症状を3つの dig で切り分ける
問題が起きているサーバー（WordPress を動かしている Web サーバーや、社内のリゾルバーそのもの）で、次の3つを実行して結果を比べます。対象には、実際に引けないドメインと、DNSSEC で署名された大きめの応答が返るものを選びます。
# 1. ふだんどおりの問い合わせ（使っているリゾルバー経由）
dig +dnssec example.org DNSKEY
# 2. TCP で問い合わせる
dig +dnssec +tcp example.org DNSKEY
# 3. 小さいバッファを申告し、断片化しないサイズに抑える
dig +dnssec +bufsize=1232 example.org DNSKEY結果の組み合わせから、疑う場所の見当をつけます。
- 1 が遅い・失敗し、2 は成功する：UDP の大きな応答か、その断片が落ちています。「原因2」を疑います。
- **2 が失敗し、
dig +dnssec +bufsize=512 +ignore example.org DNSKEYではflags:にtcが付いた応答が返る**：UDP の応答は届いているのに、TCP で取り直せていません。「原因1」を疑います。+ignoreは、TC を受け取っても TCP で再送しない指定です。 - **3 は成功し、
+bufsize=4096で失敗する**：経路のどこかで断片が捨てられています。「原因2」です。 - すべて失敗するが、別のネットワーク（スマートフォンのテザリングなど）からは成功する：社内の機器が DNS を検査・中継している可能性があります。「原因3」です。
さらに、使っているリゾルバーを飛ばして公開リゾルバーに直接聞くと、リゾルバー側の問題かどうかが分かります。
dig @1.1.1.1 +dnssec example.org DNSKEY
dig @1.1.1.1 +dnssec +tcp example.org DNSKEY公開リゾルバーでは成功し、社内のリゾルバーでは失敗するなら、問題は社内のリゾルバーか、そこから外への経路にあります。公開リゾルバーでも失敗するなら、相手の権威 DNS 側の問題（原因4）の可能性が高くなります。
ログと通信を読む
リゾルバーのログ
dig の結果だけで判断がつかない場合は、リゾルバーのログを見ます。
- Unbound：
log-servfail: yesを設定すると、SERVFAIL を返した理由がログに出ます。より詳しく見るときはverbosityを一時的に上げます。ログが大量に出るため、調査が終わったら元に戻します。 - BIND：ロギングのカテゴリー
edns-disabledは、タイムアウトなどが原因で EDNS0 なしの問い合わせに切り替えた記録を出します。lame-serversカテゴリーにも、応答の異常が記録されることがあります。 - systemd-resolved：
journalctl -u systemd-resolvedに、サーバーの対応機能を下げて問い合わせた（degraded feature set）という趣旨のメッセージが出ることがあります。
ログの文言はソフトウェアの版によって異なるため、ドメイン名やサーバーのアドレスで絞り込んで探すと見つけやすいです。
また、新しめの dig は、応答に含まれる拡張エラー（EDE、RFC 8914）を EDE: として表示します。No Reachable Authority（権威 DNS に到達できない）や DNSSEC の検証失敗を示すものなど、SERVFAIL の理由を知る手がかりになります。
パケットを見る
ログでも分からない場合は、リゾルバーが外へ出す問い合わせと、返ってくる応答を tcpdump で見ます。
# DNS の通信と、IPv4 の断片パケットをまとめて表示する
sudo tcpdump -ni any 'port 53 or (ip[6:2] & 0x3fff != 0)'確認するのは次の点です。
- UDP の応答に TC を示す印（tcpdump では問い合わせ ID の後ろの
|など。表示は版で異なります）があるか、そのあと TCP の 53 番への接続が出ているか - 断片の最初の部分だけ届いて、残りが届いていないように見えないか
- 問い合わせを送っているのに、応答がまったく返ってこないか
IPv6 の断片は別の書き方が必要になるため、IPv6 で問題が出ている場合は ip6 を対象にしたフィルタを使います。
原因1：TCP の 53 番が閉じている
もっとも多い原因です。UDP の 53 番だけを許可したファイアウォールは今も珍しくありませんが、大きな応答は TCP での取り直しが前提です。
確認：dig +tcp がタイムアウトするかどうかを、問題のサーバーから直接試します。リゾルバーを自前で運用している場合は、リゾルバーのホストから外部の権威 DNS に対して試します。
# ルートサーバーに TCP で問い合わせる（外向きの TCP 53 番が通るかの確認）
dig +tcp +norecurse @a.root-servers.net . SOA対処：リゾルバーのホストから外向きの TCP 53 番を許可します。権威 DNS を運用している側なら、内向きの TCP 53 番を許可します。サーバー上のファイアウォール（ufw や firewalld など）だけでなく、クラウドのセキュリティグループや、ネットワーク境界のファイアウォールも確認します。設定を変える前に現在のルールを控えておきます。
原因2：大きな UDP 応答の断片が捨てられている
UDP の応答が経路の MTU を超えると、IP のレベルで断片化されます。断片を捨てるファイアウォールや、断片を正しく扱えない NAT 機器があると、大きな応答だけが届きません。
確認：+bufsize=1232 では成功し、+bufsize=4096 では失敗する、という差があれば、ほぼこの原因です。
対処：リゾルバーが申告するバッファサイズを 1232 バイトに下げます。最近の Unbound や BIND は既定値がこの値になっていますが（2026年10月現在）、古い設定ファイルで大きな値を指定したままのこともあります。
# Unbound（unbound.conf の server: 節）
server:
edns-buffer-size: 1232
# BIND（named.conf の options 節）
options {
edns-udp-size 1232;
max-udp-size 1232;
};変更後に設定の構文を確認し（unbound-checkconf や named-checkconf）、再読み込みしてから最初の3つの dig をもう一度実行します。
原因3：経路上の機器が DNS を検査・中継している
古いファイアウォールの DNS 検査機能や、家庭用・小規模オフィス向けルーターの DNS 中継機能が、512 バイトを超える DNS メッセージや OPT 付きの問い合わせを捨てたり、書き換えたりすることがあります。
確認：その機器を経由しないネットワークから同じ問い合わせをして、結果が変わるかを見ます。端末の DNS の設定がルーターのアドレスになっている場合は、ルーターを飛ばして社内のリゾルバーや公開リゾルバーを直接指定して比べます。
対処：機器の DNS 検査で許可するメッセージの最大長を引き上げる、DNS 検査を無効にする、ファームウェアを更新する、といった方法があります。設定項目の名前や場所は機種ごとに違うため、製品の文書を確認してください。手早い回避策としては、端末やサーバーの DNS の参照先を、ルーターではなく正しく動くリゾルバーに直接向ける方法があります。
原因4：相手の権威 DNS が EDNS0 を正しく扱わない
どのリゾルバーから聞いても特定のドメインだけ失敗する場合は、そのドメインの権威 DNS 側の問題です。
確認：権威 DNS に直接、EDNS0 ありとなしで問い合わせます。
dig +short example.org NS
dig @ns1.example.net +norecurse +edns=0 example.org SOA
dig @ns1.example.net +norecurse +noedns example.org SOAEDNS0 なしでは答えるのに EDNS0 付きだとタイムアウトする、FORMERR が返る、といった場合は相手側の実装か、相手側の機器の問題です。
対処：根本的な対処は相手にしかできないため、上の dig の出力を添えてドメインの管理者や DNS 事業者に連絡します。自前の BIND がリゾルバーの場合は、server 文でそのサーバーに限って EDNS0 を使わない設定もできますが、そのサーバーからは DNSSEC の署名を受け取れなくなるなどの副作用があるため、一時的な回避にとどめます。
// named.conf：特定の権威 DNS に限って EDNS0 を無効にする（一時的な回避）
server 192.0.2.53 {
edns no;
};ほかのリゾルバーで同様の個別設定ができるかどうかは、ソフトウェアの文書で確認してください。
原因5：端末側の DNS クライアントの設定や状態
サーバー自身の名前解決だけがおかしい場合は、OS 側も確認します。
- systemd-resolved：一度問題が起きたサーバーに対して、機能を下げた状態のまま問い合わせ続けることがあります。原因を直したあとは
resolvectl reset-server-featuresで状態を戻し、resolvectl flush-cachesでキャッシュを消します。 - glibc のスタブ：
/etc/resolv.confのoptions edns0は、アプリケーションの問い合わせに EDNS0 を付ける指定です。大きな応答を扱うアプリケーションで問題が出る場合に、有無を確認します。 - Docker などのコンテナ：コンテナ内の名前解決は、コンテナ基盤の DNS 中継を通ることがあります。ホストでは成功しコンテナでは失敗する場合は、中継部分を疑います。
WordPress の画面で外部 API への接続が名前解決の段階で失敗している場合も、サーバー上で上記の dig を実行すると、DNS の問題かどうかを切り分けられます。
直したあとの確認
対処のあとは、最初の3つの dig と、公開リゾルバーとの比較をもう一度行い、すべてが同じ結果になることを確かめます。社外からも同じ確認をすると、見落としを減らせます。調査のために上げたログの詳細度は元に戻し、ファイアウォールやリゾルバーの設定変更は、変更前の内容と変更理由を記録しておきます。DNS の設定は影響範囲が広いため、可能であれば検証環境で試してから本番に反映してください。
まとめ
- EDNS0 の不具合は「一部のドメインだけ遅い・引けない」として現れ、通常・TCP・小さいバッファの3つの dig を比べると原因の見当がつく
- 起きやすい順に、TCP の 53 番の遮断、大きな UDP 応答の断片の破棄、経路上の機器の DNS 検査を疑う
- リゾルバーのログ（Unbound の
log-servfail、BIND のedns-disabled）と tcpdump で、どこで止まっているかを確かめる - バッファサイズは 1232 バイトに下げ、TCP の 53 番を通すことが基本の対処になる
- 相手の権威 DNS が原因なら、dig の出力を添えて管理者に連絡し、自分の側の回避策は一時的なものにとどめる