EDNS0 |
辞書:通信用語の基礎知識 通信手順上編 (CPINFO) |
読み:イーディーエンエス-ゼロ |
外語: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としては採用されなかったようである。
リンク |
通信用語の基礎知識検索システム WDIC Explorer Ver 7.04a (27-May-2022) Search System : Copyright © Mirai corporation Dictionary : Copyright © WDIC Creators club |