DNSの「512バイトの呪縛」を解く：EDNS0が支える現代のインターネットとセキュリティの深層
ネットワークエンジニアにとって、DNSは「名前解決をするだけの単純な仕組み」などではない。それはインターネットという巨大な神経系において、最初の一撃を放つ最も重要なプロトコルだ。しかし、このプロトコルには、1987年にRFC 1035で定義された「UDPパケットサイズは512バイトまで」という、現代のセキュリティ要求からすれば極めて窮屈な制約が長らく影を落としてきた。
本稿では、この制約を突破し、DNSSECをはじめとする複雑な暗号署名データを運ぶための要石、EDNS0（Extension Mechanisms for DNS）の深淵に迫る。
—
1. 512バイトの壁と「フラグメンテーションの悪夢」
なぜ512バイトなのか。それは、歴史的なTCP/IPスタックの脆弱性や、ネットワーク機器のバッファオーバーフローを避けるための保守的な設計だった。しかし、DNSSECが登場し、鍵の公開情報やデジタル署名がDNS応答に含まれるようになると、512バイトでは到底足りない。
ここで強引に大きなパケットを流そうとすると、ネットワーク層でIPフラグメンテーションが発生する。だが、ご存じの通り、昨今のファイアウォールやIDS/IPSは、フラグメント化されたUDPパケットを「攻撃の予兆」としてドロップすることが多い。結果、DNS応答が欠損し、解決不能に陥る――これが現場でよく見る「パケットは届いているはずなのに名前が引けない」という悪夢の正体だ。
2. EDNS0：パケットレベルの「拡張ヘッダー」
EDNS0（RFC 6891）は、DNSメッセージのヘッダーを拡張し、クライアントとサーバーが「私はこれだけのサイズのパケットを受け取れる」という能力（UDP Payload Size）をネゴシエーションできるようにした。
パケットレベルで見ると、EDNS0はOPT擬似リソースレコードとしてDNSメッセージの追加セクション（Additional Section）に挿入される。
- UDP Payload Size: クライアントが処理可能な最大のUDPパケットサイズ（通常は4096バイト）を通知。
- Extended RCODE: DNSの応答コード（
NXDOMAIN等）を8ビットから12ビットに拡張。
この小さな拡張が、DNSSECの大きな鍵ペアや複数の署名を、フラグメンテーションを起こさずに安全に運ぶことを可能にしたのだ。
3. 実践：パケットサイズとRTT削減のチューニング
インフラの現場でパフォーマンスを最適化する場合、単にEDNS0を有効にするだけでは不十分だ。Linuxカーネルのsocketバッファサイズと、DNSキャッシュサーバー（UnboundやBIND）の設定を同期させる必要がある。
Unboundでの設定例
/etc/unbound/unbound.confにて、UDPバッファを適切にチューニングする。
server:
# EDNS0の最大パケットサイズを設定（デフォルトは4096だが、環境に応じて調整）
edns-buffer-size: 1232
# 512バイトを超える場合のTCPフォールバックを抑制し、
# 可能な限りUDPで完結させるための最適値（MTUを考慮）
# 1232バイトは、IPv6の最小MTU(1280)からヘッダー分を引いた推奨値
msg-buffer-size: 65552なぜ1232バイトなのか？
ネットワークエンジニアの間で「1232」という数字が神聖視されるのは、IPv6の最小MTU制限（1280バイト）を意識しているからだ。これを超えると、ルーターでフラグメンテーションが発生し、パケットロス率が跳ね上がる。パフォーマンスと信頼性を両立させるための「ギリギリのライン」がここにある。
4. セキュリティとパフォーマンスのトレードオフ
EDNS0を利用したDNSSECの導入は、増幅攻撃（DNS Amplification Attack）の標的になりやすいという側面がある。攻撃者は偽装した送信元IPに対し、大きなDNS応答を送りつけ、ネットワークを飽和させる。
これを防ぐためには、単にEDNS0を拒否するのではなく、以下の対策を講じるのがモダンな設計だ。
1. Response Rate Limiting (RRL): 同じソースからの過剰なクエリを制限する。
2. TCPフォールバックの活用: UDPで応答が大きすぎる場合、あえてTC（Truncation）ビットを立ててクライアントにTCP再送を促す。
3. TLSを用いたDNS（DoT/DoH）への移行: TCPコネクションを確立する際、TLS 1.3の0-RTTハンドシェイクを活用し、RTTのペナルティを最小化する。
5. 最後に：現場が知るべきリアリティ
DNSは、単なるテキストの変換器ではない。それは、ネットワークの階層をまたぎ、カーネルのバッファからファイアウォールのポリシーまでを駆け巡る、極めて繊細な仕組みだ。
EDNS0を適切に理解し、UDP Payload Sizeをネットワーク環境のMTUと照らし合わせてチューニングする――。こうした泥臭い作業の積み重ねこそが、大規模なトラフィックを捌くインフラアーキテクトの腕の見せ所である。
「パケットがどこで、なぜドロップされたのか」。その答えは、常に教科書の外、パケットキャプチャの生データと、カーネルの統計情報の中にこそ眠っている。次回のトラブルシューティングでは、ぜひtcpdumpの-vvオプションを使い、OPTフィールドの中に隠されたEDNS0のメッセージを覗いてみてほしい。そこには、インターネットを支える技術者たちの切実な工夫が刻まれているはずだ。
コメント