[要約] RFC 5936は、DNSゾーン転送プロトコル（AXFR）に関する仕様です。このRFCの目的は、DNSゾーンの転送を安全かつ効率的に行うためのプロトコルを定義することです。
Internet Engineering Task Force (IETF) E. Lewis
Request for Comments: 5936 NeuStar, Inc.
Updates: 1034, 1035 A. Hoenes, Ed.
Category: Standards Track TR-Sys
ISSN: 2070-1721 June 2010
DNS Zone Transfer Protocol (AXFR)
DNSゾーン転送プロトコル（AXFR）
Abstract
概要
The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.
ゾーンの信頼できる名前サーバー間のコヒーレンスを維持するためのドメイン名システムプロトコル内の標準手段は、3つのメカニズムで構成されています。権威ある転送（AXFR）はメカニズムの1つであり、RFC 1034およびRFC 1035で定義されています。
The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism.
AXFRの定義は詳細に不十分であることが証明されており、それにより、相互運用性を妨げる仮定を行うために準拠することを目的とした実装を強制します。しかし、今日、私たちは相互運用を行う満足のいく実装セットを持っています。このドキュメントは、AXFRの新しい定義であり、相互運用可能なAXFRメカニズムの正確な定義を記録するという意味で新しくなります。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5936.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5936で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Definition of Terms ........................................4
1.2. Scope ......................................................5
1.3. Context ....................................................5
1.4. Coverage and Relationship to Original AXFR Specification ...5
2. AXFR Messages ...................................................6
2.1. AXFR Query .................................................8
2.1.1. Header Values .......................................8
2.1.2. Question Section ...................................10
2.1.3. Answer Section .....................................10
2.1.4. Authority Section ..................................10
2.1.5. Additional Section .................................10
2.2. AXFR Response .............................................11
2.2.1. Header Values ......................................12
2.2.2. Question Section ...................................14
2.2.3. Answer Section .....................................14
2.2.4. Authority Section ..................................14
2.2.5. Additional Section .................................14
2.3. TCP Connection Aborts .....................................15
3. Zone Contents ..................................................15
3.1. Records to Include ........................................15
3.2. Delegation Records ........................................16
3.3. Glue Records ..............................................18
3.4. Name Compression ..........................................19
3.5. Occluded Names ............................................19
4. Transport ......................................................20
4.1. TCP .......................................................20
4.1.1. AXFR Client TCP ....................................21
4.1.2. AXFR Server TCP ....................................22
4.2. UDP .......................................................22
5. Authorization ..................................................22
6. Zone Integrity .................................................23
7. Backwards Compatibility ........................................24
7.1. Server ....................................................24
7.2. Client ....................................................25
8. Security Considerations ........................................25
9. IANA Considerations ............................................25
10. Internationalization Considerations ...........................25
11. Acknowledgments ...............................................25
12. References ....................................................26
12.1. Normative References .....................................26
12.2. Informative References ...................................28
The Domain Name System standard facilities for maintaining coherent servers for a zone consist of three elements. Authoritative Transfer (AXFR) is defined in "Domain Names - Concepts and Facilities" [RFC1034] (referred to in this document as RFC 1034) and "Domain Names - Implementation and Specification" [RFC1035] (henceforth RFC 1035). Incremental Zone Transfer (IXFR) is defined in "Incremental Zone Transfer in DNS" [RFC1995]. A mechanism for prompt notification of zone changes (NOTIFY) is defined in "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of these mechanisms is to enable a set of DNS name servers to remain coherently authoritative for a given zone.
ゾーンのコヒーレントサーバーを維持するためのドメイン名システム標準設備は、3つの要素で構成されています。権威ある転送（AXFR）は、「ドメイン名 - 概念と施設」[RFC1034]（このドキュメントではRFC 1034と呼ばれる）および「ドメイン名 - 実装と仕様」[RFC1035]（以降RFC 1035）で定義されています。増分ゾーン転送（IXFR）は、「DNSの増分ゾーン転送」[RFC1995]で定義されます。ゾーン変更の迅速な通知（Notify）のメカニズムは、「ゾーンの変更（DNS通知）の迅速な通知のメカニズム」[RFC1996]で定義されています。これらのメカニズムの目標は、DNS名サーバーのセットが特定のゾーンに対して一貫した権威あるままであることを可能にすることです。
This document re-specifies the AXFR mechanism as it is deployed in the Internet at large, hopefully with the precision expected from modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.
このドキュメントは、AXFRメカニズムがインターネット全体に展開されているため、最新のインターネット標準から予想される精度で展開され、RFC 1034およびRFC 1035を更新することを願っています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [BCP14].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、「要件レベルを示すためにRFCで使用するためのキーワード」で説明されているように解釈される[BCP14]。
Use of "newer"/"new" and "older"/"old" DNS refers to implementations written after and prior to the publication of this document.
「新しい」/「新しい」および「古い」/「古い」DNSの使用とは、このドキュメントの公開前後に書かれた実装を指します。
"General-purpose DNS implementation" refers to DNS software developed for widespread use. This includes resolvers and servers freely accessible as libraries and standalone processes. This also includes proprietary implementations used only in support of DNS service offerings.
「汎用DNS実装」とは、広く使用するために開発されたDNSソフトウェアを指します。これには、ライブラリやスタンドアロンプロセスとして自由にアクセスできるリゾルバーとサーバーが含まれます。これには、DNSサービスの提供をサポートするためにのみ使用される独自の実装も含まれます。
"Turnkey DNS implementation" refers to custom-made, single-use implementations of DNS. Such implementations consist of software that employs the DNS protocol message format yet does not conform to the entire range of DNS functionality.
「Turnkey DNS実装」とは、DNSのカスタムメイドの使い捨て実装を指します。このような実装は、DNSプロトコルメッセージ形式を採用しているが、DNS機能の全範囲に準拠していないソフトウェアで構成されています。
The terms "AXFR session", "AXFR server", and "AXFR client" will be introduced in the first paragraph of Section 2, after some more context has been established.
「AXFRセッション」、「AXFRサーバー」、および「AXFRクライアント」という用語は、いくつかのコンテキストが確立された後、セクション2の最初の段落で導入されます。
In general terms, authoritative name servers for a given zone can use various means to achieve coherency of the zone contents they serve. For example, there are DNS implementations that assemble answers from data stored in relational databases (as opposed to master files), relying on the database's non-DNS means to synchronize the database instances. Some of these non-DNS solutions interoperate in some fashion. However, AXFR, IXFR, and NOTIFY are the only protocol-defined in-band mechanisms to provide coherence of a set of name servers, and they are the only mechanisms specified by the IETF.
一般的に、特定のゾーンの信頼できる名前サーバーは、さまざまな手段を使用して、提供するゾーンコンテンツの一貫性を実現できます。たとえば、データベースの非DNSに依存することで、データベースインスタンスを同期するためにデータベースの非DNSに依存することで、関連データベースに保存されたデータから回答を組み立てるDNS実装があります。これらの非DNSソリューションのいくつかは、何らかの形で相互操作します。ただし、AXFR、IXFR、およびNotifyは、一連の名前サーバーのコヒーレンスを提供する唯一のプロトコル定義インバンドメカニズムであり、IETFによって指定された唯一のメカニズムです。
This document does not cover incoherent DNS situations. There are applications of the DNS in which servers for a zone are designed to be incoherent. For these configurations, a coherency mechanism as described here would be unsuitable.
このドキュメントでは、一貫性のないDNSの状況をカバーしていません。ゾーンのサーバーが一貫性のないように設計されているDNSのアプリケーションがあります。これらの構成では、ここで説明するコヒーレンシーメカニズムは不適切です。
A DNS implementation is not required to support AXFR, IXFR, and NOTIFY, but it should have some means for maintaining name server coherency. A general-purpose DNS implementation will likely support AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS implementations may exist without AXFR.
AXFR、IXFR、およびNotifyをサポートするためにDNSの実装は必要ありませんが、名前サーバーの一貫性を維持するための何らかの手段があるはずです。汎用のDNS実装は、AXFRをサポートする可能性があります（および同じVein IXFRおよび通知）が、AXFRなしでターンキーDNSの実装が存在する場合があります。
Besides describing the mechanisms themselves, there is the context in which they operate to consider. In the initial specifications of AXFR (and IXFR and NOTIFY), little consideration was given to security and privacy issues. Since the original definition of AXFR, new opinions have appeared on the access to an entire zone's contents. In this document, the basic mechanisms will be discussed separately from the permission to use these mechanisms.
メカニズム自体を説明することに加えて、それらが検討するために動作するコンテキストがあります。AXFRの最初の仕様（およびIXFRおよび通知）では、セキュリティとプライバシーの問題についてはほとんど考慮されませんでした。AXFRの元の定義以来、ゾーン全体のコンテンツへのアクセスに関する新しい意見が表示されています。このドキュメントでは、基本的なメカニズムについては、これらのメカニズムを使用する許可とは別に説明します。
This document concentrates on just the definition of AXFR. Any effort to update the specification of the IXFR or NOTIFY mechanisms is left to different documents.
このドキュメントは、AXFRの定義のみに集中しています。IXFRの仕様または通知メカニズムの仕様を更新する努力は、さまざまなドキュメントに任されています。
The original "specification" of the AXFR sub-protocol is scattered through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 (on page 5) depicts the scenario for which AXFR has been designed. Section 4.3.5 of RFC 1034 describes the zone synchronization strategies in general and rules for the invocation of a full zone transfer via AXFR; the fifth paragraph of that section contains a very short sketch of the AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant flaw in that specification. Section 3.2.3 of RFC 1035 has assigned the code point for the AXFR QTYPE (see Section 2.1.2 below for more details). Section 4.2 of RFC 1035 discusses how the DNS uses the transport layer and briefly explains why UDP transport is deemed inappropriate for AXFR; the last paragraph of Section 4.2.2 gives details regarding TCP connection management for AXFR. Finally, the second paragraph of Section 6.3 in RFC 1035 mandates server behavior when zone data changes occur during an ongoing zone transfer using AXFR.
AXFRサブプロトコルの元の「仕様」は、RFC 1034およびRFC 1035に散らばっています。RFC1035のセクション2.2（5ページ）は、AXFRが設計されたシナリオを示しています。RFC 1034のセクション4.3.5では、一般的なゾーン同期戦略と、AXFRを介したフルゾーン転送の呼び出しの規則について説明します。そのセクションの5番目の段落には、AXFRプロトコルの非常に短いスケッチが含まれています。RFC 2181のセクション5.5は、その仕様の重大な欠陥を修正しました。RFC 1035のセクション3.2.3は、AXFR QTYPEのコードポイントを割り当てました（詳細については、以下のセクション2.1.2を参照）。RFC 1035のセクション4.2では、DNSが輸送層を使用する方法について説明し、UDP輸送がAXFRに不適切と見なされる理由について簡単に説明します。セクション4.2.2の最後の段落では、AXFRのTCP接続管理に関する詳細を示します。最後に、RFC 1035のセクション6.3の2番目の段落は、AXFRを使用した継続的なゾーン転送中にゾーンデータの変更が発生したときにサーバーの動作を義務付けます。
This document will update the specification of AXFR. To this end, it fully specifies the record formats and processing rules for AXFR, largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it details the transport considerations for AXFR, thus amending Section 4.2.2 of RFC 1035. Furthermore, it discusses backward-compatibility issues and provides policy/management considerations, as well as specific security considerations for AXFR. The goal of this document is to define AXFR as it is understood by the DNS community to exist today.
このドキュメントでは、AXFRの仕様を更新します。この目的のために、AXFRのレコード形式と処理ルールを完全に指定し、RFC 1034のセクション4.3.5のパラグラフ5で主に拡大し、AXFRの輸送に関する考慮事項を詳しく説明しているため、RFC 1035のセクション4.2.2を修正します。、それは、後方互換性の問題について議論し、AXFRの具体的なセキュリティに関する考慮事項と同様に、ポリシー/管理の考慮事項を提供します。このドキュメントの目標は、DNSコミュニティが今日存在すると理解されているAXFRを定義することです。
An AXFR session consists of an AXFR query message and the sequence of AXFR response messages returned for it. In this document, the AXFR client is the sender of the AXFR query, and the AXFR server is the responder. (Use of terms such as master, slave, primary, and secondary are not important for defining AXFR.) The use of the word "session" without qualification refers to an AXFR session.
AXFRセッションは、AXFRクエリメッセージとAXFR応答メッセージのシーケンスで構成されています。このドキュメントでは、AXFRクライアントはAXFRクエリの送信者であり、AXFRサーバーはレスポンダーです。（マスター、スレーブ、プライマリ、セカンダリーなどの用語の使用は、AXFRを定義するために重要ではありません。）資格なしの「セッション」という単語の使用は、AXFRセッションを指します。
An important aspect to keep in mind is that the definition of AXFR is restricted to TCP [RFC0793] (see Section 4 for details). The design of the AXFR process has certain inherent features that are not easily ported to UDP [RFC0768].
留意すべき重要な側面は、AXFRの定義がTCP [RFC0793]に限定されていることです（詳細についてはセクション4を参照）。AXFRプロセスの設計には、UDP [RFC0768]に簡単に移植されない特定の固有の機能があります。
The basic format of an AXFR message is the DNS message as defined in Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the following documents.
AXFRメッセージの基本形式は、次のドキュメントで更新されたRFC 1035 [RFC1035]のセクション4（「メッセージ」）で定義されているDNSメッセージです。
o The "Basic" DNS specification:
o 「基本的な」DNS仕様：
- "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]
- 「ゾーンの変更の迅速な通知のメカニズム（DNS通知）」[RFC1996]
- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
- 「ドメイン名システムの動的更新（DNSアップデート）」[RFC2136]
- "Clarifications to the DNS Specification" [RFC2181]
- 「DNS仕様の説明」[RFC2181]
- "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
- 「DNSの拡張メカニズム（EDNS0）」[RFC2671]
- "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
- 「DNSのシークレットキートランザクション認証（TSIG）」[RFC2845]
- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
- 「DNSの秘密の鍵施設（TKEYRR）」[RFC2930]
- "Obsoleting IQUERY" [RFC3425]
- 「廃止」[RFC3425]
- "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
- 「不明なDNSリソースレコード（RR）タイプの処理」[RFC3597]
- "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers" [RFC4635]
- 「HMAC SHA（ハッシュメッセージ認証コード、セキュアハッシュアルゴリズム）TSIGアルゴリズム識別子」[RFC4635]
- "Domain Name System (DNS) IANA Considerations" [RFC5395]
- 「ドメイン名システム（DNS）IANAの考慮事項」[RFC5395]
o Further additions related to the DNS Security Extensions (DNSSEC), defined in these base documents:
o これらのベースドキュメントで定義されているDNSセキュリティ拡張機能（DNSSEC）に関連するさらなる追加：
- "DNS Security Introduction and Requirements" [RFC4033]
- 「DNSセキュリティの紹介と要件」[RFC4033]
- "Resource Records for the DNS Security Extensions" [RFC4034]
- 「DNSセキュリティエクステンションのリソースレコード」[RFC4034]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035]
- 「DNSセキュリティ拡張機能のプロトコル変更」[RFC4035]
- "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)" [RFC4509]
- 「DNSSEC代表団の署名者（DS）リソースレコード（RRS）でのSHA-256の使用」[RFC4509]
- "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence" [RFC5155]
- 「DNSセキュリティ（DNSSEC）は認証された存在の拒否をハッシュする」[RFC5155]
- "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC" [RFC5702]
- 「DNSKEYのRSAとDNSSECのRRSIGリソースレコードを使用したSHA-2アルゴリズムの使用」[RFC5702]
- "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]
- 「DNSSECBISの説明と実装ノート」[DNSSEC-U]
These documents contain information about the syntax and semantics of DNS messages. They do not interfere with AXFR but are also helpful in understanding what will be carried via AXFR.
これらのドキュメントには、DNSメッセージの構文とセマンティクスに関する情報が含まれています。彼らはAXFRに干渉するのではなく、AXFRを介して何が運ばれるかを理解するのにも役立ちます。
For convenience, the synopsis of the DNS message header from [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is reproduced here informally:
便宜上、[RFC5395]からのDNSメッセージヘッダーの概要（およびDNSパラメーターのIANAレジストリ[DNSVALS]）は、ここで非公式に再現されています。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
This document makes use of the field names as they appear in this diagram. The names of sections in the body of DNS messages are capitalized in this document for clarity, e.g., "Additional section".
このドキュメントは、この図に表示されるフィールド名を使用します。DNSメッセージの本文内のセクションの名前は、明確にするためにこのドキュメントで大文字になります。たとえば、「追加セクション」。
The DNS message size limit from [RFC1035] for DNS over UDP (and its extension via the EDNS0 mechanism specified in [RFC2671]) is not relevant for AXFR, as explained in Section 4. The upper limit on the permissible size of a DNS message over TCP is only restricted by the TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a two-octet message length field, understood to be unsigned, and thus causing a limit of 65535 octets. This limit is not changed by EDNS0.
UDP上のDNSの[RFC1035]からのDNSメッセージサイズ制限（および[RFC2671]で指定されたEDNS0メカニズムを介した拡張）は、セクション4で説明されているように、AXFRには関係ありません。TCPを超えると、RFC 1035のセクション4.2.2で定義されたTCPフレーミングによってのみ制限されています。これは、署名されていないと理解されている2オクテットのメッセージ長フィールドを指定し、65535オクテットの制限を引き起こします。この制限はEDNS0によって変更されません。
Note that the TC (truncation) bit is never set by an AXFR server nor considered/read by an AXFR client.
TC（切り捨て）ビットは、AXFRサーバーによって設定されたり、AXFRクライアントによって検討/読み取られることはないことに注意してください。
An AXFR query is sent by a client whenever there is a reason to ask. This might be because of scheduled or triggered zone maintenance activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996], respectively) or as a result of a command line request, say for debugging.
AXFRクエリは、尋ねる理由があるときはいつでもクライアントによって送信されます。これは、ゾーンメンテナンスのスケジュールまたはトリガーされたゾーンメンテナンス活動が原因である可能性があります（それぞれRFC 1034およびDNSが[RFC1996]に通知するセクション4.3.5を参照）、またはコマンドライン要求の結果として、デバッグについて。
These are the DNS message header values for an AXFR query.
これらは、AXFRクエリのDNSメッセージヘッダー値です。
ID Selected by client; see Note a)
クライアントが選択したID。注を参照a）
QR MUST be 0 (Query)
QRは0（クエリ）でなければなりません
OPCODE MUST be 0 (Standard Query) Flags: AA "n/a" -- see Note b) TC "n/a" -- see Note b) RD "n/a" -- see Note b) RA "n/a" -- see Note b) Z "mbz" -- see Note c) AD "n/a" -- see Note b) CD "n/a" -- see Note b)
opcodeは0（標準クエリ）フラグ：aa "n/a" - 注b）tc "n/a"を参照してください - 注B）rd "n/a"を参照 - 注B）ra "n/a " - 注B）Z" MBZ "を参照 - 注Cを参照）ad" n/a " - 注b）cd" n/a " - 注Bを参照）
RCODE MUST be 0 (No error)
rcodeは0である必要があります（エラーなし）
QDCOUNT Number of entries in Question section; MUST be 1
QdCount問題セクションのエントリ数。1でなければなりません
ANCOUNT Number of entries in Answer section; MUST be 0
回答セクションのエントリの数。0でなければなりません
NSCOUNT Number of entries in Authority section; MUST be 0
nscount Authority Sectionのエントリの数。0でなければなりません
ARCOUNT Number of entries in Additional section -- see Note d)
追加セクションのエントリの数 - 注記を参照）
Notes:
ノート：
a) Set to any value that the client is not already using with the same server. There is no specific means for selecting the value in this field. (Recall that AXFR is done only via TCP connections -- see Section 4, "Transport".)
a) クライアントが同じサーバーでまだ使用していない任意の値に設定します。このフィールドで値を選択するための特定の手段はありません。（AXFRはTCP接続を介してのみ行われていることを思い出してください - セクション4「Transport」を参照してください。）
A server MUST reply using messages that use the same message ID to allow a client to have multiple queries outstanding concurrently over the same TCP connection -- see Note a) in Section 2.2.1 for more details.
サーバーは、同じメッセージIDを使用して、クライアントが同じTCP接続で複数のクエリを同時に発行できるようにするメッセージを使用して返信する必要があります。詳細については、セクション2.2.1の注aを参照してください。
b) "n/a" -- The value in this field has no meaning in the context of AXFR query messages. For the client, it is RECOMMENDED that the value be zero. The server MUST ignore this value.
b) 「n/a」 - このフィールドの値には、AXFRクエリメッセージのコンテキストでは意味がありません。クライアントの場合、値をゼロにすることをお勧めします。サーバーはこの値を無視する必要があります。
c) "mbz" -- The client MUST set this bit to 0; the server MUST ignore it.
c) 「MBZ」 - クライアントはこのビットを0に設定する必要があります。サーバーはそれを無視する必要があります。
d) The client MUST set this field to the number of resource records it places into the Additional section. In the absence of explicit specification of new RRs to be carried in the Additional section of AXFR queries, the value MAY be 0, 1, or 2. See Section 2.1.5, "Additional Section", for details on the currently applicable RRs.
d) クライアントは、このフィールドを追加セクションに配置するリソースレコードの数に設定する必要があります。AXFRクエリの追加セクションで実施される新しいRRの明示的な仕様がない場合、値は0、1、または2になる場合があります。現在該当するRRの詳細については、セクション2.1.5、「追加セクション」を参照してください。
The Question section of the AXFR query MUST conform to Section 4.1.2 of RFC 1035, and contain a single resource record with the following values:
AXFRクエリの質問セクションには、RFC 1035のセクション4.1.2に適合し、次の値を持つ単一のリソースレコードが含まれている必要があります。
QNAME the name of the zone requested
QName要求されたゾーンの名前
QTYPE AXFR (= 252), the pseudo-RR type for zone transfer [DNSVALS]
QTYPE AXFR（= 252）、ゾーン転送用の擬似RRタイプ[DNSVALS]
QCLASS the class of the zone requested [DNSVALS]
qclassゾーンのクラスは要求されました[dnsvals]
The Answer section MUST be empty.
回答セクションは空でなければなりません。
The Authority section MUST be empty.
当局セクションは空でなければなりません。
Currently, two kinds of resource records are defined that can appear in the Additional section of AXFR queries and responses: EDNS and DNS transaction security. Future specifications defining RRs that can be carried in the Additional section of normal DNS transactions need to explicitly describe their use with AXFR, should that be desired.
現在、AXFRクエリの追加セクションに表示される2種類のリソースレコードが定義されています。EDNSおよびDNSトランザクションセキュリティ。通常のDNSトランザクションの追加セクションで実行できるRRを定義する将来の仕様は、それが望ましい場合にAXFRでの使用を明示的に説明する必要があります。
The client MAY include one OPT resource record [RFC2671]. If the server does not support EDNS0, the client MUST send this section without an OPT resource record if there is a retry. However, the protocol does not define an explicit indication that the server does not support EDNS0; that needs to be inferred by the client. Often, the server will return a FormErr(1) that might be related to the OPT resource record. Note that, at the time of this writing, only the EXTENDED-RCODE field of the OPT RR is meaningful in the context of AXFR; future specifications of EDNS flags and/or EDNS options must describe their usage in the context of AXFR, if applicable.
クライアントには、1つのOPTリソースレコード[RFC2671]を含めることができます。サーバーがEDNS0をサポートしていない場合、再試行がある場合は、クライアントがOPTリソースレコードなしでこのセクションを送信する必要があります。ただし、プロトコルは、サーバーがEDNS0をサポートしていないという明示的な兆候を定義していません。それはクライアントによって推測される必要があります。多くの場合、サーバーは、OPTリソースレコードに関連する可能性のあるフォーマー（1）を返します。この執筆時点では、OPT RRの拡張ロードフィールドのみがAXFRのコンテキストで意味があることに注意してください。EDNSフラグおよび/またはEDNSオプションの将来の仕様は、該当する場合はAXFRのコンテキストでの使用法を説明する必要があります。
The client MAY include one transaction integrity and authentication resource record, currently a choice of TSIG [RFC2845] or SIG(0) [RFC2931]. If the server has indicated that it does not recognize the resource record, and that the error is indeed caused by the resource record, the client probably should not try again. Removing the security data in the face of an obstacle ought to only be done with full awareness of the implication of doing so.
クライアントには、1つのトランザクションの整合性と認証リソースレコードが含まれる場合があります。現在、TSIG [RFC2845]またはSIG（0）[RFC2931]の選択です。サーバーがリソースレコードを認識しておらず、エラーが実際にリソースレコードによって引き起こされることを示した場合、クライアントはおそらく再試行しないでください。障害に直面してセキュリティデータを削除することは、そうすることの意味を完全に認識してのみ行うべきです。
In general, if an AXFR client is aware that an AXFR server does not support a particular mechanism, the client SHOULD NOT attempt to engage the server using the mechanism (or engage the server at all). A client could become aware of a server's abilities via a configuration setting or via some other (as yet) undefined means.
一般に、AXFRクライアントがAXFRサーバーが特定のメカニズムをサポートしていないことを認識している場合、クライアントはメカニズムを使用してサーバーをエンゲージしようとしてはなりません（またはサーバーをまったくエンゲージします）。クライアントは、構成設定または他の（まだ）未定義の手段を介してサーバーの能力を認識することができます。
The range of permissible resource records that MAY appear in the Additional section might change over time. If either a change to an existing resource record (like the OPT RR for EDNS) is made or a new Additional section record is created, the new definitions ought to include a discussion on the applicability and impact upon AXFR. Future resource records residing in the Additional section might have an effect that is orthogonal to AXFR, and so can ride through the session as opaque data. In this case, a "wise" implementation ought to be able to pass these records through without disruption.
追加セクションに表示される可能性のある許容リソースレコードの範囲は、時間とともに変化する可能性があります。既存のリソースレコードの変更（EDNのOPT RRなど）が作成された場合、または新しい追加セクションレコードが作成された場合、新しい定義には、AXFRへの適用性と影響に関する議論を含める必要があります。追加セクションに存在する将来のリソースレコードは、AXFRに直交する効果がある可能性があり、不透明なデータとしてセッションを通過することができます。この場合、「賢明な」実装は、これらの記録を混乱させることなく渡すことができるはずです。
The AXFR response will consist of one or more messages. The special case of a server closing the TCP connection without sending an AXFR response is covered in Section 2.3.
AXFR応答は、1つ以上のメッセージで構成されます。AXFR応答を送信せずにTCP接続を閉じるサーバーの特殊なケースは、セクション2.3で説明されています。
An AXFR response that is transferring the zone's contents will consist of a series (which could be a series of length 1) of DNS messages. In such a series, the first message MUST begin with the SOA resource record of the zone, and the last message MUST conclude with the same SOA resource record. Intermediate messages MUST NOT contain the SOA resource record. The AXFR server MUST copy the Question section from the corresponding AXFR query message into the first response message's Question section. For subsequent messages, it MAY do the same or leave the Question section empty.
ゾーンの内容を転送しているAXFR応答は、DNSメッセージのシリーズ（一連の長さ1になる可能性がある）で構成されます。このようなシリーズでは、最初のメッセージはゾーンのSOAリソースレコードから開始する必要があり、最後のメッセージは同じSOAリソースレコードで終了する必要があります。中間メッセージには、SOAリソースレコードが含まれてはなりません。AXFRサーバーは、対応するAXFRクエリメッセージから質問セクションを最初の回答メッセージの質問セクションにコピーする必要があります。後続のメッセージの場合、同じことを行うか、質問セクションを空にしておくことがあります。
The AXFR protocol treats the zone contents as an unordered collection (or to use the mathematical term, a "set") of RRs. Except for the requirement that the transfer must begin and end with the SOA RR, there is no requirement to send the RRs in any particular order or grouped into response messages in any particular way. Although servers typically do attempt to send related RRs (such as the RRs forming an RRset, and the RRsets of a name) as a contiguous group or, when message space allows, in the same response message, they are not required to do so, and clients MUST accept any ordering and grouping of the non-SOA RRs. Each RR SHOULD be transmitted only once, and AXFR clients MUST ignore any duplicate RRs received.
AXFRプロトコルは、ゾーンの内容をRRSの非秩序化コレクション（または数学用語、「セット」を使用する）として扱います。転送がSOA RRで開始および終了する必要があるという要件を除き、特定の順序でRRを送信するか、特定の方法で応答メッセージにグループ化する要件はありません。サーバーは通常、関連するRRS（RRSセットを形成するRRSや名前のRRSetsなど）を連続的なグループとして送信しようとしますが、メッセージスペースが同じ応答メッセージで許可する場合は、そうする必要はありません。クライアントは、非SOA RRの注文とグループ化を受け入れる必要があります。各RRは一度だけ送信する必要があり、AXFRクライアントは受信した重複RRを無視する必要があります。
Each AXFR response message SHOULD contain a sufficient number of RRs to reasonably amortize the per-message overhead, up to the largest number that will fit within a DNS message (taking the required content of the other sections into account, as described below).
各AXFR応答メッセージには、DNSメッセージ内に適合する最大数までの最大数までの最大数までの最大数まで、各AXFR応答メッセージに十分な数のRRを含める必要があります（以下に説明するように、他のセクションの必要なコンテンツを考慮に入れます）。
Some old AXFR clients expect each response message to contain only a single RR. To interoperate with such clients, the server MAY restrict response messages to a single RR. As there is no standard way to automatically detect such clients, this typically requires manual configuration at the server.
一部の古いAXFRクライアントは、各応答メッセージが単一のRRのみを含むことを期待しています。このようなクライアントと相互運用するために、サーバーは応答メッセージを単一のRRに制限する場合があります。このようなクライアントを自動的に検出する標準的な方法はないため、通常、サーバーでの手動構成が必要です。
To indicate an error in an AXFR response, the AXFR server sends a single DNS message when the error condition is detected, with the response code set to the appropriate value for the condition encountered. Such a message terminates the AXFR session; it MUST contain a copy of the Question section from the AXFR query in its Question section, but the inclusion of the terminating SOA resource record is not necessary.
AXFR応答のエラーを示すために、AXFRサーバーは、エラー条件が検出されたときに単一のDNSメッセージを送信し、応答コードが遭遇した条件の適切な値に設定されています。このようなメッセージは、AXFRセッションを終了します。質問セクションのAXFRクエリからの質問セクションのコピーを含める必要がありますが、終了SOAリソースレコードを含める必要はありません。
An AXFR server may send a number of AXFR response messages free of an error condition before it sends the message indicating an error.
AXFRサーバーは、エラーを示すメッセージを送信する前に、エラー条件のないAXFR応答メッセージを多数送信する場合があります。
These are the DNS message header values for AXFR responses.
これらは、AXFR応答のDNSメッセージヘッダー値です。
ID MUST be copied from request -- see Note a)
IDはリクエストからコピーする必要があります - 注を参照a）
QR MUST be 1 (Response)
QRは1（応答）でなければなりません
OPCODE MUST be 0 (Standard Query)
opcodeは0（標準クエリ）である必要があります
Flags: AA normally 1 -- see Note b) TC MUST be 0 (Not truncated) RD RECOMMENDED: copy request's value; MAY be set to 0 RA SHOULD be 0 -- see Note c) Z "mbz" -- see Note d) AD "mbz" -- see Note d) CD "mbz" -- see Note d)
フラグ：AA通常1-注Bを参照）TCは0（切り捨てられていない）が必要です。RD推奨：コピー要求の値。0に設定することができますraは0になる必要があります - 注Cを参照c）z "MBZ" - 注D）AD "MBZ"を参照 - 注D）CD "MBZ" - 注Dを参照）
RCODE See Note e)
rcode注eを参照e）
QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all following messages; MUST be 1 if RCODE indicates an error
qdcountは最初のメッセージで1でなければなりません。次のすべてのメッセージで0または1でなければなりません。rcodeがエラーを示している場合は1でなければなりません
ANCOUNT See Note f)
Ancount注fを参照）
NSCOUNT MUST be 0
nscountは0でなければなりません
ARCOUNT See Note g)
ARCOUNT注Gを参照してください）
Notes:
ノート：
a) Because some old implementations behave differently than is now desired, the requirement on this field is stated in detail. New DNS servers MUST set this field to the value of the AXFR query ID in each AXFR response message for the session. AXFR clients MUST be able to manage sessions resulting from the issuance of multiple outstanding queries, whether AXFR queries or other DNS queries. A client SHOULD discard responses that do not correspond (via the message ID) to any outstanding queries.
a) 一部の古い実装は、現在望まれているものとは異なる動作を異なるため、このフィールドの要件について詳しく述べられています。新しいDNSサーバーは、セッションの各AXFR応答メッセージのAXFRクエリIDの値にこのフィールドを設定する必要があります。AXFRクライアントは、AXFRクエリまたは他のDNSクエリであろうと、複数の未解決のクエリの発行に起因するセッションを管理できる必要があります。クライアントは、（メッセージIDを介して）未解決のクエリに対応しない応答を破棄する必要があります。
Unless the client is sure that the server will consistently set the ID field to the query's ID, the client is NOT RECOMMENDED to issue any other queries until the end of the zone transfer. A client MAY become aware of a server's abilities via a configuration setting.
クライアントがサーバーが一貫してIDフィールドをクエリのIDに設定することを確信していない限り、クライアントはゾーン転送の終了まで他のクエリを発行することをお勧めしません。クライアントは、構成設定を介してサーバーの能力を認識する場合があります。
b) If the RCODE is 0 (no error), then the AA bit MUST be 1. For any other value of RCODE, the AA bit MUST be set according to the rules for that error code. If in doubt, it is RECOMMENDED that it be set to 1. It is RECOMMENDED that the value be ignored by the AXFR client.
b) rcodeが0（エラーなし）の場合、AAビットは1でなければなりません。Rcodeの他の値の場合、AAビットはそのエラーコードのルールに従って設定する必要があります。疑わしい場合は、1に設定することをお勧めします。AXFRクライアントは値を無視することをお勧めします。
c) It is RECOMMENDED that the server set the value to 0; the client MUST ignore this value.
c) サーバーが値を0に設定することをお勧めします。クライアントはこの値を無視する必要があります。
The server MAY set this value according to the local policy regarding recursive service, but doing so might confuse the interpretation of the response, as AXFR cannot be retrieved recursively. A client MAY note the server's policy regarding recursive service from this value, but SHOULD NOT conclude that the AXFR response was obtained recursively, even if the RD bit was 1 in the query.
サーバーは、再帰サービスに関するローカルポリシーに従ってこの値を設定する場合がありますが、AXFRを再帰的に取得できないため、応答の解釈を混同する可能性があります。クライアントは、この値からの再帰サービスに関するサーバーのポリシーに注意することができますが、rdビットがクエリで1であっても、AXFR応答が再帰的に取得されたと結論付けるべきではありません。
d) "mbz" -- The server MUST set this bit to 0; the client MUST ignore it.
d) 「MBZ」 - サーバーはこのビットを0に設定する必要があります。クライアントはそれを無視する必要があります。
e) In the absence of an error, the server MUST set the value of this field to NoError(0). If a server is not authoritative for the queried zone, the server SHOULD set the value to NotAuth(9). (Reminder: Consult the appropriate IANA registry [DNSVALS].) If a client receives any other value in response, it MUST act according to the error. For example, a malformed AXFR query or the presence of an OPT resource record sent to an old server will result in a FormErr(1) value. This value is not set as part of the AXFR-specific response processing. The same is true for other values indicating an error.
e) エラーがない場合、サーバーはこのフィールドの値をNoError（0）に設定する必要があります。サーバーがクエリゾーンの権威がない場合、サーバーは値をnotauth（9）に設定する必要があります。（リマインダー：適切なIANAレジストリ[DNSVALS]を参照してください。）クライアントがそれに応じて他の値を受信した場合、エラーに従って行動する必要があります。たとえば、不正なAXFRクエリまたは古いサーバーに送信されたOPTリソースレコードの存在により、FORMERR（1）値が得られます。この値は、AXFR固有の応答処理の一部として設定されていません。エラーを示す他の値にも同じことが言えます。
f) The count of answer records MUST equal the number of resource records in the AXFR Answer section. When a server is aware that a client will only accept response messages with a single resource record, then the value MUST be 1. A server MAY be made aware of a client's limitations via configuration data.
f) 回答記録のカウントは、AXFR回答セクションのリソースレコードの数に等しくなければなりません。サーバーがクライアントが単一のリソースレコードを持つ応答メッセージのみを受け入れることを認識している場合、値は1でなければなりません。サーバーは、構成データを介してクライアントの制限を認識させることができます。
g) The server MUST set this field to the number of resource records it places into the Additional section. In the absence of explicit specification of new RRs to be carried in the Additional section of AXFR response messages, the value MAY be 0, 1, or 2. See Section 2.1.5 above for details on the currently applicable RRs and Section 2.2.5 for additional considerations specific to AXFR servers.
g) サーバーは、このフィールドを追加セクションに配置するリソースレコードの数に設定する必要があります。AXFR応答メッセージの追加セクションで実施される新しいRRの明示的な仕様がない場合、値は0、1、または2になる場合があります。現在該当するRRSおよびセクション2.2.5の詳細については、上記のセクション2.1.5を参照してください。AXFRサーバーに固有の追加の考慮事項。
In the first response message, this section MUST be copied from the query. In subsequent messages, this section MAY be copied from the query, or it MAY be empty. However, in an error response message (see Section 2.2), this section MUST be copied as well. The content of this section MAY be used to determine the context of the message, that is, the name of the zone being transferred.
最初の応答メッセージでは、このセクションをクエリからコピーする必要があります。後続のメッセージでは、このセクションがクエリからコピーされるか、空になる場合があります。ただし、エラー応答メッセージ（セクション2.2を参照）では、このセクションもコピーする必要があります。このセクションの内容は、メッセージのコンテキスト、つまり転送されるゾーンの名前を決定するために使用できます。
The Answer section MUST be populated with the zone contents. See Section 3 below on encoding zone contents.
回答セクションには、ゾーンの内容を入力する必要があります。エンコードゾーンの内容については、以下のセクション3を参照してください。
The Authority section MUST be empty.
当局セクションは空でなければなりません。
The contents of this section MUST follow the guidelines for the OPT, TSIG, and SIG(0) RRs, or whatever other future record is possible here. The contents of Section 2.1.5 apply analogously as well.
このセクションの内容は、OPT、TSIG、およびSIG（0）RRSのガイドライン、またはここで可能な他の将来の記録に従う必要があります。セクション2.1.5の内容も同様に適用されます。
The following considerations specifically apply to AXFR responses:
以下の考慮事項は、AXFR応答に特に適用されます。
If the client has supplied an EDNS OPT RR in the AXFR query and if the server supports EDNS as well, it SHOULD include one OPT RR in the first response message and MAY do so in subsequent response messages (see Section 2.2); the specifications of EDNS options to be carried in the OPT RR may impose stronger requirements.
クライアントがAXFRクエリにEDNS OPT RRを提供し、サーバーがEDNSをサポートしている場合、最初の応答メッセージに1つのOPT RRを含める必要があり、後続の応答メッセージでそれを行うことができます（セクション2.2を参照）。OPT RRで運ばれるEDNSオプションの仕様は、より強い要件を課す可能性があります。
If the client has supplied a transaction security resource record (currently a choice of TSIG and SIG(0)) and the server supports the method chosen by the client, it MUST place the corresponding resource record into the AXFR response message(s), according to the rules specified for that method.
クライアントがトランザクションセキュリティリソースレコード（現在TSIGとSIG（0）の選択）を提供し、サーバーがクライアントが選択したメソッドをサポートしている場合、対応するリソースレコードをAXFR応答メッセージに配置する必要があります。その方法で指定されたルールに。
If an AXFR client sends a query on a TCP connection and the connection is closed at any point, the AXFR client MUST consider the AXFR session terminated. The message ID MAY be used again on a new connection, even if the question and AXFR server are the same.
AXFRクライアントがTCP接続でクエリを送信し、任意の時点で接続が閉じられている場合、AXFRクライアントはAXFRセッションの終了を考慮する必要があります。質問とAXFRサーバーが同じであっても、メッセージIDは新しい接続で再度使用できます。
Facing a dropped connection, a client SHOULD try to make some determination as to whether the connection closure was the result of network activity or due to a decision by the AXFR server. This determination is not an exact science. It is up to the AXFR client to react, but the implemented reaction SHOULD NOT be either an endless cycle of retries or an increasing (in frequency) retry rate.
接続の削除に直面して、クライアントは、接続クロージャーがネットワークアクティビティの結果であるか、AXFRサーバーによる決定によるものであるかについて何らかの決定を下す必要があります。この決定は正確な科学ではありません。反応するのはAXFRクライアント次第ですが、実装された反応は、レトリの無限のサイクルであっても、（周波数内）再速度の増加であってはなりません。
An AXFR server implementer should take into consideration the dilemma described above when a connection is closed with an outstanding query in the pipeline. For this reason, a server ought to reserve this course of action for situations in which it believes beyond a doubt that the AXFR client is attempting abusive behavior.
AXFRサーバーの実装者は、パイプラインの未解決のクエリで接続が閉じられている場合、上記のジレンマを考慮する必要があります。このため、サーバーは、AXFRクライアントが虐待的な行動を試みていることを疑いなく信じている状況のために、この一連の行動を予約する必要があります。
The objective of the AXFR session is to request and transfer the contents of a zone, in order to permit the AXFR client to faithfully reconstruct the zone as it exists at the primary server for the given zone serial number. The word "exists" here designates the externally visible behavior, i.e., the zone content that is being served (handed out to clients) -- not its persistent representation in a zone file or database used by the server -- and that for consistency should be served subsequently by the AXFR client in an identical manner.
AXFRセッションの目的は、AXFRクライアントが特定のゾーンシリアル番号のプライマリサーバーに存在するゾーンを忠実に再構築できるようにするために、ゾーンの内容を要求して転送することです。ここで「存在する」という言葉は、外部から見える動作、つまり提供されているゾーンコンテンツ（クライアントに配られている）を指定します - サーバーが使用するゾーンファイルまたはデータベースでの永続的な表現ではなく、一貫性のためにそれは必要なはずです。その後、AXFRクライアントから同一の方法で提供されます。
Over time the definition of a zone has evolved from denoting a static set of records to also cover a dynamically updated set of records, and then a potentially continually regenerated set of records (e.g., RRs synthesized "on the fly" from rule sets or database lookup results in other forms than RR format) as well.
時間が経つにつれて、ゾーンの定義は、動的に更新されたレコードのセットをカバーする静的なレコードセットを示すことから進化しました。その後、潜在的に継続的に再生されたレコードセット（例えば、ルールセットまたはデータベースから「オンザフライ」を合成したRRSルックアップは、RR形式以外の形式でも発生します）。
In the Answer section of AXFR response messages, the resource records within a zone for the given serial number MUST appear. The definition of what belongs in a zone is described in RFC 1034, Section 4.2, "How the database is divided into zones" (in particular Section 4.2.1, "Technical considerations"), and it has been clarified in Section 6 of RFC 2181.
AXFR応答メッセージの回答セクションでは、指定されたシリアル番号のゾーン内のリソースレコードが表示されなければなりません。ゾーンに属するものの定義は、RFC 1034、セクション4.2、「データベースがゾーンに分割される方法」（特にセクション4.2.1「技術的考慮事項」）で説明されており、RFCのセクション6で明確にされています。2181。
Zones for which it is impractical to list the entire zone for a serial number are not suitable for AXFR retrieval. A typical (but not limiting) description of such a zone is a zone consisting of responses generated via other database lookups and/or computed based upon ever-changing data.
シリアル番号のゾーン全体をリストすることは非現実的であるゾーンは、AXFR検索には適していません。このようなゾーンの典型的な（ただし制限されていない）説明は、他のデータベースルックアップを介して生成された応答や、絶えず変化するデータに基づいて計算されるゾーンです。
In Section 4.2.1 of RFC 1034, this text appears (keep in mind that the "should" in the quotation predates [BCP14], cf. Section 1.1):
RFC 1034のセクション4.2.1では、このテキストが表示されます（引用の「BCP14]、cf。セクション1.1を参照）の「予定」は留意してください）
The RRs that describe cuts ... should be exactly the same as the corresponding RRs in the top node of the subzone.
カットを記述するRRSは、サブゾーンのトップノードの対応するRRとまったく同じでなければなりません。
There has been some controversy over this statement and the impact on which NS resource records are included in a zone transfer.
この声明と、NSリソースレコードがゾーン転送に含まれる影響についていくつかの論争がありました。
The phrase "that describe cuts" is a reference to the NS set and applicable glue records. It does not mean that the cut point and apex resource records are identical. For example, the SOA resource record is only found at the apex. The discussion here is restricted to just the NS resource record set and glue, as these "describe cuts".
「カットを説明する」というフレーズは、NSセットと適用可能な接着剤レコードへの参照です。カットポイントと頂点リソースレコードが同一であるという意味ではありません。たとえば、SOAリソースレコードは頂点でのみ見つかります。ここでの議論は、NSリソースレコードセットと接着剤のみに制限されています。これらは「カットを説明する」ためです。
DNSSEC resource records have special specifications regarding their occurrence at a zone cut and the apex of a zone. This was first described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial specification of DNSSEC), which parts of RFC 2181 now in fact are historical. The current DNSSEC core document set (see second bullet in Section 2 above) gives the full details for DNSSEC(bis) resource record placement, and Section 3.1.5 of RFC 4035 normatively specifies their treatment during AXFR; the alternate NSEC3 resource record defined later in RFC 5155 behaves identically to the NSEC RR, for the purpose of AXFR.
DNSSECリソースレコードには、ゾーンカットでの発生とゾーンの頂点に関する特別な仕様があります。これは、セクション5.3 ffで最初に説明されました。RFC 2181の6.2（DNSSECの初期仕様用）、RFC 2181の一部は実際に歴史的です。現在のDNSSECコアドキュメントセット（上記のセクション2の2番目の弾丸を参照）は、DNSSEC（BIS）リソースレコードの配置の詳細を示し、RFC 4035のセクション3.1.5はAXFR中の治療を規範的に指定します。RFC 5155で後に定義された代替NSEC3リソースレコードは、AXFRを目的として、NSEC RRと同じように動作します。
Informally:
非公式に：
o The DS RRSet only occurs at the parental side of a zone cut and is authoritative data in the parent zone, not the secure child zone.
o DS RRSTは、ゾーンカットの親側でのみ発生し、安全な子ゾーンではなく、親ゾーンの権威あるデータです。
o The DNSKEY RRSet only occurs at the apex of a signed zone and is part of the authoritative data of the zone it serves.
o DNSKEY RRSTは、署名されたゾーンの頂点でのみ発生し、提供するゾーンの権威あるデータの一部です。
o Independent RRSIG RRSets occur at the signed parent side of a zone cut and at the apex of a signed zone; they are authoritative data in the respective zone; simple queries for RRSIG resource records may return both RRSets at once if the same server is authoritative for the parent zone and the child zone (Section 3.1.5 of RFC 4035 describes how to distinguish these RRs); this seeming ambiguity does not occur for AXFR, since each such RRSIG RRset belongs to a single zone.
o 独立したrrsig rrsetsは、ゾーンカットの署名された親側と署名ゾーンの頂点で発生します。それらはそれぞれのゾーンの権威あるデータです。RRSIGリソースレコードの単純なクエリは、同じサーバーが親ゾーンとチャイルドゾーンの権威ある場合、両方のRRSetsを一度に返す場合があります（RFC 4035のセクション3.1.5では、これらのRRを区別する方法について説明します）。このようなRRSIG RRSetはそれぞれ単一のゾーンに属しているため、AXFRではこの曖昧さは発生しません。
o Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records equally may occur at the parental side of a zone cut and at the apex of a zone; each such resource record belongs to exactly one of these zones and is to be included in the AXFR of that zone.
o 異なるNSEC [RFC4034]（またはNSEC3 [RFC5155]）リソースレコードは、ゾーンカットの親の側面とゾーンの頂点で等しく発生する可能性があります。このようなリソースレコードはそれぞれ、これらのゾーンの1つに属し、そのゾーンのAXFRに含まれます。
One issue is that in operations there are times when the NS resource records for a zone might be different at a cut point in the parent and at the apex of a zone. Sometimes this is the result of an error, and sometimes it is part of an ongoing change in name servers. The DNS protocol is robust enough to overcome inconsistencies up to (but not including) there being no parent-indicated NS resource record referencing a server that is able to serve the child zone. This robustness is one quality that has fueled the success of the DNS. Still, the inconsistency is an error state, and steps need to be taken to make it apparent (if it is unplanned).
1つの問題は、操作では、親のカットポイントとゾーンの頂点でゾーンのNSリソースレコードが異なる場合があることです。これはエラーの結果である場合があり、名前サーバーの継続的な変更の一部である場合があります。DNSプロトコルは、子ゾーンにサービスを提供できるサーバーを参照する親が指定したNSリソースレコードまでの矛盾を克服するのに十分堅牢です。この堅牢性は、DNSの成功を促進した1つの品質です。それでも、矛盾はエラー状態であり、それを明らかにするために手順をとる必要があります（それが計画されていない場合）。
Another issue is that the AXFR server could be authoritative for a different set of zones than the AXFR client. It is possible that the AXFR server be authoritative for both halves of an inconsistent cut point and that the AXFR client is authoritative for just the parent side of the cut point.
別の問題は、AXFRサーバーがAXFRクライアントとは異なるゾーンのセットに対して権威ある可能性があることです。AXFRサーバーは、一貫性のないカットポイントの両方の半分に対して権威ある可能性があり、AXFRクライアントはカットポイントの親側だけで権威あるものである可能性があります。
When facing a situation in which a cut point's NS resource records do not match the authoritative set, the question arises whether an AXFR server responds with the NS resource record set that is in the zone being transferred or the one that is at the authoritative location.
カットポイントのNSリソースレコードが権威あるセットと一致しない状況に直面している場合、AXFRサーバーが転送されるNSリソースレコードセットで応答するのか、それとも権威ある場所にあるもので応答するかどうかという疑問が生じます。
The AXFR response MUST contain the cut point NS resource record set registered with the zone whether it agrees with the authoritative set or not. "Registered with" can be widely interpreted to include data residing in the zone file of the zone for the particular serial number (in zone file environments) or as any data configured to be in the zone (database), statically or dynamically.
AXFR応答には、権威あるセットと一致するかどうかにかかわらず、ゾーンに登録されたカットポイントnsリソースレコードセットを含める必要があります。「登録」は、特定のシリアル番号（ゾーンファイル環境）のゾーンファイルに存在するデータを含めるように広く解釈できます（ゾーンファイル環境）、または静的または動的にゾーン（データベース）に構成されているデータが任意のデータを含めることができます。
The reasons for this requirement are:
この要件の理由は次のとおりです。
1) The AXFR server might not be able to determine that there is an inconsistency given local data; hence, requiring consistency would mean a lot more needed work and even network retrieval of data. An authoritative server ought not be required to perform any queries.
1) AXFRサーバーは、ローカルデータを考慮して矛盾があることを判断できない場合があります。したがって、一貫性を必要とすることは、より多くの必要な作業やデータのネットワーク検索さえ意味します。権威あるサーバーは、クエリを実行する必要はありません。
2) By transferring the inconsistent NS resource records from a server that is authoritative for both the cut point and the apex to a client that is not authoritative for both, the error is exposed. For example, an authorized administrator can manually request the AXFR and inspect the results to see the inconsistent records. (A server authoritative for both halves would otherwise always answer from the more authoritative set, concealing the error.)
2) カットポイントと頂点の両方に対して権威あるサーバーから、両方に対して権威がないクライアントに一貫性のないNSリソースレコードを転送することにより、エラーが公開されます。たとえば、承認された管理者は、AXFRを手動で要求し、結果を検査して一貫性のないレコードを確認できます。（それ以外の場合、両方の半分に対して信頼できるサーバーは、より権威あるセットから常に回答し、エラーを隠します。）
3) The inconsistent NS resource record set might indicate a problem in a registration database.
3) 一貫性のないNSリソースレコードセットは、登録データベースの問題を示している可能性があります。
4) This requirement is necessary to ensure that retrieving a given (zone, serial) pair by AXFR yields the exact same set of resource records, no matter which of the zone's authoritative servers is chosen as the source of the transfer.
4) この要件は、AXFRによる特定の（ゾーン、シリアル）ペアを取得することで、ゾーンの権威あるサーバーのどれが転送のソースとして選択されていても、まったく同じリソースレコードのセットを生成することを保証するために必要です。
If an AXFR server were allowed to respond with the authoritative NS RRset of a child zone instead of a parent-side NS RRset in the zone being transferred, the set of records returned could vary depending on whether or not the server happened to be authoritative for the child zone as well.
AXFRサーバーが、ゾーン内の親側ns RRSetの代わりに子ゾーンの権威あるns rrsetで応答することを許可された場合、返されるレコードのセットは、サーバーがたまたま権威あるかどうかによって異なる可能性があります。チャイルドゾーンも同様です。
The property that a given (zone, serial) pair corresponds to a single, well-defined set of records is necessary for the correct operation of incremental transfer protocols such as IXFR [RFC1995]. For example, a client may retrieve a zone by AXFR from one server, and then apply an incremental change obtained by IXFR from a different server. If the two servers have different ideas of the zone contents, the client can end up attempting to incrementally add records that already exist or to delete records that do not exist.
特定の（ゾーン、シリアル）ペアが単一の明確に定義されたレコードセットに対応するプロパティは、IXFR [RFC1995]などの増分転送プロトコルの正しい動作に必要です。たとえば、クライアントは1つのサーバーからAXFRによってゾーンを取得し、別のサーバーからIXFRによって取得された増分変更を適用することができます。2つのサーバーにゾーンコンテンツのアイデアが異なる場合、クライアントは既に存在するレコードを徐々に追加しようとするか、存在しないレコードを削除しようとすることができます。
As quoted in the previous section, Section 4.2.1 of RFC 1034 provides guidance and rationale for the inclusion of glue records as part of an AXFR response. And, as also argued in the previous section of this document, even when there is an inconsistency between the address in a glue record and the authoritative copy of the name server's address, the glue resource record that is registered as part of the zone for that serial number is to be included.
前のセクションで引用されているように、RFC 1034のセクション4.2.1は、AXFR応答の一部として接着剤レコードを含めるためのガイダンスと理論的根拠を提供します。また、このドキュメントの前のセクションでも議論されているように、接着剤レコードのアドレスと名前サーバーのアドレスの権威あるコピーの間に矛盾がある場合でも、そのゾーンの一部として登録されている接着剤リソースレコードはシリアル番号を含めます。
This applies to glue records for any address family [IANA-AF].
これは、アドレスファミリ[IANA-AF]のGlue Recordsに適用されます。
The AXFR response MUST contain the appropriate glue records as registered with the zone. The interpretation of "registered with" in the previous section applies here. Inconsistent glue records are an operational matter.
AXFR応答には、ゾーンに登録されている適切な接着剤レコードが含まれている必要があります。前のセクションで「登録」の解釈はここに適用されます。一貫性のない接着剤レコードは運用上の問題です。
Compression of names in DNS messages is described in RFC 1035, Section 4.1.4, "Message compression". The issue highlighted here relates to a comment made in RFC 1034, Section 3.1, "Name space specifications and terminology", which says:
DNSメッセージの名前の圧縮は、RFC 1035、セクション4.1.4、「メッセージ圧縮」で説明されています。ここで強調されている問題は、RFC 1034、セクション3.1、「名前空間仕様と用語」で行われたコメントに関連しています。
When you receive a domain name or label, you should preserve its case.
ドメイン名またはラベルを受け取ったら、そのケースを保存する必要があります。
("Should" in the quote predates [BCP14].)
（引用の「 "bcp14]の「すべき」）。
Since the primary objective of AXFR is to enable the client to serve the same zone content as the server, unlike such normal DNS responses that are expected to preserve the case in the query, the actual zone transfer needs to retain the case of the labels in the zone content. Hence, name compression in an AXFR message SHOULD be performed in a case-preserving manner, unlike how it is done for "normal" DNS responses. That is, although when comparing a domain name for matching, "a" equals "A", when comparing for the purposes of message compression for AXFR, "a" is not equal to "A". Note that this is not the usual definition of name comparison in the DNS protocol and represents a new understanding of the requirement on AXFR servers.
AXFRの主な目的は、クエリと同じゾーンコンテンツをサーバーと同じゾーンコンテンツを提供できるようにすることであるため、クエリでケースを保持すると予想される通常のDNS応答とは異なり、実際のゾーン転送は、ラベルのケースを保持する必要があります。ゾーンコンテンツ。したがって、「通常の」DNS応答に対してどのように行われるかとは異なり、AXFRメッセージ内の名前圧縮は、ケース提示方法で実行する必要があります。つまり、マッチングのドメイン名を比較する場合、「a "はa」に等しく、AXFRのメッセージ圧縮の目的で比較する場合、「a」は「a」に等しくありません。これは、DNSプロトコルの名前比較の通常の定義ではなく、AXFRサーバーの要件の新しい理解を表していることに注意してください。
Rules governing name compression of RDATA in an AXFR message MUST abide by the specification in "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name Compression".
AXFRメッセージ内のRDATAの名前の圧縮を管理するルールは、「不明なDNSリソースレコード（RR）タイプの処理」[RFC3597]、特に「ドメイン名圧縮」のセクション4の仕様を順守する必要があります。
Dynamic Update [RFC2136] operations, and in particular their interaction with DNAME [RFC2672], can have a side effect of occluding names in a zone. The addition of a delegation point via dynamic update will render all subordinate domain names to be in a limbo, still part of the zone but not available to the lookup process. The addition of a DNAME resource record has the same impact. The subordinate names are said to be "occluded".
動的更新[RFC2136]操作、特にDNAME [RFC2672]との相互作用は、ゾーン内の名前を閉塞する副作用を持つことができます。ダイナミックアップデートを介して委任ポイントを追加すると、すべての下位ドメイン名が範囲内にあり、ゾーンの一部になりますが、ルックアッププロセスでは利用できません。DNAMEリソースレコードの追加には同じ影響があります。下位の名前は「閉塞」と言われています。
Occluded names MUST be included in AXFR responses. An AXFR client MUST be able to identify and handle occluded names. The rationale for this action is based on a speedy recovery if the dynamic update operation was in error and is to be undone.
AXFR応答に閉塞した名前を含める必要があります。AXFRクライアントは、閉塞した名前を識別および処理できる必要があります。このアクションの理論的根拠は、動的な更新操作が誤っており、元に戻される場合の迅速な回復に基づいています。
AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC 1034, which states:
AXFRセッションは現在、RFC 1034のセクション4.3.5によるTCPに制限されています。
Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests.
精度が不可欠であるため、TCPまたはその他の信頼できるプロトコルをAXFR要求に使用する必要があります。
The restriction to TCP is also mentioned in Section 6.1.3.2 of "Requirements for Internet Hosts - Application and Support" [RFC1123].
TCPへの制限は、「インターネットホストの要件 - アプリケーションとサポート」[RFC1123]のセクション6.1.3.2にも記載されています。
The most common scenario is for an AXFR client to open a TCP connection to the AXFR server, send an AXFR query, receive the AXFR response, and then close the connection. But variations of that most simple scenario are legitimate and likely: in particular, sending a query for the zone's SOA resource record first over the same TCP connection, and reusing an existing TCP connection for other queries.
最も一般的なシナリオは、AXFRクライアントがAXFRサーバーへのTCP接続を開き、AXFRクエリを送信し、AXFR応答を受信してから接続を閉じることです。しかし、その最も単純なシナリオのバリエーションは合法であり、可能性があります。特に、最初に同じTCP接続でゾーンのSOAリソースレコードのクエリを送信し、他のクエリの既存のTCP接続を再利用します。
Therefore, the assumption that a TCP connection is dedicated to a single AXFR session is incorrect. This wrong assumption has led to implementation choices that prevent either multiple concurrent zone transfers or the use of an open connection for other queries.
したがって、TCP接続が単一のAXFRセッション専用であるという仮定は正しくありません。この誤った仮定により、複数の並行ゾーン転送または他のクエリのオープン接続の使用を防ぐ実装の選択が行われました。
Since the early days of the DNS, operators who have sets of name servers that are authoritative for a common set of zones have found it desirable to be able to have multiple concurrent zone transfers in progress; this way, a name server does not have to wait for one zone transfer to complete before the next can begin. RFC 1035 did not exclude this possibility, but legacy implementations failed to support this functionality efficiently, over a single TCP connection. The remaining presence of such legacy implementations makes it necessary that new general-purpose client implementations still provide options for graceful fallback to the old behavior in their support of concurrent DNS transactions and AXFR sessions on a single TCP connection.
DNSの初期以来、ゾーンの一般的なセットで権威ある名前サーバーのセットを持っているオペレーターは、複数の同時ゾーン転送を進行させることが望ましいことがわかりました。これにより、名前サーバーは、次のゾーンが開始する前に1つのゾーン転送が完了するのを待つ必要はありません。RFC 1035はこの可能性を除外しませんでしたが、レガシーの実装は、単一のTCP接続でこの機能を効率的にサポートできませんでした。このようなレガシーの実装の残りの存在により、新しい汎用クライアントの実装が、単一のTCP接続での同時DNSトランザクションとAXFRセッションをサポートするために、古い行動への優雅なフォールバックのオプションを提供する必要があります。
In the original definition, there arguably is an implicit assumption (probably unintentional) that a TCP connection is used for one and only one AXFR session. This is evidenced in the lack of an explicit requirement to copy the Question section and/or the message ID into responses, no explicit ordering information within the AXFR response messages, and the lack of an explicit notice indicating that a zone transfer continues in the next message.
元の定義では、TCP接続が1つのAXFRセッションにのみ使用されるという暗黙の仮定（おそらく意図的ではない）があります。これは、質問セクションおよび/またはメッセージIDを回答にコピーするための明示的な要件がないこと、AXFR応答メッセージ内の明示的な順序情報、および次のゾーン転送が次のゾーン転送が続くことを示す明示的な通知がないことで証明されています。メッセージ。
The guidance given below is intended to enable better performance of the AXFR exchange as well as provide guidelines on interactions with older software. Better performance includes being able to multiplex DNS message exchanges including zone transfer sessions. Guidelines for interacting with older software are generally applicable to new AXFR clients. In the reverse situation -- older AXFR client and newer AXFR server -- the server ought to operate within the specification for an older server.
以下に示すガイダンスは、AXFR交換のパフォーマンスを向上させるだけでなく、古いソフトウェアとのやり取りに関するガイドラインを提供することを目的としています。パフォーマンスの向上には、ゾーン転送セッションを含むマルチプレックスDNSメッセージ交換ができることが含まれます。古いソフトウェアと対話するためのガイドラインは、一般に新しいAXFRクライアントに適用されます。逆の状況 - 古いAXFRクライアントと新しいAXFRサーバー - は、サーバーは古いサーバーの仕様内で動作する必要があります。
An AXFR client MAY request a connection to an AXFR server for any reason. An AXFR client SHOULD close the connection when there is no apparent need to use the connection for some time period. The AXFR server ought not have to maintain idle connections; the burden of connection closure ought to be on the client. "Apparent need" for the connection is a judgment for the AXFR client and the DNS client. If the connection is used for multiple sessions, or if it is known that sessions will be coming, or if there is other query/response traffic anticipated or currently on the open connection, then there is "apparent need".
AXFRクライアントは、何らかの理由でAXFRサーバーへの接続を要求する場合があります。AXFRクライアントは、いくつかの期間、接続を使用する必要がないことが明らかになった場合、接続を閉じる必要があります。AXFRサーバーは、アイドル接続を維持する必要はありません。接続閉鎖の負担は、クライアントにあるべきです。接続の「明らかなニーズ」は、AXFRクライアントとDNSクライアントの判断です。接続が複数のセッションに使用されている場合、またはセッションが来ることがわかっている場合、または他のクエリ/応答トラフィックが予想されている、または現在開いている接続にある場合、「明らかなニーズ」があります。
An AXFR client can cancel the delivery of a zone only by closing the connection. However, this action will also cancel all other outstanding activity using the connection. There is no other mechanism by which an AXFR response can be cancelled.
AXFRクライアントは、接続を閉じることによってのみゾーンの配信をキャンセルできます。ただし、このアクションは、接続を使用して他のすべての未解決のアクティビティをキャンセルします。AXFR応答をキャンセルできる他のメカニズムはありません。
When a TCP connection is closed remotely (relative to the client), whether by the AXFR server or due to a network event, the AXFR client MUST cancel all outstanding sessions and non-AXFR transactions. Recovery from this situation is not straightforward. If the disruption was a spurious event, attempting to restart the connection would be proper. If the disruption was caused by a failure that proved to be persistent, the AXFR client would be wise not to spend too many resources trying to rebuild the connection. Finally, if the connection was dropped because of a policy at the AXFR server (as can be the case with older AXFR servers), the AXFR client would be wise not to retry the connection. Unfortunately, knowing which of the three cases above (momentary disruption, failure, policy) applies is not possible with certainty, and can only be assessed by heuristics. This exemplifies the general complications for clients in connection-oriented protocols not receiving meaningful error responses.
AXFRサーバーによるものであろうとネットワークイベントによるものであろうと、TCP接続がリモートで（クライアントに対して）閉じられている場合、AXFRクライアントはすべての未解決のセッションと非AXFRトランザクションをキャンセルする必要があります。この状況からの回復は簡単ではありません。混乱が偽のイベントである場合、接続を再開しようとすることが適切です。中断が永続的であることが判明した障害によって引き起こされた場合、AXFRクライアントは、接続を再構築しようとしてあまりにも多くのリソースを費やさないように賢明でしょう。最後に、AXFRサーバーでのポリシーのために接続がドロップされた場合（古いAXFRサーバーの場合は）、AXFRクライアントは接続を再試行しないように賢明です。残念ながら、上記の3つのケースのうちどれが適用されるかを知ることは、確実には不可能であり、ヒューリスティックによってのみ評価できます。これは、意味のあるエラー応答を受信しない接続指向のプロトコルでクライアントの一般的な合併症を例示しています。
An AXFR client MAY use an already opened TCP connection to start an AXFR session. Using an existing open connection is RECOMMENDED over opening a new connection. (Non-AXFR session traffic can also use an open connection.) If in doing so the AXFR client realizes that the responses cannot be properly differentiated (lack of matching query IDs, for example) or the connection is terminated for a remote reason, then the AXFR client SHOULD NOT attempt to reuse an open connection with the specific AXFR server until the AXFR server is updated (which is, of course, not an event captured in the DNS protocol).
AXFRクライアントは、すでに開いているTCP接続を使用してAXFRセッションを開始できます。新しい接続を開く際には、既存のオープン接続を使用することをお勧めします。（非AXFRセッショントラフィックは、オープン接続を使用することもできます。）そうすることで、AXFRクライアントが応答を適切に区別できないことを認識している場合（たとえば、クエリIDの一致の欠如）、またはリモートの理由で接続が終了します。AXFRクライアントは、AXFRサーバーが更新されるまで、特定のAXFRサーバーとのオープンな接続を再利用しようとしてはなりません（もちろん、DNSプロトコルでキャプチャされたイベントではありません）。
An AXFR server MUST be able to handle multiple AXFR sessions on a single TCP connection, as well as to handle other query/response transactions over it.
AXFRサーバーは、単一のTCP接続で複数のAXFRセッションを処理し、その他のクエリ/応答トランザクションを処理することができる必要があります。
If a TCP connection is closed remotely, the AXFR server MUST cancel all AXFR sessions in place. No retry activity is necessary; that is initiated by the AXFR client.
TCP接続がリモートで閉じられている場合、AXFRサーバーはすべてのAXFRセッションを配置する必要があります。再試行活動は必要ありません。これは、AXFRクライアントによって開始されます。
Local policy MAY dictate that a TCP connection is to be closed. Such an action SHOULD be in reaction to limits such as those placed on the number of outstanding open connections. Closing a connection in response to a suspected security event SHOULD be done only in extreme cases, when the server is certain the action is warranted. An isolated request for a zone not on the AXFR server SHOULD receive a response with the appropriate response code and not see the connection broken.
ローカルポリシーは、TCP接続が閉鎖されることを決定する場合があります。このようなアクションは、未解決のオープン接続の数に配置されているような制限に反応する必要があります。疑わしいセキュリティイベントに応じて接続を閉じることは、サーバーが確実にアクションが保証されていると確信している場合にのみ行う必要があります。AXFRサーバー上にないゾーンの孤立した要求は、適切な応答コードを使用して応答を受信し、接続が壊れていないことを確認する必要があります。
With the addition of EDNS0 and applications that require many small zones, such as in web hosting and some ENUM scenarios, AXFR sessions on UDP would now seem desirable. However, there are still some aspects of AXFR sessions that are not easily translated to UDP.
EDNS0と、Webホスティングやいくつかの列挙シナリオなど、多くの小さなゾーンを必要とするアプリケーションの追加により、UDPに関するAXFRセッションが望ましいと思われます。ただし、UDPに簡単に翻訳されないAXFRセッションにはまだいくつかの側面があります。
Therefore, this document does not update RFC 1035 in this respect: AXFR sessions over UDP transport are not defined.
したがって、このドキュメントは、この点でRFC 1035を更新しません。UDPトランスポートを介したAXFRセッションは定義されていません。
A zone administrator has the option to restrict AXFR access to a zone. This was not envisioned in the original design of the DNS but has emerged as a requirement as the DNS has evolved. Restrictions on AXFR could be for various reasons including a desire (or in some instances, having a legal requirement) to keep the bulk version of the zone concealed or to prevent the servers from handling the load incurred in serving AXFR. It has been argued that these reasons are questionable, but this document, driven by the desire to leverage the interoperable practice that has evolved since RFC 1035, acknowledges the factual requirement to provide mechanisms to restrict AXFR.
ゾーン管理者には、AXFRアクセスをゾーンへのアクセスを制限するオプションがあります。これは、DNSの元の設計では想定されていませんでしたが、DNSが進化するにつれて要件として浮上しています。AXFRの制限は、ゾーンの一括バージョンを隠しておくことや、AXFRのサーバーが発生した負荷を処理するのを防ぐための要望（または場合によっては、法的要件を持つ場合、法的要件を持つ）など、さまざまな理由である可能性があります。これらの理由は疑わしいと主張されていますが、この文書は、RFC 1035以来進化してきた相互運用可能な実践を活用したいという欲求によって推進され、AXFRを制限するメカニズムを提供するという事実上の要件を認めています。
A DNS implementation SHOULD provide means to restrict AXFR sessions to specific clients.
DNSの実装は、AXFRセッションを特定のクライアントに制限する手段を提供する必要があります。
An implementation SHOULD allow access to be granted to Internet Protocol addresses and ranges, regardless of whether a source address could be spoofed. Combining this with techniques such as Virtual Private Networks (VPNs) [RFC2764] or Virtual LANs has proven to be effective.
実装により、ソースアドレスをスプーフィングできるかどうかに関係なく、インターネットプロトコルアドレスと範囲にアクセスできるようにする必要があります。これを仮想プライベートネットワーク（VPNS）[RFC2764]や仮想LANなどの手法と組み合わせることで、効果的であることが証明されています。
A general-purpose implementation is RECOMMENDED to implement access controls based upon "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931].
「DNS（TSIG）のシークレットキートランザクション認証」[RFC2845]および/または「DNSリクエストおよびトランザクション署名（SIG（0））」[RFC2931]に基づいてアクセス制御を実装するために、汎用実装が推奨されます。
A general-purpose implementation SHOULD allow access to be open to all AXFR requests. That is, an operator ought to be able to allow any AXFR query to be granted.
汎用の実装により、すべてのAXFRリクエストにアクセスできるようにする必要があります。つまり、オペレーターはAXFRクエリを許可できるようにする必要があります。
A general-purpose implementation SHOULD NOT have a default policy for AXFR requests to be "open to all". For example, a default could be to restrict transfers to addresses selected by the DNS administrator(s) for zones on the server.
汎用の実装には、AXFR要求が「すべてに開かれている」ためのデフォルトのポリシーがあるべきではありません。たとえば、デフォルトは、サーバー上のゾーンのDNS管理者が選択したアドレスへの転送を制限することです。
An AXFR client MUST ensure that only a successfully transferred copy of the zone data can be used to serve this zone. Previous description and implementation practice has introduced a two-stage model of the whole zone synchronization procedure: Upon a trigger event (e.g., when polling of a SOA resource record detects a change in the SOA serial number, or when a DNS NOTIFY request [RFC1996] is received), the AXFR session is initiated, whereby the zone data are saved in a zone file or database (this latter step is necessary anyway to ensure proper restart of the server); upon successful completion of the AXFR operation and some sanity checks, this data set is "loaded" and made available for serving the zone in an atomic operation, and flagged "valid" for use during the next restart of the DNS server; if any error is detected, this data set MUST be deleted, and the AXFR client MUST continue to serve the previous version of the zone, if it did before. The externally visible behavior of an AXFR client implementation MUST be equivalent to that of this two-stage model.
AXFRクライアントは、ゾーンデータの正常に転送されたコピーのみを使用してこのゾーンにサービスを提供できることを確認する必要があります。以前の説明と実装の実践により、ゾーン全体の同期手順の2段階モデルが導入されました。トリガーイベント（たとえば、SOAリソースレコードのポーリングがSOAシリアル番号の変更が検出される場合、またはDNSがリクエストを通知した場合[RFC1996]が受信されます）、AXFRセッションが開始され、ゾーンデータがゾーンファイルまたはデータベースに保存されます（サーバーの適切な再起動を確実にするために、この後者のステップがとにかく必要です）。AXFR操作といくつかの正気チェックが正常に完了すると、このデータセットは「ロード」され、原子操作でゾーンにサービスを提供できるようになり、DNSサーバーの次の再起動中に使用するために「有効」にフラグが付けられました。エラーが検出された場合、このデータセットを削除する必要があり、AXFRクライアントが以前に行った場合、以前のバージョンのゾーンを引き続き提供する必要があります。AXFRクライアントの実装の外部的に見える動作は、この2段階モデルの動作と同等でなければなりません。
If an AXFR client rejects data obtained in an AXFR session, it SHOULD remember the serial number and MAY attempt to retrieve the same zone version again. The reason the same retrieval could make sense is that the reason for the rejection could be rooted in an implementation detail of one AXFR server used for the zone and not present in another AXFR server used for the zone.
AXFRクライアントがAXFRセッションで取得したデータを拒否した場合、シリアル番号を覚えていて、同じゾーンバージョンを再度取得しようとする必要があります。同じ検索が理にかなっている理由は、拒否の理由は、ゾーンに使用され、ゾーンに使用される別のAXFRサーバーに存在しない1つのAXFRサーバーの実装の詳細に根ざしている可能性があるためです。
Ensuring that an AXFR client does not accept a forged copy of a zone is important to the security of a zone. If a zone operator has the opportunity, protection can be afforded via dedicated links, physical or virtual via a VPN among the authoritative servers. But there are instances in which zone operators have no choice but to run AXFR sessions over the global public Internet.
AXFRクライアントがゾーンの偽造コピーを受け入れないようにすることは、ゾーンのセキュリティにとって重要です。ゾーンオペレーターに機会がある場合、保護は、権威あるサーバー間のVPNを介して物理的または仮想的な専用リンクを介して提供されます。しかし、ゾーンオペレーターがグローバルパブリックインターネット上でAXFRセッションを実行する以外に選択肢がない場合があります。
Besides best attempts at securing TCP connections, DNS implementations SHOULD provide means to make use of "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the contents. These techniques MAY also be used for authorization.
TCP接続を保護するための最良の試みに加えて、DNS実装は、「DNS（TSIG）の秘密キートランザクション認証」[RFC2845]および/または「DNSリクエストおよびトランザクション署名（SIG（0））」[RFC2931を使用する手段を提供する必要があります。] AXFRクライアントがコンテンツを確認できるようにする。これらの手法は、許可にも使用できます。
Describing backwards compatibility is difficult because of the lack of specifics in the original definition. In this section, some hints at building in backwards compatibility are given, mostly repeated from the relevant earlier sections.
元の定義には詳細が不足しているため、逆方向の互換性を説明することは困難です。このセクションでは、関連する以前のセクションから主に繰り返される後方互換性の建物に関するいくつかのヒントを示します。
Backwards compatibility is not necessary, but the greater the extent of an implementation's compatibility, the greater its interoperability. For turnkey implementations, this is not usually a concern. For general-purpose implementations, this takes on varying levels of importance, depending on the implementer's desire to maintain interoperability.
後方互換性は必要ありませんが、実装の互換性の程度が大きければ大きいほど、その相互運用性が高くなります。ターンキーの実装では、これは通常懸念事項ではありません。汎用の実装では、相互運用性を維持したいという実装者の欲求に応じて、これはさまざまなレベルの重要性を引き受けます。
It is unfortunate that a need to fall back to older behavior cannot be discovered, and thus has to be noted in a configuration file. An implementation SHOULD, in its documentation, encourage operators to periodically review AXFR clients and servers it has made notes about repeatedly, as old software gets updated from time to time.
残念ながら、古い動作に戻る必要があることは発見できないため、構成ファイルに記載する必要があります。実装は、そのドキュメントで、古いソフトウェアが時々更新されると、繰り返しメモを作成したAXFRクライアントとサーバーを定期的に確認するようオペレーターに奨励する必要があります。
An AXFR server has the luxury of being able to react to an AXFR client's abilities, with the exception of knowing whether the client can accept multiple resource records per AXFR response message. The knowledge that a client is so restricted cannot be discovered; hence, it has to be set by configuration.
AXFRサーバーには、AXFR応答メッセージごとに複数のリソースレコードを受け入れることができるかどうかを除いて、AXFRクライアントの能力に対応できるという贅沢があります。クライアントが非常に制限されているという知識を発見することはできません。したがって、構成によって設定する必要があります。
An implementation of an AXFR server MAY permit configuring, on a per AXFR client basis, the necessity to revert to a single resource record per message; in that case, the default SHOULD be to use multiple records per message.
AXFRサーバーの実装では、AXFRクライアントごとに、メッセージごとに単一のリソースレコードに戻す必要性を構成することができます。その場合、デフォルトはメッセージごとに複数のレコードを使用することです。
An AXFR client has the opportunity to try other features (i.e., those not defined by this document) when querying an AXFR server.
AXFRクライアントは、AXFRサーバーを照会するときに他の機能（つまり、このドキュメントで定義されていないもの）を試す機会があります。
Attempting to issue multiple DNS queries over a TCP transport for an AXFR session SHOULD be aborted if it interrupts the original request, and SHOULD take into consideration whether the AXFR server intends to close the connection immediately upon completion of the original (connection-causing) zone transfer.
AXFRセッションのTCPトランスポートを介して複数のDNSクエリを発行しようとすると、元のリクエストを中断する場合は中止する必要があります。AXFRサーバーが、元の（接続の原因）ゾーンの完了時にすぐに接続を閉じる予定かどうかを考慮する必要があります。移行。
This document is a clarification of a mechanism outlined in RFCs 1034 and 1035 and as such does not add any new security considerations. RFC 3833 [RFC3833] is devoted entirely to security considerations for the DNS; its Section 4.3 delineates zone transfer security aspects from the security threats addressed by DNSSEC.
このドキュメントは、RFCS 1034および1035で概説されているメカニズムの明確化であり、そのため、新しいセキュリティに関する考慮事項は追加されません。RFC 3833 [RFC3833]は、DNSのセキュリティ上の考慮事項に完全に専念しています。そのセクション4.3は、DNSSECが扱うセキュリティの脅威からゾーン転送セキュリティの側面を描写しています。
Concerns regarding authorization, traffic flooding, and message integrity are mentioned in "Authorization" (Section 5), "TCP" (Section 4.1), and "Zone Integrity" (Section 6).
承認、交通洪水、メッセージの整合性に関する懸念は、「承認」（セクション5）、「TCP」（セクション4.1）、および「ゾーンの完全性」（セクション6）で言及されています。
IANA has added a reference to this RFC in the AXFR (252) row of the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry.
IANAは、「ドメイン名システム（DNS）パラメーター」の「リソースレコード（RR）タイプ」の「リソースレコード（RR）タイプ」の行のAXFR（252）の行にこのRFCへの参照を追加しました。
The AXFR protocol is transparent to the parts of DNS zone content that can possibly be subject to Internationalization considerations. It is assumed that for DNS labels and domain names, the issue has been solved via "Internationalizing Domain Names in Applications (IDNA)" [RFC3490] or its successor(s).
AXFRプロトコルは、国際化に関する考慮事項の対象となる可能性のあるDNSゾーンコンテンツの部分に対して透明です。DNSラベルとドメイン名の場合、問題は「アプリケーションの国際化ドメイン名（IDNA）」[RFC3490]またはその後継者によって解決されていると想定されています。
Earlier draft versions of this document have been edited by Andreas Gustafsson. In his latest draft version, this acknowledgment appeared:
このドキュメントの以前のドラフトバージョンは、Andreas Gustafssonによって編集されています。彼の最新のドラフトバージョンでは、この承認が登場しました。
Many people have contributed input and commentary to earlier versions of this document, including but not limited to Bob Halley, Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Trenholme, and Brian Wellington.
多くの人々がこの文書の以前のバージョンに入力と解説を提供していますが、ボブ・ハリー、ダン・バーンスタイン、エリック・A・ホール、ジョシュ・リトルフィールド、ケビン・ダーシー、ロバート・エルツ、レヴォン・エシボフ、マーク・アンドリュース、マイケル・パットン、ピーター・コッコ、サム・トレンホルム、ブライアン・ウェリントン。
Comments on later draft versions have come from these individuals: Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly, Bill Manning, and other participants of the DNSEXT working group. Significant comments from the IETF at large have been received from Subramanian Moonesamy, Chris Lonvick, and Vijay K. Gurbani.
後のドラフトバージョンに関するコメントは、マークアンドリュース、ポールビクシー、ワーターウィジュンガード、イアンカルダー、トニーフィンチ、イアンジャクソン、アンドレアスグスタフソン、ブライアンウェリントン、ニールオライリー、ビルマニング、およびDNSEXTの作業者の他の参加者からのコメントがこれらの個人から来ています。グループ。IETF全体からの重要なコメントは、Subramanian Moonesamy、Chris Lonvick、およびVijay K. Gurbaniから受け取られています。
Edward Lewis served as a patiently listening sole document editor for two years.
エドワード・ルイスは、2年間、辛抱強く聞いている唯一のドキュメントエディターを務めました。
All "RFC" references below -- like all RFCs -- and information about the RFC series can be obtained from the RFC Editor web site at http://www.rfc-editor.org.
以下のすべての「RFC」参照 - すべてのRFCと同様に、RFCシリーズに関する情報は、http://www.rfc-editor.orgのRFCエディターWebサイトから入手できます。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R.、ed。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995] OHTA、M。、「DNSの増分ゾーン転送」、RFC 1995、1996年8月。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC1996] Vixie、P。、「ゾーンの変更の迅速な通知のメカニズム（DNS通知）」、RFC 1996、1996年8月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Ed。、Thomson、S.、Rekhter、Y.、およびJ. Bound、「ドメイン名システムの動的更新（DNSアップデート）」、RFC 2136、1997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672] Crawford、M。、「非末端DNS名リダイレクト」、RFC 2672、1999年8月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、RFC 2845、2000年5月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930] EastLake 3rd、D。、「DNSの秘密の鍵設立（TKEY RR）」、RFC 2930、2000年9月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931] EastLake 3rd、D。、「DNSリクエストとトランザクション署名（SIG（0）S）」、RFC 2931、2000年9月。
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002.
[RFC3425] Lawrence、D。、「Obereting Iquery」、RFC 3425、2002年11月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597] Gustafsson、A。、「不明なDNSリソースレコード（RR）タイプの取り扱い」、RFC 3597、2003年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張機能のリソースレコード」、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル修正」、RFC 4035、2005年3月。
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC4509] Hardaker、W。、「DNSSEC Delogation Signer（DS）Resource Records（RRS）でのSHA-256の使用」、RFC 4509、2006年5月。
[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", RFC 4635, August 2006.
[RFC4635] EastLake 3rd、D。、「HMAC SHA（ハッシュメッセージ認証コード、セキュアハッシュアルゴリズム）TSIGアルゴリズム識別子」、RFC 4635、2006年8月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）は認証された存在拒否」、RFC 5155、2008年3月。
[RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 5395, November 2008.
[RFC5395] EastLake 3rd、D。、「ドメイン名システム（DNS）IANAの考慮事項」、BCP 42、RFC 5395、2008年11月。
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009.
[RFC5702] Jansen、J。、「DNSKEYのRSAとDNSSECのRSAリソースレコードを使用したSHA-2アルゴリズムの使用」、RFC 5702、2009年10月。
[DNSVALS] IANA Registry "Domain Name System (DNS) Parameters", http://www.iana.org/.
[DNSVALS] IANAレジストリ「ドメイン名システム（DNS）パラメーター」、http：//www.iana.org/。
[IANA-AF] IANA Registry "Address Family Numbers", http://www.iana.org/.
[IANA-AF] IANAレジストリ「アドレスファミリー番号」、http://www.iana.org/。
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000.
[RFC2764] Gleeson、B.、Lin、A.、Heinanen、J.、Armitage、G。、およびA. Malis、「IPベースの仮想プライベートネットワークのフレームワーク」、RFC 2764、2000年2月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[DNSSEC-U] Weiler, S. and D. Blacka, "Clarifications and Implementation Notes for DNSSECbis", Work in Progress, March 2010.
[DNSSEC-U] Weiler、S。およびD. Blacka、「DNSSecbisの説明と実装ノート」、2010年3月、進行中の作業。
Authors' Addresses
著者のアドレス
Edward Lewis 46000 Center Oak Plaza Sterling, VA 20166 US
エドワードルイス46000センターオークプラザスターリング、バージニア州20166米国
EMail: ed.lewis@neustar.biz
Alfred Hoenes, Editor TR-Sys Gerlinger Str. 12 Ditzingen D-71254 Germany
Alfred Hoenes、編集者Tr-Sys Gerlinger str。12 Ditzingen D-71254ドイツ
EMail: ah@TR-Sys.de