[要約] RFC 4035は、DNSセキュリティ拡張（DNSSEC）のためのプロトコル変更に関する文書です。このRFCは、DNS応答の信頼性と認証を向上させるために、デジタル署名をDNS情報に追加する方法を定義しています。目的は、DNS応答の改ざんを防ぎ、ユーザーが正確な情報を受け取ることを保証することです。利用場面は、インターネット上でのドメイン名解決時にセキュリティを強化する場合です。関連するRFCには、RFC 4033（DNSSECの導入）、RFC 4034（DNSSECのリソースレコード拡張）、およびRFC 3833（DNS脅威分析）などがあります。
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
DNSセキュリティ拡張機能のプロトコル変更
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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 RRSを使用して応答を認証する方法を定義します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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は、署名されたゾーンの概念を紹介します。署名ゾーンには、DNS公開キー（DNSKEY）、リソースレコード署名（RRSIG）、次のセキュア（NSEC）、および（オプションで）代表者署名者（DS）がセクション2.1、2.2、2.3、および2.4で指定されたルールに従って記録されます。それぞれ。このセクションのルールに従ってこれらのレコードを含まないゾーンは、署名されていないゾーンです。
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 RRSが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つ以上のパブリック/プライベートキーペアを生成し、秘密鍵を使用してゾーン内の信頼できるrrsetsに署名します。ゾーンでRRSIG RRSを作成するために使用される各秘密キーについて、ゾーンには、対応する公開キーを含むゾーンDNSKEY RRを含める必要があります。ゾーンキーDNSKEY RRには、フラグRDATAフィールドセットのゾーンキービットが必要です（[RFC4034]のセクション2.1.1を参照）。他のDNS操作に関連付けられているパブリックキーは、ゾーンキーとしてマークされていないが、RRSIGを確認するために使用してはならないDNSKEY RRSに保存される場合があります。
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]).
ゾーン管理者が、セキュリティの島として以外に署名されたゾーンを使用することを意図している場合、ゾーンアペックスには、ゾーンへの安全なエントリポイントとして機能するために、少なくとも1つのDNSKEYRRを含める必要があります。この安全なエントリポイントは、親ゾーンの対応する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ごとに、次の要件を満たす少なくとも1つのRRSIGレコードが必要です。
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タイプのカバーフィールドは、RRSetタイプに等しくなります。
o The RRSIG Original TTL field is equal to the TTL of the RRset.
o RRSIGオリジナル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の所有者名のラベルの数に等しく、nullルートラベルをカウントせず、ワイルドカードの場合は左端のラベルをカウントしません。
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 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].
特定のRRSTのRRSIG RRを構築するプロセスは、[RFC4034]で説明されています。RRSetには、複数のRRSIG RRが関連付けられている場合があります。RRSIG RRSは、署名に含まれるRRSetsに密接に結び付けられているため、RRSIG RRSは、他のすべてのDNS RRタイプとは異なり、RRSETを形成しないことに注意してください。特に、共通の所有者名を持つRRSIG RRSの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自体に署名してはなりません。RRSIGRRに署名しても値が追加されず、署名プロセスで無限のループが作成されるからです。
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 RRSets（つまり、名前をチャイルドゾーンの名前サーバーに委任する親ゾーンのNS RRSets）に署名する必要はありません。代表団に関連付けられた接着アドレスrrsetsに署名してはなりません。
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).
Zone Apex 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 RRSの形式と特定の名前の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 RRSを作成してはなりません。これの主な理由は、同じゾーンの署名されたバージョンと署名されていないバージョンとの間の名前空間の一貫性と、セキュリティ忘却の再帰名サーバーの応答の矛盾を減らすことを望んでいることです。
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レコードは、署名されたゾーンが権威あるすべての名前の所有者名に存在し、署名ゾーンからその子供への代表団の所有者名もあります。接着剤アドレスrrsetsの所有者名に、NSECもRRSIGレコードも（親ゾーンに）存在しません。ただし、NSEC rrsetsは権威あるデータであり、したがって署名されているため、この区別はゾーン署名プロセス中にのみ目に見えるものであることに注意してください。したがって、NSEC RRSetを持つ所有者名は、署名ゾーンにもRRSIG RRSを備えています。
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および親ゾーンに権威あるデータを持っているRRSetsに対応するビットを設定する必要があります。親が信頼できるものではない非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 rrsetsに署名する必要があり、ds rrsetsはゾーンの頂点に表示されてはなりません。
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を指す必要があり、子供のApex 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 RRSTのTTLは、委任NS RRSETのTTL（つまり、DS RRSetを含む同じゾーンからのNS RRSET）と一致する必要があります。
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 RRSetsが必要です。安全な動的更新目的のためにその名前で重要な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 RRSが必要です。この競合を解決するために、この仕様はCNAMEリソースレコードの定義を変更して、NSECおよびRRSIG RRSと共存できるようにします。
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 RRSが必要です。委任されたゾーンが署名され、親ゾーンに認証チェーンを持つことを目指している場合、DS RRも存在する可能性があります。これは、元のDNS仕様（[RFC1034]）の例外であり、ゾーンカットの親の側面にNS rrsetsのみが表示される可能性があると述べています。
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.
この仕様では、元のDNS仕様を更新して、ゾーンカットの親側でNSECおよびDS RRタイプを可能にします。これらの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パケットはソースホストによってのみ断片化できるため、セキュリティ認識名サーバーは、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 Pseudo-RRを含まないDNSクエリを受信した、またはDOが少し明確にしているDNSクエリを受信するセキュリティ対応の名前サーバーは、RRSIG、DNSKEY、およびNSEC RRSを他のRRSETと同様に処理する必要があり、実行していない必要があります。以下で説明する追加の処理。DS RRタイプは、委任ポイントの親ゾーンにのみ存在する独特のプロパティを持っているため、DS RRSは常にセクション3.1.4.1で説明されているように特別な処理が必要です。
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 RRSが自己行動する必要があります） - sonsめに。応答が各クエリに対して常に一貫している限り、名前サーバーへのクエリごとに、名前サーバーは次のいずれかを返すことができます。
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 上記の解釈rrsets。o以下のデリゲーションrrsets。o上記の両方と下の両方のrrsets。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（チェックダイブル）ビットとAD（Authentic Data）ビット。CDビットはリゾルバーによって制御されます。セキュリティ対応の名前サーバーは、クエリからCDビットを対応する応答にコピーする必要があります。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 RRSのCNAME RRSを合成するセキュリティ認識ネームサーバーは、合成されたCNAME RRSの署名を生成してはなりません。
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 PSEUDO-RR DO BIT（[RFC3225]）セットを持つ関連するクエリを受信すると、署名ゾーンのセキュリティ認識権限名サーバーが追加のRRSIG、NSEC、およびDS RRSを含める必要があります。次のルールに：
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 RRSは、セクション3.1.1のルールに従って応答に含める必要があります。
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のルールに従って応答に自動的に含める必要があります。
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またはNSEC RRのいずれかが、DS RRSが存在しないことを証明し、セクション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 RRSを送信しようとする必要があります。名前サーバーは、RRSetとそれに関連するRRSIGを一緒に維持するためにあらゆる試みを行う必要があります。応答にRRSIG RRSを含めることは、次のルールの対象となります。
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を配置する場合、名前サーバーは回答セクションにRRSIG RRを配置する必要があります。RRSIG RRSは、含める必要がある他のどの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を当局セクションに配置する場合、名前サーバーはRRSIG RRSを当局セクションに配置する必要があります。RRSIG RRSは、含める必要がある他のどの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 RRSの両方を含めることを許可しない場合、名前サーバーはRRSIG RRSを削除しながらRRSetを保持する場合があります。これが発生した場合、これらのRRSIG RRSが適合しなかったために、名前サーバーが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 RRSを要求するクエリに応答する場合、そのゾーンのセキュリティ認識権限名サーバーは、追加セクションのゾーンAPEX DNSKEY RRSETを返す場合があります。この状況では、DNSKEY RRSETと関連するRRSIG RRSは、追加セクションに配置される他の情報よりも優先度が低くなります。DNSKEY RRSETと関連するRRSIG RRの両方に応答メッセージに十分なスペースがない限り、名前サーバーにはDNSKEY RRSETを含めるべきではありません。これらのDNSKEYとRRSIG RRSを含めるのに十分なスペースがない場合、名前サーバーはそれらを省略する必要があり、これらの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 BITセットがあるクエリに応答する場合、署名ゾーンのセキュリティ認識権限名サーバーには、次の各ケースにNSEC RRSを含める必要があります。
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>が正確に一致するrrsetsが含まれていますが、<sname、sclass、stype>を正確に一致させるrrsetsは含まれていません。
Name Error: The zone does not contain any RRsets that match <SNAME, SCLASS> either exactly or via wildcard name expansion.
名前のエラー：ゾーンには、<sname、sclass>正確またはワイルドカード名の拡張を介して一致するrrsetsは含まれていません。
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>に一致するrrsetsは含まれていませんが、ワイルドカード名拡張を介して<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>を正確に一致させるrrsetsが含まれておらず、ワイルドカード名の拡張を介して<sname、sclass>に一致する1つ以上のrrsetsが含まれていますが、<suname、sclassに一致するrrsetsは含まれていません。、Stype> WildCard名拡張を介して。
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.
これらの各ケースでは、名前サーバーには、<sname、sclass、stype>との正確な一致がゾーンに存在しないこと、およびデータがデータを返すことで正しいことを確認することを証明するための応答にnsec rrsが含まれています。ゾーン内。
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>を一致させるrrsetsが含まれているが、rrsetマッチング<sname、sclass、stype>が含まれていない場合、名前サーバーには、<sname、sclass>のnsec rrと関連するrrsig rrのnsec 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>を正確にまたはワイルドカード名拡張を介して一致するrrsetsが含まれていない場合、名前サーバーには、関連するRRSIG RRSとともに、当局セクションに次のNSEC RRを含める必要があります。
o An NSEC RR proving that there is no exact match for <SNAME, SCLASS>.
o NSEC RRは、<Snake、S Class>に正確な一致がないことを証明しています。
o An NSEC RR proving that the zone contains no RRsets that would match <SNAME, SCLASS> via wildcard name expansion.
o NSEC RRは、ゾーンに<Sname、sclass>と一致するRRSetsがワイルドカード名拡張を介して含まれていないことを証明しています。
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 RRSを含めることができない場合、名前サーバーは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.
これらのNSECおよびRRSIG RRの所有者名は、これらの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).
この形式の応答には、sunameがゾーン内の空の非末端名に対応する場合（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>に一致するが、ワイルドカード名拡張を介して<sname、sclass、stype>に一致するrrsetが含まれている場合、名前サーバーにはワイルドカード拡張回答と対応するワイルドカードを含める必要があります。回答セクションでRRSIG RRSを拡張し、AuthorityセクションにNSEC RRと関連するRRSIG RRを含める必要があります。Spaceが回答、NSECおよびRRSIG RRSを含めることを許可しない場合、名前サーバーは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>に一致するrrsetsが含まれていますが、これらのrrsetsのどれもスタイプと一致しません。名前サーバーには、関連するRRSIG RRSとともに、次のNSEC RRSを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 WildCardの拡張を介して<Sname、Sclass>に一致するWildCardの所有者名に、rrsetsが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 NSEC RRは、ゾーンに<sname、sclass>に近いマッチとなるであろうRRSetsがゾーンにないことを証明しています。
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.
これらのNSECおよびRRSIG RRの所有者名は、これらの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 RRSを含めることができない場合、名前サーバーは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.
上で説明したように、セキュリティを認識した権威ある名前サーバーが、特定のスナムと一致するRRSetsが存在しないことを証明するNSEC RRを見つける必要があるいくつかの状況があります。信頼できるゾーン内でこのようなNSEC RRを見つけることは、少なくとも概念が比較的単純です。次の議論では、名前サーバーは、存在しないrrsetsを一致させるゾーンの権威あるものであると想定しています。以下のアルゴリズムは、効率ではなく、明確にするために記述されています。
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.
名前を保持していたゾーンZに一致するrrsetsが存在しないことを証明するNSECを見つけるには、Zのすべてのrrsetの所有者名で構成されるシーケンスを構築し、標準的な順序に分類されています（[rfc4034]）、重複した名前はありません。所有者名nを持つrrsetが存在していた場合、sの直前にnの直前の名前mを見つけます。Mは、所有者名nにrrsetが存在しないことを証明するNSEC RRの所有者名です。
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を見つけるためのアルゴリズムは、他の所有者名を持つRRSetsが存在しないことを証明する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 BIT SETがあるクエリに応答する場合、紹介を返すセキュリティ認識権限名サーバーには、NS 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が委任ポイントに存在する場合、名前サーバーは、NS RRSETとともに、当局セクションのDS RRSetとそれに関連するRRSIG RRの両方を返す必要があります。
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 RRSTが存在しないことを証明するNSEC RRと、NS RRSTとともにNSEC RRに関連するRRSIG RR（S）の両方を返す必要があります。名前サーバーは、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 RRSを含むと、紹介メッセージのサイズが増加し、いくつかまたはすべての接着剤が省略される可能性があります。スペースでは、DSまたはNSEC RRSETおよび関連RRSIG RRSを含めることができない場合、名前サーバーは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」ゾーンではなく「例」ゾーンに保存されます。これには、名前サーバーとリゾルバーの両方に特別な処理ルールが必要です。これは、子ゾーンの名前サーバーは通常の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 RRSTを取得する何らかの方法があるか、Pre-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がChild Zoneの頂点に存在しないことを示す権威ある「データなし」応答を返す必要があります。このような応答の例については、付録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 rrsetsは、ゾーンカットの親側にのみ表示され、親ゾーンの権威あるデータです。他の権威あるRRSETと同様に、DS RRSTは、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 RRSは、ゾーンカットの親と子の両方のゾーンに表示され、親ゾーンとチャイルドゾーンの両方で権威あるデータです。ゾーンカットでの親と子のNSEC RRSは互いに同一ではありません。子ゾーンの頂点のNSEC RRは常に子ゾーンのSOA RRの存在を示しているのに対し、ゾーンカットの親のNSEC RRは決して示すことはありません。SOA RRの存在。他の権威あるRRSと同様に、NSEC RRSは、それらが権威あるデータであるゾーンのゾーン転送に含める必要があります。ゾーンカットの親の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 RRSは、ゾーンカットの親ゾーンとチャイルドゾーンの両方に表示され、RRSIG RRが署名を提供する権威あるRRSetを含むゾーンでは権威あるものです。つまり、ゾーンカットでのDS RRSETまたは親のNSEC RRのRRSIG RRは親ゾーンで権威があり、子ゾーンの頂点のRRSETのRRSIGは子供ゾーンでは権威があります。ゾーンカットでの親と子のrrsig RRSは、子ゾーンの頂点のrrsig rrの署名者の名前フィールドは、子ゾーンの頂点のdnskeyRRを示しているため、親のrrsig rrsig rrrの同じフィールドが示されているため、互いに同一になることはありません。ゾーンカットでは、親ゾーンの頂点にDNSKEY RRが示されます。他の権威あるRRSと同様に、RRSIG RRSは、権威あるデータであるゾーンのゾーン転送に含める必要があります。
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.
セキュリティ対応の名前のサーバーは、名前サーバーが回答のすべてのrrsetsと応答のすべてのrrsetsを本物であると考慮しない限り、ADビットを応答に設定してはなりません。セキュリティ対応の名前サーバーのローカルポリシーは、権威あるゾーンからのデータを、さらに検証することなく本物であると考える場合があります。ただし、名前サーバーが安全な手段（安全なゾーン転送メカニズムなど）を介して権威あるゾーンを取得しない限り、名前サーバーはそうしてはなりません。この動作が明示的に構成されていない限り、そうしてはなりません。
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]で説明されているように、セキュリティ認識の再帰名サーバーは、セキュリティ対応の名前サーバーとセキュリティ対応のリゾルバーの役割の両方で機能するエンティティです。このセクションでは、「Server Side」と「Resolver Side」という用語を使用して、セキュリティ対応の名前サーバーの役割を実装するセキュリティ対応の再帰名サーバー内のコードと、それぞれセキュリティ対応のリゾルバーロールを実装するコードを参照してください。。
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をBITを設定する必要があります。開始クエリのbitが設定されていない場合、名前サーバー側は応答から認証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ビットが設定されている場合、発信元のリゾルバーが、ローカルポリシーが必要とする認証を実行する意思があることを示しています。したがって、再帰名サーバーのリゾルバー側は、応答のrrsetsで認証を実行する必要はありません。CDビットが設定されている場合、再帰的な名前サーバーのローカル認証ポリシーが問題のレコードを拒否する場合でも、可能であれば、可能であれば、要求されたデータを元のリゾルバーに返す必要があります。つまり、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).
リゾルバー側が悪いキャッシュを実装し（セクション4.7を参照）、名前サーバー側がResolverの悪いキャッシュのエントリに一致するクエリを受信した場合、名前サーバー側の応答は元のクエリのCDビットの状態に依存します。CDビットが設定されている場合、名前サーバー側は悪いキャッシュからデータを返す必要があります。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 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].
セキュリティ対応の再帰名サーバーの名前サーバー側は、名前サーバーが回答のすべてのrrsetsと応答のすべてのrrsetsを本物であると見なさない限り、ADビットを応答に設定してはなりません。Resolver Sideが回答セクション内のすべてのrrsetを考慮し、Authorityセクションの関連する負の応答RRが本物である場合にのみ、名前サーバー側はADビットを設定する必要があります。リゾルバー側は、セクション5で説明されている手順に従って、問題のRRが本物であるかどうかを判断する必要があります。ただし、後方互換性の場合、応答に署名されていないCNAME RRSが含まれている場合、再帰名の名前サーバーがADビットを設定することができます。[RFC2672]。
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]）BITセットを使用して、EDNS（[RFC2671]）OPT PSEUDO-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 Pseudo-RRの「送信者のUDPペイロードサイズ」フィールドを使用して、それをメッセージサイズを宣伝する必要があります。喜んで受け入れます。セキュリティ認識Resolverの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.
セキュリティ対応のリゾルバーは、検証を実行しようとして、セキュリティRRSの欠落を照会する場合があります。そうすることを選択する実装は、受け取った回答が元の応答を検証するのに十分ではないかもしれないことに注意する必要があります。たとえば、ゾーンの更新が、元のクエリとフォローアップクエリの間で目的の情報を変更（または削除）している可能性があります。
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 RRSを取得しようとする場合、セキュリティ認識の反復モードリゾルバーは、チャイルドゾーンではなく、親ゾーンの名前サーバーを照会する必要があります。
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が存在しない場合、リゾルバーは左端の残りのラベルを取り除き、その名前のクエリを取得し、ns rrsetを見つけるかラベルがなくなるまでツリーを上に歩いているこのプロセスを繰り返します。
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が署名されることを期待すべきかどうかを判断できる必要があります。より正確には、セキュリティ対応のリゾルバーは、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.
偽物：リゾルバーが信頼の連鎖を確立できるはずだと信じているが、何らかの理由で検証に失敗した署名または関連するデータが欠落しているため、そうすることができないrrsetDNSSEC RRSは、存在する必要があることを示しています。このケースは攻撃を示している可能性がありますが、構成エラーまたは何らかの形式のデータ腐敗を示している場合があります。
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を取得できないため、RELSTが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で構成できる必要があります。セキュリティ対応のリゾルバーは、そのような構成された信頼アンカーなしで署名を検証できないため、リゾルバーには、ブートを起動するときにそのようなキーを取得するための合理的に堅牢なメカニズムが必要です。このようなメカニズムの例は、何らかの形の不揮発性ストレージ（ディスクドライブなど）または何らかの形の信頼できるローカルネットワーク構成メカニズムです。
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.
Trust Anchorsは、安全な方法で更新される重要な資料もカバーしていることに注意してください。この安全な方法は、物理メディア、キーエクスチェンジプロトコル、またはその他の帯域外の手段を通じて行うことができます。
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で説明されている応答フォームなどの場合、適切なキャッシュインデックスはdouble <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 RRSは、セキュリティ認識のリゾルバーによって再利用され、その名前の範囲内にある名前の存在を証明することができます。
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 RRSを使用して、問題のレコードの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.
セキュリティ対応のリゾルバーは、リゾルバーが応答のrrsetsに必要な認証を実行する責任を解決する責任を負うことを示すために、クエリのCDビットを設定する場合があります。このビットがセキュリティ認識の再帰名サーバーの動作に与える影響については、セクション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.
セキュリティ対応のリゾルバーは、クエリ名のサーバーから保護するクエリメッセージを構成するときに広告ビットをクリアする必要があります。これは、クエリメッセージから応答メッセージまで理解できないヘッダービットを盲目的にコピーする必要があります。
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.
多くの検証エラーは一時的になりますが、管理エラー（ゾーンの再署名の失敗、クロックスキューなど）によって引き起こされるものなど、一部の検証エラーはより永続的になる可能性があります。これらの場合には補償が役立たないため、リゾルバーの検証は、永続的な検証障害を備えたRRSetsの繰り返しクエリの結果として、かなりの量の不必要な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]）に似ていますが、有効な否定的な応答をキャッシュする代わりに、リゾルバーは特定の答えが検証できなかったという事実をキャッシュしています。このドキュメントは、「悪いキャッシュ」として無効な署名を持つデータのキャッシュを指します。
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:
悪いキャッシュを実装するリゾルバーは、サービス拒否攻撃アンプとしてキャッシュが役立つのを防ぐための手順を講じる必要があります。
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 検証に失敗したRRSetsには信頼できる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 一時的な検証障害のキャッシュを防ぐため（攻撃の結果である可能性があります）、リゾルバーは検証障害をもたらすクエリを追跡し、その特定のクエリに対する応答の回数後にのみ悪いキャッシュから答える必要があります<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に記載されているルールに基づいて、問題のRRSetsの署名を検証する必要がない場合を除き、不良キャッシュからrrsetを返してはなりません。セキュリティ認識の再帰名サーバーによって返された応答が悪いキャッシュとどのように相互作用するかについての議論については、セクション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.
検証済みのセキュリティ対応のリゾルバーは、[RFC2672]で説明されているように、DNAME RRから合成された可能性のある署名されていないCNAME RRSをカバーするものとして、有効な署名されたDNAME RRの署名を扱う必要があります。少なくとも応答メッセージを拒否しない範囲でそのようなcname rrsが含まれているという理由だけです。リゾルバーは、そのようなCNAME RRSをキャッシュまたは回答に留めておくことができますが、そうする必要はありません。
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 RRSが含まれる場合があります。これを行おうとする非検証スタブリゾルバーは、再帰名サーバーから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.
検証済みのセキュリティ対応のスタブリゾルバーは、署名検証を実行するために必要なDNSSEC RRSを受信しないため、DOビットを設定する必要があります。
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ビットの設定を調べることを選択することができます。応答メッセージの回答と権限セクション。ただし、セキュリティ認識のスタブリゾルバーによって受け取った応答は、セキュリティ対応の再帰名サーバーのローカルポリシーに大きく依存していることに注意してください。したがって、おそらくデバッグ援助として除き、広告ビットのステータスをチェックする際にはほとんど実用的な価値がないかもしれません。いずれにせよ、セキュリティ対応のスタブリゾルバーが安全なチャネルを介して信頼できるセキュリティ対応の再帰名サーバーから問題のデータを取得した場合を除き、セキュリティ認識スタブリゾルバーは、そのために実行された署名検証に依存してはなりません。。
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ビットの設定を調べてはなりません。定義上、Stub Resolverは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 RRSを使用するには、セキュリティ認識リゾルバーには、少なくとも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を使用して、ゾーンのApex 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がAPEX 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. Apex DNSKEY RRSETをカバーするRRSIG RRがあること、およびRRSIG RRと初期DNSKEY RRの組み合わせがDNSKEY RRSETを認証することを確認します。RRSIG RRを使用してRRSTを認証するプロセスについては、セクション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 RRSを使用して認証できます。これにより、リゾルバーは最初のキーから開始し、DS rrsetsを使用してDNSツリーを再帰的に進み、他のapex dnskey rrsetsを取得できます。リゾルバーがルートDNSKEY RRで構成されていて、すべての委任がそれに関連付けられたDS RRを持っていた場合、リゾルバーはApex DNSKEY RRSETを取得して検証することができます。DS RRSを使用して紹介を認証するプロセスについては、セクション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は、ResolverがゾーンのApex DNSKEY RRSetを認証した後、ゾーンのApex DNSKEY RRSETおよびRRSIG RRSをゾーンからApex DNSKEY RRSETおよびRRSIG RRSをゾーンから認証する方法を示しています。セクション5.4は、リゾルバーがゾーンから認証されたNSEC RRSetsを使用してゾーンに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.
ResolverがDNSSECのサポート（DO BITを設定することにより）を示す場合、セキュリティ認識の名前サーバーは、応答で必要なDNSKEY、RRSIG、NSEC、およびDS RRSetsを提供しようと試みる必要があります（セクション3を参照）。ただし、セキュリティ対応のリゾルバーは、DNSSEC RRSを誤って干渉する上流のセキュリティタームブリビアな再帰的な名前サーバーなどの構成の問題が原因であろうと、または副産物が故意に攻撃するため、適切なDNSSEC RRSを欠いている応答を受け取る場合があります。応答を忘れたり、応答からDNSSEC RRをストリップしたり、クエリを変更して、DNSSEC RRSが要求されていないように見えるようにします。応答中に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 RRSetsを使用して、署名された子ゾーンに代表団を認証できます。DS RRは、チャイルドゾーンの頂点DNSKEY RRSETでDNSKEY RRを識別し、Child ZoneのDNSKEY RRの暗号化ダイジェストを含みます。強力な暗号化ダイジェストアルゴリズムを使用すると、敵がダイジェストに一致するDNSKEY RRを生成することが計算的に実行不可能になります。したがって、ダイジェストを認証することで、リゾルバーが一致するDNSKEY RRを認証できます。その後、リゾルバーはこの子供DNSKEY RRを使用して、子Apex 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が与えられた場合、次のすべてが保持される場合、チャイルドゾーンのApex 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は、親のApex 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のアルゴリズムとキータグは、チャイルドゾーンのApex DNSKEY RRSETのアルゴリズムフィールドとDNSKEY RRのキータグと一致し、DNSKEY RRの所有者名とRDATAがDS RRの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にはゾーンフラグビットが設定されており、対応する秘密鍵がチャイルドゾーンのApex DNSKEY RRSETに署名し、結果のRRSIG RRがChild ZoneのApex 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もDS RRSETが存在しないことを証明しても、DS 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.
VALIDATORがこのゾーンにDS RRSTが存在しないことを証明するNSEC RRSETを認証する場合、親から子供への認証パスはありません。リゾルバーに、チャイルドゾーンまたはチャイルドゾーンの下の代表団に属する最初のDNSKEYまたはDS RRがある場合、この最初のDNSKEYまたはDS RRを使用して認証パスを再確立することができます。そのような最初のDNSKEYまたはDS RRが存在しない場合、VALIDATORはチャイルドゾーンまたは以下の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が存在するかを特定します。親NSEC RRとチャイルドNSEC RRは、SOAビットが子供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にリストされているアルゴリズムのいずれをサポートしていない場合、リゾルバーは子ゾーンへの認証パスを確認できません。この場合、リゾルバーは子ゾーンをまるで署名しているかのように扱う必要があります。
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を認証しようとすることができます。VALIDATORは最初にRRSIG RRをチェックして、RRSTをカバーし、有効な時間間隔を持ち、有効なDNSKEY RRを識別します。次に、VALIDATORは、RRSIG RDATA（署名フィールドを除く）をカバーされたRRSetの標準形式に追加することにより、署名データの標準形式を構築します。最後に、Validatorは公開キーと署名を使用して、署名されたデータを認証します。セクション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とRRSTには、同じ所有者名と同じクラスが必要です。
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のタイプカバーフィールドは、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のラベルフィールドの値以上でなければなりません。
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の開始分野にリストされている時間以上でなければなりません。
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の署名者の名前、アルゴリズム、およびキータグフィールドは、ゾーンのApex 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は、ゾーンのApex DNSKEY RRSetに存在する必要があり、ゾーンフラグビット（DNSKEY RDATAフラグビット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でカバーされているRRSTは、APEX DNSKEY RRST自体であり、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の正規形式が含まれます。注文されることは別として、RRSTの標準形式は、DNS名の圧縮、TTLの減少、またはワイルドカードの拡張により、受信したRRSetとも異なる場合があります。バリーターは、以下を使用して、元の署名されたデータを再構築する必要があります。
signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
"|" 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は、signatureフィールドが除外され、署名者の名前が正規の形式であるrrsig rdataフィールドのワイヤー形式です。
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
rr（i）= name |タイプ|クラス|Origttl |rdata長|rdata
name is calculated according to the function below
名前は、以下の関数に従って計算されます
class is the RRset's class
クラスはRRSetのクラスです
type is the RRset type and all RRs in the class
タイプはRRSetタイプであり、クラス内のすべてのRRS
OrigTTL is the value from the RRSIG Original TTL field
OrigttlはRRSIGオリジナルTTLフィールドからの値です
All names in the RDATA field are in canonical form The set of all RR(i) is sorted into canonical order.
rdataフィールドのすべての名前は標準的な形式です。すべてのRR（i）のセットは標準的な順序に分類されます。
To calculate the name: let rrsig_labels = the value of the RRSIG Labels field
名前を計算するには：rrsig_labels = rrsigラベルの値をフィールドにします
let fqdn = RRset's fully qualified domain name in canonical form
fqdn = rrsetの完全資格のドメイン名と標準形式
let fqdn_labels = Label count of the fqdn above.
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 rrsetsは、特別な処理が必要です。署名された委任された名前に関連付けられた2つの異なるNSEC rrsetsがあります。1つのNSEC RRSETは親ゾーンに存在し、親ゾーンにどのrrsetが存在するかを指定します。2番目のNSEC RRSetはチャイルドゾーンに存在し、子ゾーンの頂点にどのrrsetが存在するかを識別します。親NSEC RRSETと子供NSEC RRSETは、子NSEC RRのみがSOA RRSETが名前に存在することを示しているため、常に区別できます。親ゾーンからの代表団の元のNSEC RRSETを再構築する場合、NSEC RRSをチャイルドゾーンのNSEC RRと組み合わせることはできません。子ゾーンの頂点の元のNSEC RRSETを再構築する場合、NSEC RRSを親ゾーンの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 RRSetsのそれぞれには、委任された名前と一致する所有者名が付いた対応するRRSIG RRがあり、これらのRRSIG RRはそれぞれ、対応するNSEC RRSetを含む同じゾーンに関連付けられた権威あるデータです。必要に応じて、リゾルバーは、署名者の名前フィールドをチェックすることにより、これらのRRSIG RRSを隔てることができます。
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のアルゴリズムフィールドは、署名を生成するために使用される暗号化アルゴリズムを識別します。署名自体はrrsig rdataの署名フィールドに含まれており、署名の検証に使用される公開鍵は、一致するDNSKEY RRの公開鍵フィールドに含まれています（セクション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のラベルフィールドが、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 RRSもこのRRSETをカバーする場合、ローカルリゾルバーセキュリティポリシーは、これらのRRSIG RRSをテストする必要があるかどうか、およびこれらのRRSIG RRSが異なる結果につながる場合、競合を解決する方法も決定します。
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:
ResolverがRRSTを本物として受け入れる場合、バリッターはRRSIG RRのTTLと、認証されたRRSETの各RRを最小値よりも大きい値に設定する必要があります。
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のカバーのラベルフィールドよりも大きい場合、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).
Resolverが受け取った応答には、応答を認証するために必要なすべてのNSEC RRSを含める必要があることに注意してください（セクション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 RRSを使用して、署名ゾーンに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のラベルフィールドに等しい場合、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 要求されたRR名が、認証されたNSEC RRの所有者名の後に表示され、そのNSEC RRの次のドメイン名フィールドにリストされている名前が[RFC4034]で定義されている標準的なDNS名注文に従って表示される場合、要求された名前を持つRRSetsは存在しません。ゾーン。ただし、要求された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が存在しないこと、関連するWildCard RRSetが存在しないことを確認できる必要があります。これを証明するには、ゾーンから複数のNSEC RRSetが必要になる場合があります。必要なNSEC rrsetsの完全なセットが応答に存在しない場合（おそらくメッセージの切り捨てによる）、セキュリティ認識リゾルバーは、非非を確認するために必要なNSEC RRの完全なコレクションを取得しようとするためにクエリを再送信する必要があります。要求された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の両方の存在を証明するため、VALIBATORは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 BITを予約し、その使用を定義しました。使用は修正されますが、このドキュメントでは変更されません。
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クエリメッセージまたはDNS応答メッセージのADビットでCDビットを設定できるアクティブな攻撃者は、これらのビットを使用して、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エクステンションワーキンググループおよびワーキンググループメーリングリストのメンバーの入力とアイデアから作成されました。編集者は、これらのセキュリティ拡張仕様の改訂中に受け取ったコメントと提案に感謝します。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] Braden、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] Conrad、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 Aware Server/Resolverメッセージサイズ要件」、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）BITの再定義」、RFC 3655、2003年11月。
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.
例。soa ns1.exampleの3600。bugs.x.w.example。（1081539377 3600 300 3600000 3600）3600 RRSIG SOA 5 1 3600 20040509183619（20040409183619 38519の例。Anx0K36Rcjaxytcngq6iqnpnv5drqyasc9h 7tsjahcqbhedugdhgdhgqdhidhgqdhidgqme ZRF VKGO9EBARZ0GWDKCUWLM6ENB5SIX2K74L5LWDA7S/UN/IBTDQ4AY8NMNLQI7DW7N4P8/RJKB JV7J86HYQGM5E7 MIRAZ8V01B0I =）3600 NS NS1.3600 NS NS2.example。3600 RRSIG NS 5 1 3600 20040509183619（20040409183619 38519の例。GL13F00F00F2U0RSWIXXLHWSMYQSTYY5K6ZFD EUIVWC WD1FMBNCYQL0TK7LHTX6UOXC8AGNF 4ISPMISFF4IISMF 4MISPMISFMF -NISPPPITMISFMFMISPMISPMISPMISPMISFMFISPMISFMFISPMISFMF QF4NF T4FZ8 RO5URFOVOVOMRTBQXW3U0HXWUGGE4G3ZPSHV48 0HJMERAZB/FRPGFJPAJNGCQ6KWG =）3600 MX 1 XX.EXAMPLE。3600 RRSIG MX 5 1 3600 20040509183619（20040409183619 38519の例。HydHyvt5KHSZ7HTO/VYPUMPMSZZQRCOP3TZWB 2QAKKHVPFAU/DGLGS/IKENKYOGL95G4N NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE NZE /ZKUO 6GMMUW4B89RZ1PUXW4JZUXJ66PTWOVTUU/IM W6OISUKD1EQT7A0KYGKG PEDXDI =）3600 NSEC A.Example。dkqoak9ny nc3ahfvcv1tp4vkdqxqg7r5ttvm =）3600 rrsig dnskey 5 1 3600 20040509183619（20040409183619 38519例。NS1.A.Exampleの3600。NS2.A.Exampleの3600。NS DS RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 2004050509183619（20040409183619 38519例K/25 FI7XR5NOVJSB0LQ4ZSB3I BBDJYGDAHE0F5ROJJ87996VJUPDM1FBH481G SDKOW6ZYQTZ3ZOS8N0BBKEX 2G4 =）NS1.A.EXAMPLE。192.0.2.5 ns2.a.exampleで3600。192.0.2.6 ai.exampleで3600。3600 in 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= )
paotzlp2mu0tdjuhoke5fpiihmdyscgtb5b erggpnjlua9ixoyf6xxvcgrejw0wnzssjicd hbhxfdmagkuajuulysah8ts4znrhymivk3u ardu2wft130e9uhnuumhmimyumimyumimimimimivk3u XGVMYRVOTNYX2HVQ =）3600 HINFO "KLH-10" "ITS" 3600 RRSIG HINFO 5 2 3600 20040509183619（20040409183619 38519例l7vy/ikmtuy0ggdcfh zeockf4leykzf9npok1/r/fwrtznp8jobuy7 azeczadp1wddf3jc2/ndca5xzhlkd3jzosbw fvl8sqls5qs6fy/ijfedni4rkza =Hinfo aaaa rrsig nsec 3600 rrsig nsec 5 2 3600 20040509183619（20040409183619 38519の例。 84l453/buqb8bpdogky4hsn 3agclev1gr0qmvirqafcjzoecfngybm wpfl ahs jovfdi/79qtyti0sadwcg8u =）b.example。NS1.B.Exampleの3600。NS2.B.Exampleの3600。3600 NSEC NS1.example。NS RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519例。GNUXHN844WFMUPZGWKJCPY5TEX/RFJDOOOX 9UEK1PTYKOWNIJ/PJKCYBCCYBCCYBCCYBCCYBCCYBCCYBCCYJ/PJKODIJ * nvbnkm6owopysy97mvj5vqews 0lm9tfoqjcptqkmqkyprwuncsnwvvclsf1xz vhrxgwt7oufxldocg6tfvfms9xe =）ns1.b.example。192.0.2.7 ns2.b.exampleで3600。192.0.2.8 ns1.exampleで3600。192.0.2.1 3600 RRSIG A 5 2 3600 20040509183619（20040409183619 38519の例djypq84bhtv8vrxt5ab1wnb iaqvifdgw4sfnc6oadb1hk8qnauw9vepjhk v/ivxsyc0b7mpsu eolknfpvecs =）3600 nsec ns2.example。A RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519例。 vbnwqaaepjk3ukddbq ziali8qr2xhkjq38beqsbp8x0 6h4etwsgt8 izaigblryqwglw6y6x8dqhlnxjm =）ns2.example。3600 IN 192.0.2.2 3600 RRSIG A 5 2 3600 20040509183619（20040409183619 38519例zgde3vt5snfeaoe1vn3mqqtu7so 6 amijk13kj/jyj4ngmdric/3cm3ipxfhntkq rdhx8szz0yy4obirzizvbfliss8o =）3600 nsec *.w.w.emample。RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519例2v9ngchj/ovf/lbxffwwhlwzngh l bqagacmslu/nl3ndi1y/jsqjacdzndl4bw ymx28etgipo9a0qmp08rmbqs1jw =） *.w.example。MX 1 AI.exampleの3600。MX RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519例mjhfyps8tvvfxsaxfahpyqtx 91gsmcv/1v9/bzag55cefp9cm4z9y9nt9xq8 s1inq2uoiv6tjeaakkp701j8ola =）x.w.example。MX 1 xx.exampleの3600。3600 RRSIG MX 5 3 3600 20040509183619（20040409183619 38519の例。IL2WTZBKVOYTBX4LITNW5MJB4RCWHOO8Y1 XZPHZMZUTVYL7LAA63F6T9YSVZJRI3KIN1FDDDDDDDDDDDDDDDDDRCHINCHUN1FKVO8Y1 XZPHZMZUTVYL7LAA 4FOOBKBCDM7P3I KX70EPCOFGRZ1YQ BVVXCVGUAU4XALV3W/Y1 JNSLWZ2MSWKHFXFQXPTLJ8S32 K =）3600 NSEC X.Y.W.EXAMPLE。MX RRSIG NSEC 3600 RRSIG NSEC 5 3 3600 20040509183619（20040409183619 38519例。 dpy6rvearlzlcr1ikvctvbtai njubba/vhm pebtbkcapivl9tbooh to1h6e ijgim8pxkbqtxpq37wdkalkyn7q =）x.y.w.example。MX 1 xx.exampleの3600。3600 RRSIG MX 5 4 3600 20040509183619（20040409183619 38519の例。K2BJHBWP5LH5QN4IS39UIPZJAWYMJA38HHHIAT7I9T7NBX/E0PNVDJCC7UL ZRJCXXCC7UL ZRMIN w3va // lvrxkkp6xupq gtob9prkkk54qtl/qztxfmqpw480yovvknhvb glcmzbnhj326nb/toomrqnmqqe =）3600 nsec xx.example。MX RRSIG NSEC 3600 RRSIG NSEC 5 4 3600 20040509183619（20040409183619 38519例f/lzy2zqromubrnqhjtidtx a0arunjqczpjoyq5t0sljm6qp6mcji1ap5vr qokqjdclnoalcpopkam/jjkn3jk =）xx.example。192.0.2.10の3600 3600 RRSIG A 5 2 3600 20040509183619（20040409183619 38519例RKL1EZMCDMGOAEUUZZAJ2BMQ Y VDXG9IK1YZKYGY9AGBTOGPOAGBJYO9EPULSX KBIDV6GPPSZVUSNZU6OMGZGZHV4 =
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.
Apex DNSKEYセットには2つのDNSKEY RRSが含まれており、DNSKEY RDATAフラグは、これらのDNSKEY RRのそれぞれがゾーンキーであることを示しています。これらのDNSKEY RRSの1つには、SEPフラグが設定されており、Apex DNSKEY RRSetに署名するために使用されています。これは、親ゾーンに挿入されるDSレコードを生成するためにハッシュする必要がある鍵です。他のdnskeyは、ゾーン内の他のすべてのrrsetsに署名するために使用されます。
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」が含まれています。「*.w.example」という名前は、nsecチェーンの構築に使用され、「*.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 RRSTのみが署名されていることに注意してください。「a.example」への代表団はDS RRを提供します。NSECおよびDS RRSetsのみが署名されていることに注意してください。
The examples in this section show response messages using the signed zone example in Appendix A.
このセクションの例は、付録Aの署名ゾーンの例を使用した応答メッセージを示しています。
A successful query to an authoritative server.
権威あるサーバーへのクエリが成功しました。
;; Header: QR AA DO RCODE=0
;;
;; Question
x.w.example. IN 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。MX 1 xx.exampleの3600。X.W.Example。3600 RRSIG MX 5 3 3600 20040509183619（20040409183619 38519の例。IL2WTZBKVOYTBX4LITNW5MJB4RCWHOO8Y1 XZPHZMZUTVYL7LAA63F6T9YSVZJRI3KIN1FDCMPMPMPMPMPMPMDN1KPMPMINT9KWO8Y1 4FOOBKBCDM7P3I 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 NS 5 1 3600 20040509183619（20040409183619 38519の例。GL13F00F00F2U0RSWIXXLHWSMYQSTYY5K6ZFD EUIVWC WD1FMBNCYQL0TK7LHTX6UOXC8AGNF 4ISPMISFF4IISMF 4MISPMISFMF -NIVWC WD1FMBNCYQL0TK3LINGF4NFISPMISFMFISPMISFMFISPMISFMF 4MISFMF 4MISFMF 4ISFMFIISMF T4FZ8 RO5URFOVOVOMRTBQXW3U0HXWUGGE4G3ZPSHV48 0HJMERAZB/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。192.0.2.10 xx.exampleで3600。3600 AAAA 2001：db8 :: f00：baaa xx.example。3600 RRSIG AAAA 5 2 3600 20040509183619（20040409183619 38519例。ZZJ0YODDXCBLNNOIWDSUKO5WQIAK24DLKG9C AGAXDFIKKOBUJ2JILYQFN2PPTCKSD4ZD4ZPPTIZD4ZPPTIZD4ZPPTIZD4ZPPTIZD4ZPPTIZD4ZPPTIZD4ZDLKG9C AGAXDFIKGKOBUJ2J IWP4LWPVTR U4ZFEA RDZ9STMSBP/4PEKH/X2IOAYNWCTD/XS9CL2QGW7FCHW16MZLKH6/VSFS =）NS1.EXAMPLE。192.0.2.1 ns1.exampleで3600。192.0.2.2 ns2.exampleで3600。
An authoritative name error. The NSEC RRs prove that the name does not exist and that no covering wildcard exists.
権威ある名前エラー。NSEC RRSは、名前が存在せず、ワイルドカードをカバーしていないことを証明しています。
;; Header: QR AA DO RCODE=3
;;
;; Question
ml.example. IN A
;; 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= )
;;権限の例。soa ns1.exampleの3600。bugs.x.w.example。（1081539377 3600 300 3600000 3600）例。3600 RRSIG SOA 5 1 3600 20040509183619（20040409183619 38519の例。onx0k36rcjaxytcngq6iqnpnv5 drqyasc9h 7tsjahcqbhe67sr6ah2xdugdug dug dug dug dug duguzuzdugdugdugdugduをM6ENB5SIX2K74L5LW 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の例。GNUXHN844WFMUHPZGWKJCJCPY5TEX/RFJDOOX 9UEK1PTYKOWKOODIJ/PJKCYB3HHYX 858888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 YSY97MVJ5VQEWS 0LM9TFOQJCPTQKMQKYPRWUNCSNWVVCLSF1XZ VHRXGWT7OUFXLDOCG6TFVFMS9XE =）例。3600 NSEC A.Example。NS SOA MX RRSIG NSEC DNSKEYの例。
;; Additional
;; (empty)
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
;; 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= )
;;権限の例。soa ns1.exampleの3600。bugs.x.w.example。（1081539377 3600 300 3600000 3600）例。3600 RRSIG SOA 5 1 3600 20040509183619（20040409183619 38519の例。onx0k36rcjaxytcngq6iqnpnv5 drqyasc9h 7tsjahcqbhe67sr6ah2xdugdug dug dug dug dug duguzuzdugdugdugdugduをM6ENB5SIX2K74L5LW DA7S/UN/IBTDQ4AY8NMNLQI7DW7N4P8/RJKB JV7J86HYQGM5E7 MIRAZ8V01B0I =）NS1.EXAMPLE。3600 NSEC NS2.example。rrsig nsec ns1.example。3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519の例。I4HJKT68RCCHCUDOLKS2S WZRI9H3FHAS8 jk3ukddbq ziali8qr2xhkjq38beqsbp8x0 6h4etwsgt8 izaigblryqwglw6y6x8dqhlnxjm =）
;; Additional
;; (empty)
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には、Child Zoneの頂点で対応するDNSKEY RRを検証するためにリゾルバーが必要なデータが含まれています。
;; Header: 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。NS1.A.Exampleの3600。A.例。NS2.A.Exampleの3600。A.例。3600 DS 57855 5 1（B6DCD485719ADCA18E5F3D48A2331627FDD3 636B）A.Example。
;; Additional ns1.a.example. 3600 IN A 192.0.2.5 ns2.a.example. 3600 IN A 192.0.2.6
;;追加のns1.a.example。192.0.2.5 ns2.a.exampleで3600。192.0.2.6の3600
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
;; 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.例。NS1.B.Exampleの3600。B.例。NS2.B.Exampleの3600。B.例。3600 NSEC NS1.example。ns rrsig nsec b.example。
;; Additional ns1.b.example. 3600 IN A 192.0.2.7 ns2.b.example. 3600 IN A 192.0.2.8
;;追加のns1.b.example。192.0.2.7 ns2.b.exampleで3600。192.0.2.8で3600
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
;; 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。MX 1 AI.exampleの3600。a.z.w.example。
;; 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 NS 5 1 3600 20040509183619（20040409183619 38519の例。GL13F00F00F2U0RSWIXXLHWSMYQSTYY5K6ZFD EUIVWC WD1FMBNCYQL0TK7LHTX6UOXC8AGNF 4ISPMISFF4IISMF 4MISPMISFMF -NISPPPITMISFMFMISPMISPMISPMISPMISFMFISPMISFMFISPMISFMF QF4NF T4FZ8 RO5URFOVOVOMRTBQXW3U0HXWUGGE4G3ZPSHV48 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の例。Ove6Wuzn2ziiejcvkpwbcayxyp6ef8cr6csparvstzkunwbezmmku7e34o5lmb6cwssspg x xwssspg xwmb6cwssspgfmhcsspgfmhcsspgfmhcsspgfmhcsspgfmhcsspgfmhcsspgpgmb6cwssspgfmbzsspm ubrnqhjtidtx a0arunjqczpjoyq5t0sljm6qp6mcji1ap5vr qokqjdclnoalcpopkam/jjkn3jk =））
;; Additional ai.example. 3600 IN A 192.0.2.9 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
;;追加のai.example。192.0.2.9 ai.exampleで3600。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例。paotzlp2mu0tdjuhoke5fpiihmdyscgtb5b erggpnjlua9ixoyf6xxvcgrejw0wnzssjicd hbhxfdmagkuajuulysah8ts4znrhymivk3u ardu2wft130e9uhnuumhmimyumimyumimimimimivk3u xgvmyrvotnyx2hvq =）ai.example。3600 AAAA 2001：db8 :: f00：baa9 ai.example。3600 RRSIG AAAA 5 2 3600 20040509183619（20040409183619 38519の例。NLCPFUXDT35ACEEOAFOUKL69KB /E56XMFK KEWXG2IADYLKAOBIOR5 VOQV3XGTCOFTJNSH 1MSHSSH 1MSHSSHSHNSHSHNSHSSH NKR4A7CL9T CMMDWV/HWFKSBGBSJ8XSCN/CAEL2CWY/5XP2 SZM6QJBBLMUKH30 W1Z3H8PUP2O =）
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 RRSは、一致するワイルドカード名に要求されたタイプのRRSがなく、ゾーンに近い一致が存在しないことを証明しています。
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN 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 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= )
;;権限の例。soa ns1.exampleの3600。bugs.x.w.example。（1081539377 3600 300 3600000 3600）例。3600 RRSIG SOA 5 1 3600 20040509183619（20040409183619 38519の例。onx0k36rcjaxytcngq6iqnpnv5 drqyasc9h 7tsjahcqbhe67sr6ah2xdugdug dug dug dug dug duguzuzdugdugdugdugduをM6ENB5SIX2K74L5LWDA7S/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の例。Ove6Wuzn2ziiejcvkpwbcayxyp6ef8cr6csparvstzkunwbezmmku7e34o5lmb6cwssspg x xwssspg xwmb6cwssspgfmhcsspgfmhcsspgfmhcsspgfmhcsspgfmhcsspgfmhcsspgpgmb6cwssspgfmbzsspm ubrnqhjtidtx a0arunjqczpjoyq5t0sljm6qp6mcji1ap5vr qokqjdclnoalcpopkam/jjkn3jk =） *.w.example。3600 NSEC X.W.Example。mx rrsig nsec *.w.example。3600 RRSIG NSEC 5 2 3600 20040509183619（20040409183619 38519の例。R/MZNRC3I/VICRELGICTESXDHTSDLTDTDT8NG9 HSBLABOLZLXQTFGTNN8F AOWJIAFE1EE5PXFFCJN8FCJN8FCJN8FCHPXFFCJN8FCHPXFFCJN8F vfxSaxfahpyqtx 91GSMCV/1V9/BZAG55CEFP9CM4Z9Y9NT9XQ8 S1INQ2UOIV6TJEAAKKP701J8OLA =）
;; Additional
;; (empty)
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
;; 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 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U= )
;;権限の例。soa ns1.exampleの3600。bugs.x.w.example。（1081539377 3600 300 3600000 3600）例。3600 RRSIG SOA 5 1 3600 20040509183619（20040409183619 38519の例。Anx0k36rcjaxytcngq6iqnpnv5drqyasc9h 7tsjahcqbhe67sr6ah2xdugdugqucwsufiduzuzufdugduをM6ENB5SIX2K74L5LWDA7S/UN/IBTDQ4AY8NMNLQI7DW7N4P8/RJKB JV7J86HYQGM5E7 MIRAZ8V01B0I =）例。3600 NSEC A.Example。NS SOA MX RRSIG NSEC DNSKEYの例。
;; Additional
;; (empty)
The examples in this section show how the response messages in Appendix B are authenticated.
このセクションの例は、付録Bの応答メッセージがどのように認証されるかを示しています。
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は、MX RRSTがアルゴリズム5およびキータグ38519の「例」DNSKEYによって署名されたことを示しています。リゾルバーには、この回答を認証するために対応する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 RRSTの元のTTLが3600であり、認証の目的で、現在のTTLが3600に置き換えられたことを示します。RRSIGラベル3のフィールド値は、答えがワイルドカードの拡張の結果ではなかったことを示します。「x.w.example.com」MX rrsetは標準的な形に配置されており、現在の時刻が署名の開始日と有効期限の間にあると仮定すると、署名は認証されています。
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のすべてのキーは認証されていると見なされます。その後、Resolverは1つ（またはそれ以上）のルートDNSKEY RRSを使用して、「例」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.
root 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.
最後に、Resolverは、「例」DNSKEY RRSetの一部のDNSKEY RRがアルゴリズム5を使用し、38519の重要なタグを持っていることを確認します。このDNSKEYは、応答に含まれるRRSIGを認証するために使用されます。複数の「例」DNSKEY RRSがこのアルゴリズムとキータグと一致する場合、各DNSKEY RRが試され、一致するDNSKEY RRSが上記のように署名を検証する場合、答えは認証されます。
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 RRSを返しました。否定的な応答は、両方のNSEC RRを検証することにより認証されます。NSEC RRは、上記のMX RRSTと同じ方法で認証されています。
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 RRSTと同じ方法で認証されています。
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 RRSTと同じ方法で認証されています。この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.
「a.example」ds rrsetが「例」dnskeyを使用して認証されると、リゾルバーは、ds rrと一致する「a.example "dnskey rrの「a.example」dnskey rrsetをチェックします。このような一致する「a.example」dnskeyが見つかった場合、リゾルバーは、このdnskey RRが「a.example」dnskey rrsetに署名したかどうか、および署名の生涯が有効かどうかをチェックします。これらすべての条件が満たされている場合、「a.example」DNSKEY RRSetのすべてのキーは認証されていると見なされます。
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は、「例」から「b.example」に認証が導かれないことを証明し、NSEC RRは上記のMX RRSetと同一の方法で認証されています。
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によって署名されたことを示しています。MX RRSTの元のTTLは3600であり、認証を目的として、現在のTTLは3600に置き換えられます。RRSIGラベル2のフィールド値は、「A.Z.W.Example」名のように、答えがワイルドカード拡張の結果であることを示しています。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も回答が有効と見なされる前に認証されなければなりません。
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 RRSを返しました。否定的な応答は、両方のNSEC RRを検証することにより認証されます。
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 RRSを返しました。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
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブオーストインインターネットシステムコンソーシアム950チャーターストリートレッドウッドシティ、カリフォルニア94063 USA
EMail: 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 USA
EMail: mlarson@verisign.com
Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873
ダンマッシーコロラド州立大学コンピュータサイエンス学部フォートコリンズ、コロラド州80523-1873
EMail: massey@cs.colostate.edu
Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA
スコットローズ国立標準技術研究所100ビューロードライブゲーサーズバーグ、メリーランド20899-8920 USA
EMail: scott.rose@nist.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。