EDNS0
読み：イーディーエンエス-ゼロ
外語：EDNS0: Extension mechanism for DNS version 0

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