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

7. Backwards Compatibility (後方互換性)

元の定義の詳細が不足しているため, 後方互換性を説明することは困難です。このセクションでは, 後方互換性を構築するためのヒントをいくつか示します。これらは主に関連する以前のセクションから繰り返されたものです。

後方互換性は必須ではありませんが, 実装の互換性の程度が高いほど, その相互運用性も高くなります。専用実装の場合, これは通常問題になりません。汎用実装の場合, これは実装者が相互運用性を維持したいという願望に応じて, さまざまなレベルの重要性を持ちます。

残念ながら, 古い動作に戻る必要性を発見することはできないため, 構成ファイルに記録する必要があります。実装は, そのドキュメントで, 繰り返しメモを作成したAXFRクライアントとサーバーを定期的に確認するようオペレーターに推奨すべきです。古いソフトウェアは時々更新されるためです。

7.1. Server (サーバー)​

AXFRサーバーは, クライアントが各AXFR応答メッセージで複数のリソースレコードを受け入れることができるかどうかを知ることができないことを除いて, AXFRクライアントの能力に反応できるという利点があります。クライアントがそのように制限されているという知識は発見できません。したがって, 構成によって設定する必要があります。

AXFRサーバーの実装は, AXFRクライアントごとに, メッセージごとに単一のリソースレコードに戻す必要性を構成することを許可することができます。その場合, デフォルトはメッセージごとに複数のレコードを使用することであるべきです。

レガシークライアントの考慮事項:

  1. メッセージごとの単一RR: 一部の非常に古いDNS実装は, 各AXFR応答メッセージの回答セクションに単一のリソースレコードのみを期待します。効率のために, 現代のAXFRサーバーはメッセージごとに複数のRRをサポートすべきですが, 特定のレガシークライアント用に単一RR動作に戻すための構成オプションを提供することができます。

  2. メッセージサイズ: 古いクライアントは, 処理できるDNSメッセージの最大サイズに制限がある場合があります。AXFRサーバーは, そのようなクライアントと対話するときに個々の応答メッセージのサイズを制限する構成オプションを提供することができます。

  3. EDNS(0), TSIG, およびSIG(0): 古いクライアントはEDNS(0), TSIG, またはSIG(0) をサポートしていない場合があります。AXFRサーバーは, これらのオプションを含まないクライアントからのクエリを適切に処理すべきであり, セキュリティ上の理由で特別に構成されていない限り, それらの存在を要求すべきではありません。

サーバー実装の推奨事項:

  • デフォルトで現代的で効率的な動作 (メッセージごとに複数のRR, EDNS(0)/TSIG/SIG(0) のサポート)。
  • クライアントごとにレガシークライアントに対応するための構成オプションを提供します。
  • 既知の互換性問題と, 古いソフトウェアとの相互運用のための推奨構成設定を文書化します。

7.2. Client (クライアント)​

AXFRクライアントは, AXFRサーバーにクエリを実行するときに他の機能 (つまり, このドキュメントで定義されていない機能) を試す機会があります。

AXFRセッションのTCPトランスポートを介して複数のDNSクエリを発行しようとする試みは, 元のリクエストを中断する場合は中止すべきであり, AXFRサーバーが元の (接続を引き起こす) ゾーン転送の完了後すぐに接続を閉じることを意図しているかどうかを考慮すべきです。

レガシーサーバーの考慮事項:

  1. メッセージごとの複数RR: 現代のAXFRクライアントは, 単一のAXFR応答メッセージで複数のリソースレコードを受信する準備をしなければなりません。これは標準的な動作であり, 長年にわたって広く展開されています。

  2. 接続処理: 古いサーバーは, 最終SOA RRを送信した後すぐにTCP接続を閉じる場合があり, 他のサーバーは一定期間接続を開いたままにする場合があります。AXFRクライアントはどちらの動作にも対応できるように準備すべきであり, ゾーン転送が完了した後も接続が開いたままであることに依存すべきではありません。

  3. エラー応答: 一部の古いサーバーは非標準エラー応答を返す場合があり, DNSメッセージフォーマットに厳密に準拠していない場合があります。AXFRクライアントは, 予期しない応答を適切に処理するために堅牢なエラー処理を実装すべきです。

クライアント実装の推奨事項:

  • このドキュメントで定義されているすべての標準機能をサポートします。
  • 仕様からの小さな逸脱を許容するために堅牢なエラー処理を実装します。
  • 接続の永続性やその他の非標準動作に依存しないようにします。
  • サーバーがEDNS(0) をサポートしていないように見える場合は, より簡単な動作 (たとえば, EDNS(0) を使用しない) にフォールバックする準備をします。
に最終更新