メインコンテンツまでスキップ

2. AXFR Messages (AXFRメッセージ)

AXFRセッションは単一のTCP接続で構成され, DNSクエリメッセージによって開始されます。そのクエリメッセージは, 転送されるゾーンとセッションの特定の特性を決定します。クエリに続いて, クエリが成功したと仮定して, ゾーンコンテンツの転送が行われ, その後接続が終了します。

このドキュメントでは以下の定義を使用します。"AXFR client" (AXFRクライアント) は, TCP接続を開始し, DNS AXFRクエリを送信するホストです。"AXFR server" (AXFRサーバー) は, AXFRクエリを受信し, AXFR応答を送信するホストです。"AXFR session" (AXFRセッション) は, 1つのAXFRクエリとそのクエリに対応するAXFR応答のシーケンスで構成されます。

AXFRはDNSに定義されているいくつかのクエリタイプ (QTYPE) の1つです。ただし, ほとんどのクエリタイプとは異なり, AXFRはクエリに完全に応答するために複数のDNSメッセージを必要とする場合があります。初期クエリと応答メッセージのフォーマットは, RFC 1035および後続のドキュメントで定義されている標準的なDNSメッセージです。クエリタイプがAXFRの場合, DNSメッセージの一部のフィールドはさらに制限されます。

このドキュメント全体を通して, AXFRクエリと応答は, DNSメッセージの構造に従ってセクションに分割されます。5つのセクションは次のとおりです: (1) Header (ヘッダー), (2) Question (質問), (3) Answer (回答), (4) Authority (権威), (5) Additional (追加)。

このセクションでは, クエリと応答のメッセージを文書化し, クエリに対する制限とサーバーに対する要件を含みます。これはTCP接続の使用法にも対応しています。

2.1. AXFR Query (AXFRクエリ)​

このサブセクションでは, AXFRセッションを開始するクエリメッセージのフォーマットとセマンティクスについて説明します。"normal DNS" (通常のDNS) という用語は, 標準DNS仕様 (RFC 1034, RFC 1035, および更新) によって管理される動作を説明するために使用されます。

AXFRクエリは, QTYPEがAXFRの通常のDNSクエリメッセージに似ていますが, "well-formed AXFRクエリ" には追加の制限が課されています。AXFRクエリを送信するAXFRクライアントは, well-formedクエリのルールに準拠する必要があります。AXFRサーバーは, これらのルールに準拠しないAXFRクエリに対して, 不適切にフォーマットされたクエリに応答するのと同じ方法で応答しなければなりません。(これは通常FORMERR応答です。)

well-formed AXFRクエリには以下の特性があります:

  1. DNSヘッダーのOPCODEは0でなければなりません (標準クエリ)。

  2. DNSヘッダーの質問セクション (QDCOUNT) は1でなければなりません。

  3. DNSヘッダーの回答セクションカウント (ANCOUNT), 権威セクションカウント (NSCOUNT), および追加セクションカウント (ARCOUNT) はすべて0でなければなりません。

  4. 質問セクションには, 以下を持つ単一の質問が含まれていなければなりません:

    • QTYPEはAXFR [RFC5395] (252 10進数) と等しい;
    • QCLASSはゾーンクラスまたはANYと等しい;
    • QNAMEは転送されるゾーンの名前と等しい。

  5. AXFR応答は, クエリよりも高いDNSプロトコルバージョンである可能性があります。

2.1.1. Header Values (ヘッダー値)​

QR: 0でなければなりません (Query, クエリ)

OPCODE: 0でなければなりません (Standard Query, 標準クエリ)

AA: 検査されません (クエリには無関係)

TC: 0でなければなりません (Not Truncated, 切り詰められていない) - TCが1に設定されたAXFRクエリは不適切にフォーマットされています。

RD: 0または1である可能性があります - Recursion Desired (再帰希望) ビットはAXFRサーバーによって無視されます。それはAXFRクエリの動作に影響を与えず, 権威転送で役割を果たしません。AXFRクエリメッセージのRDビットの設定は, クエリが再帰クエリであることの信頼できる指標ではありません。

RA: 検査されません (応答でのみ使用)

Z: 0でなければなりません (将来の使用のために予約) - DNS仕様の要件に従って, 予約ビットはクエリで0でなければならず, 応答では無視されなければなりません。したがって, AXFRクライアントはZビットをゼロに設定しなければならず, AXFRサーバーはその値を無視しなければなりません。予約 (Z) ビットのいずれかが非ゼロ値に設定されたAXFRクエリは不適切にフォーマットされています。

AD: 0でなければなりません - Authentic Data (真正データ) ビットは応答に対してのみ定義されます [RFC4035]。

CD: 0または1である可能性があります - Checking Disabled (チェック無効) ビットは応答にのみ関連するため, ゾーン転送クエリに対して定義された意味はありません。AXFRクライアントはこのビットを設定することができます。AXFRサーバーはその値を無視しなければなりません。

RCODE: 0でなければなりません (No Error, エラーなし) - 応答コードフィールドは応答に対してのみ定義されます。

QDCOUNT: 1でなければなりません

ANCOUNT: 0でなければなりません

NSCOUNT: 0でなければなりません

ARCOUNT: 0でなければなりません, またはクエリにEDNS(0) [RFC2671], TSIG [RFC2845], またはSIG(0) [RFC2931] オプションが含まれている場合は0より大きい可能性があります。

EDNS(0), TSIG, およびSIG(0) の考慮事項については, セクション2.2.5を参照してください。

2.1.2. Question Section (質問セクション)​

質問セクションは, RFC 1035で指定されたものに準拠しなければならず, 以下の特性を持つ単一の質問を含みます:

QNAME: 転送されるゾーンの名前。有効なDNSドメイン名でなければなりません。

QTYPE: 値は252 (AXFRの場合), [RFC5395] による。

QCLASS: 転送されるゾーンのクラス。AXFRクエリは主要なセキュリティリスクになる可能性があるため, AXFRサーバーは何らかのポリシー (アクセス制御リスト, TSIG認証など) を通じてゾーン転送アクセスを制限する可能性が高く, ゾーン転送は任意のクエリ発行者に提供されるべきではありません。特別なQCLASS値 * (ANY, 255 10進数) は, 後方互換性のために使用される可能性があります。QCLASSがANYの場合, AXFRサーバーは利用可能なすべてのクラスのデータのゾーンデータを返すのではなく, 1つのクラスを選択してそのゾーンを転送するか, クエリを拒否することができます。(汎用DNS実装には後者が推奨されます。) 注意深く書かれたAXFRクライアントは, 特定のクラスを介してゾーン転送を要求します。

2.1.3. Answer Section (回答セクション)​

AXFRクエリでは回答セクションは空でなければなりません (ANMUSTは0でなければなりません)。

2.1.4. Authority Section (権威セクション)​

AXFRクエリでは権威セクションは空でなければなりません (NSCOUNTは0でなければなりません)。

2.1.5. Additional Section (追加セクション)​

AXFRクエリメッセージの追加セクションには, EDNSサポートとパラメータを示すためにEDNS(0) リソースレコード (RR) [RFC2671] が含まれている場合があります。また, 認証目的でTSIG [RFC2845] またはSIG(0) [RFC2931] RRが含まれている場合もあります。TSIGまたはSIG(0) オプションの存在により, AXFRクエリの認証が可能になり, AXFRサーバーでより寛容な認可ポリシーが可能になる可能性があります。

EDNS(0) が使用される場合, OPT擬似RRは追加セクションに配置され, ARCOUNTは適切にインクリメントされます。EDNS(0) によってアドバタイズされるバージョン番号は, そのバージョン用にフォーマットされたパケットを受け入れる意欲を示します。EDNS対応でないAXFRクライアントは, ARCOUNTを0に設定し, OPT RRを含めません。EDNS対応でないAXFRサーバーは, OPT RRを無視し, ARCOUNTが0より大きく, 追加処理 (これらの追加RRの検査) が有効になっている場合, クエリを不正な形式として扱うことを選択できます。

SIG(0) を持つAXFRクエリは, ARCOUNTが追加セクションのOPT RRの数に1を加えたものと等しくなります。TSIG RRはARCOUNTにカウントされません。TSIGはDNSの代替メッセージ認証技術であるためです。TSIGの考慮事項については [RFC2845] を参照してください。

TSIGとEDNS(0) は同時に使用される可能性があります。

2.2. AXFR Response (AXFR応答)​

このサブセクションでは, AXFRクエリに対する応答のフォーマットとセマンティクスについて説明します。応答は, TCP接続が確立され, AXFRクエリが解析された後に送信されます。

AXFRサーバーは, 予期しない, 未定義, またはサポートされていないフラグまたは属性を持つクエリを, 標準DNS エラー応答で応答することによって処理できなければなりません。さまざまなエラーを引き起こす条件は, 以下のサブセクションで詳しく説明されます。

AXFRクエリに対するAXFRサーバー応答には4つのカテゴリがあります:

  1. 不正な形式の応答: TCPを介して受信したAXFRクエリが合法的なDNSクエリメッセージでない場合, またはDNSメッセージがセクション2.1で指定されたwell-formed AXFRクエリの要件に準拠していない場合, これが発生します。不正な形式のクエリに対する応答は, 適切なRCODE (FORMERR, NOTIMP, REFUSEDなど) を持つ単一のDNS応答メッセージであるべきです。

  2. 拒否された応答: 受信したDNSメッセージが合法的なAXFRクエリであるが, ポリシーの考慮事項により, この特定のAXFRクライアントがゾーン転送を実行することが許可されていない場合 (問題のゾーンまたは一般的に), 応答はRCODE REFUSEDを持つ単一のDNS応答メッセージであるべきです。

  3. 空の応答: 転送されるゾーンが空の場合 (ゾーンapexのすべての権威データがゾーンの外側にある), AXFRサーバーは回答セクションに1つのSOA RRのみを含む単一の応答メッセージを返すべきです。このSOA RRはゾーン内の唯一のRRになります。空のゾーンの条件は非常に珍しく, ゾーンから必須のSOA以外のすべてを削除した帯域外操作 (ゾーン編集, 動的更新, またはその他の手段) の結果です。

  4. 成功した応答: ポリシーまたは不正な形式の問題がないと仮定して, AXFRサーバーは, セクション3で説明されている特定の包含と除外を条件として, 転送されたゾーンからのすべての権威データをまとめて含む1つ以上のDNS応答メッセージで応答します。

最初の3つのタイプの応答は単一のDNSメッセージを介して配信されます。最後のタイプ, 成功した応答は, TCP接続を介して順次送信される1つ以上のDNS応答メッセージで構成できます。

EDNS(0), TSIG, またはSIG(0) を実装するAXFRサーバーは, 対応するオプションを含まないAXFRクエリメッセージを受信する準備をしなければなりません。逆に, AXFRサーバーは, クエリメッセージ内のEDNS(0), TSIG, またはSIG(0) オプションの存在を無視することを選択できます (たとえば, それらをサポートまたは要求しない場合)。ただし, AXFRサーバーがEDNS(0), TSIG, またはSIG(0) を実装し, リクエスト内のそれらのオプションからの情報を利用することを選択する場合, AXFR応答メッセージに適切なオプション情報を含めなければなりません。

AXFRクライアントは, TC (切り詰め) ビットが使用されていないか意味がないAXFR応答を受信する準備をしなければなりません。AXFRはTCP上で動作し, 応答シーケンスで複数のDNSメッセージを使用することが許可されているため, 切り詰めは必要ありません。(TCビットの使用については, セクション2.2.1で明示的にカバーされています。)

2.2.1. Header Values (ヘッダー値)​

QR: 1でなければなりません (Response, 応答)

OPCODE: 0でなければなりません (Standard Query, 標準クエリ)

AA: AA (Authoritative Answer, 権威回答) ビットは, すべての応答メッセージで1に設定されるべきです。AXFRサーバーは転送されるゾーンに対して権威を持っている可能性が高いですが, そうでなければならないという厳格な要件はありません。

TC: 0でなければなりません (Not Truncated, 切り詰められていない) - AXFRはTCP上で動作し, 複数の応答メッセージを使用できるため, TCビットを設定する必要はありません。

RD: 応答のRDビットはクエリからRDビットをコピーします (DNS仕様による)。RDビットはAXFRには意味がありません。その値はAXFRの動作に影響しません。

RA: RA (Recursion Available, 再帰利用可能) ビットは, AXFRサーバーの一般的なポリシーに従って応答で設定またはクリアされる可能性があります。ゾーン転送の場合, 再帰は適用されないため, RAの値はこのコンテキストでは意味がありません。

Z: 0でなければなりません (Reserved, 予約済み) - AXFRサーバーは予約ビットをゼロに設定しなければならず, AXFRクライアントはそれらを無視しなければなりません。

AD: 0または1である可能性があります - DNSSEC署名ゾーンを提供するDNSSEC対応AXFRサーバーの場合, AD (Authentic Data, 真正データ) ビットは, DNSSEC要件 [RFC4035] に従ってAXFR応答で設定される可能性があります。DNSSEC署名されていないゾーンの場合, ADビットは0であるべきです。DNSSEC対応でないAXFRクライアントはADビットを無視します。

CD: 0であるべきです - CD (Checking Disabled, チェック無効) ビットはリゾルバにのみ関連し, 権威サーバーには関連しません。AXFR応答の場合, CDビットは0であるべきであり, 定義された意味はありません。

RCODE: 応答コードはAXFRクエリの結果を示します。一般的な値には以下が含まれます:

  • NOERROR (0): 転送成功 (成功したAXFR応答シーケンスのすべての回答メッセージはRCODEがNOERRORに設定されます)。
  • FORMERR (1): クエリのフォーマットエラー。
  • SERVFAIL (2): リクエストの処理中のサーバー障害。
  • NOTIMP (4): クエリタイプが実装されていません。
  • REFUSED (5): ポリシーによるゾーン転送の拒否。
  • NOTAUTH (9): サーバーは要求されたゾーンに対して権威を持っていません ([RFC2136] で定義)。

成功したAXFR応答の場合, AXFRセッション内のすべてのDNS応答メッセージのRCODEはNOERRORに設定されなければなりません。AXFRセッション内のDNS応答メッセージのRCODEがNOERROR以外に設定されている場合, AXFRクライアントはゾーン転送が失敗したと見なさなければなりません。

QDCOUNT: 1でなければなりません - 質問セクションは各応答メッセージで繰り返され, クエリから質問をコピーします。

ANCOUNT: 回答セクションのRRの数を示します。値は各応答メッセージに収まるRRの数によって異なります。

NSCOUNT: 0でなければなりません - AXFR応答メッセージには権威セクションは含まれません。

ARCOUNT: EDNS(0), TSIG, またはSIG(0) が使用される場合, 0以上でなければなりません。通常, AXFR応答の場合ARCOUNTは0です。

2.2.2. Question Section (質問セクション)​

応答の質問セクションは, 対応するAXFRクエリの質問セクションと同一でなければなりません。これは, QDCOUNTが1でなければならず, 単一の質問がクエリからの質問と一致しなければならないことを意味します。

2.2.3. Answer Section (回答セクション)​

回答セクションには, 転送されるゾーンデータが含まれます。回答セクションの内容の要件は次のとおりです:

  1. SOA RRs: AXFR応答の最初の回答メッセージの最初のRRは, ゾーンのSOA RRでなければなりません。AXFR応答の最後の回答メッセージの最後のRRも, ゾーンのSOA RRでなければなりません (つまり, 同じSOA RRが転送の最初と最後に表示されます)。

  2. 中間RR: 2つのSOA RR (最初と最後) の間で, 応答メッセージの回答セクションには, ゾーンの他のすべての権威RRが含まれます (セクション3の制限を条件とします)。

  3. 順序: 回答セクションのRRの順序 (最初と最後のSOA RR以外) は未定義です。ただし, 同じRRset (同じ所有者名, クラス, タイプ) のすべてのRRは, 効率のためにグループ化されるべきです。

  4. 複数のメッセージ: ゾーンデータが単一のDNS応答メッセージに収まらない場合, AXFRサーバーは複数の応答メッセージを送信します。最初のメッセージの後の各応答メッセージは追加のゾーンデータを続け, 最後のメッセージは末尾のSOA RRで終了します。

2.2.4. Authority Section (権威セクション)​

AXFR応答メッセージでは権威セクションは空でなければなりません (NSCOUNT = 0)。AXFR応答の権威セクションにNSレコードまたは他の権威データを含めることは明示的に禁止されています。

2.2.5. Additional Section (追加セクション)​

AXFR応答メッセージの追加セクションは一般的に空ですが, これらのオプションがネゴシエートされているか使用されている場合, EDNS(0), TSIG, またはSIG(0) RRが含まれている可能性があります。

EDNS(0): AXFRクエリにEDNS(0) OPT RRが含まれている場合, AXFRサーバーは応答メッセージの追加セクションにOPT RRを含めることができます。AXFR応答のEDNS(0) は主に拡張機能とバッファサイズのシグナリングに使用されます。

TSIG: TSIGが認証に使用される場合, TSIG RRはAXFR応答メッセージの追加セクションに含まれます。TSIG署名は, マルチメッセージAXFR応答で異なる方法で適用されます:

  • 成功したAXFRシーケンスの最初の応答メッセージにはTSIG RRを含めなければなりません。
  • 中間メッセージはTSIG RRを省略できます (署名されていない中間メッセージが許可されています)。
  • 最後の応答メッセージにはTSIG RRを含めなければなりません。

詳細なTSIGの考慮事項については [RFC2845] を参照してください。

SIG(0): SIG(0) が使用される場合, SIG(0) を含む各応答メッセージはそれに応じてARCOUNTをインクリメントします。

2.3. TCP Connection Aborts (TCP接続の中止)​

AXFRクライアントまたはAXFRサーバーは, TCP接続を閉じることによって進行中のAXFRセッションを中止することができます。接続を中止する理由には以下が含まれます:

  • 不正な形式または予期しないDNSメッセージ。
  • タイムアウト (読み取りまたは書き込みタイムアウト)。
  • 認証失敗 (たとえば, TSIG検証失敗)。
  • 内部サーバーエラー。
  • リソースの枯渇。

AXFRクライアントは, 中止された接続をゾーン転送の失敗として解釈しなければなりません。AXFRクライアントは, 接続が閉じられる前に受信した部分的なゾーンデータをコミットしてはなりません。

AXFRサーバーは, TCP接続のクローズを使用して, AXFRクライアントにゾーン転送が失敗したことを示すことができます。

に最終更新