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

4. Transport (トランスポート)

このセクションでは, AXFRのトランスポートプロトコル要件について説明します。元のDNS仕様では, AXFRがTCP上で動作することが定義されており, これはAXFRの唯一の標準化されたトランスポートのままです。

4.1. TCP​

AXFRはそのトランスポートプロトコルとしてTCPを使用しなければなりません。TCPは, ゾーン転送の整合性に不可欠な, 信頼性が高く, 順序付けられ, エラーチェックされたデータ配信を提供します。

4.1.1. AXFR Client TCP (AXFRクライアントTCP)​

AXFRクライアントは, AXFRサーバーのDNSポート (通常はポート53, ただし他のポートが構成されている場合があります) へのTCP接続を確立します。

接続確立:

  1. AXFRクライアントは, AXFRサーバーとの接続を確立するためにTCP三方向ハンドシェイクを開始します。

  2. TCP接続が確立されると, AXFRクライアントはセクション2.1で指定されたAXFRクエリメッセージを送信します。

  3. その後, AXFRクライアントは, AXFRサーバーがゾーンデータを含む1つ以上のDNS応答メッセージで応答するのを待ちます。

接続の永続性:

  1. AXFRクライアントは, 完全なゾーン転送を受信するまでTCP接続を開いたままにすべきです。これは, 応答メッセージの回答セクションで最終SOA RRを受信したことで示されます。

  2. 完全なゾーン転送を受信した後, AXFRクライアントはTCP接続を閉じることができます。または, 追加のクエリを送信するために開いたままにすることができます (ただし, これはAXFRの典型的な動作ではありません)。

  3. AXFRクライアントは, ゾーン転送を完了した直後を含め, AXFRサーバーがいつでもTCP接続を閉じる準備をしなければなりません。

タイムアウト:

  1. AXFRクライアントは, 応答しないサーバーやネットワークの問題を検出するために, 読み取りおよび書き込みタイムアウトを実装すべきです。

  2. 推奨されるタイムアウト値は, ゾーンのサイズとネットワーク条件によって異なりますが, 典型的な読み取りタイムアウトは, 大きなゾーンに対応するために数分の範囲 (たとえば, 5〜10分) である可能性があります。

  3. タイムアウトが発生した場合, AXFRクライアントはTCP接続を閉じ, ゾーン転送を失敗として扱うべきです。

エラー処理:

  1. AXFRクライアントがNOERROR以外のRCODEを持つDNS応答メッセージを受信した場合, ゾーン転送を失敗として扱い, TCP接続を閉じなければなりません。

  2. AXFRクライアントが不正な形式のDNSメッセージまたはAXFRプロトコルに準拠していないメッセージを受信した場合, TCP接続を閉じてゾーン転送を失敗として扱うべきです。

  3. 最終SOA RRを受信する前にTCP接続が早期に閉じられた場合, AXFRクライアントはゾーン転送を失敗として扱い, 受信した部分的なゾーンデータを破棄しなければなりません。

複数のクエリ:

  1. AXFRクライアントは, 同じTCP接続を介して複数のAXFRクエリを送信することができます。これは "パイプライン化" または "接続の再利用" として知られる慣行です。ただし, この動作は広く実装または要求されていません。

  2. AXFRクライアントが複数のクエリを送信する場合, 次のクエリを送信する前に, 最初のクエリへの完全な応答 (最終SOA RRを含む) を待たなければなりません。

  3. AXFRサーバーは, 接続ごとに複数のクエリをサポートする必要はなく, 単一のクエリに応答した後に接続を閉じることができます。

4.1.2. AXFR Server TCP (AXFRサーバーTCP)​

AXFRサーバーは, そのDNSポート (通常はポート53) で着信TCP接続をリッスンします。

接続処理:

  1. TCP接続を受け入れた後, AXFRサーバーはAXFRクライアントからDNSクエリメッセージを受信するのを待ちます。

  2. AXFRサーバーは, クエリメッセージを解析して, それが有効なAXFRクエリであるかどうかを判断します (セクション2.1で定義されているとおり)。

  3. クエリと適用可能なポリシー (たとえば, ACL, TSIG認証) に基づいて, AXFRサーバーはゾーンデータで応答するか, エラーメッセージで応答します。

応答転送:

  1. ゾーン転送が承認された場合, AXFRサーバーは, セクション2.2で指定されているように, ゾーンデータを含む1つ以上のDNS応答メッセージを送信します。

  2. 各応答メッセージは, TCP接続を介して完全なDNSメッセージとして送信されます。AXFRサーバーは, メッセージ境界が保持されることを保証しなければなりません (つまり, 各DNSメッセージの前に, RFC 1035セクション4.2.2で指定されているように2バイトの長さフィールドが付いています)。

  3. AXFRサーバーは, すべてのゾーンデータ (最終SOA RRを含む) が送信されるまで応答メッセージを送信し続けます。

接続終了:

  1. 最終応答メッセージ (末尾のSOA RRを含む) を送信した後, AXFRサーバーはすぐにTCP接続を閉じることができます。または, 追加のクエリを受け入れるために開いたままにすることができます。

  2. AXFRサーバーは, リソースを解放するために, 合理的なタイムアウト期間後にアイドル接続を閉じるべきです。

  3. エラーが発生した場合 (たとえば, 書き込みエラー, タイムアウト, または内部エラー), AXFRサーバーはいつでも接続を閉じることができます。

並行性:

  1. AXFRサーバーは, 複数の並行AXFRセッション (つまり, 異なるクライアントからの複数のTCP接続) を処理できるべきです。

  2. AXFRサーバーは, リソースの枯渇を防ぐために, 並行ゾーン転送の数に制限を課すことができます。

4.2. UDP​

AXFR over UDP (UDPを介したAXFR) は標準化されておらず, 汎用DNS実装では使用してはなりません。初期のDNS仕様では, 小さなゾーンのAXFR over UDPの可能性が言及されていましたが, このアプローチには重大な制限があります:

  1. 信頼性: UDPは信頼性の低いプロトコルであり, パケットの配信や順序を保証しません。

  2. メッセージサイズ: UDP上のDNSメッセージはサイズが制限されています (EDNS(0) なしで通常512バイト, EDNS(0) で最大4096バイト), ほとんどのゾーン転送には実用的ではありません。

  3. 標準化の欠如: 現代のDNS仕様には, AXFR over UDPの標準化されたフォーマットや動作はありません。

これらの理由により, AXFR over UDPは廃止されたと見なされ, 新しいDNSソフトウェアに実装してはなりません。古いDNSドキュメント内のAXFR over UDPへの参照はすべて歴史的なものであり, 無視すべきです。

推奨事項: AXFRクライアントとサーバーはTCPを使用しなければなりません。何らかの理由でUDPベースのゾーン同期が必要な場合, 実装者はUDPを介したIXFR [RFC1995] の使用を検討すべきですが, IXFRでさえ通常TCPを介して実施されます。

に最終更新