2026年6月14日

EDNS0 の検証手順｜権威DNS・リゾルバー・経路の機器が EDNS0 を正しく扱うかを dig で確かめる

DNS・名前解決

EDNS0 が正しく扱われているかは、dig で「EDNS0 付きの問い合わせに OPT 付きで答えるか」「知らないバージョン・オプション・フラグを正しく扱うか」「大きな応答が UDP と TCP の両方で届くか」の3点を順に試すと確かめられます。この記事では、自分のドメインの権威 DNS や社内のリゾルバーを対象に、それぞれの確認コマンドと、結果の読み方、失敗したときに疑う場所を説明します。EDNS0 の設定値（バッファサイズや DNS Cookie など）を決める話は別の記事に譲り、ここでは「今の状態が正しいか」を検証する手順に絞ります。

なぜ EDNS0 を検証するのか

EDNS0（RFC 6891）は、DNS メッセージに OPT という疑似レコードを付けて、512 バイトを超える UDP 応答や DNSSEC の DO ビットなどを運べるようにする拡張です。現在のリゾルバーは EDNS0 を前提に問い合わせます。

かつては、EDNS0 に正しく答えない権威 DNS に対して、リゾルバー側が「EDNS0 を外して問い合わせ直す」回避策を持っていました。2019 年の DNS Flag Day で主要なリゾルバーがこの回避策をやめたため、EDNS0 の付いた問い合わせを捨てる権威 DNS やファイアウォールがあると、そのドメインは名前解決に時間がかかる、または引けなくなります。さらに 2020 年の DNS Flag Day では、UDP の断片化を避けるためにバッファサイズを 1232 バイト前後にそろえ、それを超える応答は TCP で取り直す方針が示されました。

つまり検証で見るべきなのは、DNS サーバーのソフトウェアだけではありません。サーバーの手前にあるファイアウォール、ロードバランサー、クラウドのセキュリティ機能も含めた「経路全体」が EDNS0 を通すかどうかです。

準備：対象と環境をそろえる

検証する相手を決める

権威 DNS を検証するときは、ドメインの NS レコードに載っているサーバーを1台ずつ、IPv4 と IPv6 の両方で確かめます。1台だけ古い設定が残っている、という例は珍しくありません。
リゾルバー（キャッシュ DNS） を検証するときは、端末が実際に使っているアドレスを対象にします。

# 権威 DNS の一覧を取得する（example.com は自分のドメインに置き換える）
dig +short example.com NS

# 各ネームサーバーの IPv4 / IPv6 アドレス
dig +short ns1.example.net A
dig +short ns1.example.net AAAA

使う道具

BIND 9.18 以降に付属する dig を前提にします（2026年10月現在）。古い dig では一部のオプションがないため、dig -v で版を確認してください。権威 DNS への問い合わせには +norec（再帰を求めない）を付けます。付けないと、権威専用のサーバーが REFUSED を返して結果が読みにくくなります。

検証は、できれば社外のネットワーク（クラウド上の VPS など）からも行います。社内からだけ試すと、社内のファイアウォールやプロキシの影響と、サーバー側の問題を区別できません。

手順1：EDNS0 付きの問い合わせに OPT 付きで答えるか

まず、もっとも基本的な確認です。

dig @ns1.example.net +norec +edns=0 example.com SOA

出力の OPT PSEUDOSECTION を見ます。

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

EDNS: version: 0 が表示されていれば、サーバーは EDNS0 を理解して OPT を返しています。
udp: の値は、サーバーが受け取れると申告している UDP サイズです。1232 前後なら近年の推奨に沿っています。4096 などの大きい値でも直ちに誤りではありませんが、断片化しやすい経路では大きな応答で失敗することがあります。
OPT PSEUDOSECTION 自体がない場合、サーバーが EDNS0 に対応していないか、途中の機器が OPT を取り除いています。

比較のため、EDNS0 なしでも試します。

dig @ns1.example.net +norec +noedns example.com SOA

EDNS0 なしでは答えるのに、EDNS0 付きだとタイムアウトする場合は、典型的な「EDNS0 の問い合わせを捨てる機器」が経路上にあります。

手順2：知らないバージョン・オプション・フラグを正しく扱うか

EDNS には将来の拡張に備えたルールがあり、正しい実装はそれに沿って答えます。ここが崩れていると、新しい機能を使い始めたリゾルバーとの間で問題が起きます。

# 未知のバージョン（1）: BADVERS が返り、OPT の version は 0 になるのが正しい動作
dig @ns1.example.net +norec +edns=1 +noednsneg example.com SOA

# 未知のオプション（番号 100）: 無視して通常どおり答えるのが正しい動作
dig @ns1.example.net +norec +edns=0 +ednsopt=100 example.com SOA

# 未定義のフラグ: 無視して通常どおり答える（応答側ではそのフラグを立てない）
dig @ns1.example.net +norec +edns=0 +ednsflags=0x80 example.com SOA

結果の読み方は次のとおりです。

+edns=1 には、status: BADVERS と EDNS: version: 0 の組み合わせが期待される応答です。+noednsneg は、dig が自動でバージョンを下げて再送するのを止めるオプションです。タイムアウトや FORMERR になる場合は、実装か途中の機器がバージョンを正しく扱えていません。
+ednsopt=100 には、普段と同じ NOERROR が返れば問題ありません。未知のオプションを理由に FORMERR を返したり、応答に同じオプションをそのまま入れて返したりするのは誤った動作です。
+ednsflags=0x80 も同様に、通常の応答が返り、応答の flags: に余計な値が付いていなければ問題ありません。

これらは DNS サーバーのソフトウェアが古い、または DNS を検査する機能を持つファイアウォールが独自に判定していることが原因になりがちです。

手順3：大きな応答が UDP と TCP の両方で届くか

EDNS0 の検証でいちばん実害につながりやすいのが、この確認です。DNSSEC の署名付き応答や、TXT レコードが多いドメインの応答は 1232 バイトを超えることがあります。

# DNSKEY は大きくなりやすい。DO ビットを立てて問い合わせる
dig @ns1.example.net +norec +dnssec example.com DNSKEY

# 小さいバッファを申告して、わざと切り詰め（TC）を起こす
dig @ns1.example.net +norec +dnssec +bufsize=512 +ignore example.com DNSKEY

# TCP で問い合わせる
dig @ns1.example.net +norec +dnssec +tcp example.com DNSKEY

1つ目の出力末尾の MSG SIZE rcvd: で応答サイズを確認します。申告した UDP サイズを超える応答は、flags: に tc が立った切り詰めの応答になるのが正しい動作です。
2つ目の +ignore は、TC を受け取っても TCP で取り直さないオプションです。flags: に tc が見えれば、サーバーは「大きいので TCP で来てください」と正しく伝えています。
3つ目で TCP の応答が返ることが前提条件です。ここでタイムアウトする場合は、ファイアウォールやセキュリティグループで TCP の 53 番が閉じています。UDP の 53 番だけを開けている構成は今も見かけますが、EDNS0 と DNSSEC の時代には足りません。

DNSSEC を使っていないドメインでも、SPF やドメイン認証用の TXT レコードが多い場合など、大きなレコードセットでは同じことが起こり得ます。その場合は DNSKEY の代わりに TXT で同じ確認を行います。

手順4：リゾルバー側から見た結果を確かめる

権威 DNS が正しくても、社内のリゾルバーや、その手前の機器が EDNS0 を壊していることがあります。リゾルバーに対しては、再帰を求める通常の問い合わせで確認します。

# リゾルバーが EDNS0 で応答し、DNSSEC の検証結果（ad フラグ）を返すか
dig @192.0.2.53 +dnssec example.com A

# 大きめの応答を UDP / TCP それぞれで
dig @192.0.2.53 +dnssec example.com DNSKEY
dig @192.0.2.53 +dnssec +tcp example.com DNSKEY

リゾルバーに対する結果が、権威 DNS に直接聞いた結果と食い違うなら、問題はリゾルバーかその手前にあります。ルーターの DNS 中継機能など、EDNS0 の扱いが不十分な機器を経由していないかも確認します。

全サーバーをまとめて確かめるスクリプト例

ネームサーバーが複数あると手作業は漏れやすいので、簡単なスクリプトにしておくと便利です。結果は目視で確認する前提の、読み取り専用の例です。

#!/bin/bash
# 使い方: ./edns-check.sh example.com
zone="$1"
for ns in $(dig +short "$zone" NS); do
  for ip in $(dig +short "$ns" A) $(dig +short "$ns" AAAA); do
    echo "=== $ns ($ip) ==="
    echo -n "edns0:   "; dig @"$ip" +norec +edns=0 +time=3 +tries=1 "$zone" SOA | grep -E 'status:|EDNS:' | tr '\n' ' '; echo
    echo -n "edns1:   "; dig @"$ip" +norec +edns=1 +noednsneg +time=3 +tries=1 "$zone" SOA | grep -E 'status:|EDNS:' | tr '\n' ' '; echo
    echo -n "tcp:     "; dig @"$ip" +norec +tcp +time=3 +tries=1 "$zone" SOA | grep -E 'status:' ; echo
  done
done

外部の診断サービス（DNSViz など）でも、権威 DNS ごとの応答の違いや大きな応答の扱いを確認できます。ただし、診断サービスのテスト項目や提供状況は変わることがあるため、最終的な判断は自分で dig を打った結果で行うと確かです。

失敗したときに疑う場所（多い順）

TCP の 53 番が閉じている。 大きな応答だけ失敗する、DNSSEC を有効にしてから一部の環境で引けなくなった、という症状の大半はこれです。ファイアウォール、クラウドのセキュリティグループ、サーバー上の ufw / firewalld の順に確認します。
途中の機器が 512 バイトを超える UDP や OPT 付きのパケットを捨てている。 古いファイアウォールの DNS 検査機能や、ルーターの DNS 中継で起こります。社外から直接権威 DNS に聞くと成功し、社内経由だと失敗する場合はこちらを疑います。
DNS サーバーのソフトウェアが古い。 手順2の結果が期待どおりでない場合は、ソフトウェアの版を確認し、サポートが続いている版へ更新します。マネージド DNS を使っている場合は、事業者に結果を添えて問い合わせます。
バッファサイズが大きすぎて断片化している。 UDP では失敗し TCP では成功する、かつ TC が返っていない場合は、断片が経路のどこかで落ちている可能性があります。バッファサイズを 1232 前後に下げると改善することがあります。

設定を変更する場合は、変更前の設定ファイルを控え、検証用の環境で試してから本番に反映してください。変更後は、この記事の手順1〜3をもう一度実行して、結果が改善したことを確かめます。

まとめ

EDNS0 の検証は「OPT 付きで答えるか」「未知のバージョン・オプション・フラグを正しく扱うか」「大きな応答が UDP と TCP で届くか」の3点で行います。
権威 DNS は NS に載っている全サーバーを IPv4 / IPv6 の両方で、社外のネットワークからも確かめます。
+edns=1 +noednsneg には BADVERS、未知のオプションやフラグには通常の応答が返るのが正しい動作です。
大きな応答では TC が返り、TCP で取り直せることが前提です。TCP の 53 番を閉じていないかを最初に疑います。
失敗したら、TCP の遮断 → 途中の機器 → ソフトウェアの版 → バッファサイズの順に確認します。