4. Messages (メッセージ)
ドメインプロトコル内のすべての通信は、メッセージ (Message) と呼ばれる単一の形式で行われます。
4.1. Format (形式)
メッセージの最上位形式は、5つのセクションに分かれています (一部のセクションは特定の場合に空になることがあります):
+---------------------+
| Header |
+---------------------+
| Question | ネームサーバーへの質問
+---------------------+
| Answer | 質問に答えるRR
+---------------------+
| Authority | 権威を指すRR
+---------------------+
| Additional | 追加情報を保持するRR
+---------------------+
セクションの説明:
-
Header (ヘッダー): 常に存在します。残りのどのセクションが存在するかを指定するフィールド、およびメッセージがクエリか応答か、標準クエリか他のオペコードかなどを指定します。
-
Question (質問): ネームサーバーへの質問を記述するフィールドが含まれます。これらのフィールドは、クエリタイプ (QTYPE)、クエリクラス (QCLASS)、およびクエリドメイン名 (QNAME) です。
-
Answer (回答): 質問に答えるRRが含まれます。
-
Authority (権威): 権威ネームサーバーを指すRRが含まれます。
-
Additional (追加): クエリに関連するRRが含まれますが、厳密には質問への回答ではありません。
最後の3つのセクションは同じ形式を持っています: 連結されたリソースレコード (RR) の空の可能性があるリストです。
4.1.1. Header Section Format (ヘッダーセクション形式)
ヘッダーには次のフィールドが含まれます:
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ビット):
- 任意の種類のクエリを生成するプログラムによって割り当てられる16ビット識別子
- この識別子は対応する応答にコピーされます
- リクエスタが未処理のクエリと応答を照合するために使用できます
QR (1ビット):
- クエリ/応答フラグ (Query/Response Flag)
- このメッセージがクエリ (0) か応答 (1) かを指定します
OPCODE (4ビット):
- このメッセージのクエリの種類を指定します
- クエリの発信者によって設定され、応答にコピーされます
- 値:
0- 標準クエリ (QUERY)1- 逆引きクエリ (IQUERY)2- サーバーステータス要求 (STATUS)3-15- 将来の使用のために予約
AA (1ビット):
- 権威回答 (Authoritative Answer)
- 応答で有効
- 応答するネームサーバーが質問セクションのドメイン名の権威であることを指定します
- 注意: 回答セクションには、エイリアスのために複数の所有者名が含まれる場合があります。AAビットは、クエリ名と一致する名前、または回答セクションの最初の所有者名に対応します。
TC (1ビット):
- 切り詰め (TrunCation)
- 伝送チャネルで許可されている長さよりも長いため、このメッセージが切り詰められたことを指定します
RD (1ビット):
- 再帰希望 (Recursion Desired)
- クエリで設定され、応答にコピーされます
- RDが設定されている場合、ネームサーバーにクエリを再帰的に追求するよう指示します
- 再帰クエリサポートはオプションです
RA (1ビット):
- 再帰利用可能 (Recursion Available)
- 応答で設定またはクリアされます
- ネームサーバーで再帰クエリサポートが利用可能かどうかを示します
Z (3ビット):
- 将来の使用のために予約
- すべてのクエリと応答でゼロでなければなりません (MUST)
RCODE (4ビット):
- 応答コード (Response Code)
- 応答の一部として設定されます
- 値:
0- エラー条件なし1- フォーマットエラー - ネームサーバーがクエリを解釈できませんでした2- サーバー障害 - ネームサーバーの問題によりこのクエリを処理できませんでした3- 名前エラー - 権威ネームサーバーからの応答でのみ意味があり、クエリで参照されているドメイン名が存在しないことを示します4- 未実装 - ネームサーバーは要求された種類のクエリをサポートしていません5- 拒否 - ネームサーバーはポリシー上の理由で指定された操作の実行を拒否します6-15- 将来の使用のために予約
QDCOUNT (16ビット):
- 質問セクションのエントリ数を指定する符号なし16ビット整数
ANCOUNT (16ビット):
- 回答セクションのリソースレコード数を指定する符号なし16ビット整数
NSCOUNT (16ビット):
- 権威レコードセクションのネームサーバーリソースレコード数を指定する符号なし16ビット整数
ARCOUNT (16ビット):
- 追加レコードセクションのリソースレコード数を指定する符号なし16ビット整数
4.1.2. Question Section Format (質問セクション形式)
質問セクションは、ほとんどのクエリで「質問」を運ぶために使用されます。つまり、何が尋ねられているかを定義するパラメータです。
このセクションには、QDCOUNT (通常は1) のエントリが含まれ、各エントリは次の形式です:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
フィールドの説明
QNAME (可変長):
- ラベルのシーケンスとして表現されるドメイン名
- 各ラベルは、長さオクテットとそれに続くオクテット数で構成されます
- ドメイン名は、ルートの空ラベルのゼロ長オクテットで終了します
- 注意: このフィールドは奇数のオクテット数である可能性があります。パディングは使用されません
QTYPE (16ビット):
- クエリのタイプを指定する2オクテットコード
- このフィールドの値には、TYPEフィールドに有効なすべてのコードと、複数のタイプのRRに一致できるより一般的なコードが含まれます
QCLASS (16ビット):
- クエリのクラスを指定する2オクテットコード
- 例えば、QCLASSフィールドはインターネットの場合INです
4.1.3. Resource Record Format (リソースレコード形式)
回答、権威、および追加セクションはすべて同じ形式を共有します: 可変数のリソースレコード。レコード数はヘッダーの対応するカウントフィールドで指定されます。
各リソースレコードは次の形式を持ちます:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
フィールドの説明
NAME (可変長):
- このリソースレコードが関係するドメイン名
TYPE (16ビット):
- RRタイプコードの1つを含む2オクテット
- このフィールドはRDATAフィールドのデータの意味を指定します
CLASS (16ビット):
- RDATAフィールドのデータのクラスを指定する2オクテット
TTL (32ビット):
- リソースレコードが破棄される前にキャッシュされる可能性のある時間間隔 (秒単位) を指定する32ビット符号なし整数
- ゼロ値は、RRが進行中のトランザクションにのみ使用でき、キャッシュすべきではないことを意味すると解釈されます
RDLENGTH (16ビット):
- RDATAフィールドの長さをオクテット単位で指定する符号なし16ビット整数
RDATA (可変長):
- リソースを記述する可変長のオクテット文字列
- この情報の形式は、リソースレコードのTYPEとCLASSによって異なります
- 例えば、TYPEがAでCLASSがINの場合、RDATAフィールドは4オクテットのARPAインターネットアドレスです
4.1.4. Message Compression (メッセージ圧縮)
メッセージのサイズを削減するために、ドメインシステムは圧縮スキーム (Compression Scheme) を利用します。これにより、メッセージ内のドメイン名の繰り返しが排除されます。
圧縮方法
このスキームでは、ドメイン名全体またはドメイン名の末尾のラベルのリストが、同じ名前の以前の出現へのポインタ (Pointer) に置き換えられます。
ポインタ形式:
ポインタは次の形式をとります:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 最初の2ビットは1です
- これにより、ポインタをラベルと区別できます。ラベルは2つのゼロビットで始まる必要があるためです
- OFFSETフィールドは、メッセージの先頭からのオフセットを指定します (つまり、ドメインヘッダーのIDフィールドの最初のオクテット)
- ゼロオフセットは、IDフィールドの最初のバイトなどを指定します
圧縮規則
圧縮スキームにより、メッセージ内のドメイン名を次のように表現できます:
- ゼロオクテットで終わるラベルのシーケンス
- ポインタ
- ポインタで終わるラベルのシーケンス
重要な制限:
- ポインタは、形式がクラス固有でないドメイン名の出現にのみ使用できます
- そうでない場合、ネームサーバーまたはリゾルバは処理するすべてのRRの形式を知る必要があります
- まだそのようなケースはありませんが、将来のRDATA形式で発生する可能性があります
圧縮が許可される場所:
- リソースレコードのNAMEフィールド
- 質問エントリのQNAMEフィールド
- RDATAフィールドにドメイン名が表示される場合 (形式がわかっている特定のRRタイプのみ)
圧縮が許可されない場所:
- RDATA形式が不明または可変のRRタイプのRDATA
例
クエリに次が含まれている場合:
www.example.com
mail.example.com
「example.com」の2回目の出現は、最初の出現へのポインタに置き換えることができ、バイトを節約できます。
4.2. Transport (トランスポート)
DNSメッセージは、さまざまなトランスポートプロトコルで伝送できます:
4.2.1. UDP Usage (UDP使用法)
- デフォルトトランスポート: UDPはDNSクエリと応答の優先トランスポートです
- 最大サイズ: UDP経由で送信されるDNSメッセージは512オクテットを超えてはなりません (SHOULD NOT)
- 切り詰め: 応答が512オクテットを超える場合、ヘッダーのTC (切り詰め) ビットを設定すべきです (SHOULD)
- 再試行: TC=1の場合、クライアントはTCPを使用してクエリを再試行すべきです (SHOULD)
UDPの利点:
- オーバーヘッドが低い
- 小さなクエリの場合高速
- 接続設定が不要
4.2.2. TCP Usage (TCP使用法)
- 使用するタイミング: TCPは次の場合に使用すべきです (SHOULD):
- 応答サイズが512オクテットを超える場合
- 信頼性の高い配信が必要な場合
- ゾーン転送が実行される場合
- メッセージ形式: TCPを使用する場合、各メッセージの前に16ビット長フィールドが付きます
- 接続管理: 接続は永続的である場合もあれば、各クエリ応答ペアの後に閉じられる場合もあります
TCPメッセージ形式:
+---------------------+
| Length (16ビット) |
+---------------------+
| |
| DNSメッセージ |
| |
+---------------------+
4.3. Standard Query Example (標準クエリの例)
www.example.com のAレコードの標準クエリの例:
クエリメッセージ構造:
Header (ヘッダー):
ID: 0x1234
QR: 0 (クエリ)
OPCODE: 0 (標準クエリ)
RD: 1 (再帰希望)
QDCOUNT: 1
ANCOUNT: 0
NSCOUNT: 0
ARCOUNT: 0
Question (質問):
QNAME: www.example.com
QTYPE: A (1)
QCLASS: IN (1)
応答メッセージ構造:
Header (ヘッダー):
ID: 0x1234
QR: 1 (応答)
OPCODE: 0 (標準クエリ)
AA: 1 (権威回答)
RD: 1 (再帰希望)
RA: 1 (再帰利用可能)
RCODE: 0 (エラーなし)
QDCOUNT: 1
ANCOUNT: 1
NSCOUNT: 0
ARCOUNT: 0
Question (質問):
QNAME: www.example.com
QTYPE: A (1)
QCLASS: IN (1)
Answer (回答):
NAME: www.example.com
TYPE: A (1)
CLASS: IN (1)
TTL: 3600
RDLENGTH: 4
RDATA: 93.184.216.34