DNSプロトコルのヘッダセクションのフォーマット

DNSプロトコルのヘッダセクションのフォーマットについて調べた。
今回はその96ビット(12バイト)のメモ。
 
解りづらい日本語で、なかなか難しい。
ボディ部分はいずれ書く予定。
 

全体像

DNSプロトコルの全体像
    +---------------------+
    |        Header       | ←今回はここ
    +---------------------+
    |       Question      |
    +---------------------+
    |        Answer       |
    +---------------------+
    |      Authority      |
    +---------------------+
    |      Additional     |
    +---------------------+

 

DNSプロトコルのヘッダ全体像
                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      ID                       |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

 

ID

16ビット。
問い合わせと応答で同じ値が使われる。
0x0000から0xFFFFの値を、被らないようにDNSクライアントが自由に決める。
インクリメントされてリクエストするクライアントが多いみたい。
 

Flag

16ビット。
ビットレベルで分割されている。
解りにくいので視覚化。

0....... ........ QR
.0000... ........ OPcode
.....0.. ........ AA
......0. ........ TC
.......0 ........ RD
........ 0....... RA
........ .000.... Z
........ ....0000 Rcode

 

QR (Query/Response)

1ビット。
クライアントは0を指定する。
サーバは1に書き換える。
 
このパケットがリクエストなのかレスポンスなのか。

0 => 問い合わせ
1 => レスポンス

 

OPCode (Operation code)

4ビット。
クライアントが指定する。
 
どんな問い合わせか。
RFC 1035で定義されているのは以下の通り。

0 => 問い合わせ
1 => 逆問い合わせ
2 => サーバ状態要求

逆問い合わせについては「RFC 1035 6.4. Inverse queries (Optional)」を参照。
 

AA (Authoritative Answer)

1ビット。
サーバが指定する。
 
直接問い合わせを受けたサーバの知っている情報を返したか否か。

0 => 反復の結果の応答
1 => そのネームサーバからの応答

 

TC (Truncated)

1ビット。
サーバが指定する。
 
切り捨てられた先頭のデータか否か。
512バイトに入りきらなかった場合、別途TCPでやり取りする。

0 => 512バイトに入りきった
1 => 512バイトに入りきらなかった

 

RD (Recursion Desired)

1ビット。
クライアントが指定する。
 
問い合わせたドメインをサーバが知らなかった場合に、サーバが別サーバに問い合わせてその結果を返して欲しいか否か。
サーバはクライアントが1を送ったからといって、必ず従わなければいけない訳ではない。
Bindの場合、「recursion yes;」となっていたらサーバはクライアントに従う。

0 => クライアントが再問い合わせする
1 => サーバが再問い合わせする

 

RA (Recursion Available)

1ビット。
サーバが指定する。
 
サーバで再帰問い合わせに対応しているか否か。
Bindの場合、「recursion yes;」なら1、「recursion no;」なら0。

0 => 再帰問い合わせ不可能
1 => 再帰問い合わせ可能

 

Z

3ビット。
予約。
使われていない。
 

Rcode (Return code)

4ビット。
サーバが指定する。
 
レスポンスのステータス。
RFC 1035で定義されているものは以下の通り。

0 => エラーなし (HTTP 200 OK相当)
1 => フォーマットエラー (HTTP 400 Bad Request相当)
2 => サーバエラー (HTTP 500 Internal Server Error相当)
3 => 問い合わせの名前なし (HTTP 404 Not Found相当)
4 => 未実装 (HTTP 501 Not Implemented相当)
5 => 拒否 (HTTP 403 Forbidden相当)

 

QD Count (Query count)

16ビット。
クライアントが指定する。
 
質問の数。
 

AN Count (Answer count)

16ビット。
サーバが指定する。
 
回答の数。
 

NS Count (Authority count)

16ビット。
サーバが指定する。
 
オーソリティの数。
 

AR Count (Additional information count)

16ビット。
サーバが指定する。
 
追加情報の数。
 

参考URL

第66回DNS(5) DNSメッセージ
http://www5e.biglobe.ne.jp/aji/3min/66.html
 
RFC1035 ドメイン名−実装と仕様書
http://www5d.biglobe.ne.jp/~stssk/rfc/rfc1035j.html
 
RFC2929 ドメインネームシステム(DNS)のIANAの考慮
http://www5d.biglobe.ne.jp/~stssk/rfc/rfc2929j.html
 
DNS, Domain Name System
http://www.networksorcery.com/enp/protocol/dns.htm