この文書はRFC4074の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
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). 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. この文書はRFC2535を時代遅れにし、そしてRFC2535からのす べての更新を含みます。 Table of Contents 目次 1. Introduction 1. はじめに 1.1. Background and Related Documents 1.1. 背景と関連文書 1.2. Reserved Words 1.2. 予約語 2. Zone Signing 2. ゾーン署名 2.1. Including DNSKEY RRs in a Zone 2.1. ゾーンにDNSKEY資源レコードを含めること 2.2. Including RRSIG RRs in a Zone 2.2. ゾーンの資源レコード署名資源レコードを含めること 2.3. Including NSEC RRs in a Zone 2.3. ゾーンにNSEC資源レコードを含めること 2.4. Including DS RRs in a Zone 2.4. ゾーンに委任署名資源レコードを含めること 2.5. Changes to the CNAME Resource Record 2.5. CNAME資源レコードの変更 2.6. DNSSEC RR Types Appearing at Zone Cuts 2.6. ゾーン切断に現われるDNSSEC資源レコード種別 2.7. Example of a Secure Zone 2.7. セキュアゾーンの例 3. Serving 3. サーバ 3.1. Authoritative Name Servers 3.1. 正式なネームサーバ 3.1.1. Including RRSIG RRs in a Response 3.1.1. 回答に資源レコード署名資源レコードを含めること 3.1.2. Including DNSKEY RRs in a Response 3.1.2. 回答にDNSKEY資源レコードを含めること 3.1.3. Including NSEC RRs in a Response 3.1.3. 回答にNSEC資源レコードを含めること 3.1.4. Including DS RRs in a Response 3.1.4. 回答に委任署名資源レコードを含めること 3.1.5. Responding to Queries for Type AXFR or IXFR 3.1.5. AXFRやIXFRの質問への返答 3.1.6. The AD and CD Bits in an Authoritative Response 3.1.6. 正式な回答のADとCDビット 3.2. Recursive Name Servers 3.2. 再帰ネームサーバ 3.2.1. The DO Bit 3.2.1. DOビット 3.2.2. The CD Bit 3.2.2. CDビット 3.2.3. The AD Bit 3.2.3. ADビット 3.3. Example DNSSEC Responses 3.3. DNSSEC回答例。 4. Resolving 4. リゾルバ 4.1. EDNS Support 4.1. EDNS対応 4.2. Signature Verification Support 4.2. 署名検証サポート 4.3. Determining Security Status of Data 4.3. データのセキュリティ状況の決定 4.4. Configured Trust Anchors 4.4. 信頼固定点の設定 4.5. Response Caching 4.5. 回答キャッシュ 4.6. Handling of the CD and AD Bits 4.6. CDとADビットの取り扱い 4.7. Caching BAD Data 4.7. 悪いデータのキャッシュ 4.8. Synthesized CNAMEs 4.8. CNAME合成 4.9. Stub Resolvers 4.9. スタブリゾルバ 4.9.1. Handling of the DO Bit 4.9.1. DOビットの扱い 4.9.2. Handling of the CD Bit 4.9.2. CDビットの扱い 4.9.3. Handling of the AD Bit 4.9.3. ADビットの扱い 5. Authenticating DNS Responses 5. DNS応答検証 5.1. Special Considerations for Islands of Security 5.1. セキュリティの孤島に対する特別な考慮 5.2. Authenticating Referrals 5.2. 照会の検証 5.3. Authenticating an RRset with an RRSIG RR 5.3. 資源レコード署名資源レコード付きの資源レコード集合の認証 5.3.1. Checking the RRSIG RR Validity 5.3.1. 資源レコード署名資源レコードの正当性の検査 5.3.2. Reconstructing the Signed Data 5.3.2. 署名されたデータの再構築 5.3.3. Checking the Signature 5.3.3. 署名検査 5.3.4. Authenticating a Wildcard Expanded RRset Positive Response 5.3.4.ワイルドカード拡張肯定応答の認証 5.4. Authenticated Denial of Existence 5.4. 非存在認証 5.5. Resolver Behavior When Signatures Do Not Validate 5.5. 署名無効時のリゾルバ行動 5.6. Authentication Example 5.6. 認証例 6. IANA Considerations 6. IANA考慮 7. Security Considerations 7. セキュリティの考察 8. Acknowledgements 8. 受取りの通知 9. References 9. 参考文献 9.1. Normative References 9.1. 参照する参考文献 9.2. Informative References 9.2. 有益な参考文献 Appendix A. Signed Zone Example 付録A 署名されたゾーンの例 Appendix B. Example Responses 付録B 回答例 B.1. Answer B.1. 解答 B.2. Name Error B.2. 名前エラー B.3. No Data Error B.3. データなしエラー B.4. Referral to Signed Zone B.4. 署名されたゾーンへの照会 B.5. Referral to Unsigned Zone B.5. 署名されていないゾーンへの照会 B.6. Wildcard Expansion B.6. ワイルドカード拡大 B.7. Wildcard No Data Error B.7. ワイルドカードデータなしエラー B.8. DS Child Zone No Data Error B.8. 委任署名子ゾーンデータなしエラー Appendix C. Authentication Examples 付録C. 認証例 C.1. Authenticating an Answer C.1. 応答認証 C.1.1. Authenticating the Example DNSKEY RR C.1.1. 例DNSKEY資源レコード認証 C.2. Name Error C.2. 名前エラー C.3. No Data Error C.3. データなしエラー C.4. Referral to Signed Zone C.4. 署名されたゾーンの参照 C.5. Referral to Unsigned Zone C.5. 署名されていないゾーンの参照 C.6. Wildcard Expansion C.6. ワイルドカード拡大 C.7. Wildcard No Data Error C.7. ワイルドカードデータなしエラー C.8. DS Child Zone No Data Error C.8. 委任署名子ゾーンデータなしエラー Authors' Addresses 著者のアドレス Full Copyright Statement 著作権表示全文 1. Introduction 1. はじめに 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に新しい資源レコードと データ源認証とデータ完全性を加えるプロトコル修正です。この文書はDN SSECプロトコル修正を定義します。この文書の2章が署名されたゾーン の概念を定義して、そしてゾーン署名の必要条件をリストアップします。3 章が署名されたゾーンを扱うために正式なネームサーバの行動に必要な修正 を記述します。4章がセキュリティの認識のあるリゾルバの機能を含むエン ティティーの行動を記述します。最後に、5章が回答を認証するためにDN SSEC資源レコードをどう使うべきか定義します。 1.1. Background and Related Documents 1.1. 背景と関連文書 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プロトコルオペレーションを定義します。 1.2. Reserved Words 1.2. 予約語 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は [RFC2119]で記述されるように解釈してください。 2. Zone Signing 2. ゾーン署名 DNSSEC introduces the concept of signed zones. A signed zone includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), Next Secure (NSEC), and (optionally) Delegation Signer (DS) records according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4, respectively. A zone that does not include these records according to the rules in this section is an unsigned zone. DNSSECは署名されたゾーンの概念を導入します。署名されたゾーンは、 それぞれ第2.1章と2.2章と2.3章と2.4章とで指定した規則により、 DNS公開鍵(DNSKEY)と資源レコード署名(RRSIG)と次の安 全(NSEC)と(任意で)委任署名者(DS)レコードを含みます。これ らのレコードを含まないゾーンはこの章での規則によれば署名されていない ゾーンです。 DNSSEC requires a change to the definition of the CNAME resource record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs to appear at the same owner name as does a CNAME RR. DNSSECはCNAME資源レコード([RFC1035])の定義に対する変更を 必要とします。資源レコード署名(RRSIG)とNSEC資源レコードが CNAME資源レコードと同じ所有者名において現われることを許すために 2.5章がCNAME資源レコードを変えます。 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がこの変 更を記述します。 2.1. Including DNSKEY RRs in a Zone 2.1. ゾーンにDNSKEY資源レコードを含めること 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. ゾーンに署名するために、ゾーン管理者は公開鍵/秘密鍵の対を生成し、秘 密鍵をゾーンの正式な資源レコード集合を署名するために秘密鍵を使います。 ゾーンの資源レコード署名資源レコードの生成に使用したそれぞれの秘密鍵 に対し、ゾーンは対応する公開鍵を含むゾーンのDNSKEY資源レコード を含むべきです(SHOULD)。ゾーン鍵DNSKEY資源レコードは、資源デー タフィールドのフラグのゾーン鍵ビットを設定しなければなりません(MUST) ([RFC4034]の2.1.1章参照)。他のDNSオペレーションと結び付けられ た公開鍵はゾーン鍵のマークを付けられないDNSKEY資源レコードに保 存されるかもしれません(MAY)が、資源レコード署名の検証に使われてはなり ません(MUST NOT)。 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つのDNSKEY資源レコードを含んでいなくて はなりません(MUST)。このセキュリティ入口点はそれから親ゾーンの対応す る委任署名資源レコードでセキュリティ委任の目標として用いられることが できます([RFC4034]参照)。 2.2. Including RRSIG RRs in a Zone 2.2. ゾーンの資源レコード署名資源レコードを含めること For each authoritative RRset in a signed zone, there MUST be at least one RRSIG record that meets the following requirements: 署名されたゾーンでそれぞれの正式な資源レコード集合のために、次の必要 条件を満たす少なくとも1つの資源レコード署名レコードがあるに違いあり ません(MUST): o The RRSIG owner name is equal to the RRset owner name. o 資源レコード署名の所有者名は資源レコード集合の所有者名と同じです。 o The RRSIG class is equal to the RRset class. o 資源レコード署名のクラスは資源レコード集合のクラスと同じです。 o The RRSIG Type Covered field is equal to the RRset type. o 資源レコード署名の種別カバーフィールドは資源レコード集合の種別と同 じです。 o The RRSIG Original TTL field is equal to the TTL of the RRset. o 資源レコード署名の元のTTLフィールドは資源レコード集合のTTLと 同じです。 o The RRSIG RR's TTL is equal to the TTL of the RRset. o 資源レコード署名資源レコードのTTLは資源レコード集合の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 資源レコード署名のラベルフィールドは、ゼロのルートラベルと、ワイル ドカードの場合の再左ラベル除いた、資源レコード集合の所有者名のラベ ル数と同じです。 o The RRSIG Signer's Name field is equal to the name of the zone containing the RRset. o 資源レコード署名の署名者の名前フィールドは資源レコード集合を含んで いるゾーンの名前と同じです。 o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a zone key DNSKEY record at the zone apex. o 資源レコード署名のアルゴリズムと署名の名前と鍵タグフィールドはゾー ン頂上のゾーン鍵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]. 所定の資源レコード集合の資源レコード署名資源レコードを構築するプロセ スは[RFC4034]で記述されます。資源レコード集合が多数の資源レコード署名 資源レコードと結び付くかもしれません(MAY)。資源レコード署名資源レコー ドは署名対象の資源レコード集合に密接に結びつくため、資源レコード署名 資源レコードが、他のDNS資源レコード種別と異なり、資源レコード集合 を形成しないことに注意してください。特に、共通の所有者名の資源レコー ド署名資源レコードのTTL値は[RFC2181]で記述された資源レコード集合規 則に従いません。 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. 資源レコード署名資源レコードの署名は価値がなく署名処理の無限ループを 作るので、資源レコード署名資源レコード自身は署名されてはなりません (MUST NOT)。 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. ゾーン頂上名に現われるネームサーバ資源レコード集合は署名されなくては なりません(MUST)が、委任点に現われるNS資源レコード集合(すなわち、 子ゾーンのネームサーバに名前を委任するため親ゾーンの中にあるネームサー バ資源レコード集合)を署名してはなりません(MUST NOT)。委任に関連する 接着剤アドレス資源レコード集合を署名してはなりません(MUST NOT)。 There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). それぞれの資源レコード集合に対し、ゾーン頂上のDNSKEY資源レコー ド集合のそれぞれのアルゴリズムのDNSKEYの少なくとも1つを使用し た、資源レコード署名があるに違いありません(MUST)。頂上のDNSKEY 資源レコード自身は、委任親ゾーン(もしあれば)の委任署名資源レコード 集合のそれぞれのアルゴリズムで、署名されなくてはなりません(MUST)。 2.3. Including NSEC RRs in a Zone 2.3. ゾーンにNSEC資源レコードを含めること 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資源レコード集合を持つ所有者 名にNSEC資源レコードがなければなりません(MUST)。NSEC資源レコー ドのフォーマットとNSEC資源レコードを構築する処理は[RFC4034]で記述 されます。 The TTL value for any NSEC RR SHOULD be the same as the minimum TTL value field in the zone SOA RR. NSEC資源レコードのTTL値はゾーンのSOA資源レコードの最小TT L値フィールドと同じであるべきです(SHOULD)。 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レコード(そして関連する資源レコード署名資源レコード集合)は 特定の所有者名の唯一の資源レコード集合であってはなりません(MUST NOT)。 すなわち、署名処理は、ゾーンが署名される前に資源レコード集合がなかっ た所有者名に対して、NSECあるいは資源レコード署名資源レコードを作っ てはなりません(MUST NOT)。これの主な理由は、署名されたのと署名されて いないのでゾーンの名前空間が整合している事の要望と、セキュリティの認 識がない再帰ネームサーバの回答の一貫性のなさに対するリスクを減らす要 望のためです。 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自身と対応する資源レコード署名レコードの両方の存在を示さなく てはなりません(MUST)。 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. 資源レコード署名レコードを必要とする所有者名とNSECレコードを必要 とする所有者名の間の相違は微妙で興味深い点です。資源レコード署名レコー ドはすべての正式な資源レコード集合の所有者名に存在しています。NSE Cレコードは、署名されたゾーンで正式な所有者名と、署名ゾーンから子へ の委任点の所有者名に存在します。NSECと資源レコード署名レコードの いずれも、(親ゾーンの)接着剤アドレス資源レコード集合の所有者名に対 しては存在しません。しかしながらこの区別は、NSEC資源レコード集合 が正式なデータであり、従って署名されるので、ゾーン署名処理の間に見え るだけであることに注意してください。それで、署名されたゾーンで、NS EC資源レコード集合を持つ所有者名では、資源レコード署名資源レコード も持つでしょう。 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資源レコードの間のビットマップは特別な注意を必要と します。親ゾーンで正式な資源レコード集合と委任NS資源レコード集合に 対応しているビットは設定しなければなりません(MUST);親ゾーンで正式で はな非NS資源レコード集合に対応しているビットはクリアしなければなり ません(MUST)。 2.4. Including DS RRs in a Zone 2.4. ゾーンに委任署名資源レコードを含めること 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. 委任署名資源レコードはDNSゾーン間の認証鎖を生成します。委任署名資 源レコード集合は、子ゾーンが署名される時、委任点に存在するべきです (SHOULD)。委任署名資源レコード集合は複数存在するかも知れず(MAY)、それ ぞれはそのゾーンの資源レコード署名を実証するために使われた子ゾーンの 公開鍵を示します。すべてのゾーンの委任署名資源レコード集合は署名され なくてはなりません(MUST)、そして委任署名資源レコード集合はゾーンの頂 上に現われてはなりません(MUST NOT)。 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. 委任署名資源レコードは子の頂上にあるDNSKEY資源レコードを示すべ きです(SHOULD)、そして子の頂上のDNSKEY資源レコード集合は対応す る秘密鍵によって署名されるべきです(SHOULD)。これらの条件を満たすこと に失敗する委任署名資源レコードは検証に役立ちませんが、委任署名資源レ コードと対応するDNSKEY資源レコードは異なるゾーンにあり、そして 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). 委任署名資源レコード集合のTTLは委任NS資源レコード集合(委任署名 資源レコード集合を含んでいるのと同じゾーンのNS資源レコード集合)の TTLと一致するべきです(SHOULD)。 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. 委任署名資源レコードの構築は子ゾーンの対応するDNSKEY資源レコー ド知識を必要とし、そしてこれは子ゾーンと親ゾーンの間の会話を暗示しま す。この会話はこの文書の範囲外の運用上の問題です。 2.5. Changes to the CNAME Resource Record 2.5. CNAME資源レコードの変更 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資源レコード集合が署名されたゾーンのある名前に存在する なら、適切な資源レコード署名とNSEC資源レコード集合がその名前にお いて必要とされます(REQUIRED)。セキュア動的更新の目的の名前での鍵資源 レコード集合が同じく許されます([RFC3007])。他の種類がその名前に存在 していてはなりません(MUST NOT)。 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 資源レコードの元の定義は他の種類のレコードがCNAMEレコードと共存 することを許しませんでしたが、署名されたゾーンがすべての正式な名前の ためにNSECと資源レコード署名資源レコードを必要とします。この矛盾 を解決するために、この仕様書はNSECと資源レコード署名資源レコード との共存することを許すためにCNAME資源レコードの定義を修正します。 2.6. DNSSEC RR Types Appearing at Zone Cuts 2.6. ゾーン切断に現われるDNSSEC資源レコード種別 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つの 新しい資源レコード種別を導入しました。ゾーン切断(すなわち、委任点) の親側において、その所有者名のNSEC資源レコードが必要とされます (REQUIRED)。もし委任されているゾーンが署名され、そして親ゾーンと認証 鎖を持とうと努めるなら、委任署名資源レコードも存在し得ます。これは元 のDNS仕様書([RFC1034])の例外です、元の仕様書はゾーン切断の親の側 においてNS資源レコード集合だけが現われることができると述べます。 This specification updates the original DNS specification to allow NSEC and DS RR types at the parent side of a zone cut. These RRsets are authoritative for the parent when they appear at the parent side of a zone cut. この仕様書はゾーン切断の親側においてNSECと委任署名資源レコード種 別を許すために元のDNS仕様書を更新します。これらの資源レコード集合 は、ゾーン切断の親側において現われる時、親の正式データです。 2.7. Example of a Secure Zone 2.7. セキュアゾーンの例 Appendix A shows a complete example of a small signed zone. 付録Aで小さい署名されたゾーンの完全な例を示します。 3. Serving 3. サーバ 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])メッセー ジサイズ拡張をサポートしなくてはならず(MUST)、少なくとも1220のオ クテットのメッセージサイズをサポートしなくてはならなくて(MUST)、そし て4000のオクテットのメッセージサイズをサポートするべきです(SHOULD)。 IPv6パケットはソースホストでのみ断片化できるので、セキュリティの 認識のあるネームサーバは、パスMTUが知られていないなら、IPv6上 で伝達するUDPデータグラムが到達する事を確実にするために、必要なら 最小IPv6MTUに分割されていることを保証する処置を取るべきです。 パケットサイズと分割問題のこれ以上の論議は[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疑似資源レコードを含まない、あるいはそのDOビットが クリアされているDNS問合せを受け取るセキュリティの認識のあるネーム サーバは、資源レコード署名とDNSKEYとNSEC資源レコードを他の 資源レコード集合と同様に扱い(MUST)、下記述の追加処理を行ってはなりま せん(MUST NOT)。委任署名資源レコード種別が委任点の親ゾーンでだけ存在 する奇妙な特性を持つので、委任署名資源レコードは、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: サポートする複数のゾーンの一致するセキュリティ資源レコード種別(例え ば、サーバが委任点の上下のゾーンで正式である時の、NSECと資源レコー ド署名資源レコード)を明確に要求されたセキュリティの認識のあるネーム サーバは、自己一貫性のある動作をすべきです。ネームサーバのそれぞれの 問合せで常に回答に整合性がある限り、ネームサーバは次のいずれかを返す かもしれません: o The above-delegation RRsets. o 委任の上の資源レコード集合 o The below-delegation RRsets. o 委任の下の資源レコード集合 o Both above and below-delegation RRsets. o 委任の上と下の資源レコード集合 o Empty answer section (no records). o 空の解答章(レコードなし) o Some other response. o 何か他の回答 o An error. 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(正しいデータ)ビット。CDビットは リゾルバによって制御されます;セキュリティの認識がある名前サーバは問 合せのCDビットを対応する回答にコピーしなくてはなりません(MUST)。A Dビットはネームサーバによって制御されます;セキュリティの認識がある ネームサーバは問合せのADビットの設定を無視しなくてはなりません(MUST)。 これらのビットの行動の詳細は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資源レコードからCNAME資源 レコードを合成するセキュリティの認識のあるネームサーバは、合成された CNAME資源レコードの署名を生成するべきではありません(SHOULD NOT)。 3.1. Authoritative Name Servers 3.1. 正式なネームサーバ 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疑似資源レコードのDOビット([RFC3225]が 設定された適切な問合せを受け取ると、署名されたゾーンのセキュリティの 認識がある正式なネームサーバは、次の規則に従って追加の資源レコード署 名とNSECと委任署名資源レコードを含まなくてはなりません(MUST): 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 回答を認証するために使うことができる資源レコード署名資源レコードは 3.1.1章の規則に従って回答に含めなくてはなりません(MUST)。 o NSEC RRs that can be used to provide authenticated denial of existence MUST be included in the response automatically according to the rules in Section 3.1.3. o 非存在の認証を供給するために使うことができるNSEC資源レコードは 3.1.3章の規則に従って自動的に回答に含めなくてはなりません(MUST)。 o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST be included in referrals automatically according to the rules in Section 3.1.4. o 委任署名資源レコード集合あるいは委任署名資源レコードが存在しないこ とを証明しているNSEC資源レコードは3.1.4章の規則に従って自動 的に照会に含めなくてはなりません(MUST)。 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"). これらの規則は意味的に資源レコードの存在か不在の情報を運ぶ回答に当て はまるだけです。すなわち、これらの規則は応答コード4(「未実装」)や 応答コード5(「拒否」)のような回答の抑制を意図しません。 DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 discusses zone transfer requirements. DNSSECはDNSゾーン転送プロトコルを変えません。3.1.5章が地 域転送必要条件を論じます。 3.1.1. Including RRSIG RRs in a Response 3.1.1. 回答に資源レコード署名資源レコードを含めること 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ビットが設定された問合せに返答する時、セキュリティの認識がある正 式なネームサーバはセキュリティの認識があるリゾルバが回答の資源レコー ド集合を認証するために使うことができる資源レコード署名資源レコードを 送ろうと試みるべきです(SHOULD)。ネームサーバは応答に資源レコード集合 と関連する資源レコード署名の両方を入れる全ての試みをするべきです (SHOULD)。回答に資源レコード署名資源レコードを含める際に、次の規則が 適用されます: 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 署名された資源レコード集合を解答部に設定する時、ネームサーバはその 資源レコード署名資源レコードを解答部に置かなくてはなりません(MUST)。 資源レコード署名資源レコードは含める必要がある他の資源レコード集合 よりも高い優先度を持っています。もしこれらの資源レコード署名資源レ コードを入れる空間がないなら、ネームサーバはTCビットを設定しなけ ればなりません(MUST)。 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 署名された資源レコード集合を権威部に設定する時、ネームサーバはその 資源レコード署名資源レコードを権威部に設定しなければなりません(MUST)。 資源レコード署名資源レコードは含める必要がある他の資源レコード集合 よりも高い優先度を持っています。もしこれらの資源レコード署名資源レ コードを入れる空間がないなら、ネームサーバは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 署名された資源レコード集合を追加部に設定する時、ネームサーバはその 資源レコード署名資源レコードを追加部に置かなくてはなりません。もし 資源レコード集合と関連する資源レコード署名資源レコードの両方を含め る空間がないなら、ネームサーバは、資源レコード署名資源レコードを捨 てて、資源レコード集合を維持するかもしれません(MAY)。もしこうなった 場合、これらの資源レコード署名資源レコードは必須ではないので、ネー ムサーバはTCビットを設定してはなりません(MUST NOT)。 3.1.2. Including DNSKEY RRs in a Response 3.1.2. 回答にDNSKEY資源レコードを含めること 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かネームサーバ資源 レコードを求める問合せに応答する時、そのゾーンのセキュリティの認識が ある正式なネームサーバが追加部でゾーン頂上のDNSKEY資源レコード 集合を返すかもしれません。この場合、DNSKEY資源レコード集合と関 連する資源レコード署名資源レコードは追加部に置かれる他の情報より低い 優先度になります。DNSKEY資源レコード集合と関連する資源レコード 署名資源レコードの両方に十分な空間がないなら、ネームサーバは回答にD NSKEY資源レコード集合を含めるべきではありません(SHOULD NOT)。も しこれらのDNSKEYと資源レコード署名資源レコードを含むのに十分な 空間がないなら、ネームサーバはこれらを除かなくてはならなくて(MUST)、 そしてこれらの資源レコードは必須ではないのでTCビットを設定してはな りません(MUST NOT)(3.1.1章参照)。 3.1.3. Including NSEC RRs in a Response 3.1.3. 回答にNSEC資源レコードを含めること When responding to a query that has the DO bit set, a security-aware authoritative name server for a signed zone MUST include NSEC RRs in each of the following cases: DOビットの設定された問合せに応答する時、署名されたゾーンのセキュリ ティの認識がある正式な名前サーバは、次の場合のそれぞれにNSEC資源 レコードを含めなくてはなりません(MUST): 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>に正確に一致する資源レコード集合を 持つが、正確に<SNAME, SCLASS, STYPE>に一致する資源レコード集合を持っ ていません。 Name Error: The zone does not contain any RRsets that match <SNAME, SCLASS> either exactly or via wildcard name expansion. 名前エラー:ゾーンは正確にあるいはワイルドカード名前拡大によって <SNAME, SCLASS>に一致する資源レコード集合を含んでいません。 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>に一致する資源レコー ド集合を含んでいません、しかしワイルドカード名前拡大によって <SNAME, SCLASS, STYPE>に一致する資源レコード集合を含んでいます。 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>に一致する資源 レコード集合を含まず、ワイルドカード名前拡大によって<SNAME, SCLASS> と一致する資源レコード集合を含んでいるが、ワイルドカード名前拡大 によって<SNAME, SCLASS, STYPE>と一致する資源レコード集合を含んで いません。 In each of these cases, the name server includes NSEC RRs in the response to prove that an exact match for <SNAME, SCLASS, STYPE> was not present in the zone and that the response that the name server is returning is correct given the data in the zone. これらのそれぞれの場合に、ネームサーバは正確に<SNAME, SCLASS, STYPE> に一致するものがゾーンになく、ネームサーバが返す応答がゾーンで正しい 事を証明するために回答にNSEC資源レコードを含めます。 3.1.3.1. Including NSEC RRs: No Data Response 3.1.3.1. NSEC資源レコードを含むこと:データなし回答 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>に一致する資源レコード集合があるが、 <SNAME, SCLASS, STYPE>に一致する資源レコード集合がなければ、ネームサー バは<SNAME, SCLASS>のNSEC資源レコードと対応する資源レコード署名資 源レコードを応答の権威部に設定しなければなりません(MUST)(3.1.1章 参照)。もしNSEC資源レコードや関連する資源レコード署名資源レコー ドを含める空間がなければ、ネームサーバはTCビットを設定しなければな りません(MUST)(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. 探索名が存在するので、ワイルドカード名前拡大がこの問合せに当てはまり ません、そして1つの署名されたNSEC資源レコードが求められた資源レ コード種別が存在しないことを証明するのに十分です。 3.1.3.2. Including NSEC RRs: Name Error Response 3.1.3.2. NSEC資源レコードを含むこと:名前エラー回答 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>に一致する資源レコード集合がないなら、ネームサーバは権 限部に次のNSEC資源レコードと関連する資源レコード署名資源レコード を含まなくてはなりません(MUST): o An NSEC RR proving that there is no exact match for <SNAME, SCLASS>. o 正確に<SNAME, SCLASS>と一致するものがない事を示すNSEC資源レコー ド。 o An NSEC RR proving that the zone contains no RRsets that would match <SNAME, SCLASS> via wildcard name expansion. o ゾーンにワイルドカード拡大によって<SNAME, SCLASS>に一致する資源レ コード集合がない事を示すNSEC資源レコード。 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資源レコードが両方を証明するかもしれませ ん。もしそうなら、ネームサーバは権限部にそのNSEC資源レコードと資 源レコード署名資源レコードを1つだけ含むべきです(SHOULD)。 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と資源レコード署名資源レコードの両方を含める空間がないな ら、ネームサーバはTCビットを設定します(MUST)(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と資源レコード署名資源レコードが回答の権威部に含められる時、 これらの資源レコードの所有者名はワイルドカード名前拡大の適用を受けま せん。 Note that this form of response includes cases in which SNAME corresponds to an empty non-terminal name within the zone (a name that is not the owner name for any RRset but that is the parent name of one or more RRsets). この回答の形式は SNAMEがゾーンの空の非終端の名前(どんな資源レコード 集合の所有者名でもないが、ある資源レコード集合の親の名である名前)に 対応する場合があることに注意してください。 3.1.3.3. Including NSEC RRs: Wildcard Answer Response 3.1.3.3. NSEC資源レコードを含むこと:ワイルドカード解答応答 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>に一致する資源レ コード集合があるなら、ネームサーバは解答部にワイルドカードによって拡 大された答えと対応するワイルドカードによって拡大された資源レコード署 名資源レコードを含めなくてはならず(MUST)、そして権威部にゾーンに <SNAME, SCLASS>と正確に一致するものがばい事を示すNSEC資源レコード と対応する資源レコード署名資源レコードを含めなければなりません(MUST)。 もしNSECと資源レコード署名資源レコードを含める空間がないなら、ネー ムサーバはTCビットを設定します(3.1.1章参照)。 3.1.3.4. Including NSEC RRs: Wildcard No Data Response 3.1.3.4. NSEC資源レコードを含むこと:ワイルドカードデータなし回答 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>に一致する資源レ コード集合を含むが、STYPEに一致するものがありません。ネームサーバは権 限部に以下のNSEC資源レコードと関連する資源レコード署名資源レコー ドを含めなければなりません(MUST): o An NSEC RR proving that there are no RRsets matching STYPE at the wildcard owner name that matched <SNAME, SCLASS> via wildcard expansion. o ワイルドカード拡大に<SNAME, SCLASS>に一致したワイルドカード所有者 名にSTYPEと一致している資源レコード集合がない事を示すNSEC資 源レコード。 o An NSEC RR proving that there are no RRsets in the zone that would have been a closer match for <SNAME, SCLASS>. o ゾーンに<SNAME, SCLASS>に正確に一致する資源レコード集合がない事を 示すNSEC資源レコード。 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資源レコードが両方を証明するかもしれません。 もしそうなら、ネームサーバは権限部にNSEC資源レコードとその資源レ コード署名資源レコードを1つだけ含めるべきです(SHOULD)。 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と資源レコード署名資源レコードの所有者名は、これらの 資源レコードが回答の権限部に含められる時、ワイルドカード名前拡大の適 用を受けません。 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と資源レコード署名資源レコードを含める空間がない なら、ネームサーバはTCビットを設定しなければなりません(3.1章参照)。 3.1.3.5. Finding the Right NSEC RRs 3.1.3.5. 正しいNSEC資源レコードの発見 As explained above, there are several situations in which a security-aware authoritative name server has to locate an NSEC RR that proves that no RRsets matching a particular SNAME exist. Locating such an NSEC RR within an authoritative zone is relatively simple, at least in concept. The following discussion assumes that the name server is authoritative for the zone that would have held the non-existent RRsets matching SNAME. The algorithm below is written for clarity, not for efficiency. 上で説明したように、セキュリティの認識がある正式な名前サーバが特定の SNAMEと一致する資源レコード集合が存在しないことを証明するNSEC資源 レコードを設定しなければならないいくつかの状態があります。正式なゾー ンの中でこのようなNSEC資源レコードを突き止めることは、少なくとも 概念的には、比較的単純です。次の議論はネームサーバがSNAMEと一致する非 実在の資源レコード集合を持つゾーンのために正式なサーバと想定します。 以下のアルゴリズムは、効率ではなく、わかりやすさで書かれます。 To find the NSEC that proves that no RRsets matching name N exist in the zone Z that would have held them, construct a sequence, S, consisting of the owner names of every RRset in Z, sorted into canonical order ([RFC4034]), with no duplicate names. Find the name M that would have immediately preceded N in S if any RRsets with owner name N had existed. M is the owner name of the NSEC RR that proves that no RRsets exist with owner name N. 名前Nを持ちうるゾーンZで名前Nに一致する資源レコードがない事を証明 するNSEC資源レコードを見つけるため、Zの全ての資源レコードの所有 者名からなる列Sを生成し、重複名を除いて正規順序([RFC4034])で並べな おします。もし所有者名がNの資源レコード集合が存在しているなら、Sの 中でNの直前の名前M]を見つけます。Mが所有者名Nの資源レコード集合 が存在しないことを証明するNSEC資源レコードの所有者名です。 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資 源レコードを見いだすアルゴリズムは類似ですが、余分の手順を必要としま す。より正確に、適用可能なワイルドカード名の資源レコードが存在しない ことを証明するNSECは、他の所有者名の資源レコード集合が存在しない ことを証明するNSEC資源レコードを見いだすアルゴリズムと正確に同じ です。欠けている部分は存在しない適用可能なワイルドカードの名前を決定 する方法です。実際は、これは容易です、なぜなら正式なネームサーバはす でに正確に[RFC1034]の4.3.2章で記述された標準的な検索アルゴリズムの 手順(1)(c)の一部としてのワイルドカード名の存在を調べたからです。 3.1.4. Including DS RRs in a Response 3.1.4. 回答に委任署名資源レコードを含めること 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ビットを設定した問合せに返答する時、セキュリティの認識がある正式 なネームサーバは参照としてのNS資源レコード集合とともに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. もし委任署名資源レコード集合が委任点に存在しているなら、名前サーバは NS資源レコードと共に権威部に、委任署名資源レコード集合と関連する資 源レコード署名資源レコ−ドを返さなければなりません(MUST)。 If no DS RRset is present at the delegation point, the name server MUST return both the NSEC RR that proves that the DS RRset is not present and the NSEC RR's associated RRSIG RR(s) along with the NS RRset. The name server MUST place the NS RRset before the NSEC RRset and its associated RRSIG RR(s). もし委任署名資源レコード集合が委任点に存在しないなら、ネームサーバは NS資源レコード集合と、委任署名資源レコード集合が存在していないこと を証明するNSEC資源レコードとNSEC資源レコードに関する資源レコー ド署名資源レコードの両方を返さなくてはなりません(MUST)。ネームサーバ はNSEC資源レコード集合と関連する資源レコード署名資源レコードの前 にNS資源レコード集合を置かなくてはなりません(MUST)。 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). これらの委任署名とNSECと資源レコード署名資源レコードを含める事は、 参照メッセージのサイズを大きくし、一部か全部の接着剤資源レコードを削 除するかもしれません。もし委任署名やNSEC資源レコード集合と関連す る資源レコード署名資源レコードを含める空間がないなら、ネームサーバは TCビットを設定します(MUST)(3.1.1章参照)。 3.1.4.1. Responding to Queries for DS RRs 3.1.4.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. 委任署名資源レコード種別は、それがゾーン切断の親ゾーン側にだけ現われ るという点で、普通ではありません。例えば、"foo.example"の委任のための 委任署名資源レコード集合は"foo.example"ゾーンではなく"example"ゾーン に保管されます。これは、標準的なDNS規則で子ゾーンのネームサーバが ゾーン切断の名前の権威であるから、ネームサーバとリゾルバ両方で特別な 処理規則を必要とします、しかし子ゾーンは委任署名資源レコード集合を含 んでいません。 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. セキュリティの認識のあるリゾルバは、委任点で必要とされる委任署名資源 レコードを探す時、親ゾーンに質問を送ります(4.2章参照)。しかしなが ら、このような問合せを処理に関係するセキュリティの認識がないリゾルバ (例えば、セキュリティの認識があるリゾルバがが、セキュリティの認識が ない再帰ネームサーバを通して問合せをするネットワーク設定で)の混乱を 避けるために必要です。この章の残りがセキュリティの認識があるネームサー バがこの問題を避けて委任署名の問合せを処理する方法を記述します。 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 ネームサーバはゾーン切断の場所で委任署名資源レコード集合の問合せを 受信。 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. すべての他の場合は、ネームサーバは委任署名資源レコード集合を得る方法 を持つか、DNSSEC以前の処理規則で委任署名資源レコード集合を得る 事が期待できます、それでネームサーバは標準的な処理規則に従って委任署 名資源レコード集合あるいはエラー回答を返すことができます。 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の権威です が、求められた資源レコード集合を供給することができません。この場合、 ネームサーバは委任署名資源レコード集合が子ゾーンの頂上で存在しないこ とを示す正式な「データなし」回答を返してはなりません(MUST)。このよう な回答の例として付録B.8を見てください。 3.1.5. Responding to Queries for Type AXFR or IXFR 3.1.5. AXFRやIXFRの質問への返答 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ゾーン転送プロセスを変えません。署名されたゾーン は資源レコード署名とDNSKEYとNSECと委任署名資源レコードを含 みますが、これらのレコードはゾーン転送オペレーションに関して特別な意 味を持っていません。 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章 で記述された署名必要条件のいずれかを満さないなら、正式なネームサーバ は全部のゾーン転送を拒絶することに決めてもよいです(MAY)。ゾーン転送の 主目的はすべての正式なネームサーバが同一のゾーンのコピーを持っている ことを保証することです。自身のゾーンの検証を行うことに決める正式なネー ムサーバは選択的にある資源レコードを拒絶し、他を受け入れてはなりませ ん(MUST NOT)。 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. 委任署名資源レコード集合はゾーン切断の親の側にだけ現われて、親ゾーン で正式なデータです。他のいかなる正式な資源レコード集合と同じように、 委任署名資源レコード集合は資源レコード集合が正式なデータであるゾーン のゾーン転送に含められなくてはなりません(MUST)。委任署名資源レコード 集合の場合、これは親ゾーンです。 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資源レコードはゾーン切断の両方の親と子ゾーンに現われて、そし て親と子のゾーンの両方で正式なデータです。ゾーン切断の親と子のNSE C資源レコード本質的に同一ではなく、子ゾーンの頂上のNSEC資源レコー ドは子ゾーンのSOA資源レコードの存在を示し、ゾーン切断の親のNSE C資源レコードは決してSOA資源レコードの存在を示しません。他のいか なる正式な資源レコードと同じように、NSEC資源レコードはそれらが正 式なデータであるゾーンのゾーン転送に含められなくてはなりません(MUST)。 ゾーン切断の親のNSEC資源レコードは親ゾーンのゾーン転送に含められ なくてはなりません、そして子ゾーンのゾーン頂上のNSECは子ゾーンの ゾーン転送に含められなくてはなりません(MUST)。 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. 資源レコード署名資源レコードはゾーン切断の親と子ゾーンの両方に現われ て、そして資源レコード署名資源レコードが署名を供給する正式な資源レコー ド集合を含んでいるゾーンで正式です。すなわち、委任署名資源レコード集 合やゾーン切断の親のNSEC資源レコードの資源レコード署名資源レコー ドは親ゾーンで正式であり、子ゾーンの頂上の資源レコード集合の資源レコー ド署名は子供ゾーンで正式であるでしょう。ゾーン切断の親と子の資源レコー ド署名資源レコードは本質的に異なっていて、子ゾーンの頂上の資源レコー ド署名資源レコードの署名者名フィールドは子ゾーンの頂上のDNSKEY 資源レコードを示し、親の資源レコード署名資源レコードの同じフィールド が親ゾーンの頂上のDNSKEY資源レコードを示すでしょう。他の正式な 資源レコードと同じようにでも、資源レコード署名資源レコードは、それが 正式なデータであるゾーンのゾーン転送に含められなくてはなりません(MUST)。 3.1.6. The AD and CD Bits in an Authoritative Response 3.1.6. 正式な回答のADとCDビット 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ビット をクリアするべきです(SHOULD)。 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. セキュリティの認識があるネームサーバは、ネームサーバがすべての答えの 資源レコード集合と回答の権限部が本物であると考える場合を除き、ADビッ トを設定してはなりません(MUST NOT)。セキュリティの認識のあるネームサー バのローカルポリシは正式なゾーンのデータが検証なしで正しいと考えるか もしれません(MAY)。しかしながら、ネームサーバは、ネームサーバが(安全 なゾーン転送メカニズムのような)安全な手段で正式なゾーンを得てなけれ ばこうしてはならず(MUST NOT)、そして、この行動が明示的に設定されなけ ればこうしてはなりません(MUST NOT)。 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ビッ トの規則に従わなければなりません(MUST)。 3.2. Recursive Name Servers 3.2. 再帰ネームサーバ As explained in [RFC4033], a security-aware recursive name server is an entity that acts in both the security-aware name server and security-aware resolver roles. This section uses the terms "name server side" and "resolver side" to refer to the code within a security-aware recursive name server that implements the security-aware name server role and the code that implements the security-aware resolver role, respectively. [RFC4033]で説明したように、セキュリティの認識がある再帰ネームサーバは セキュリティの認識のあるネームサーバとセキュリティの認識のあるリゾル バの両方の役割で動作するエンティティーです。この章はセキュリティの認 識がある再帰ネームサーバの中のセキュリティの認識のあるネームサーバ役 割を実行するコードとセキュリティの認識のあるリゾルバ役割を実行するコー ドを参照するために、それぞれ「ネームサーバの側面」と「リゾルバの側面」 という用語を使います。 The resolver side follows the usual rules for caching and negative caching that would apply to any security-aware resolver. リゾルバの側面は、どんなセキュリティの認識のあるリゾルバにも当てはま るキャッシュとネガティブキャッシュの規則に従います。 3.2.1. The DO Bit 3.2.1. DOビット 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ビットを設定しなければなりません(MUST)。もし最初の要求のD Oが設定されていなければ、ネームサーバの側面は回答から認証のDNSS EC資源レコードを取去らなければなりません(MUST)が、初めの問合せが明 示的に求めたDNSSEC資源レコードを取去ってはなりません(MUST NOT)。 3.2.2. The CD Bit 3.2.2. CDビット 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ビットの設定を写さな ければなりません(MUST)。 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ビットの設定状態を渡さなければ なりません(MUST)、それでリゾルバの側面はネームサーバの側面に返す回答 データの検証が要求されているかどうか知るでしょう。もしCDビットが設 定されるなら、それは出発点のリゾルバはそのローカルポリシが必要とする 検証を行うことを示します。それで、再帰ネームサーバのリゾルバの側面は 回答の資源レコード集合の検証を行う必要がありません。CDビットが設定 されるとき、たとえ再帰ネームサーバのローカル認証ポリシがそのレコード を拒絶しても、再帰ネームサーバは、もし可能であるなら、出発点のリゾル バに求められたデータを返すべきです(SHOULD)。すなわち、CDビットを設 定する事で、出発点のリゾルバは自分が検証を行うことに対して責任をとる ことを示し、そして再帰ネームサーバはそれ妨げるべきではありません。 If the resolver side implements a BAD cache (see Section 4.7) and the name server side receives a query that matches an entry in the resolver side's BAD cache, the name server side's response depends on the state of the CD bit in the original query. If the CD bit is set, the name server side SHOULD return the data from the BAD cache; if the CD bit is not set, the name server side MUST return RCODE 2 (server failure). もしリゾルバの側面が悪いキャッシュ(4.7章参照)を実装し、そしてネー ムサーバの側面がリゾルバの側面の悪いキャッシュ項目と一致する問合せを 受け取るなら、ネームサーバの側面の回答は元の問合せのCDビットの状態 に依存します。もしCDビットが設定されるなら、ネームサーバの側面は悪 いキャッシュのデータを返すべきです(SHOULD);もしCDビットが設定され ないなら、ネームサーバの側面はRCODE2(サーバ失敗)を返さなくてはなり ません(MUST)。 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. 上記の規則の意図は、セキュリティの認識がある再帰ネームサーバのリゾル バの側面が検証を実行することをあてにするクライアントを守りながら、自 身で署名検証を行うことができるクライアントに生のデータを供給するため です。署名検証に失敗する理由のいくつかは、再帰ネームサーバと呼出しク ライアントで等しくない状態により発生します。例えば、再帰ネームサーバ の時計は間違って調整されるかもしれませんし、あるいはクライアントは再 帰ネームサーバが共有しない適切なセキュリティの孤島の知識を持っている かもしれません。このような場合、自身で署名検証を行うことができるクラ イアントを「悪い」データを見ることから「守る」ことはクライアントを助 けません。 3.2.3. The AD Bit 3.2.3. ADビット 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]. セキュリティの認識がある再帰ネームサーバのネームサーバの側面は、ネー ムサーバが解答部と権威部のすべての資源レコード集合が本物であると考え る場合を除き、回答でADビットを設定してはなりません(MUST NOT)。ネー ムサーバの側面は、リゾルバの側面が解答部のすべての資源レコード集合と 関連する権威部の否定応答資源レコードが検証されたと考える場合に限り、 そしてその場合には必ず、ADビットを設定するべきです(SHOULD)。リゾル バの側面は問題の資源レコードが本物であるかどうか決定するために5章で 記述された手順に従わなくてはなりません(MUST)。しかしながら、逆方向互 換性のために、再帰ネームサーバは回答に非検証のCNAME資源レコード があっても、もしそれらのCNAME資源レコードがが明らかに認証済みの DNAME資源レコードから合成され、そのDNAME資源レコードが [RFC2672]で記述した統合に従って応答に含まれる、ADビットを設定するか もしれません(MAY)。 3.3. Example DNSSEC Responses 3.3. DNSSEC回答例。 See Appendix B for example response packets. 回答パケットの例は付録Bを見てください。 4. Resolving 4. リゾルバ 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章で記述されます。 4.1. EDNS Support 4.1. EDNS対応 A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo-RR with the DO ([RFC3225]) bit set when sending queries. セキュリティの認識のあるリゾルバが質問を送る時、DO([RFC3225])ビッ トを設定したEDNS([RFC2671])のOPT疑似資源レコードを含まなくて はなりません(MUST)。 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オクテットのメッ セージサイズをサポートしなくてはならなくて(MUST)、4000オクテット のメッセージサイズをサポートするべきで(SHOULD)、そして受け入れ可能な メッセージサイズを広告するためにEDNSのOPT疑似資源レコードの 「送信者のUDPペイロードサイズ」フィールドを使わなくてはなりません。 セキュリティの認識のあるリゾルバのIP層は、IPv4かIPv6かに関 わらず、受信した分割UDPパケットを正確に処理しなくてはなりません (MUST)。これらの必要条件の論議について[RFC1122]と[RFC2460]と[RFC3226] を見てください。 4.2. Signature Verification Support 4.2. 署名検証サポート 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章で記述した署名検証メカニズムが をサポートしなくてはならなくて(MUST)、そして、以下を除き、すべての受 信した回答を検証するべきです(SHOULD): 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. セキュリティの認識のあるリゾルバの、署名検証のサポートはワイルドカー ド所有者名の検証のサポートを含まなくてはなりません(MUST)。 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. セキュリティの認識があるリゾルバが検証を行うため欠けているセキュリティ 資源レコードを質問してもよいです(MAY);そうすることに決めた実装は受 信した答えが元の回答を検証するのに十分ではないかもしれないことを知っ ていなくてはなりません。例えば、元と続く質問の間にゾーン更新が求める 情報を変える(あるいは削除する)かもしれません。 When attempting to retrieve missing NSEC RRs that reside on the parental side at a zone cut, a security-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone. ゾーン切断の親の側にあるNSEC資源レコードを得ようとする時、セキュ リティの認識がある再帰モードのリゾルバは、子ゾーンではなく、親ゾーン のネームサーバに問い合わせなくてはなりません(MUST)。 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. 欠けている委任署名を得ようと試みる時、セキュリティの認識がある再帰モー ドのリゾルバは、子ゾーンではなく、親ゾーンのネームサーバに問い合わせ なくてはなりません(MUST)。3.1.4.1章で説明したように、セキュリティ の認識があるネームサーバは委任署名資源レコードを扱うために特別な処理 規則を適用する必要があります、そしてある状態でリゾルバは、もしリゾル バがまだ親のNS資源レコード集合を持っていないなら、親ゾーンのネーム サーバの場所を突き止めるために同じく特別な規則を適用する必要があるか もしれません。親NS資源レコード集合の場所を突き止めるために、リゾル バは委任名から始めて、最左ラベルを取去り、その名前でNS資源レコード 集合の質問することができます。もしNS資源レコード集合がその名前にな いなら、リゾルバは残りのラベルの最左ラベルを除き、NS資源レコード集 合を見いだすか、あるいはラベルがなくなるまで、この木を歩く処理を繰り 返し、その名前の質問をし続けます。 4.3. Determining Security Status of Data 4.3. データのセキュリティ状況の決定 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: セキュリティの認識のあるリゾルバは特定の資源レコード集合が署名されて ると期待するべきかどうか決定できなければなりません(MUST)。より正確に 言うと、セキュリティの認識のあるリゾルバは4つの場合を区別できなけれ ばなりません: Secure: An RRset for which the resolver is able to build a chain of signed DNSKEY and DS RRs from a trusted security anchor to the RRset. In this case, the RRset should be signed and is subject to signature validation, as described above. 安全:リゾルバが信頼できるセキュリティーアンカーから資源レコード集合 まで署名されたDNSKEYと委任署名資源レコードの鎖を築くことが可 能な資源レコード集合。この場合、資源レコード集合は署名されるべきで あり、そして、上に記のように署名検証を受けます。 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. 不安定:信頼できる出発点から資源レコード集合までの署名されたDNSK EYと委任署名資源レコードの鎖がないのをリゾルバが知っています。目 標資源レコード集合が署名されていないゾーンあるいは署名されていない ゾーンの下にあるとき、これは起きえます。この場合、資源レコード集合 は署名されるてるかもしれないし、そうでないかもしれませんが、しかし リゾルバは署名を確認可能ではないでしょう。 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. 偽リゾルバは資源レコード集合の信頼鎖を形成できなければいけないと考え ているが、何らかの理由で署名の検証に失敗するか、存在するはずの適切 なDNSSEC資源レコードが欠けているために、できなかっ場合。この 場合は攻撃を示すかもしれませんが、設定エラーあるいは何らかの形のデー タ破壊を示すかもしれません。 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資源レコードを得ることができず、 リゾルバは資源レコード集合が署名されるべきかどうか決定できません。 セキュリティの認識があるリゾルバが目的ゾーンのセキュリティの認識の あるネームサーバと接触することができないときに、これは生じます。 4.4. Configured Trust Anchors 4.4. 信頼固定点の設定 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つの信頼する公開鍵か委 任署名資源レコードを設定できるに違いなく(MUST)、そして多数の信頼する 公開鍵や委任署名資源レコードを設定できるべきです(SHOULD)。セキュリティ の認識のあるリゾルバがこのような設定された信頼固定点なしで署名の妥当 性を検査することが可能ではないでしょうから、リゾルバは起動するときに 鍵を得る何らかの適度に強靭なメカニズムを持つべきです(SHOULD);このよ うなメカニズムの例は(ディスク・ドライブのような)何らかの形の不発揮 性の記憶装置や、何らかの形の信頼できるローカルネットワーク設定機構で しょう。 Note that trust anchors also cover key material that is updated in a secure manner. This secure manner could be through physical media, a key exchange protocol, or some other out-of-band means. 信頼固定点が確実な方法で更新される鍵材料を取り扱うことに注意してくだ さい。この確実な方法は物理メディアや鍵交換プロトコルや何か他のアウト バンドの方法かもしれません。 4.5. Response Caching 4.5. 回答キャッシュ 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>. セキュリティの認識のあるリゾルバは資源レコードと関連するDNSSEC 資源レコードを含む全部の答えを一つの原子項目として回答キャッシュする べきです(SHOULD)。それに含まれる資源レコードのいずれかの期限が切れる とき、リゾルバは全部の原子項目を捨てるべきです(SHOULD)。ほとんどの場 合、原子項目の適切なキャッシュインデックスは<QNAME, QTYPE, QCLASS>の 3項組みですが、フォームがセクション3.1.3.2章で記述した形式の場合 の適切なキャッシュインデックスは<QNAME,QCLASS>であるでしょう。 The reason for these recommendations is that, between the initial query and the expiration of the data from the cache, the authoritative data might have been changed (for example, via dynamic update). この推薦の理由は、最初の質問とキャッシュデータの期限切れの間に、正式 なデータが(例えば、動的更新によって)変わったかもしれないということ です。 There are two situations for which this is relevant: これが適切である2つの状態があります: 1. By using the RRSIG record, it is possible to deduce that an answer was synthesized from a wildcard. A security-aware recursive name server could store this wildcard data and use it to generate positive responses to queries other than the name for which the original answer was first received. 1. 資源レコード署名レコードを使うことによって、答えがワイルドカード から合成されたことを推論することは可能です。 セキュリティの認識 がある再帰的ネームサーバがこのワイルドカードデータを記憶し、最初 の応答で受信した名前以外の問合せに対する肯定的な応答を生成するた めに使うことができます。 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資源レコードは、その 名前範囲の他の名前の非実在を示すためにセキュリティの認識のあるリ ゾルバによって再利用できます。 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. 理論上、レコードに関するTTLか署名期限が切れるまで、リゾルバはワイ ルドカードやNSEC資源レコードを(それぞれ)肯定と否定応答を生成す るために使うことができます。しかしながら、リゾルバが新しい正式なデー タを遮るのを避けるか、独自に新しいデータを合成するのを避けることは賢 明に思われます。この推薦に従うリゾルバが名前空間のより整合性がある光 景だと示すでしょう。 4.6. Handling of the CD and AD Bits 4.6. CDとADビットの取り扱い 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. ローカルポリシが回答の資源レコード集合に認証を要求する場合でも、セキュ リティの認識のあるリゾルバが認証実行の責任をとることを示すために質問 のCDビットを設定するかもしれません(MAY)。このビットがセキュリティの 認識がある再帰的ネームサーバの行動に与える効果は3.2章を見てください。 A security-aware resolver MUST clear the AD bit when composing query messages to protect against buggy name servers that blindly copy header bits that they do not understand from the query message to the response message. 問合せメッセージから応答メッセージへ理解せずにやみくもにヘッダ部分を コピーするバグだらけのネームサーバからの保護のために、問合せメッセー ジを書くときにセキュリティの認識があるリゾルバはADビットをクリアし なくてはなりません(MUST)。 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 ビットの意味を無視しなくてはなりません(MUST)。 4.7. Caching BAD Data 4.7. 悪いデータのキャッシュ 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. 検証エラーは多くはないでしょうが、管理上のエラー(ゾーン再署名のエラー 、時計誤り、など)によって起こったものは持続する可能性が高いです。再 質問はこれらの場合助けにならないでしょうから、資源レコード集合の持続 的な検証失敗で繰り返された問合せの結果として、検証リゾルバが多くの不 必要なDNSトラフィックを生成するかもしれません。 To prevent such unnecessary DNS traffic, security-aware resolvers MAY cache data with invalid signatures, with some restrictions. 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". このような不必要なDNSトラフィックを防ぐために、セキュリティの認識 があるリゾルバがある制限付きで無効な署名のデータをキャッシュするかも しれません(MAY)。概念的に、このようなデータをキャッシュすることは、リ ゾルバが正当な否定回答をキャッシュする代わりに特定の答えの妥当性検査 に失敗した事実をキャッシュする以外、ネガティブキャッシュ([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: 悪いキャッシュを実装するリゾルバは、キャッシュがサービス妨害攻撃の増 幅、特に次が有用となる事を阻止する処置を取らなくてはなりません(MUST): 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 検証に失敗した資源レコード集合は信頼できるTTLを持たないので、実 装はTTLを割り当てなくてはなりません(MUST)。このTTLは攻撃の結 果をキャッシュする効果を和らげるために、小さくあるべきです(SHOULD)。 o In order to prevent caching of a transient validation failure (which might be the result of an attack), resolvers SHOULD track queries that result in validation failures and SHOULD only answer from the BAD cache after the number of times that responses to queries for that particular <QNAME, QTYPE, QCLASS> have failed to validate exceeds a threshold value. o (攻撃の結果かもしれない)短期的な検証失敗のキャッシュを妨げるため に、リゾルバは検証失敗をもたらす問合せを追跡するべきで(SHOULD)、そ して特定の<QNAME, QTYPE, QCLASS>の問合せの失敗が規定回数を越えた場 合にだけ悪いキャッシュから応答するべきです(SHOULD)。 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章で規定された規則により資源レコード集合の 署名の検証を必要とされない場合を除き、悪いキャッシュの資源レコード集 合を返してはなりません(MUST NOT)。セキュリティの認識がある再帰ネーム サーバの応答と悪いキャッシュと相互に作用の議論は3.2.2章を見てくだ さい。 4.8. Synthesized CNAMEs 4.8. CNAME合成 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資源レコード署名がDNAME資源レコード から合成された無署名の資源レコードをカバーしていると、少なくとも単に CNAME資源レコードを含んでいるからといって回答メッセージを拒絶し ない程度に、見なさなくてはなりません(MUST)。リゾルバはキャッシュや応 答でこのようなCANME資源レコードを維持するかもしれません(MAY)が、 そうするように要求はされません。 4.9. Stub Resolvers 4.9. スタブリゾルバ 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資源レコードを 含んでいるからといって、応答の処置を誤らない程度に、DNSSEC資源 レコードタイプをサポートしなくてはなりません(MUST)。 4.9.1. Handling of the DO Bit 4.9.1. DOビットの扱い 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資源レコードを含むかも しれません(MAY)が、そうする必要はありません。これをする非検証のスタブ リゾルバが再帰的ネームサーバからDNSSEC資源レコードを受け取るた めにDOビットを設定する必要があるでしょう。 A validating security-aware stub resolver MUST set the DO bit, because otherwise it will not receive the DNSSEC RRs it needs to perform signature validation. 検証をするセキュリティの認識があるスタブリゾルバはDOビットを設定し なくてはなりません(MUST)、さもなければ署名検証に必要なDNSSEC資 源レコードを受け取らないでしょう。 4.9.2. Handling of the CD Bit 4.9.2. CDビットの扱い 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ビットを設定するべきではあ りません(SHOULD NOT)。 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ビットを設定す るべきです(SHOULD)、さもなければセキュリティの認識がある再帰的なネー ムサーバはネームサーバーのローカルポリシを使って問合せに答え、それは スタブリゾルバのローカルポリシで受け入れられるデータの受け取りを阻止 するかもしれません。 4.9.3. Handling of the AD Bit 4.9.3. ADビットの扱い A non-validating security-aware stub resolver MAY chose to examine the setting of the AD bit in response messages that it receives in order to determine whether the security-aware recursive name server that sent the response claims to have cryptographically verified the data in the Answer and Authority sections of the response message. Note, however, that the responses received by a security-aware stub resolver are heavily dependent on the local policy of the security-aware recursive name server. Therefore, there may be little practical value in checking the status of the AD bit, except perhaps as a debugging aid. In any case, a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel. メイが AD の設定を調べるために選択した非検証のセキュリティの認識があ るスタブリゾルバは、反応を送ったセキュリティの認識がある再帰的ネーム サーバが暗号的に応答メッセージの回答部と権限分のデータを実証したと主 張するかどうか決定するために、受信した反応メッセージのADビットの設 定を調べる事に決めるかもしれません(MAY)。しかしながら、セキュリティの 認識があるスタブリゾルバにから受信した応答は、セキュリティの認識があ る再帰的なネームサーバのローカルポリシに強く依存していることに注意し てください。そのために、ADビットの状態を検査することは、デバッグの 手助けを除き、実際的な価値がないかもしれません。いずれにしても、セキュ リティの認識があるスタブリゾルバは安全なチャネルによって信頼できるセ キュリティの認識がある再帰的なネームサーバからのデータを得たときを除 き、セキュリティの認識があるスタブリゾルバは署名検証がされたと称され るものに依存してはなりません(MUST NOT)。 A validating security-aware stub resolver SHOULD NOT examine the setting of the AD bit in response messages, as, by definition, the stub resolver performs its own signature validation regardless of the setting of the AD bit. 検証をするセキュリティの認識があるスタブリゾルバは、定義上スタブリゾ ルバがADビットの設定にかかわらず自身で署名検証を行なうので、応答メッ セージのADビットの設定を調べるべきではありません(SHOULD NOT)。 5. Authenticating DNS Responses 5. DNS応答検証 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資源レコードを使うためには、セキュリティの認識があ るリゾルバが少なくとも1つの認証されたDNSKEYか委任署名資源レコー ドの知識の設定を要求します。この最初の信頼固定点の取得と認証手順は何 らかの外部手段で達成されます。例えば、ゾーンのDNSKEY資源レコー ドを得ることか、ゾーンのDNSKEY資源レコードを識別して認証できる 委任署名資源レコードを得るために、リゾルバがあるオフラインの認証され た交換を使うことができます。この章の残りはリゾルバがどうにかして最初 の1つの信頼固定点を得たと想定します。 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資源レコードはゾーンの頂上のDNSKEY資源レコー ド集合を認証するために使うことができます。最初の鍵を使って頂上DNS KEY資源レコード集合を認証するために、リゾルバは以下をしなくてはな りません(MUST): 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資源レコードが頂上DNSKEY資源レコード集合 に現われ、DNSKEY資源レコードのゾーン鍵フラグ(DNSKEY 資源データビット7)が設定されることることを確かめます;そして 2. verify that there is some RRSIG RR that covers the apex DNSKEY RRset, and that the combination of the RRSIG RR and the initial DNSKEY RR authenticates the DNSKEY RRset. The process for using an RRSIG RR to authenticate an RRset is described in Section 5.3. 2. 頂上DNSKEY資源レコード集合をカバーするある資源レコード署名 資源レコードがあり、そして資源レコード署名資源レコードと最初のD NSKEY資源レコードの組み合わせがDNSKEY資源レコード集合 を認証することを確かめてください。資源レコード集合を認証するため に資源レコード署名資源レコードを使う手順は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資源レコードを使うことによって、リゾルバが頂上DN SKEY資源レコード集合を認証したら、委任署名資源レコードを使うこと によって、そのゾーンからの委任を認証できます。これはリゾルバが最初の 鍵からスタートして、他の頂上DNSKEY資源レコード集合を得て、DN Sの木を下方向に再帰的に進むために、委任署名資源レコード集合を使うこ とを可能にします。もしリゾルバがルートDNSKEY資源レコードと共に 設定されたなら、そしてもしすべての委任がそれと結び付く委任署名資源レ コードを持っているなら、リゾルバは任意の頂上DNSKEY資源レコード 集合を得て検証することができます。委任署名資源レコードを認証参照に使 う処理は、5.2章で記述されます。 Section 5.3 shows how the resolver can use DNSKEY RRs in the apex DNSKEY RRset and RRSIG RRs from the zone to authenticate any other RRsets in the zone once the resolver has authenticated a zone's apex DNSKEY RRset. Section 5.4 shows how the resolver can use authenticated NSEC RRsets from the zone to prove that an RRset is not present in the zone. 5.3章は、リゾルバがゾーンの頂上DNSKEY資源レコード集合を認証し た後で、ゾーンの他の資源レコード集合を認証するために、頂上DNSKE Y資源レコード集合のDNSKEY資源レコードとゾーンの資源レコード署 名資源レコードをどのように使うことができるか示します。5.4章は、リゾ ルバがどのようにゾーンの認証されたNSEC資源レコード集合を資源レコー ド集合がゾーンに存在していないことを証明するために使うことができるか 示します。 When a resolver indicates support for DNSSEC (by setting the DO bit), a security-aware name server should attempt to provide the necessary DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). However, a security-aware resolver may still receive a response that lacks the appropriate DNSSEC RRs, whether due to configuration issues such as an upstream security-oblivious recursive name server that accidentally interferes with DNSSEC RRs or due to a deliberate attack in which an adversary forges a response, strips DNSSEC RRs from a response, or modifies a query so that DNSSEC RRs appear not to be requested. The absence of DNSSEC data in a response MUST NOT by itself be taken as an indication that no authentication information exists. リゾルバが(DOビットを設定することで)DNSSECのサポートを示す とき、セキュリティの認識のあるネームサーバが応答で必要なDNSKEY と資源レコード署名とNSECと委任署名資源レコード集合を提供しようと 試みるべきです(3章参照)。しかしながら、偶発的にDNSSEC資源レ コードを妨げる上流のセキュリティの認識がない再帰的なネームサーバのよ うな設定問題や、敵が応答を作り出すか、応答のDNSSEC資源レコード を抜出すか、DNSSEC資源レコードが求められないように思わせる問合 せ修正をする故意の攻撃などにより、セキュリティの認識があるリゾルバが 適切なDNSSEC資源レコードに欠ける回答を受け取るかもしれません。 回答のDNSSECデータの欠如は認証情報が存在しないという意味と思っ てはなりません(MUST NOT)。 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. リゾルバが署名されたゾーンからの認証情報を期待するべきです(SHOULD)。 もしリゾルバにゾーンの公開鍵情報は設定されたなら、あるいはもしゾーン の親が署名され、親からの委任が委任署名資源レコード集合を含むなら、リ ゾルバがゾーンが署名されてると信じるべきです(SHOULD)。 5.1. Special Considerations for Islands of Security 5.1. セキュリティの孤島に対する特別な考慮 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]参照)は、親からゾーンの認証鎖を子対句で きない署名されたゾーンです。セキュリティの孤島の署名の妥当性検査は、 検証者が孤島のある最初の認証されたゾーン鍵を得る他の手段を要求します。 もし検証者がこのような鍵を得ることができないなら、セキュリティの孤島 の中のゾーンは署名なしであるかのように運用を切替えるべきです(SHOULD)。 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. 検証回答のすべての通常の処理はセキュリティの孤島にも当てはまります。 標準的な検証とセキュリティの孤島内の検証の間の唯一の相違は検証者が検 証鎖の信頼固定点を得る方法にあります。 5.2. Authenticating Referrals 5.2. 照会の検証 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. 署名された親ゾーンの頂上DNSKEY資源レコード集合が検証されると、 委任署名資源レコード集合を署名された子供ゾーンへの委任を認証するため に使うことができます。委任署名資源レコードは、子供ゾーンの頂上DNS KEY資源レコード集合の中のDNSKEY資源レコードを識別し、そのD NSKEY資源レコードの暗号ダイジェストを含んでいます。強い暗号ダイ ジェストアルゴリズムを使用は、敵がダイジェストと一致するDNSKEY 資源レコードを生成する事が計算量的に実行不可能であることを保証します。 それで、ダイジェストを検証することで、リゾルバが対応するDNSKEY 資源レコードを認証できます。それからリゾルバはこの子DNSKEY資源 レコードを使い、全部の子の頂上DNSKEY資源レコード集合を認証でき ます。 Given a DS RR for a delegation, the child zone's apex DNSKEY RRset can be authenticated if all of the following hold: もし次を満たすなら、委任のための委任署名資源レコードを与えられても子 供ゾーンの頂上DNSKEY資源レコード集合を認証できます: o The DS RR has been authenticated using some DNSKEY RR in the parent's apex DNSKEY RRset (see Section 5.3). o 委任署名資源レコードは親の頂上DNSKEY資源レコード集合のあるD NSKEY資源レコードを使って認証されました(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 委任署名資源レコードのアルゴリズムと鍵タグは、子ゾーンの頂上DNS KEY資源レコード集合のアルゴリズムフィールドと鍵タグに一致し、そ して、DNSKEY資源レコードの所有者名と資源データが、委任署名資 源レコードのダイジェストタイプフィールドで指定されたダイジェストア ルゴリズムを使ってハッシュされるとき、結果として生じてるダイジェス ト値は委任署名資源レコードのダイジェストフィールドと一致します。 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資源レコードはゾーンフラグビットが 設定され、対応する秘密鍵は子供ゾーンの頂上DNSKEY資源レコード 集合を署名し、結果として生じる資源レコード署名資源レコードは子供ゾー ンの頂上DNSKEY資源レコード集合を認証します。 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). もし親ゾーンからの参照が委任署名資源レコード集合を含んでいなければ、 応答は委任署名資源レコード集合が委任された名前に存在しないことを証明 する、署名されたNSEC資源レコード集合を含むべきです(3.1.4章参 照)。もし参照が委任署名資源レコード集合が存在しないことを証明せず、 委任署名資源レコード集合とNSEC資源レコード集合のいずれも含まれな いなら、セキュリティの認識があるリゾルバは親ゾーンのネームサーバに委 任署名資源レコード集合を問合わせなくてはなりません(MUST)(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. もし検証者が委任署名資源レコード集合がこのゾーンに存在していないこと を証明するNSEC資源レコード集合を認証するなら、親から子までのパス を導く認証がありません。もしリゾルバが子ゾーンや子ゾーンの下のゾーン に属する初期DNSKEYあるいは委任署名資源レコードを持っているなら、 この最初のDNSKEYか委任署名資源レコードが認証パスを再確立するた めに使われるかもしれません(MAY)。もし初期DNSKEYも委任署名資源レ コードも存在しないなら、検証者は子供ゾーンやその下のゾーンの資源レコー ド集合を認証することができません。 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. もし検証者が委任署名資源レコード集合のアルゴリズムリストのどれもサポー トしないなら、リゾルバは親から子への認証パスを持ちません。リゾルバは この場合を、委任署名資源レコード集合が存在しない認証されたNSEC資 源レコード集合の場合として取り扱うべきです。 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資源レ コードがあることに注意してください。1つのNSEC資源レコードが親ゾー ンにあり、委任署名資源レコード集合が委任された名前のために存在するか どうか証明するために使われることができます。2番目のNSEC資源レコー ドは子ゾーンにあり、そしてどの資源レコード集合が子ゾーンの頂上にある か明らかにします。SOAビットが子のNSEC資源レコードで設定され、 親のNSEC資源レコードでクリアされるので、親NSEC資源レコードと 子NSEC資源レコードは常に区別できます。委任署名資源レコード集合が 存在しないことを証明しようと試みるとき、セキュリティの認識があるリゾ ルバが親NSEC資源レコードを使わなくてはなりません(MUST)。 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. もしリゾルバが認証された委任署名資源レコード集合でリストされたアルゴ リズムのどれもサポートしないなら、リゾルバは子ゾーンへの認証パスを確 認することが可能ではないでしょう。この場合リゾルバは、署名なしである かのように、子ゾーンを扱うべきです(SHOULD)。 5.3. Authenticating an RRset with an RRSIG RR 5.3. 資源レコード署名資源レコード付きの資源レコード集合の認証 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. 検証者は資源レコード署名資源レコードと対応するDNSKEY資源レコー ドを資源レコード集合を認証する試みに使うことができます。検証者は最初 に資源レコード署名資源レコードが、資源レコード集合をカバーし、正しい 有効期間であり、正当なDNSKEY資源レコードを識別することを確かめ る検査をします。検証者は、(署名フィールドを除く)資源レコード署名資 源データにカバーする資源レコード集合の正規形式を追加することで、署名 されたデータの正規形式を組み立てます。最終的に、検証者は署名されたデー タを認証するために公開鍵と署名を使います。5.3.1章と5.3.2章と 5.3.3章がそれぞれのステップを記述します。 5.3.1. Checking the RRSIG RR Validity 5.3.1. 資源レコード署名資源レコードの正当性の検査 A security-aware resolver can use an RRSIG RR to authenticate an RRset if all of the following conditions hold: セキュリティの認識があるリゾルバは、もし次の条件のすべてを資源レコー ド署名資源レコードが満たすなら、資源レコード集合を認証に使うことがで きます: o The RRSIG RR and the RRset MUST have the same owner name and the same class. o 資源レコード署名資源レコードと資源レコード集合は同じ所有者名と同じ クラスでなければなりません(MUST)。 o The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset. o 資源レコード署名資源レコードの署名者の名前フィールドは資源レコード 集合を含んでいるゾーンの名前に違いありません(MUST)。 o The RRSIG RR's Type Covered field MUST equal the RRset's type. o 資源レコード署名資源レコードのタイプカバーフィールドは資源レコード 集合のタイプに等しくてはなりません(MUST)。 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 資源レコード集合所有者名のラベルの数は資源レコード署名資源レコード のラベルフィールドの値以上に違いありません(MUST)。 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 検証者の考ええる現在時刻は資源レコード署名資源レコードの期限フィー ルドで示された時刻以前に違いありません(MUST)。 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 検証者の考える現在時刻は資源レコード署名資源レコードの開始フィール ドで示された時刻以降に違いありません(MUST)。 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 資源レコード署名資源レコードの署名者とアルゴリズムと鍵タグフィール ドは、ゾーンの頂上のDNSKEY資源レコード集合の所有者名前とアル ゴリズムと鍵タグと一致するに違いありません(MUST)。 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資源レコードはゾーンの頂上DNSKEY資源 レコード集合に存在しているに違いなく(MUST)、そしてゾーンフラグビッ ト(DNSKEY資源データフラグビット7)が設定されていなくてはな りません(MUST)。 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資源レコードが上の状態と一致することはありえます。 この場合、検証者は前もってどのDNSKEY資源レコードを署名を認証に 使用すべきか決定できません、そして検証者は署名が検証されるか試みる公 開鍵がなくなるまで、一致するDNSKEY資源レコードで検証を試みなけ ればなりません(MUST)。 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資源レコードを認証した場合にだけ、 この認証処理が有効な事に注意してください。一致してするDNSKEY資 源レコードは以下の場合正しいと考えられます: o the apex DNSKEY RRset containing the DNSKEY RR is considered authentic; or o この頂上DNSKEY資源レコードを含むDNSKEY資源レコード集 合が本物と考えられる;あるいは 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 資源レコード署名資源レコードによってカバーされた資源レコード集合 は頂上DNSKEY資源レコード集合自身で、そしてDNSKEY資源 レコードは親ゾーンから認証された委任署名資源レコードと一致するか、 あるいは信頼固定点と一致します。 5.3.2. Reconstructing the Signed Data 5.3.2. 署名されたデータの再構築 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: 資源レコード署名資源レコードが5.3.1章で記述された正当性条件を満た したら、検証者は元の署名されたデータを再構築しなければなりません。元 の署名されたデータは(署名フィールドを除く)資源レコード署名資源デー タと、資源レコード集合の標準形式を含みます。順序を別として、資源レコー ド集合の標準形式はDNS名圧縮やTTL減算やワイルドカード拡大のため に受信した資源レコード集合と違うかもしれません。検証者は以下を元の署 名されたデータを再構築するために使うべきです: 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は、署名フィールドを除き、署名者の名前が標準形式 の資源レコード署名資源データフィールドのワイヤフォーマッ トです。 RR(i) = name | type | class | OrigTTL | RDATA length | RDATA name is calculated according to the function below nameが下記の関数に従って計算されます class is the RRset's class classは資源レコード集合のクラスです type is the RRset type and all RRs in the class typeは資源レコード集合タイプとクラスのすべての資源レコードです OrigTTL is the value from the RRSIG Original TTL field OrigTTLは資源レコード署名の元のTTLフィールドからの値です All names in the RDATA field are in canonical form 資源データフィールドのすべての名前は標準形式です The set of all RR(i) is sorted into canonical order. すべてのRR(i)の集合は標準順序に並べられます。 To calculate the name: nameを計算するために: let rrsig_labels = the value of the RRSIG Labels field rrsig_labels = 資源レコード署名ラベルフィールドの値 let fqdn = RRset's fully qualified domain name in canonical form fqdn = 資源レコード集合の標準形式の完全指定ドメイン名 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 なら、 資源レコード署名資源レコードは検査を通らず、そして この資源レコード集合を認証に使ってはなりません(MUST NOT)。 The canonical forms for names and RRsets are defined in [RFC4034]. 名前と資源レコード集合の標準形式は[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資源レコード集合は特別な処理を必要とします。署名 された委任名と結び付けられた2つの別のNSEC資源レコード集合があり ます。1番目のNSEC資源レコード集合が親ゾーンに存在して、そしてど の資源レコード集合が親ゾーンに存在しているか明示します。2番目のNS EC資源レコード集合は子ゾーンにおいて存在して、そしてどの資源レコー ド集合が子供ゾーンで頂上に存在しているかについて明らかにします。ただ 子NSEC資源レコードだけが名前にSOA資源レコード集合が存在するこ とを示すので、親NSEC資源レコード集合と子NSEC資源レコード集合 は常に区別可能です。親ゾーンの委任点の元のNSEC資源レコード集合を 再構築するとき、NSEC資源レコードと子ゾーンのNSEC資源レコード とを組み合わせてはなりません(MUST NOT)。子ゾーンの頂上の元のNSEC 資源レコード集合を再構築するとき、NSEC資源レコードと親ゾーンのN SEC資源レコードとを組み合わせてはなりません(MUST NOT)。 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資源レコード集合のそれぞれが委任名に一致する所 有者名の資源レコード署名資源レコードを持ち、そしてこれらの資源レコー ド署名資源レコードのそれぞれが対応するNSEC資源レコード集合を含む ゾーンと結び付けられる正式なデータであることに注意してください。もし 必要なら、署名者の名前フィールドをチェックすることによって、リゾルバ がこれらの資源レコード署名資源レコードを区別することができます。 5.3.3. Checking the Signature 5.3.3. 署名検査 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章で記述されるように資源レコード署名資源レコードを 検証し、5.3.2章で記述されるように元の署名されたデータを再構築した ら、検証者は署名されたデータの認証に暗号署名を使用し、そして(最終的 に!)資源レコード集合を認証する試みができます。 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. 資源レコード署名資源レコードのアルゴリズムフィールドは署名を生成する ために使われた暗号のアルゴリズムを識別します。署名自身は資源レコード 署名資源データの署名フィールドに含まれます、そして署名を確認するため に使われる公開鍵は対応するDNSKEY資源レコードの公開鍵フィールド に含まれます(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資源レコードが5.3.1章の状態と一致することが可能 であることに注意してください。この場合、検証者が署名の検証に成功する か、試みるべき鍵を使い果たすまで、それぞれの一致する公開鍵をで検証を 試めすことによってのみ、DNSKEY資源レコードを正しいと決定でます。 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. もし資源レコード署名資源レコードのラベルフィールドが資源レコード集合 の完全指定所有者名のラベルの数と等しくないなら、資源レコード集合は無 効であるかワイルドカード拡大の結果です。資源レコード集合を正しいと考 える前に、リゾルバはワイルドカード拡大が適切に適用されたことを確かめ なくてはなりません(MUST)。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. もし他の資源レコード署名資源レコードが同じくこの資源レコード集合をカ バーするなら、ローカルなリゾルバセキュリティポリシは、リゾルバがこれ らの資源レコード署名資源レコードも検査しなければならないかどうか、も しこれらの資源レコード署名資源レコードが異なる結果を導くなら、どのよ うに矛盾を解決するべきかを決定します。 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: もしリゾルバが資源レコード集合を認証するなら、検証者は資源レコード署 名資源レコードと認証された資源レコード集合のTTLを以下のどれよりも 小さい値に設定します(MUST): o the RRset's TTL as received in the response; o 応答で受信した資源レコード集合のTTL; o the RRSIG RR's TTL as received in the response; o 応答で受信した資源レコード署名資源レコードのTTL; o the value in the RRSIG RR's Original TTL field; and o 資源レコード署名資源レコードの元のTTLフィールドの値;そして o the difference of the RRSIG RR's Signature Expiration time and the current time. o 資源レコード署名資源レコードの署名期限時刻と現在の時刻の差。 5.3.4. Authenticating a Wildcard Expanded RRset Positive Response 5.3.4.ワイルドカード拡張肯定応答の認証 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. もし資源レコード集合の所有者名のラベルの数がそれをカバーする資源レコー ド署名資源レコードのラベルフィールドより大きいなら、資源レコード集合 とそれをカバーする資源レコード署名資源レコードはワイルドカード拡大の 結果として作られました。検証者が署名を実証したら、5.3章で記述される ように、問合せに正確に一致するかより近いワイルドカード一致が非実在で ある事を確認する追加手順をとらなくてはなりません。5.4章がこれらの手 順を論じます。 Note that the response received by the resolver should include all NSEC RRs needed to authenticate the response (see Section 3.1.3). リゾルバが受信した応答に、応答を認証するのに必要なすべてのNSEC資 源レコードが含まれるべきことに注意してください(3.1.3章参照)。 5.4. Authenticated Denial of Existence 5.4. 非存在認証 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資源レコードを資源レコード集合が署名され たゾーンに存在していないことを証明するために使うことができます。セキュ リティの認識のあるネームサーバは、自動的に署名されたゾーンで、セキュ リティの認識があるリゾルバに対する応答に、必要なNSEC資源レコード を含めるべきです。 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 もし求められた資源レコード名が認証されたNSEC資源レコードの所有 者名と一致するなら、NSEC資源レコードのタイプビットマップフィー ルドはその所有者名で存在しているすべての資源レコードタイプをリスト します、そしてリゾルバはビットマップの資源レコードタイプを調べて、 求められた資源レコードタイプが存在しないことを証明できます。もし認 証されたNSEC資源レコードの所有者名のラベルの数がカバーする資源 レコード署名資源レコードのラベルフィールドと等しいなら、NSEC資 源レコードの存在は、要求と一致させるためにワイルドカード拡大が使わ れていないことを証明します。 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 もし、要求した資源レコードの所有者名が、[RFC4034]で定義された正規 DNS順で、認証されたNSEC資源レコードの所有者名より後で、その NSEC資源レコードの次のドメイン名フィールドより前ならば、求めら れた名前を持つ資源レコード集合がゾーンに存在しません。しかしながら、 求められた資源レコード所有者名とタイプに一致するためにワイルドカー ドが使われることが可能で、それで求められた資源レコード集合が存在し ない事の証明には、肯定的な応答を生成するために使うことができる資源 レコード集合も存在しない事を証明する必要があります。 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資源レコード集合を認証しなくてはなりま せん(MUST)。 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. 資源レコード集合の非実在を証明するために、リゾルバは共に質問された資 源レコード集合が存在しない事と、適切なワイルドカード資源レコード集合 が存在しないことを確かめることができなければなりません。これを証明す るにはゾーンの複数のNSEC資源レコード集合を必要とするかもしれませ ん。もし必要なNSEC資源レコード集合の完全な集合が応答に存在してい ないなら(多分メッセージ切り詰めで)、セキュリティの認識のあるリゾル バは、求めた資源レコード集合の非実在を確認するために必要なNSEC資 源レコードを得るために、再度質問をしなくてはなりません(MUST)。しかし ながら、すべての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資源レコードがそれ自身とその対応する資源レコード署 名資源レコード両方の存在を証明しますから、検証者はNSEC資源レコー ドのNSECビットと資源レコード署名ビットの設定を無視しなくてはなり ません(MUST)。 5.5. Resolver Behavior When Signatures Do Not Validate 5.5. 署名無効時のリゾルバ行動 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. もし理由が何であれどの資源レコード署名も有効でないならば、応答は悪い と思われるべきです(SHOULD)。もし検証が再帰問合せサービスを提供するた めにされていたなら、ネームサーバは出発点のクライアントにRCODE2 を返さなくてはなりません(MUST)。しかしながら、もし元の質問のCDビッ トが設定されているならば、そしてこの場合には必ず、完全な応答を返さな くてはなりません(MUST)。検証されない応答のキャッシュについて、4.7 章も見てください。 5.6. Authentication Example 5.6. 認証例 Appendix C shows an example of the authentication process. 付録Cが認証過程の例を示します。 6. IANA Considerations 6. IANA考慮 [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ビッ トを予約し、その用途を定義しました。使用法はこの文書で再び述べられま すが、変えられません。 7. Security Considerations 7. セキュリティの考察 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 資源レコードセットを署名し認証するか記述します。どうか専門用語とDN SSECと関係がある一般的なセキュリティー考慮のために[RFC4033]を見 てください;DNSSEC資源レコードタイプに特定の考慮のために [RFC4034]を見てください。 An active attacker who can set the CD bit in a DNS query message or the AD bit in a DNS response message can use these bits to defeat the protection that DNSSEC attempts to provide to security-oblivious recursive-mode resolvers. For this reason, use of these control bits by a security-aware recursive-mode resolver requires a secure channel. See Sections 3.2.2 and 4.9 for further discussion. DNSの問合せメッセージのCDビットあるいはDNS応答メッセージのA Dビットを設定することができるアクティブな攻撃者が、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が スタブリゾルバに提供する能力は不適当であるかもしれません。セキュリティ の認識がある再帰ネームサーバのオペレータが近い、ローカル検証ポリシを 選択するとき、それらのサービスを使うアプリケーションの行動に深い注意 を払わなければならないでしょう;そうしなければ容易に、クライアントが 期待するサービスを、再帰ネームサーバが否定する結果になるでしょう。 8. Acknowledgements 8. 受取りの通知 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拡張作業班と作業班メーリングリストのメンバのインプッ トと考えから作成されました。編集者はこれらのセキュリティ拡張仕様の修 正の間に受け取ったコメントと提案に対し感謝をします。明示的にDNSS EC開発下の10年間に貢献した全員をリストすることは不可能ですが、 [RFC4033]が親切にもこれらの文書についてコメントしてくださった参与者の あるリストを含みます。 9. References 9. 参考文献 9.1. Normative References 9.1. 参照する参考文献 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for DNS Security Extensions", RFC 4034, March 2005. 9.2. Informative References 9.2. 有益な参考文献 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003. Appendix A. Signed Zone Example 付録A 署名されたゾーンの例 The following example shows a (small) complete signed zone. 次の例は(小さい)完全な署名されたゾーンを示します。 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) 3600 NS ns1.example. 3600 NS ns2.example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 20040409183619 38519 example. gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) 3600 MX 1 xx.example. 3600 RRSIG MX 5 1 3600 20040509183619 ( 20040409183619 38519 example. HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM W6OISukd1EQt7a0kygkg+PEDxdI= ) 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 20040409183619 38519 example. O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U= ) 3600 DNSKEY 256 3 5 ( AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== ) 3600 DNSKEY 257 3 5 ( AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== ) 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 20040409183619 9465 example. ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 20040409183619 38519 example. eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk 7z5OXogYVaFzHKillDt3HRxHIZM= ) a.example. 3600 IN NS ns1.a.example. 3600 IN NS ns2.a.example. 3600 DS 57855 5 1 ( B6DCD485719ADCA18E5F3D48A2331627FDD3 636B ) 3600 RRSIG DS 5 2 3600 20040509183619 ( 20040409183619 38519 example. oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) 3600 NSEC ai.example. NS DS RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) ns1.a.example. 3600 IN A 192.0.2.5 ns2.a.example. 3600 IN A 192.0.2.6 ai.example. 3600 IN A 192.0.2.9 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. 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= ) The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA Flags indicate that each of these DNSKEY RRs is a zone key. One of these DNSKEY RRs also has the SEP flag set and has been used to sign the apex DNSKEY RRset; this is the key that should be hashed to generate a DS record to be inserted into the parent zone. The other DNSKEY is used to sign all the other RRsets in the zone. 頂上DNSKEY集合は2つのDNSKEY資源レコードを含み、DNSK EY資源データフラグはこれらのDNSKEY資源レコードのそれぞれがゾー ンの鍵であることを示します。これらのDNSKEY資源レコードの1つは SEPフラグが設定され、頂上DNSKEY資源レコード集合を署名するた めに使われました;これは親ゾーンに挿入される委任署名レコードを生成す るためにハッシュされるべき鍵です。他のDNSKEYはゾーンのすべての 他の資源レコード集合を署名するために使われます。 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資源レコード集 合をカバーする資源レコード署名はラベル数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資源レコー ド集合と、接着アドレスレコードとNSEC資源レコードを含みます;NS EC資源レコード集合だけが署名されることに注意してください。"a.example" への委任は委任署名資源レコードを提供します;ただNSECと委任署名資 源レコード集合だけが署名されることに注意してください。 Appendix B. Example Responses 付録B 回答例 The examples in this section show response messages using the signed zone example in Appendix A. この章の例は付録A.で署名されたゾーンを使う応答メッセージ例を示します。 B.1. Answer B.1. 解答 A successful query to an authoritative server. 正式なサーバへの成功した質問。 ;; Header: QR AA DO RCODE=0 ;; ;; Question x.w.example. IN MX ;; 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= ) ;; 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= ) ;; 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= ) B.2. Name Error B.2. 名前エラー An authoritative name error. The NSEC RRs prove that the name does not exist and that no covering wildcard exists. 正式な名前エラー。NSEC資源レコードは名前が存在せず、そしてカバー ワイルドカードが存在しないことを証明します。 ;; 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= ) ;; Additional ;; (empty) B.3. No Data Error B.3. データなしエラー A "no data" response. The NSEC RR proves that the name exists and that the requested RR type does not. 「データなし」応答。NSEC資源レコードは名前が存在するが、求められ た資源レコードタイプが存在しないことを証明します。 ;; 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= ) ;; Additional ;; (empty) B.4. Referral to Signed Zone B.4. 署名されたゾーンへの照会 Referral to a signed zone. The DS RR contains the data which the resolver will need to validate the corresponding DNSKEY RR in the child zone's apex. 署名されたゾーンへの照会。委任署名資源レコードは、リゾルバが子供ゾー ンの頂上の対応するDNSKEY資源レコードを検証するために必要であろ うデータを含みます。 ;; Header: QR DO RCODE=0 ;; ;; Question mc.a.example. IN 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= ) ;; Additional ns1.a.example. 3600 IN A 192.0.2.5 ns2.a.example. 3600 IN A 192.0.2.6 B.5. Referral to Unsigned Zone B.5. 署名されていないゾーンへの照会 Referral to an unsigned zone. The NSEC RR proves that no DS RR for this delegation exists in the parent zone. 署名されていないゾーンへの照会。NSEC資源レコードはこの委任のため の委任署名資源レコードが親ゾーンに存在しないことを証明します。 ;; 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= ) ;; Additional ns1.b.example. 3600 IN A 192.0.2.7 ns2.b.example. 3600 IN A 192.0.2.8 B.6. Wildcard Expansion B.6. ワイルドカード拡大 A successful query that was answered via wildcard expansion. The label count in the answer's RRSIG RR indicates that a wildcard RRset was expanded to produce this response, and the NSEC RR proves that no closer match exists in the zone. ワイルドカード拡大によって答えられた成功した問合せ。答えの資源レコー ド署名資源レコードのラベルカウントはワイルドカード資源レコード集合が この応答を作り出すために拡大されたことを示します、そしてNSEC資源 レコードはより一致するデータがゾーンに存在しないことを証明します。 ;; 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= ) ;; 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= ) ;; Additional ai.example. 3600 IN A 192.0.2.9 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) ai.example. 3600 AAAA 2001:db8::f00:baa9 ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 sZM6QjBBLmukH30+w1z3h8PUP2o= ) B.7. Wildcard No Data Error B.7. ワイルドカードデータなしエラー A "no data" response for a name covered by a wildcard. The NSEC RRs prove that the matching wildcard name does not have any RRs of the requested type and that no closer match exists in the zone. ワイルドカードによってカバーされた名前の「データなし」応答。NSEC 資源レコードは一致するワイルドカード名が求められたタイプの資源レコー ドを持たず、そしてより一致するデータがゾーンに存在しないことを示します。 ;; 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= ) ;; Additional ;; (empty) B.8. DS Child Zone No Data Error B.8. 委任署名子ゾーンデータなしエラー 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= ) ;; Additional ;; (empty) Appendix C. Authentication Examples 付録C. 認証例 The examples in this section show how the response messages in Appendix B are authenticated. この章の例は付録Bの応答メッセージがどのように認証されるか示します。 C.1. Authenticating an Answer C.1. 応答認証 The query in Appendix B.1 returned an MX RRset for "x.w.example.com". The corresponding RRSIG indicates that the MX RRset was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. The resolver needs the corresponding DNSKEY RR in order to authenticate this answer. The discussion below describes how a resolver might obtain this DNSKEY RR. 付録B.1の質問は"x.w.example.com"のMX資源レコード集合を返しました。 対応する資源レコード署名はMX資源レコード集合がアルゴリズム5と鍵タ グ38519の"example"DNSKEYによって署名されたことを示します。 リゾルバはこの応答を認証するために対応するDNSKEY資源レコードを 必要とします。下の議論はリゾルバがどのようにこのDNSKEY資源レコー ドを得るかを記述します。 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. 資源レコード署名はMX資源レコード集合の元のTTLが3600であった ことを示し、そして、認証のため現在のTTLは3600で置き換えられま す。資源レコード署名ラベルフィールド値の3は解答がワイルドカード拡大 の結果ではなかったことを示します。"x.w.example.com"MX資源レコード 集合は標準形式にされ、そして現在の時間は署名開始時刻と有効期限の間に あると仮定すると、署名は認証されます。 C.1.1. Authenticating the Example DNSKEY RR C.1.1. 例DNSKEY資源レコード認証 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(あるいは委任署名資源レコード) から開始し、木を下にたどり、目的の"example"DNSKEY資源レコードを 認証する論理的な認証過程を示します。明快さのために論理的な順序が提示 されることに注意してください。実装は参照を受信したときに認証を構築す る事も、全ての資源レコード集合が得られてから認証鎖を作ることも、それ らを組み合わせる事もできます。ここの例はただ論理的な過程だけを説明し、 そして実装規則を規定しません。 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資源レコー ド(あるいはルートゾーンのための設定された委任署名資源レコード)から 出発すると想定します。リゾルバは設定されたDNSKEY資源レコードが ルートDNSKEY資源レコード集合に存在しているか(あるいは委任署名 資源レコードがルートDNSKEY資源レコード集合のいずれかのDNSK EYと一致する)と、このDNSKEY資源レコードがルートDNSKEY 資源レコード集合を署名したかどかと、署名寿命が有効であるかどうか調べ ます。もしこれらすべての条件が満たされるなら、DNSKEY資源レコー ド集合のすべての鍵は認証されたと考えられます。ここでリゾルバはルート DNSKEY資源レコードを"example"委任署名資源レコード集合を認証する ために使います。ルートDNSKEY資源レコード集合あるいは"example"委 任署名資源レコード集合を得るためにリゾルバがルートゾーンに問い合わせ なければならないかもしれないことに注意してください。 Once the DS RRset has been authenticated using the root DNSKEY, the resolver checks the "example" DNSKEY RRset for some "example" DNSKEY RR that matches one of the authenticated "example" DS RRs. If such a matching "example" DNSKEY is found, the resolver checks whether this DNSKEY RR has signed the "example" DNSKEY RRset and the signature lifetime is valid. If these conditions are met, all keys in the "example" DNSKEY RRset are considered authenticated. 委任署名資源レコード集合がルートDNSKEYを使って認証されたら、リ ゾルバは認証された"example"委任署名資源レコードのいずれかに一致する "example"DNSKEY資源レコードがないかどうか、"example"DNSKE Y資源レコード集合を検査します。もし"example"DNSKEYと一致する 物が見つかれば、リゾルバはこのDNSKEY資源レコードが"example"D NSKEY資源レコード集合を署名したかどうかと、署名寿命が有効である かどうかを調べます。もしこれらの条件が満たされるなら、"example"DN SKEY資源レコード集合のすべての鍵は認証されたと考えられます。 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. 最終的に、リゾルバは"example"DNSKEY資源レコード集合のいずれか のDNSKEY資源レコードがアルゴリズム5を使い38519の鍵タグ を持っているかを調べます。このDNSKEYは応答で含まれている資源 レコード署名を認証するために使われます。もし多数の"example"DNSK EY資源レコードがこのアルゴリズムと鍵タグに一致するなら、それぞれ のDNSKEY資源レコードが試され、そしてもし似合っているDNSK EY資源レコードのどれかが上記の署名を有効にするなら、応答は認証さ れます。 C.2. Name Error C.2. 名前エラー The query in Appendix B.2 returned NSEC RRs that prove that the requested data does not exist and no wildcard applies. The negative reply is authenticated by verifying both NSEC RRs. The NSEC RRs are authenticated in a manner identical to that of the MX RRset discussed above. 付録B.2の問合せはNSEC資源レコードを返し、これは求められたデー タが存在せずワイルドカードが適用されない事を証明します。両方のNS EC資源レコードを確認することによって、否定応答は認証されます。N SEC資源レコードは上記のMX資源レコード集合とまったく同じの方法 で認証されます。 C.3. No Data Error C.3. データなしエラー The query in Appendix B.3 returned an NSEC RR that proves that the requested name exists, but the requested RR type does not exist. The negative reply is authenticated by verifying the NSEC RR. The NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above. 付録B.3の質問は求められた名前が存在することを証明するNSEC資源 レコードを返しました、しかし求められた資源レコードタイプは存在しませ ん。NSEC資源レコードを確認することによって、否定応答は認証されま す。NSEC資源レコードは上で論じたMX資源レコード集合とまったく同 じの方法で認証されます。 C.4. Referral to Signed Zone C.4. 署名されたゾーンの参照 The query in Appendix B.4 returned a referral to the signed "a.example." zone. The DS RR is authenticated in a manner identical to that of the MX RRset discussed above. This DS RR is used to authenticate the "a.example" DNSKEY RRset. 付録B.4の質問は署名された"a.example."ゾーンの参照を返しました。委任 署名資源レコードは上で論じたMX資源レコード集合とまったく同じの方法 で認証されます。この委任署名資源レコードは"a.example"DNSKEY資源 レコード集合を認証するために使われます。 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"委任署名資源レコード集合が"example"DNSKEYを使って認証され たら、リゾルバは委任署名資源レコードと一致するある"a.example"DNSK EY資源レコードがないか"a.example"DNSKEY資源レコード集合を検査 します。もしこのような一致する"a.example"DNSKEYが見つかるなら、 リゾルバはこのDNSKEY資源レコードが"a.example"DNSKEY資源レ コード集合を署名したかどうか、そして署名寿命が有効であるかどうか調べ ます。もしこれらすべての条件が満たされるなら"a.example"DNSKEY資 源レコード集合のすべての鍵は認証されたと考えられます。 C.5. Referral to Unsigned Zone C.5. 署名されていないゾーンの参照 The query in Appendix B.5 returned a referral to an unsigned "b.example." zone. The NSEC proves that no authentication leads from "example" to "b.example", and the NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above. 付録B.5の質問は無署名の"b.example."ゾーンの参照を返しました。NSE Cは"example"から"b.example"への認証がないことを証明します、そしてN SEC資源レコードは上で論じたMX資源レコード集合とまったく同じの方 法で認証されます。 C.6. Wildcard Expansion C.6. ワイルドカード拡大 The query in Appendix B.6 returned an answer that was produced as a result of wildcard expansion. The answer section contains a wildcard RRset expanded as it would be in a traditional DNS response, and the corresponding RRSIG indicates that the expanded wildcard MX RRset was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG indicates that the original TTL of the MX RRset was 3600, and, for the purpose of authentication, the current TTL is replaced by 3600. The RRSIG labels field value of 2 indicates that the answer is the result of wildcard expansion, as the "a.z.w.example" name contains 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset is placed in canonical form, and, assuming that the current time falls between the signature inception and expiration dates, the signature is authenticated. 付録B.6の問合せはワイルドカード拡大の結果として作り出された応答を返 しました。解答部は伝統的なDNS応答と同じく拡大したワイルドカード資 源レコード集合を含んでいます、そして対応する資源レコード署名は拡張さ れたワイルドカードMX資源レコード集合がアルゴリズム5と鍵タグ385 19の"example"DNSKEYによって署名されたことを示します。資源レコー ド署名はMX資源レコード集合の元のTTLが3600であったことを示し、 そして認証のために現在のTTLは3600で置き換えられます。 "a.z.w.example"名が4つのラベルを含むので、資源レコード署名のラベル フィールドの2の値は応答がワイルドカード拡大の結果であることを示しま す。名前"a.z.w.w.example"は"*.w.example"で置き換えられ、MX資源レコー ド集合は正規形式とされ、現在の時刻が署名開始時刻と有効期限の間にあれ ば、署名が認証されます。 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資源レコードも認証されなくてはなりません。 C.7. Wildcard No Data Error C.7. ワイルドカードデータなしエラー The query in Appendix B.7 returned NSEC RRs that prove that the requested data does not exist and no wildcard applies. The negative reply is authenticated by verifying both NSEC RRs. 付録B.7の問合せは求められたデータが存在せず、そしてワイルドカードが 適用されないことを証明する、NSEC資源レコードを返しますです。両方 のNSEC資源レコードを確認することによって、否定的な返答は認証され ます。 C.8. DS Child Zone No Data Error C.8. 委任署名子ゾーンデータなしエラー 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の問合せは、問い合わせが子サーバ("example"サーバ)によって 答えられたことを示すNSEC資源レコードを返します。NSEC資源レコー ドは、応答が子からであることを示すSOA資源レコードの存在を示します。 "example"委任署名資源レコード集合の問い合わせは、親サーバ(「ルート」 サーバ)が送られるべきす。 Authors' Addresses 著者のアドレス 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 EMail: sra@isc.org 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 EMail: massey@cs.colostate.edu Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA EMail: scott.rose@nist.gov Full Copyright Statement 著作権表示全文 Copyright (C) The Internet Society (2005). 著作権(C)インターネット学会(2005)。 This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして この中に明らかにされる以外は著者がすべての権利を維持します。 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文書の権利に関する手続 きの情報はBCP78とBCP79を見てください。 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エディタ機能のための資金供給が現在インターネット学会によって 供給されます。