Network Working Group R. Arends
Request for Comments: 4035 Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
3755, 3757, 3845 ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Category: Standards Track D. Massey
Colorado State University
S. Rose
NIST
March 2005
Protocol Modifications for the DNS 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.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.
このドキュメントは、DNSセキュリティ拡張機能（DNSSEC）を説明するドキュメントファミリの一部です。 DNSセキュリティ拡張機能は、DNSにデータ発信元認証とデータ整合性を追加する新しいリソースレコードとプロトコル変更のコレクションです。 このドキュメントでは、DNSSECプロトコルの変更について説明します。 このドキュメントでは、DNSSECを使用して処理および解決するための要件とともに、署名済みゾーンの概念を定義します。 これらの手法により、セキュリティ対応リゾルバは、DNSリソースレコードと信頼できるDNSエラー表示の両方を認証できます。
This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.
このドキュメントはRFC 2535を廃止し、RFC 2535へのすべての更新からの変更を組み込みます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Related Documents . . . . . . . . . . . . 4
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4
2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5
2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5
2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6
2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7
2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7
2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8
2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9
3.1.1. Including RRSIG RRs in a Response . . . . . . . 10
3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11
3.1.3. Including NSEC RRs in a Response . . . . . . . . 11
3.1.4. Including DS RRs in a Response . . . . . . . . . 14
3.1.5. Responding to Queries for Type AXFR or IXFR . . 15
3.1.6. The AD and CD Bits in an Authoritative Response. 16
3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17
3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17
3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17
3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18
3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Signature Verification Support . . . . . . . . . . . . . 19
4.3. Determining Security Status of Data . . . . . . . . . . 20
4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21
4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21
4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22
4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24
4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24
4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
5.1. Special Considerations for Islands of Security . . . . . 26
5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26
5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28
5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28
5.3.2. Reconstructing the Signed Data . . . . . . . . . 29
5.3.3. Checking the Signature . . . . . . . . . . . . . 31
5.3.4. Authenticating a Wildcard Expanded RRset
Positive Response. . . . . . . . . . . . . . . . 32
5.4. Authenticated Denial of Existence . . . . . . . . . . . 32
5.5. Resolver Behavior When Signatures Do Not Validate . . . 33
5.6. Authentication Example . . . . . . . . . . . . . . . . . 33
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 35
A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36
B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41
B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44
B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44
B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45
B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48
C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49
C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49
C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49
C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50
C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50
C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51
C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
The DNS Security Extensions (DNSSEC) are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document defines the DNSSEC protocol modifications. Section 2 of this document defines the concept of a signed zone and lists the requirements for zone signing. Section 3 describes the modifications to authoritative name server behavior necessary for handling signed zones. Section 4 describes the behavior of entities that include security-aware resolver functions. Finally, Section 5 defines how to use DNSSEC RRs to authenticate a response.
DNSセキュリティ拡張機能（DNSSEC）は、DNSにデータ発信元認証とデータ整合性を追加する新しいリソースレコードとプロトコル変更のコレクションです。 このドキュメントでは、DNSSECプロトコルの変更を定義しています。 このドキュメントのセクション2では、署名済みゾーンの概念を定義し、ゾーン署名の要件をリストしています。 セクション3では、署名済みゾーンの処理に必要な権限のあるネームサーバーの動作に対する変更について説明します。 セクション4では、セキュリティ対応リゾルバー機能を含むエンティティの動作について説明します。 最後に、セクション5では、DNSSEC RRを使用して応答を認証する方法を定義します。
This document is part of a family of documents defining DNSSEC that should be read together as a set.
このドキュメントは、DNSSECを定義する一連のドキュメントの一部であり、まとめて読む必要があります。
[RFC4033] contains an introduction to DNSSEC and definitions of common terms; the reader is assumed to be familiar with this document. [RFC4033] also contains a list of other documents updated by and obsoleted by this document set.
[RFC4033]には、DNSSECの紹介と一般的な用語の定義が含まれています。 読者はこのドキュメントに精通していると想定されます。 [RFC4033]には、このドキュメントセットによって更新され、廃止された他のドキュメントのリストも含まれています。
[RFC4034] defines the DNSSEC resource records.
[RFC4034]はDNSSECリソースレコードを定義します。
The reader is also assumed to be familiar with the basic DNS concepts described in [RFC1034], [RFC1035], and the subsequent documents that update them; particularly, [RFC2181] and [RFC2308].
また、読者は[RFC1034]、[RFC1035]で説明されている基本的なDNSの概念、およびそれらを更新する後続のドキュメントに精通していると想定されます。 特に、[RFC2181]および[RFC2308]。
This document defines the DNSSEC protocol operations.
このドキュメントは、DNSSECプロトコル操作を定義します。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は [RFC2119]で説明されているように解釈されます。
DNSSEC introduces the concept of signed zones. A signed zone includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), Next Secure (NSEC), and (optionally) Delegation Signer (DS) records according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4, respectively. A zone that does not include these records according to the rules in this section is an unsigned zone.
DNSSECは、署名済みゾーンの概念を導入しています。 署名済みゾーンには、セクション2.1、2.2、2.3、および2.4で指定されたルールに従って、DNS公開キー（DNSKEY）、リソースレコード署名（RRSIG）、Next Secure（NSEC）、および（オプションで）委任署名者（DS）レコードが含まれます。 それぞれ。 このセクションの規則に従ってこれらのレコードを含まないゾーンは、署名されていないゾーンです。
DNSSEC requires a change to the definition of the CNAME resource record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs to appear at the same owner name as does a CNAME RR.
DNSSECでは、CNAMEリソースレコード（[RFC1035]）の定義を変更する必要があります。 セクション2.5では、CNAME RRを変更して、RRSIGおよびNSEC RRをCNAME RRと同じ所有者名で表示できるようにします。
DNSSEC specifies the placement of two new RR types, NSEC and DS, which can be placed at the parental side of a zone cut (that is, at a delegation point). This is an exception to the general prohibition against putting data in the parent zone at a zone cut. Section 2.6 describes this change.
DNSSECは、ゾーンカットの親側（つまり、委任ポイント）に配置できる2つの新しいRRタイプ、NSECとDSの配置を指定します。 これは、ゾーンカットで親ゾーンにデータを配置することに対する一般的な禁止の例外です。 セクション2.6では、この変更について説明します。
To sign a zone, the zone's administrator generates one or more public/private key pairs and uses the private key(s) to sign authoritative RRsets in the zone. For each private key used to create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR containing the corresponding public key. A zone key DNSKEY RR MUST have the Zone Key bit of the flags RDATA field set (see Section 2.1.1 of [RFC4034]). Public keys associated with other DNS operations MAY be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT be used to verify RRSIGs.
ゾーンに署名するために、ゾーンの管理者は、1つ以上の公開/秘密キーペアを生成し、秘密キーを使用してゾーン内の信頼できるRRsetに署名します。 ゾーンでRRSIG RRを作成するために使用される各秘密キーについて、ゾーンは、対応する公開キーを含むゾーンDNSKEY RRを含める必要があります。 ゾーンキーDNSKEY RRには、フラグRDATAフィールドのゾーンキービットが設定されている必要があります（[RFC4034]のセクション2.1.1を参照）。 他のDNS操作に関連付けられた公開キーは、ゾーンキーとしてマークされていないDNSKEY RRに格納できますが、RRSIGの検証には使用してはなりません。
If the zone administrator intends a signed zone to be usable other than as an island of security, the zone apex MUST contain at least one DNSKEY RR to act as a secure entry point into the zone. This secure entry point could then be used as the target of a secure delegation via a corresponding DS RR in the parent zone (see [RFC4034]).
ゾーン管理者が、署名されたゾーンをセキュリティアイランドとして以外に使用できるようにする場合、ゾーンの頂点には、ゾーンへの安全なエントリポイントとして機能するDNSKEY RRが少なくとも1つ含まれている必要があります。 このセキュアエントリポイントは、親ゾーン内の対応するDS RRを介したセキュアな委任のターゲットとして使用できます（[RFC4034]を参照）。
For each authoritative RRset in a signed zone, there MUST be at least one RRSIG record that meets the following requirements:
署名済みゾーン内の各権限のあるRRsetには、次の要件を満たすRRSIGレコードが少なくとも1つ存在する必要があります。
o The RRSIG owner name is equal to the RRset owner name.
o RRSIGオーナーネームは、RRsetオーナーネームと同じです。
o The RRSIG class is equal to the RRset class.
o RRSIGクラスはRRsetクラスと同等です。
o The RRSIG Type Covered field is equal to the RRset type.
o RRSIG Type Coveredフィールドは、RRsetタイプと同じです。
o The RRSIG Original TTL field is equal to the TTL of the RRset.
o RRSIG Original TTLフィールドは、RRsetのTTLと同じです。
o The RRSIG RR's TTL is equal to the TTL of the RRset.
o RRSIG RRのTTLは、RRsetのTTLと等しい。
o The RRSIG Labels field is equal to the number of labels in the RRset owner name, not counting the null root label and not counting the leftmost label if it is a wildcard.
o RRSIGラベルフィールドは、RRset所有者名のラベル数と等しく、ヌルルートラベルをカウントせず、左端のラベルがワイルドカードの場合は左端のラベルをカウントしません。
o The RRSIG Signer's Name field is equal to the name of the zone containing the RRset.
o RRSIG署名者の名前フィールドは、RRsetを含むゾーンの名前と同じです。
o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a zone key DNSKEY record at the zone apex.
o RRSIGアルゴリズム、署名者名、およびキータグフィールドは、ゾーンの頂点にあるゾーンキーDNSKEYレコードを識別します。
The process for constructing the RRSIG RR for a given RRset is described in [RFC4034]. An RRset MAY have multiple RRSIG RRs associated with it. Note that as RRSIG RRs are closely tied to the RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
特定のRRsetのRRSIG RRを構築するプロセスは、[RFC4034]で説明されています。 RRsetには、複数のRRSIG RRが関連付けられている場合があります。 RRSIG RRは、他のすべてのDNSとは異なり、署名が含まれているRRset、RRSIG RRに密接に関連していることに注意してください。
RR types, do not form RRsets. In particular, the TTL values among RRSIG RRs with a common owner name do not follow the RRset rules described in [RFC2181].
RRタイプは、RRsetを形成しません。 特に、共通所有者名を持つRRSIG RRのTTL値は、[RFC2181]で説明されているRRsetルールに従いません。
An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would add no value and would create an infinite loop in the signing process.
RRSIG RRに署名しても値は追加されず、署名プロセスで無限ループが作成されるため、RRSIG RR自体に署名することはできません。
The NS RRset that appears at the zone apex name MUST be signed, but the NS RRsets that appear at delegation points (that is, the NS RRsets in the parent zone that delegate the name to the child zone's name servers) MUST NOT be signed. Glue address RRsets associated with delegations MUST NOT be signed.
ゾーンの頂点名に表示されるNS RRsetに署名する必要がありますが、委任ポイントに表示されるNS RRset（つまり、名前を子ゾーンのネームサーバーに委任する親ゾーン内のNS RRset）に署名することはできません。 委任に関連付けられたグルーアドレスRRsetに署名してはなりません。
There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any).
ゾーン頂点DNSKEY RRset内の各アルゴリズムの少なくとも1つのDNSKEYを使用して、各RRsetにRRSIGがなければなりません。 apex DNSKEY RRset自体は、委任する親（ある場合）にあるDS RRsetに現れる各アルゴリズムによって署名されなければなりません。
Each owner name in the zone that has authoritative data or a delegation point NS RRset MUST have an NSEC resource record. The format of NSEC RRs and the process for constructing the NSEC RR for a given name is described in [RFC4034].
権限のあるデータまたは委任ポイントNS RRsetを持つゾーン内の各所有者名には、NSECリソースレコードが必要です。 NSEC RRのフォーマットと、特定の名前のNSEC RRを構築するプロセスは、[RFC4034]で説明されています。
The TTL value for any NSEC RR SHOULD be the same as the minimum TTL value field in the zone SOA RR.
NSEC RRのTTL値は、ゾーンSOA RRの最小TTL値フィールドと同じである必要があります。
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not the owner name of any RRset before the zone was signed. The main reasons for this are a desire for namespace consistency between signed and unsigned versions of the same zone and a desire to reduce the risk of response inconsistency in security oblivious recursive name servers.
NSECレコード（および関連するRRSIG RRset）が、特定の所有者名の唯一のRRsetであってはなりません。 つまり、署名プロセスは、ゾーンが署名される前にRRsetの所有者名ではなかった所有者名ノードのNSECまたはRRSIG RRを作成してはなりません。 これの主な理由は、同じゾーンの署名付きバージョンと署名なしバージョン間の名前空間の一貫性の欲求と、セキュリティ忘却型再帰ネームサーバーでの応答の不一致のリスクを軽減したいことです。
The type bitmap of every NSEC resource record in a signed zone MUST indicate the presence of both the NSEC record itself and its corresponding RRSIG record.
署名済みゾーン内のすべてのNSECリソースレコードのタイプビットマップは、NSECレコード自体とそれに対応するRRSIGレコードの両方の存在を示さなければなりません。
The difference between the set of owner names that require RRSIG records and the set of owner names that require NSEC records is subtle and worth highlighting. RRSIG records are present at the owner names of all authoritative RRsets. NSEC records are present at the owner names of all names for which the signed zone is authoritative and also at the owner names of delegations from the signed zone to its children. Neither NSEC nor RRSIG records are present (in the parent zone) at the owner names of glue address RRsets. Note, however, that this distinction is for the most part visible only during the zone signing process, as NSEC RRsets are authoritative data and are therefore signed. Thus, any owner name that has an NSEC RRset will have RRSIG RRs as well in the signed zone.
RRSIGレコードを必要とする所有者名のセットとNSECレコードを必要とする所有者名のセットの違いは微妙であり、強調する価値があります。 RRSIGレコードは、すべての信頼できるRRsetの所有者名に存在します。 NSECレコードは、署名済みゾーンが権限を持つすべての名前の所有者名と、署名済みゾーンからその子への委任の所有者名に存在します。 グルーアドレスRRsetの所有者名には（親ゾーンに）NSECレコードもRRSIGレコードも存在しません。 ただし、NSEC RRsetは信頼できるデータであり、したがって署名されているため、この区別はゾーン署名プロセス中にのみほとんどの部分で表示されることに注意してください。 したがって、NSEC RRsetを持つ所有者名は、署名されたゾーンにもRRSIG RRを持ちます。
The bitmap for the NSEC RR at a delegation point requires special attention. Bits corresponding to the delegation NS RRset and any RRsets for which the parent zone has authoritative data MUST be set; bits corresponding to any non-NS RRset for which the parent is not authoritative MUST be clear.
委任ポイントでのNSEC RRのビットマップには、特別な注意が必要です。 委任NS RRsetおよび親ゾーンに信頼できるデータがあるRRsetに対応するビットを設定する必要があります。 親が信頼できない非NS RRsetに対応するビットは明確でなければなりません。
The DS resource record establishes authentication chains between DNS zones. A DS RRset SHOULD be present at a delegation point when the child zone is signed. The DS RRset MAY contain multiple records, each referencing a public key in the child zone used to verify the RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS RRsets MUST NOT appear at a zone's apex.
DSリソースレコードは、DNSゾーン間の認証チェーンを確立します。 子ゾーンに署名する場合、DS RRsetは委任ポイントに存在する必要があります。 DS RRsetには複数のレコードが含まれている場合があり、各レコードは、そのゾーンのRRSIGを検証するために使用される子ゾーンの公開鍵を参照します。 ゾーン内のすべてのDS RRsetに署名する必要があり、ゾーンの頂点にDS RRsetを表示してはなりません。
A DS RR SHOULD point to a DNSKEY RR that is present in the child's apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed by the corresponding private key. DS RRs that fail to meet these conditions are not useful for validation, but because the DS RR and its corresponding DNSKEY RR are in different zones, and because the DNS is only loosely consistent, temporary mismatches can occur.
DS RRは、子の頂点DNSKEY RRsetに存在するDNSKEY RRを指す必要があり（SHOULD）、子の頂点DNSKEY RRsetは対応する秘密鍵で署名される必要があります。 これらの条件を満たさないDS RRは検証には役立ちませんが、DS RRとそれに対応するDNSKEY RRは異なるゾーンにあり、DNSの整合性は緩やかであるため、一時的な不一致が発生する可能性があります。
The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset (that is, the NS RRset from the same zone containing the DS RRset).
DS RRsetのTTLは、委任NS RRset（つまり、DS RRsetを含む同じゾーンからのNS RRset）のTTLと一致する必要があります。
Construction of a DS RR requires knowledge of the corresponding DNSKEY RR in the child zone, which implies communication between the child and parent zones. This communication is an operational matter not covered by this document.
DS RRの構築には、子ゾーンの対応するDNSKEY RRの知識が必要です。これは、子ゾーンと親ゾーンの間の通信を意味します。 この通信は、このドキュメントで扱われていない運用上の問題です。
If a CNAME RRset is present at a name in a signed zone, appropriate RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that name for secure dynamic update purposes is also allowed ([RFC3007]). Other types MUST NOT be present at that name.
署名済みゾーンの名前にCNAME RRsetが存在する場合、その名前には適切なRRSIGおよびNSEC RRsetが必要です。 安全な動的更新を目的としたその名前のKEY RRsetも許可されています（[RFC3007]）。 他のタイプがその名前に存在してはなりません。
This is a modification to the original CNAME definition given in [RFC1034]. The original definition of the CNAME RR did not allow any other types to coexist with a CNAME record, but a signed zone requires NSEC and RRSIG RRs for every authoritative name. To resolve this conflict, this specification modifies the definition of the CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
これは、[RFC1034]で指定された元のCNAME定義の変更です。 CNAME RRの元の定義では、他のタイプをCNAMEレコードと共存させることはできませんでしたが、署名されたゾーンでは、すべての信頼できる名前にNSECおよびRRSIG RRが必要です。 この競合を解決するため、この仕様ではCNAMEリソースレコードの定義を変更して、NSECおよびRRSIG RRと共存できるようにします。
DNSSEC introduced two new RR types that are unusual in that they can appear at the parental side of a zone cut. At the parental side of a zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at the owner name. A DS RR could also be present if the zone being delegated is signed and seeks to have a chain of authentication to the parent zone. This is an exception to the original DNS specification ([RFC1034]), which states that only NS RRsets could appear at the parental side of a zone cut.
DNSSECは、ゾーンカットの親側に表示されるという点で珍しい2つの新しいRRタイプを導入しました。 ゾーンカットの親側（つまり、委任ポイント）では、所有者名でNSEC RRが必要です。 DS RRは、委任されるゾーンが署名され、親ゾーンへの認証チェーンを取得しようとする場合にも存在する可能性があります。 これは元のDNS仕様（[RFC1034]）の例外であり、NS RRsetのみがゾーンカットの親側に表示される可能性があると述べています。
This specification updates the original DNS specification to allow NSEC and DS RR types at the parent side of a zone cut. These RRsets are authoritative for the parent when they appear at the parent side of a zone cut.
この仕様は、ゾーンカットの親側でNSECおよびDS RRタイプを許可するために、元のDNS仕様を更新します。 これらのRRsetは、ゾーンカットの親側に表示される場合、親に対して権限があります。
Appendix A shows a complete example of a small signed zone.
付録Aは、小さな署名済みゾーンの完全な例を示しています。
This section describes the behavior of entities that include security-aware name server functions. In many cases such functions will be part of a security-aware recursive name server, but a security-aware authoritative name server has some of the same requirements. Functions specific to security-aware recursive name servers are described in Section 3.2; functions specific to authoritative servers are described in Section 3.1.
このセクションでは、セキュリティ対応のネームサーバー機能を含むエンティティの動作について説明します。 多くの場合、そのような関数はセキュリティ対応の再帰ネームサーバーの一部になりますが、セキュリティ対応の権限ネームサーバーには同じ要件がいくつかあります。 セキュリティ対応の再帰ネームサーバーに固有の機能については、セクション3.2で説明しています。 権限のあるサーバーに固有の機能については、セクション3.1で説明しています。
In the following discussion, the terms "SNAME", "SCLASS", and "STYPE" are as used in [RFC1034].
以下の説明では、「SNAME」、「SCLASS」、および「STYPE」という用語は[RFC1034]で使用されているとおりです。
A security-aware name server MUST support the EDNS0 ([RFC2671]) message size extension, MUST support a message size of at least 1220 octets, and SHOULD support a message size of 4000 octets. As IPv6 packets can only be fragmented by the source host, a security aware name server SHOULD take steps to ensure that UDP datagrams it transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460], and [RFC3226] for further discussion of packet size and fragmentation issues.
セキュリティ対応のネームサーバーは、EDNS0（[RFC2671]）メッセージサイズ拡張をサポートしなければならず、少なくとも1220オクテットのメッセージサイズをサポートしなければならず、4000オクテットのメッセージサイズをサポートする必要があります。 IPv6パケットはソースホストによってのみフラグメント化できるため、セキュリティ対応のネームサーバーは、パスMTUが不明な場合を除き、必要に応じて、IPv6を介して送信するUDPデータグラムが必要に応じて最小IPv6 MTUでフラグメント化されるように対策を講じる必要があります。 パケットサイズとフラグメンテーションの問題の詳細については、[RFC1122]、[RFC2460]、および[RFC3226]を参照してください。
A security-aware name server that receives a DNS query that does not include the EDNS OPT pseudo-RR or that has the DO bit clear MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and MUST NOT perform any of the additional processing described below. Because the DS RR type has the peculiar property of only existing in the parent zone at delegation points, DS RRs always require some special processing, as described in Section 3.1.4.1.
EDNS OPT疑似RRを含まない、またはDOビットがクリアされているDNSクエリを受信するセキュリティ対応のネームサーバーは、RRSIG、DNSKEY、およびNSEC RRを他のRRsetと同様に扱わなければならず、 以下に説明する追加処理。 DS RRタイプには、委任ポイントの親ゾーンにのみ存在する固有のプロパティがあるため、セクション3.1.4.1で説明されているように、DS RRには常に特別な処理が必要です。
Security aware name servers that receive explicit queries for security RR types that match the content of more than one zone that it serves (for example, NSEC and RRSIG RRs above and below a delegation point where the server is authoritative for both zones) should behave self-consistently. As long as the response is always consistent for each query to the name server, the name server MAY return one of the following:
サービスを提供する複数のゾーンのコンテンツに一致するセキュリティRRタイプの明示的なクエリを受信するセキュリティ対応ネームサーバー（たとえば、サーバーが両方のゾーンに対して権限を持つ委任ポイントの上下のNSECおよびRRSIG RR）は、自己動作する必要があります -一貫して。 ネームサーバーへのクエリごとに応答が常に一貫している限り、ネームサーバーは次のいずれかを返す場合があります。
o The above-delegation RRsets. o The below-delegation RRsets. o Both above and below-delegation RRsets. o Empty answer section (no records). o Some other response. o An error.
o上記の委任RRset。 o委任以下のRRset。 o委任より上と下の両方のRRset。 o空の回答セクション（記録なし）。 oその他の応答。 oエラー。
DNSSEC allocates two new bits in the DNS message header: the CD (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit is controlled by resolvers; a security-aware name server MUST copy the CD bit from a query into the corresponding response. The AD bit is controlled by name servers; a security-aware name server MUST ignore the setting of the AD bit in queries. See Sections 3.1.6, 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
DNSSECは、DNSメッセージヘッダーに2つの新しいビットを割り当てます。CD（Checking Disabled）ビットとAD（Authentic Data）ビットです。 CDビットはリゾルバによって制御されます。 セキュリティ対応のネームサーバーは、CDビットをクエリから対応する応答にコピーする必要があります。 ADビットはネームサーバーによって制御されます。 セキュリティ対応のネームサーバーは、クエリのADビットの設定を無視する必要があります。 これらのビットの動作の詳細については、セクション3.1.6、3.2.2、3.2.3、4、および4.9を参照してください。
A security aware name server that synthesizes CNAME RRs from DNAME RRs as described in [RFC2672] SHOULD NOT generate signatures for the synthesized CNAME RRs.
[RFC2672]で説明されているようにDNAME RRからCNAME RRを合成するセキュリティ対応ネームサーバーは、合成されたCNAME RRの署名を生成すべきではありません。
Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name server for a signed zone MUST include additional RRSIG, NSEC, and DS RRs, according to the following rules:
EDNS（[RFC2671]）OPT擬似RR DOビット（[RFC3225]）が設定された関連クエリを受信すると、署名済みゾーンのセキュリティ対応の権限ネームサーバーは、追加のRRSIG、NSEC、およびDS RRを含める必要があります。 次のルールに：
o RRSIG RRs that can be used to authenticate a response MUST be included in the response according to the rules in Section 3.1.1.
o応答の認証に使用できるRRSIG RRは、セクション3.1.1の規則に従って応答に含まれなければならない（MUST）。
o NSEC RRs that can be used to provide authenticated denial of existence MUST be included in the response automatically according to the rules in Section 3.1.3.
o認証された存在の否定を提供するために使用できるNSEC RRは、セクション3.1.3の規則に従って自動的に応答に含まれなければならない（MUST）。
o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST be included in referrals automatically according to the rules in Section 3.1.4.
o DS RRsetまたはDS RRが存在しないことを証明するNSEC RRのいずれかが、セクション3.1.4の規則に従って自動的に紹介に含まれなければなりません。
These rules only apply to responses where the semantics convey information about the presence or absence of resource records. That is, these rules are not intended to rule out responses such as RCODE 4 ("Not Implemented") or RCODE 5 ("Refused").
これらの規則は、セマンティクスがリソースレコードの有無に関する情報を伝える応答にのみ適用されます。 つまり、これらのルールは、RCODE 4（「実装されていない」）やRCODE 5（「拒否された」）などの応答を除外することを目的としていません。
DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 discusses zone transfer requirements.
DNSSECは、DNSゾーン転送プロトコルを変更しません。 セクション3.1.5では、ゾーン転送の要件について説明します。
When responding to a query that has the DO bit set, a security-aware authoritative name server SHOULD attempt to send RRSIG RRs that a security-aware resolver can use to authenticate the RRsets in the response. A name server SHOULD make every attempt to keep the RRset and its associated RRSIG(s) together in a response. Inclusion of RRSIG RRs in a response is subject to the following rules:
DOビットが設定されたクエリに応答する場合、セキュリティ対応の権限ネームサーバーは、セキュリティ対応リゾルバが応答内のRRsetを認証するために使用できるRRSIG RRを送信しようとする必要があります。 ネームサーバーは、RRsetとそれに関連するRRSIGを1つの応答として保持するためのあらゆる試みを行う必要があります。 応答にRRSIG RRを含めるには、次の規則が適用されます。
o When placing a signed RRset in the Answer section, the name server MUST also place its RRSIG RRs in the Answer section. The RRSIG RRs have a higher priority for inclusion than any other RRsets that may have to be included. If space does not permit inclusion of these RRSIG RRs, the name server MUST set the TC bit.
o署名済みRRsetをAnswerセクションに配置する場合、ネームサーバーは、RRSIG RRもAnswerセクションに配置する必要があります。 RRSIG RRは、含める必要のある他のRRsetよりも含める優先度が高くなります。 スペースがこれらのRRSIG RRの包含を許可しない場合、ネームサーバーはTCビットを設定しなければなりません。
o When placing a signed RRset in the Authority section, the name server MUST also place its RRSIG RRs in the Authority section. The RRSIG RRs have a higher priority for inclusion than any other RRsets that may have to be included. If space does not permit inclusion of these RRSIG RRs, the name server MUST set the TC bit.
o署名済みRRsetをAuthorityセクションに配置する場合、ネームサーバーは、RRSIG RRもAuthorityセクションに配置する必要があります。 RRSIG RRは、含める必要のある他のRRsetよりも含める優先度が高くなります。 スペースがこれらのRRSIG RRの包含を許可しない場合、ネームサーバーはTCビットを設定しなければなりません。
o When placing a signed RRset in the Additional section, the name server MUST also place its RRSIG RRs in the Additional section. If space does not permit inclusion of both the RRset and its associated RRSIG RRs, the name server MAY retain the RRset while dropping the RRSIG RRs. If this happens, the name server MUST NOT set the TC bit solely because these RRSIG RRs didn't fit.
o署名付きRRsetを追加セクションに配置する場合、ネームサーバーは、RRSIG RRも追加セクションに配置する必要があります。 RRsetとそれに関連するRRSIG RRの両方を含めることがスペースで許可されていない場合、ネームサーバーはRRsetを保持しながら、RRSIG RRをドロップしてもよい（MAY）。 これが発生した場合、これらのRRSIG RRが適合しなかったという理由だけで、ネームサーバーはTCビットを設定してはなりません。
When responding to a query that has the DO bit set and that requests the SOA or NS RRs at the apex of a signed zone, a security-aware authoritative name server for that zone MAY return the zone apex DNSKEY RRset in the Additional section. In this situation, the DNSKEY RRset and associated RRSIG RRs have lower priority than does any other information that would be placed in the additional section. The name server SHOULD NOT include the DNSKEY RRset unless there is enough space in the response message for both the DNSKEY RRset and its associated RRSIG RR(s). If there is not enough space to include these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST NOT set the TC bit solely because these RRs didn't fit (see Section 3.1.1).
DOビットが設定され、署名されたゾーンの頂点でSOAまたはNS RRを要求するクエリに応答する場合、そのゾーンのセキュリティ対応の権限のあるネームサーバーは、追加セクションでゾーンの頂点DNSKEY RRsetを返す場合があります。 この状況では、DNSKEY RRsetおよび関連するRRSIG RRの優先順位は、追加セクションに配置される他の情報よりも低くなります。 ネームサーバーは、DNSKEY RRsetとそれに関連するRRSIG RRの両方の応答メッセージに十分なスペースがない限り、DNSKEY RRsetを含めるべきではありません。 これらのDNSKEYおよびRRSIG RRを含めるのに十分なスペースがない場合、ネームサーバーはそれらを省略しなければならず、これらのRRが適合しなかったという理由だけでTCビットを設定してはなりません（セクション3.1.1を参照）。
When responding to a query that has the DO bit set, a security-aware authoritative name server for a signed zone MUST include NSEC RRs in each of the following cases:
DOビットが設定されているクエリに応答する場合、署名されたゾーンのセキュリティ対応の権限ネームサーバーは、次の各ケースにNSEC RRを含める必要があります。
No Data: The zone contains RRsets that exactly match <SNAME, SCLASS> but does not contain any RRsets that exactly match <SNAME, SCLASS, STYPE>.
データなし：ゾーンには、<SNAME、SCLASS>に完全に一致するRRsetが含まれますが、<SNAME、SCLASS、STYPE>に完全に一致するRRsetは含まれません。
Name Error: The zone does not contain any RRsets that match <SNAME, SCLASS> either exactly or via wildcard name expansion.
名前エラー：ゾーンには、<SNAME、SCLASS>に完全に一致するか、ワイルドカード名展開によって一致するRRsetが含まれていません。
Wildcard Answer: The zone does not contain any RRsets that exactly match <SNAME, SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE> via wildcard name expansion.
ワイルドカード回答：ゾーンには、<SNAME、SCLASS>に完全に一致するRRsetは含まれませんが、ワイルドカード名の展開により<SNAME、SCLASS、STYPE>に一致するRRsetが含まれます。
Wildcard No Data: The zone does not contain any RRsets that exactly match <SNAME, SCLASS> and does contain one or more RRsets that match <SNAME, SCLASS> via wildcard name expansion, but does not contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name expansion.
ワイルドカードデータなし：ゾーンには、<SNAME、SCLASS>に完全に一致するRRsetが含まれておらず、ワイルドカード名展開によって<SNAME、SCLASS>に一致する1つ以上のRRsetが含まれますが、<SNAME、SCLASSに一致するRRsetは含まれません 、STYPE>をワイルドカード名展開で。
In each of these cases, the name server includes NSEC RRs in the response to prove that an exact match for <SNAME, SCLASS, STYPE> was not present in the zone and that the response that the name server is returning is correct given the data in the zone.
これらの各ケースで、ネームサーバーは、応答にNSEC RRを含めて、<SNAME、SCLASS、STYPE>の完全一致がゾーンに存在せず、ネームサーバーが返す応答がデータに対して正しいことを証明します。 ゾーン内。
If the zone contains RRsets matching <SNAME, SCLASS> but contains no RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST include the NSEC RR for <SNAME, SCLASS> along with its associated RRSIG RR(s) in the Authority section of the response (see Section 3.1.1). If space does not permit inclusion of the NSEC RR or its associated RRSIG RR(s), the name server MUST set the TC bit (see Section 3.1.1).
ゾーンに<SNAME、SCLASS>に一致するRRsetが含まれているが<SNAME、SCLASS、STYPE>に一致するRRsetが含まれていない場合、ネームサーバーは<SNAME、SCLASS>のNSEC RRを、関連するRRSIG RRとともに含める必要があります。 応答の権限セクション（セクション3.1.1を参照）。 スペースがNSEC RRまたはそれに関連するRRSIG RRの包含を許可しない場合、ネームサーバーはTCビットを設定しなければなりません（セクション3.1.1を参照）。
Since the search name exists, wildcard name expansion does not apply to this query, and a single signed NSEC RR suffices to prove that the requested RR type does not exist.
検索名が存在するため、ワイルドカード名の展開はこのクエリには適用されず、単一の署名済みNSEC RRで十分であり、要求されたRRタイプが存在しないことを証明できます。
If the zone does not contain any RRsets matching <SNAME, SCLASS> either exactly or via wildcard name expansion, then the name server MUST include the following NSEC RRs in the Authority section, along with their associated RRSIG RRs:
ゾーンに<SNAME、SCLASS>に一致するRRsetがまったく含まれていないか、ワイルドカード名展開を介して含まれていない場合、ネームサーバーは関連するRRSIG RRと共に機関セクションに次のNSEC RRを含める必要があります。
o An NSEC RR proving that there is no exact match for <SNAME, SCLASS>.
o <NAME、S CLASS>に完全に一致するものがないことを証明するNSEC RR。
o An NSEC RR proving that the zone contains no RRsets that would match <SNAME, SCLASS> via wildcard name expansion.
oワイルドカード名の展開により<SNAME、SCLASS>に一致するRRsetがゾーンに含まれていないことを証明するNSEC RR。
In some cases, a single NSEC RR may prove both of these points. If it does, the name server SHOULD only include the NSEC RR and its RRSIG RR(s) once in the Authority section.
場合によっては、単一のNSEC RRがこれらのポイントの両方を証明する場合があります。 存在する場合、ネームサーバーは機関セクションにNSEC RRとそのRRSIG RRを1回だけ含める必要があります。
If space does not permit inclusion of these NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1).
これらのNSECおよびRRSIG RRを含めることがスペースで許可されていない場合、ネームサーバーはTCビットを設定しなければなりません（セクション3.1.1を参照）。
The owner names of these NSEC and RRSIG RRs are not subject to wildcard name expansion when these RRs are included in the Authority section of the response.
これらのRRが応答のAuthorityセクションに含まれている場合、これらのNSECおよびRRSIG RRの所有者名はワイルドカード名の拡張の対象になりません。
Note that this form of response includes cases in which SNAME corresponds to an empty non-terminal name within the zone (a name that is not the owner name for any RRset but that is the parent name of one or more RRsets).
この形式の応答には、SNAMEがゾーン内の空の非端末名（RRsetの所有者名ではなく、1つ以上のRRsetの親名）に対応する場合が含まれることに注意してください。
If the zone does not contain any RRsets that exactly match <SNAME, SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE> via wildcard name expansion, the name server MUST include the wildcard-expanded answer and the corresponding wildcard-expanded RRSIG RRs in the Answer section and MUST include in the Authority section an NSEC RR and associated RRSIG RR(s) proving that the zone does not contain a closer match for <SNAME, SCLASS>. If space does not permit inclusion of the answer, NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1).
ゾーンに<SNAME、SCLASS>に完全に一致するRRsetが含まれていないが、ワイルドカード名展開を介して<SNAME、SCLASS、STYPE>に一致するRRsetが含まれている場合、ネームサーバーはワイルドカード展開された回答と対応するワイルドカード- AnswerセクションのRRSIG RRを拡張し、NSEC RRおよび関連するRRSIG RRをAuthorityセクションに含める必要があります。これは、ゾーンに<SNAME、SCLASS>のより近い一致が含まれていないことを証明します。 スペースが回答、NSEC、RRSIG RRの包含を許可しない場合、ネームサーバーはTCビットを設定しなければなりません（セクション3.1.1を参照）。
This case is a combination of the previous cases. The zone does not contain an exact match for <SNAME, SCLASS>, and although the zone does contain RRsets that match <SNAME, SCLASS> via wildcard expansion, none of those RRsets matches STYPE. The name server MUST include the following NSEC RRs in the Authority section, along with their associated RRSIG RRs:
このケースは、前のケースの組み合わせです。 ゾーンには<SNAME、SCLASS>に完全に一致するものは含まれず、ゾーンにはワイルドカード拡張を介して<SNAME、SCLASS>に一致するRRsetが含まれますが、これらのRRsetはSTYPEに一致しません。 ネームサーバーは、関連するRRSIG RRとともに、以下のNSEC RRをAuthorityセクションに含める必要があります。
o An NSEC RR proving that there are no RRsets matching STYPE at the wildcard owner name that matched <SNAME, SCLASS> via wildcard expansion.
oワイルドカード拡張により<SNAME、SCLASS>に一致したワイルドカード所有者名にSTYPEに一致するRRsetがないことを証明するNSEC RR。
o An NSEC RR proving that there are no RRsets in the zone that would have been a closer match for <SNAME, SCLASS>.
o <SNAME、SCLASS>によりよく一致するRRsetがゾーンにないことを証明するNSEC RR。
In some cases, a single NSEC RR may prove both of these points. If it does, the name server SHOULD only include the NSEC RR and its RRSIG RR(s) once in the Authority section.
場合によっては、単一のNSEC RRがこれらのポイントの両方を証明する場合があります。 存在する場合、ネームサーバーは機関セクションにNSEC RRとそのRRSIG RRを1回だけ含める必要があります。
The owner names of these NSEC and RRSIG RRs are not subject to wildcard name expansion when these RRs are included in the Authority section of the response.
これらのRRが応答のAuthorityセクションに含まれている場合、これらのNSECおよびRRSIG RRの所有者名はワイルドカード名の拡張の対象になりません。
If space does not permit inclusion of these NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1).
これらのNSECおよびRRSIG RRを含めることがスペースで許可されていない場合、ネームサーバーはTCビットを設定しなければなりません（セクション3.1.1を参照）。
As explained above, there are several situations in which a security-aware authoritative name server has to locate an NSEC RR that proves that no RRsets matching a particular SNAME exist. Locating such an NSEC RR within an authoritative zone is relatively simple, at least in concept. The following discussion assumes that the name server is authoritative for the zone that would have held the non-existent RRsets matching SNAME. The algorithm below is written for clarity, not for efficiency.
上で説明したように、特定のSNAMEに一致するRRsetが存在しないことを証明するNSEC RRをセキュリティ対応の権威ネームサーバーが見つけなければならない状況がいくつかあります。 このようなNSEC RRを信頼できるゾーン内に配置することは、少なくとも概念的には比較的簡単です。 次の説明では、ネームサーバーが、SNAMEに一致する存在しないRRsetを保持しているゾーンに対して権限があると想定しています。 以下のアルゴリズムは、効率のためではなく、明確にするために書かれています。
To find the NSEC that proves that no RRsets matching name N exist in the zone Z that would have held them, construct a sequence, S, consisting of the owner names of every RRset in Z, sorted into canonical order ([RFC4034]), with no duplicate names. Find the name M that would have immediately preceded N in S if any RRsets with owner name N had existed. M is the owner name of the NSEC RR that proves that no RRsets exist with owner name N.
名前Nに一致するRRsetがゾーンZに存在しないことを証明するNSECを見つけるには、ZのすべてのRRsetの所有者名で構成されるシーケンスSを作成し、正規の順序（[RFC4034]）にソートします。 重複する名前はありません。 所有者名NのRRsetが存在した場合、SのNの直前にある名前Mを見つけます。 Mは、NSEC RRの所有者名であり、所有者名NのRRsetが存在しないことを証明します。
The algorithm for finding the NSEC RR that proves that a given name is not covered by any applicable wildcard is similar but requires an extra step. More precisely, the algorithm for finding the NSEC proving that no RRsets exist with the applicable wildcard name is precisely the same as the algorithm for finding the NSEC RR that proves that RRsets with any other owner name do not exist. The part that's missing is a method of determining the name of the non-existent applicable wildcard. In practice, this is easy, because the authoritative name server has already checked for the presence of precisely this wildcard name as part of step (1)(c) of the normal lookup algorithm described in Section 4.3.2 of [RFC1034].
特定の名前が適用可能なワイルドカードでカバーされていないことを証明するNSEC RRを見つけるアルゴリズムは似ていますが、追加の手順が必要です。 より正確には、該当するワイルドカード名を持つRRsetが存在しないことを証明するNSECを見つけるためのアルゴリズムは、他の所有者名を持つRRsetが存在しないことを証明するNSEC RRを見つけるためのアルゴリズムとまったく同じです。 欠落している部分は、存在しない適用可能なワイルドカードの名前を決定する方法です。 実際には、権限のあるネームサーバーは、[RFC1034]のセクション4.3.2で説明されている通常のルックアップアルゴリズムのステップ（1）（c）の一部として、このワイルドカード名の存在を既にチェックしているため、これは簡単です。
When responding to a query that has the DO bit set, a security-aware authoritative name server returning a referral includes DNSSEC data along with the NS RRset.
DOビットが設定されたクエリに応答する場合、照会を返すセキュリティ対応の権限ネームサーバーには、NSSEC RRsetとともにDNSSECデータが含まれます。
If a DS RRset is present at the delegation point, the name server MUST return both the DS RRset and its associated RRSIG RR(s) in the Authority section along with the NS RRset.
DS RRsetが委任ポイントに存在する場合、ネームサーバーは、DS RRsetとNS RRsetと共にAuthorityセクションの関連するRRSIG RRの両方を返さなければなりません（MUST）。
If no DS RRset is present at the delegation point, the name server MUST return both the NSEC RR that proves that the DS RRset is not present and the NSEC RR's associated RRSIG RR(s) along with the NS RRset. The name server MUST place the NS RRset before the NSEC RRset and its associated RRSIG RR(s).
DS RRsetが委任ポイントに存在しない場合、ネームサーバーは、DS RRsetが存在しないことを証明するNSEC RRと、NS RRsetとともにNSEC RRの関連RRSIG RRの両方を返さなければなりません。 ネームサーバーは、NSEC RRsetおよび関連するRRSIG RRの前にNS RRsetを配置する必要があります。
Including these DS, NSEC, and RRSIG RRs increases the size of referral messages and may cause some or all glue RRs to be omitted. If space does not permit inclusion of the DS or NSEC RRset and associated RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1).
これらのDS、NSEC、およびRRSIG RRを含めると、参照メッセージのサイズが大きくなり、一部またはすべてのグルーRRが省略される場合があります。 スペースがDSまたはNSEC RRsetおよび関連するRRSIG RRの包含を許可しない場合、ネームサーバーはTCビットを設定しなければなりません（セクション3.1.1を参照）。
The DS resource record type is unusual in that it appears only on the parent zone's side of a zone cut. For example, the DS RRset for the delegation of "foo.example" is stored in the "example" zone rather than in the "foo.example" zone. This requires special processing rules for both name servers and resolvers, as the name server for the child zone is authoritative for the name at the zone cut by the normal DNS rules but the child zone does not contain the DS RRset.
DSリソースレコードタイプは、ゾーンカットの親ゾーンの側にのみ表示されるという点で異常です。 たとえば、「foo.example」の委任のDS RRsetは、「foo.example」ゾーンではなく「example」ゾーンに保存されます。 子ゾーンのネームサーバーは、通常のDNSルールによってカットされたゾーンの名前に対して権限がありますが、子ゾーンにはDS RRsetが含まれていないため、ネームサーバーとリゾルバーの両方に特別な処理ルールが必要です。
A security-aware resolver sends queries to the parent zone when looking for a needed DS RR at a delegation point (see Section 4.2). However, special rules are necessary to avoid confusing security-oblivious resolvers which might become involved in processing such a query (for example, in a network configuration that forces a security-aware resolver to channel its queries through a security-oblivious recursive name server). The rest of this section describes how a security-aware name server processes DS queries in order to avoid this problem.
セキュリティ対応リゾルバは、委任ポイントで必要なDS RRを探すときに、親ゾーンにクエリを送信します（セクション4.2を参照）。 ただし、このようなクエリの処理に関与する可能性のあるセキュリティを意識しないリゾルバの混乱を避けるために、特別なルールが必要です（たとえば、セキュリティを意識するリゾルバがセキュリティを意識しない再帰ネームサーバーを介してクエリをチャネルするように強制するネットワーク構成で） 。 このセクションの残りの部分では、この問題を回避するために、セキュリティ対応ネームサーバーがDSクエリを処理する方法について説明します。
The need for special processing by a security-aware name server only arises when all the following conditions are met:
セキュリティ対応のネームサーバーによる特別な処理の必要性は、次のすべての条件が満たされた場合にのみ発生します。
o The name server has received a query for the DS RRset at a zone cut.
oネームサーバーは、ゾーンカットでDS RRsetのクエリを受信しました。
o The name server is authoritative for the child zone.
oネームサーバーは、子ゾーンに対して権限があります。
o The name server is not authoritative for the parent zone.
oネームサーバーは、親ゾーンに対して権限がありません。
o The name server does not offer recursion.
oネームサーバーは再帰を提供しません。
In all other cases, the name server either has some way of obtaining the DS RRset or could not have been expected to have the DS RRset even by the pre-DNSSEC processing rules, so the name server can return either the DS RRset or an error response according to the normal processing rules.
他のすべての場合、ネームサーバーはDS RRsetを取得する何らかの方法を持っているか、DNSSEC以前の処理ルールによってもDS RRsetを持つことを期待できなかったため、ネームサーバーはDS RRsetまたはエラーを返すことができます 通常の処理ルールに従った応答。
If all the above conditions are met, however, the name server is authoritative for SNAME but cannot supply the requested RRset. In this case, the name server MUST return an authoritative "no data" response showing that the DS RRset does not exist in the child zone's apex. See Appendix B.8 for an example of such a response.
ただし、上記のすべての条件が満たされている場合、ネームサーバーはSNAMEに対して権限がありますが、要求されたRRsetを提供できません。 この場合、ネームサーバーは、DS RRsetが子ゾーンの頂点に存在しないことを示す信頼できる「データなし」応答を返さなければなりません。 そのような応答の例については、付録B.8を参照してください。
DNSSEC does not change the DNS zone transfer process. A signed zone will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these records have no special meaning with respect to a zone transfer operation.
DNSSECは、DNSゾーン転送プロセスを変更しません。 署名済みゾーンにはRRSIG、DNSKEY、NSEC、およびDSリソースレコードが含まれますが、これらのレコードにはゾーン転送操作に関して特別な意味はありません。
An authoritative name server is not required to verify that a zone is properly signed before sending or accepting a zone transfer. However, an authoritative name server MAY choose to reject the entire zone transfer if the zone fails to meet any of the signing requirements described in Section 2. The primary objective of a zone transfer is to ensure that all authoritative name servers have identical copies of the zone. An authoritative name server that chooses to perform its own zone validation MUST NOT selectively reject some RRs and accept others.
権限のあるネームサーバーは、ゾーン転送を送信または受け入れる前に、ゾーンが適切に署名されていることを確認する必要はありません。 ただし、権限のあるネームサーバーは、ゾーンがセクション2で説明されている署名要件のいずれかを満たさない場合、ゾーン全体の転送を拒否することを選択できます。ゾーン転送の主な目的は、 ゾーン。 独自のゾーン検証を実行することを選択する権限のあるネームサーバーは、一部のRRを選択的に拒否し、他のRRを受け入れてはなりません。
DS RRsets appear only on the parental side of a zone cut and are authoritative data in the parent zone. As with any other authoritative RRset, the DS RRset MUST be included in zone transfers of the zone in which the RRset is authoritative data. In the case of the DS RRset, this is the parent zone.
DS RRsetは、ゾーンカットの親側にのみ表示され、親ゾーンの信頼できるデータです。 他の信頼できるRRsetと同様に、RRsetが信頼できるデータであるゾーンのゾーン転送にDS RRsetを含める必要があります。 DS RRsetの場合、これは親ゾーンです。
NSEC RRs appear in both the parent and child zones at a zone cut and are authoritative data in both the parent and child zones. The parental and child NSEC RRs at a zone cut are never identical to each other, as the NSEC RR in the child zone's apex will always indicate the presence of the child zone's SOA RR whereas the parental NSEC RR at the zone cut will never indicate the presence of an SOA RR. As with any other authoritative RRs, NSEC RRs MUST be included in zone transfers of the zone in which they are authoritative data. The parental NSEC RR at a zone cut MUST be included in zone transfers of the parent zone, and the NSEC at the zone apex of the child zone MUST be included in zone transfers of the child zone.
NSEC RRは、ゾーンカットの親ゾーンと子ゾーンの両方に表示され、親ゾーンと子ゾーンの両方の信頼できるデータです。 ゾーンカットの親と子のNSEC RRは、決して同じではありません。子ゾーンの頂点のNSEC RRは常に子ゾーンのSOA RRの存在を示すのに対し、ゾーンカットの親のNSEC RRは、 SOA RRの存在。 他の信頼できるRRと同様に、NSEC RRは、それらが信頼できるデータであるゾーンのゾーン転送に含まれなければなりません。 ゾーンカットの親NSEC RRは、親ゾーンのゾーン転送に含まれなければならず、子ゾーンのゾーン頂点のNSECは、子ゾーンのゾーン転送に含まれなければなりません。
RRSIG RRs appear in both the parent and child zones at a zone cut and are authoritative in whichever zone contains the authoritative RRset for which the RRSIG RR provides the signature. That is, the RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be authoritative in the parent zone, and the RRSIG for any RRset in the child zone's apex will be authoritative in the child zone. Parental and child RRSIG RRs at a zone cut will never be identical to each other, as the Signer's Name field of an RRSIG RR in the child zone's apex will indicate a DNSKEY RR in the child zone's apex whereas the same field of a parental RRSIG RR at the zone cut will indicate a DNSKEY RR in the parent zone's apex. As with any other authoritative RRs, RRSIG RRs MUST be included in zone transfers of the zone in which they are authoritative data.
RRSIG RRは、ゾーンカットの親ゾーンと子ゾーンの両方に表示され、RRSIG RRが署名を提供する権限のあるRRsetを含むゾーンで権限があります。 つまり、ゾーンカットでのDS RRsetまたは親NSEC RRのRRSIG RRは親ゾーンで権限を持ち、子ゾーンの頂点にあるRRsetのRRSIGは子ゾーンで権限を持ちます。 子ゾーンの頂点のRRSIG RRの署名者の名前フィールドは、子ゾーンの頂点のDNSKEY RRを示すのに対し、親RRSIG RRの同じフィールドは、ゾーンカットの親と子のRRSIG RRが互いに同一になることはありません。 ゾーンカットでは、親ゾーンの頂点にDNSKEY RRが示されます。 他の信頼できるRRと同様に、RRSIG RRは、それらが信頼できるデータであるゾーンのゾーン転送に含まれなければなりません。
The CD and AD bits are designed for use in communication between security-aware resolvers and security-aware recursive name servers. These bits are for the most part not relevant to query processing by security-aware authoritative name servers.
CDおよびADビットは、セキュリティ対応リゾルバとセキュリティ対応再帰ネームサーバー間の通信で使用するために設計されています。 これらのビットの大部分は、セキュリティ対応の権限のあるネームサーバーによるクエリ処理には関係ありません。
A security-aware name server does not perform signature validation for authoritative data during query processing, even when the CD bit is clear. A security-aware name server SHOULD clear the CD bit when composing an authoritative response.
セキュリティ対応のネームサーバーは、CDビットがクリアされている場合でも、クエリ処理中に信頼できるデータの署名検証を実行しません。 セキュリティ対応のネームサーバーは、信頼できる応答を作成するときにCDビットをクリアする必要があります。
A security-aware name server MUST NOT set the AD bit in a response unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic. A security-aware name server's local policy MAY consider data from an authoritative zone to be authentic without further validation. However, the name server MUST NOT do so unless the name server obtained the authoritative zone via secure means (such as a secure zone transfer mechanism) and MUST NOT do so unless this behavior has been configured explicitly.
セキュリティ対応のネームサーバーは、ネームサーバーが応答のAnswerセクションとAuthorityセクションのすべてのRRsetを本物と見なさない限り、応答にADビットを設定してはなりません。 セキュリティ対応のネームサーバーのローカルポリシーは、権限のあるゾーンからのデータを、さらに検証することなく本物であると見なしてもよい（MAY）。 ただし、ネームサーバーがセキュアな手段（セキュアゾーン転送メカニズムなど）を介して権限ゾーンを取得しない限り、ネームサーバーはそうしてはならず、この動作が明示的に構成されていない限りそうしてはなりません。
A security-aware name server that supports recursion MUST follow the rules for the CD and AD bits given in Section 3.2 when generating a response that involves data obtained via recursion.
再帰をサポートするセキュリティ対応のネームサーバーは、再帰を介して取得したデータを含む応答を生成する場合、セクション3.2で指定されたCDおよびADビットの規則に従う必要があります。
As explained in [RFC4033], a security-aware recursive name server is an entity that acts in both the security-aware name server and security-aware resolver roles. This section uses the terms "name server side" and "resolver side" to refer to the code within a security-aware recursive name server that implements the security-aware name server role and the code that implements the security-aware resolver role, respectively.
[RFC4033]で説明されているように、セキュリティ対応の再帰ネームサーバーは、セキュリティ対応のネームサーバーとセキュリティ対応のリゾルバーの両方の役割で機能するエンティティです。 このセクションでは、「ネームサーバー側」と「リゾルバー側」という用語を使用して、セキュリティ対応ネームサーバーの役割を実装するセキュリティ対応再帰ネームサーバー内のコードと、セキュリティ対応リゾルバーの役割を実装するコードをそれぞれ参照します。 。
The resolver side follows the usual rules for caching and negative caching that would apply to any security-aware resolver.
リゾルバー側は、セキュリティを意識したリゾルバーに適用されるキャッシングとネガティブキャッシングの通常のルールに従います。
The resolver side of a security-aware recursive name server MUST set the DO bit when sending requests, regardless of the state of the DO bit in the initiating request received by the name server side. If the DO bit in an initiating query is not set, the name server side MUST strip any authenticating DNSSEC RRs from the response but MUST NOT strip any DNSSEC RR types that the initiating query explicitly requested.
セキュリティ対応の再帰ネームサーバーのリゾルバ側は、ネームサーバー側が受信した開始要求のDOビットの状態に関係なく、要求を送信するときにDOビットを設定する必要があります。 開始クエリのDOビットが設定されていない場合、ネームサーバー側は応答から認証DNSSEC RRを削除しなければなりませんが、開始クエリが明示的に要求したDNSSEC RRタイプを削除してはなりません。
The CD bit exists in order to allow a security-aware resolver to disable signature validation in a security-aware name server's processing of a particular query.
CD対応ビットは、セキュリティ対応リゾルバが特定のクエリのセキュリティ対応ネームサーバーの処理で署名検証を無効にできるようにするために存在します。
The name server side MUST copy the setting of the CD bit from a query to the corresponding response.
ネームサーバー側は、CDビットの設定をクエリから対応する応答にコピーしなければなりません。
The name server side of a security-aware recursive name server MUST pass the state of the CD bit to the resolver side along with the rest of an initiating query, so that the resolver side will know whether it is required to verify the response data it returns to the name server side. If the CD bit is set, it indicates that the originating resolver is willing to perform whatever authentication its local policy requires. Thus, the resolver side of the recursive name server need not perform authentication on the RRsets in the response. When the CD bit is set, the recursive name server SHOULD, if possible, return the requested data to the originating resolver, even if the recursive name server's local authentication policy would reject the records in question. That is, by setting the CD bit, the originating resolver has indicated that it takes responsibility for performing its own authentication, and the recursive name server should not interfere.
セキュリティ対応の再帰ネームサーバーのネームサーバー側は、リゾルバー側が応答データを検証する必要があるかどうかを知るために、CDビットの状態を残りの開始クエリとともにリゾルバー側に渡す必要があります ネームサーバー側に戻ります。 CDビットが設定されている場合、発信元のリゾルバがローカルポリシーに必要な認証を実行することを示します。 したがって、再帰ネームサーバーのリゾルバ側は、応答内のRRsetで認証を実行する必要はありません。 CDビットが設定されている場合、再帰ネームサーバーは、可能であれば、再帰ネームサーバーのローカル認証ポリシーが問題のレコードを拒否する場合でも、要求されたデータを元のリゾルバーに返すべきです（SHOULD）。 つまり、CDビットを設定することにより、発信元のリゾルバーは独自の認証を実行する責任があることを示しており、再帰ネームサーバーが干渉してはなりません。
If the resolver side implements a BAD cache (see Section 4.7) and the name server side receives a query that matches an entry in the resolver side's BAD cache, the name server side's response depends on the state of the CD bit in the original query. If the CD bit is set, the name server side SHOULD return the data from the BAD cache; if the CD bit is not set, the name server side MUST return RCODE 2 (server failure).
リゾルバー側がBADキャッシュを実装し（セクション4.7を参照）、ネームサーバー側がリゾルバー側のBADキャッシュのエントリに一致するクエリを受信した場合、ネームサーバー側の応答は元のクエリのCDビットの状態に依存します。 CDビットが設定されている場合、ネームサーバー側はBADキャッシュからデータを返す必要があります。 CDビットが設定されていない場合、ネームサーバー側はRCODE 2（サーバー障害）を返さなければなりません。
The intent of the above rule is to provide the raw data to clients that are capable of performing their own signature verification checks while protecting clients that depend on the resolver side of a security-aware recursive name server to perform such checks. Several of the possible reasons why signature validation might fail involve conditions that may not apply equally to the recursive name server and the client that invoked it. For example, the recursive name server's clock may be set incorrectly, or the client may have knowledge of a relevant island of security that the recursive name server does not share. In such cases, "protecting" a client that is capable of performing its own signature validation from ever seeing the "bad" data does not help the client.
上記のルールの目的は、独自の署名検証チェックを実行できるクライアントに生データを提供すると同時に、このようなチェックを実行するためにセキュリティ対応の再帰ネームサーバーのリゾルバー側に依存するクライアントを保護することです。 署名の検証が失敗する可能性のあるいくつかの理由には、再帰ネームサーバーとそれを呼び出したクライアントに等しく適用されない条件が含まれます。 たとえば、再帰ネームサーバーのクロックが正しく設定されていないか、クライアントが再帰ネームサーバーが共有していない関連するセキュリティアイランドを知っている可能性があります。 そのような場合、「不正な」データを見ることから独自の署名検証を実行できるクライアントを「保護」することは、クライアントを助けません。
The name server side of a security-aware recursive name server MUST NOT set the AD bit in a response unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic. The name server side SHOULD set the AD bit if and only if the resolver side considers all RRsets in the Answer section and any relevant negative response RRs in the Authority section to be authentic. The resolver side MUST follow the procedure described in Section 5 to determine whether the RRs in question are authentic. However, for backward compatibility, a recursive name server MAY set the AD bit when a response includes unsigned CNAME RRs if those CNAME
セキュリティ対応の再帰ネームサーバーのネームサーバー側は、ネームサーバーが応答のAnswerセクションとAuthorityセクションのすべてのRRsetを本物と見なさない限り、応答にADビットを設定してはなりません。 ネームサーバー側は、リゾルバー側がAnswerセクション内のすべてのRRsetとAuthorityセクション内の関連する否定応答RRを本物と見なす場合にのみADビットを設定する必要があります。 リゾルバ側は、セクション5で説明した手順に従って、問題のRRが本物かどうかを判断する必要があります。 ただし、下位互換性のために、応答に未署名のCNAME RRが含まれる場合、再帰ネームサーバーはADビットを設定する場合があります。
RRs demonstrably could have been synthesized from an authentic DNAME RR that is also included in the response according to the synthesis rules described in [RFC2672].
RRは、[RFC2672]で説明されている合成ルールに従って、応答にも含まれる本物のDNAME RRから明らかに合成できたはずです。
See Appendix B for example response packets.
応答パケットの例については、付録Bを参照してください。
This section describes the behavior of entities that include security-aware resolver functions. In many cases such functions will be part of a security-aware recursive name server, but a stand-alone security-aware resolver has many of the same requirements. Functions specific to security-aware recursive name servers are described in Section 3.2.
このセクションでは、セキュリティ対応リゾルバー機能を含むエンティティの動作について説明します。 多くの場合、このような関数はセキュリティ対応の再帰ネームサーバーの一部になりますが、スタンドアロンのセキュリティ対応リゾルバには同じ要件の多くがあります。 セキュリティ対応の再帰ネームサーバーに固有の機能については、セクション3.2で説明します。
A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
セキュリティ対応リゾルバは、クエリを送信するときにDO（[RFC3225]）ビットが設定されたEDNS（[RFC2671]）OPT疑似RRを含まなければなりません。
A security-aware resolver MUST support a message size of at least 1220 octets, SHOULD support a message size of 4000 octets, and MUST use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR to advertise the message size that it is willing to accept. A security-aware resolver's IP layer MUST handle fragmented UDP packets correctly regardless of whether any such fragmented packets were received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and [RFC3226] for discussion of these requirements.
セキュリティ対応リゾルバは、少なくとも1220オクテットのメッセージサイズをサポートする必要があり、4000オクテットのメッセージサイズをサポートする必要があり、EDNS OPT擬似RRの「送信者のUDPペイロードサイズ」フィールドを使用して、そのメッセージサイズをアドバタイズする必要があります 喜んで受け入れます。 セキュリティ対応リゾルバのIP層は、そのような断片化されたパケットがIPv4またはIPv6経由で受信されたかどうかにかかわらず、断片化されたUDPパケットを正しく処理しなければなりません。 これらの要件の説明については、[RFC1122]、[RFC2460]、および[RFC3226]を参照してください。
A security-aware resolver MUST support the signature verification mechanisms described in Section 5 and SHOULD apply them to every received response, except when:
セキュリティ対応リゾルバは、セクション5で説明されている署名検証メカニズムをサポートする必要があり、次の場合を除き、受信したすべての応答にそれらを適用する必要があります。
o the security-aware resolver is part of a security-aware recursive name server, and the response is the result of recursion on behalf of a query received with the CD bit set;
oセキュリティ対応リゾルバはセキュリティ対応の再帰ネームサーバーの一部であり、応答はCDビットが設定された状態で受信したクエリに代わって再帰の結果です。
o the response is the result of a query generated directly via some form of application interface that instructed the security-aware resolver not to perform validation for this query; or
o応答は、何らかの形式のアプリケーションインターフェイスを介して直接生成されたクエリの結果であり、セキュリティ対応リゾルバにこのクエリの検証を実行しないよう指示しました。 または
o validation for this query has been disabled by local policy.
oこのクエリの検証は、ローカルポリシーによって無効にされています。
A security-aware resolver's support for signature verification MUST include support for verification of wildcard owner names.
セキュリティを意識したリゾルバの署名検証のサポートには、ワイルドカード所有者名の検証のサポートが含まれなければなりません。
Security-aware resolvers MAY query for missing security RRs in an attempt to perform validation; implementations that choose to do so must be aware that the answers received may not be sufficient to validate the original response. For example, a zone update may have changed (or deleted) the desired information between the original and follow-up queries.
セキュリティ対応リゾルバは、検証を実行しようとして、欠落しているセキュリティRRを照会してもよい（MAY）。 そうすることを選択した実装は、受け取った回答が元の応答を検証するのに十分でない可能性があることに注意する必要があります。 たとえば、ゾーンの更新により、元のクエリとフォローアップクエリの間で必要な情報が変更（または削除）された可能性があります。
When attempting to retrieve missing NSEC RRs that reside on the parental side at a zone cut, a security-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone.
ゾーンカットの親側に存在する欠落したNSEC RRを取得しようとするとき、セキュリティ対応の反復モードリゾルバは、子ゾーンではなく親ゾーンのネームサーバーを照会しなければなりません。
When attempting to retrieve a missing DS, a security-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone. As explained in Section 3.1.4.1, security-aware name servers need to apply special processing rules to handle the DS RR, and in some situations the resolver may also need to apply special rules to locate the name servers for the parent zone if the resolver does not already have the parent's NS RRset. To locate the parent NS RRset, the resolver can start with the delegation name, strip off the leftmost label, and query for an NS RRset by that name. If no NS RRset is present at that name, the resolver then strips off the leftmost remaining label and retries the query for that name, repeating this process of walking up the tree until it either finds the NS RRset or runs out of labels.
欠落しているDSを取得しようとするとき、セキュリティ対応の反復モードリゾルバは、子ゾーンではなく、親ゾーンのネームサーバーに照会する必要があります。 セクション3.1.4.1で説明したように、セキュリティ対応のネームサーバーは、DS RRを処理するために特別な処理ルールを適用する必要があり、状況によっては、リゾルバーが親ゾーンのネームサーバーを見つけるために特別なルールを適用する必要がある場合があります 親のNS RRsetがまだありません。 親NS RRsetを見つけるために、リゾルバーは委任名で開始し、左端のラベルを取り除き、その名前でNS RRsetを照会できます。 その名前にNS RRsetが存在しない場合、リゾルバーは左端の残りのラベルを取り除き、その名前のクエリを再試行します。NSRRsetが見つかるか、ラベルがなくなるまで、ツリーを上るこのプロセスを繰り返します。
A security-aware resolver MUST be able to determine whether it should expect a particular RRset to be signed. More precisely, a security-aware resolver must be able to distinguish between four cases:
セキュリティを意識したリゾルバは、特定のRRsetが署名されることを期待すべきかどうかを判断できなければなりません（MUST）。 より正確には、セキュリティ対応のリゾルバは、次の4つのケースを区別できる必要があります。
Secure: An RRset for which the resolver is able to build a chain of signed DNSKEY and DS RRs from a trusted security anchor to the RRset. In this case, the RRset should be signed and is subject to signature validation, as described above.
セキュア：リゾルバーが、信頼できるセキュリティアンカーからRRsetへの署名済みDNSKEYおよびDS RRのチェーンを構築できるRRset。 この場合、RRsetは署名される必要があり、上記のように署名検証の対象となります。
Insecure: An RRset for which the resolver knows that it has no chain of signed DNSKEY and DS RRs from any trusted starting point to the RRset. This can occur when the target RRset lies in an unsigned zone or in a descendent of an unsigned zone. In this case, the RRset may or may not be signed, but the resolver will not be able to verify the signature.
安全でない：リゾルバが、信頼できる開始点からRRsetへの署名済みDNSKEYおよびDS RRのチェーンがないことを認識しているRRset。 これは、ターゲットRRsetが符号なしゾーンまたは符号なしゾーンの子孫にある場合に発生する可能性があります。 この場合、RRsetは署名されている場合とされていない場合がありますが、リゾルバは署名を検証できません。
Bogus: An RRset for which the resolver believes that it ought to be able to establish a chain of trust but for which it is unable to do so, either due to signatures that for some reason fail to validate or due to missing data that the relevant DNSSEC RRs indicate should be present. This case may indicate an attack but may also indicate a configuration error or some form of data corruption.
偽：リゾルバーが信頼チェーンを確立できるはずであると考えているが、何らかの理由で検証に失敗した署名または関連するデータが欠落しているために確立できないRRset DNSSEC RRは存在することを示します。 このケースは攻撃を示している場合がありますが、構成エラーまたは何らかの形のデータ破損を示している場合もあります。
Indeterminate: An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones.
不確定：リゾルバーは必要なDNSSEC RRを取得できないため、リゾルバーがRRsetに署名する必要があるかどうかを判断できないRRset。 これは、セキュリティ対応リゾルバが関連ゾーンのセキュリティ対応ネームサーバーに接続できない場合に発生する可能性があります。
A security-aware resolver MUST be capable of being configured with at least one trusted public key or DS RR and SHOULD be capable of being configured with multiple trusted public keys or DS RRs. Since a security-aware resolver will not be able to validate signatures without such a configured trust anchor, the resolver SHOULD have some reasonably robust mechanism for obtaining such keys when it boots; examples of such a mechanism would be some form of non-volatile storage (such as a disk drive) or some form of trusted local network configuration mechanism.
セキュリティを意識したリゾルバは、少なくとも1つの信頼できる公開鍵またはDS RRで構成できなければならず、複数の信頼できる公開鍵またはDS RRで構成できる必要があります（SHOULD）。 セキュリティを意識したリゾルバは、このような設定されたトラストアンカーがないと署名を検証できないため、リゾルバには、起動時にそのようなキーを取得するためのある程度堅牢なメカニズムが必要です。 そのようなメカニズムの例は、何らかの形の不揮発性ストレージ（ディスクドライブなど）または何らかの形の信頼できるローカルネットワーク構成メカニズムです。
Note that trust anchors also cover key material that is updated in a secure manner. This secure manner could be through physical media, a key exchange protocol, or some other out-of-band means.
トラストアンカーは、安全な方法で更新されるキーマテリアルもカバーすることに注意してください。 この安全な方法は、物理メディア、キー交換プロトコル、またはその他の帯域外の手段を使用する可能性があります。
A security-aware resolver SHOULD cache each response as a single atomic entry containing the entire answer, including the named RRset and any associated DNSSEC RRs. The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire. In most cases the appropriate cache index for the atomic entry will be the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response form described in Section 3.1.3.2 the appropriate cache index will be the double <QNAME,QCLASS>.
セキュリティ対応のリゾルバは、各応答を、名前付きRRsetおよび関連するDNSSEC RRを含む回答全体を含む単一のアトミックエントリとしてキャッシュする必要があります。 リゾルバは、含まれるRRのいずれかが期限切れになったときに、アトミックエントリ全体を破棄する必要があります。 ほとんどの場合、アトミックエントリの適切なキャッシュインデックスはトリプル<QNAME、QTYPE、QCLASS>ですが、セクション3.1.3.2で説明されている応答フォームなどの場合、適切なキャッシュインデックスはダブル<QNAME、QCLASS>になります 。
The reason for these recommendations is that, between the initial query and the expiration of the data from the cache, the authoritative data might have been changed (for example, via dynamic update).
これらの推奨事項の理由は、最初のクエリとキャッシュからのデータの有効期限の間に、権限のあるデータが（たとえば、動的更新を介して）変更された可能性があるためです。
There are two situations for which this is relevant:
これに関連する2つの状況があります。
1. By using the RRSIG record, it is possible to deduce that an answer was synthesized from a wildcard. A security-aware recursive name server could store this wildcard data and use it to generate positive responses to queries other than the name for which the original answer was first received.
1. RRSIGレコードを使用することにより、ワイルドカードから回答が合成されたことを推測できます。 セキュリティ対応の再帰ネームサーバーは、このワイルドカードデータを保存し、それを使用して、元の回答が最初に受信された名前以外のクエリに対する肯定的な応答を生成できます。
2. NSEC RRs received to prove the non-existence of a name could be reused by a security-aware resolver to prove the non-existence of any name in the name range it spans.
2.名前が存在しないことを証明するために受け取ったNSEC RRは、セキュリティ対応のリゾルバが再利用して、その名前の範囲内の名前が存在しないことを証明できます。
In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace.
理論的には、リゾルバはワイルドカードまたはNSEC RRを使用して、問題のレコードのTTLまたは署名が期限切れになるまで、それぞれ肯定応答と否定応答を生成できます。 ただし、リゾルバが新しい信頼できるデータをブロックしたり、独自に新しいデータを合成したりすることは避けたほうが賢明です。 この推奨事項に従うリゾルバは、名前空間のより一貫したビューを持ちます。
A security-aware resolver MAY set a query's CD bit in order to indicate that the resolver takes responsibility for performing whatever authentication its local policy requires on the RRsets in the response. See Section 3.2 for the effect this bit has on the behavior of security-aware recursive name servers.
セキュリティ対応のリゾルバは、リゾルバが応答内のRRsetでローカルポリシーに必要な認証を実行する責任を負うことを示すために、クエリのCDビットを設定してもよい（MAY）。 このビットがセキュリティ対応の再帰ネームサーバーの動作に与える影響については、セクション3.2を参照してください。
A security-aware resolver MUST clear the AD bit when composing query messages to protect against buggy name servers that blindly copy header bits that they do not understand from the query message to the response message.
セキュリティ対応のリゾルバは、クエリメッセージを作成するときにADビットをクリアして、クエリメッセージから応答メッセージに理解できないヘッダービットを盲目的にコピーするバグのあるネームサーバーから保護する必要があります。
A resolver MUST disregard the meaning of the CD and AD bits in a response unless the response was obtained by using a secure channel or the resolver was specifically configured to regard the message header bits without using a secure channel.
リゾルバは、セキュアチャネルを使用して応答が取得されたか、リゾルバがセキュアチャネルを使用せずにメッセージヘッダービットを考慮するように特別に構成されていない限り、応答のCDおよびADビットの意味を無視しなければなりません。
While many validation errors will be transient, some are likely to be more persistent, such as those caused by administrative error (failure to re-sign a zone, clock skew, and so forth). Since requerying will not help in these cases, validating resolvers might generate a significant amount of unnecessary DNS traffic as a result of repeated queries for RRsets with persistent validation failures.
多くの検証エラーは一時的なものですが、管理エラー（ゾーンへの再署名の失敗、クロックスキューなど）に起因するものなど、一部のエラーはより永続的である可能性があります。 これらの場合、再クエリは役に立たないので、リゾルバの検証では、永続的な検証エラーのあるRRsetに対するクエリの繰り返しの結果として、大量の不要なDNSトラフィックが生成される場合があります。
To prevent such unnecessary DNS traffic, security-aware resolvers MAY cache data with invalid signatures, with some restrictions.
このような不要なDNSトラフィックを防ぐために、セキュリティ対応のリゾルバーは、いくつかの制限付きで、無効な署名でデータをキャッシュできます。
Conceptually, caching such data is similar to negative caching ([RFC2308]), except that instead of caching a valid negative response, the resolver is caching the fact that a particular answer failed to validate. This document refers to a cache of data with invalid signatures as a "BAD cache".
概念的に、そのようなデータのキャッシングはネガティブキャッシング（[RFC2308]）に似ていますが、有効なネガティブレスポンスをキャッシュする代わりに、リゾルバーは特定の回答の検証に失敗したという事実をキャッシュします。 このドキュメントでは、無効な署名を持つデータのキャッシュを「BADキャッシュ」と呼びます。
Resolvers that implement a BAD cache MUST take steps to prevent the cache from being useful as a denial-of-service attack amplifier, particularly the following:
BADキャッシュを実装するリゾルバは、特に次のサービス拒否攻撃アンプとしてキャッシュが有用にならないように対策を講じる必要があります。
o Since RRsets that fail to validate do not have trustworthy TTLs, the implementation MUST assign a TTL. This TTL SHOULD be small, in order to mitigate the effect of caching the results of an attack.
o検証に失敗したRRsetには信頼できるTTLがないため、実装はTTLを割り当てなければなりません。 攻撃の結果をキャッシュする効果を軽減するために、このTTLは小さくする必要があります。
o In order to prevent caching of a transient validation failure (which might be the result of an attack), resolvers SHOULD track queries that result in validation failures and SHOULD only answer from the BAD cache after the number of times that responses to queries for that particular <QNAME, QTYPE, QCLASS> have failed to validate exceeds a threshold value.
o一時的な検証エラー（攻撃の結果である可能性がある）のキャッシングを防ぐために、リゾルバーは、検証エラーとなるクエリを追跡する必要があり（SHOULD）、そのクエリへの応答回数の後にBADキャッシュからのみ応答する必要があります 特定の<QNAME、QTYPE、QCLASS>が検証に失敗し、しきい値を超えています。
Resolvers MUST NOT return RRsets from the BAD cache unless the resolver is not required to validate the signatures of the RRsets in question under the rules given in Section 4.2 of this document. See Section 3.2.2 for discussion of how the responses returned by a security-aware recursive name server interact with a BAD cache.
リゾルバは、このドキュメントのセクション4.2で与えられた規則の下で問題のRRsetの署名を検証する必要がない限り、BADキャッシュからRRsetを返してはいけません。 セキュリティ対応の再帰ネームサーバーによって返される応答がBADキャッシュと対話する方法については、セクション3.2.2を参照してください。
A validating security-aware resolver MUST treat the signature of a valid signed DNAME RR as also covering unsigned CNAME RRs that could have been synthesized from the DNAME RR, as described in [RFC2672], at least to the extent of not rejecting a response message solely because it contains such CNAME RRs. The resolver MAY retain such CNAME RRs in its cache or in the answers it hands back, but is not required to do so.
検証セキュリティ対応リゾルバは、有効な署名付きDNAME RRの署名を、少なくとも応答メッセージを拒否しない範囲で、[RFC2672]で説明されているように、DNAME RRから合成された可能性のある未署名CNAME RRをもカバーするものとして扱わなければなりません（MUST） そのようなCNAME RRが含まれているからです。 リゾルバは、そのようなCNAME RRをそのキャッシュまたは返送する回答に保持することができますが、そうする必要はありません。
A security-aware stub resolver MUST support the DNSSEC RR types, at least to the extent of not mishandling responses just because they contain DNSSEC RRs.
セキュリティ対応のスタブリゾルバは、少なくともDNSSEC RRが含まれているという理由だけで応答を誤って処理しない程度まで、DNSSEC RRタイプをサポートする必要があります。
A non-validating security-aware stub resolver MAY include the DNSSEC RRs returned by a security-aware recursive name server as part of the data that the stub resolver hands back to the application that invoked it, but is not required to do so. A non-validating stub resolver that seeks to do this will need to set the DO bit in order to receive DNSSEC RRs from the recursive name server.
非検証のセキュリティ対応スタブリゾルバーには、セキュリティ対応の再帰ネームサーバーによって返されたDNSSEC RRを、スタブリゾルバーが呼び出し元のアプリケーションに返すデータの一部として含めることができますが、そうする必要はありません。 これを実行しようとする非検証スタブリゾルバは、再帰ネームサーバーからDNSSEC RRを受信するためにDOビットを設定する必要があります。
A validating security-aware stub resolver MUST set the DO bit, because otherwise it will not receive the DNSSEC RRs it needs to perform signature validation.
検証セキュリティ対応スタブリゾルバは、DOビットを設定する必要があります。そうしないと、署名検証の実行に必要なDNSSEC RRを受信しません。
A non-validating security-aware stub resolver SHOULD NOT set the CD bit when sending queries unless it is requested by the application layer, as by definition, a non-validating stub resolver depends on the security-aware recursive name server to perform validation on its behalf.
非検証のセキュリティ対応スタブリゾルバーは、アプリケーションレイヤーから要求されない限り、クエリを送信するときにCDビットを設定すべきではありません。定義により、非検証スタブリゾルバーは、セキュリティ対応の再帰ネームサーバーに依存して検証を実行します その代わり。
A validating security-aware stub resolver SHOULD set the CD bit, because otherwise the security-aware recursive name server will answer the query using the name server's local policy, which may prevent the stub resolver from receiving data that would be acceptable to the stub resolver's local policy.
セキュリティ対応のスタブリゾルバはCDビットを設定する必要があります。そうしないと、セキュリティ対応の再帰ネームサーバーがネームサーバーのローカルポリシーを使用してクエリに応答し、スタブリゾルバーが受け入れ可能なデータをスタブリゾルバーが受信できなくなる場合があります ローカルポリシー。
A non-validating security-aware stub resolver MAY chose to examine the setting of the AD bit in response messages that it receives in order to determine whether the security-aware recursive name server that sent the response claims to have cryptographically verified the data in the Answer and Authority sections of the response message. Note, however, that the responses received by a security-aware stub resolver are heavily dependent on the local policy of the security-aware recursive name server. Therefore, there may be little practical value in checking the status of the AD bit, except perhaps as a debugging aid. In any case, a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel.
非検証のセキュリティ対応スタブリゾルバは、応答を送信したセキュリティ対応の再帰ネームサーバーが暗号化されたデータを検証したと主張するかどうかを判断するために、受信した応答メッセージのADビットの設定を調べることを選択する場合があります 応答メッセージの回答および権限セクション。 ただし、セキュリティ対応のスタブリゾルバが受信する応答は、セキュリティ対応の再帰ネームサーバーのローカルポリシーに大きく依存していることに注意してください。 したがって、ADビットのステータスをチェックすることは、デバッグの補助として使用する場合を除いて、ほとんど実用的な価値がない場合があります。 いずれにせよ、セキュリティ対応スタブリゾルバは、セキュリティ対応スタブリゾルバが安全なチャネルを介して信頼できるセキュリティ対応再帰ネームサーバーから問題のデータを取得した場合を除き、その代わりに行われた署名検証に依存してはなりません 。
A validating security-aware stub resolver SHOULD NOT examine the setting of the AD bit in response messages, as, by definition, the stub resolver performs its own signature validation regardless of the setting of the AD bit.
定義により、スタブリゾルバはADビットの設定に関係なく独自の署名検証を実行するため、検証セキュリティ対応スタブリゾルバは応答メッセージ内のADビットの設定を調べるべきではありません。
To use DNSSEC RRs for authentication, a security-aware resolver requires configured knowledge of at least one authenticated DNSKEY or DS RR. The process for obtaining and authenticating this initial trust anchor is achieved via some external mechanism. For example, a resolver could use some off-line authenticated exchange to obtain a zone's DNSKEY RR or to obtain a DS RR that identifies and authenticates a zone's DNSKEY RR. The remainder of this section assumes that the resolver has somehow obtained an initial set of trust anchors.
DNSSEC RRを認証に使用するには、セキュリティ対応のリゾルバーは、少なくとも1つの認証済みDNSKEYまたはDS RRの構成済みの知識を必要とします。 この初期トラストアンカーを取得および認証するプロセスは、何らかの外部メカニズムによって実現されます。 たとえば、リゾルバはオフライン認証交換を使用して、ゾーンのDNSKEY RRを取得したり、ゾーンのDNSKEY RRを識別および認証するDS RRを取得したりできます。 このセクションの残りの部分では、リゾルバーが何らかの方法でトラストアンカーの初期セットを取得したことを前提としています。
An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY RRset. To authenticate an apex DNSKEY RRset by using an initial key, the resolver MUST:
初期DNSKEY RRを使用して、ゾーンの頂点DNSKEY RRsetを認証できます。 初期キーを使用してapex DNSKEY RRsetを認証するには、リゾルバーは以下を行わなければなりません：
1. verify that the initial DNSKEY RR appears in the apex DNSKEY RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA bit 7) set; and
1.最初のDNSKEY RRが頂点DNSKEY RRsetに表示されていること、およびDNSKEY RRにゾーンキーフラグ（DNSKEY RDATAビット7）が設定されていることを確認します。 そして
2. verify that there is some RRSIG RR that covers the apex DNSKEY RRset, and that the combination of the RRSIG RR and the initial DNSKEY RR authenticates the DNSKEY RRset. The process for using an RRSIG RR to authenticate an RRset is described in Section 5.3.
2.頂点のDNSKEY RRsetをカバーするRRSIG RRがあること、およびRRSIG RRと初期DNSKEY RRの組み合わせがDNSKEY RRsetを認証することを確認します。 RRSIG RRを使用してRRsetを認証するプロセスについては、セクション5.3で説明しています。
Once the resolver has authenticated the apex DNSKEY RRset by using an initial DNSKEY RR, delegations from that zone can be authenticated by using DS RRs. This allows a resolver to start from an initial key and use DS RRsets to proceed recursively down the DNS tree, obtaining other apex DNSKEY RRsets. If the resolver were configured with a root DNSKEY RR, and if every delegation had a DS RR associated with it, then the resolver could obtain and validate any apex DNSKEY RRset. The process of using DS RRs to authenticate referrals is described in Section 5.2.
リゾルバが初期DNSKEY RRを使用してapex DNSKEY RRsetを認証すると、DS RRを使用してそのゾーンからの委任を認証できます。 これにより、リゾルバーは初期キーから開始し、DS RRsetを使用してDNSツリーを再帰的に進め、他の頂点DNSKEY RRsetを取得できます。 リゾルバがルートDNSKEY RRで設定され、すべての委任にDS RRが関連付けられている場合、リゾルバは頂点DNSKEY RRsetを取得して検証できます。 DS RRを使用して紹介を認証するプロセスについては、セクション5.2で説明しています。
Section 5.3 shows how the resolver can use DNSKEY RRs in the apex DNSKEY RRset and RRSIG RRs from the zone to authenticate any other RRsets in the zone once the resolver has authenticated a zone's apex DNSKEY RRset. Section 5.4 shows how the resolver can use authenticated NSEC RRsets from the zone to prove that an RRset is not present in the zone.
セクション5.3は、リゾルバがゾーンの頂点DNSKEY RRsetを認証した後、リゾルバが頂点DNSKEY RRset内のDNSKEY RRとゾーンのRRSIG RRを使用して、ゾーン内の他のRRsetを認証する方法を示しています。 セクション5.4は、リゾルバがゾーンからの認証済みNSEC RRsetを使用して、RRsetがゾーンに存在しないことを証明する方法を示しています。
When a resolver indicates support for DNSSEC (by setting the DO bit), a security-aware name server should attempt to provide the necessary DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). However, a security-aware resolver may still receive a response that lacks the appropriate DNSSEC RRs, whether due to configuration issues such as an upstream security-oblivious recursive name server that accidentally interferes with DNSSEC RRs or due to a deliberate attack in which an adversary forges a response, strips DNSSEC RRs from a response, or modifies a query so that DNSSEC RRs appear not to be requested. The absence of DNSSEC data in a response MUST NOT by itself be taken as an indication that no authentication information exists.
リゾルバが（DOビットを設定することにより）DNSSECのサポートを示している場合、セキュリティ対応ネームサーバーは、応答で必要なDNSKEY、RRSIG、NSEC、およびDS RRsetを提供しようとする必要があります（セクション3を参照）。 ただし、セキュリティを意識したリゾルバーは、DNSSEC RRを誤って干渉する上流のセキュリティを意識しない再帰的なネームサーバーなどの構成の問題、または敵が 応答を偽造したり、応答からDNSSEC RRを削除したり、DNSSEC RRが要求されていないように見えるようにクエリを変更したりします。 応答にDNSSECデータが存在しないことを、認証情報が存在しないことを示すものと見なしてはなりません。
A resolver SHOULD expect authentication information from signed zones. A resolver SHOULD believe that a zone is signed if the resolver has been configured with public key information for the zone, or if the zone's parent is signed and the delegation from the parent contains a DS RRset.
リゾルバは、署名されたゾーンからの認証情報を期待する必要があります。 リゾルバは、リゾルバがゾーンの公開鍵情報で設定されている場合、またはゾーンの親が署名されており、親からの委任にDS RRsetが含まれている場合、ゾーンが署名されていると考える必要があります。
Islands of security (see [RFC4033]) are signed zones for which it is not possible to construct an authentication chain to the zone from its parent. Validating signatures within an island of security requires that the validator have some other means of obtaining an initial authenticated zone key for the island. If a validator cannot obtain such a key, it SHOULD switch to operating as if the zones in the island of security are unsigned.
セキュリティの島（[RFC4033]を参照）は、親からゾーンへの認証チェーンを構築することができない署名済みゾーンです。 セキュリティのアイランド内で署名を検証するには、バリデーターがアイランドの初期認証済みゾーンキーを取得する他の手段を持っている必要があります。 バリデータがそのようなキーを取得できない場合、セキュリティアイランドのゾーンが署名されていないかのように動作するように切り替える必要があります。
All the normal processes for validating responses apply to islands of security. The only difference between normal validation and validation within an island of security is in how the validator obtains a trust anchor for the authentication chain.
応答を検証するための通常のプロセスはすべて、セキュリティの島に適用されます。 通常の検証とセキュリティアイランド内の検証の唯一の違いは、バリデータが認証チェーンのトラストアンカーを取得する方法です。
Once the apex DNSKEY RRset for a signed parent zone has been authenticated, DS RRsets can be used to authenticate the delegation to a signed child zone. A DS RR identifies a DNSKEY RR in the child zone's apex DNSKEY RRset and contains a cryptographic digest of the child zone's DNSKEY RR. Use of a strong cryptographic digest algorithm ensures that it is computationally infeasible for an adversary to generate a DNSKEY RR that matches the digest. Thus, authenticating the digest allows a resolver to authenticate the matching DNSKEY RR. The resolver can then use this child DNSKEY RR to authenticate the entire child apex DNSKEY RRset.
署名された親ゾーンのapex DNSKEY RRsetが認証されると、DS RRsetを使用して、署名された子ゾーンへの委任を認証できます。 DS RRは、子ゾーンの頂点DNSKEY RRset内のDNSKEY RRを識別し、子ゾーンのDNSKEY RRの暗号ダイジェストを含みます。 強力な暗号化ダイジェストアルゴリズムを使用すると、ダイジェストに一致するDNSKEY RRを敵が生成するのが計算上実行不可能になります。 したがって、ダイジェストを認証すると、リゾルバーは一致するDNSKEY RRを認証できます。 リゾルバは、この子DNSKEY RRを使用して、子頂点DNSKEY RRset全体を認証できます。
Given a DS RR for a delegation, the child zone's apex DNSKEY RRset can be authenticated if all of the following hold:
委任のDS RRが与えられると、次のすべてが成り立つ場合、子ゾーンの頂点DNSKEY RRsetを認証できます。
o The DS RR has been authenticated using some DNSKEY RR in the parent's apex DNSKEY RRset (see Section 5.3).
o DS RRは、親の頂点DNSKEY RRsetのDNSKEY RRを使用して認証されています（セクション5.3を参照）。
o The Algorithm and Key Tag in the DS RR match the Algorithm field and the key tag of a DNSKEY RR in the child zone's apex DNSKEY RRset, and, when the DNSKEY RR's owner name and RDATA are hashed using the digest algorithm specified in the DS RR's Digest Type field, the resulting digest value matches the Digest field of the DS RR.
o DS RRのアルゴリズムとキータグは、子ゾーンの頂点DNSKEY RRsetのDNSKEY RRのアルゴリズムフィールドとキータグと一致し、DSで指定されたダイジェストアルゴリズムを使用してDNSKEY RRの所有者名とRDATAがハッシュされる場合 RRのダイジェストタイプフィールド。結果のダイジェスト値は、DS RRのダイジェストフィールドと一致します。
o The matching DNSKEY RR in the child zone has the Zone Flag bit set, the corresponding private key has signed the child zone's apex DNSKEY RRset, and the resulting RRSIG RR authenticates the child zone's apex DNSKEY RRset.
o子ゾーンの一致するDNSKEY RRにはZone Flagビットが設定され、対応する秘密鍵は子ゾーンの頂点DNSKEY RRsetに署名し、結果のRRSIG RRは子ゾーンの頂点DNSKEY RRsetを認証します。
If the referral from the parent zone did not contain a DS RRset, the response should have included a signed NSEC RRset proving that no DS RRset exists for the delegated name (see Section 3.1.4). A security-aware resolver MUST query the name servers for the parent zone for the DS RRset if the referral includes neither a DS RRset nor a NSEC RRset proving that the DS RRset does not exist (see Section 4).
親ゾーンからの照会にDS RRsetが含まれていない場合、応答には、委任された名前のDS RRsetが存在しないことを証明する署名付きNSEC RRsetが含まれている必要があります（セクション3.1.4を参照）。 照会にDS RRsetもDSSEC RRsetが存在しないことを証明するNSEC RRsetも含まれていない場合、セキュリティ対応リゾルバは、DS RRsetの親ゾーンのネームサーバーに照会する必要があります（セクション4を参照）。
If the validator authenticates an NSEC RRset that proves that no DS RRset is present for this zone, then there is no authentication path leading from the parent to the child. If the resolver has an initial DNSKEY or DS RR that belongs to the child zone or to any delegation below the child zone, this initial DNSKEY or DS RR MAY be used to re-establish an authentication path. If no such initial DNSKEY or DS RR exists, the validator cannot authenticate RRsets in or below the child zone.
バリデーターが、このゾーンにDS RRsetがないことを証明するNSEC RRsetを認証する場合、親から子への認証パスはありません。 リゾルバに、子ゾーンまたは子ゾーンの下の委任に属する初期DNSKEYまたはDS RRがある場合、この初期DNSKEYまたはDS RRを使用して認証パスを再確立することができます。 そのような初期DNSKEYまたはDS RRが存在しない場合、バリデーターは子ゾーン内またはその下のRRsetを認証できません。
If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described above.
バリデーターが認証されたDS RRsetにリストされているアルゴリズムをサポートしていない場合、リゾルバーは親から子へのサポートされる認証パスを持ちません。 リゾルバは、上記のように、DS RRsetが存在しないことを証明する認証済みNSEC RRsetの場合と同様に、このケースを扱う必要があります。
Note that, for a signed delegation, there are two NSEC RRs associated with the delegated name. One NSEC RR resides in the parent zone and can be used to prove whether a DS RRset exists for the delegated name. The second NSEC RR resides in the child zone and identifies which RRsets are present at the apex of the child zone. The parent NSEC RR and child NSEC RR can always be distinguished because the SOA bit will be set in the child NSEC RR and clear in the parent NSEC RR. A security-aware resolver MUST use the parent NSEC RR when attempting to prove that a DS RRset does not exist.
署名された委任には、委任された名前に関連付けられた2つのNSEC RRがあることに注意してください。 1つのNSEC RRが親ゾーンに存在し、委任された名前にDS RRsetが存在するかどうかを証明するために使用できます。 2番目のNSEC RRは子ゾーンに存在し、子ゾーンの頂点に存在するRRsetを識別します。 SOAビットは子NSEC RRで設定され、親NSEC RRでクリアされるため、親NSEC RRと子NSEC RRは常に区別できます。 セキュリティを意識したリゾルバは、DS RRsetが存在しないことを証明しようとするとき、親NSEC RRを使用しなければなりません。
If the resolver does not support any of the algorithms listed in an authenticated DS RRset, then the resolver will not be able to verify the authentication path to the child zone. In this case, the resolver SHOULD treat the child zone as if it were unsigned.
リゾルバーが認証済みのDS RRsetにリストされているアルゴリズムをサポートしていない場合、リゾルバーは子ゾーンへの認証パスを検証できません。 この場合、リゾルバは子ゾーンを署名されていないものとして扱うべきです（SHOULD）。
A validator can use an RRSIG RR and its corresponding DNSKEY RR to attempt to authenticate RRsets. The validator first checks the RRSIG RR to verify that it covers the RRset, has a valid time interval, and identifies a valid DNSKEY RR. The validator then constructs the canonical form of the signed data by appending the RRSIG RDATA (excluding the Signature Field) with the canonical form of the covered RRset. Finally, the validator uses the public key and signature to authenticate the signed data. Sections 5.3.1, 5.3.2, and 5.3.3 describe each step in detail.
バリデーターは、RRSIG RRとそれに対応するDNSKEY RRを使用して、RRsetの認証を試みることができます。 バリデーターはまずRRSIG RRをチェックして、RRsetをカバーし、有効な時間間隔を持ち、有効なDNSKEY RRを識別することを確認します。 バリデーターは、RRSIG RDATA（署名フィールドを除く）に正規形式の対象RRsetを追加することにより、署名付きデータの正規形式を構築します。 最後に、バリデーターは公開鍵と署名を使用して署名付きデータを認証します。 セクション5.3.1、5.3.2、および5.3.3では、各ステップについて詳しく説明しています。
A security-aware resolver can use an RRSIG RR to authenticate an RRset if all of the following conditions hold:
次の条件がすべて満たされている場合、セキュリティ対応リゾルバーはRRSIG RRを使用してRRsetを認証できます。
o The RRSIG RR and the RRset MUST have the same owner name and the same class.
o RRSIG RRとRRsetは同じ所有者名と同じクラスを持たなければなりません。
o The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset.
o RRSIG RRの署名者の名前フィールドは、RRsetを含むゾーンの名前でなければなりません。
o The RRSIG RR's Type Covered field MUST equal the RRset's type.
o RRSIG RRのType Coveredフィールドは、RRsetのタイプと等しくなければなりません。
o The number of labels in the RRset owner name MUST be greater than or equal to the value in the RRSIG RR's Labels field.
o RRset所有者名のラベルの数は、RRSIG RRのLabelsフィールドの値以上でなければなりません。
o The validator's notion of the current time MUST be less than or equal to the time listed in the RRSIG RR's Expiration field.
oバリデーターの現在の時間の概念は、RRSIG RRの有効期限フィールドにリストされた時間以下でなければなりません。
o The validator's notion of the current time MUST be greater than or equal to the time listed in the RRSIG RR's Inception field.
oバリデーターの現在時刻の概念は、RRSIG RRのInceptionフィールドにリストされている時刻以上でなければなりません。
o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST match the owner name, algorithm, and key tag for some DNSKEY RR in the zone's apex DNSKEY RRset.
o RRSIG RRの署名者の名前、アルゴリズム、およびキータグフィールドは、ゾーンの頂点DNSKEY RRset内のDNSKEY RRの所有者名、アルゴリズム、およびキータグと一致しなければなりません。
o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) set.
o一致するDNSKEY RRはゾーンの頂点DNSKEY RRsetに存在しなければならず（MUST）、Zone Flagビット（DNSKEY RDATA Flag bit 7）が設定されていなければなりません。
It is possible for more than one DNSKEY RR to match the conditions above. In this case, the validator cannot predetermine which DNSKEY RR to use to authenticate the signature, and it MUST try each matching DNSKEY RR until either the signature is validated or the validator has run out of matching public keys to try.
複数のDNSKEY RRが上記の条件に一致する可能性があります。 この場合、バリデーターは署名を認証するために使用するDNSKEY RRを事前に決定できず、署名が検証されるか、バリデーターが試行する一致する公開キーを使い果たすまで、一致する各DNSKEY RRを試行する必要があります。
Note that this authentication process is only meaningful if the validator authenticates the DNSKEY RR before using it to validate signatures. The matching DNSKEY RR is considered to be authentic if:
この認証プロセスは、バリデーターが署名を検証するために使用する前にDNSKEY RRを認証する場合にのみ意味があることに注意してください。 次の場合、一致するDNSKEY RRは本物と見なされます。
o the apex DNSKEY RRset containing the DNSKEY RR is considered authentic; or
o DNSKEY RRを含むapex DNSKEY RRsetは本物と見なされます。 または
o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, and the DNSKEY RR either matches an authenticated DS RR from the parent zone or matches a trust anchor.
o RRSIG RRでカバーされるRRsetは頂点DNSKEY RRset自体であり、DNSKEY RRは親ゾーンからの認証済みDS RRと一致するか、トラストアンカーと一致します。
Once the RRSIG RR has met the validity requirements described in Section 5.3.1, the validator has to reconstruct the original signed data. The original signed data includes RRSIG RDATA (excluding the Signature field) and the canonical form of the RRset. Aside from being ordered, the canonical form of the RRset might also differ from the received RRset due to DNS name compression, decremented TTLs, or wildcard expansion. The validator should use the following to reconstruct the original signed data:
RRSIG RRがセクション5.3.1で説明されている有効性要件を満たしたら、検証者は元の署名済みデータを再構築する必要があります。 元の署名されたデータには、RRSIG RDATA（署名フィールドを除く）と正規形式のRRsetが含まれます。 DNS名の圧縮、TTLの減少、またはワイルドカード拡張のために、RRsetの標準形式は、注文されている以外に、受信したRRsetと異なる場合があります。 バリデータは、次を使用して元の署名済みデータを再構築する必要があります。
signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
signed_data = RRSIG_RDATA | RR（1）| RR（2）...ここで
"|" denotes concatenation
「|」 連結を示します
RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signature field excluded and the Signer's Name in canonical form.
RRSIG_RDATAは、RRSIG RDATAフィールドのワイヤー形式で、署名フィールドは除外され、署名者の名前は正規の形式です。
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
RR（i）=名前| タイプ| クラス| OrigTTL | RDATAの長さ| RDATA
name is calculated according to the function below
名前は以下の関数に従って計算されます
class is the RRset's class
classはRRsetのクラスです
type is the RRset type and all RRs in the class
typeはRRsetタイプおよびクラス内のすべてのRRです
OrigTTL is the value from the RRSIG Original TTL field
OrigTTLは、RRSIG Original TTLフィールドの値です
All names in the RDATA field are in canonical form
RDATAフィールドのすべての名前は標準形式です
The set of all RR(i) is sorted into canonical order.
すべてのRR（i）のセットは標準的な順序にソートされます。
To calculate the name: let rrsig_labels = the value of the RRSIG Labels field
名前を計算するには：rrsig_labels = RRSIG Labelsフィールドの値にしましょう
let fqdn = RRset's fully qualified domain name in canonical form
let fqdn = RRsetの正規形式の完全修飾ドメイン名
let fqdn_labels = Label count of the fqdn above.
let fqdn_labels =上記のfqdnのラベルカウント。
if rrsig_labels = fqdn_labels, name = fqdn
rrsig_labels = fqdn_labels、name = fqdnの場合
if rrsig_labels < fqdn_labels, name = "*." | the rightmost rrsig_label labels of the fqdn
rrsig_labels <fqdn_labelsの場合、name = "*。" | fqdnの右端のrrsig_labelラベル
if rrsig_labels > fqdn_labels the RRSIG RR did not pass the necessary validation checks and MUST NOT be used to authenticate this RRset.
rrsig_labels> fqdn_labelsの場合、RRSIG RRは必要な検証チェックに合格せず、このRRsetの認証に使用してはなりません。
The canonical forms for names and RRsets are defined in [RFC4034].
名前とRRsetの標準形式は[RFC4034]で定義されています。
NSEC RRsets at a delegation boundary require special processing. There are two distinct NSEC RRsets associated with a signed delegated name. One NSEC RRset resides in the parent zone, and specifies which RRsets are present at the parent zone. The second NSEC RRset resides at the child zone and identifies which RRsets are present at the apex in the child zone. The parent NSEC RRset and child NSEC RRset can always be distinguished as only a child NSEC RR will indicate that an SOA RRset exists at the name. When reconstructing the original NSEC RRset for the delegation from the parent zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the child zone. When reconstructing the original NSEC RRset for the apex of the child zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent zone.
委任境界のNSEC RRsetには特別な処理が必要です。 署名された委任名に関連付けられた2つの異なるNSEC RRsetがあります。 1つのNSEC RRsetが親ゾーンに存在し、どのRRsetが親ゾーンに存在するかを指定します。 2番目のNSEC RRsetは子ゾーンに存在し、どのRRsetが子ゾーンの頂点に存在するかを識別します。 子NSEC RRのみがSOA RRsetが名前に存在することを示すため、親NSEC RRsetと子NSEC RRsetは常に区別できます。 親ゾーンからの委任のために元のNSEC RRsetを再構築するとき、NSEC RRは子ゾーンからのNSEC RRと組み合わせてはいけません。 子ゾーンの頂点の元のNSEC RRsetを再構築するとき、NSEC RRは親ゾーンからのNSEC RRと組み合わせてはなりません。
Note that each of the two NSEC RRsets at a delegation point has a corresponding RRSIG RR with an owner name matching the delegated name, and each of these RRSIG RRs is authoritative data associated with the same zone that contains the corresponding NSEC RRset. If necessary, a resolver can tell these RRSIG RRs apart by checking the Signer's Name field.
委任ポイントの2つのNSEC RRsetのそれぞれには、委任された名前と一致する所有者名を持つ対応するRRSIG RRがあり、これらのRRSIG RRのそれぞれは、対応するNSEC RRsetを含む同じゾーンに関連付けられた信頼できるデータであることに注意してください。 必要に応じて、リゾルバーは、署名者の名前フィールドを確認することにより、これらのRRSIG RRを区別できます。
Once the resolver has validated the RRSIG RR as described in Section 5.3.1 and reconstructed the original signed data as described in Section 5.3.2, the validator can attempt to use the cryptographic signature to authenticate the signed data, and thus (finally!) authenticate the RRset.
リゾルバーがセクション5.3.1で説明されているようにRRSIG RRを検証し、セクション5.3.2で説明されているように元の署名済みデータを再構築すると、検証者は暗号化署名を使用して署名済みデータを認証しようと試みることができます。 RRsetを認証します。
The Algorithm field in the RRSIG RR identifies the cryptographic algorithm used to generate the signature. The signature itself is contained in the Signature field of the RRSIG RDATA, and the public key used to verify the signature is contained in the Public Key field of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034] provides a list of algorithm types and provides pointers to the documents that define each algorithm's use.
RRSIG RRのAlgorithmフィールドは、署名の生成に使用される暗号化アルゴリズムを識別します。 署名自体はRRSIG RDATAのSignatureフィールドに含まれ、署名の検証に使用される公開鍵は、一致するDNSKEY RRのPublic Keyフィールドに含まれます（セクション5.3.1にあります）。 [RFC4034]は、アルゴリズムタイプのリストを提供し、各アルゴリズムの使用を定義するドキュメントへのポインタを提供します。
Note that it is possible for more than one DNSKEY RR to match the conditions in Section 5.3.1. In this case, the validator can only determine which DNSKEY RR is correct by trying each matching public key until the validator either succeeds in validating the signature or runs out of keys to try.
複数のDNSKEY RRがセクション5.3.1の条件に一致する可能性があることに注意してください。 この場合、検証者は署名の検証に成功するか、試行する鍵がなくなるまで、一致する各公開鍵を試すことによって、どのDNSKEY RRが正しいかを判断できます。
If the Labels field of the RRSIG RR is not equal to the number of labels in the RRset's fully qualified owner name, then the RRset is either invalid or the result of wildcard expansion. The resolver MUST verify that wildcard expansion was applied properly before considering the RRset to be authentic. Section 5.3.4 describes how to determine whether a wildcard was applied properly.
RRSIG RRのLabelsフィールドがRRsetの完全修飾所有者名のラベルの数と等しくない場合、RRsetは無効であるか、ワイルドカード拡張の結果です。 リゾルバは、RRsetが本物であると見なす前に、ワイルドカード拡張が適切に適用されたことを確認する必要があります。 セクション5.3.4では、ワイルドカードが適切に適用されたかどうかを判断する方法について説明します。
If other RRSIG RRs also cover this RRset, the local resolver security policy determines whether the resolver also has to test these RRSIG RRs and how to resolve conflicts if these RRSIG RRs lead to differing results.
他のRRSIG RRもこのRRsetをカバーする場合、ローカルリゾルバーセキュリティポリシーは、リゾルバーがこれらのRRSIG RRもテストする必要があるかどうか、およびこれらのRRSIG RRが異なる結果をもたらす場合の競合を解決する方法を決定します。
If the resolver accepts the RRset as authentic, the validator MUST set the TTL of the RRSIG RR and each RR in the authenticated RRset to a value no greater than the minimum of:
リゾルバがRRsetを本物として受け入れる場合、バリデーターはRRSIG RRのTTLと認証済みRRsetの各RRを以下の最小値以下の値に設定しなければなりません（MUST）。
o the RRset's TTL as received in the response;
o応答で受信したRRsetのTTL。
o the RRSIG RR's TTL as received in the response;
o応答で受信したRRSIG RRのTTL。
o the value in the RRSIG RR's Original TTL field; and
o RRSIG RRの元のTTLフィールドの値。 そして
o the difference of the RRSIG RR's Signature Expiration time and the current time.
o RRSIG RRの署名の有効期限と現在の時刻の差。
If the number of labels in an RRset's owner name is greater than the Labels field of the covering RRSIG RR, then the RRset and its covering RRSIG RR were created as a result of wildcard expansion. Once the validator has verified the signature, as described in Section 5.3, it must take additional steps to verify the non-existence of an exact match or closer wildcard match for the query. Section 5.4 discusses these steps.
RRsetの所有者名のラベルの数が、カバーするRRSIG RRのLabelsフィールドよりも大きい場合、RRsetとそのカバーするRRSIG RRは、ワイルドカード拡張の結果として作成されました。 セクション5.3で説明したように、バリデーターが署名を検証したら、追加の手順を実行して、クエリの完全一致またはより厳密なワイルドカード一致の存在を検証する必要があります。 セクション5.4では、これらの手順について説明します。
Note that the response received by the resolver should include all NSEC RRs needed to authenticate the response (see Section 3.1.3).
リゾルバが受信する応答には、応答の認証に必要なすべてのNSEC RRを含める必要があることに注意してください（セクション3.1.3を参照）。
A resolver can use authenticated NSEC RRs to prove that an RRset is not present in a signed zone. Security-aware name servers should automatically include any necessary NSEC RRs for signed zones in their responses to security-aware resolvers.
リゾルバは、認証済みのNSEC RRを使用して、署名済みゾーンにRRsetが存在しないことを証明できます。 セキュリティ対応ネームサーバーは、セキュリティ対応リゾルバへの応答に署名済みゾーンに必要なNSEC RRを自動的に含める必要があります。
Denial of existence is determined by the following rules:
存在の否定は、次の規則によって決定されます。
o If the requested RR name matches the owner name of an authenticated NSEC RR, then the NSEC RR's type bit map field lists all RR types present at that owner name, and a resolver can prove that the requested RR type does not exist by checking for the RR type in the bit map. If the number of labels in an authenticated NSEC RR's owner name equals the Labels field of the covering RRSIG RR, then the existence of the NSEC RR proves that wildcard expansion could not have been used to match the request.
o要求されたRR名が認証されたNSEC RRの所有者名と一致する場合、NSEC RRのタイプビットマップフィールドはその所有者名に存在するすべてのRRタイプをリストし、リゾルバーは以下をチェックすることで要求されたRRタイプが存在しないことを証明できます ビットマップのRRタイプ。 認証されたNSEC RRの所有者名のラベルの数が、カバーするRRSIG RRのLabelsフィールドと等しい場合、NSEC RRの存在は、ワイルドカード拡張を使用して要求を照合できなかったことを証明します。
o If the requested RR name would appear after an authenticated NSEC RR's owner name and before the name listed in that NSEC RR's Next Domain Name field according to the canonical DNS name order defined in [RFC4034], then no RRsets with the requested name exist in the zone. However, it is possible that a wildcard could be used to match the requested RR owner name and type, so proving that the requested RRset does not exist also requires proving that no possible wildcard RRset exists that could have been used to generate a positive response.
o認証されたNSEC RRの所有者名の後、[RFC4034]で定義された正規のDNS名順序に従ってそのNSEC RRの次のドメイン名フィールドにリストされた名前の前に要求されたRR名が表示される場合、要求された名前のRRsetは存在しません ゾーン。 ただし、ワイルドカードを使用して要求されたRR所有者の名前とタイプを一致させることができるため、要求されたRRsetが存在しないことを証明するには、肯定的な応答を生成するために使用できる可能性のあるワイルドカードRRsetが存在しないことも証明する必要があります。
In addition, security-aware resolvers MUST authenticate the NSEC RRsets that comprise the non-existence proof as described in Section 5.3.
さらに、セキュリティ対応リゾルバは、セクション5.3で説明されているように、存在しない証明を構成するNSEC RRsetを認証しなければなりません。
To prove the non-existence of an RRset, the resolver must be able to verify both that the queried RRset does not exist and that no relevant wildcard RRset exists. Proving this may require more than one NSEC RRset from the zone. If the complete set of necessary NSEC RRsets is not present in a response (perhaps due to message truncation), then a security-aware resolver MUST resend the query in order to attempt to obtain the full collection of NSEC RRs necessary to verify the non-existence of the requested RRset. As with all DNS operations, however, the resolver MUST bound the work it puts into answering any particular query.
RRsetが存在しないことを証明するために、リゾルバーは照会されたRRsetが存在しないこと、および関連するワイルドカードRRsetが存在しないことの両方を検証できなければなりません。 これを証明するには、ゾーンから複数のNSEC RRsetが必要になる場合があります。 必要なNSEC RRsetの完全なセットが応答に存在しない場合（おそらくメッセージの切り捨てが原因）、セキュリティ対応のリゾルバは、非-SEC 要求されたRRsetの存在。 ただし、すべてのDNS操作と同様に、リゾルバーは特定のクエリへの応答に費やす作業を制限しなければなりません。
Since a validated NSEC RR proves the existence of both itself and its corresponding RRSIG RR, a validator MUST ignore the settings of the NSEC and RRSIG bits in an NSEC RR.
検証済みのNSEC RRは、自身とその対応するRRSIG RRの両方の存在を証明するため、バリデーターはNSEC RRのNSECビットとRRSIGビットの設定を無視しなければなりません。
If for whatever reason none of the RRSIGs can be validated, the response SHOULD be considered BAD. If the validation was being done to service a recursive query, the name server MUST return RCODE 2 to the originating client. However, it MUST return the full response if and only if the original query had the CD bit set. Also see Section 4.7 on caching responses that do not validate.
何らかの理由でRRSIGのいずれも検証できない場合、応答は不良と見なされる必要があります。 再帰クエリを処理するために検証が行われていた場合、ネームサーバーは発信元クライアントにRCODE 2を返さなければなりません。 ただし、元のクエリにCDビットが設定されている場合にのみ、完全な応答を返す必要があります。 検証されない応答のキャッシュについては、セクション4.7も参照してください。
Appendix C shows an example of the authentication process.
付録Cは、認証プロセスの例を示しています。
[RFC4034] contains a review of the IANA considerations introduced by DNSSEC. The following are additional IANA considerations discussed in this document:
[RFC4034]には、DNSSECによって導入されたIANAの考慮事項のレビューが含まれています。 このドキュメントで説明されている追加のIANAの考慮事項は次のとおりです。
[RFC2535] reserved the CD and AD bits in the message header. The meaning of the AD bit was redefined in [RFC3655], and the meaning of both the CD and AD bit are restated in this document. No new bits in the DNS message header are defined in this document.
[RFC2535]はメッセージヘッダーのCDおよびADビットを予約しました。 ADビットの意味は[RFC3655]で再定義され、CDとADビットの両方の意味はこのドキュメントで書き直されています。 このドキュメントでは、DNSメッセージヘッダーの新しいビットは定義されていません。
[RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit and defined its use. The use is restated but not altered in this document.
[RFC2671]はEDNSを導入し、[RFC3225]はDNSSEC OKビットを予約し、その使用を定義しました。 このドキュメントでは、使用方法は修正されていますが、変更されていません。
This document describes how the DNS security extensions use public key cryptography to sign and authenticate DNS resource record sets. Please see [RFC4033] for terminology and general security considerations related to DNSSEC; see [RFC4034] for considerations specific to the DNSSEC resource record types.
このドキュメントでは、DNSセキュリティ拡張機能が公開キー暗号を使用してDNSリソースレコードセットに署名および認証する方法について説明します。 DNSSECに関連する用語と一般的なセキュリティの考慮事項については、[RFC4033]をご覧ください。 DNSSECリソースレコードタイプに固有の考慮事項については、[RFC4034]を参照してください。
An active attacker who can set the CD bit in a DNS query message or the AD bit in a DNS response message can use these bits to defeat the protection that DNSSEC attempts to provide to security-oblivious recursive-mode resolvers. For this reason, use of these control bits by a security-aware recursive-mode resolver requires a secure channel. See Sections 3.2.2 and 4.9 for further discussion.
DNSクエリメッセージのCDビットまたはDNS応答メッセージのADビットを設定できるアクティブな攻撃者は、これらのビットを使用して、DNSSECがセキュリティを意識しない再帰モードリゾルバーに提供しようとする保護を無効にできます。 このため、セキュリティ対応の再帰モードリゾルバがこれらの制御ビットを使用するには、安全なチャネルが必要です。 詳細については、セクション3.2.2および4.9を参照してください。
The protocol described in this document attempts to extend the benefits of DNSSEC to security-oblivious stub resolvers. However, as recovery from validation failures is likely to be specific to particular applications, the facilities that DNSSEC provides for stub resolvers may prove inadequate. Operators of security-aware recursive name servers will have to pay close attention to the behavior of the applications that use their services when choosing a local validation policy; failure to do so could easily result in the recursive name server accidentally denying service to the clients it is intended to support.
このドキュメントで説明されているプロトコルは、DNSSECの利点をセキュリティを意識しないスタブリゾルバに拡張しようとしています。 ただし、検証の失敗からの回復は特定のアプリケーションに固有である可能性が高いため、DNSSECがスタブリゾルバに提供する機能は不適切である可能性があります。 セキュリティ対応の再帰ネームサーバーの運用者は、ローカル検証ポリシーを選択するときに、サービスを使用するアプリケーションの動作に細心の注意を払う必要があります。 そうしないと、再帰ネームサーバーが、サポートするクライアントへのサービスを誤って拒否してしまう可能性があります。
This document was created from the input and ideas of the members of the DNS Extensions Working Group and working group mailing list. The editors would like to express their thanks for the comments and suggestions received during the revision of these security extension specifications. Although explicitly listing everyone who has contributed during the decade in which DNSSEC has been under development would be impossible, [RFC4033] includes a list of some of the participants who were kind enough to comment on these documents.
このドキュメントは、DNS Extensionsワーキンググループおよびワーキンググループメーリングリストのメンバーの意見とアイデアから作成されました。 編集者は、これらのセキュリティ拡張仕様の改訂中に受け取ったコメントと提案に感謝します。 DNSSECが開発中の10年間に貢献したすべての人を明示的にリストすることは不可能ですが、[RFC4033]にはこれらの文書にコメントするのに十分親切な参加者のリストが含まれています。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。、およびR. Bush、「DNS仕様の明確化」、RFC 2181、1997年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672] Crawford、M。、「非端末DNS名リダイレクト」、RFC 2672、1999年8月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225]コンラッド、D。、「DNSSECのリゾルバーサポートを示す」、RFC 3225、2001年12月。
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001.
[RFC3226] Gudmundsson、O。、「DNSSECおよびIPv6 A6対応サーバー/リゾルバーのメッセージサイズ要件」、RFC 3226、2001年12月
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のリソースレコード」、RFC 4034、2005年3月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308] Andrews、M。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、1998年3月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake 3rd、D。、「ドメインネームシステムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「セキュアドメインネームシステム（DNS）動的更新」、RFC 3007、2000年11月。
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3655] Wellington、B.およびO. Gudmundsson、「DNS認証データ（AD）ビットの再定義」、RFC 3655、2003年11月。
Appendix A. Signed Zone Example
付録A.署名済みゾーンの例
The following example shows a (small) complete signed zone.
次の例は、（小さな）完全な署名済みゾーンを示しています。
example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) 3600 NS ns1.example. 3600 NS ns2.example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 20040409183619 38519 example. gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) 3600 MX 1 xx.example. 3600 RRSIG MX 5 1 3600 20040509183619 ( 20040409183619 38519 example. HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM W6OISukd1EQt7a0kygkg+PEDxdI= ) 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 20040409183619 38519 example. O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U= ) 3600 DNSKEY 256 3 5 ( AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== ) 3600 DNSKEY 257 3 5 ( AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== ) 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 20040409183619 9465 example. ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 20040409183619 38519 example. eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk 7z5OXogYVaFzHKillDt3HRxHIZM= ) a.example. 3600 IN NS ns1.a.example. 3600 IN NS ns2.a.example. 3600 DS 57855 5 1 ( B6DCD485719ADCA18E5F3D48A2331627FDD3 636B ) 3600 RRSIG DS 5 2 3600 20040509183619 ( 20040409183619 38519 example. oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) 3600 NSEC ai.example. NS DS RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) ns1.a.example. 3600 IN A 192.0.2.5 ns2.a.example. 3600 IN A 192.0.2.6 ai.example. 3600 IN A 192.0.2.9 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example.
例。 3600 IN SOA ns1.example。 bugs.x.w.example。 （3600 300 3600000 3600 1081539377）3600 RRSIG SOA 5 1 3600 20040509183619（20040409183619 38519例。ONx0k36rcjaxYtcNgq6iQnpNV5 + drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu / n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S / UN / IbtDq4Ay8NMNLQI7Dw7n4p8 / rjkB jV7j86HyQgM5e7 + miRAz8V01b0I =）3600 NSのns1.example。 3600 NS ns2.example。 3600 RRSIG NS 5 1 3600 20040509183619（20040409183619 38519例。gl13F00f2U0R + SWiXXLHwsMY + qStYy5k6zfd EuivWc + wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q + o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB / FRPGfJPajngcq6Kwg =）3600 MX 1 xx.example。 3600 RRSIG MX 5 1 3600 20040509183619（20040409183619 38519例。HyDHYVT5KHSZ7HtO / vypumPmSZQrcOP3tzWB 2qaKkHVPfau / DgLgS / IKENkYOGL95G4N + NZE VyNU8dcTOckT + ChPcGeVjguQ7a3Ao9Z / ZkUO 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU / IM W6OISukd1EQt7a0kygkg + PEDxdI =）3600 NSECのa.example。 NS SOA MX RRSIG NSEC DNSKEY 3600 RRSIG NSEC 5 1 3600 20040509183619（20040409183619 38519例。O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp / kEowGgBRzY / U =）3600 DNSKEY 256 3 5（AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV rZy / lvI5CQePxXHZS4i8dANH4DX3tbHol61e k8EFMcsGXxKciJFHyhl94C + NwILQdzsUlSFo vBZsyl / NX6yEbtw / xN9ZNcrbYvgjjZ / UVPZI ySFNsgEYvh0z2542lzMKR4Dh8uZffQ ==）3600 DNSKEY 257 3 5（AQOeX7 + baTmvpVHb2CcLnL1dMRWbuscRvHXl LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y / 0QZ syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP RLMlGybr51bOV / 1se0ODacj3DomyB4QB5gKT Yotの/ K9alk5 / j8vfd4jWCWD + E1Sze0Q ==）3600 RRSIG DNSKEY 5 1 3600 20040509183619（20040409183619 9465例。ZxgauAuIj + k1YoVEOSlZfx41fcmKzTFHoweZ xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ Xevoと/ 7nAbo88iWsMkSpSR6jWzYYKwfrBI / L9 hjYmyVO9m6FjQ7uwM4dCP / bIuV / DKqOAK9NY NC3AHfvCV1Tp4VKDqxqG7R5tTVM =）3600 RRSIG DNSKEY 5 1 3600 20040509183619（20040409183619 38519の例。 eGL0s90glUqcOmloo / 2Y + bSzyEfKVOQViD9Z DNhLz / Yn9CQZlDVRJffACQDAUhXpU / oP34ri bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp eFIku28Vqfr8Nt7cigZLxjK + u0Ws / 4lIRjKk 7z5OXogYVaFzHKillDt3HRxHIZM =）a.example。 3600 IN NS ns1.a.example。 3600 IN NS ns2.a.example。 3600 DS（20040409183619 38519例。oXIKit / QtdG64J / CB + Gi8dOvnwRvqrto1AdQ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX / FM + v6ccF2EGNLRiY08kdkz + XHHo =）57855 5 1（B6DCD485719ADCA18E5F3D48A2331627FDD3 636B）3600 RRSIG DS 5 2 3600 20040509183619 3600 NSECのai.example。 NS DS RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519例。cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 039 / cRUs6Jk / 25 + fi7Xr5nOVJsb0lq4zsB3I BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g sdkOW6Zyqtz3Zos8N0BBkEx + 2G4 =）ns1.a.example。 3600 IN A 192.0.2.5 ns2.a.example。 3600 IN A 192.0.2.6 ai.example。 3600 IN A 192.0.2.9 3600 RRSIG A 5 2 3600 20040509183619（20040409183619 38519の例。
pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) 3600 HINFO "KLH-10" "ITS" 3600 RRSIG HINFO 5 2 3600 20040509183619 ( 20040409183619 38519 example. Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) 3600 AAAA 2001:db8::f00:baa9 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 sZM6QjBBLmukH30+w1z3h8PUP2o= ) 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL AhS+JOVfDI/79QtyTI0SaDWcg8U= ) b.example. 3600 IN NS ns1.b.example. 3600 IN NS ns2.b.example. 3600 NSEC ns1.example. NS RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE= ) ns1.b.example. 3600 IN A 192.0.2.7 ns2.b.example. 3600 IN A 192.0.2.8 ns1.example. 3600 IN A 192.0.2.1 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK v/iVXSYC0b7mPSU+EOlknFpVECs= ) 3600 NSEC ns2.example. A RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) ns2.example. 3600 IN A 192.0.2.2 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) 3600 NSEC *.w.example. A RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) *.w.example. 3600 IN MX 1 ai.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( 20040409183619 38519 example. OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 4kX18MMR34i8lC36SR5xBni8vHI= ) 3600 NSEC x.w.example. MX RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 s1InQ2UoIv6tJEaaKkP701j8OLA= ) x.w.example. 3600 IN MX 1 xx.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( 20040409183619 38519 example. Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) 3600 NSEC x.y.w.example. MX RRSIG NSEC 3600 RRSIG NSEC 5 3 3600 20040509183619 ( 20040409183619 38519 example. aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e IjgiM8PXkBQtxPq37wDKALkyn7Q= ) x.y.w.example. 3600 IN MX 1 xx.example. 3600 RRSIG MX 5 4 3600 20040509183619 ( 20040409183619 38519 example. k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb +gLcMZBnHJ326nb/TOOmrqNmQQE= ) 3600 NSEC xx.example. MX RRSIG NSEC 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 20040409183619 38519 example. OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) xx.example. 3600 IN A 192.0.2.10 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx kbIDV6GPPSZVusnZU6OMgdgzHV4= ) 3600 HINFO "KLH-10" "TOPS-20" 3600 RRSIG HINFO 5 2 3600 20040509183619 ( 20040409183619 38519 example. GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ RgNvuwbioFSEuv2pNlkq0goYxNY= ) 3600 AAAA 2001:db8::f00:baaa 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ xS9cL2QgW7FChw16mzlkH6/vsfs= ) 3600 NSEC example. A HINFO AAAA RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W GghLahumFIpg4MO3LS/prgzVVWo= )
pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 6zrTpg9FkS0XGVmYRvOTNYx2HvQ =）3600 HINFO "KLH-10"、 "ITS" 3600 RRSIG HINFO 5 2 3600 20040509183619（20040409183619 38519例。Iqと/ RGCbBdKzcYzlGE4ovbr5YcB + ezxbZ9W0l E / 7WqyvhOO9J16HxhhL7VY / IKmTUY0GGdcfh ZEOCkf4lEykZF9NPok1 / R / fWrtzNp8jobuY7 AZEcZadp1WdDF3jc2 / ndCa5XZhLKD3JzOsBw FvL8sqlS5QS6FY / ijFEDnI4RkZA =）3600 AAAA 2001：DB8 :: F00：baa9 3600 RRSIG AAAA 5 2 3600 20040509183619（20040409183619 38519例nLcpFuXdT35AcE + EoafOUkl69KB + / e56XmFK kewXG2IadYLKAOBIoR5 + VoQV3XgTcofTJNsh 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T cMmDwV / hWFKsbGBsj8xSCN / caEL2CWY / 5XP2 sZM6QjBBLmukH30 + w1z3h8PUP2o =）3600 NSEC b.example 。 HINFO AAAA RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519例。QoshyPevLcJ / xcRpEtMft1uoIrcrieVcc9pG CScIn5Glnib40T6ayVOimXwdSTZ / 8ISXGj4p P8Sh0PlA6olZQ84L453 / BUqB8BpdOGky4hsN 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm + wpFL AHS + JOVfDI / 79QtyTI0SaDWcg8U =）b.example。 3600 IN NS ns1.b.example。 3600 IN NS ns2.b.example。 3600 NSEC ns1.example。 NS RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519例。GNuxHn844wfmUhPzGWKJCPY5ttEX / RfjDoOx 9ueK1PtYkOWKOOdiJ / PJKCYB3hYX + 858dDWS xb2qnV / LSTCNVBnkm6owOpysY97MVj5VQEWs 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE =）ns1.b.example。 3600 IN A 192.0.2.7 ns2.b.example。 3600 IN A 192.0.2.8 ns1.example。 192.0.2.1 3600 RRSIG A 5 2 3600 20040509183619（20040409183619 38519例。F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 5pGhp82pzhAOMZ3K22JnmK4c + IjUeFp / TO06 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB + + iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK V / iVXSYC0b7mPSU + EOlknFpVECs =）3600 NSECのns2.example IN 3600。 RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519例。I4hj + KT6 + 8rCcHcUdolks2S + Wzri9h3fHas8 1rGN / eILdJHN7JpV6lLGPIh / 8fIBkfvdyWnB jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq ZIaLi8Qr2XHkjq38BeQsbp8X0 + 6h4ETWSGT8 IZaIGBLryQWGLw6Y6X8dqhlnxJM =）ns2.example。 192.0.2.2 3600 RRSIG A 5 2 3600 20040509183619 IN 3600（20040409183619 38519例。V7cQRw1TR + knlaL1z / psxlS1PcD37JJDaCMq Qo6 / u1qFQu6x + wuDHRH22Ap9ulJPQjFwMKOu yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 6 amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq rdhx8SZ0yy4ObIRzIzvBFLiSS8o =）3600 NSEC *の.w.example。 RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519例。N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb 3QbeJ5Dfb2V9NGCHj / OVF / LBxFFWwhLwzngH L + bQAgAcMsLu / nL3nDi1y / JSQjAcdZNDl4bw Ymx28EtgIpo9A0qmP08rMBqs1Jw =）* .w.example。 3600 IN MX 1 ai.example。 3600 RRSIG MX 5 2 3600 20040509183619（20040409183619 38519例。OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc tvOQ2ofO7AZJ + d01EeeQTVBPq4 / 6KCWhqe2X TjnkVLNvvhnc0u28aoSsG0 + 4InvkkOHknKxw 4kX18MMR34i8lC36SR5xBni8vHI =）3600 NSECのx.w.example。 MX RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519例。R / mZnRC3I / VIcrelgIcteSxDhtsdlTDt8ng9 HSBlABOlzLxQtfgTnn8f + aOwJIAFe1Ee5RvU 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 91gsmcV / 1V9 / bZAG55CefP9cM4Z9Y9NT9XQ8 s1InQ2UoIv6tJEaaKkP701j8OLA =）x.w.example。 3600 IN MX 1 xx.example。 3600 RRSIG MX 5 3 3600 20040509183619（20040409183619 38519例。Il2WTZ + BKV + OytBx4LItNW5mjB4RCwhOO8y1 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I kx70ePCoFgRz1Yq + bVVXCvGuAU4xALv3W / Y1 jNSlwZ2mSWKHfxFQxPtLj8s32 + K =）3600 NSECのx.y.w.example。 MX RRSIG NSEC 3600 RRSIG NSEC 5 3 3600 20040509183619（20040409183619 38519例。aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK vw8J0tZEUNQByH5Qfnf5N1FqH / pS46UA7A4E mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI NJuBba / VHM + pebTbKcAPIvL9tBOoh + to1h6e IjgiM8PXkBQtxPq37wDKALkyn7Q =）x.y.w.example。 3600 IN MX 1 xx.example。 3600 RRSIG MX 5 4 3600 20040509183619（20040409183619 38519例。k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia t7i9t7nbX / e0FPnvDSQXzcK7UL + zrVA + 3MDj q1ub4q3SZgcbLMgexxIW3Va // LVrxkP6Xupq GtOB9prkK54QTl / qZTXfMQpW480YOvVknhvb + gLcMZBnHJ326nb / TOOmrqNmQQE =）3600 NSECのxx.example。 MX RRSIG NSEC 3600 RRSIG NSEC 5 4 3600 20040509183619（20040409183619 38519例。OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf / LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm / jJkn3jk =）xx.example。 192.0.2.10 3600 RRSIG A 5 2 3600 20040509183619 IN 3600（20040409183619 38519の例では。kBF4YxMGWF0D8r0cztL + 2fWWOvN1U / GYSpYP 7SoKoNQ4fZKyk + weWGlKLIUM + uE1zjVTPXoa 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq + Y VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx kbIDV6GPPSZVusnZU6OMgdgzHV4 =）3600 HINFO "KLH-10" "" 3600 RRSIG HINFO-20 TOPS 5 2 3600 20040509183619（20040409183619 38519例GY2PLSXmMHkWHfLdggiox8 + chWpeMNJLkML0 T + U / SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq BcPZ6EqrF + vl5v5oGuvSF7U52epfVTC + wWF8 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8 / WI + RgNvuwbioFSEuv2pNlkq0goYxNY =。）3600 AAAA 2001：DB8 :: F00：baaa 3600 RRSIG AAAA 5 2 3600 20040509183619（20040409183619 38519例。 Zzj0yodDxcBLnnOIw
The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA Flags indicate that each of these DNSKEY RRs is a zone key. One of these DNSKEY RRs also has the SEP flag set and has been used to sign the apex DNSKEY RRset; this is the key that should be hashed to generate a DS record to be inserted into the parent zone. The other DNSKEY is used to sign all the other RRsets in the zone.
頂点DNSKEYセットには2つのDNSKEY RRが含まれ、DNSKEY RDATAフラグは、これらのDNSKEY RRのそれぞれがゾーンキーであることを示します。 これらのDNSKEY RRの1つにもSEPフラグが設定されており、apex DNSKEY RRsetの署名に使用されています。 これは、親ゾーンに挿入されるDSレコードを生成するためにハッシュされる必要があるキーです。 他のDNSKEYは、ゾーン内の他のすべてのRRsetに署名するために使用されます。
The zone includes a wildcard entry, "*.w.example". Note that the name "*.w.example" is used in constructing NSEC chains, and that the RRSIG covering the "*.w.example" MX RRset has a label count of 2.
ゾーンには、ワイルドカードエントリ「* .w.example」が含まれます。 NSECチェーンの構築には「* .w.example」という名前が使用され、「*。w.example」MX RRsetをカバーするRRSIGのラベルカウントは2であることに注意してください。
The zone also includes two delegations. The delegation to "b.example" includes an NS RRset, glue address records, and an NSEC RR; note that only the NSEC RRset is signed. The delegation to "a.example" provides a DS RR; note that only the NSEC and DS RRsets are signed.
ゾーンには2つの委任も含まれます。 「b.example」への委任には、NS RRset、グルーアドレスレコード、およびNSEC RRが含まれます。 NSEC RRsetのみが署名されることに注意してください。 「a.example」への委任はDS RRを提供します。 NSECおよびDS RRsetのみが署名されることに注意してください。
Appendix B. Example Responses
付録B.応答の例
The examples in this section show response messages using the signed zone example in Appendix A.
このセクションの例は、付録Aの署名済みゾーンの例を使用した応答メッセージを示しています。
B.1. Answer
B.1。 回答
A successful query to an authoritative server.
権限のあるサーバーへの正常なクエリ。
;; Header: QR AA DO RCODE=0 ;; ;; Question x.w.example. IN MX
;; ヘッダー：QR AA DO RCODE = 0 ;; ;; 質問x.w.example。 MXで
;; Answer x.w.example. 3600 IN MX 1 xx.example. x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( 20040409183619 38519 example. Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
;; x.w.exampleと答えます。 3600 IN MX 1 xx.example。 x.w.example。3600 RRSIG MX53360020040509183619（2004040918361938519例。Il2WTZ+ BKV+ OytBx4LItNW5mjB4RCwhOO8y1 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I kx70ePCoFgRz1Yq+ bVVXCvGuAU4xALv3W/ Y1 jNSlwZ2mSWKHfxFQxPtLj8s32+ K=）
;; Authority example. 3600 NS ns1.example. example. 3600 NS ns2.example. example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 20040409183619 38519 example. gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
;; 権限の例。 3600 NS ns1.example。 例。 3600 NS ns2.example。 例。3600 RRSIG NS51360020040509183619（2004040918361938519例。gl13F00f2U0R+ SWiXXLHwsMY+ qStYy5k6zfd EuivWc+ wd1fmbNCyql0Tk7lHTX6UOxc8AgNf4ISFve8XqF4q+ o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv480HjMeRaZB/ FRPGfJPajngcq6Kwg=）
;; Additional xx.example. 3600 IN A 192.0.2.10 xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx kbIDV6GPPSZVusnZU6OMgdgzHV4= ) xx.example. 3600 AAAA 2001:db8::f00:baaa xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ xS9cL2QgW7FChw16mzlkH6/vsfs= ) ns1.example. 3600 IN A 192.0.2.1 ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK v/iVXSYC0b7mPSU+EOlknFpVECs= ) ns2.example. 3600 IN A 192.0.2.2 ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
;;追加のxx.example。 3600 IN A 192.0.2.10 xx.example。 3600 RRSIG A 5 2 3600 20040509183619（20040409183619 38519例。kBF4YxMGWF0D8r0cztL + 2fWWOvN1U / GYSpYP 7SoKoNQ4fZKyk + weWGlKLIUM + uE1zjVTPXoa 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq + Y VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx kbIDV6GPPSZVusnZU6OMgdgzHV4 =）xx.example。 3600 AAAA 2001：db8 :: f00：baaa xx.example。 3600 RRSIG AAAA 5 2 3600 20040509183619（20040409183619 38519例。Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA + rDz9stmSBP / 4PekH / x2IoAYnwctd / xS9cL2QgW7FChw16mzlkH6 / vsfs =）ns1.example。 3600 IN A 192.0.2.1 ns1.example。 3600 RRSIG A 5 2 3600 20040509183619（20040409183619 38519例。F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 5pGhp82pzhAOMZ3K22JnmK4c + IjUeFp / TO06 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB + + iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK V / iVXSYC0b7mPSU + EOlknFpVECs =）ns2.example。 3600 IN A 192.0.2.2 ns2.example。 3600 RRSIG A 5 2 3600 20040509183619（20040409183619 38519例。V7cQRw1TR + knlaL1z / psxlS1PcD37JJDaCMq Qo6 / u1qFQu6x + wuDHRH22Ap9ulJPQjFwMKOu yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 6 amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq rdhx8SZ0yy4ObIRzIzvBFLiSS8o =）
B.2. Name Error
B.2。 名前エラー
An authoritative name error. The NSEC RRs prove that the name does not exist and that no covering wildcard exists.
正式な名前エラー。 NSEC RRは、名前が存在せず、カバーするワイルドカードが存在しないことを証明します。
;; Header: QR AA DO RCODE=3 ;; ;; Question ml.example. IN A
;; ヘッダー：QR AA DO RCODE = 3 ;; ;; 質問ml.example。 で
;; Answer ;; (empty)
;; 回答;; （空の）
;; Authority example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) b.example. 3600 NSEC ns1.example. NS RRSIG NSEC b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE= ) example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 20040409183619 38519 example. O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U= )
;; 権限の例。 3600 IN SOA ns1.example。 bugs.x.w.example。 （1081539377 3600 300 3600000 3600）例。3600 RRSIG SOA51360020040509183619（2004040918361938519例。ONx0k36rcjaxYtcNgq6iQnpNV5+ drqYAsC9h7TSJaHCqbhE67Sr6aH2xDUGcqQWu/ n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/ UN / IbtDq4Ay8NMNLQI7Dw7n4p8/ rjkB jV7j86HyQgM5e7+ miRAz8V01b0I=）b.example。 3600 NSEC ns1.example。 NS RRSIG NSEC b.example。3600 RRSIG NSEC52360020040509183619（2004040918361938519例。GNuxHn844wfmUhPzGWKJCPY5ttEX/ RfjDoOx9ueK1PtYkOWKOOdiJ/ PJKCYB3hYX+858dDWS xb2qnV/ LSTCNVBnkm6owOpysY97MVj5VQEWs0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE=）の例。 3600 NSEC a.example。 NS SOA MX RRSIG NSEC DNSKEYの例。3600 RRSIG NSEC51360020040509183619（2004040918361938519例。O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/ kEowGgBRzY/ U=）
;; Additional ;; (empty)
;; 追加;; （空の）
B.3. No Data Error
B.3。 データエラーなし
A "no data" response. The NSEC RR proves that the name exists and that the requested RR type does not.
「データなし」応答。 NSEC RRは、名前が存在し、要求されたRRタイプが存在しないことを証明します。
;; Header: QR AA DO RCODE=0 ;; ;; Question ns1.example. IN MX
;; ヘッダー：QR AA DO RCODE = 0 ;; ;; 質問ns1.example。 MXで
;; Answer ;; (empty)
;; 回答;; （空の）
;; Authority example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
;; 権限の例。 3600 IN SOA ns1.example。 bugs.x.w.example。 （1081539377 3600 300 3600000 3600）例。3600 RRSIG SOA51360020040509183619（2004040918361938519例。ONx0k36rcjaxYtcNgq6iQnpNV5+ drqYAsC9h7TSJaHCqbhE67Sr6aH2xDUGcqQWu/ n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/ UN / IbtDq4Ay8NMNLQI7Dw7n4p8/ rjkB jV7j86HyQgM5e7+ miRAz8V01b0I=）ns1.example。 3600 NSEC ns2.example。 RRSIG NSEC ns1.example。3600 RRSIG NSEC52360020040509183619（2004040918361938519例。I4hj+ KT6+8rCcHcUdolks2S+ Wzri9h3fHas81rGN/ eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 IZaIGBLryQWGLw6Y6X8dqhlnxJM=）
;; Additional ;; (empty)
;; 追加;; （空の）
B.4. Referral to Signed Zone
B.4。 署名済みゾーンへの紹介
Referral to a signed zone. The DS RR contains the data which the resolver will need to validate the corresponding DNSKEY RR in the child zone's apex.
署名済みゾーンへの紹介。 DS RRには、リゾルバが子ゾーンの頂点にある対応するDNSKEY RRを検証するために必要なデータが含まれています。
;; Header: QR DO RCODE=0 ;;
;; ヘッダー：QR DO RCODE = 0 ;;
;; Question mc.a.example. IN MX
;; 質問mc.a.example。 MXで
;; Answer ;; (empty)
;; 回答;; （空の）
;; Authority a.example. 3600 IN NS ns1.a.example. a.example. 3600 IN NS ns2.a.example. a.example. 3600 DS 57855 5 1 ( B6DCD485719ADCA18E5F3D48A2331627FDD3 636B ) a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( 20040409183619 38519 example. oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
;; 機関a.example。 3600 IN NS ns1.a.example。 a.example。 3600 IN NS ns2.a.example。 a.example。 3600 DS 57855 5 1（B6DCD485719ADCA18E5F3D48A2331627FDD3 636B）a.example。3600 RRSIG DS52360020040509183619（2004040918361938519例。oXIKit/ QtdG64J/ CB+ Gi8dOvnwRvqrto1AdQ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ FM+ v6ccF2EGNLRiY08kdkz+ XHHo=）
;; Additional ns1.a.example. 3600 IN A 192.0.2.5 ns2.a.example. 3600 IN A 192.0.2.6
;; 追加のns1.a.example。 3600 IN A 192.0.2.5 ns2.a.example。 3600 IN A 192.0.2.6
B.5. Referral to Unsigned Zone
B.5。 署名なしゾーンへの紹介
Referral to an unsigned zone. The NSEC RR proves that no DS RR for this delegation exists in the parent zone.
署名されていないゾーンへの紹介。 NSEC RRは、この委任のDS RRが親ゾーンに存在しないことを証明します。
;; Header: QR DO RCODE=0 ;; ;; Question mc.b.example. IN MX
;; ヘッダー：QR DO RCODE = 0 ;; ;; 質問mc.b.example。 MXで
;; Answer ;; (empty)
;; 回答;; （空の）
;; Authority b.example. 3600 IN NS ns1.b.example. b.example. 3600 IN NS ns2.b.example. b.example. 3600 NSEC ns1.example. NS RRSIG NSEC b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE= )
;; 権限b.example。 3600 IN NS ns1.b.example。 b.example。 3600 IN NS ns2.b.example。 b.example。 3600 NSEC ns1.example。 NS RRSIG NSEC b.example。3600 RRSIG NSEC52360020040509183619（2004040918361938519例。GNuxHn844wfmUhPzGWKJCPY5ttEX/ RfjDoOx9ueK1PtYkOWKOOdiJ/ PJKCYB3hYX+858dDWS xb2qnV/ LSTCNVBnkm6owOpysY97MVj5VQEWs0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE=）
;; Additional ns1.b.example. 3600 IN A 192.0.2.7 ns2.b.example. 3600 IN A 192.0.2.8
;; 追加のns1.b.example。 3600 IN A 192.0.2.7 ns2.b.example。 3600 IN A 192.0.2.8
B.6. Wildcard Expansion
B.6。 ワイルドカード拡張
A successful query that was answered via wildcard expansion. The label count in the answer's RRSIG RR indicates that a wildcard RRset was expanded to produce this response, and the NSEC RR proves that no closer match exists in the zone.
ワイルドカード展開を介して応答された成功したクエリ。 回答のRRSIG RRのラベルカウントは、ワイルドカードRRsetがこの応答を生成するために拡張されたことを示し、NSEC RRはゾーンに一致するものが存在しないことを証明します。
;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN MX
;; ヘッダー：QR AA DO RCODE = 0 ;; ;; 質問a.z.w.example。 MXで
;; Answer a.z.w.example. 3600 IN MX 1 ai.example. a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( 20040409183619 38519 example. OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 4kX18MMR34i8lC36SR5xBni8vHI= )
;; a.z.w.exampleと答えてください。 3600 IN MX 1 ai.example。 a.z.w.example。3600 RRSIG MX52360020040509183619（2004040918361938519例。OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc tvOQ2ofO7AZJ+ d01EeeQTVBPq4/6KCWhqe2X TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw4kX18MMR34i8lC36SR5xBni8vHI=）
;; Authority example. 3600 NS ns1.example. example. 3600 NS ns2.example. example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 20040409183619 38519 example. gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 20040409183619 38519 example. OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
;; 権限の例。 3600 NS ns1.example。 例。 3600 NS ns2.example。 例。3600 RRSIG NS51360020040509183619（2004040918361938519例。gl13F00f2U0R+ SWiXXLHwsMY+ qStYy5k6zfd EuivWc+ wd1fmbNCyql0Tk7lHTX6UOxc8AgNf4ISFve8XqF4q+ o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv480HjMeRaZB/ FRPGfJPajngcq6Kwg=）x.y.w.example。 3600 NSEC xx.example。 MX RRSIG NSEC x.y.w.example。3600 RRSIG NSEC54360020040509183619（2004040918361938519例。OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/ LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/ jJkn3jk=）
;; Additional ai.example. 3600 IN A 192.0.2.9 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
;; 追加のai.example。 3600 IN A 192.0.2.9 ai.example。 3600 RRSIG A 5 2 3600 20040509183619（
20040409183619 38519 example. pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) ai.example. 3600 AAAA 2001:db8::f00:baa9 ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 sZM6QjBBLmukH30+w1z3h8PUP2o= )
20040409183619 38519の例。 pAOz 3600 AAAA 2001：db8 :: f00：baa9 ai.example。3600 RRSIG AAAA52360020040509183619（2004040918361938519例。nLcpFuXdT35AcE+ EoafOUkl69KB+/ e56XmFK kewXG2IadYLKAOBIoR5+ VoQV3XgTcofTJNsh1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T cMmDwV/ hWFKsbGBsj8xSCN/ caEL2CWY/5XP2 sZM6QjBBLmukH30+ w1z3h8PUP2o=）
B.7. Wildcard No Data Error
B.7。 ワイルドカードデータなしエラー
A "no data" response for a name covered by a wildcard. The NSEC RRs prove that the matching wildcard name does not have any RRs of the requested type and that no closer match exists in the zone.
ワイルドカードで覆われた名前の「データなし」応答。 NSEC RRは、一致するワイルドカード名に要求されたタイプのRRがないこと、およびゾーンに一致するものが存在しないことを証明します。
;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN AAAA
;; ヘッダー：QR AA DO RCODE = 0 ;; ;; 質問a.z.w.example。 AAAAで
;; Answer ;; (empty)
;; 回答;; （空の）
;; Authority example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 20040409183619 38519 example. OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
;; 権限の例。 3600 IN SOA ns1.example。 bugs.x.w.example。 （1081539377 3600 300 3600000 3600）例。3600 RRSIG SOA51360020040509183619（2004040918361938519例。ONx0k36rcjaxYtcNgq6iQnpNV5+ drqYAsC9h7TSJaHCqbhE67Sr6aH2xDUGcqQWu/ n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/ UN / IbtDq4Ay8NMNLQI7Dw7n4p8/ rjkB jV7j86HyQgM5e7+ miRAz8V01b0I=）x.y.w.example。 3600 NSEC xx.example。 MX RRSIG NSEC x.y.w.example。 3600 RRSIG NSEC 5 4 3600 20040509183619（20040409183619 38519の例。OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 s1InQ2UoIv6tJEaaKkP701j8OLA= )
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf / LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5VkQka / jk.mj.mj.jjmkjjmjjmjjmjjmjjmjjmjjmjjmkjjmjjmkjjmjjmjjmkjjmjjmjjmjjmkjjmjjmjjmmjjmjjmjjmjjmjjmmjjmjjmjjmmjjmmjjmjjmjjmjjmjjmjjmjjmjjmjjmjjmjjmjjmjjmjjmjjmjjmjjjmjjmjjjmjjmjjmjmjjmjjmjjkjjm 3600 NSEC x.w.example。 MX RRSIG NSEC * .w.example。3600 RRSIG NSEC52360020040509183619（2004040918361938519例。R/ mZnRC3I/ VIcrelgIcteSxDhtsdlTDt8ng9 HSBlABOlzLxQtfgTnn8f+ aOwJIAFe1Ee5RvU5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx91gsmcV/1V9/ bZAG55CefP9cM4Z9Y9NT9XQ8 s1InQ2UoIv6tJEaaKkP701j8OLA=）
;; Additional ;; (empty)
;; 追加;; （空の）
B.8. DS Child Zone No Data Error
B.8。 DS子ゾーンのデータエラーなし
A "no data" response for a QTYPE=DS query that was mistakenly sent to a name server for the child zone.
子ゾーンのネームサーバーに誤って送信されたQTYPE = DSクエリの「データなし」応答。
;; Header: QR AA DO RCODE=0 ;; ;; Question example. IN DS
;; ヘッダー：QR AA DO RCODE = 0 ;; ;; 質問の例。 DSで
;; Answer ;; (empty)
;; 回答;; （空の）
;; Authority example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 20040409183619 38519 example. O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
;; 権限の例。 3600 IN SOA ns1.example。 bugs.x.w.example。 （1081539377 3600 300 3600000 3600）例。3600 RRSIG SOA51360020040509183619（2004040918361938519例。ONx0k36rcjaxYtcNgq6iQnpNV5+ drqYAsC9h7TSJaHCqbhE67Sr6aH2xDUGcqQWu/ n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/ UN / IbtDq4Ay8NMNLQI7Dw7n4p8/ rjkB jV7j86HyQgM5e7+ miRAz8V01b0I=）の例。 3600 NSEC a.example。 NS SOA MX RRSIG NSEC DNSKEYの例。 3600 RRSIG NSEC 5 1 3600 20040509183619（20040409183619 38519の例。O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
jfFJ5arXf4nPxp/kEowGgBRzY/U= )
;; Additional ;; (empty)
;; 追加;; （空の）
Appendix C. Authentication Examples
付録C.認証の例
The examples in this section show how the response messages in Appendix B are authenticated.
このセクションの例は、付録Bの応答メッセージがどのように認証されるかを示しています。
C.1. Authenticating an Answer
C.1。 回答の認証
The query in Appendix B.1 returned an MX RRset for "x.w.example.com". The corresponding RRSIG indicates that the MX RRset was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. The resolver needs the corresponding DNSKEY RR in order to authenticate this answer. The discussion below describes how a resolver might obtain this DNSKEY RR.
付録B.1のクエリは、「x.w.example.com」のMX RRsetを返しました。 対応するRRSIGは、アルゴリズム5とキータグ38519を使用した「例」DNSKEYによってMX RRsetが署名されたことを示します。リゾルバは、この回答を認証するために対応するDNSKEY RRを必要とします。 以下の説明では、リゾルバがこのDNSKEY RRを取得する方法について説明します。
The RRSIG indicates the original TTL of the MX RRset was 3600, and, for the purpose of authentication, the current TTL is replaced by 3600. The RRSIG labels field value of 3 indicates that the answer was not the result of wildcard expansion. The "x.w.example.com" MX RRset is placed in canonical form, and, assuming the current time falls between the signature inception and expiration dates, the signature is authenticated.
RRSIGは、MX RRsetの元のTTLが3600であることを示し、認証のために、現在のTTLが3600に置き換えられます。RRSIGラベルフィールド値3は、回答がワイルドカード拡張の結果ではなかったことを示します。 「x.w.example.com」MX RRsetは正規の形式で配置され、現在の時刻が署名の開始日と有効期限の間にあると仮定して、署名が認証されます。
C.1.1. Authenticating the Example DNSKEY RR
C.1.1。 サンプルDNSKEY RRの認証
This example shows the logical authentication process that starts from the a configured root DNSKEY (or DS RR) and moves down the tree to authenticate the desired "example" DNSKEY RR. Note that the logical order is presented for clarity. An implementation may choose to construct the authentication as referrals are received or to construct the authentication chain only after all RRsets have been obtained, or in any other combination it sees fit. The example here demonstrates only the logical process and does not dictate any implementation rules.
この例は、構成されたルートDNSKEY（またはDS RR）から開始し、ツリーを下に移動して目的の「例」DNSKEY RRを認証する論理認証プロセスを示しています。 明確にするために、論理的な順序が示されていることに注意してください。 実装は、紹介が受信されたときに認証を構築するか、すべてのRRsetが取得された後にのみ認証チェーンを構築するか、または適切と思われる他の組み合わせで選択することができます。 ここでの例は、論理プロセスのみを示しており、実装規則を規定するものではありません。
We assume the resolver starts with a configured DNSKEY RR for the root zone (or a configured DS RR for the root zone). The resolver checks whether this configured DNSKEY RR is present in the root DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY RRset, and whether the signature lifetime is valid. If all these conditions are met, all keys in the DNSKEY RRset are considered authenticated. The resolver then uses one (or more) of the root DNSKEY RRs to authenticate the "example" DS RRset. Note that the resolver may have to query the root zone to obtain the root DNSKEY RRset or "example" DS RRset.
リゾルバーは、ルートゾーン用に構成されたDNSKEY RR（またはルートゾーン用に構成されたDS RR）で始まると想定しています。 リゾルバーは、この設定されたDNSKEY RRがルートDNSKEY RRsetに存在するかどうか（またはDS RRがルートDNSKEY RRsetのDNSKEYと一致するかどうか）、このDNSKEY RRがルートDNSKEY RRsetに署名したかどうか、署名の有効期間が有効かどうかをチェックします。 これらすべての条件が満たされている場合、DNSKEY RRset内のすべてのキーは認証されたと見なされます。 次に、リゾルバーは1つ（または複数）のルートDNSKEY RRを使用して、「サンプル」DS RRsetを認証します。 リゾルバーは、ルートDNSKEY RRsetまたは「サンプル」DS RRsetを取得するために、ルートゾーンを照会する必要があることに注意してください。
Once the DS RRset has been authenticated using the root DNSKEY, the resolver checks the "example" DNSKEY RRset for some "example" DNSKEY RR that matches one of the authenticated "example" DS RRs. If such a matching "example" DNSKEY is found, the resolver checks whether this DNSKEY RR has signed the "example" DNSKEY RRset and the signature lifetime is valid. If these conditions are met, all keys in the "example" DNSKEY RRset are considered authenticated.
ルートDNSKEYを使用してDS RRsetが認証されると、リゾルバーは、認証された「サンプル」DS RRのいずれかに一致する「サンプル」DNSKEY RRの「サンプル」DNSKEY RRsetをチェックします。 このような一致する「例」DNSKEYが見つかった場合、リゾルバは、このDNSKEY RRが「例」DNSKEY RRsetに署名し、署名の有効期間が有効かどうかを確認します。 これらの条件が満たされている場合、「例」のDNSKEY RRset内のすべてのキーは認証されたと見なされます。
Finally, the resolver checks that some DNSKEY RR in the "example" DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY is used to authenticate the RRSIG included in the response. If multiple "example" DNSKEY RRs match this algorithm and key tag, then each DNSKEY RR is tried, and the answer is authenticated if any of the matching DNSKEY RRs validate the signature as described above.
最後に、リゾルバーは「例」のDNSKEY RRsetの一部のDNSKEY RRがアルゴリズム5を使用し、38519のキータグを持っていることを確認します。このDNSKEYは、応答に含まれるRRSIGを認証するために使用されます 複数の「例」DNSKEY RRがこのアルゴリズムとキータグに一致する場合、各DNSKEY RRが試行され、一致するDNSKEY RRのいずれかが上記のように署名を検証すると、回答が認証されます。
C.2. Name Error
C.2。 名前エラー
The query in Appendix B.2 returned NSEC RRs that prove that the requested data does not exist and no wildcard applies. The negative reply is authenticated by verifying both NSEC RRs. The NSEC RRs are authenticated in a manner identical to that of the MX RRset discussed above.
付録B.2のクエリは、要求されたデータが存在せず、ワイルドカードが適用されないことを証明するNSEC RRを返しました。 否定応答は、両方のNSEC RRを検証することにより認証されます。 NSEC RRは、前述のMX RRsetと同じ方法で認証されます。
C.3. No Data Error
C.3。 データエラーなし
The query in Appendix B.3 returned an NSEC RR that proves that the requested name exists, but the requested RR type does not exist. The negative reply is authenticated by verifying the NSEC RR. The NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above.
付録B.3のクエリは、要求された名前が存在することを証明するNSEC RRを返しましたが、要求されたRRタイプは存在しません。 NSEC RRを確認することにより、否定応答が認証されます。 NSEC RRは、前述のMX RRsetと同じ方法で認証されます。
C.4. Referral to Signed Zone
C.4。 署名済みゾーンへの紹介
The query in Appendix B.4 returned a referral to the signed "a.example." zone. The DS RR is authenticated in a manner identical to that of the MX RRset discussed above. This DS RR is used to authenticate the "a.example" DNSKEY RRset.
付録B.4のクエリは、署名された「a.example」への紹介を返しました。 ゾーン。 DS RRは、前述のMX RRsetと同じ方法で認証されます。 このDS RRは、「a.example」DNSKEY RRsetの認証に使用されます。
Once the "a.example" DS RRset has been authenticated using the "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset for some "a.example" DNSKEY RR that matches the DS RR. If such a matching "a.example" DNSKEY is found, the resolver checks whether this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether the signature lifetime is valid. If all these conditions are met, all keys in the "a.example" DNSKEY RRset are considered authenticated.
「example」DNSKEYを使用して「a.example」DS RRsetが認証されると、リゾルバは「a.example」DNSKEY RRsetでDS RRと一致する「a.example」DNSKEY RRをチェックします。 そのような一致する「a.example」DNSKEYが見つかった場合、リゾルバは、このDNSKEY RRが「a.example」DNSKEY RRsetに署名したかどうか、および署名の有効期間が有効かどうかをチェックします。 これらすべての条件が満たされている場合、「a.example」DNSKEY RRset内のすべてのキーは認証されたと見なされます。
C.5. Referral to Unsigned Zone
C.5。 署名なしゾーンへの紹介
The query in Appendix B.5 returned a referral to an unsigned "b.example." zone. The NSEC proves that no authentication leads from "example" to "b.example", and the NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above.
付録B.5のクエリは、署名されていない「b.example」への紹介を返しました。 ゾーン。 NSECは、「example」から「b.example」への認証が行われないことを証明し、NSEC RRは上記のMX RRsetと同じ方法で認証されます。
C.6. Wildcard Expansion
C.6。 ワイルドカード拡張
The query in Appendix B.6 returned an answer that was produced as a result of wildcard expansion. The answer section contains a wildcard RRset expanded as it would be in a traditional DNS response, and the corresponding RRSIG indicates that the expanded wildcard MX RRset was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG indicates that the original TTL of the MX RRset was 3600, and, for the purpose of authentication, the current TTL is replaced by 3600. The RRSIG labels field value of 2 indicates that the answer is the result of wildcard expansion, as the "a.z.w.example" name contains 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset is placed in canonical form, and, assuming that the current time falls between the signature inception and expiration dates, the signature is authenticated.
付録B.6のクエリは、ワイルドカード拡張の結果として生成された回答を返しました。 回答セクションには、従来のDNS応答のように展開されたワイルドカードRRsetが含まれており、対応するRRSIGは、展開されたワイルドカードMX RRsetがアルゴリズム5およびキータグ38519の「例」DNSKEYによって署名されたことを示します。RRSIGは、 MX RRsetの元のTTLは3600であり、認証の目的で、現在のTTLは3600に置き換えられます。RRSIGラベルフィールド値2は、回答が「azwexample」名としてのワイルドカード拡張の結果であることを示します 4つのラベルが含まれます。 「a.z.w.w.example」という名前は「* .w.example」に置き換えられ、MX RRsetは正規の形式で配置され、現在の時刻が署名の開始日と有効期限の間にあると仮定して、署名が認証されます。
The NSEC proves that no closer match (exact or closer wildcard) could have been used to answer this query, and the NSEC RR must also be authenticated before the answer is considered valid.
NSECは、このクエリに回答するために、より厳密な一致（正確またはより厳密なワイルドカード）を使用できなかったことを証明し、回答が有効と見なされる前にNSEC RRも認証する必要があります。
C.7. Wildcard No Data Error
C.7。 ワイルドカードデータなしエラー
The query in Appendix B.7 returned NSEC RRs that prove that the requested data does not exist and no wildcard applies. The negative reply is authenticated by verifying both NSEC RRs.
付録B.7のクエリは、要求されたデータが存在せず、ワイルドカードが適用されないことを証明するNSEC RRを返しました。 否定応答は、両方のNSEC RRを検証することにより認証されます。
C.8. DS Child Zone No Data Error
C.8。 DS子ゾーンのデータエラーなし
The query in Appendix B.8 returned NSEC RRs that shows the requested was answered by a child server ("example" server). The NSEC RR indicates the presence of an SOA RR, showing that the answer is from the child . Queries for the "example" DS RRset should be sent to the parent servers ("root" servers).
付録B.8のクエリは、要求が子サーバー（「サンプル」サーバー）によって応答されたことを示すNSEC RRを返しました。 NSEC RRは、SOA RRの存在を示し、回答が子からのものであることを示します。 「例」のDS RRsetのクエリは、親サーバー（「ルート」サーバー）に送信する必要があります。
Authors' Addresses
著者のアドレス
Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL
Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL
EMail: roy.arends@telin.nl
メール：roy.arends@telin.nl
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City、CA 94063 USA
EMail: sra@isc.org
メール：sra@isc.org
Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Matt Larson VeriSign、Inc. 21345 Ridgetop Circle Dulles、VA 20166-6503アメリカ合衆国
EMail: mlarson@verisign.com
メール：mlarson@verisign.com
Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873
ダンマッセイコロラド州立大学コンピュータサイエンス学部フォートコリンズ、コロラド州80523-1873
EMail: massey@cs.colostate.edu
メール：massey@cs.colostate.edu
Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA
スコットローズ国立標準技術研究所100 Bureau Drive Gaithersburg、MD 20899-8920 USA
EMail: scott.rose@nist.gov
メール：scott.rose@nist.gov
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。