DNSプロトコルの制限の一部を緩和する、DNSの機能拡張技術。STD 75
(Extension Mechanisms for DNS)で標準化されている。
DNSのUDPメッセージは、最大で512オクテット、とするのが元々の仕様である。
512オクテットを超える場合、UDPではなくTCPを用いることになっていた。これが「TCPフォールバック」である、
TCPフォールバックでは、512オクテット以下の複数のパケットに分割したTCPパケットにて結果を返す必要がある。だが、TCPによるDNSプロトコルに対応せず、このためTCPで値を返しても受け取ることができない実装が多かった。もって、DNSサーバーから(UDPでの)応答がない→通信できない、という問題が生じた。
そこで、UDPの範囲内で制限を緩和する方法が模索された。その結果が、EDNSである。
DNSサーバーは、512オクテットを超えるリザルトを返すことになる。
受信側がより大きな情報を受け取ることができる場合、DNSサーバー側に通達するべき最低限必要な情報は、受信するクライアント側のMTUである。
そこで、MTUを送受信するための専用のリソースレコードを用意した。
要求時にクライアントは自身のMTUを含めてDNSサーバーにパケットを投げる。DNSサーバーは、それを見てクライアントに返信するが、同時に自身のMTUも送り返す。
これを読み取れば互いのMTUが分かることになるが、未対応のクライアント側実装でこれを読み飛ばさずエラーとするものがあり、このようなものは正常に処理できないという制限がある。
DNSプロトコルは、ヘッダーを必須とし、質問、回答、オーソリティ、追加情報の4セクションを任意としている。
DNSサーバーが要求クライアントへDNSの情報を返送する時には回答欄にリソースレコードを入れて返すことになり、EDNSもそのリソースレコードの種類の一つとして定義されている。
リソースレコードは全部で6項目あり、そのレコードの種類は16ビット長のフィールドTYPEで表現する。
EDNSは、TYPE=41 (0x29) である。
EDNSは、リソースレコードの6項目のフィールドのうち、CLASSフィールドをMTUの表現に流用し、TTLフィールドをフラグ類に流用している。
このため、基本的にはRDATA欄は使用せず、ここはオプション用として予約されている。
RDATAは、オプション用に次のように定義され、次の情報が0個以上からなる構造となる。
EDNSにおいてCLASS欄16ビットは、MTUサイズの表現に用いる。
EDNSにおける肝となるフィールドである。早い話が、この16ビットの領域を用意するために、関連する仕様が形作られているとも言える。
転送可能バイト数は16ビットの長さが用意されるため、最大で65535オクテットまで可能である。
ただし、あまり大きいとパケットのフラグメントが発生する。特にEthernetならMTUが1500バイトなので、これを超えれば確実にフラグメントが発生するため、パケットドロップ率が高い環境の場合、あまり実用的でなくなる。
EDNSにおいてTTL欄32ビットは、拡張RCODEおよびフラグに用いる。
フラグは次のとおりである。
)オプションを用いて拡張可能なように設計されている。
EDNS0のRFCでは、オプションは未定義であるが、しかしGoogleらにより、DNSリクエスト内にクライアントのIPアドレス情報を含める拡張の提案がなされていた。
I-Dでは、IPv4とIPv6が想定されていた。
このI-Dは、RFCとしては採用されなかったようである。
コメントなどを投稿するフォームは、日本語対応時のみ表示されます
通信用語の基礎知識検索システム WDIC Explorer Version 7.04a (27-May-2022)
DNSプロトコル
