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

1. Introduction (はじめに)

ドメインネームシステムがゾーンの一貫したサーバーを維持するための標準的な設備は, 3つの要素で構成されます。Authoritative Transfer (権威転送, AXFR) は, "Domain Names - Concepts and Facilities" [RFC1034] (このドキュメントではRFC 1034と呼びます) および "Domain Names - Implementation and Specification" [RFC1035] (以下RFC 1035) で定義されています。Incremental Zone Transfer (増分ゾーン転送, IXFR) は, "Incremental Zone Transfer in DNS" [RFC1995] で定義されています。ゾーン変更の迅速な通知のメカニズム (NOTIFY) は, "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996] で定義されています。これらのメカニズムの目標は, 一連のDNSネームサーバーが特定のゾーンに対して一貫して権威を持つことを可能にすることです。

このドキュメントは, インターネット全体に展開されているAXFRメカニズムを再指定し, できれば現代のインターネット標準に期待される精度で, それによってRFC 1034およびRFC 1035を更新します。

1.1. Definition of Terms (用語の定義)​

このドキュメントのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は, "Key words for use in RFCs to Indicate Requirement Levels" [BCP14] に記述されているように解釈されるものとします。

"newer"/"new" および "older"/"old" DNSの使用は, このドキュメントの公開後および公開前に書かれた実装を指します。

"General-purpose DNS implementation" (汎用DNS実装) とは, 広く使用するために開発されたDNSソフトウェアを指します。これには, ライブラリおよびスタンドアロンプロセスとして自由にアクセスできるリゾルバとサーバーが含まれます。これには, DNSサービス提供のサポートにのみ使用される独自の実装も含まれます。

"Turnkey DNS implementation" (専用DNS実装) とは, カスタムメイドの単一用途のDNS実装を指します。このような実装は, DNSプロトコルメッセージフォーマットを採用しているが, DNS機能の全範囲には準拠していないソフトウェアで構成されます。

"AXFR session" (AXFRセッション), "AXFR server" (AXFRサーバー), および "AXFR client" (AXFRクライアント) という用語は, さらにコンテキストが確立された後の第2節の最初の段落で紹介されます。

1.2. Scope (スコープ)​

一般的に言えば, 特定のゾーンの権威ネームサーバーは, 提供するゾーンコンテンツの一貫性を達成するためにさまざまな手段を使用できます。たとえば, リレーショナルデータベースに格納されたデータから回答を組み立てるDNS実装があり (マスターファイルとは対照的に), データベースの非DNS手段に依存してデータベースインスタンスを同期します。これらの非DNSソリューションのいくつかは, ある形で相互運用します。ただし, AXFR, IXFR, およびNOTIFYは, 一連のネームサーバーの一貫性を提供するためのプロトコル定義のインバンドメカニズムであり, IETFによって指定された唯一のメカニズムです。

このドキュメントは, 非一貫性のDNS状況をカバーしていません。ゾーンのサーバーが一貫していることを意図していないDNSのアプリケーションがあります。

1.3. Context (コンテキスト)​

AXFRクライアントは, AXFRサーバーからゾーンのコンテンツを受信するためにクエリを発行します。このような転送はDNSクエリタイプであり, クエリヘッダーおよび応答メッセージを含むDNSプロトコル仕様に準拠しています。

ゾーンコンテンツは, ゾーン内のドメイン名が所有する権威DNS RRです。通常, ゾーンのすべての権威RRはAXFRセッションによって転送されますが, 1つの例外があります。ゾーンカットに従う場合, グルーレコードは転送されません。

ゾーン転送は, DNS SOAリフレッシュタイマー, NOTIFYメッセージ, またはオペレーターの介入によって開始されます (ただし, 他の手段も排除されません)。AXFRは, 多くの場合, ゾーンのプライマリサーバーのセカンダリとして特別に構成されたサーバーに限定され, 他のクライアントからのクエリは拒否されます。

元の1035定義では, AXFRがTCP上で実行されることが指定されていました。この仕様は, TCP上のAXFRのみをサポートします。ただし, 完全性のために, この仕様では情報付録でAXFR-over-UDPについて言及しています。

AXFRセッションは, 1つのAXFRクエリメッセージ, 1つ以上のAXFR応答メッセージ, および最後にTCP接続の終了で構成されます。次の2つの条件が成り立つ場合, AXFRセッションは "成功" したと言われます: (1) AXFRクライアントが成功したAXFR応答シーケンスを受信し, (2) AXFRクライアントがTCP接続を閉じたか, クライアントがAXFRサーバーがTCP接続を閉じたことの確認を受信しました。

このドキュメントはゾーン転送のセキュリティには対応していません。関連するセキュリティの考慮事項は第8節で説明されています。

1.4. Coverage and Relationship to Original AXFR Specification (カバレッジと元のAXFR仕様との関係)​

このドキュメントは, DNS UPDATE非対応の権威的な, プライマリからセカンダリへのAXFRセッションをカバーし, セキュリティは採用されておらず, 転送されるゾーンはIPv4トランスポート用の "通常の" DNSゾーンです。つまり, サーバーはゾーンのマスターまたはプライマリであり, クライアントはセカンダリまたはスレーブサーバーです。この定義は, 追加のパラメータ値のカバレッジを示す拡張メカニズムを許可する方法で書かれています。

参考のために, このドキュメントは以下に注意しています (ただし, これらの変種のいずれも定義していません):

  • ゾーン転送は, スレーブと別のスレーブの間で実施できます (すべてが権威サーバーです)。

  • ゾーン転送クライアントは, データを収集するリゾルバまたはゾーンバリデータである可能性があります (非権威アプリケーション)。

  • "増分転送" を許可するオプションのプロトコル拡張があります -- Incremental Zone Transfer (IXFR) [RFC1995]。

  • DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], およびRFC 4035 [RFC4035] を介して) は, DNSのセキュリティプロトコルを定義します。

  • DNS UPDATE (RFC 2136 [RFC2136]) は, ゾーンを動的に更新できる手段を提供します。

  • IPv6トランスポートが使用される場合があります。

これらに言及する目的は, このドキュメントで説明されているメカニズムが特定のシナリオにのみ適用されるが, いくつかのコンテキストを提供するためにこのドキュメントを参照する関連するシナリオがあることを明確にすることです。リストされた変種はすべて同等ではなく, 確かに互いに独立しておらず, このドキュメントの範囲内にあるかどうかはわかりません。

このドキュメントは意図的に範囲が狭いですが, 拡張可能なメカニズムを説明していることを示すように書かれています。

に最終更新