DNSプロトコル

DNSプロトコル自体は、UDPでもTCPでも利用できる。しかし、通常は速度優先でUDPを用いている。

速度と信頼性はトレードオフの関係にあり、UDPはシンプルなプロトコルであるため高速だが信頼性に欠く。それでも、速度のためにUDPがよく使われている。この影響で逆に、TCPでDNSプロトコルが利用できない実装も少なくないという状況を作り出した。ここで発生するのが、DNSが返すデータのサイズが、DNSの想定する最小MTUを越えてしまった場合の動作である。

IPv4用DNSプロトコルは、IPv4の最小MTUである548オクテット以内で動作することを想定している。このため、データサイズが512オクテットを越える場合、そのリザルトはパケット分割に対応したTCPにする(TCPフォールバック)か、UDPの場合でもEDNS0という手法を使わざるを得なくなる。どちらも一長一短がある。

リザルトを53/tcpで返信することで、通信の継続を図る手法である。最小MTU以下にTCP層で分割して送信することで、512バイトを越える場合でも情報のやりとりが可能となる。

しかしTCPのコネクション処理が必要になるため、どうしてもレスポンスの低下が発生してしまう。

更に、主要な実装(各種ネットワーク装置や、安物ルーターなども含む)はTCPのDNSプロトコル(53/tcp)に対応していない可能性が高い。仮にルーター自体は対応していても、セキュリティのために53/tcpを通さない設定になっていることもありうる。このためDNSのレコードが膨らみ512バイトを超えてしまうと、正常に通信できない問題が頻発することになる。

クライアントはUDPで要求を投げ、UDPでレスポンスが戻ることを期待している。この状況でTCPでリザルトを返して来ても、それを受け取る処理がない。結果、いくら待ってもクライアントが期待した(UDPの)応答が返って来ないため、通信することが出来ないことになる。これが「512バイトの壁」である。

基本的にクライアント側の問題であるため、サーバー側で打てる手はない。512バイトを越えないようにする消極的対応しか無いが、IPv6対応なども進む中、レコードサイズは増える状況にあり、512バイト以内に収めることは困難となってきた。

EDNS0は、STD 75(RFC 6891)で標準化されたDNSの拡張技術で、512バイトを超えるUDPでのDNSプロトコルを実現するものである。

そもそもEthernetのMTUは1500バイトあるので、UDPのDNSでも1500バイトのパケットを扱うことは難しいことではない(はずである)。問題は、クライアント側、サーバー側の双方が、512バイトを越えるMTUがあるかどうか、である。そこで、互いのMTUを送受信する機能を、DNSプロトコルの水準で設けた。これがEDNS0である。

転送可能バイト数は16ビットの長さが用意されるため、最大で65535まで可能である。ただし、あまり大きいとパケットのフラグメントが発生する。特にEthernetならMTUが1500バイトなので、これを超えれば確実にフラグメントが発生するため、パケットドロップ率が高い環境の場合、あまり実用的でなくなる。

DNSが提供する各情報を、リソースレコード(RR)という。

zoneファイルに書かれた情報を、DNSプロトコルでクライアントに送信することが主たる目的となり、そのための手法が用意されている。

DNSプロトコルのメッセージフォーマットは、大きく5つのセクションがある。DNSメッセージヘッダーのみ必須で、それ以外は空となるセクションが存在する。

• ヘッダー (必須)
• 質問 (ネームサーバー宛ての質問)
• 回答 (質問に対する回答となるリソースレコード)
• オーソリティ
• 追加情報

ヘッダー内の各項目は、全て16ビット長である。したがって12オクテット、96ビット固定長である。フラグは、MSB→LSBの順に記載する。

• ID(16ビット)
• Flags (フラグ)
  • QR(1ビット): 0=問い合わせ、1=応答
  • Opcode(4ビット)
    • 0=標準問い合わせ(QUERY)
    • 1=逆問い合わせ(IQUERY)
    • 2=サーバー状態要求(STATUS)
  • AA(1ビット)
  • TC(1ビット)
  • RD(1ビット)
  • RA(1ビット)
  • Z(3ビット) (将来用の予約、常に0)
  • RCODE(4ビット)
    • 0=エラーなし
    • 1=フォーマットエラー
    • 2=サーバー障害
    • 3=ドメインが存在しない
    • 4=未実装
    • 5=拒絶
• QDCOUNT(16ビット): 質問の項目数
• ANCOUNT(16ビット): 回答の項目数
• NSCOUNT(16ビット): オーソリティの項目数
• ARCOUNT(16ビット): 追加情報の項目数

• QNAME: ドメイン名(可変長)
• QTYPE(16ビット): タイプ
• QCLASS(16ビット): クラス

回答欄、オーソリティ、追加情報は次の共通の構造となる。