DNSプロトコル - 通信用語の基礎知識

DNSを照会する際に用いる通信プロトコル。

概要
512バイトの壁

原因
TCPフォールバック
EDNS0 (Extension mechanism for DNS)

仕様

資源レコード
プロトコル構造
DNSメッセージヘッダー
質問欄
リソースレコード

構造
TYPE
CLASS

概要

TCP/IPのポート53(53/tcpおよび53/udp)が使われる。

DNSでは、問い合わせや応答について、DNSプロトコルと呼ばれるプロトコルを使う。その仕様は、美しさに欠け、解読にも苦慮するが、少しでもデータサイズを縮めるための努力が込められている(らしい)。

512バイトの壁

原因

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

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

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

TCPフォールバック

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

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

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

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

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

EDNS0 (Extension mechanism for DNS)

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メッセージヘッダーのみ必須で、それ以外は空となるセクションが存在する。

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

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ビット): クラス

リソースレコード

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

構造

リソースレコード(資源レコード)は可変長である。

NAME: ドメイン名文字列(ASCIIZで、終端'\0')
TYPE(16ビット): タイプ('A'、'PTR'、'NS'、などの区別)
CLASS(16ビット): クラス('IN'、などの区別)
TTL(32ビット): TTL(Time To Live)
RDLENGTH(16ビット): RDATAのサイズ
RDATA: データ

RDATAの大きさや内容、構造などはTYPEごとに様々である。詳細なフォーマットについては、RFC 1035の3.3章に記載がある。

TYPE

リソースレコードに使われるTYPE値。

A 1 IPv4ホストアドレス
NS 2 オーソリティネームサーバー
MD 3 メールデスティネーション (破棄、→ MX)
MF 4 メールフォワーダー (破棄、→ MX)
CNAME 5 別名に対する正規名
SOA 6 ゾーンに関する様々な情報
MB 7 メールボックスドメイン名 (実験プロトコル)
MG 8 メールグループメンバー (実験プロトコル)
MR 9 名前を変更したメールボックス (実験プロトコル)
NULL 10 ナルRR (実験プロトコル)
WKS 11 周知のサービス記述
PTR 12 ドメイン名スペースへのポインター
HINFO 13ホスト情報
MINFO 14 メールボックスまたはメールリストの情報
MX 15 メールエクスチェンジャー
TXT 16 テクスト文字列
RP 17 Responsible Person (RFC 1183)
AFSDB 18 Andrew File System(AFS)データベース (RFC 1183)
X25 19 X.25アドレス (RFC 1183)
ISDN 20 ISDNアドレス (RFC 1183)
RT 21 Route Through (RFC 1183)
NSAP 22 NSAPアドレス (RFC 1706)
AAAA 28 IPv6ホストアドレス (RFC 1884)
SRV 33 サービスロケーション (RFC 2782)
NAPTR 35 Naming Authority Pointer (RFC 2915)
A6 38 IPv6ホストアドレス (RFC 2874)
EDNS 41 EDNS0 (RFC 2671)

以下は、質問(Query)時に使われるQTYPE値。

AXFR 252 ゾーン全体の転送要求
MAILB 253 メールボックス関連レコードの要求(MB、MG、またはMR)
MAILA 254 メールエージェントの資源レコードの要求 (破棄)
* 255 すべてのレコードの要求

CLASS

リソースレコードに使われるCLASS値。

IN 1 インターネット
CS 2 CSNET (破棄)
CH 3 CHAOS
HS 4 Hesiod [Dyer 87]

以下は、質問(Query)時に使われるCLASS値。

* 255 全てのクラス

リンク

用語の所属

DNS
関連する用語

EDNS0