Network Working Group D. Eastlake
Request for Comments: 2535 IBM
Obsoletes: 2065 March 1999
Updates: 2181, 1035, 1034
Category: Standards Track
Domain Name System Security Extensions
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can also be provided through non-security aware DNS servers in some cases.
ドメインネームシステム（DNS）への拡張は、暗号化、デジタル署名を使用して、セキュリティ対応リゾルバとアプリケーションへのデータの整合性と認証を提供することが記載されています。これらのデジタル署名は、リソースレコードとして確保のゾーンに含まれています。セキュリティにもいくつかのケースでは非セキュリティ意識のDNSサーバを介して提供することができます。
The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.
拡張子は、DNSで認証された公開鍵の保管を提供します。このキーのストレージは、一般的な公開鍵配信サービスだけでなく、DNSのセキュリティをサポートすることができます。保存されたキーは、彼らが最初に設定されているものに加えて、ゾーンの認証キーを学ぶために、セキュリティ対応リゾルバを有効にします。 DNS名に関連付けられたキーが他のプロトコルをサポートするために取得することができます。引当金は、キーの種類とさまざまなアルゴリズムのために作られています。
In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests.
また、セキュリティ拡張はDNSプロトコルのトランザクションとリクエストのオプションの認証を提供します。
This document incorporates feedback on RFC 2065 from early implementers and potential users.
この文書では、早期に実装し、潜在的なユーザーからのRFC 2065に関するフィードバックを内蔵しています。
Acknowledgments
謝辞
The significant contributions and suggestions of the following persons (in alphabetic order) to DNS security are gratefully acknowledged:
DNSセキュリティに対する重要な貢献と（アルファベット順）次の者の提案は深く感謝しています。
James M. Galvin John Gilmore Olafur Gudmundsson Charlie Kaufman Edward Lewis Thomas Narten Radia J. Perlman Jeffrey I. Schiller Steven (Xunhua) Wang Brian Wellington
ジェームスM.ガルビンジョン・ギルモアオラフルグドムンソンチャーリー・カウフマンエドワード・ルイス・トーマスNarten氏のRadia J.パールマンジェフリーI.シラースティーブン（Xunhua）王ブライアンウェリントン
Table of Contents
目次
Abstract...................................................1
Acknowledgments............................................2
1. Overview of Contents....................................4
2. Overview of the DNS Extensions..........................5
2.1 Services Not Provided..................................5
2.2 Key Distribution.......................................5
2.3 Data Origin Authentication and Integrity...............6
2.3.1 The SIG Resource Record..............................7
2.3.2 Authenticating Name and Type Non-existence...........7
2.3.3 Special Considerations With Time-to-Live.............7
2.3.4 Special Considerations at Delegation Points..........8
2.3.5 Special Considerations with CNAME....................8
2.3.6 Signers Other Than The Zone..........................9
2.4 DNS Transaction and Request Authentication.............9
3. The KEY Resource Record................................10
3.1 KEY RDATA format......................................10
3.1.1 Object Types, DNS Names, and Keys...................11
3.1.2 The KEY RR Flag Field...............................11
3.1.3 The Protocol Octet..................................13
3.2 The KEY Algorithm Number Specification................14
3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
3.4 Determination of Zone Secure/Unsecured Status.........15
3.5 KEY RRs in the Construction of Responses..............17
4. The SIG Resource Record................................17
4.1 SIG RDATA Format......................................17
4.1.1 Type Covered Field..................................18
4.1.2 Algorithm Number Field..............................18
4.1.3 Labels Field........................................18
4.1.4 Original TTL Field..................................19
4.1.5 Signature Expiration and Inception Fields...........19
4.1.6 Key Tag Field.......................................20
4.1.7 Signer's Name Field.................................20
4.1.8 Signature Field.....................................20
4.1.8.1 Calculating Transaction and Request SIGs..........21
4.2 SIG RRs in the Construction of Responses..............21
4.3 Processing Responses and SIG RRs......................22
4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
5. Non-existent Names and Types...........................24
5.1 The NXT Resource Record...............................24
5.2 NXT RDATA Format......................................25
5.3 Additional Complexity Due to Wildcards................26
5.4 Example...............................................26
5.5 Special Considerations at Delegation Points...........27
5.6 Zone Transfers........................................27
5.6.1 Full Zone Transfers.................................28
5.6.2 Incremental Zone Transfers..........................28
6. How to Resolve Securely and the AD and CD Bits.........29
6.1 The AD and CD Header Bits.............................29
6.2 Staticly Configured Keys..............................31
6.3 Chaining Through The DNS..............................31
6.3.1 Chaining Through KEYs...............................31
6.3.2 Conflicting Data....................................33
6.4 Secure Time...........................................33
7. ASCII Representation of Security RRs...................34
7.1 Presentation of KEY RRs...............................34
7.2 Presentation of SIG RRs...............................35
7.3 Presentation of NXT RRs...............................36
8. Canonical Form and Order of Resource Records...........36
8.1 Canonical RR Form.....................................36
8.2 Canonical DNS Name Order..............................37
8.3 Canonical RR Ordering Within An RRset.................37
8.4 Canonical Ordering of RR Types........................37
9. Conformance............................................37
9.1 Server Conformance....................................37
9.2 Resolver Conformance..................................38
10. Security Considerations...............................38
11. IANA Considerations...................................39
References................................................39
Author's Address..........................................41
Appendix A: Base 64 Encoding..............................42
Appendix B: Changes from RFC 2065.........................44
Appendix C: Key Tag Calculation...........................46
Full Copyright Statement..................................47
This document standardizes extensions of the Domain Name System (DNS) protocol to support DNS security and public key distribution. It assumes that the reader is familiar with the Domain Name System, particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An earlier version of these extensions appears in RFC 2065. This replacement for that RFC incorporates early implementation experience and requests from potential users.
この文書では、DNSのセキュリティと公開鍵配布をサポートするためのドメインネームシステム（DNS）プロトコルの拡張を標準化しています。これは、読者がRFCの後1033、1034、1035およびRFCに記載のように、特に、ドメインネームシステムに精通していることを前提としています。これらの拡張機能の以前のバージョンは、そのRFCのためのこの置換は、初期の実装経験と潜在的なユーザーからの要望を取り入れRFC 2065に表示されます。
Section 2 provides an overview of the extensions and the key distribution, data origin authentication, and transaction and request security they provide.
第2節では、それらが提供する拡張機能や鍵の配布、データ発信元認証、およびトランザクションおよび要求のセキュリティの概要を説明します。
Section 3 discusses the KEY resource record, its structure, and use in DNS responses. These resource records represent the public keys of entities named in the DNS and are used for key distribution.
第3節では、DNS応答のKEYリソースレコード、その構造、および使用について説明します。これらのリソースレコードがDNSで指定されたエンティティの公開鍵を表し、鍵配布のために使用されています。
Section 4 discusses the SIG digital signature resource record, its structure, and use in DNS responses. These resource records are used to authenticate other resource records in the DNS and optionally to authenticate DNS transactions and requests.
セクション4は、SIGデジタル署名リソースレコード、その構造、およびDNS応答の使用を論じています。これらのリソースレコードがDNS内の他のリソースレコードを認証するために使用されており、必要に応じてDNSトランザクションと要求を認証します。
Section 5 discusses the NXT resource record (RR) and its use in DNS responses including full and incremental zone transfers. The NXT RR permits authenticated denial of the existence of a name or of an RR type for an existing name.
第5節では、NXTリソースレコード（RR）とフルと増分ゾーン転送を含むDNS応答での使用について説明します。 NXTのRR許可は、既存の名前の名前またはRRタイプの存在の否定を認証済み。
Section 6 discusses how a resolver can be configured with a starting key or keys and proceed to securely resolve DNS requests. Interactions between resolvers and servers are discussed for various combinations of security aware and security non-aware. Two additional DNS header bits are defined for signaling between resolvers and servers.
第6節は、リゾルバが起動キーまたはキーを使用して構成し、安全にDNS要求を解決するために進めることができる方法について説明します。リゾルバとサーバ間の相互作用は、セキュリティ意識とセキュリティ非意識の様々な組み合わせのために議論されています。二つの追加DNSヘッダビットは、リゾルバとサーバ間のシグナリングのために定義されています。
Section 7 describes the ASCII representation of the security resource records for use in master files and elsewhere.
第7節は、他の場所でマスターファイルとで使用するためのセキュリティリソースレコードのASCII表現を記述する。
Section 8 defines the canonical form and order of RRs for DNS security purposes.
第8章は、DNSのセキュリティのためにRRの正規の形式と順序を定義します。
Section 9 defines levels of conformance for resolvers and servers.
第9章は、リゾルバとサーバーの適合性のレベルを定義します。
Section 10 provides a few paragraphs on overall security considerations.
セクション10は、全体的なセキュリティの考慮事項には、いくつかの段落を提供します。
Section 11 specified IANA considerations for allocation of additional values of paramters defined in this document.
セクション11は、この文書で定義されたパラメータの追加の値の割り当てのためのIANA問題を指定しました。
Appendix A gives details of base 64 encoding which is used in the file representation of some RRs defined in this document.
付録Aは、この文書で定義されたいくつかのRRのファイルの表現に使用されるベース64符号化の詳細を与えます。
Appendix B summarizes changes between this memo and RFC 2065.
付録Bは、このメモとRFC 2065の間の変化をまとめたもの。
Appendix C specified how to calculate the simple checksum used as a key tag in most SIG RRs.
付録Cは、ほとんどのSIGのRRにキータグとして使用される単純なチェックサムを計算する方法を指定しました。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The Domain Name System (DNS) protocol security extensions provide three distinct services: key distribution as described in Section 2.2 below, data origin authentication as described in Section 2.3 below, and transaction and request authentication, described in Section 2.4 below.
ドメインネームシステム（DNS）プロトコルのセキュリティ拡張機能は、3つの異なるサービスを提供します。鍵の配布を、以下のセクション2.4で説明し、以下のセクション2.3、およびトランザクションおよび要求の認証で説明したように、以下のセクション2.2、データ発信元認証で説明したように。
Special considerations related to "time to live", CNAMEs, and delegation points are also discussed in Section 2.3.
「生存時間」に関連する特別な考慮事項は、のCNAME、および委任ポイントは、2.3節で議論されています。
It is part of the design philosophy of the DNS that the data in it is public and that the DNS gives the same answers to all inquirers. Following this philosophy, no attempt has been made to include any sort of access control lists or other means to differentiate inquirers.
それはそれで、データが公共およびDNSは、すべての照会者に同じ答えを与えることであることをDNSの設計哲学の一部です。この理念に続き、試みは、アクセス制御リストや照会者を区別するための他の手段の任意の並べ替えを含めるようになされていません。
No effort has been made to provide for any confidentiality for queries or responses. (This service may be available via IPSEC [RFC 2401], TLS, or other security protocols.)
努力は、クエリまたは応答のいずれかの機密性を提供するために行われていません。 （このサービスはIPSEC [RFC 2401]、TLS、または他のセキュリティプロトコルを介して利用可能であってもよいです。）
Protection is not provided against denial of service.
保護は、サービス拒否に対して提供されていません。
A resource record format is defined to associate keys with DNS names. This permits the DNS to be used as a public key distribution mechanism in support of DNS security itself and other protocols.
リソースレコードのフォーマットは、DNS名を持つキーを関連付けるために定義されています。これは、DNSのセキュリティ自体や他のプロトコルをサポートする公開鍵配布メカニズムとして使用するDNSを許可します。
The syntax of a KEY resource record (RR) is described in Section 3. It includes an algorithm identifier, the actual public key parameter(s), and a variety of flags including those indicating the type of entity the key is associated with and/or asserting that there is no key associated with that entity.
KEYリソースレコード（RR）の構文は、セクション3に記載されているこれは、キーが関連付けられているエンティティのタイプを示すアルゴリズム識別子、実際の公開鍵パラメータ（単数または複数）、およびそれらを含むフラグの多様を含み、および/またはまたはそのエンティティに関連付けられたキーが存在しないことを主張します。
Under conditions described in Section 3.5, security aware DNS servers will automatically attempt to return KEY resources as additional information, along with those resource records actually requested, to minimize the number of queries needed.
セクション3.5に記載された条件の下では、セキュリティ対応DNSサーバーは、自動的に必要なクエリの数を最小限にするために、実際に要求されたそれらのリソースレコードと一緒に、付加情報としてKEYリソースを返そうとします。
Authentication is provided by associating with resource record sets (RRsets [RFC 2181]) in the DNS cryptographically generated digital signatures. Commonly, there will be a single private key that authenticates an entire zone but there might be multiple keys for different algorithms, signers, etc. If a security aware resolver reliably learns a public key of the zone, it can authenticate, for signed data read from that zone, that it is properly authorized. The most secure implementation is for the zone private key(s) to be kept off-line and used to re-sign all of the records in the zone periodically. However, there are cases, for example dynamic update [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC 2541].
認証は、暗号デジタル署名を生成したDNSのリソースレコードセット（RRセット[RFC 2181]）と関連付けることによって提供されます。一般的に、ゾーン全体を認証しますが、セキュリティ対応リゾルバが確実ゾーンの公開鍵を学習した場合など、異なるアルゴリズム、署名者のための複数のキーがあるかもしれない単一の秘密鍵があるだろう、それが署名されたデータの読み取りのために、認証を行うことができますそのゾーンから、それが適切に承認されていること。最も安全な実装では、オフラインで保管し、定期的にゾーン内のすべてのレコードを再署名するために使用されるゾーンの秘密鍵（S）のためです。しかし、場合があり、例えば動的更新【のRFC 2136、2137]、DNS秘密鍵は、[RFC 2541]にオンラインである必要があります。
The data origin authentication key(s) are associated with the zone and not with the servers that store copies of the data. That means compromise of a secondary server or, if the key(s) are kept off line, even the primary server for a zone, will not necessarily affect the degree of assurance that a resolver has that it can determine whether data is genuine.
データ発信元認証キー（S）は、ゾーンではなく、データのコピーを保存するサーバに関連付けられています。すなわち、二次サーバーの妥協を意味し、または、キー（複数可）ゾーンに対しても、プライマリサーバ、ラインオフのままである場合、必ずしもリゾルバは、データが本物であるかどうかを決定することができることを持っていることを保証の程度に影響を与えないであろう。
A resolver could learn a public key of a zone either by reading it from the DNS or by having it staticly configured. To reliably learn a public key by reading it from the DNS, the key itself must be signed with a key the resolver trusts. The resolver must be configured with at least a public key which authenticates one zone as a starting point. From there, it can securely read public keys of other zones, if the intervening zones in the DNS tree are secure and their signed keys accessible.
リゾルバは、DNSからそれを読み取ることによって、またはそれが静的に設定されたことにより、いずれかのゾーンの公開鍵を学ぶことができました。確実にDNSからそれを読み取ることによって、公開鍵を学習するには、キー自体は、レゾルバ信託鍵で署名する必要があります。リゾルバは、出発点として一つのゾーンを認証し、少なくとも公開鍵を使用して構成されなければなりません。 DNSツリー内の介在ゾーンが安全かつその署名キーにアクセスしている場合があるから、それはしっかりと、他のゾーンの公開鍵を読み取ることができます。
Adding data origin authentication and integrity requires no change to the "on-the-wire" DNS protocol beyond the addition of the signature resource type and the key resource type needed for key distribution. (Data non-existence authentication also requires the NXT RR as described in 2.3.2.) This service can be supported by existing resolver and caching server implementations so long as they can support the additional resource types (see Section 9). The one exception is that CNAME referrals in a secure zone can not be authenticated if they are from non-security aware servers (see Section 2.3.5).
データ発信元認証及び完全性を追加すると、署名のリソースタイプと鍵配布のために必要なキーリソースタイプの付加を超えて「オン・ザ・ワイヤ」DNSプロトコルへの変更を必要としません。 （データ非実在認証はまた、2.3.2で説明したようにNXT RRを必要とします。）このサービスは長い間、彼らは追加のリソースタイプを（セクション9を参照）をサポートできるよう、既存のリゾルバとキャッシュサーバ実装によってサポートすることができます。唯一の例外は、彼らが非セキュリティ対応サーバ（2.3.5項を参照）からであれば、セキュアゾーンでCNAME紹介を認証することができないということです。
If signatures are separately retrieved and verified when retrieving the information they authenticate, there will be more trips to the server and performance will suffer. Security aware servers mitigate that degradation by attempting to send the signature(s) needed (see Section 4.2).
彼らは認証情報を取得する際の署名を別々に取得され、検証されている場合は、サーバーとパフォーマンスへのより多くの旅行は苦しむことになるがあるでしょう。セキュリティ意識のサーバーが必要な署名（複数可）（4.2節を参照）を送信しようとすることによって、その劣化を軽減します。
The syntax of a SIG resource record (signature) is described in Section 4. It cryptographicly binds the RRset being signed to the signer and a validity interval.
SIGリソースレコード（署名）の構文は、それがcryptographicly署名と有効期間に署名さRRセットを結合する第4項に記載されています。
Every name in a secured zone will have associated with it at least one SIG resource record for each resource type under that name except for glue address RRs and delegation point NS RRs. A security aware server will attempt to return, with RRs retrieved, the corresponding SIGs. If a server is not security aware, the resolver must retrieve all the SIG records for a name and select the one or ones that sign the resource record set(s) that resolver is interested in.
セキュリティで保護されたゾーン内のすべての名前がのりアドレスのRRと委任ポイントNS RRを除いその名前の下に、各リソースタイプのそれ少なくとも一つのSIGリソースレコードに関連付けられています。セキュリティ意識のサーバーは、対応のSIG、取り出さのRRと、返そうとします。サーバは、セキュリティ認識していない場合は、リゾルバは名前のためのすべてのSIGレコードを取得し、リソースレコードセット（S）というリゾルバが興味を持っているの署名1かのものを選択する必要があります。
The above security mechanism only provides a way to sign existing RRsets in a zone. "Data origin" authentication is not obviously provided for the non-existence of a domain name in a zone or the non-existence of a type for an existing name. This gap is filled by the NXT RR which authenticatably asserts a range of non-existent names in a zone and the non-existence of types for the existing name just before that range.
上記のセキュリティ・メカニズムは、ゾーン内の既存のRRセットに署名する方法を提供します。 「データの起源」の認証を明らかにゾーン内のドメイン名または既存の名前のためのタイプの非存在の非存在のために提供されていません。このギャップはauthenticatablyゾーンとちょうどその範囲の前に既存の名前の型の非存在し、存在しない名前の範囲を主張するのNXT RRによって満たされています。
Section 5 below covers the NXT RR.
第5節では、以下のNXT RRをカバーしています。
A digital signature will fail to verify if any change has occurred to the data between the time it was originally signed and the time the signature is verified. This conflicts with our desire to have the time-to-live (TTL) field of resource records tick down while they are cached.
デジタル署名は、任意の変更は、それが最初に署名された時間と署名が検証される時間との間のデータに発生したかどうかを確認することができないであろう。それらがキャッシュされている間、リソースレコードの生存時間（TTL）フィールドを持っている私たちの願いと、この競合がダウンダニ。
This could be avoided by leaving the time-to-live out of the digital signature, but that would allow unscrupulous servers to set arbitrarily long TTL values undetected. Instead, we include the "original" TTL in the signature and communicate that data along with the current TTL. Unscrupulous servers under this scheme can manipulate the TTL but a security aware resolver will bound the TTL value it uses at the original signed value. Separately, signatures include a signature inception time and a signature expiration time. A resolver that knows the absolute time can determine securely whether a signature is in effect. It is not possible to rely solely on the signature expiration as a substitute for the TTL, however, since the TTL is primarily a database consistency mechanism and non-security aware servers that depend on TTL must still be supported.
これは、デジタル署名のうち、生存時間を残すことによって回避できるが、それは不謹慎なサーバが検出されない任意の長いTTL値を設定することができるようになります。その代わりに、我々は、署名に「元の」TTLを含め、現在のTTLと共にそのデータを通信します。このスキームの下での悪質なサーバーでは、TTLを操作することができますが、セキュリティ対応リゾルバは、それが本来の符号付きの値で使用するTTL値をバインドします。別々に、署名は署名開始時間と署名の有効期限が含まれます。絶対時間を知っているリゾルバは、署名が有効であるかどうかを確実に判断することができます。 TTLは、主にTTLに依存して、データベースの整合性メカニズムと非セキュリティ対応サーバはまだサポートされなければならないですので、しかし、TTLの代替として、署名の有効期限のみに依存することはできません。
DNS security would like to view each zone as a unit of data completely under the control of the zone owner with each entry (RRset) signed by a special private key held by the zone manager. But the DNS protocol views the leaf nodes in a zone, which are also the apex nodes of a subzone (i.e., delegation points), as "really" belonging to the subzone. These nodes occur in two master files and might have RRs signed by both the upper and lower zone's keys. A retrieval could get a mixture of these RRs and SIGs, especially since one server could be serving both the zone above and below a delegation point. [RFC 2181]
DNSセキュリティは完全にゾーン・マネージャによって保持された特別な秘密鍵によって署名された各エントリ（RRセット）を持つゾーン所有者の管理下にあるデータの単位として、各ゾーンを表示したいと思います。しかし、DNSプロトコルは「本当に」サブゾーンに属するものとして、またサブゾーン（すなわち、委任ポイント）の頂点ノードであり、ゾーン内のリーフノードを、見ています。これらのノードは、2つのマスターファイルで発生し、上下のゾーンの両方のキーが署名したRRを持っているかもしれません。検索は、一つのサーバがゾーン委任ポイントの上方および下方の両方配信することができ、特に以来、これらのRRとのSIGの混合物を得ることができます。 [RFC 2181]
There MUST be a zone KEY RR, signed by its superzone, for every subzone if the superzone is secure. This will normally appear in the subzone and may also be included in the superzone. But, in the case of an unsecured subzone which can not or will not be modified to add any security RRs, a KEY declaring the subzone to be unsecured MUST appear with the superzone signature in the superzone, if the superzone is secure. For all but one other RR type the data from the subzone is more authoritative so only the subzone KEY RR should be signed in the superzone if it appears there. The NS and any glue address RRs SHOULD only be signed in the subzone. The SOA and any other RRs that have the zone name as owner should appear only in the subzone and thus are signed only there. The NXT RR type is the exceptional case that will always appear differently and authoritatively in both the superzone and subzone, if both are secure, as described in Section 5.
上位ゾーンが安全である場合は、すべてのサブゾーンのために、その上位ゾーンによって署名されたゾーンKEYのRR、があるに違いありません。これは通常、サブゾーンに表示され、また、上位ゾーンに含まれていてもよいです。上位ゾーンが安全である場合でも、または任意のセキュリティRRを追加するように変更されることはありませんができない無担保サブゾーンの場合には、サブゾーンを宣言するKEYは、上位ゾーンにおける上位ゾーンの署名が現れなければならない無担保されるように。すべての1が、他のRRタイプについてサブゾーンからのデータは、それが表示された場合のみ、そのサブゾーンKEY RRは上位ゾーンに署名しなければならない多くの権威です。 NSおよび任意の接着剤アドレスRRは唯一のサブゾーンに署名される必要があります。 SOAおよび所有者としてゾーン名を持つ他のRRは唯一のサブゾーンに表示されますので、そこだけに署名されています。 NXTのRRタイプは、両方が安全である場合、セクション5で説明したように、常に、上位ゾーンとサブゾーンの両方で異なると正式現れる例外的なケースです。
There is a problem when security related RRs with the same owner name as a CNAME RR are retrieved from a non-security-aware server. In particular, an initial retrieval for the CNAME or any other type may not retrieve any associated SIG, KEY, or NXT RR. For retrieved types other than CNAME, it will retrieve that type at the target name of the CNAME (or chain of CNAMEs) and will also return the CNAME. In particular, a specific retrieval for type SIG will not get the SIG, if any, at the original CNAME domain name but rather a SIG at the target name.
CNAME RRと同じ所有者名を持つセキュリティ関連のRRは、非セキュリティ対応のサーバから取得している問題があります。具体的には、CNAMEのための初期検索または任意の他のタイプは、任意の関連するSIG、KEY、またはNXT RRを取得できません。 CNAME以外取り出さタイプの場合、それはCNAME（またはのCNAMEの連鎖）のターゲット名でその型を取得し、また、CNAMEが返されます。特に、タイプSIGのための具体的な検索は、元のCNAMEドメイン名ではなく、ターゲット名のSIGで、もしあれば、SIGを取得することはありません。
Security aware servers must be used to securely CNAME in DNS. Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along with CNAME RRs, (2) suppress CNAME processing on retrieval of these types as well as on retrieval of the type CNAME, and (3) automatically return SIG RRs authenticating the CNAME or CNAMEs encountered in resolving a query. This is a change from the previous DNS standard [RFCs 1034/1035] which prohibited any other RR type at a node where a CNAME RR was present.
セキュリティ対応サーバは、DNSにまでしっかりとCNAMEを使用する必要があります。セキュリティ対応サーバは、（1）（2）これらのタイプの検索に、ならびにタイプCNAMEの検索にCNAME処理を抑制し、（3）自動SIGのRR認証を返す、CNAMEのRRと共にKEY、SIG、およびNXT RRを許容しなければなりませんCNAMEやのCNAMEクエリを解決する際に遭遇しました。これは、CNAME RRが存在したノードに、他のRRタイプを禁止以前のDNS標準【のRFC 1035分の1034]からの変更です。
There are cases where the signer in a SIG resource record is other than one of the private key(s) used to authenticate a zone.
SIGリソース・レコードの署名者がゾーンを認証するために使用される秘密鍵（S）の1以外である場合があります。
One is for support of dynamic update [RFC 2136] (or future requests which require secure authentication) where an entity is permitted to authenticate/update its records [RFC 2137] and the zone is operating in a mode where the zone key is not on line. The public key of the entity must be present in the DNS and be signed by a zone level key but the other RR(s) may be signed with the entity's key.
エンティティがそのレコードを更新/認証することを許可される一方は、[RFC 2137]動的更新[RFC 2136]（または安全な認証を必要とする将来の要求）をサポートするためのものであり、ゾーンは、ゾーンキーがオンになっていないモードで動作していますライン。エンティティの公開鍵がDNSに存在しなければならないとゾーンレベルキーによって署名さが、他のRR（s）はエンティティのキーで署名されてもよいです。
A second case is support of transaction and request authentication as described in Section 2.4.
2.4節で説明したように、第2の場合は、トランザクションおよび要求の認証のサポートです。
In additions, signatures can be included on resource records within the DNS for use by applications other than DNS. DNS related signatures authenticate that data originated with the authority of a zone owner or that a request or transaction originated with the relevant entity. Other signatures can provide other types of assurances.
追加で、署名がDNS以外のアプリケーションで使用するためにDNS内のリソースレコードに含めることができます。 DNS関連の署名は、データがゾーン所有者の権限で始まったり、要求またはトランザクションが関連するエンティティが起源ということを認証します。他の署名は、保証の他の種類を提供することができます。
The data origin authentication service described above protects retrieved resource records and the non-existence of resource records but provides no protection for DNS requests or for message headers.
上記データ発信元認証サービスは、検索されたリソースレコードおよびリソースレコードの非存在を保護しますが、DNS要求またはメッセージヘッダを保護しません。
If header bits are falsely set by a bad server, there is little that can be done. However, it is possible to add transaction authentication. Such authentication means that a resolver can be sure it is at least getting messages from the server it thinks it queried and that the response is from the query it sent (i.e., that these messages have not been diddled in transit). This is accomplished by optionally adding a special SIG resource record at the end of the reply which digitally signs the concatenation of the server's response and the resolver's query.
ヘッダビットが誤って悪いサーバによって設定されている場合、行うことができ、そのほとんどがあります。しかし、トランザクションの認証を追加することが可能です。このような認証は、リゾルバが、それは、少なくとも、それが照会および応答は、それが（これらのメッセージは、輸送中にdiddledされていないこと、すなわち）送信されたクエリからのものであることを考えて、サーバーからメッセージを取得していることを確認することができますことを意味しています。これは、必要に応じてデジタルサーバの応答とレゾルバのクエリの連結に署名応答の最後に特殊SIGリソースレコードを追加することによって達成されます。
Requests can also be authenticated by including a special SIG RR at the end of the request. Authenticating requests serves no function in older DNS servers and requests with a non-empty additional information section produce error returns or may even be ignored by many of them. However, this syntax for signing requests is defined as a way of authenticating secure dynamic update requests [RFC 2137] or future requests requiring authentication.
要求はまた、要求の終了時に特別なSIG RRを含むによって認証することができます。リクエストの認証は、古いDNSサーバに何の機能を果たしていないと、空でない追加情報セクション農産物エラーリターンを要求したり、それらの多くでは無視することができます。しかし、署名要求のためのこの構文は、セキュリティで保護された動的更新要求[RFC 2137]または認証を必要とする将来の要求を認証する方法として定義されます。
The private keys used in transaction security belong to the entity composing the reply, not to the zone involved. Request authentication may also involve the private key of the host or other entity composing the request or other private keys depending on the request authority it is sought to establish. The corresponding public key(s) are normally stored in and retrieved from the DNS for verification.
トランザクションのセキュリティで使用される秘密鍵が返事を構成するエンティティにではなく、関係するゾーンに属しています。要求の認証も要求または確立することを求められている要求の権限に応じて、他の秘密鍵を構成するホストまたは他のエンティティの秘密鍵を含むことができます。対応する公開鍵（単数または複数）は、通常に格納され、検証のためのDNSから取得されます。
Because requests and replies are highly variable, message authentication SIGs can not be pre-calculated. Thus it will be necessary to keep the private key on-line, for example in software or in a directly connected piece of hardware.
要求と応答が非常に多様であるため、メッセージ認証のSIGは、事前に計算することができません。したがって、ソフトウェアやハードウェアの直接接続された作品では、たとえば、オンラインの秘密鍵を保持する必要があります。
The KEY resource record (RR) is used to store a public key that is associated with a Domain Name System (DNS) name. This can be the public key of a zone, a user, or a host or other end entity. Security aware DNS implementations MUST be designed to handle at least two simultaneously valid keys of the same type associated with the same name.
KEYリソースレコード（RR）は、ドメインネームシステム（DNS）名に関連付けられている公開鍵を格納するために使用されます。これは、ゾーン、ユーザー、またはホストまたは他のエンドエンティティの公開鍵することができます。セキュリティ意識のDNS実装では、同じ名前に関連付けられた同じタイプの少なくとも二つを同時に有効なキーを処理するように設計されなければなりません。
The type number for the KEY RR is 25.
KEYのRRのタイプ番号は25です。
A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs must be signed by a zone level key.
KEY RRはSIGのRRによって認証他のRR、同様に、です。 KEY RRはゾーンレベルの鍵で署名されなければなりません。
The RDATA for a KEY RR consists of flags, a protocol octet, the algorithm number octet, and the public key itself. The format is as follows:
KEYのRRのためのRDATAは、プロトコルオクテット、アルゴリズム番号オクテット、及び公開鍵自体、フラグから成ります。形式は次のとおりです。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The KEY RR is not intended for storage of certificates and a separate certificate RR has been developed for that purpose, defined in [RFC 2538].
RRは、証明書の保管及び別証明書RRのために意図されていないキーは、[RFC 2538]で定義され、その目的のために開発されました。
The meaning of the KEY RR owner name, flags, and protocol octet are described in Sections 3.1.1 through 3.1.5 below. The flags and algorithm must be examined before any data following the algorithm octet as they control the existence and format of any following data. The algorithm and public key fields are described in Section 3.2. The format of the public key is algorithm dependent.
KEY RRの所有者名、フラグ、およびプロトコルオクテットの意味は以下の3.1.5を介してセクション3.1.1に記載されています。彼らはいずれかの次のデータの存在と形式を制御してフラグとアルゴリズムは、アルゴリズムオクテット以下のいずれかのデータの前に検討する必要があります。アルゴリズムと公開鍵フィールドは、セクション3.2で説明されています。公開鍵の形式は、アルゴリズムに依存しています。
KEY RRs do not specify their validity period but their authenticating SIG RR(s) do as described in Section 4 below.
KEY RRは、その有効期間を指定しませんが、以下のセクション4で説明したように、その認証SIGのRR（複数可）を行います。
The public key in a KEY RR is for the object named in the owner name.
KEYのRRにおける公開鍵は、所有者名で指定されたオブジェクトのためです。
A DNS name may refer to three different categories of things. For example, foo.host.example could be (1) a zone, (2) a host or other end entity , or (3) the mapping into a DNS name of the user or account foo@host.example. Thus, there are flag bits, as described below, in the KEY RR to indicate with which of these roles the owner name and public key are associated. Note that an appropriate zone KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs occur only at delegation points.
DNS名は、物事の3つのカテゴリを参照してもよいです。例えば、foo.host.example（1）ゾーン、（2）ホストまたは他のエンドエンティティ、またはユーザまたはアカウントfoo@host.exampleのDNS名（3）にマッピングすることができました。これらの役割の所有者名と公開鍵が関連付けられている指示するためのキーのRRに、以下に説明したように、フラグビットがあります。適切なゾーンKEY RRは、セキュアゾーンの頂点ノードで発生しなければならないことに注意してくださいとゾーン鍵資源レコードは、委任点で発生します。
In the "flags" field:
「フラグ」フィールドに：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Bit 0 and 1 are the key "type" bits whose values have the following meanings:
ビット0と1は、その値が以下の意味を有するキー「タイプ」ビットです。
10: Use of the key is prohibited for authentication.
01: Use of the key is prohibited for confidentiality.
00: Use of the key for authentication and/or confidentiality
is permitted. Note that DNS security makes use of keys
for authentication only. Confidentiality use flagging is
provided for use of keys in other protocols.
Implementations not intended to support key distribution
for confidentiality MAY require that the confidentiality
use prohibited bit be on for keys they serve.
11: If both bits are one, the "no key" value, there is no key
information and the RR stops after the algorithm octet.
By the use of this "no key" value, a signed KEY RR can
authenticatably assert that, for example, a zone is not
secured. See section 3.4 below.
Bits 2 is reserved and must be zero.
ビット2が予約され、ゼロでなければなりません。
Bits 3 is reserved as a flag extension bit. If it is a one, a second 16 bit flag field is added after the algorithm octet and before the key data. This bit MUST NOT be set unless one or more such additional bits have been defined and are non-zero.
ビット3は、フラグ拡張ビットとして予約されています。それが一つである場合、第16ビットフラグフィールドは、アルゴリズムオクテットの後に鍵データの前に付加されます。 1つまたは複数のそのような追加のビットが定義され、非ゼロであるれていない限り、このビットが設定されてはいけません。
Bits 4-5 are reserved and must be zero.
ビット4-5は予約され、ゼロでなければなりません。
Bits 6 and 7 form a field that encodes the name type. Field values have the following meanings:
ビット6と7は、名前型をコードフィールドを形成します。フィールド値は以下の意味があります。
00: indicates that this is a key associated with a "user" or
"account" at an end entity, usually a host. The coding
of the owner name is that used for the responsible
individual mailbox in the SOA and RP RRs: The owner name
is the user name as the name of a node under the entity
name. For example, "j_random_user" on
host.subdomain.example could have a public key associated
through a KEY RR with name
j_random_user.host.subdomain.example. It could be used
in a security protocol where authentication of a user was
desired. This key might be useful in IP or other
security for a user level service such a telnet, ftp,
rlogin, etc.
01: indicates that this is a zone key for the zone whose name
is the KEY RR owner name. This is the public key used
for the primary DNS security feature of data origin
authentication. Zone KEY RRs occur only at delegation
points.
10: indicates that this is a key associated with the non-zone
"entity" whose name is the RR owner name. This will
commonly be a host but could, in some parts of the DNS tree, be some other type of entity such as a telephone
number [RFC 1530] or numeric IP address. This is the
public key used in connection with DNS request and
transaction authentication services. It could also be
used in an IP-security protocol where authentication at
the host, rather than user, level was desired, such as
routing, NTP, etc.
11: reserved.
Bits 8-11 are reserved and must be zero.
ビット8-11は予約され、ゼロでなければなりません。
Bits 12-15 are the "signatory" field. If non-zero, they indicate that the key can validly sign things as specified in DNS dynamic update [RFC 2137]. Note that zone keys (see bits 6 and 7 above) always have authority to sign any RRs in the zone regardless of the value of the signatory field.
ビット12-15は「調印」フィールドです。ゼロ以外の場合、彼らはDNS動的更新[RFC 2137]で指定されたキーが有効に物事を署名することができることを示しています。そのゾーンキー（ビット上記6及び7を参照）にかかわらず常に署名フィールドの値のゾーン内の任意のRRを署名する権限を持っているに注意してください。
It is anticipated that keys stored in DNS will be used in conjunction with a variety of Internet protocols. It is intended that the protocol octet and possibly some of the currently unused (must be zero) bits in the KEY RR flags as specified in the future will be used to indicate a key's validity for different protocols.
DNSに格納された鍵は、インターネットのさまざまなプロトコルと組み合わせて使用されることが予想されます。プロトコルオクテットおよびおそらく現在未使用のいくつかの将来に指定されているKEY RRフラグのビット（ゼロでなければならないが）異なるプロトコルのためのキーの有効性を示すために使用されることが意図されます。
The following values of the Protocol Octet are reserved as indicated:
示されるように、プロトコルオクテットの次の値が予約されています。
VALUE Protocol
VALUEプロトコル
0 -reserved 1 TLS 2 email 3 dnssec 4 IPSEC 5-254 - available for assignment by IANA 255 All
0 -reserved 1 TLS 2電子メール3 DNSSEC 4 IPSEC 5から254 - IANA 255すべてによって割り当てのために利用可能
In more detail: 1 is reserved for use in connection with TLS. 2 is reserved for use in connection with email. 3 is used for DNS security. The protocol field SHOULD be set to this value for zone keys and other keys used in DNS security. Implementations that can determine that a key is a DNS security key by the fact that flags label it a zone key or the signatory flag field is non-zero are NOT REQUIRED to check the protocol field. 4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol and indicates that this key is valid for use in conjunction with that security standard. This key could be used in connection with secured communication on behalf of an end entity or user whose name is the owner name of the KEY RR if the entity or user flag bits are set. The presence of a KEY resource with this protocol value is an assertion that the host speaks Oakley/IPSEC. 255 indicates that the key can be used in connection with any protocol for which KEY RR protocol octet values have been defined. The use of this value is discouraged and the use of different keys for different protocols is encouraged.
より詳細には：1は、TLSに関連して使用するために予約されています。 2は、電子メールに関連して使用するために予約されています。 3は、DNSのセキュリティのために使用されています。プロトコルフィールドは、DNSセキュリティで使用されるゾーンのキーと他のキーについては、この値に設定する必要があります。キーはフラグがそれをゾーン鍵や調印フラグフィールドにラベルを付けているという事実によるDNSのセキュリティキーが非ゼロであることを判断することができます実装は、プロトコルフィールドをチェックする必要はありません。 4はオークリー/ IPSEC [RFC 2401]プロトコルを指すために予約され、このキーがそのセキュリティ規格と共に使用するため有効であることを示しています。このキーは、名前エンティティまたはユーザフラグビットが設定されている場合KEY RRの所有者名であるエンドエンティティまたはユーザの代わりに保護された通信に関連して使用することができます。このプロトコル値を持つキーリソースの存在は、ホストがオークリー/ IPSECを話しアサーションです。 255は鍵がKEY RRプロトコルオクテット値が定義されているため、任意のプロトコルに関連して使用することができることを示しています。この値の使用が推奨され、異なるプロトコルごとに異なる鍵を使用することが奨励されています。
This octet is the key algorithm parallel to the same field for the SIG resource as described in Section 4.1. The following values are assigned:
セクション4.1で説明したように、このオクテットは、SIGリソースの同じフィールドに鍵アルゴリズムと平行です。次の値が割り当てられています。
VALUE Algorithm
VALUEアルゴリズム
0 - reserved, see Section 11 1 RSA/MD5 [RFC 2537] - recommended 2 Diffie-Hellman [RFC 2539] - optional, key only 3 DSA [RFC 2536] - MANDATORY 4 reserved for elliptic curve crypto 5-251 - available, see Section 11 252 reserved for indirect keys 253 private - domain name (see below) 254 private - OID (see below) 255 - reserved, see Section 11
0 - 予約済みセクション11 1 RSA / MD5 [RFC 2537]を参照してください - キーのみ3 DSA [RFC 2536]は、オプション - - 必須4は、5から251暗号、楕円曲線のために予約 - 利用可能な、2ディフィー・ヘルマン[RFC 2539]を推奨ドメイン名（下記参照）254プライベート - - OID（下記参照）255 - 予約済み、セクション11を参照してください間接的なキーのために確保章11 252 253プライベートを見ます
Algorithm specific formats and procedures are given in separate documents. The mandatory to implement for interoperability algorithm is number 3, DSA. It is recommended that the RSA/MD5 algorithm, number 1, also be implemented. Algorithm 2 is used to indicate Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
アルゴリズム固有の形式と手順は、別の文書に記載されています。相互運用性のアルゴリズムのために実装するために義務的には、DSAナンバー3です。 RSA / MD5アルゴリズム、番号1は、また、実施することが推奨されます。アルゴリズム2のDiffie-Hellmanキーを示すために使用されるアルゴリズム4は、楕円曲線のために予約されています。
Algorithm number 252 indicates an indirect key format where the actual key material is elsewhere. This format is to be defined in a separate document.
アルゴリズム番号252は、実際の鍵材料は他の場所で間接キーフォーマットを示しています。この形式は、別の文書で定義されるべきです。
Algorithm numbers 253 and 254 are reserved for private use and will never be assigned a specific algorithm. For number 253, the public key area and the signature begin with a wire encoded domain name. Only local domain name compression is permitted. The domain name indicates the private algorithm to use and the remainder of the public key area is whatever is required by that algorithm. For number 254, the public key area for the KEY RR and the signature begin with an unsigned length byte followed by a BER encoded Object
アルゴリズム番号253および254は、私的使用のために予約されており、特定のアルゴリズムを割り当てることはありません。番号253は、公開鍵領域と署名は、ワイヤ符号化されたドメイン名で始まります。唯一のローカルドメイン名の圧縮が許可されています。ドメイン名は使用するプライベートのアルゴリズムを示し、公開鍵エリアの残りの部分は、そのアルゴリズムによって必要とされているものです。番号254は、KEYのRR及び署名の公開鍵領域がBER符号化されたオブジェクトに続く符号なしの長さバイトで始まります
Identifier (ISO OID) of that length. The OID indicates the private algorithm in use and the remainder of the area is whatever is required by that algorithm. Entities should only use domain names and OIDs they control to designate their private algorithms.
その長さの識別子（ISO OID）。 OIDは、使用中のプライベートなアルゴリズムを示し、地域の残りの部分はそのアルゴリズムによって必要とされているものです。エンティティは、ドメイン名のみ、彼らは自分のプライベートのアルゴリズムを指定するコントロールのOIDを使用する必要があります。
Values 0 and 255 are reserved but the value 0 is used in the algorithm field when that field is not used. An example is in a KEY RR with the top two flag bits on, the "no-key" value, where no key is present.
値が0と255は予約されていますが、そのフィールドが使用されていないとき値0は、アルゴリズムの分野で使用されています。例には、キーが存在しない「非キー」の値、に上位2つのフラグビットを有するキーのRRです。
Various combinations of the no-key type flags, algorithm byte, protocol byte, and any future assigned protocol indicating flags are possible. The meaning of these combinations is indicated below:
フラグを示す無キータイプフラグ、アルゴリズムバイト、プロトコル・バイト、及び将来割り当てプロトコルの様々な組み合わせが可能です。これらの組み合わせの意味は以下のとおりであります：
NK = no key type (flags bits 0 and 1 on) AL = algorithm byte PR = protocols indicated by protocol byte or future assigned flags
NKには、キータイプ（フラグビット0及び1上の）AL =アルゴリズムバイトPR =プロトコルバイトまたは将来割り当てられたフラグによって示されるプロトコルを=ありません
x represents any valid non-zero value(s).
Xは、任意の有効な非ゼロ値（S）を表します。
AL PR NK Meaning 0 0 0 Illegal, claims key but has bad algorithm field. 0 0 1 Specifies total lack of security for owner zone. 0 x 0 Illegal, claims key but has bad algorithm field. 0 x 1 Specified protocols unsecured, others may be secure. x 0 0 Gives key but no protocols to use it. x 0 1 Denies key for specific algorithm. x x 0 Specifies key for protocols. x x 1 Algorithm not understood for protocol.
0 0 0不正な意味AL PR NKは、キー主張悪いアルゴリズムフィールドがあります。 0 0 1オーナーゾーンのセキュリティの完全な欠如を指定します。 X 0 0違法、キー主張悪いアルゴリズムフィールドがあります。 X 1 0指定されたプロトコルセキュリティで保護されていない、他の人が安全であることができます。 X 0 0は、鍵与えますが、何のプロトコルは、それを使用しないように。 X 0 1は、特定のアルゴリズムのキーを拒否します。プロトコルのためのX X 0を指定するキー。 X X 1アルゴリズムは、プロトコルに理解されていません。
A zone KEY RR with the "no-key" type field value (both key type flag bits 0 and 1 on) indicates that the zone named is unsecured while a zone KEY RR with a key present indicates that the zone named is secure. The secured versus unsecured status of a zone may vary with different cryptographic algorithms. Even for the same algorithm, conflicting zone KEY RRs may be present.
「非キー」タイプフィールドの値（キータイプフラグビット0と1の両方で）を有するゾーンKEY RRはキー本付きゾーンKEY RRは名前付きゾーンが安全であることを示しているという名前のゾーンが無担保であることを示しています。異なる暗号アルゴリズムを用いて変えることができるゾーンのセキュリティで保護されていない状態に対して固定されます。同じアルゴリズムに、競合ゾーンKEY RRは存在していてもよいです。
Zone KEY RRs, like all RRs, are only trusted if they are authenticated by a SIG RR whose signer field is a signer for which the resolver has a public key they trust and where resolver policy permits that signer to sign for the KEY owner name. Untrusted zone KEY RRs MUST be ignored in determining the security status of the zone. However, there can be multiple sets of trusted zone KEY RRs for a zone with different algorithms, signers, etc.
彼らはその署名者フィールドリゾルバは、彼らが信頼公開鍵を持っているとリゾルバポリシーが鍵の所有者の名前を署名する署名者を許すところ署名者であるSIG RRによって認証された場合、ゾーンKEY RRは、すべてのRRと同様に、唯一信頼されています。信頼されないゾーンKEY RRは、ゾーンのセキュリティ状態を決定する際に無視しなければなりません。しかし、等の異なるアルゴリズム、署名者とゾーンの信頼ゾーン鍵資源レコードの複数のセットが存在することができます
For any particular algorithm, zones can be (1) secure, indicating that any retrieved RR must be authenticated by a SIG RR or it will be discarded as bogus, (2) unsecured, indicating that SIG RRs are not expected or required for RRs retrieved from the zone, or (3) experimentally secure, which indicates that SIG RRs might or might not be present but must be checked if found. The status of a zone is determined as follows:
任意の特定のアルゴリズムのために、ゾーンは、任意の検索RRはSIGのRRによって認証されなければならないか、それが偽として廃棄され、（2）保護されていない、SIG資源レコードが検索のRRに対して期待または必要とされないことを示すことを示し、（1）安全であることができますSIGのRRは、または存在しないかもしれないかもしれないが、見つかった場合はチェックしなければならないことを示しているゾーン、または（3）実験的に安全な、から。次のようにゾーンの状態が決定されます。
1. If, for a zone and algorithm, every trusted zone KEY RR for the zone says there is no key for that zone, it is unsecured for that algorithm.
ゾーンとアルゴリズムのために、ゾーンごとに、信頼ゾーンKEY RRはそのゾーンのためのキーが存在しないと言い、場合1、それはそのアルゴリズムのための無担保です。
2. If, there is at least one trusted no-key zone KEY RR and one trusted key specifying zone KEY RR, then that zone is only experimentally secure for the algorithm. Both authenticated and non-authenticated RRs for it should be accepted by the resolver.
2.場合は、少なくとも一つが、何のキーゾーンのKEYのRRと1つの信頼できるキー指定ゾーンKEY RRを信頼されていないが存在し、そのゾーンにのみ実験的アルゴリズムのために確保されます。それのための認証および非認証RRは、リゾルバで受け入れられるべきです。
3. If every trusted zone KEY RR that the zone and algorithm has is key specifying, then it is secure for that algorithm and only authenticated RRs from it will be accepted.
3.ゾーンとアルゴリズムが持つすべての信頼されたゾーンKEY RRは、キー指定であれば、それはそのアルゴリズムのために安全であり、それからだけで認証されたRRは受け入れられます。
Examples:
例：
(1) A resolver initially trusts only signatures by the superzone of zone Z within the DNS hierarchy. Thus it will look only at the KEY RRs that are signed by the superzone. If it finds only no-key KEY RRs, it will assume the zone is not secure. If it finds only key specifying KEY RRs, it will assume the zone is secure and reject any unsigned responses. If it finds both, it will assume the zone is experimentally secure
（1）リゾルバは、最初にDNS階層内のゾーンZの上位ゾーンによってのみ署名を信頼します。したがって、それだけで上位ゾーンによって署名されているKEY RRを見ていきます。それが唯一の無キーKEY RRを見つけた場合、それはゾーンが安全ではないと仮定します。それがKEY RRを指定するだけで鍵を見つけた場合は、ゾーンが安全であると仮定し、任意の符号なしの応答を拒否します。それは両方が見つかった場合は、ゾーンが実験的に安全であると仮定します
(2) A resolver trusts the superzone of zone Z (to which it got securely from its local zone) and a third party, cert-auth.example. When considering data from zone Z, it may be signed by the superzone of Z, by cert-auth.example, by both, or by neither. The following table indicates whether zone Z will be considered secure, experimentally secure, or unsecured, depending on the signed zone KEY RRs for Z;
（2）リゾルバは、（それが確実にそのローカルゾーンから得た）ゾーンZと第三者、CERT-auth.exampleの上位ゾーンを信頼します。ゾーンZからのデータを考慮すると、それはCERT-auth.exampleにより、両方によって、またはどちらによって、Zの上位ゾーンによって署名されてもよいです。次の表は、ゾーンZは、Z用の署名されたゾーン鍵資源レコードに依存し、実験的に安全な、または保護されていない、セキュア考えるかどうかを示します。
c e r t - a u t h . e x a m p l e
C E R T - A UのT H。 m個のP LがE X E
KEY RRs| None | NoKeys | Mixed | Keys |
S --+-----------+-----------+----------+----------+
u None | illegal | unsecured | experim. | secure |
p --+-----------+-----------+----------+----------+
e NoKeys | unsecured | unsecured | experim. | secure |
r --+-----------+-----------+----------+----------+
Z Mixed | experim. | experim. | experim. | secure | o --+-----------+-----------+----------+----------+
n Keys | secure | secure | secure | secure |
e +-----------+-----------+----------+----------+
An explicit request for KEY RRs does not cause any special additional information processing except, of course, for the corresponding SIG RR from a security aware server (see Section 4.2).
KEY RRのための明示的な要求はもちろん、セキュリティ意識のサーバから対応するSIG RR（4.2節を参照）を除いて、特別な追加情報の処理は発生しません。
Security aware DNS servers include KEY RRs as additional information in responses, where a KEY is available, in the following cases:
セキュリティ意識のDNSサーバは、KEYは、次の場合に、利用可能である回答では、追加情報としてKEY RRを、次のとおりです。
(1) On the retrieval of SOA or NS RRs, the KEY RRset with the same name (perhaps just a zone key) SHOULD be included as additional information if space is available. If not all additional information will fit, type A and AAAA glue RRs have higher priority than KEY RR(s).
スペースが利用可能である場合（1）SOAまたはNS RRの検索で、同じ名前（おそらくだけゾーンキー）とKEY RRセットは、付加情報として含まれるべきです。いないすべての追加情報が収まる場合は、タイプAとAAAAグルーRRはKEY RR（S）よりも高い優先度を持っています。
(2) On retrieval of type A or AAAA RRs, the KEY RRset with the same name (usually just a host RR and NOT the zone key (which usually would have a different name)) SHOULD be included if space is available. On inclusion of A or AAAA RRs as additional information, the KEY RRset with the same name should also be included but with lower priority than the A or AAAA RRs.
スペースが利用可能な場合（2）タイプAまたはAAAA RRの検索で、同じ名前（通常はホストRR及びNOT通常、異なる名前を持つであろうゾーンキー（））とKEY RRセットは含まれるべきです。付加情報としてAまたはAAAA RRの包含に、同じ名前を持つKEY RRセットも含まれるが、AまたはAAAAのRRよりも低い優先度を有するべきです。
The SIG or "signature" resource record (RR) is the fundamental way that data is authenticated in the secure Domain Name System (DNS). As such it is the heart of the security provided.
SIGまたは「署名」リソースレコード（RR）は、データをセキュアなドメインネームシステム（DNS）で認証されていることを基本的な方法です。そのためには、提供されるセキュリティの心臓部です。
The SIG RR unforgably authenticates an RRset [RFC 2181] of a particular type, class, and name and binds it to a time interval and the signer's domain name. This is done using cryptographic techniques and the signer's private key. The signer is frequently the owner of the zone from which the RR originated.
SIG RRはunforgably RRセット特定の種類の[RFC 2181]、クラス、および名前を認証し、時間間隔と署名者のドメイン名にバインドします。これは、暗号技術と署名者の秘密鍵を使用して行われます。署名者は頻繁にRRが発信されたゾーンの所有者です。
The type number for the SIG RR type is 24.
SIG RRタイプの種類数は24です。
The RDATA portion of a SIG RR is as shown below. The integrity of the RDATA information is protected by the signature field.
SIG RRのRDATA部分は、以下のように示されています。 RDATA情報の整合性が署名フィールドによって保護されています。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type covered | algorithm | labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name +
| /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/ /
/ signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "type covered" is the type of the other RRs covered by this SIG.
「タイプカバーは、」このSIGによってカバーされ、他のRRのタイプです。
This octet is as described in section 3.2.
セクション3.2で説明したように、このオクテットです。
The "labels" octet is an unsigned count of how many labels there are in the original SIG RR owner name not counting the null label for root and not counting any initial "*" for a wildcard. If a secured retrieval is the result of wild card substitution, it is necessary for the resolver to use the original form of the name in verifying the digital signature. This field makes it easy to determine the original form.
「ラベル」のオクテットがあり、元のSIG RRの所有者名にrootのヌルラベルを数えていないし、ワイルドカードは、「*」は任意の初期を数えていませんどのように多くのラベルの符号なし数です。セキュアな検索がワイルドカード置換の結果である場合にはレゾルバがデジタル署名の検証に名前の元の形式を使用することが必要です。このフィールドは、元の形を決定することが容易になります。
If, on retrieval, the RR appears to have a longer name than indicated by "labels", the resolver can tell it is the result of wildcard substitution. If the RR owner name appears to be shorter than the labels count, the SIG RR must be considered corrupt and ignored. The maximum number of labels allowed in the current DNS is 127 but the entire octet is reserved and would be required should DNS names ever be expanded to 255 labels. The following table gives some examples. The value of "labels" is at the top, the retrieved owner name on the left, and the table entry is the name to use in signature verification except that "bad" means the RR is corrupt.
、検索に、RRは「ラベル」で示されているよりも長い名前を持っているように見える場合、リゾルバはそれがワイルドカード置換の結果である伝えることができます。 RRの所有者名はラベルが数えるよりも短くなるように表示された場合は、SIG RRが破損しているとみなされ、無視されなければなりません。現在のDNSで許可されたラベルの最大数は127ですが、全体のオクテットが予約されており、DNS名は、これまで255枚のラベルに拡大すべき必要とされるであろう。次の表は、いくつかの例を示します。 「ラベル」の値が一番上にある、左側の検索所有者名、およびテーブルエントリが「不良」とRRが破損であることを意味することを除いて、署名検証に使用する名前です。
labels= | 0 | 1 | 2 | 3 | 4 |
--------+-----+------+--------+----------+----------+
.| . | bad | bad | bad | bad |
d.| *. | d. | bad | bad | bad |
c.d.| *. | *.d. | c.d. | bad | bad |
b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad |
a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
The "original TTL" field is included in the RDATA portion to avoid (1) authentication problems that caching servers would otherwise cause by decrementing the real TTL field and (2) security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field. This original TTL is protected by the signature while the current TTL field is not.
「オリジナルのTTL」フィールドには、キャッシュサーバがそうでなければ、実際のTTLフィールドをデクリメントとによって、原因となる（1）認証の問題を回避するために、RDATA部分に含まれている（2）悪徳サーバはそれ以外の場合は実際のTTLフィールドを操作することで発生する可能性があり、セキュリティ上の問題。現在のTTLフィールドがないが、この元のTTLは署名によって保護されています。
NOTE: The "original TTL" must be restored into the covered RRs when the signature is verified (see Section 8). This generaly implies that all RRs for a particular type, name, and class, that is, all the RRs in any particular RRset, must have the same TTL to start with.
注：署名が検証される場合、「元のTTL」は、（セクション8を参照）被覆のRRに復元されなければなりません。このgeneralyは、特定のタイプ、名前、およびクラスのすべてのRRことを意味し、つまり、特定のRRセット内のすべてのRRは、で開始する同じTTLを持っている必要があります。
The SIG is valid from the "signature inception" time until the "signature expiration" time. Both are unsigned numbers of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. (See also Section 4.4.) Ring arithmetic is used as for DNS SOA serial numbers [RFC 1982] which means that these times can never be more than about 68 years in the past or the future. This means that these times are ambiguous modulo ~136.09 years. However there is no security flaw because keys are required to be changed to new random keys by [RFC 2541] at least every five years. This means that the probability that the same key is in use N*136.09 years later should be the same as the probability that a random guess will work.
SIGは、「署名開始」時間から「署名の有効期限」まで有効です。どちらも、うるう秒を無視して、1970年1月1日、GMTの開始からの経過秒の符号なしの数値です。 （また、セクション4.4を参照してください。）リング演算は、これらの時間は、過去や未来で約68年以上になることはないことを意味DNS SOAシリアル番号[RFC 1982]のために使用されます。これは、これらの時間があいまい剰余〜136.09年であることを意味します。キーは[RFC 2541]少なくとも五年ごとにより新しいランダムキーに変更する必要があるためしかし、何のセキュリティ上の欠陥がありません。これは、確率は同じキーが使用されているN * 136.09年後にランダムな推測がうまくいく確率と同じでなければならないことを意味します。
A SIG RR may have an expiration time numerically less than the inception time if the expiration time is near the 32 bit wrap around point and/or the signature is long lived.
有効期限は、ポイント約32ビットラップ近くにあり、および/または署名が長寿命されている場合SIG RRは開始時間よりも数値的により少ない有効期限を有していてもよいです。
(To prevent misordering of network requests to update a zone dynamically, monotonically increasing "signature inception" times may be necessary.)
（動的ゾーンを更新するために、ネットワーク要求の誤った順序を防止するために、単調に「署名開始」時間を増加させることが必要であってもよいです。）
A secure zone must be considered changed for SOA serial number purposes not only when its data is updated but also when new SIG RRs are inserted (ie, the zone or any part of it is re-signed).
安全なゾーンは、そのデータが更新されたときだけでなく、SOAシリアル番号の目的のために変更だけでなく、ときに新しいSIG RRを考慮しなければなりません（つまり、ゾーンまたはその一部が再署名されている）が挿入されています。
The "key Tag" is a two octet quantity that is used to efficiently select between multiple keys which may be applicable and thus check that a public key about to be used for the computationally expensive effort to check the signature is possibly valid. For algorithm 1 (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the least significant 24 bits of the modulus in network (big endian) order. For all other algorithms, including private algorithms, it is calculated as a simple checksum of the KEY RR as described in Appendix C.
「キータグは、」効率的に適用できるため、署名を確認するための計算コストの努力のために使用されようとしている公開鍵はおそらく有効であることを確認することができ、複数のキーの間で選択するために使用される2つのオクテットの量です。 [RFC 2537]で定義されるようなアルゴリズム1（MD5 / RSA）のためには、署名フィールドをデコードするために必要な公開鍵係数の底2つのオクテットの隣にあります。すなわち、ネットワークにおけるモジュラスの最下位24ビット（ビッグエンディアン）オーダーの最も重要な16です。付録Cに記載されているように、プライベートアルゴリズムを含む全ての他のアルゴリズムについては、それがKEY RRの単純なチェックサムとして計算されます
The "signer's name" field is the domain name of the signer generating the SIG RR. This is the owner name of the public KEY RR that can be used to verify the signature. It is frequently the zone which contained the RRset being authenticated. Which signers should be authorized to sign what is a significant resolver policy question as discussed in Section 6. The signer's name may be compressed with standard DNS name compression when being transmitted over the network.
「署名者の名前」フィールドには、SIG RRを生成する署名者のドメイン名です。これは、署名を検証するために使用することができる公開鍵RRの所有者名です。それは頻繁にRRセットが認証されて含まれているゾーンです。どの署名者は、第6節で説明したように重要なリゾルバポリシーの質問が何であるかに署名する権限をしなければならない署名者の名前がネットワークを介して送信されている標準のDNS名圧縮で圧縮されてもよいです。
The actual signature portion of the SIG RR binds the other RDATA fields to the RRset of the "type covered" RRs with that owner name and class. This covered RRset is thereby authenticated. To accomplish this, a data sequence is constructed as follows:
SIG RRの実際の署名部分は、その所有者名とクラスと「タイプ被覆」RRのRRセットに他のRDATAフィールドを結合します。この覆われたRRセットは、それによって認証されます。次のようにこれを実現するために、データシーケンスが構築されます。
data = RDATA | RR(s)...
データ= RDATA | RR（S）...
where "|" is concatenation,
ここで、「|」連結は、あります
RDATA is the wire format of all the RDATA fields in the SIG RR itself (including the canonical form of the signer's name) before but not including the signature, and
RDATA前（署名者の名前の正規形を含む）SIGのRR自体内のすべてのRDATAフィールドのワイヤフォーマットであるが、署名を含まない、及び
RR(s) is the RRset of the RR(s) of the type covered with the same owner name and class as the SIG RR in canonical form and order as defined in Section 8.
セクション8で定義されるようにRR（S）が標準形式と順にSIG RRと同じ所有者名およびクラスで覆われたタイプのRR（S）のRRセットです。
How this data sequence is processed into the signature is algorithm dependent. These algorithm dependent formats and procedures are described in separate documents (Section 3.2).
このデータ列は、署名に加工されたどのようなアルゴリズムに依存しています。これらのアルゴリズムに依存する形式と手順は、別の文書（3.2節）に記載されています。
SIGs SHOULD NOT be included in a zone for any "meta-type" such as ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR).
SIGは（しかしIXFRに関してはセクション5.6.2を参照）、このようないずれかのような、任意の「メタ型」、AXFRなどのゾーンに含めるべきではありません。
A response message from a security aware server may optionally contain a special SIG at the end of the additional information section to authenticate the transaction.
セキュリティ意識のサーバからの応答メッセージは、必要に応じてトランザクションを認証するために、追加情報セクションの終わりに特別なSIGが含まれていてもよいです。
This SIG has a "type covered" field of zero, which is not a valid RR type. It is calculated by using a "data" (see Section 4.1.8) of the entire preceding DNS reply message, including DNS header but not the IP header and before the reply RR counts have been adjusted for the inclusion of any transaction SIG, concatenated with the entire DNS query message that produced this response, including the query's DNS header and any request SIGs but not its IP header. That is
このSIGは、有効なRRタイプではありませんゼロの「タイプカバー」フィールドを、持っています。それは「データ」を用いて算出されるDNSヘッダはなく、IPヘッダと応答RR数は、任意のトランザクションSIGの包含のために調整されている前に、連結を含む全体の先行DNS応答メッセージの、（セクション4.1.8を参照）クエリのDNSヘッダと任意の要求のSIGではなく、そのIPヘッダを含め、この応答を生成全体のDNSクエリメッセージを持ちます。あれは
data = full response (less transaction SIG) | full query
データ=フル応答（以下トランザクションSIG）|完全なクエリ
Verification of the transaction SIG (which is signed by the server host key, not the zone key) by the requesting resolver shows that the query and response were not tampered with in transit, that the response corresponds to the intended query, and that the response comes from the queried server.
要求リゾルバによって（サーバホストキーではなく、ゾーン鍵によって署名された）トランザクションSIGの検証は、応答が意図されたクエリに対応すること、クエリ及び応答が転送中に改ざんされなかったことを示し、そしてその応答照会サーバーから来ています。
A DNS request may be optionally signed by including one or more SIGs at the end of the query. Such SIGs are identified by having a "type covered" field of zero. They sign the preceding DNS request message including DNS header but not including the IP header or any request SIGs at the end and before the request RR counts have been adjusted for the inclusions of any request SIG(s).
DNS要求は、必要に応じて、クエリの最後に1つの以上のSIGを含むによって署名されてもよいです。このようなのSIGはゼロの「タイプカバー」フィールドを持つことによって識別されます。彼らは、DNSヘッダを含む、先行するDNS要求メッセージに署名するが、最後にIPヘッダまたは任意の要求のSIGを含むリクエストRRカウントする前に要求SIG（単数または複数）の介在のために調整されていません。
WARNING: Request SIGs are unnecessary for any currently defined request other than update [RFC 2136, 2137] and will cause some old DNS servers to give an error return or ignore a query. However, such SIGs may in the future be needed for other requests.
WARNING：リクエストのSIGが更新[RFC 2136、2137]以外のすべての現在定義されている要求のために不必要であり、いくつかの古いDNSサーバがエラーリターンを与えるか、またはクエリを無視するようになります。しかし、そのようなのSIGは、将来的に他の要求のために必要とすることができます。
Except where needed to authenticate an update or similar privileged request, servers are not required to check request SIGs.
更新または同様の特権要求を認証するために必要な場合を除き、サーバはリクエストのSIGをチェックする必要はありません。
Security aware DNS servers SHOULD, for every authenticated RRset the query will return, attempt to send the available SIG RRs which authenticate the requested RRset. The following rules apply to the inclusion of SIG RRs in responses:
セキュリティ意識のDNSサーバは、すべての認証されたRRセットのクエリは、要求されたRRセットを認証可能なSIG RRを送信しようとする試みを返しますべきです。次の規則は、応答のSIG RRの算入に適用されます。
1. when an RRset is placed in a response, its SIG RR has a higher priority for inclusion than additional RRs that may need to be included. If space does not permit its inclusion, the response MUST be considered truncated except as provided in 2 below.
資源レコード集合が応答して置かれたとき1.、そのSIG RRが含まれる必要がある追加のRRよりも含めるために高い優先順位を有します。スペースはその含めることを許可していない場合は、応答は以下の2に提供されるもの以外切り捨て考えなければなりません。
2. When a SIG RR is present in the zone for an additional information section RR, the response MUST NOT be considered truncated merely because space does not permit the inclusion of the SIG RR with the additional information.
SIG RRは、付加情報部RRのゾーン内に存在する場合にスペースが追加情報をSIG RRを含めることを許可しないので2は、応答は、単に切り捨てと考えてはいけません。
3. SIGs to authenticate glue records and NS RRs for subzones at a delegation point are unnecessary and MUST NOT be sent.
委任ポイントでグルーレコードとサブゾーンのNS RRを認証するための3のSIGは不要であり、送ってはいけません。
4. If a SIG covers any RR that would be in the answer section of the response, its automatic inclusion MUST be in the answer section. If it covers an RR that would appear in the authority section, its automatic inclusion MUST be in the authority section. If it covers an RR that would appear in the additional information section it MUST appear in the additional information section. This is a change in the existing standard [RFCs 1034, 1035] which contemplates only NS and SOA RRs in the authority section.
4. SIGは、応答の回答セクションであろう任意のRRを覆う場合、その自動包含は応答区間でなければなりません。それは権威セクションに現れるRRをカバーする場合、その自動含めることは、権限のセクションでなければなりません。それは追加情報セクションに表示されるRRをカバーする場合には、追加情報セクションに表示される必要があります。これは、権限のセクションでのみNSとSOA RRを企図する既存の標準[RFCの1034、1035]の変化です。
5. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section (Section 4.1.8.1). Such SIG RRs are signed by the DNS server originating the response. Although the signer field MUST be a name of the originating server host, the owner name, class, TTL, and original TTL, are meaningless. The class and TTL fields SHOULD be zero. To conserve space, the owner name SHOULD be root (a single zero octet). If transaction authentication is desired, that SIG RR must be considered the highest priority for inclusion.
5.必要に応じて、DNSトランザクションは、追加情報セクション（セクション4.1.8.1）で反応の終了時にSIGのRRによって認証されてもよいです。このようなSIGのRRは、応答を元のDNSサーバによって署名されています。署名者フィールドは、元のサーバーのホスト名でなければなりませんが、所有者名、クラス、TTL、およびオリジナルのTTLは、無意味です。クラスとTTLフィールドがゼロであるべきです。スペースを節約するために、所有者名はルート（単一のゼロオクテット）であるべきです。トランザクション認証を希望する場合は、そのSIG RRは含めるための最高の優先順位を考慮しなければなりません。
The following rules apply to the processing of SIG RRs included in a response:
以下の規則は、SIG RRの処理に適用される応答に含まれます。
1. A security aware resolver that receives a response from a security aware server via a secure communication with the AD bit (see Section 6.1) set, MAY choose to accept the RRs as received without verifying the zone SIG RRs.
1. ADビットとのセキュアな通信を介してセキュリティ認識サーバからの応答を受信するセキュリティ対応リゾルバ（セクション6.1を参照）セット、ゾーンSIG RRを確認せずに受け取ったRRを受け入れるのを選ぶかもしれ。
2. In other cases, a security aware resolver SHOULD verify the SIG RRs for the RRs of interest. This may involve initiating additional queries for SIG or KEY RRs, especially in the case of getting a response from a server that does not implement security. (As explained in 2.3.5 above, it will not be possible to secure CNAMEs being served up by non-secure resolvers.)
2.他の例では、セキュリティ対応リゾルバは、関心のRRのためにSIG RRを確認する必要があります。これは、特にセキュリティを実装していないサーバーからの応答を取得する場合には、SIGまたはKEYのRRのための追加のクエリを開始することを含むことができます。 （上記2.3.5で説明したように、非安全レゾルバによってアップ提供されているのCNAMEを確保することはできません。）
NOTE: Implementers might expect the above SHOULD to be a MUST. However, local policy or the calling application may not require the security services.
注：実装者はSHOULD上記MUSTであることを期待するかもしれません。しかし、ローカルポリシーまたは呼び出し元のアプリケーションは、セキュリティ・サービスを必要としない場合があります。
3. If SIG RRs are received in response to a user query explicitly specifying the SIG type, no special processing is required.
SIG資源レコードが明示的SIGのタイプを指定するユーザクエリに応答して受信された3.場合、特別な処理は必要とされません。
If the message does not pass integrity checks or the SIG does not check against the signed RRs, the SIG RR is invalid and should be ignored. If all of the SIG RR(s) purporting to authenticate an RRset are invalid, then the RRset is not authenticated.
メッセージは整合性チェックに合格しないか、SIGが署名したRRに対してチェックされない場合は、SIG RRは無効であり、無視してください。 RRセットを認証するために主張するSIG RR（S）の全てが無効である場合には、RRセットが認証されていません。
If the SIG RR is the last RR in a response in the additional information section and has a type covered of zero, it is a transaction signature of the response and the query that produced the response. It MAY be optionally checked and the message rejected if the checks fail. But even if the checks succeed, such a transaction authentication SIG does NOT directly authenticate any RRs in the message. Only a proper SIG RR signed by the zone or a key tracing its authority to the zone or to static resolver configuration can directly authenticate RRs, depending on resolver policy (see Section 6). If a resolver does not implement transaction and/or request SIGs, it MUST ignore them without error.
SIG RRは、追加情報セクションの応答の最後のRRであり、ゼロの被覆型を有する場合、それは応答し、応答を生成したクエリのトランザクション署名です。チェックが失敗した場合には、必要に応じて確認することができ、メッセージは拒否します。しかし、チェックが成功しても、そのようなトランザクション認証SIGは、直接メッセージ内の任意のRRを認証しません。ゾーンまたは直接レゾルバポリシーに応じて、RRを認証することができるゾーンにまたは静的リゾルバ構成にその権限を追跡キーによって署名のみ適切SIGのRR（セクション6を参照）。リゾルバは、トランザクションおよび/または要求のSIGを実装していない場合は、エラーなしでそれらを無視しなければなりません。
If all checks indicate that the SIG RR is valid then RRs verified by it should be considered authenticated.
すべてのチェックがSIG RRが有効であることを示している場合、それによって検証RRは認証されたと考えるべきです。
Security aware servers MUST NOT consider SIG RRs to authenticate anything before their signature inception or after its expiration time (see also Section 6). Security aware servers MUST NOT consider any RR to be authenticated after all its signatures have expired. When a secure server caches authenticated data, if the TTL would expire at a time further in the future than the authentication expiration time, the server SHOULD trim the TTL in the cache entry not to extent beyond the authentication expiration time. Within these constraints, servers should continue to follow DNS TTL aging. Thus authoritative servers should continue to follow the zone refresh and expire parameters and a non-authoritative server should count down the TTL and discard RRs when the TTL is zero (even for a SIG that has not yet reached its authentication expiration time). In addition, when RRs are transmitted in a query response, the TTL should be trimmed so that current time plus the TTL does not extend beyond the authentication expiration time. Thus, in general, the TTL on a transmitted RR would be
セキュリティ対応サーバは、自分の署名開始前またはその有効期限の後に何を認証するSIG RRを検討してはならない（セクション6を参照してください）。セキュリティ対応サーバは、そのすべての署名が期限切れになった後に認証される任意のRRを検討してはなりません。 TTLは、さらに、認証の有効期限よりも、将来の時点で期限が切れるならば、セキュアサーバーのキャッシュは、データを認証した場合、サーバーはいない、認証の有効期限を越えた範囲にキャッシュエントリにTTLをトリミングすべきです。これらの制約の中で、サーバは、DNS TTLの老化に従うことを続けるべきです。したがって、権威サーバーは、ゾーンの更新を追跡し続けるとパラメータを期限切れと非権威サーバはTTLをカウントダウンし、TTLがゼロ（でもまだその認証の有効期限に達していないSIG用）のときのRRを破棄しなければならないはずです。加えて、資源レコードは、クエリ応答で送信される場合、TTLは、その結果、現在の時刻をトリミングすべきであるプラスTTLは、認証の有効期限を越えて延びません。したがって、一般的には、送信RR上のTTLがあろう
min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
分（authExpTim、最大（zoneMinTTL、分（originalTTL、currentTTL）））
When signatures are generated, signature expiration times should be set far enough in the future that it is quite certain that new signatures can be generated before the old ones expire. However, setting expiration too far into the future could mean a long time to flush any bad data or signatures that may have been generated.
署名が生成されると、署名の有効期限は、古い有効期限が切れる前に新しいシグネチャを生成することができる、非常に一定であることを将来的には十分に設定する必要があります。しかし、将来的にすぎ、有効期限を設定すると、生成された可能性のある不正なデータや署名をフラッシュするために長い時間を意味するかもしれません。
It is recommended that signature lifetime be a small multiple of the TTL (ie, 4 to 16 times the TTL) but not less than a reasonable maximum re-signing interval and not less than the zone expiry time.
署名寿命が小さいTTL（すなわち、4〜16倍TTL）の複数が、合理的な最大再署名間隔より小さくないとゾーン満了時間以上であることが推奨されます。
The SIG RR mechanism described in Section 4 above provides strong authentication of RRs that exist in a zone. But it is not clear above how to verifiably deny the existence of a name in a zone or a type for an existent name.
上記セクション4で説明SIG RR機構は、ゾーン内に存在するRRの強力な認証を提供します。しかし、それは検証可能ゾーンまたは既存の名のタイプに名前の存在を否定する方法上記明確ではありません。
The nonexistence of a name in a zone is indicated by the NXT ("next") RR for a name interval containing the nonexistent name. An NXT RR or RRs and its or their SIG(s) are returned in the authority section, along with the error, if the server is security aware. The same is true for a non-existent type under an existing name except that there is no error indication other than an empty answer section accompanying the NXT(s). This is a change in the existing standard [RFCs 1034/1035] which contemplates only NS and SOA RRs in the authority section. NXT RRs will also be returned if an explicit query is made for the NXT type.
ゾーン内の名前の非存在は、存在しない名前を含む名前間隔のNXT（「次」）RRによって示されています。 NXTのRRまたはRRは、そのまたはサーバーがセキュリティ認識している場合は、そのSIG（複数可）、エラーとともに、権限のセクションに返されます。同じことが、NXT（単数または複数）を伴う空の応答セクション以外のエラー表示がないことを除いて、既存の名前の下に存在しないタイプについても同様です。これは、権限のセクションでのみNSとSOA RRを企図する既存の標準[RFCの1035分の1034]の変化です。明示的なクエリがNXTタイプのために作られている場合NXT RRはまた、返されます。
The existence of a complete set of NXT records in a zone means that any query for any name and any type to a security aware server serving the zone will result in an reply containing at least one signed RR unless it is a query for delegation point NS or glue A or AAAA RRs.
ゾーンのNXTレコードの完全なセットの存在は、それが委任ポイントNSのクエリでない限り、ゾーンにサービスを提供するセキュリティ意識のサーバーに任意の名前と任意のタイプのための任意のクエリは、少なくとも一つの署名RRを含む応答をもたらすことを意味しまたは接着剤AまたはAAAA RRを。
The NXT resource record is used to securely indicate that RRs with an owner name in a certain name interval do not exist in a zone and to indicate what RR types are present for an existing name.
NXTリソースレコードは、特定の名前の間隔で所有者名の資源レコードがゾーン内に存在せず、既存の名前のために存在しているものRRタイプを示すようにすることを確実に示すために使用されます。
The owner name of the NXT RR is an existing name in the zone. It's RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone create a chain of all of the literal owner names in that zone, including unexpanded wildcards but omitting the owner name of glue address records unless they would otherwise be included. This implies a canonical ordering of all domain names in a zone as described in Section 8. The presence of the NXT RR means that no name between its owner name and the name in its RDATA area exists and that no other types exist under its owner name.
NXT RRの所有者名は、ゾーン内の既存の名前です。これは、RDATAは「次」の名前とタイプのビットマップであるです。したがって、ゾーンのNXTのRRは拡張されていないワイルドカードを含むが、それらがそうでない場合は含まれない限り、グルーアドレスレコードの所有者名を省略し、そのゾーン内のリテラル所有者名、のすべてのチェーンを作成します。セクション8に記載されているように、これはNXT RRの存在は、そのRDATA領域にその所有者の名前と名前の間に名前が存在しないことを意味し、他のタイプは、その所有者名の下に存在しないことをゾーン内のすべてのドメイン名の正規順序を暗示します。
There is a potential problem with the last NXT in a zone as it wants to have an owner name which is the last existing name in canonical order, which is easy, but it is not obvious what name to put in its RDATA to indicate the entire remainder of the name space. This is handled by treating the name space as circular and putting the zone name in the RDATA of the last NXT in a zone.
そこには簡単である、標準的な順序に既存の最後の名前である所有者名を持って望んでいるとして、ゾーン内の最後のNXTとの潜在的な問題はあるが、全体を示すために、そのRDATAに置くためにどのような名前は明らかではありません名前空間の残りの部分。これは、円形として名前空間を処理すると、ゾーン内の最後のNXTのRDATAにゾーン名を置くことによって処理されます。
The NXT RRs for a zone SHOULD be automatically calculated and added to the zone when SIGs are added. The NXT RR's TTL SHOULD NOT exceed the zone minimum TTL.
ゾーンのNXT資源レコードは、自動的に計算さのSIGが追加されたゾーンに添加されるべきです。 NXT RRのTTLはゾーンの最小TTLを超えないようにしてください。
The type number for the NXT RR is 30.
NXT RRのタイプ番号は30です。
NXT RRs are only signed by zone level keys.
NXTのRRは唯一のゾーンレベルの鍵によって署名されています。
The RDATA for an NXT RR consists simply of a domain name followed by a bit map, as shown below.
以下に示すようにNXTのRRのためのRDATAは、単にビットマップに続くドメイン名からなります。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next domain name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type bit map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NXT RR type bit map format currently defined is one bit per RR type present for the owner name. A one bit indicates that at least one RR of that type is present for the owner name. A zero indicates that no such RR is present. All bits not specified because they are beyond the end of the bit map are assumed to be zero. Note that bit 30, for NXT, will always be on so the minimum bit map length is actually four octets. Trailing zero octets are prohibited in this format. The first bit represents RR type zero (an illegal type which can not be present) and so will be zero in this format. This format is not used if there exists an RR with a type number greater than
現在定義されているNXTのRRタイプビットマップ形式は、所有者名のRRタイプごとに1ビットが存在します。 1ビットは、そのタイプの少なくとも1つのRRが所有者名のために存在することを示しています。ゼロは、そのようなRRが存在しないことを示しています。それらは、ビットマップの終わりを超えているので、指定されていないすべてのビットがゼロであると仮定されます。最小ビットマップの長さは、実際には4つのオクテットであるので、30ビットノートは、NXTのために、常にオンになります。末尾のゼロオクテットはこの形式で禁止されています。最初のビットは、RRタイプゼロ（存在させることができない不正タイプ）を表すので、この形式でゼロとなります。より大きなタイプ番号のRRが存在する場合に、この形式が使用されていません
127. If the zero bit of the type bit map is a one, it indicates that a different format is being used which will always be the case if a type number greater than 127 is present.
タイプビットマップのゼロビットが1である場合127は、異なるフォーマットが127を超える種類の番号が存在する場合に常に当てはまるであろうが使用されていることを示します。
The domain name may be compressed with standard DNS name compression when being transmitted over the network. The size of the bit map can be inferred from the RDLENGTH and the length of the next domain name.
ネットワークを介して送信される場合、ドメイン名は、標準的なDNS名圧縮で圧縮されてもよいです。ビットマップのサイズはRDLENGTH、次のドメイン名の長さから推測することができます。
Proving that a non-existent name response is correct or that a wildcard expansion response is correct makes things a little more complex.
存在しない名前の応答が正しいことか、ワイルドカードの展開応答が正しいことを証明することは、物事はもう少し複雑になります。
In particular, when a non-existent name response is returned, an NXT must be returned showing that the exact name queried did not exist and, in general, one or more additional NXT's need to be returned to also prove that there wasn't a wildcard whose expansion should have been returned. (There is no need to return multiple copies of the same NXT.) These NXTs, if any, are returned in the authority section of the response.
具体的には、存在しない名前の応答が返されたときに、NXTが照会の正確な名前は、一般的に、存在していなかったことを示す返される必要があり、1つ以上の追加のNXTの必要もありませんでしたことを証明するために返されますその拡張ワイルドカードが返却されている必要があります。 （同じNXTの複数のコピーを返却する必要はありません。）これらのNXTsは、もしあれば、応答の権限セクションで返されます。
Furthermore, if a wildcard expansion is returned in a response, in general one or more NXTs needs to also be returned in the authority section to prove that no more specific name (including possibly more specific wildcards in the zone) existed on which the response should have been based.
ワイルドカードの展開は、一般的な1以上のNXTsで、応答で返された場合さらに、また（ゾーンの可能性がより具体的なワイルドカードを含む）は、より具体的な名前が存在しないことを証明するための権限セクションに返却する必要がある応答がすべきで基づくものでした。
Assume zone foo.nil has entries for
ゾーンfoo.nilはのエントリを持っていると仮定
big.foo.nil,
medium.foo.nil.
small.foo.nil.
tiny.foo.nil.
Then a query to a security aware server for huge.foo.nil would produce an error reply with an RCODE of NXDOMAIN and the authority section data including something like the following: foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2 19970102030405 ;signature expiration 19961211100908 ;signature inception 2143 ;key identifier foo.nil. ;signer AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits) ) big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 19970102030405 ;signature expiration 19961211100908 ;signature inception 2143 ;key identifier foo.nil. ;signer MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) ) Note that this response implies that big.foo.nil is an existing name in the zone and thus has other RR types associated with it than NXT. However, only the NXT (and its SIG) RR appear in the response to this query for huge.foo.nil, which is a non-existent name.
foo.nil：次にhuge.foo.nilのためのセキュリティ意識のサーバへのクエリがNXDOMAINのRCODEと、次のようなものを含む権限セクションデータでエラー応答を生成します。 NS KEY SOA NXT big.foo.nil NXT;ない* .foo.nil foo.nilを証明していません。 SIG NXT 1 2（;タイプCOV = NXT、ALG = 1、標識= 2 19970102030405;署名の有効期限19961211100908;署名開始2143;キー識別子foo.nil;署名AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx / fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm fiYy2X + 8XpFjwICHc398kzWsTMKlxovpz2FnCTM =、署名（640ビット） ）big.foo.nil。 NXT medium.foo.nil。 MX SIG NXT;ないhuge.foo.nilのbig.foo.nilを証明していません。 SIG NXT 1 3（;タイプ-COV = NXT、ALG = 1、標識= 3 19970102030405;署名の有効期限19961211100908;署名開始2143;キー識別子foo.nil;署名MxFcby9k / yvedMfQgKzhH5er0Mu / vILz45IkskceFGgiWCn / GxHhai6VAuHAoNUz4YoU 1tVfSCSqQYn6 // 11U6Nld80jEeC8aTrO + KKmCaY =、署名（640ビット））この応答はbig.foo.nilゾーン内の既存の名前であり、従ってNXTよりも、それに関連付けられた他のRRタイプを有することを意味することに留意されたいです。しかし、唯一のNXT（およびそのSIG）RRは、存在しない名前ですhuge.foo.nilため、このクエリに応答して表示されます。
A name (other than root) which is the head of a zone also appears as the leaf in a superzone. If both are secure, there will always be two different NXT RRs with the same name. They can be easily distinguished by their signers, the next domain name fields, the presence of the SOA type bit, etc. Security aware servers should return the correct NXT automatically when required to authenticate the non-existence of a name and both NXTs, if available, on explicit query for type NXT.
ゾーンの頭である（root以外の）名前は、上位ゾーンにおける葉として表示されます。両方が安全である場合は、必ず同じ名前を持つ2つの異なるNXT用のRRが存在します。名前の非存在との両方NXTsを認証するために必要なとき、彼らは簡単に自分の署名者、次のドメイン名フィールド、SOAタイプビットの存在によって区別できるなど、セキュリティ対応サーバは、以下の場合に、自動的に正しいNXTを返す必要がありますタイプNXTの明示的なクエリで、利用できます。
Non-security aware servers will never automatically return an NXT and some old implementations may only return the NXT from the subzone on explicit queries.
非セキュリティ意識のサーバーが自動的にNXTを返すことはありませんし、いくつかの古い実装が唯一の明示的なクエリのサブゾーンからNXTを返すことがあります。
The subsections below describe how full and incremental zone transfers are secured.
以下のサブセクションでは、フルと増分ゾーン転送が確保されている方法について説明します。
SIG RRs secure all authoritative RRs transferred for both full and incremental [RFC 1995] zone transfers. NXT RRs are an essential element in secure zone transfers and assure that every authoritative name and type will be present; however, if there are multiple SIGs with the same name and type covered, a subset of the SIGs could be sent as long as at least one is present and, in the case of unsigned delegation point NS or glue A or AAAA RRs a subset of these RRs or simply a modified set could be sent as long as at least one of each type is included.
SIG RRは完全と増分[RFC 1995]の両方に転送されるすべての権威のRRゾーン転送を確保します。 NXT RRは、セキュアゾーン転送に不可欠な要素であり、すべての権限の名前とタイプが存在することを保証します。被覆された同じ名前とタイプを持つ複数のSIGが存在する場合は、のSIGのサブセットは、少なくとも一方が存在すると、符号なし委任ポイントNS又はグルーAまたはAAAA RRの場合にサブセット限り送信することができますこれらのRRまたは単に修飾セットがあれば、各タイプの少なくとも1つが含まれるように送信することができます。
When an incremental or full zone transfer request is received with the same or newer version number than that of the server's copy of the zone, it is replied to with just the SOA RR of the server's current version and the SIG RRset verifying that SOA RR.
増分または完全ゾーン転送要求はゾーンのサーバのコピーに比べて同じか新しいバージョン番号で受信されると、それだけで、サーバーの現在のバージョンのSOA RRとSIG RRセットは、SOAのRRことを検証しに答えています。
The complete NXT chains specified in this document enable a resolver to obtain, by successive queries chaining through NXTs, all of the names in a zone even if zone transfers are prohibited. Different format NXTs may be specified in the future to avoid this.
この文書で指定された完全なNXTチェーンは、ゾーン転送が禁止されている場合でも、NXTsを通じてチェイニング連続クエリによって、ゾーン内の名前のすべてを取得するためにリゾルバを有効にします。異なるフォーマットNXTsはこれを避けるために、将来的に指定することができます。
To provide server authentication that a complete transfer has occurred, transaction authentication SHOULD be used on full zone transfers. This provides strong server based protection for the entire zone in transit.
完全転送が発生したサーバー認証を提供するには、トランザクションの認証は、完全なゾーン転送で使用する必要があります。これは、輸送中のゾーン全体のための強力なサーバーベースの保護を提供します。
Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be verified in the same way as for a full zone transfer and the integrity of the NXT name chain and correctness of the NXT type bits for the zone after the incremental RR deletes and adds can check each disjoint area of the zone updated. But the completeness of an incremental transfer can not be confirmed because usually neither the deleted RR section nor the added RR section has a compete zone NXT chain. As a result, a server which securely supports IXFR must handle IXFR SIG RRs for each incremental transfer set that it maintains.
増分RRが削除された後に増分（IXFR）転送[RFC 1995]で個々のRRゾーンのNXTタイプビットの完全ゾーン転送とNXT名チェーンの整合性および正当と同じ方法で確認することができると更新ゾーンのそれぞればらばらエリアを確認することができます追加します。通常、削除されたRRセクションも追加RR区間でもないが、競合ゾーンNXTチェーンを持っているので、しかし、増分転送の完全性を確認することができません。その結果、安全にIXFRをサポートするサーバーは、それが維持していることを設定し、各増分転送のためIXFR SIG RRを処理する必要があります。
The IXFR SIG is calculated over the incremental zone update collection of RRs in the order in which it is transmitted: old SOA, then deleted RRs, then new SOA and added RRs. Within each section, RRs must be ordered as specified in Section 8. If condensation of adjacent incremental update sets is done by the zone owner, the original IXFR SIG for each set included in the condensation must be discarded and a new on IXFR SIG calculated to cover the resulting condensed set.
IXFR SIGは、それが送信された順にRRの増分ゾーン更新コレクションに渡って計算される：古いSOA、その後、新しいSOAそして、RRを削除し、RRを追加しました。セクション8で指定されるように、隣接する増分更新セットの縮合は、縮合に含まれる各セットのゾーンの所有者は、元のIXFR SIGによって行われる場合、各セクション内、RRは注文する必要があり、算出IXFR SIGに廃棄され、新しいされなければなりませんその結果凝縮セットをカバーしています。
The IXFR SIG really belongs to the zone as a whole, not to the zone name. Although it SHOULD be correct for the zone name, the labels field of an IXFR SIG is otherwise meaningless. The IXFR SIG is only sent as part of an incremental zone transfer. After validation of the IXFR SIG, the transferred RRs MAY be considered valid without verification of the internal SIGs if such trust in the server conforms to local policy.
IXFR SIGは本当に全体としてではなく、ゾーン名のゾーンに属しています。それはゾーン名のために正しいはずですが、IXFR SIGのラベルフィールドは無意味です。 IXFR SIGだけ増分ゾーン転送の一部として送信されます。サーバーにそのような信頼がローカルポリシーに準拠している場合IXFR SIGの検証した後、転送RRは内部のSIGの検証なしに有効と考えることができます。
Retrieving or resolving secure data from the Domain Name System (DNS) involves starting with one or more trusted public keys that have been staticly configured at the resolver. With starting trusted keys, a resolver willing to perform cryptography can progress securely through the secure DNS structure to the zone of interest as described in Section 6.3. Such trusted public keys would normally be configured in a manner similar to that described in Section 6.2. However, as a practical matter, a security aware resolver would still gain some confidence in the results it returns even if it was not configured with any keys but trusted what it got from a local well known server as if it were staticly configured.
ドメインネームシステム（DNS）からのセキュアなデータを取得するか、解決することは静的にリゾルバで設定された1つのまたは複数の信頼できる公開鍵から始まる含まれます。セクション6.3で説明したように、信頼できるキーを起動して、暗号化を行うことをいとわリゾルバは、関心のあるゾーンへのセキュアDNS構造を介して確実に進行させることができます。そのような信頼された公開鍵は、通常、セクション6.2で説明したものと同様に構成されることになります。しかし、実際問題として、セキュリティ対応リゾルバはまだそれはそれはどのキーで構成されたが、それは静的に設定されているかのように、それは地元の有名サーバから得たもの、信頼されていなかった場合でも返した結果で、いくつかの自信を得るでしょう。
Data stored at a security aware server needs to be internally categorized as Authenticated, Pending, or Insecure. There is also a fourth transient state of Bad which indicates that all SIG checks have explicitly failed on the data. Such Bad data is not retained at a security aware server. Authenticated means that the data has a valid SIG under a KEY traceable via a chain of zero or more SIG and KEY RRs allowed by the resolvers policies to a KEY staticly configured at the resolver. Pending data has no authenticated SIGs and at least one additional SIG the resolver is still trying to authenticate. Insecure data is data which it is known can never be either Authenticated or found Bad in the zone where it was found because it is in or has been reached via a unsecured zone or because it is unsigned glue address or delegation point NS data. Behavior in terms of control of and flagging based on such data labels is described in Section 6.1.
セキュリティ意識のサーバーに格納されたデータは、内部認証、保留、または安全でないとして分類する必要があります。すべてのSIGのチェックが明示的にデータに失敗したことを示し悪いの第四過渡状態もあります。このような不正なデータは、セキュリティ意識のサーバに保持されていません。認証されたデータがゼロ以上SIGと静的にリゾルバに設定されているキーにリゾルバポリシーによって許可されたKEY RRのチェーンを介しKEYトレーサブル下有効SIGを有することを意味します。保留中のデータには、認証済みのSIGと、少なくとも1つの追加のSIGリゾルバがまだ認証しようとしているがありません。安全でないデータは、それがであるか、無担保ゾーンを経由して到達したため、それが発見された場所、ゾーンで認証済みか見つけ悪いのどちらかになることはありませんが知られているデータであるか、それは符号なし糊アドレスまたは委任ポイントNSデータであるため。このようなデータのラベルに基づいての制御とフラグ付けの点で挙動は、セクション6.1に記載されています。
The proper validation of signatures requires a reasonably secure shared opinion of the absolute time between resolvers and servers as described in Section 6.4.
署名の適切な検証は6.4節で説明したようにリゾルバとサーバ間の絶対時間の合理的にセキュアな共有の意見が必要です。
Two previously unused bits are allocated out of the DNS query/response format header. The AD (authentic data) bit indicates in a response that all the data included in the answer and authority portion of the response has been authenticated by the server according to the policies of that server. The CD (checking disabled) bit indicates in a query that Pending (non-authenticated) data is acceptable to the resolver sending the query.
二つの未使用ビットは、DNSクエリ/応答フォーマットヘッダから割り当てられています。 AD（本物のデータ）のビットは、応答の回答と権威部に含まれるすべてのデータは、そのサーバのポリシーに従ってサーバによって認証されたことを応答して示しています。 CD（チェック無効）ビットは、保留（非認証）のデータがクエリを送信リゾルバに受け入れられるクエリに示します。
These bits are allocated from the previously must-be-zero Z field as follows:
次のようにこれらのビットは以前でなければならないゼロZフィールドから割り当てられています。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
These bits are zero in old servers and resolvers. Thus the responses of old servers are not flagged as authenticated to security aware resolvers and queries from non-security aware resolvers do not assert the checking disabled bit and thus will be answered by security aware servers only with Authenticated or Insecure data. Security aware resolvers MUST NOT trust the AD bit unless they trust the server they are talking to and either have a secure path to it or use DNS transaction security.
これらのビットは、古いサーバとリゾルバではゼロです。チェック無効ビットをアサートしていない非セキュリティ対応リゾルバからのセキュリティ対応リゾルバとクエリに認証されたので、唯一の認証や安全でないデータとセキュリティ対応サーバで答えられるようしたがって、古いサーバの応答はフラグが設定されていません。彼らが話しているサーバーを信頼し、それへの安全なパスを持っているか、DNSトランザクションセキュリティを使用するかしない限り、セキュリティ対応リゾルバは、ADビットを信用してはいけません。
Any security aware resolver willing to do cryptography SHOULD assert the CD bit on all queries to permit it to impose its own policies and to reduce DNS latency time by allowing security aware servers to answer with Pending data.
暗号化を行うには喜んで任意のセキュリティ対応リゾルバは、独自のポリシーを課すこととセキュリティ対応サーバは、保留中のデータと答えるできるようにすることで、DNSの遅延時間を短縮することを可能にするために、すべてのクエリにCDビットをアサートすべきです。
Security aware servers MUST NOT return Bad data. For non-security aware resolvers or security aware resolvers requesting service by having the CD bit clear, security aware servers MUST return only Authenticated or Insecure data in the answer and authority sections with the AD bit set in the response. Security aware servers SHOULD return Pending data, with the AD bit clear in the response, to security aware resolvers requesting this service by asserting the CD bit in their request. The AD bit MUST NOT be set on a response unless all of the RRs in the answer and authority sections of the response are either Authenticated or Insecure. The AD bit does not cover the additional information section.
セキュリティ意識のサーバーが不正なデータを返してはなりません。非セキュリティ対応リゾルバまたはCDビットがクリアさせることによってサービスを要求するセキュリティ対応リゾルバのために、セキュリティ意識のサーバが応答に設定されたADビットと答えと権威セクションで唯一の認証や安全でないデータを返さなければなりません。セキュリティ対応サーバは、その要求にCDビットをアサートすることにより、このサービスを要求するセキュリティ対応リゾルバに、対応して明確なADビットと、保留中のデータを返すべきです。応答の答えと権威セクションにあるRRの全てがいずれかの認証または安全でないされていない限り、ADビットは、応答に設定してはいけません。 ADビットは、追加情報セクションをカバーしていません。
The public key to authenticate a zone SHOULD be defined in local configuration files before that zone is loaded at the primary server so the zone can be authenticated.
ゾーンを認証することができますので、そのゾーンがプライマリサーバにロードされる前に、ゾーンを認証するための公開鍵は、ローカル構成ファイルで定義する必要があります。
While it might seem logical for everyone to start with a public key associated with the root zone and staticly configure this in every resolver, this has problems. The logistics of updating every DNS resolver in the world should this key ever change would be severe. Furthermore, many organizations will explicitly wish their "interior" DNS implementations to completely trust only their own DNS servers. Interior resolvers of such organizations can then go through the organization's zone servers to access data outside the organization's domain and need not be configured with keys above the organization's DNS apex.
誰もがルートゾーンに関連付けられている公開鍵で開始し、静的にすべてのリゾルバでこれを設定することが論理的に見えるかもしれませんが、これは問題があります。世界のすべてのDNSリゾルバを更新する物流は、このキーこれまでの変更は厳しいだろう必要があります。さらに、多くの組織は、明示的に「内部」のDNS実装が完全にのみ、独自のDNSサーバーを信頼することを希望します。このような組織の内部リゾルバは、組織のドメイン外のデータにアクセスするために、組織のゾーンのサーバーを介して行くことができ、組織のDNSの頂点上記のキーを使用して設定する必要はありません。
Host resolvers that are not part of a larger organization may be configured with a key for the domain of their local ISP whose recursive secure DNS caching server they use.
大きな組織の一部ではないホストリゾルバは再帰的なセキュアなDNSキャッシュサーバー、彼らが使用して自分のローカルISPのドメインのためのキーを設定することができます。
Starting with one or more trusted keys for any zone, it should be possible to retrieve signed keys for that zone's subzones which have a key. A secure sub-zone is indicated by a KEY RR with non-null key information appearing with the NS RRs in the sub-zone and which may also be present in the parent. These make it possible to descend within the tree of zones.
いずれかのゾーンのための1つまたは複数の信頼できるキーで開始し、キーを持って、そのゾーンのサブゾーンのための署名キーを取得することが可能です。セキュアサブゾーンは、非ヌル鍵情報は、サブゾーンにNSのRRで出現し、これはまた、親に存在してもよいとKEYのRRで示されています。これらは、それが可能なゾーンのツリーの中に下降するようにしてください。
In general, some RRset that you wish to validate in the secure DNS will be signed by one or more SIG RRs. Each of these SIG RRs has a signer under whose name is stored the public KEY to use in authenticating the SIG. Each of those KEYs will, generally, also be signed with a SIG. And those SIGs will have signer names also referring to KEYs. And so on. As a result, authentication leads to chains of alternating SIG and KEY RRs with the first SIG signing the original data whose authenticity is to be shown and the final KEY being some trusted key staticly configured at the resolver performing the authentication.
一般的には、あなたがセキュアなDNSで検証したいいくつかのRRセットは、一つ以上のSIGのRRによって署名されます。これらのSIG RRのそれぞれは、その名のSIGの認証に使用する公開鍵を格納している下で、署名者を持っています。これらの各キーには、一般的に、またSIGで署名されます。そして、それらのSIGはまた、キーを参照する署名者の名前を持っています。等々。その結果、認証が真正で示され、いくつかの信頼できる鍵である最終鍵が静的に認証を行うレゾルバで構成されるべき元のデータを署名最初SIGとSIGとKEY RRを交互の鎖をもたらします。
In testing such a chain, the validity periods of the SIGs encountered must be intersected to determine the validity period of the authentication of the data, a purely algorithmic process. In addition, the validation of each SIG over the data with reference to a KEY must meet the objective cryptographic test implied by the cryptographic algorithm used (although even here the resolver may have policies as to trusted algorithms and key lengths). Finally, the judgement that a SIG with a particular signer name can authenticate data (possibly a KEY RRset) with a particular owner name, is primarily a policy question. Ultimately, this is a policy local to the resolver and any clients that depend on that resolver's decisions. It is, however, recommended, that the policy below be adopted:
そのような鎖を試験する際に、遭遇のSIGの有効期間は、データ、純粋にアルゴリズム的プロセスの認証の有効期間を決定するように交差しなければなりません。また、KEYを参照して、データに対する各SIGの検証は（ここでもリゾルバが信頼アルゴリズムおよび鍵長についてのポリシーを持っているかもしれないが）使用される暗号アルゴリズムによって暗示客観暗号テストを満たさなければなりません。最後に、特定の署名者名を持つSIGは、特定の所有者名を（おそらくKEY RRセット）のデータを認証することができるの判断は、主に政策の問題です。最終的に、これはリゾルバとそのリゾルバの決定に依存するすべてのクライアントにローカルポリシーです。しかし、以下の方針を採用することを、お勧めします。
Let A < B mean that A is a shorter domain name than B formed by
dropping one or more whole labels from the left end of B, i.e.,
A is a direct or indirect superdomain of B. Let A = B mean that
A and B are the same domain name (i.e., are identical after
letter case canonicalization). Let A > B mean that A is a
longer domain name than B formed by adding one or more whole
labels on the left end of B, i.e., A is a direct or indirect
subdomain of B
Let Static be the owner names of the set of staticly configured trusted keys at a resolver.
静的リゾルバで静的に構成された、信頼できるキーのセットの所有者名とします。
Then Signer is a valid signer name for a SIG authenticating an RRset (possibly a KEY RRset) with owner name Owner at the resolver if any of the following three rules apply:
その後、署名者は、次の3つのルールのいずれかに該当する場合、リゾルバの所有者名所有者でRRセット（おそらくKEY RRセット）を認証SIGの有効な署名者名は次のとおりです。
(1) Owner > or = Signer (except that if Signer is root, Owner must be root or a top level domain name). That is, Owner is the same as or a subdomain of Signer.
（1）所有者>または=署名者（署名者がルートである場合、所有者がルートまたはトップレベルドメイン名でなければならないことを除いては）。それは所有者が同じか、署名者のサブドメインである、です。
(2) ( Owner < Signer ) and ( Signer > or = some Static ). That is, Owner is a superdomain of Signer and Signer is staticly configured or a subdomain of a staticly configured key.
（2）（所有者<署名者）と（署名者>または=何らかの静的）。それは所有者が署名者と署名者のスーパードメイン静的に設定されているか、静的に設定されているキーのサブドメインである、です。
(3) Signer = some Static. That is, the signer is exactly some staticly configured key.
（3）署名者は、いくつかの静的=。これは、署名者は、正確にいくつかの静的に設定されているキーで、です。
Rule 1 is the rule for descending the DNS tree and includes a special prohibition on the root zone key due to the restriction that the root zone be only one label deep. This is the most fundamental rule.
ルール1は、DNSツリーを下降するためのルールであるとによるルートゾーンが一つだけのラベルの深さ制限にルートゾーンキーの特別な禁止を含んでいます。これは、最も基本的なルールです。
Rule 2 is the rule for ascending the DNS tree from one or more staticly configured keys. Rule 2 has no effect if only root zone keys are staticly configured.
ルール2は、一つ以上の静的に設定されたキーからのDNSツリーを昇順ためのルールです。ルール2は、ルートゾーンキーが静的に設定されている場合は効果がありません。
Rule 3 is a rule permitting direct cross certification. Rule 3 has no effect if only root zone keys are staticly configured.
ルール3は、直接相互認証を許可するルールです。ルール3は、唯一のルートゾーンキーが静的に設定されている場合は効果がありません。
Great care should be taken that the consequences have been fully considered before making any local policy adjustments to these rules (other than dispensing with rules 2 and 3 if only root zone keys are staticly configured).
細心の注意は、結果は完全に（のみルートゾーンキーが静的に設定されている場合は、ルール2と3で調剤以外の）これらの規則に任意のローカルポリシーの調整を行う前に考慮されていることに注意しなければなりません。
It is possible that there will be multiple SIG-KEY chains that appear to authenticate conflicting RRset answers to the same query. A resolver should choose only the most reliable answer to return and discard other data. This choice of most reliable is a matter of local policy which could take into account differing trust in algorithms, key sizes, staticly configured keys, zones traversed, etc. The technique given below is recommended for taking into account SIG-KEY chain length.
同じクエリに矛盾RRセットの答えを認証するように思われる複数のSIG-KEYチェーンが存在することも可能です。リゾルバは戻って、他のデータを破棄するための唯一の最も信頼できる答えを選択する必要があります。最も信頼性の高いのこの選択は、下記の技術がアカウントSIG-KEYチェーンの長さを考慮に推奨され、ゾーンが横断などのアルゴリズム、鍵のサイズ、静的に設定されたキーの信頼を異なる考慮に入れることができ、ローカルポリシーの問題です。
A resolver should keep track of the number of successive secure zones traversed from a staticly configured key starting point to any secure zone it can reach. In general, the lower such a distance number is, the greater the confidence in the data. Staticly configured data should be given a distance number of zero. If a query encounters different Authenticated data for the same query with different distance values, that with a larger value should be ignored unless some other local policy covers the case.
リゾルバは、それが到達することができ、任意のセキュアゾーンに静的に設定されているキーの開始点から横断連続セキュアゾーンの数を追跡しなければなりません。一般に、より低いような距離の数は、データに高い信頼性です。静的に構成されたデータは、ゼロの距離番号を与えられるべきです。クエリは異なる距離値と同一のクエリの異なる認証されたデータに遭遇した場合、いくつかの他のローカルポリシーは、ケースをカバーしていない限り、大きな値を持つものは無視されるべきです。
A security conscious resolver should completely refuse to step from a secure zone into a unsecured zone unless the unsecured zone is certified to be non-secure by the presence of an authenticated KEY RR for the unsecured zone with the no-key type value. Otherwise the resolver is getting bogus or spoofed data.
セキュリティ意識リゾルバは完全に保護されていない領域がないキータイプの値を持つ保護されていないゾーンの認証KEY RRの存在により、非セキュアであると認定されていない限り、保護されていないゾーンにセキュアゾーンからステップを拒否しなければなりません。そうしないとリゾルバは偽または偽装されたデータを取得しています。
If legitimate unsecured zones are encountered in traversing the DNS tree, then no zone can be trusted as secure that can be reached only via information from such non-secure zones. Since the unsecured zone data could have been spoofed, the "secure" zone reached via it could be counterfeit. The "distance" to data in such zones or zones reached via such zones could be set to 256 or more as this exceeds the largest possible distance through secure zones in the DNS.
正当なセキュリティで保護されていないゾーンがDNSツリーを横断する際に遭遇している場合は、何のゾーンは、このような非セキュアゾーンからの情報を介して到達することができる、安全なとして信頼することはできません。無担保ゾーンデータが詐称されている可能性があるので、それを介して到達「安全な」ゾーンが偽造である可能性があります。これはDNSで、セキュアゾーンを介して可能な最大距離を超えるようなゾーンを介して到達ようなゾーンまたはゾーン内のデータへの「距離」が256以上に設定することができます。
Coordinated interpretation of the time fields in SIG RRs requires that reasonably consistent time be available to the hosts implementing the DNS security extensions.
SIGのRRでの時間フィールドの協調解釈は合理的に一貫性のある時間はDNSセキュリティ拡張を実装するホストに利用可能である必要があります。
A variety of time synchronization protocols exist including the Network Time Protocol (NTP [RFC 1305, 2030]). If such protocols are used, they MUST be used securely so that time can not be spoofed.
時刻同期プロトコルの様々なネットワークタイムプロトコル（NTP [RFC 1305、2030]）などが存在します。このようなプロトコルが使用されている場合はその時間がスプーフィングすることはできませんので、彼らはしっかりと使用しなければなりません。
Otherwise, for example, a host could get its clock turned back and might then believe old SIG RRs, and the data they authenticate, which were valid but are no longer.
それ以外の場合は、例えば、そのクロックを得ることができるホストは引き返し、その後、古いSIG RRを信じているかもしれないし、有効ではなかったが、もはやそれらが認証データ、。
This section discusses the format for master file and other ASCII presentation of the three DNS security resource records.
このセクションでは、マスターファイルと3つのDNSセキュリティリソースレコードの他のASCIIプレゼンテーションのためのフォーマットについて説明します。
The algorithm field in KEY and SIG RRs can be represented as either an unsigned integer or symbolicly. The following initial symbols are defined as indicated:
KEYとSIG資源レコードにおけるアルゴリズムフィールドは符号なし整数またはsymboliclyのいずれかとして表すことができます。示されるように、以下の初期のシンボルが定義されています。
Value Symbol
値シンボル
001 RSAMD5 002 DH 003 DSA 004 ECC 252 INDIRECT 253 PRIVATEDNS 254 PRIVATEOID
RSAMD5 DH 001 002 003 004 ECC DSA 252 253 INDIRECT PRIVATEDNS 254 PRIVATEOID
KEY RRs may appear as single logical lines in a zone data master file [RFC 1033].
KEY RRは、ゾーンデータマスターファイル[RFC 1033]で単一の論理行として表示されることができます。
The flag field is represented as an unsigned integer or a sequence of mnemonics as follows separated by instances of the verticle bar ("|") character:
次のようにフラグフィールドは、垂直方向のバー（「|」）のインスタンスによって分離された符号なし整数またはニーモニックのシーケンスとして表されている文字。
BIT Mnemonic Explanation 0-1 key type NOCONF =1 confidentiality use prohibited NOAUTH =2 authentication use prohibited NOKEY =3 no key present 2 FLAG2 - reserved 3 EXTEND flags extension 4 FLAG4 - reserved 5 FLAG5 - reserved 6-7 name type USER =0 (default, may be omitted) ZONE =1 HOST =2 (host or other end entity) NTYP3 - reserved 8 FLAG8 - reserved 9 FLAG9 - reserved
BITニーモニック説明0-1キー型NOCONF = 1機密使用はNOAUTH = 2認証使用禁止NOKEY = 3ないキー本2 FLAG2を禁止 - 3 FLAGS伸長4 FLAG4をEXTEND予約 - 5 FLAG5予約 - 6-7名前型USER = 0予約しました（デフォルト、省略してもよい）ZONE = 1 HOST = 2（ホストまたは他のエンドエンティティ）NTYP3は - 8 FLAG8予約は - 9 FLAG9予約 - 予約します
10 FLAG10 - reserved 11 FLAG11 - reserved 12-15 signatory field, values 0 to 15 can be represented by SIG0, SIG1, ... SIG15
10 FLAG10は、 - 0~15 SIG0で表されることができ、SIG1、... SIG15値、12-15署名フィールドを予約 - 11 FLAG11予約しました
No flag mnemonic need be present if the bit or field it represents is zero.
それが表すビットまたはフィールドが0であれば何フラグニーモニックが存在する必要はありません。
The protocol octet can be represented as either an unsigned integer or symbolicly. The following initial symbols are defined:
プロトコルオクテットは、符号なし整数またはsymboliclyのいずれかとして表すことができます。以下の初期シンボルが定義されています。
000 NONE
001 TLS
002 EMAIL
003 DNSSEC
004 IPSEC
255 ALL
Note that if the type flags field has the NOKEY value, nothing appears after the algorithm octet.
タイプフラグフィールドがNOKEY値を持っている場合、何もアルゴリズムオクテットの後に表示されないことに注意してください。
The remaining public key portion is represented in base 64 (see Appendix A) and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can span lines using the standard parenthesis.
残りの公開鍵部分は、基部64に示されている（付録A参照）、ダウン単一塩基への完全な署名を得るために連結されている64桁、ホワイトスペースで区切られたサブストリングの任意の数に分割してもよいです。これらの部分文字列は、標準の括弧を使用して行にまたがることができます。
Note that the public key may have internal sub-fields but these do not appear in the master file representation. For example, with algorithm 1 there is a public exponent size, then a public exponent, and then a modulus. With algorithm 254, there will be an OID size, an OID, and algorithm dependent information. But in both cases only a single logical base 64 string will appear in the master file.
公開鍵は内部のサブフィールドを有することができるが、これらはマスターファイル表現で表示されないことに注意してください。例えば、アルゴリズム1と公開指数サイズ、次に公開指数、及びその後モジュラスがあります。アルゴリズム254では、OIDサイズ、OID、およびアルゴリズムに依存する情報が存在します。しかし、どちらの場合にのみ、単一の論理ベース64文字列は、マスターファイルに表示されます。
A data SIG RR may be represented as a single logical line in a zone data file [RFC 1033] but there are some special considerations as described below. (It does not make sense to include a transaction or request authenticating SIG RR in a file as they are a transient authentication that covers data including an ephemeral transaction number and so must be calculated in real time.)
データSIG RRは、ゾーンデータファイル[RFC 1033]で単一の論理行として表されてもよいが、以下に説明するようにいくつかの特別な考慮事項があります。 （それは彼らが短命取引番号などをリアルタイムに計算されなければならないなどのデータを網羅過渡認証されているように、ファイルSIG RRを認証するトランザクションまたは要求を含めるしても意味がありません。）
There is no particular problem with the signer, covered type, and times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59).
署名者、カバータイプ、および時間と特に問題はありません。時間フィールドは、YYYYは年形式YYYYMMDDHHMMSSで表示され、最初のMMは月番号（01-12）、DDは月（1月31日）の日であり、HHは24時間表記の時間（00です-23）、第二のMMは分（00-59）であり、SSは秒（00-59）です。
The original TTL field appears as an unsigned integer.
オリジナルのTTLフィールドは、符号なし整数として表示されます。
If the original TTL, which applies to the type signed, is the same as the TTL of the SIG RR itself, it may be omitted. The date field which follows it is larger than the maximum possible TTL so there is no ambiguity.
署名されたタイプに適用され、元のTTLは、SIG RR自体のTTLと同じである場合、それは省略してもよいです。いかなる曖昧さが存在しないので、それを次の日付フィールドには最大可能TTLよりも大きいです。
The "labels" field appears as an unsigned integer.
「ラベル」フィールドは、符号なし整数として表示されます。
The key tag appears as an unsigned number.
鍵タグは、符号なしの数値として表示されます。
However, the signature itself can be very long. It is the last data field and is represented in base 64 (see Appendix A) and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can be split between lines using the standard parenthesis.
しかし、署名自体は非常に長くなることができます。これは、最後のデータフィールドであり、ベース64に示されている（付録A参照）、ダウン単一塩基への完全な署名を得るために連結されている64桁、ホワイトスペースで区切られたサブストリングの任意の数に分割してもよいです。これらの部分文字列は、標準の括弧を使用して行に分割することができます。
NXT RRs do not appear in original unsigned zone master files since they should be derived from the zone as it is being signed. If a signed file with NXTs added is printed or NXTs are printed by debugging code, they appear as the next domain name followed by the RR type present bits as an unsigned interger or sequence of RR mnemonics.
それが署名されているとして、彼らはゾーンから派生しなければならないので、NXTのRRは、元の符号なしのゾーンのマスターファイルには表示されません。加えNXTs符号付きファイルが印刷されるかNXTsコードをデバッグすることによって印刷される場合、それらはRRニーモニックの符号なしintergerまたはシーケンスとしてRR型存在ビットに続く次のドメイン名として表示されます。
This section specifies, for purposes of domain name system (DNS) security, the canonical form of resource records (RRs), their name order, and their overall order. A canonical name order is necessary to construct the NXT name chain. A canonical form and ordering within an RRset is necessary in consistently constructing and verifying SIG RRs. A canonical ordering of types within a name is required in connection with incremental transfer (Section 5.6.2).
このセクションでは、ドメインネームシステム（DNS）セキュリティ、リソースレコード（RR）の正規形、自分の名前の順序、および全体的な秩序の目的のために、指定します。正規名順はNXT名のチェーンを構築する必要があります。資源レコード集合内の標準形式および順序付けは一貫してSIG RRを構築し、検証に必要です。名前の中のタイプの標準的な順序は、増分転送（5.6.2項）に関連して必要とされます。
For purposes of DNS security, the canonical form for an RR is the wire format of the RR with domain names (1) fully expanded (no name compression via pointers), (2) all domain name letters set to lower case, (3) owner name wild cards in master file form (no substitution made for *), and (4) the original TTL substituted for the current TTL.
DNSセキュリティの目的のために、RRのための標準形式は、ドメイン名を持つRRのワイヤフォーマットである（1）完全に拡張（なし名称圧縮ポインタを介して）、（2）すべてのドメイン名の文字を小文字に設定し、（3）マスタファイル形式で所有者名ワイルドカード現在のTTLの代わりに（*ために作られた無置換）、及び（4）元のTTL。
For purposes of DNS security, the canonical ordering of owner names is to sort individual labels as unsigned left justified octet strings where the absence of a octet sorts before a zero value octet and upper case letters are treated as lower case letters. Names in a zone are sorted by sorting on the highest level label and then, within those names with the same highest level label by the next lower label, etc. down to leaf node labels. Within a zone, the zone name itself always exists and all other names are the zone name with some prefix of lower level labels. Thus the zone name itself always sorts first.
DNSセキュリティの目的のためには、所有者名の正規の順序はオクテットの種類が存在しない場合は、ゼロ値のオクテットと大文字の文字が小文字として扱われる前に、符号なしの左詰めでオクテット文字列として個々のラベルを並べ替えることです。ゾーンの名前は、リーフノードのラベルまで、次に低いラベルなどによって同じ最高レベルのラベルを持つこれらの名前の中には、最高レベルのラベルにソートとによって並べ替えられています。ゾーン内では、自身が常に存在するゾーン名と他のすべての名称は、下位レベルのラベルのいくつかの接頭辞を持つゾーン名です。このようにゾーン名自体は常に最初にソートします。
Example: foo.example a.foo.example yljkjljk.a.foo.example Z.a.foo.example zABC.a.FOO.EXAMPLE z.foo.example *.z.foo.example \200.z.foo.example
例：foo.example a.foo.example yljkjljk.a.foo.example Z.a.foo.example zABC.a.FOO.EXAMPLE z.foo.example * .z.foo.example \ 200.z.foo.example
Within any particular owner name and type, RRs are sorted by RDATA as a left justified unsigned octet sequence where the absence of an octet sorts before the zero octet.
任意の特定の所有者の名前とタイプ内で、RRは左正当符号なしオクテットシーケンスとしてRDATAによってソートされるゼロオクテット前オクテット種類の不在。
When RRs of the same name but different types must be ordered, they are ordered by type, considering the type to be an unsigned integer, except that SIG RRs are placed immediately after the type they cover. Thus, for example, an A record would be put before an MX record because A is type 1 and MX is type 15 but if both were signed, the order would be A < SIG(A) < MX < SIG(MX).
名前が同じで、異なる種類のRRのを注文しなければならない場合には、そのSIG RRを、それらがカバータイプの直後に配置されている以外、それらは、符号なし整数にタイプを考慮して、タイプによって順序付けされています。したがってAがタイプ1であり、MXは15型であるため、例えば、レコードは、MXレコードの前に置かれるが、両方が署名された場合、順序は<SIG（A）であろう<MX <SIG（MX）。
Levels of server and resolver conformance are defined below.
サーバとリゾルバの適合性のレベルは、以下に定義されています。
Two levels of server conformance for DNS security are defined as follows:
次のようにDNSのセキュリティのため、サーバーの適合性の2つのレベルが定義されています。
BASIC: Basic server compliance is the ability to store and retrieve (including zone transfer) SIG, KEY, and NXT RRs. Any secondary or caching server for a secure zone MUST have at least basic compliance and even then some things, such as secure CNAMEs, will not work without full compliance.
BASIC：基本的なサーバーのコンプライアンスがSIG、KEY、およびNXTのRR（ゾーン転送を含む）を格納および取得する機能です。安全なゾーンの任意のセカンダリまたはキャッシュサーバは、少なくとも基本的なコンプライアンスを有していなければならず、その後も安全なのCNAMEなどいくつかのものは、完全に遵守せずに動作しません。
FULL: Full server compliance adds the following to basic compliance: (1) ability to read SIG, KEY, and NXT RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG and NXT RRs, possibly via a separate application, (3) proper automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) suppression of CNAME following on retrieval of the security type RRs, (5) recognize the CD query header bit and set the AD query header bit, as appropriate, and (6) proper handling of the two NXT RRs at delegation points. Primary servers for secure zones MUST be fully compliant and for complete secure operation, all secondary, caching, and other servers handling the zone SHOULD be fully compliant as well.
FULL：フルサーバーのコンプライアンスは、基本的な遵守に以下を追加します：（1）ゾーンファイルと（2）の能力にSIG、KEY、およびNXT RRを読み取る能力、適切なSIGおよびNXT RRを追加するには、ゾーンファイルと秘密鍵与えられ、おそらく別のアプリケーションを介して、（3）SIG、KEY、および応答にNXT資源レコード、CNAMEがセキュリティタイプRRの検索で、次の（4）抑制の適切な自動含める（5）CDクエリヘッダビットを認識し、設定AD適切なクエリヘッダビット、および委任点における2つのNXT RRの（6）適切な取り扱い。安全なゾーンのプライマリサーバは、すべてのセカンダリ、キャッシュに完全に準拠し、完全に安全な操作のためでなければならない、とゾーンを扱う他のサーバも同様に完全に準拠するべきです。
Two levels of resolver compliance (including the resolver portion of a server) are defined for DNS Security:
（サーバーのリゾルバ部分を含む）リゾルバのコンプライアンスの二つのレベルは、DNSセキュリティのために定義されています。
BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs when they are explicitly requested.
BASIC：それらが明示的に要求された場合、基本的なコンプライアンスリゾルバは、SIG、KEY、およびNXT RRを扱うことができます。
FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT RRs including verification of SIGs at least for the mandatory algorithm, (2) maintains appropriate information in its local caches and database to indicate which RRs have been authenticated and to what extent they have been authenticated, (3) performs additional queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when needed, (4) normally sets the CD query header bit on its queries.
FULL：完全に準拠レゾルバ（1）は、少なくとも必須のアルゴリズムのSIGの検証を含むKEY、SIG、およびNXT RRを理解し、（2）のRRが認証されたかを示すために、そのローカル・キャッシュとデータベース内の適切な情報を維持し、何にエクステントそれらは（4）は、通常、そのクエリにCDクエリヘッダビットを設定し、必要な場合（3）KEY、SIGを取得しようとするために、必要に応じて追加のクエリを実行し、またはNXT RRを、認証されました。
This document specifies extensions to the Domain Name System (DNS) protocol to provide data integrity and data origin authentication, public key distribution, and optional transaction and request security.
このドキュメントでは、データの整合性とデータ発信元認証、公開鍵配布、およびオプション取引と要求セキュリティを提供するために、ドメインネームシステム（DNS）プロトコルの拡張を指定します。
It should be noted that, at most, these extensions guarantee the validity of resource records, including KEY resource records, retrieved from the DNS. They do not magically solve other security problems. For example, using secure DNS you can have high confidence in the IP address you retrieve for a host name; however, this does not stop someone for substituting an unauthorized host at that address or capturing packets sent to that address and falsely responding with packets apparently from that address. Any reasonably complete security system will require the protection of many additional facets of the Internet beyond DNS.
せいぜい、これらの拡張機能は、DNSから取得KEYリソースレコードを含め、リソースレコードの妥当性を保証することに留意すべきです。彼らは魔法のように、他のセキュリティ問題を解決しません。例えば、セキュアなDNSを使用して、あなたがホスト名の取得IPアドレスで高い信頼性を持つことができます。しかし、これはそのアドレスに不正ホストを置き換えるか、そのアドレスに送信されたパケットをキャプチャし、誤ってそのアドレスから明らかパケットで応答するために誰かを停止しません。任意の合理的に完全なセキュリティシステムがDNSを超え、インターネットの多くの追加ファセットの保護を必要とします。
The implementation of NXT RRs as described herein enables a resolver to determine all the names in a zone even if zone transfers are prohibited (section 5.6). This is an active area of work and may change.
本明細書に記載されるようNXT RRの実装では、ゾーン転送は（セクション5.6）を禁止している場合でも、リゾルバは、ゾーン内のすべての名前を決定することが可能となります。これは仕事の活性領域であり、変更される可能性。
A number of precautions in DNS implementation have evolved over the years to harden the insecure DNS against spoofing. These precautions should not be abandoned but should be considered to provide additional protection in case of key compromise in secure DNS.
DNSの実装における注意事項の数は、なりすましに対して安全でないDNSを強化するために長年にわたって進化してきました。これらの予防措置は放棄されるべきではなく、安全なDNSの重要な妥協の場合には追加的な保護を提供するために考慮されるべきです。
KEY RR flag bits 2 and 8-11 and all flag extension field bits can be assigned by IETF consensus as defined in RFC 2434. The remaining values of the NAMTYP flag field and flag bits 4 and 5 (which could conceivably become an extension of the NAMTYP field) can only be assigned by an IETF Standards Action [RFC 2434].
RFC 2434で定義されるようにKEY RRフラグビット2及び8-11と全てフラグ拡張フィールドビットはNAMTYPフラグフィールド及びフラグビットの残りの値は4と5（おそらくの拡張になる可能性がIETFコンセンサスによって割り当てることができますNAMTYPフィールドが）のみIETF標準化アクション[RFC 2434]で割り当てることができます。
Algorithm numbers 5 through 251 are available for assignment should sufficient reason arise. However, the designation of a new algorithm could have a major impact on interoperability and requires an IETF Standards Action [RFC 2434]. The existence of the private algorithm types 253 and 254 should satify most needs for private or proprietary algorithms.
アルゴリズム番号5 251までは、十分な理由が生じれば、割り当てのために利用可能です。しかし、新しいアルゴリズムの指定は、相互運用性に大きな影響を与えるとIETF標準化行動[RFC 2434]を必要とすることができます。プライベートアルゴリズムの種類253と254の存在は、プライベートまたは独自のアルゴリズムのための最もニーズをsatify必要があります。
Additional values of the Protocol Octet (5-254) can be assigned by IETF Consensus [RFC 2434].
プロトコルオクテット（5-254）の追加の値は、IETFコンセンサス[RFC 2434]で割り当てることができます。
The meaning of the first bit of the NXT RR "type bit map" being a one can only be assigned by a standards action.
NXT RR「タイプのビットマップが」1であることの最初のビットの意味は、唯一の標準アクションで割り当てることができます。
References
リファレンス
[RFC 1033] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, November 1987.
[RFC 1033] Lottor、M.、 "ドメイン管理者操作ガイド"、RFC 1033、1987年11月。
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC 1034] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC 1035] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
[RFC 1305] Mills, D., "Network Time Protocol (v3)", RFC 1305, March 1992.
[RFC 1305]ミルズ、D.、 "ネットワークタイムプロトコル（V3）"、RFC 1305、1992年3月。
[RFC 1530] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT Subdomain: General Principles and Policy", RFC 1530, October 1993.
[RFC 1530]マラマッド、C.とM.ローズ、 "TPC.INTサブドメインのための動作原理：一般原則と政策"、RFC 1530、1993年10月。
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC 2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, September 1996.
[RFC 1982]エルツ、R.とR.ブッシュ大統領、 "シリアル番号演算"、RFC 1982、1996年9月。
[RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC 1995]太田、M.、 "DNSにおける増分ゾーン転送"、RFC 1995、1996年8月。
[RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC 2030]ミルズ、D.、 "IPv4、IPv6、およびOSIのため簡易ネットワークタイムプロトコル（SNTP）バージョン4"、RFC 2030、1996年10月。
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC 2045]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC 2065]イーストレイク、D.およびC.カウフマン、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2065、1997年1月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC 2136]いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.はバウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[RFC 2137]イーストレイク、D.は、RFC 2137、1997年4月、 "ドメインネームシステム動的な更新を固定します"。
[RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC 2181]エルツ、R.とR.ブッシュ大統領、 "DNS仕様の明確化"、RFC 2181、1997年7月。
[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC 2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", RFC 2537, March 1999.
[RFC 2537]イーストレイク、D.、 "RSA / MD5キーおよびドメインネームシステム（DNS）でのSIG"、RFC 2537、1999年3月。
[RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999.
[RFC 2539]イーストレイク、D.、RFC 2539 "ドメインネームシステム（DNS）でのDiffie-Hellmanの鍵の保管"、1999年3月。
[RFC 2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC 2536]イーストレイク、D.、 "DSA鍵とドメインネームシステム（DNS）でのSIG"、RFC 2536、1999年3月。
[RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System", RFC 2538, March 1999.
[RFC 2538]イーストレイク、D.およびO.グドムンソン、 "ドメインネームシステムでの保管証明書"、RFC 2538、1999年3月。
[RFC 2541] Eastlake, D., "DNS Operational Security Considerations", RFC 2541, March 1999.
[RFC 2541]イーストレイク、D.、 "DNS運用セキュリティの考慮事項"、RFC 2541、1999年3月。
[RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
[RSAのFAQ] - RSADSIよくある質問定期的な投稿。
Author's Address
著者のアドレス
Donald E. Eastlake 3rd IBM 65 Shindegan Hill Road RR #1 Carmel, NY 10512
ドナルドE.イーストレイク3位IBM 65 ShindeganヒルロードRR＃1カーメル、NY 10512
Phone: +1-914-784-7913 (w) +1-914-276-2668 (h) Fax: +1-914-784-3833 (w-fax) EMail: dee3@us.ibm.com
電話番号：+ 1-914-784-7913 1-914-276-2668 +（W）（H）ファックス：+ 1-914-784-3833（W-FAX）Eメール：dee3@us.ibm.com
Appendix A: Base 64 Encoding
付録A：基本64エンコーディング
The following encoding technique is taken from [RFC 2045] by N. Borenstein and N. Freed. It is reproduced here in an edited form for convenience.
次の符号化技術は、N. Borenstein及びN.フリードによって[RFC 2045]から取られます。これは、利便性のために編集された形でここに再現されます。
A 65-character subset of US-ASCII is used, enabling 6 bits to be represented per printable character. (The extra 65th character, "=", is used to signify a special processing function.)
US-ASCIIの65文字サブセットは、印刷可能な文字ごとに表現する6ビットを可能に用いられます。 （余分な65番目の文字は、「=」、特別な処理機能を意味するために使用されます。）
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating 3 8-bit input groups. These 24 bits are then treated as 4 concatenated 6-bit groups, each of which is translated into a single digit in the base 64 alphabet.
符号化プロセスは、4つのエンコードされた文字の出力列として入力ビットの24ビットのグループを表します。左から右に進むと、24ビットの入力グループは3〜8ビットの入力グループを連結することによって形成されています。これらの24ビットは、ベース64のアルファベットに単一の数字に変換されそれぞれが4連結さ6ビットのグループとして扱われます。
Each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string.
各6ビットグループは64の印刷可能文字の配列へのインデックスとして使用されます。インデックスで参照される文字は、出力文字列に配置されます。
Table 1: The Base 64 Alphabet
表1：ベース64アルファベット
Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y
値エンコーディング値エンコーディング値エンコーディング値34 I 51 Z 1 B 18 S 35 J 52 0 2 C 19 T 36 K 53 1 3 D 20 U 37リットル54 2 4 E 21、V 38メートル55 3 5 F 17 R 0エンコーディング22 W 39 N 56 4 6 G 23 X 40 O 57 5 7 H 24 Y 41、P 58 6 8 I 25、Z 42、Q 59 7 9 26 J 43 R 60 8 10 K 27、B 44、S 61 9 11 L 28 C 45トン62 + 12 M 29、D 46、U 13分の63 N 30、E 47、V 14 O 31 48 F（パッド）= 15 P 32グラム49 X 16 Q 33 H 50 Y、W
Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a quantity. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Padding at the end of the data is performed using the '=' character. Since all base 64 input is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.
未満の24ビットは符号化されたデータの最後に利用可能である場合、特別な処理が行われます。フルエンコードの量子は、常に量の年末に完成されます。 24個の未満の入力ビットが入力グループに利用可能である場合、ゼロのビットが6ビットグループの整数を形成する（右側）を添加します。データの終わりにパディングが「=」文字を使用して行われます。全てのベース64の入力は、次の場合に発生する可能性が、オクテットの整数であるので、（1）符号化入力の最終的な量子は、24ビットの整数倍です。ここで、符号化された出力の最終のユニット（2）符号化入力の最終量子が正確に8ビットであり、NO「=」パディングと4つの文字の整数倍であろう。ここで、符号化された出力の最終的なユニットは、2つの「=」パディング文字に続く2つの文字であるか、または（3）符号化入力の最終的な量子は正確に16ビットです。ここでは、エンコードされた出力の最終単位は1「=」パディング文字が続く3つの文字になります。
Appendix B: Changes from RFC 2065
付録B：RFC 2065からの変更点
This section summarizes the most important changes that have been made since RFC 2065.
このセクションでは、RFC 2065以降に行われてきた最も重要な変更点をまとめ。
1. Most of Section 7 of [RFC 2065] called "Operational Considerations", has been removed and may be made into a separate document [RFC 2541].
1. [RFC 2065]いわゆる「操作の考慮事項」の第7章の大部分は、除去され、別の文書[RFC 2541]にしてもよいです。
2. The KEY RR has been changed by (2a) eliminating the "experimental" flag as unnecessary, (2b) reserving a flag bit for flags expansion, (2c) more compactly encoding a number of bit fields in such a way as to leave unchanged bits actually used by the limited code currently deployed, (2d) eliminating the IPSEC and email flag bits which are replaced by values of the protocol field and adding a protocol field value for DNS security itself, (2e) adding material to indicate that zone KEY RRs occur only at delegation points, and (2f) removing the description of the RSA/MD5 algorithm to a separate document [RFC 2537]. Section 3.4 describing the meaning of various combinations of "no-key" and key present KEY RRs has been added and the secure / unsecure status of a zone has been clarified as being per algorithm.
2. KEY RRは不要として「実験」フラグを除去する（2A）、（2B）、フラグ拡張用フラグビットを予約（2C）よりコンパクトに残すような方法でビットフィールドの数を符号化することによって変更されています実際に現在配備制限符号、（2D）（2E）そのゾーンを示すために材料を追加すること、プロトコルフィールドの値によって置換されるIPSEC及びメールフラグビットを排除し、DNSセキュリティ自体のプロトコルフィールド値を追加することによって、使用不変ビットKEY RRは委任点でのみ起こる、及び（2F）別の文書[RFC 2537]にRSA / MD5アルゴリズムの説明を除去します。 「非キー」およびキー本KEY RRの種々の組み合わせの意味を説明するセクション3.4が追加されており、ゾーンのセキュア/非セキュア状態はアルゴリズムごとであると明らかにされています。
3. The SIG RR has been changed by (3a) renaming the "time signed" field to be the "signature inception" field, (3b) clarifying that signature expiration and inception use serial number ring arithmetic, (3c) changing the definition of the key footprint/tag for algorithms other than 1 and adding Appendix C to specify its calculation. In addition, the SIG covering type AXFR has been eliminated while one covering IXFR [RFC 1995] has been added (see section 5.6).
3. SIG RRは、名前の変更（3a）で変更された（図3C）の定義を変更すること、（3B）署名の有効期限と開始は、シリアルナンバーリング演算を使用することを明確に、「署名開始」フィールドするフィールドを「時間に署名しました」 1以外のアルゴリズムおよび付録Cを追加するためのキーフットプリント/タグは、その計算を指定します。一つはIXFR [RFC 1995]カバーしながら加えて、型AXFRを覆うSIGが除去された（セクション5.6を参照）が追加されました。
4. Algorithm 3, the DSA algorithm, is now designated as the mandatory to implement algorithm. Algorithm 1, the RSA/MD5 algorithm, is now a recommended option. Algorithm 2 and 4 are designated as the Diffie-Hellman key and elliptic cryptography algorithms respectively, all to be defined in separate documents. Algorithm code point 252 is designated to indicate "indirect" keys, to be defined in a separate document, where the actual key is elsewhere. Both the KEY and SIG RR definitions have been simplified by eliminating the "null" algorithm 253 as defined in [RFC 2065]. That algorithm had been included because at the time it was thought it might be useful in DNS dynamic update [RFC 2136]. It was in fact not so used and it is dropped to simplify DNS security. Howver, that algorithm number has been re-used to indicate private algorithms where a domain name specifies the algorithm.
4.アルゴリズム3、DSAアルゴリズムは、今のアルゴリズムを実装するために義務的に指定されています。アルゴリズム1、RSA / MD5アルゴリズムは、今お勧めのオプションです。アルゴリズム2と4はすべて、別個の文書で定義される、それぞれのDiffie-Hellman鍵と楕円暗号化アルゴリズムとして指定されます。アルゴリズム・コード・ポイント252は、実際のキーが他の場所で別の文書で定義される「間接」キーを示すために指定されています。両方のKEYとSIG RRの定義は、[RFC 2065]で定義されるように「NULL」アルゴリズム253を排除することによって簡略化されています。そのアルゴリズムがあるため、それがDNS動的更新[RFC 2136]で有用かもしれないと思った時に含まれていました。これは、実際にはそのように使用し、DNSのセキュリティを簡素化するために破棄されませんでした。 Howver、そのアルゴリズムの数は、ドメイン名は、アルゴリズムを指定する民間のアルゴリズムを示すために再使用されてきました。
5. The NXT RR has been changed so that (5a) the NXT RRs in a zone cover all names, including wildcards as literal names without expansion, except for glue address records whose names would not otherwise appear, (5b) all NXT bit map areas whose first octet has bit zero set have been reserved for future definition, (5c) the number of and circumstances under which an NXT must be returned in connection with wildcard names has been extended, and (5d) in connection with the bit map, references to the WKS RR have been removed and verticle bars ("|") have been added between the RR type mnemonics in the ASCII representation.
5. NXT RRゾーンのカバーで（5A）となるようNXT資源レコード名前がそうでなければ表示されない接着剤アドレスレコードを除いて膨張することなくリテラル名としてワイルドカードを含むすべての名前、（5B）は、すべてのNXTビットマップが変更されています領域その最初のオクテットのビットのゼロセットは、将来の定義のために予約されていた（図5c）NXTワイルドカード名に関連して返さなければならないの下の数や状況が拡張された、及び（5D）ビットマップに関連して、 WKS RRへの参照が削除され、垂直方向のバーは、（「|」）ASCII表現でのRRタイプニーモニックの間に追加されました。
6. Information on the canonical form and ordering of RRs has been moved into a separate Section 8.
RRの正規形式と順序6.情報は、別々のセクション8に移動されました。
7. A subsection covering incremental and full zone transfer has been added in Section 5.
7.増分と完全ゾーン転送をカバーするサブセクションは、セクション5で追加されています。
8. Concerning DNS chaining: Further specification and policy recommendations on secure resolution have been added, primarily in Section 6.3.1. It is now clearly stated that authenticated data has a validity period of the intersection of the validity periods of the SIG RRs in its authentication chain. The requirement to staticly configure a superzone's key signed by a zone in all of the zone's authoritative servers has been removed. The recommendation to continue DNS security checks in a secure island of DNS data that is separated from other parts of the DNS tree by insecure zones and does not contain a zone for which a key has been staticly configured was dropped.
DNS連鎖に関する8：セキュアな解像度に関するさらなる明細書及び政策提言は、主セクション6.3.1に、追加されています。今、明らかに認証されたデータは、その認証チェーンのSIG RRの有効期間の交差点の有効期間を持っていることが述べられています。静的にゾーンの権威のすべてのサーバーでゾーンが署名した上位ゾーンのキーを設定するための要件は削除されました。勧告は、安全でないゾーンでDNSツリーの他の部分から分離され、キーは静的に落とされたように構成されたゾーンが含まれていないDNSデータの安全な島でのDNSセキュリティチェックを続行します。
9. It was clarified that the presence of the AD bit in a response does not apply to the additional information section or to glue address or delegation point NS RRs. The AD bit only indicates that the answer and authority sections of the response are authoritative.
9.これは、応答のADビットの存在が追加情報セクションには適用されませんまたはアドレスまたは委任ポイントNSのRRを接着することが明らかになりました。 ADビットは、応答のみの答えと権威セクションは権威であることを示しています。
10. It is now required that KEY RRs and NXT RRs be signed only with zone-level keys.
10.今鍵資源レコードとNXT資源レコードのみゾーンレベルキーで署名する必要があります。
Appendix C: Key Tag Calculation
付録C：鍵タグ計算
The key tag field in the SIG RR is just a means of more efficiently selecting the correct KEY RR to use when there is more than one KEY RR candidate available, for example, in verifying a signature. It is possible for more than one candidate key to have the same tag, in which case each must be tried until one works or all fail. The following reference implementation of how to calculate the Key Tag, for all algorithms other than algorithm 1, is in ANSI C. It is coded for clarity, not efficiency. (See section 4.1.6 for how to determine the Key Tag of an algorithm 1 key.)
SIG RRにおける鍵タグフィールドは、より効率的に利用可能な複数のキーのRR候補がある場合、署名を検証するには、例えば、使用する正しいキーRRを選択するだけの手段です。複数の候補キーは1作品、またはすべてが失敗するまで、それぞれが試さなければならない場合には、同じタグを持つことが可能です。アルゴリズム1以外のすべてのアルゴリズムのために、鍵タグを計算する方法の次のリファレンス実装は、それが明瞭ではなく、効率のためにコード化されているANSI Cです。 （アルゴリズム1の鍵の鍵タグを決定する方法については、セクション4.1.6を参照してください。）
/* assumes int is at least 16 bits
first byte of the key tag is the most significant byte of return
value
second byte of the key tag is the least significant byte of
return value
*/
int keytag (
int型キータグ（
unsigned char key[], /* the RDATA part of the KEY RR */
unsigned int keysize, /* the RDLENGTH */
)
{
long int ac; /* assumed to be 32 bits or larger */
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i&1) ? key[i] : key[i]<<8;
ac += (ac>>16) & 0xFFFF;
return ac & 0xFFFF;
}
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。