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)
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）は、メカニズムの一つであり、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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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つの要素で構成されています。 [RFC1034]（RFC 1034として、この文書で言及）と「ドメイン名 - 実装と仕様」[RFC1035]（以下RFC 1035） - 権限の転送（AXFR）は、「概念および機能ドメイン名」で定義されています。増分ゾーン転送（IXFR）は、「DNSに増分ゾーン転送」[RFC1995]で定義されています。ゾーンの変更の迅速通知するためのメカニズムは、（NOTIFY）「ゾーン変更のプロンプト通知するためのメカニズム（DNSがNOTIFY）」[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.
それがうまくいけば、現代のインターネット標準から期待される精度で、大規模でインターネットに展開し、それによって、RFC 1034およびRFC 1035を更新しているので、この文書では、AXFRメカニズムを再指定します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[BCP14]「要求レベルを示すためのRFCsにおける使用のためのキーワード」に記載されているように解釈されます。
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.
「ターンキーの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ソリューションの一部が何らかの形で相互運用します。しかし、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.
DNSの実装はAXFR、IXFRをサポートし、通知する必要がされていないが、それは、ネームサーバの一貫性を維持するためのいくつかの手段を持っている必要があります。汎用DNS実装は、おそらくAXFRをサポートする（そして同じ静脈IXFRおよびNOTIFY）が、ターンキーDNS実装がAXFRなしで存在することができるであろう。
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およびNOTIFY）、少し配慮がセキュリティやプライバシーの問題に与えられました。 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
AXFRサブプロトコルの元の「仕様」は、RFC 1034及びRFC 1035のセクション（5ページ）RFC 1035の2.2 AXFRが設計されたシナリオを示しを通して散乱されます。 RFC 1034のセクション4.3.5は、ゾーンの同期一般的な戦略とAXFRを経由して、完全なゾーン転送の呼び出しのためのルールを説明し、そのセクションの第五の段落はAXFRプロトコルの非常に短いスケッチが含まれています。 RFC 2181のセクション5.5には、その仕様に重大な欠陥を修正しました。 RFC 1035のセクション3.2.3はAXFR QTYPEのコードポイントを割り当てた（詳細については、以下のセクション2.1.2を参照の
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.
詳細）。 RFC 1035のセクション4.2には、DNSは、トランスポート層を使用する方法について説明し、UDPトランスポートがAXFRのために不適切と判断された理由を簡単に説明します。 4.2.2節の最後の段落は、AXFRのためのTCP接続管理に関する詳細を提供します。最後に、ゾーンデータの変更がAXFRを使用して、進行中のゾーン転送中に発生したRFC 1035義務付けサーバ動作のセクション6.3の第二段落。
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の仕様を更新します。そのためには、完全に主にRFC 1034のセクション4.3.5の第5項に拡大し、AXFRのレコード形式と処理規則を指定し、それはこのようにさらにRFC 1035のセクション4.2.2を修正、AXFRのための輸送の考慮事項の詳細を、それは下位互換性の問題について説明し、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.
第4章（「メッセージ」）は、以下の文書により更新RFC 1035 [RFC1035]で定義されるようAXFRメッセージの基本フォーマットは、DNSメッセージです。
o The "Basic" DNS specification:
「基本」DNS仕様○：
- "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]
- 「ゾーンの変更のプロンプトの通知のメカニズム（DNSがNOTIFY）」[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のための秘密鍵確立（TKEYのRR）" [RFC2930]
- "Obsoleting IQUERY" [RFC3425]
- "時代遅れIQUERY" [RFC3425]
- "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
- [RFC3597] "未知のDNSリソースレコード（RR）タイプの取り扱い"
- "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:
これらの基本文書で定義されているDNSセキュリティ拡張機能（DNSSEC）、に関連するOさらなる追加：
- "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委任署名者でSHA-256の使用（DS）リソースレコード（RR）" [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とSHA-2アルゴリズムとDNSSECのためのRRSIGリソースレコードの使用" [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パラメータのIANAレジストリ[DNSVALS]）からDNSメッセージヘッダの概要は、非公式にここで再生されます。
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.
DNSメッセージの許容サイズの上限は、セクション4で説明したようにUDP上DNSの[RFC1035]（と[RFC2671]で指定さEDNS0機構を介してその拡張）からDNSメッセージサイズ制限は、AXFRに関連しませんTCPは、2つだけのオクテットメッセージ長フィールドを指定RFC 1035のセクション4.2.2で定義されたTCPフレーミングによって制限されている上に、未署名であると理解され、従って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のセクション4.3.5およびDNSは、[RFC1996]をNOTIFY参照）、またはコマンドライン要求の結果として、デバッグのために言うかもしれません。
These are the DNS message header values for an AXFR query.
これらは、AXFRクエリのDNSメッセージヘッダの値です。
ID Selected by client; see Note a)
クライアントによって選択されたID。 ）注記
QR MUST be 0 (Query)
QRは0でなければならない（クエリ）
OPCODE MUST be 0 (Standard Query)
OPCODEは0でなければなりません（標準クエリ）
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)
フラグ：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
回答セクションのエントリのANCOUNT数。 0であるに違いありません
NSCOUNT Number of entries in Authority section; MUST be 0
権威セクションのエントリのNSCOUNT数。 0であるに違いありません
ARCOUNT Number of entries in Additional section -- see Note d)
追加のセクションのエントリのARCOUNT数 - 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章、「トランスポート」を参照してください。）
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.
詳細は、2.2.1項a）において注記 - サーバーは、クライアントが同時に同じTCP接続上で優れた複数のクエリを持つことができるように、同じメッセージIDを使用したメッセージを使用して返答しなければなりません。
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の明示的な指定がない場合には、値が現在適用のRRの詳細については、0、1、または2を参照してくださいセクション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.
EDNSとDNSトランザクションセキュリティ：現在、リソースレコードの2種類がAXFRクエリと応答の追加セクションに表示できるように定義されています。通常の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リソースレコードに関連するかもしれないFORMERR（1）を返します。これを書いている時点で、OPT RRの唯一拡張RCODEフィールドは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.
追加のセクションに現れるかもしれ許容リソースレコードの範囲は、時間の経過とともに変更される可能性があります。 （EDNSのための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プロトコルは、資源レコードの順序付けられていないコレクションとしてゾーンの内容を処理する（または数学的用語を使用するように、「セット」）。転送が始まるとSOA RRで終わらなければならないという要件を除いて、任意の特定の方法で応答メッセージに任意の特定の順序またはグループ化されたRRを送信する必要はありません。サーバーには、一般的に連続したグループとして、関連する（例えばRRセットを形成するのRRとして、名前のRRセット）RRを送信しようとするか、または、メッセージ空間が許すとき、同じ応答メッセージに、彼らは、そうする必要はありませんが、クライアントは非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メッセージ内に収まる最大数まで、メッセージごとのオーバーヘッドを償却する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 - TCは、0（切り捨てられない）RD推奨でなければならない）注b参照：コピー要求の値。 ）Dを注記AD "MBZ" - - 注記Cを参照されたい）Z "MBZ" - 0にしてください0 RAに設定されるかもしれD注参照）CD "MBZ" - D注参照）
RCODE See Note e)
RCODE）注記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
ANCOUNT See Note f)
ANCOUNTを参照してください注F）
NSCOUNT MUST be 0
NSCOUNTは0でなければなりません
ARCOUNT See Note g)
ARCOUNTを参照してください注グラム）
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ビットはRCODEの他の値については1でなければなりません、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）に値を設定する必要があります。 （注意：[DNSVALS]適切なIANAレジストリを参照してください）クライアントが応答して他の値を受信した場合は、エラーに応じて行動しなければなりません。たとえば、不正な形式の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、または現在適用のRRおよび2.2.5項の詳細については、上記2.を参照してくださいセクション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）のRR、または任意の他の将来の記録がここに可能であるに従わなければなりません。 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セッションを考慮する必要があります。メッセージIDは、質問とAXFRサーバーが同じであっても、新しい接続で再使用されるかもしれません。
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.
ルール・セットまたはデータベースから、時間が経つにつれてゾーンの定義は、レコードの動的に更新されたセットをカバーするために、レコードの静的なセットを表すから進化してきました、その後、レコードの潜在的に継続的に再生されたセットは、（例えば、RRは「オンザフライ」に合成します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,
AXFR応答メッセージの回答セクションでは、与えられたシリアル番号のゾーン内のリソースレコードが表示される必要があります。ゾーンに属するものの定義は、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.
4.2節、（特定のセクション4.2.1、「技術的な考慮事項」で）「どのようにデータベースをゾーンに分割された」、それはRFC 2181の6章で明らかにされています。
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]、節参照1.1以前から「すべきである」ということを覚えておいてください）が表示されます：
The RRs that describe cuts ... should be exactly the same as the corresponding RRs in the top node of the subzone.
カット記述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の部分は歴史的であり、（DNSSECの初期仕様）RFC 2181の6.2。現在DNSSECコアドキュメントセットは、（上記のセクション2における第二弾を参照）DNSSEC（ビス）リソースレコードを配置するための完全な詳細を与え、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資源レコード集合は唯一のゾーンカットの親側で発生し、親ゾーンで正式なデータではなく、安全な子ゾーンです。
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資源レコード集合は、署名されたゾーンの頂点に発生し、それが機能するゾーンの正式なデータの一部です。
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資源レコード集合はゾーンカットの署名された親側と署名されたゾーンの頂点に起こります。彼らは、それぞれのゾーンの正式なデータです。同じサーバが親ゾーンと子ゾーンに対して権限のある場合RRSIGリソースレコードのための単純なクエリは、（RFC 4035の3.1.5項には、これらのRRを区別する方法について説明します）一度に両方のRRセットを返す場合があります。このような各RRSIG RRセットは単一のゾーンに属しているので、この見かけ上の曖昧さは、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]）リソースレコード均等ゾーンカットの親側に、ゾーンの頂点で起こり得ます。このような各リソースレコードは、これらのゾーンの正確に一つに属し、そのゾーンの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サーバが転送されているゾーンまたは正式な場所である1である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 RRセットの子ゾーンの権威NS RRセットで応答させた場合は、返されたレコードのセットは、サーバが権威のためにあることを起こったか否かに応じて変化させることができます子ゾーンにも。
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]として増分転送プロトコルの正しい動作のために必要です。例えば、クライアントが一つのサーバからの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]のレコードを接着することに適用されます。
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応答とは異なり、実際のゾーン転送は、のラベルのケースを保持する必要がありますゾーン内容。したがって、AXFRメッセージ内の名前の圧縮は、それが「通常」のDNS応答のためにどのように行われるかとは異なり、ケース・保存方法で実行する必要があります。すなわち、「」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の名前圧縮を管理する規則は、[RFC3597]、具体的には、「ドメイン名の圧縮」の第4章「未知のDNSリソースレコード（RR）タイプの取り扱い」の仕様を遵守しなければなりません。
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].
[RFC1123] - TCPへの制限は、「アプリケーションとサポートインターネットホストの要件」のセクション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接続は、唯一の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.
TCP接続がリモートで（クライアントに対して）閉じているときは、AXFRサーバやネットワークイベントに起因することによってか、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クライアントはAXFRセッションを開始するために、既に開かれたTCP接続を使用するかもしれません。既存の開いた接続を使用すると、新しい接続を開く上で推奨されます。 （非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と、このようなウェブホスティングおよびいくつかのENUMのシナリオのように多くの小さなゾーンを、必要とするアプリケーションの追加により、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.
実装では、アクセスは関係なく、送信元アドレスを詐称することができるかどうかの、インターネット・プロトコル・アドレスと範囲に付与することができるようにする必要があります。そのような仮想プライベートネットワーク（VPN）などの技術でこれを組み合わせると、[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）S）」[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クライアントは、ゾーンデータのみ正常に転送され、コピーがこのゾーンにサービスを提供するために使用できることを確認しなければなりません。前の説明と実装練習全体ゾーン同期手順の二段階モデルを導入した：トリガイベント時に（例えば、SOAリソースレコードのポーリングは、SOAシリアル番号の変更、またはDNS要求をNOTIFY [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サーバの実装の詳細に根ざしゾーンに使用される別の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）S）」を利用するために手段を提供すべきである[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.
この文書は、RFCの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）タイプ」副登録の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ラベルとドメイン名のために、問題は[RFC3490]やその後継（S）「アプリケーション（IDNA）で国際化ドメイン名」を介して解決されているものとします。
Earlier draft versions of this document have been edited by Andreas Gustafsson. In his latest draft version, this acknowledgment appeared:
このドキュメントの以前のドラフト版は、アンドレアス・グスタフソンによって編集されています。彼の最新のドラフト版では、この確認応答が現れました。
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.ホール、ジョッシュリトルフィールド、ケビン・ダーシー、ロバート・エルツ、レヴォンEsibov、マーク・アンドリュース、マイケル・パットン、ピーター・コッホに制限されていません、サムTrenholme、そしてブライアンウェリントン。
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.
マーク・アンドリュース、ポール・ヴィクシー、はWouter Wijngaards、イアン・カルダー、トニー・フィンチ、イアン・ジャクソン、アンドレアス・グスタフソン、ブライアンウェリントン、ニールオライリー、ビル・マニング、およびDNSEXTの作業の他の参加者：以降の草案へのコメントは、これらの個人から来ていますグループ。大型でIETFからの重要なコメントはサブラマニアンMoonesamy、クリスLonvick、およびビジェイ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 EditorのWebサイトから入手することができます。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、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]ブレーデン、R.、エド、 "インターネットホストのための要件 - 、アプリケーションとサポート"。、STD 3、RFC 1123、1989年10月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]太田、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.、RFC 1996、1996年8月 "ゾーンの変更（DNSがNOTIFY）のプロンプト通知のメカニズム"。
[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.編、トムソン、S.、Rekhter、Y.、およびJ.はバウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、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]クロフォード、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.、グドムンソン、O.、イーストレイク3日、D.、およびB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、RFC 2845、2000年5月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]イーストレーク第3、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]イーストレイク3日、D.、 "DNS要求とトランザクション署名（SIG（0）S）"、RFC 2931、2000年9月。
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002.
[RFC3425]ローレンス、D.、 "IQUERYを時代遅れ"、RFC 3425、2002年11月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]グスタフソン、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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.、RFC 4509、2006年5月 "DNSSEC委任署名者（DS）リソースレコード（RR）でSHA-256の使用"。
[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", RFC 4635, August 2006.
[RFC4635]イーストレイク3日、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]ローリー、B.、シッソン、G.、アレンズ、R.、およびD. Blacka、 "DNSセキュリティ（DNSSEC）存在のハッシュ認証拒否"、RFC 5155、2008年3月。
[RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 5395, November 2008.
[RFC5395]イーストレイク3日、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]ヤンセン、J.、 "DNSKEYとDNSSECのためのRRSIGリソースレコードで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]グリーソン、B.、林、A.、Heinanen、J.、アーミテージ、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.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、2004年8月。
[DNSSEC-U] Weiler, S. and D. Blacka, "Clarifications and Implementation Notes for DNSSECbis", Work in Progress, March 2010.
[DNSSEC-U]ワイラー、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
メールアドレス：ed.lewis@neustar.biz
Alfred Hoenes, Editor TR-Sys Gerlinger Str. 12 Ditzingen D-71254 Germany
アルフレッドHoenes、エディタTR-SYS GerlingerのStr。 12 DitzingenのD-71254ドイツ
EMail: ah@TR-Sys.de
メールアドレス：ah@TR-Sys.de