「512の壁」を越える～EDNS0の概要と運用上の注意～

DNSプロトコルに存在する制限の一部を緩和し、DNSSECやIPv6などへの対応を可能にするためのDNSの機能拡張技術である「EDNS0」について解説します。

DNSの通信ではドメイン名やIPアドレスなど、比較的短いデータを含むDNSメッセージが頻繁にやりとりされることが一般的です。こうした通信形態では、相手との接続の事前確立を必要としないUDPを用いる方が、接続の事前確立が必要なTCPよりも通信にかかるコスト・時間を抑制でき、システム全体の効率や処理能力を向上させることができます。
このような背景から、DNSでは主な通信プロトコルとしてUDPが採用され、TCPは権威DNSサーバー間のゾーン転送やある程度の長さを超えるDNS メッセージを取り扱う際にのみ使用されるように設計されました。そして、UDPにおいて取り扱い可能なDNSメッセージの最大長は当初、512バイトまでと定められました。

512バイト制限の理由

なぜUDPにおけるDNSメッセージの最大長は512バイトまでと定められたのでしょうか。
インターネットで使われているIP（IPv4）の仕様では一度に受信可能なデータグラム（ヘッダーを含むパケット）として、576バイトを保証しなければならないと定められています。この値は、64バイトのヘッダーと512バイトのデータブロックを格納可能な大きさとして選択されたものです（RFC 791 3.1. Internet Header Format）。
このため、UDPにおけるDNSメッセージサイズの最大値を512バイトまでとすることで、通常のDNS通信はIPv4ネットワークにおいて必ず1パケットで送受信可能になります。

図 1 UDPにおけるDNSメッセージサイズDNS キャッシュポイズニングの概要

このことは通信の信頼性が高くなかった当時のインターネットにおいて、DNSを実用的に使用可能にするための重要な要素となりました。

TCPフォールバックと「512の壁」

そして、512バイトを超えるDNS メッセージを応答するための方法として、「TCPフォールバック」と呼ばれる方式が定められました。
DNSサーバーが返そうとする応答が512バイトを越えた場合、512バイト以下に切り詰めた上で「データが切り詰められた」というビット（TC）をセットした応答を送信元に返します。TCがセットされた応答を受け取った場合、送信元は同じ問い合わせをTCPで再送します（*1）。この一連のやりとりをTCPフォールバックと呼びます。
TCPフォールバックは必ずUDPによる通信の後で発生します。そのため、名前解決にかかるコスト・時間が最初からTCPを使う場合よりも更に大きくなります。このUDPにおけるDNSメッセージサイズの制限は後に、DNSにおける「512の壁」と呼ばれるようになりました。

DNSSECの標準化と「512の壁」の顕在化

その後、1990年代にDNSキャッシュポイズニングが関係者の間で問題視され（*2）、DNSSECの標準化作業が開始されました。そして、1997年にDNSSECの最初の仕様（RFC 2065）が標準化されました。
DNSSECを導入した場合、DNS応答を検証するための鍵や署名によりDNSメッセージのサイズが増大します。この、メッセージの増大に伴うUDPメッセージのオーバーフローと、オーバーフローした場合のTCPフォールバックの高いオーバーヘッド（512の壁）が、DNSSEC導入における障害として顕在化してきました。

EDNS0の概要と特徴

IPv4における576バイトの制限は、1980年代当時の通信網の信頼性や制限を考慮したうえで設定されました。その後、ローカルエリアネットワークにおいて広く普及したEthernetでは1回の伝送で送信可能な最大値（MTU）は1500バイトとなっており、かつ広域ネットワークの信頼性も当時と比べ、飛躍的に向上しています。
そのような背景から、通信に従来のUDPを使いながらDNSメッセージサイズの制限を緩和するための拡張機能である「Extension Mechanisms for DNS（EDNS0（*3））」が、1999年に標準化されました（RFC 2671）。EDNS0にはDNSメッセージサイズの制限緩和以外のプロトコル拡張も含まれており、DNSをDNSSECやIPv6に対応させる場合、EDNS0への対応が必須とされています（RFC 3226）。EDNS0はその後、細部の仕様や推奨値などが2013年に変更されています（RFC 6891）。
EDNS0ではEthernetにおけるDNSメッセージサイズの推奨値を、1280バイトから1410バイトまでの間としています。

EDNS0による通信のしくみ

EDNS0による通信ではOPTというリソースレコードが、DNSメッセージのadditionalセクションに付加されます。OPTレコードはAレコードやNSレコードなどとは異なり、DNSにおける通信（トランザクション）の際にのみ現れることから、「疑似RR」（pseudo-RR）と呼ばれています。
EDNS0に対応したキャッシュDNSサーバーが権威DNSサーバーと通信する場合、まずOPTレコードを用いたDNSメッセージを通信相手の権威DNSサーバーに送信します。相手がEDNS0をサポートしている場合には正しい応答が返るため、その後のその相手との通信ではEDNS0が有効になります。
相手がEDNS0をサポートしていなかった場合、OPTレコードを用いたDNSメッセージに対しエラー応答が返るか、OPTレコードが無視されることになります。その場合、その相手とは従来のDNSプロトコルにより通信を継続します。
相手がEDNS0 に対応しているかどうかは応答を受け取ったキャッシュDNSサーバーにより、一定時間キャッシュされます。

EDNS0環境における注意

EDNS0 を用いた環境では、512バイトよりも大きなUDPによるDNS応答が送受信されます。また、MTUを超える大きなDNS応答では、IPフラグメンテーション（*4）が発生する可能性があります。
一部のルーターやファイアーウォールなどのネットワーク機器はこのようなDNSメッセージに対応しておらず、誤動作やデータの喪失などが発生する可能性があります。その場合、DNSの誤動作や名前解決エラーなどにつながる危険性があります。
そうしたトラブルの発生を防ぐため、自組織で運用しているネットワーク機器がEDNS0に対応したDNSメッセージを正しく取り扱えるかを事前確認し、必要に応じた機器の更新やファームウェア・ソフトウェアのバージョンアップなどの対応を実施しておく必要があります。
また、EDNS0をサポートしていない相手との通信や、EDNS0により設定されるDNSメッセージサイズ（ペイロードサイズ）よりも大きなDNSメッセージを応答する場合、従来からのTCPフォールバックによる再問い合わせが実行されます。そのため、各組織において設定するファイアーウォールなどでは、DNSのための設定としてUDPの53番ポートだけではなく、TCPの53番ポートへのアクセスも許可しておく必要があります。

今回のまとめ

TCPでは65,535バイトまでのDNSメッセージサイズを処理できます。

1990年に書かれたS. Bellovin氏の論文がきっかけとなりました。

EDNS0の「0」は、バージョン番号に由来しています。

IPの内部処理において、MTUよりも大きなデータを小さなデータに断片化することをいいます。

掲載内容は2013年11月のものです。

「512の壁」を越える ～EDNS0の概要と運用上の注意～

目次

「512の壁」を越える～EDNS0の概要と運用上の注意～