DNSとEDNSの違い｜DNSの基本と、EDNS(0)が何を拡張したのかをdigで確かめる

DNS はドメイン名と IP アドレスなどの情報を結びつける仕組みそのもので、EDNS（Extension Mechanisms for DNS、現在の版は EDNS(0)）は、その DNS のメッセージに「拡張情報を載せる欄」を追加するための仕様です。つまり両者は別の技術ではなく、EDNS は DNS の上に乗る追加ルールという関係にあります。この記事では、DNS の基本的な動きを簡単に押さえたうえで、EDNS(0) が生まれた理由、具体的に何ができるようになったのか、dig の出力で EDNS を見分ける方法、EDNS が原因で起きる典型的なトラブルまでを解説します。

DNSとは何か

名前と情報を結びつける分散データベース

DNS（Domain Name System）は、www.example.com のような名前から、IP アドレス（A・AAAA レコード）やメールの受け取り先（MX レコード）、各種の確認用文字列（TXT レコード）などを引くための仕組みです。情報は1か所に集まっているのではなく、ルートサーバー、com などの TLD サーバー、各ドメインの権威 DNS サーバーに分かれて管理されています。パソコンやサーバーは、通常はキャッシュ DNS サーバー（フルリゾルバー）に問い合わせ、キャッシュ DNS がこれらのサーバーを順にたどって答えを調べます。

元々のDNSメッセージの制約

DNS は 1980 年代に設計された仕組みで、当時の仕様（RFC 1035）では UDP で送れるメッセージの大きさが 512 バイトまでに制限されていました。512 バイトを超える応答は、途中で切り詰めた印（TC フラグ）を立てて返し、問い合わせ側が TCP で聞き直すという決まりです。また、メッセージのヘッダーには、応答コードやフラグを入れる欄がわずかしかありませんでした。

この設計は、レコードが少なく応答も小さかった時代には十分でしたが、IPv6 アドレスの普及、DNSSEC による署名の追加、多数の TXT レコードなどで応答が大きくなると、512 バイトでは足りなくなりました。毎回 TCP で聞き直すのは時間も負荷もかかります。

EDNS(0)は何を拡張したのか

EDNS は、DNS のメッセージの形式を変えずに拡張を載せる方法として作られ、現在は RFC 6891 で EDNS(0) として定められています。仕組みは単純で、問い合わせや応答の追加情報セクションに「OPT」という特別なレコードを1つ入れ、そこに拡張情報を書き込みます。OPT は実際のレコードではなく、その通信の間だけ意味を持つ「疑似レコード」です。EDNS に対応していないサーバーは OPT を理解できませんが、対応しているサーバー同士なら、次のことができるようになります。

1. UDPで受け取れるサイズを伝える

問い合わせ側が「UDP でこのサイズまで受け取れる」と申告できます。これにより、512 バイトを超える応答も UDP のまま受け取れるようになりました。現在は、通信経路での IP フラグメント（パケットの分割）によるトラブルを避けるため、1232 バイト程度を上限にする設定が広く推奨されています。

2. フラグと応答コードを増やす

OPT には追加のフラグ欄があります。代表的なのが DO ビット（DNSSEC OK）で、「DNSSEC の署名も一緒に返してほしい」と伝えるために使います。DNSSEC の検証は EDNS(0) が前提になっているということです。また、応答コードの欄も拡張され、元のヘッダーでは表せなかった種類の結果を返せます。

3. オプションを載せる

OPT には、用途ごとのオプションを追加できます。よく見かけるものを挙げます。

• DNS Cookie：簡易的な相手確認の仕組みで、送信元を偽装した問い合わせへの対策の一つ
• EDNS Client Subnet（ECS）：問い合わせ元のネットワークの一部をキャッシュ DNS から権威 DNS に伝え、地域に応じた応答を返すための仕組み。プライバシーとの兼ね合いで、送らない方針のキャッシュ DNS もあります
• Padding：暗号化した DNS 通信（DNS over TLS など）で、メッセージの長さから内容を推測されにくくするための詰め物
• Extended DNS Errors：SERVFAIL などの失敗理由を、より詳しく伝えるための情報
• NSID：応答したサーバーの識別子。エニーキャストで運用されたサーバーのうち、どの拠点が答えたかを調べるときに使います

DNSとEDNSの違いを整理する

EDNS は「新しい DNS」ではなく、既存の DNS に後から付け足された仕組みです。そのため、問い合わせ側も応答側も EDNS に対応している場合にだけ効果があります。

digでEDNSを確かめる

dig は既定で EDNS(0) を使って問い合わせます。出力の OPT PSEUDOSECTION が、OPT 疑似レコードの内容です。

dig example.com A

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0123456789abcdef... (good)

version: 0 が EDNS(0)、udp: 1232 は相手が受け取れると申告した UDP のサイズです。表示される値は、使っている dig のバージョンや相手のサーバーの設定によって変わります。比較のために、EDNS を使わない問い合わせや、DNSSEC の署名を要求する問い合わせも試せます。

# EDNSを使わずに問い合わせる（元々のDNSの動き）
dig +noedns example.com A

# DOビットを立てて、DNSSECの署名も要求する
dig +dnssec example.com A

# 受け取れるサイズを小さく申告し、TCPへの切り替えを観察する
dig +bufsize=512 +dnssec example.com DNSKEY

最後の例では、応答が申告サイズに収まらないと TC フラグが立ち、dig が TCP で聞き直します。+ignore を付けると聞き直しをせず、切り詰められた応答をそのまま表示できます。

EDNSが関係する典型的なトラブル

特定のドメインだけ名前解決が遅い・失敗する

ファイアウォールやルーターが、512 バイトを超える DNS の UDP パケットや、分割された IP フラグメントを落としているケースがあります。応答が届かず、キャッシュ DNS がタイムアウトしてから再試行するため、遅くなったり失敗したりします。DNSSEC で署名されたドメインなど、応答が大きいドメインでだけ起きるのが特徴です。+bufsize を変えて dig を試し、小さいサイズでは成功するなら経路を疑います。

TCPの53番ポートが閉じている

応答が大きいと最終的に TCP での聞き直しが必要になるため、DNS サーバーの TCP 53 番を閉じていると名前解決に失敗することがあります。DNS は UDP だけで動くものという理解は誤りで、権威 DNS もキャッシュ DNS も TCP での受け付けが仕様上求められています。

古い機器やソフトウェアがEDNSを正しく扱えない

EDNS に正しく応答しないサーバーへの互換性のための回避策は、2019 年の「DNS Flag Day」を機に主要なキャッシュ DNS ソフトウェアから順次取り除かれました。続く 2020 年の DNS Flag Day では、フラグメントを避けるために UDP のサイズを 1232 バイト程度にすることが呼びかけられています。自前で古い DNS ソフトウェアや機器を運用している場合は、EDNS への対応状況とアップデートの有無を確認してください（2026年10月現在）。

まとめ

• DNS は名前解決の仕組み全体、EDNS(0) は DNS メッセージに拡張情報を載せるためのルール
• EDNS(0) は OPT 疑似レコードを使い、UDP で受け取れるサイズの申告、DO ビット、各種オプションを可能にした
• DNSSEC の検証や DNS Cookie、ECS などは EDNS(0) を前提にしている
• dig の OPT PSEUDOSECTION で EDNS の内容を確認でき、+noedns・+bufsize・+dnssec で挙動を比べられる
• 応答が大きいドメインだけ失敗する場合は、UDP の大きなパケットやフラグメントの遮断、TCP 53 番の閉塞を疑う

• digコマンドでDNSレコードを調査する方法
• DNSSECを有効化する手順