RFC4035 日本語訳
4035 Protocol Modifications for the DNS Security Extensions. R.Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=130589 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Updated by RFC4470) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Arendsがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4035Telematica Instituutは以下を時代遅れにします。 2535、3008、3090、3445、3655、3658、Austein3755、3757、3845ISCがアップデートするR.: 1034 1035 2136 2181 2308 3225 M.ラーソン3007、3597、3226ベリサインCategory: 標準化過程D.マッシーコロラド州立大学S.は2005年のNIST行進のときに上昇しました。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.
このドキュメントはDNS Security Extensions(DNSSEC)について説明するドキュメントの家族の一部です。 DNS Security Extensionsはデータ起源認証とデータ保全をDNSに加える新しいリソース記録とプロトコル変更の収集です。 このドキュメントはDNSSECプロトコル変更について説明します。 このドキュメントは給仕のための要件とDNSSECを使用するのによる決議と共にサインされたゾーンの概念を定義します。 これらのテクニックで、セキュリティ意識しているレゾルバはDNSリソース記録と正式のDNS誤り指摘の両方を認証できます。
This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.
このドキュメントは、RFC2535を時代遅れにして、すべてのアップデートからRFC2535までの変化を取り入れます。
Arends, et al. Standards Track [Page 1] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[1ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Related Documents . . . . . . . . . . . . 4
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4
2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5
2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5
2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6
2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7
2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7
2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8
2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9
3.1.1. Including RRSIG RRs in a Response . . . . . . . 10
3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11
3.1.3. Including NSEC RRs in a Response . . . . . . . . 11
3.1.4. Including DS RRs in a Response . . . . . . . . . 14
3.1.5. Responding to Queries for Type AXFR or IXFR . . 15
3.1.6. The AD and CD Bits in an Authoritative Response. 16
3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17
3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17
3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17
3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18
3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Signature Verification Support . . . . . . . . . . . . . 19
4.3. Determining Security Status of Data . . . . . . . . . . 20
4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21
4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21
4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22
4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24
4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24
4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
5.1. Special Considerations for Islands of Security . . . . . 26
5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26
5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28
5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28
5.3.2. Reconstructing the Signed Data . . . . . . . . . 29
5.3.3. Checking the Signature . . . . . . . . . . . . . 31
5.3.4. Authenticating a Wildcard Expanded RRset
Positive Response. . . . . . . . . . . . . . . . 32
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 バックグラウンドと関連ドキュメント. . . . . . . . . . . . 4 1.2。 リザーブドワード. . . . . . . . . . . . . . . . . . . . . 4 2。 ゾーン調印. . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1。 ゾーン. . . . . . . . . . . . . 5 2.2にDNSKEY RRsを含んでいます。 ゾーン. . . . . . . . . . . . . 5 2.3にRRSIG RRsを含んでいます。 ゾーン. . . . . . . . . . . . . . 6 2.4にnsec RRsを含んでいます。 ゾーン. . . . . . . . . . . . . . . 7 2.5にDS RRsを含んでいます。 CNAMEリソースへの変化は記録します。 . . . . . . . . . 7 2.6. DNSSEC RRはゾーンカットのときに排臨をタイプします。 . . . . . . . . 8 2.7. 安全なゾーン. . . . . . . . . . . . . . . . 8 3に関する例。 .83.1に役立ちます。 正式のネームサーバ. . . . . . . . . . . . . . . 9 3.1.1。 応答. . . . . . . 10 3.1.2にRRSIG RRsを含んでいます。 応答. . . . . . . 11 3.1.3にDNSKEY RRsを含んでいます。 応答. . . . . . . . 11 3.1.4にnsec RRsを含んでいます。 応答. . . . . . . . . 14 3.1.5にDS RRsを含んでいます。 タイプAXFRかIXFR. . 15 3.1.6のための質問に応じます。 正式の応答におけるADとCDビット。 16 3.2. 再帰的なネームサーバ. . . . . . . . . . . . . . . . . 17 3.2.1。 .2にビット. . . . . . . . . . . . . . . . . . . 17 3.2をしてください。 CDビット. . . . . . . . . . . . . . . . . . . 17 3.2.3。 ADビット. . . . . . . . . . . . . . . . . . . 18 3.3。 例のDNSSEC応答. . . . . . . . . . . . . . . . 19 4。 .194.1を決議します。 EDNSは.194.2を支持します。 署名照合サポート. . . . . . . . . . . . . 19 4.3。 データ. . . . . . . . . . 20 4.4のセキュリティ状態を決定します。 構成された信用は.214.5を据えつけます。 応答キャッシュ. . . . . . . . . . . . . . . . . . . . 21 4.6。 CDとADビット. . . . . . . . . . . . . 22 4.7の取り扱い。 悪いデータ. . . . . . . . . . . . . . . . . . . . 22 4.8をキャッシュします。 CNAMEs. . . . . . . . . . . . . . . . . . . 23 4.9を統合しました。 レゾルバ. . . . . . . . . . . . . . . . . . . . . 23 4.9.1を引き抜いてください。 取り扱い、.2にビット. . . . . . . . . . . . . 24 4.9をしてください。 CDビット. . . . . . . . . . . . . 24 4.9.3の取り扱い。 ADの取り扱いは.245に噛み付きました。 DNS応答. . . . . . . . . . . . . . . . . 25 5.1を認証します。 セキュリティ. . . . . 26 5.2の諸島に、特別な問題。 紹介. . . . . . . . . . . . . . . . 26 5.3を認証します。 RRSIG RR. . . . . . . . 28 5.3.1があるRRsetを認証します。 RRSIG RRの正当性. . . . . . . . . 28 5.3.2をチェックします。 サインされたデータ. . . . . . . . . 29 5.3.3を再建します。 署名. . . . . . . . . . . . . 31 5.3.4をチェックします。 ワイルドカードを認証すると、RRsetの積極的な応答は広がりました。 . . . . . . . . . . . . . . . 32
Arends, et al. Standards Track [Page 2] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[2ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
5.4. Authenticated Denial of Existence . . . . . . . . . . . 32
5.5. Resolver Behavior When Signatures Do Not Validate . . . 33
5.6. Authentication Example . . . . . . . . . . . . . . . . . 33
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 35
A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36
B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41
B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44
B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44
B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45
B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48
C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49
C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49
C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49
C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50
C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50
C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51
C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
5.4. 存在. . . . . . . . . . . 32 5.5の否定を認証しました。 署名が.335.6を有効にしないときのレゾルバの振舞い。 認証の例. . . . . . . . . . . . . . . . . 33 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 33 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 33 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 34 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1。 引用規格. . . . . . . . . . . . . . . . . . 34 9.2。 有益な参照. . . . . . . . . . . . . . . . . 35A.はゾーンの例. . . . . . . . . . . . . . . . . . . . . 36のB.例の応答. . . . . . . . . . . . . . . . . . . . . . 41B.1にサインしました。 .41B.2に答えてください。 誤り. . . . . . . . . . . . . . . . . . . . . . . 43をB.3と命名してください。 いいえ、データ誤り. . . . . . . . . . . . . . . . . . . . . 44B.4。 サインされたゾーン.44B.5への紹介。 無記名のゾーン.45B.6への紹介。 ワイルドカード拡大. . . . . . . . . . . . . . . . . . . 46B.7。 ワイルドカードいいえデータ誤り. . . . . . . . . . . . . . . . . 47B.8。 DS子供ゾーンいいえデータ誤り. . . . . . . . . . . . . . 48C.認証の例. . . . . . . . . . . . . . . . . . . 49のC.1。 答え. . . . . . . . . . . . . . . . 49C.1.1を認証します。 例のDNSKEY RR. . . . . . 49C.2を認証します。 誤り. . . . . . . . . . . . . . . . . . . . . . . 50をC.3と命名してください。 いいえ、データ誤り. . . . . . . . . . . . . . . . . . . . . 50C.4。 サインされたゾーン.50C.5への紹介。 無記名のゾーン.51C.6への紹介。 ワイルドカード拡大. . . . . . . . . . . . . . . . . . . 51C.7。 ワイルドカードいいえデータ誤り. . . . . . . . . . . . . . . . . 51C.8。 DS子供ゾーンいいえデータ誤り. . . . . . . . . . . . . . 51作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 52の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 53
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 Security Extensions(DNSSEC)はデータ起源認証とデータ保全をDNSに加える新しいリソース記録とプロトコル変更の収集です。 このドキュメントはDNSSECプロトコル変更を定義します。 このドキュメントのセクション2は、サインされたゾーンの概念を定義して、ゾーン調印のための要件をリストアップします。 セクション3はサインされたゾーンを扱うのに必要な正式のネームサーバの振舞いに変更を説明します。 セクション4はセキュリティ意識しているレゾルバ機能を含んでいる実体の振舞いについて説明します。 最終的に、セクション5は応答を認証するのにDNSSEC RRsを使用する方法を定義します。
Arends, et al. Standards Track [Page 3] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[3ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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 Public Key(DNSKEY)、Resource Record Signature(RRSIG)、Next Secure(NSEC)、および(任意に)代表団Signer(DS)記録を含んでいます。 このセクションの規則に従ってこれらの記録を含んでいないゾーンは無記名のゾーンです。
DNSSEC requires a change to the definition of the CNAME resource record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs to appear at the same owner name as does a CNAME RR.
DNSSECはCNAMEリソース記録([RFC1035])の定義への変化を必要とします。 セクション2.5は、RRSIGとNSEC RRsがCNAME RRのように同じ所有者名で見えるのを許容するためにCNAME RRを変えます。
DNSSEC specifies the placement of two new RR types, NSEC and DS, which can be placed at the parental side of a zone cut (that is, at a delegation point). This is an exception to the general prohibition against putting data in the parent zone at a zone cut. Section 2.6 describes this change.
DNSSECは2新しいRRタイプ、NSEC、およびDSのプレースメントを指定します。(ゾーンカット(すなわち、代表団ポイントの)親側にDSを置くことができます)。 これはゾーンカットのときに親ゾーンにデータを置くことに対する一般的な禁止への例外です。 セクション2.6はこの変化について説明します。
Arends, et al. Standards Track [Page 4] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[4ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
2.1. Including DNSKEY RRs in a Zone
2.1. ゾーンにDNSKEY RRsを含んでいます。
To sign a zone, the zone's administrator generates one or more public/private key pairs and uses the private key(s) to sign authoritative RRsets in the zone. For each private key used to create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR containing the corresponding public key. A zone key DNSKEY RR MUST have the Zone Key bit of the flags RDATA field set (see Section 2.1.1 of [RFC4034]). Public keys associated with other DNS operations MAY be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT be used to verify RRSIGs.
ゾーンにサインするなら、ゾーンの管理者は、1公衆/秘密鍵組以上を発生させて、ゾーンで正式のRRsetsにサインするのに秘密鍵を使用します。 ゾーンでRRSIG RRsを作成するのに使用される各秘密鍵のために、ゾーンSHOULDは対応する公開鍵を含むゾーンDNSKEY RRを含んでいます。 ゾーン主要なDNSKEY RR MUSTには、RDATA分野が設定した旗のZone Keyビットがあります(.1セクション2.1[RFC4034]を見てください)。 他のDNS操作に関連している公開鍵を、ゾーンキーとしてマークされないDNSKEY RRsに格納されるかもしれませんが、RRSIGsについて確かめるのに使用してはいけません。
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]).
ゾーンの管理者が、セキュリティの島を除いて、サインされたゾーンが使用可能であることを意図するなら、ゾーンの頂点は、安全なエントリー・ポイントとしてゾーンに機能するように少なくとも1DNSKEY RRを含まなければなりません。 そして、安全な代表団の目標として親ゾーンの対応するDS RRを通してこの安全なエントリー・ポイントを使用できました([RFC4034]を見てください)。
2.2. Including RRSIG RRs in a Zone
2.2. ゾーンにRRSIG RRsを含んでいます。
For each authoritative RRset in a signed zone, there MUST be at least one RRSIG record that meets the following requirements:
サインされたゾーンのそれぞれの正式のRRsetのために、以下の必要条件を満たす少なくとも1つのRRSIG記録があるに違いありません:
o The RRSIG owner name is equal to the RRset owner name.
o RRSIG所有者名はRRset所有者名と等しいです。
o The RRSIG class is equal to the RRset class.
o RRSIGのクラスはRRsetのクラスと等しいです。
o The RRSIG Type Covered field is equal to the RRset type.
o RRSIG Type Covered分野はRRsetタイプと等しいです。
o The RRSIG Original TTL field is equal to the TTL of the RRset.
o RRSIG Original TTL分野はRRsetのTTLと等しいです。
o The RRSIG RR's TTL is equal to the TTL of the RRset.
o RRSIG RRのTTLはRRsetのTTLと等しいです。
o The RRSIG Labels field is equal to the number of labels in the
RRset owner name, not counting the null root label and not
counting the leftmost label if it is a wildcard.
o RRSIG Labels分野はRRset所有者名のラベルの数と等しいです、ヌル根のラベルを数えないで、またそれがワイルドカードであるなら一番左ラベルを数えないで。
o The RRSIG Signer's Name field is equal to the name of the zone
containing the RRset.
o RRSIG SignerのName分野はRRsetを含むゾーンの名前と等しいです。
o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
zone key DNSKEY record at the zone apex.
o RRSIG Algorithm、SignerのName、およびKey Tag分野はゾーンの頂点でゾーンの主要なDNSKEY記録を特定します。
The process for constructing the RRSIG RR for a given RRset is described in [RFC4034]. An RRset MAY have multiple RRSIG RRs associated with it. Note that as RRSIG RRs are closely tied to the RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
与えられたRRsetのためにRRSIG RRを組み立てるための過程は[RFC4034]で説明されます。 RRsetには、それに関連している複数のRRSIG RRsがあるかもしれません。 RRSIG RRsが密接にそれらが署名を含むRRsetsに結ばれるとき、それに注意してください、RRSIG RRs、他のすべてのDNSと異なって
Arends, et al. Standards Track [Page 5] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[5ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
RR types, do not form RRsets. In particular, the TTL values among RRSIG RRs with a common owner name do not follow the RRset rules described in [RFC2181].
RRタイプはRRsetsを形成しないでください。 特に、共同所有者名があるRRSIG RRsの中のTTL値は[RFC2181]で説明されたRRset規則に従いません。
An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would add no value and would create an infinite loop in the signing process.
RRSIG RR自身にサインしてはいけません、RRSIG RRにサインすると、価値が全く高められないで、無限ループがサインアップ過程で作成されるだろうというとき。
The NS RRset that appears at the zone apex name MUST be signed, but the NS RRsets that appear at delegation points (that is, the NS RRsets in the parent zone that delegate the name to the child zone's name servers) MUST NOT be signed. Glue address RRsets associated with delegations MUST NOT be signed.
ゾーン頂点名に現れるNS RRsetにサインしなければなりませんが、代表団ポイント(すなわち、親ゾーンの子供ゾーンのネームサーバへ名前を代表として派遣するNS RRsets)で現れるNS RRsetsはサインしてはいけません。 代表団に関連している接着剤アドレスRRsetsにサインしてはいけません。
There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any).
各RRsetのためのそれぞれのアルゴリズムの少なくとも1DNSKEYを使用するRRSIGがゾーンの頂点DNSKEY RRsetにあるに違いありません。 代表として派遣している親(もしあれば)に位置するDS RRsetに現れる各アルゴリズムで頂点DNSKEY RRset自身にサインしなければなりません。
2.3. Including NSEC RRs in a Zone
2.3. ゾーンにnsec RRsを含んでいます。
Each owner name in the zone that has authoritative data or a delegation point NS RRset MUST have an NSEC resource record. The format of NSEC RRs and the process for constructing the NSEC RR for a given name is described in [RFC4034].
信頼すべきデータか代表団がNS RRsetを指すゾーンのそれぞれの所有者名には、NSECリソース記録がなければなりません。 名のためにNSEC RRを組み立てるためのNSEC RRsの形式と過程は[RFC4034]で説明されます。
The TTL value for any NSEC RR SHOULD be the same as the minimum TTL value field in the zone SOA RR.
TTLはゾーンの最小のTTL値の分野と同じくらいがSOA RRであったならいずれのためにもNSEC RR 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レコード(そして、関連RRSIG RRset)はどんな特定の所有者名でも唯一のRRsetであるはずがありません。 すなわち、サインアップ過程はゾーンがサインされる前に所有者名(どんなRRsetも)でなかった所有者名前ノードのためのNSECかRRSIG RRsを作成してはいけません。 この主な理由は同じゾーンと願望のサインされて無記名のバージョンの間の名前空間の一貫性がセキュリティの忘れっぽい再帰的なネームサーバにおける、応答矛盾の危険を減少させる願望です。
The type bitmap of every NSEC resource record in a signed zone MUST indicate the presence of both the NSEC record itself and its corresponding RRSIG record.
サインされたゾーンでのあらゆるNSECリソース記録のタイプビットマップはNSEC記録自体とその対応するRRSIG記録の両方の存在を示さなければなりません。
The difference between the set of owner names that require RRSIG records and the set of owner names that require NSEC records is subtle and worth highlighting. RRSIG records are present at the owner names of all authoritative RRsets. NSEC records are present at the owner names of all names for which the signed zone is authoritative and also at the owner names of delegations from the
RRSIG記録を必要とする所有者名のセットとNSEC記録を必要とする所有者名のセットの違いは、微妙であって、強調する価値があります。 RRSIG記録は所有者名(すべての正式のRRsets)で存在しています。 NSEC記録はサインされたゾーンが正式であるすべての名前の所有者名において代表団の所有者名においても存在しています。
Arends, et al. Standards Track [Page 6] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[6ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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もRRSIG記録も所有者名(接着剤アドレスRRsets)で存在していません(親ゾーンの)。 しかしながら、この区別がゾーンサインアップ過程だけの間だいたい目に見えることに注意してください、NSEC RRsetsは信頼すべきデータであり、したがって、サインされます。 したがって、NSEC RRsetを持っているどんな所有者名もサインされたゾーンにまた、RRSIG RRsを持つでしょう。
The bitmap for the NSEC RR at a delegation point requires special attention. Bits corresponding to the delegation NS RRset and any RRsets for which the parent zone has authoritative data MUST be set; bits corresponding to any non-NS RRset for which the parent is not authoritative MUST be clear.
代表団ポイントのNSEC RRのためのビットマップは特別な注意を必要とします。 親ゾーンには信頼すべきデータがある代表団NS RRsetとどんなRRsetsにも対応するビットを設定しなければなりません。 親が正式でないどんな非NS RRsetにも対応するビットは明確であるに違いありません。
2.4. Including DS RRs in a Zone
2.4. ゾーンにDS RRsを含んでいます。
The DS resource record establishes authentication chains between DNS zones. A DS RRset SHOULD be present at a delegation point when the child zone is signed. The DS RRset MAY contain multiple records, each referencing a public key in the child zone used to verify the RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS RRsets MUST NOT appear at a zone's apex.
DSリソース記録はDNSゾーンの間の認証チェーンを設立します。 DS RRset SHOULD、子供ゾーンがサインされたら代表団ポイントに存在してください。 DS RRsetは複数の記録を含むかもしれません、そのゾーンでRRSIGsについて確かめるのに使用される子供ゾーンでそれぞれ公開鍵に参照をつけて。 ゾーンのすべてのDS RRsetsにサインしなければなりません、そして、DS RRsetsはゾーンの頂点に現れてはいけません。
A DS RR SHOULD point to a DNSKEY RR that is present in the child's apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed by the corresponding private key. DS RRs that fail to meet these conditions are not useful for validation, but because the DS RR and its corresponding DNSKEY RR are in different zones, and because the DNS is only loosely consistent, temporary mismatches can occur.
それは子供の頂点DNSKEY RRset、および子供の頂点DNSKEY RRset SHOULDにDNSKEY RRへのDS RR SHOULDポイント、存在しています。対応する秘密鍵で、サインされます。 これらの条件を満たさないDS RRsは合法化の役に立ちませんが、DS RRとその対応するDNSKEY RRが異なったゾーンにあって、DNSが緩くだけ一貫しているので、一時的なミスマッチは起こることができます。
The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset (that is, the NS RRset from the same zone containing the DS RRset).
DS RRset SHOULDのTTLは代表として派遣するNS RRset(すなわち、DS RRsetを含む同じゾーンからのNS RRset)のTTLに合っています。
Construction of a DS RR requires knowledge of the corresponding DNSKEY RR in the child zone, which implies communication between the child and parent zones. This communication is an operational matter not covered by this document.
DS RRの構造は子供ゾーンで対応するDNSKEY RRに関する知識を必要とします。(それは、子供と親ゾーンとのコミュニケーションを含意します)。 このコミュニケーションはこのドキュメントでカバーされなかった操作上の問題です。
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 RRsetがサインされたゾーンの名前で存在しているなら、適切なRRSIGとNSEC RRsetsはその名前でREQUIREDです。 また、([RFC3007])は安全なダイナミックなアップデート目的のためのその名前におけるKEY RRsetに許容されています。 他のタイプはその名前で出席しているはずがありません。
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
これは[RFC1034]で与えられたオリジナルのCNAME定義への変更です。 CNAME RRのオリジナルの定義はCNAME記録と共存するようにいかなる他のタイプも許容したのではなく、サインされたゾーンを許容しました。
Arends, et al. Standards Track [Page 7] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[7ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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.
あらゆる正式の名前のためにNSECとRRSIG RRsを必要とします。 この闘争を解決するなら、この仕様は、NSECとRRSIG RRsと共存するのを許容するようにCNAMEリソース記録の定義を変更します。
2.6. DNSSEC RR Types Appearing at Zone Cuts
2.6. DNSSEC RRはゾーンカットのときに排臨をタイプします。
DNSSEC introduced two new RR types that are unusual in that they can appear at the parental side of a zone cut. At the parental side of a zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at the owner name. A DS RR could also be present if the zone being delegated is signed and seeks to have a chain of authentication to the parent zone. This is an exception to the original DNS specification ([RFC1034]), which states that only NS RRsets could appear at the parental side of a zone cut.
DNSSECは2つの彼らがゾーンカット親側に載ることができるので珍しい新しいRRタイプを導入しました。 ゾーンカット(すなわち、代表団ポイントの)親側では、NSEC RRsが所有者名でREQUIREDです。 また、代表として派遣されるゾーンがサインされて、親ゾーンに認証のチェーンを持っていようとするなら、DS RRも存在しているかもしれません。 これは当初のDNS仕様([RFC1034])への例外です。(それは、NS RRsetsだけがゾーンカット親側に載るかもしれないと述べます)。
This specification updates the original DNS specification to allow NSEC and DS RR types at the parent side of a zone cut. These RRsets are authoritative for the parent when they appear at the parent side of a zone cut.
この仕様はNSECを許容するために当初のDNS仕様をアップデートします、そして、DS RRはゾーンカットの親側でタイプします。 彼らがゾーンカットの親側に載っているとき、親にとって、これらのRRsetsは正式です。
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])メッセージサイズ拡張子をサポートしなければならなくて、サポートの少なくとも1220の八重奏のメッセージサイズ、およびSHOULDは4000の八重奏のメッセージサイズを支持しなければなりませんか? 送信元ホストがIPv6パケットを断片化できるだけであるように、必要なら、ネームサーバSHOULDがそれがIPv6の上で送るデータグラムをそのUDPに確実にするために手を打つのを意識しているセキュリティは最小のIPv6 MTUで断片化されます、経路MTUが知られていない場合。 パケットサイズと断片化問題のさらなる議論に関して[RFC1122]、[RFC2460]、および[RFC3226]を見てください。
Arends, et al. Standards Track [Page 8] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[8ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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.
そして、疑似RRかそれが持っているEDNS OPTを含んでいないDNS質問を受けるセキュリティ意識しているネームサーバ、はっきりとビットをしてください、扱うようにRRSIG、DNSKEY、およびNSEC RRsを扱わなければならない、いかなる他のRRset、も以下で説明された追加処理のいずれも実行してはいけません。 DS RRタイプが代表団ポイントに親ゾーンに存在するだけの私有財産を持っているので、DS RRsはいつも何らかの特別な処理を必要とします、セクション3.1.4で.1に説明されるように
Security aware name servers that receive explicit queries for security RR types that match the content of more than one zone that it serves (for example, NSEC and RRSIG RRs above and below a delegation point where the server is authoritative for both zones) should behave self-consistently. As long as the response is always consistent for each query to the name server, the name server MAY return one of the following:
それが役立つ1つ以上のゾーン(例えば、ポイントと、そして、両方のゾーンに、サーバが正式である代表団ポイントの下のNSECとRRSIG RRs)の内容に合っているセキュリティRRタイプのために明白な質問を受けるセキュリティの意識しているネームサーバは一貫して自己を振る舞わせるべきです。 各質問において、応答がネームサーバといつも一致している限り、ネームサーバは以下の1つを返すかもしれません:
o The above-delegation RRsets. o The below-delegation RRsets. o Both above and below-delegation RRsets. o Empty answer section (no records). o Some other response. o An error.
o 代表団の下のRRsets o Empty答え部(記録がない) ○ Some他の応答上の上の代表団RRsetsの. ○ 以下の代表団RRsets o Bothとo An誤り。
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(Disabledをチェックする)ビットとAD(正統のData)ビット。 CDビットはレゾルバによって制御されます。 セキュリティ意識しているネームサーバは質問からのCDビットを対応する応答にコピーしなければなりません。 ADビットはネームサーバによって制御されます。 セキュリティ意識しているネームサーバは質問でADビットの設定を無視しなければなりません。 セクション3.1.6、3.2を見てください。.2 3.2 .3 4、およびこれらのビットの動きに関する詳細のための4.9。
A security aware name server that synthesizes CNAME RRs from DNAME RRs as described in [RFC2672] SHOULD NOT generate signatures for the synthesized CNAME RRs.
[RFC2672]で説明されて、SHOULD NOTが統合CNAME RRsのために署名を発生させるときDNAME RRsからCNAME RRsを統合するセキュリティの意識しているネームサーバ。
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疑似RR DOビット([RFC3225])を設定する関連質問を受けると、サインされたゾーンへのセキュリティ意識している正式のネームサーバは追加RRSIG、NSEC、およびDS RRsを含まなければなりません、以下の規則に従って:
o RRSIG RRs that can be used to authenticate a response MUST be
included in the response according to the rules in Section 3.1.1.
o 規則に従って、応答にセクション3.1.1で応答を認証するのに使用できるRRSIG RRsを含まなければなりません。
Arends, et al. Standards Track [Page 9] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[9ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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 規則に従って、応答にセクション3.1.3で自動的に、存在の認証された否定を提供するのに使用できるNSEC RRsを含まなければなりません。
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 規則に従って、紹介にセクション3.1.4で自動的にどんなDS RRsも存在しないと立証するDS RRsetかNSEC RRのどちらかを含まなければなりません。
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").
意味論がリソース記録の存在か欠如に関して情報を伝達するところでこれらの規則は応答に適用されるだけです。 すなわち、これらの規則がRCODE4(「実行されない」)かRCODE5(「拒否される」)などの応答を除外することを意図しません。
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. 応答にRRSIG RRsを含んでいます。
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:
それが持っている質問に応じる、噛み付いているセット(セキュリティ意識しているレゾルバが応答でRRsetsを認証するのに使用できるRRSIG RRsを送るセキュリティ意識している正式のネームサーバSHOULD試み)をしてください。 SHOULDが応答でRRsetを保つための最善の努力とその関連RRSIG(s)を一緒にするネームサーバ。 応答でのRRSIG RRsの包含は以下の規則を受けることがあります:
o When placing a signed RRset in the Answer section, the name server
MUST also place its RRSIG RRs in the Answer section. The RRSIG
RRs have a higher priority for inclusion than any other RRsets
that may have to be included. If space does not permit inclusion
of these RRSIG RRs, the name server MUST set the TC bit.
o また、サインされたRRsetをAnswer部に置くとき、ネームサーバはAnswer部にRRSIG RRsを置かなければなりません。 RRSIG RRsには、包含のための含まれなければならないかもしれないいかなる他のRRsetsよりも高い優先度があります。 スペースがこれらのRRSIG RRsの包含を可能にしないなら、ネームサーバはTCビットを設定しなければなりません。
o When placing a signed RRset in the Authority section, the name
server MUST also place its RRSIG RRs in the Authority section.
The RRSIG RRs have a higher priority for inclusion than any other
RRsets that may have to be included. If space does not permit
inclusion of these RRSIG RRs, the name server MUST set the TC bit.
o 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 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 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.
Arends, et al. Standards Track [Page 10] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends, et al. Standards Track [Page 10] RFC 4035 DNSSEC Protocol Modifications March 2005
3.1.2. Including DNSKEY RRs in a Response
3.1.2. Including DNSKEY RRs in a Response
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).
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).
3.1.3. Including NSEC RRs in a Response
3.1.3. Including NSEC RRs in a Response
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:
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:
No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
but does not contain any RRsets that exactly match <SNAME, SCLASS,
STYPE>.
No Data: The zone contains RRsets that exactly match <SNAME, SCLASS> but does not contain any RRsets that exactly match <SNAME, SCLASS, STYPE>.
Name Error: The zone does not contain any RRsets that match <SNAME,
SCLASS> either exactly or via wildcard name expansion.
Name Error: The zone does not contain any RRsets that match <SNAME, SCLASS> either exactly or via wildcard name expansion.
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.
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.
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.
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.
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.
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.
Arends, et al. Standards Track [Page 11] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends, et al. Standards Track [Page 11] RFC 4035 DNSSEC Protocol Modifications March 2005
3.1.3.1. Including NSEC RRs: No Data Response
3.1.3.1. Including NSEC RRs: No Data Response
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).
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).
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.
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.
3.1.3.2. Including NSEC RRs: Name Error Response
3.1.3.2. Including NSEC RRs: Name Error Response
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:
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:
o An NSEC RR proving that there is no exact match for <SNAME,
SCLASS>.
o An NSEC RR proving that there is no exact match for <SNAME, SCLASS>.
o An NSEC RR proving that the zone contains no RRsets that would
match <SNAME, SCLASS> via wildcard name expansion.
o An NSEC RR proving that the zone contains no RRsets that would match <SNAME, SCLASS> via wildcard name expansion.
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.
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.
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).
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).
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.
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.
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).
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).
3.1.3.3. Including NSEC RRs: Wildcard Answer Response
3.1.3.3. Including NSEC RRs: Wildcard Answer Response
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
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
Arends, et al. Standards Track [Page 12] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends, et al. Standards Track [Page 12] RFC 4035 DNSSEC Protocol Modifications March 2005
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).
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).
3.1.3.4. Including NSEC RRs: Wildcard No Data Response
3.1.3.4. Including NSEC RRs: Wildcard No Data Response
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:
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:
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 An NSEC RR proving that there are no RRsets matching STYPE at the wildcard owner name that matched <SNAME, SCLASS> via wildcard expansion.
o An NSEC RR proving that there are no RRsets in the zone that would
have been a closer match for <SNAME, SCLASS>.
o An NSEC RR proving that there are no RRsets in the zone that would have been a closer match for <SNAME, SCLASS>.
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.
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.
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.
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.
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).
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).
3.1.3.5. Finding the Right NSEC RRs
3.1.3.5. Finding the Right NSEC RRs
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.
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.
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
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
Arends, et al. Standards Track [Page 13] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends, et al. Standards Track [Page 13] RFC 4035 DNSSEC Protocol Modifications March 2005
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.
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.
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].
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].
3.1.4. Including DS RRs in a Response
3.1.4. Including DS RRs in a Response
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.
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.
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.
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.
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).
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).
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).
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).
3.1.4.1. Responding to Queries for DS RRs
3.1.4.1. Responding to Queries for DS RRs
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.
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.
Arends, et al. Standards Track [Page 14] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends, et al. Standards Track [Page 14] RFC 4035 DNSSEC Protocol Modifications March 2005
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.
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.
The need for special processing by a security-aware name server only arises when all the following conditions are met:
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 The name server has received a query for the DS RRset at a zone cut.
o The name server is authoritative for the child zone.
o The name server is authoritative for the child zone.
o The name server is not authoritative for the parent zone.
o The name server is not authoritative for the parent zone.
o The name server does not offer recursion.
o The name server does not offer recursion.
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.
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.
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.
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.
3.1.5. Responding to Queries for Type AXFR or IXFR
3.1.5. Responding to Queries for Type AXFR or 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 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.
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
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
Arends, et al. Standards Track [Page 15] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends, et al. Standards Track [Page 15] RFC 4035 DNSSEC Protocol Modifications March 2005
chooses to perform its own zone validation MUST NOT selectively reject some RRs and accept others.
chooses to perform its own zone validation MUST NOT selectively reject some RRs and accept others.
DS RRsets appear only on the parental side of a zone cut and are authoritative data in the parent zone. As with any other authoritative RRset, the DS RRset MUST be included in zone transfers of the zone in which the RRset is authoritative data. In the case of the DS RRset, this is the parent zone.
DS RRsets 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.
NSEC RRs appear in both the parent and child zones at a zone cut and are authoritative data in both the parent and child zones. The parental and child NSEC RRs at a zone cut are never identical to each other, as the NSEC RR in the child zone's apex will always indicate the presence of the child zone's SOA RR whereas the parental NSEC RR at the zone cut will never indicate the presence of an SOA RR. As with any other authoritative RRs, NSEC RRs MUST be included in zone transfers of the zone in which they are authoritative data. The parental NSEC RR at a zone cut MUST be included in zone transfers of the parent zone, and the NSEC at the zone apex of the child zone MUST be included in zone transfers of the child zone.
NSEC RRs 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.
RRSIG RRs appear in both the parent and child zones at a zone cut and are authoritative in whichever zone contains the authoritative RRset for which the RRSIG RR provides the signature. That is, the RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be authoritative in the parent zone, and the RRSIG for any RRset in the child zone's apex will be authoritative in the child zone. Parental and child RRSIG RRs at a zone cut will never be identical to each other, as the Signer's Name field of an RRSIG RR in the child zone's apex will indicate a DNSKEY RR in the child zone's apex whereas the same field of a parental RRSIG RR at the zone cut will indicate a DNSKEY RR in the parent zone's apex. As with any other authoritative RRs, RRSIG RRs MUST be included in zone transfers of the zone in which they are authoritative data.
RRSIG RRs 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.
3.1.6. The AD and CD Bits in an Authoritative Response
3.1.6. The AD and CD Bits in an Authoritative Response
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.
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.
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.
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.
Arends, et al. Standards Track [Page 16] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends, et al. Standards Track [Page 16] RFC 4035 DNSSEC Protocol Modifications March 2005
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.
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.
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.
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. Recursive Name Servers
3.2. Recursive Name Servers
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.
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.
The resolver side follows the usual rules for caching and negative caching that would apply to any security-aware resolver.
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. The DO Bit
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.
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.
3.2.2. The CD Bit
3.2.2. The CD Bit
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.
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.
The name server side MUST copy the setting of the CD bit from a query to the corresponding response.
The name server side MUST copy the setting of the CD bit from a query to the corresponding response.
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
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
Arends, et al. Standards Track [Page 17] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends, et al. Standards Track [Page 17] RFC 4035 DNSSEC Protocol Modifications March 2005
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.
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.
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).
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).
The intent of the above rule is to provide the raw data to clients that are capable of performing their own signature verification checks while protecting clients that depend on the resolver side of a security-aware recursive name server to perform such checks. Several of the possible reasons why signature validation might fail involve conditions that may not apply equally to the recursive name server and the client that invoked it. For example, the recursive name server's clock may be set incorrectly, or the client may have knowledge of a relevant island of security that the recursive name server does not share. In such cases, "protecting" a client that is capable of performing its own signature validation from ever seeing the "bad" data does not help the client.
The 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. The AD Bit
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
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
Arends, et al. Standards Track [Page 18] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends, et al. Standards Track [Page 18] RFC 4035 DNSSEC Protocol Modifications March 2005
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].
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].
3.3. Example DNSSEC Responses
3.3. Example DNSSEC Responses
See Appendix B for example response packets.
See Appendix B for example response packets.
4. Resolving
4. Resolving
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.
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.
4.1. EDNS Support
4.1. EDNS Support
A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
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.
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.
4.2. Signature Verification Support
4.2. Signature Verification Support
A security-aware resolver MUST support the signature verification mechanisms described in Section 5 and SHOULD apply them to every received response, except when:
A security-aware resolver MUST support the signature verification mechanisms described in Section 5 and SHOULD apply them to every received response, except when:
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 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 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 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 validation for this query has been disabled by local policy.
o validation for this query has been disabled by local policy.
Arends, et al. Standards Track [Page 19] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends, et al. Standards Track [Page 19] RFC 4035 DNSSEC Protocol Modifications March 2005
A security-aware resolver's support for signature verification MUST include support for verification of wildcard owner names.
A security-aware resolver's support for signature verification MUST include support for verification of wildcard owner names.
Security-aware resolvers MAY query for missing security RRs in an attempt to perform validation; implementations that choose to do so must be aware that the answers received may not be sufficient to validate the original response. For example, a zone update may have changed (or deleted) the desired information between the original and follow-up queries.
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.
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.
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.
When attempting to retrieve a missing DS, a security-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone. As explained in Section 3.1.4.1, security-aware name servers need to apply special processing rules to handle the DS RR, and in some situations the resolver may also need to apply special rules to locate the name servers for the parent zone if the resolver does not already have the parent's NS RRset. To locate the parent NS RRset, the resolver can start with the delegation name, strip off the leftmost label, and query for an NS RRset by that name. If no NS RRset is present at that name, the resolver then strips off the leftmost remaining label and retries the query for that name, repeating this process of walking up the tree until it either finds the NS RRset or runs out of labels.
なくなったDSを検索するのを試みるとき、セキュリティ意識している繰り返しのモードレゾルバは子供ゾーンではなく、親ゾーンにネームサーバについて質問しなければなりません。 .1、セキュリティ意識しているネームサーバが適用する必要があるセクション3.1.4で説明されるように、特別な処理はDS RRを扱うために統治されます、そして、また、いくつかの状況で、レゾルバが既に親のNS RRsetを持たないなら、レゾルバが親ゾーンへのネームサーバの場所を見つけるように特別な規則を適用する必要があるかもしれません。 親NS RRsetの場所を見つけるように、レゾルバは代表団名、一番左ラベルの片、およびその名前のNS RRsetのための質問から始まることができます。 どんなNS RRsetもその名前で存在していないなら、レゾルバは、次に、一番左残っているラベルを全部はぎ取って、その名前のための質問を再試行します、NS RRsetを見つけるか、またはラベルを使い果たすまで木を歩くこの過程を繰り返して。
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:
セキュリティ意識しているレゾルバは、それが、特定のRRsetがサインされると予想するべきであるかどうか決定できなければなりません。 より正確に、セキュリティ意識しているレゾルバは4つのケースを見分けることができなければなりません:
Secure: An RRset for which the resolver is able to build a chain of
signed DNSKEY and DS RRs from a trusted security anchor to the
RRset. In this case, the RRset should be signed and is subject to
signature validation, as described above.
安全にします: 信じられたセキュリティからのレゾルバがサインされたDNSKEYのチェーンを組立てることができるRRsetとDS RRsはRRsetに投錨します。 この場合、RRsetは上で説明されるようにサインされるべきであり、署名合法化を受けることがあります。
Insecure: An RRset for which the resolver knows that it has no chain
of signed DNSKEY and DS RRs from any trusted starting point to the
RRset. This can occur when the target RRset lies in an unsigned
zone or in a descendent of an unsigned zone. In this case, the
RRset may or may not be signed, but the resolver will not be able
to verify the signature.
不安定: レゾルバがそれにはどんな信じられた出発点からRRsetまでもサインされたDNSKEYとDS RRsのチェーンが全くないのを知っているRRset。 目標RRsetが無記名のゾーンか無記名のゾーンにおける下降のaにいると、これは起こることができます。 この場合、RRsetはサインされるかもしれませんが、レゾルバは署名について確かめることができないでしょう。
Arends, et al. Standards Track [Page 20] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[20ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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 RRsが存在しているべきであるのを示すデータを、有効にするか、またはレゾルバが信用のチェーンを設立できるべきであると信じていますが、それがどちらかある理由でそうしない署名のためそうすることができないRRsetは逃します。 本件は、攻撃を示しますが、また、構成誤りか何らかの形式のデータの汚染を示すかもしれません。
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.
不確定: レゾルバが、RRsetがレゾルバとしてサインされるべきであるかどうか決定できないRRsetは必要なDNSSEC RRsを入手できません。 セキュリティ意識しているレゾルバがセキュリティ意識しているネームサーバに関連ゾーンへ連絡できないとき、これは起こることができます。
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信じられた公開鍵かDS RRとSHOULDで構成できなければなりません。複数の信じられた公開鍵かDS RRsで構成できてください。 セキュリティ意識しているレゾルバがそのような構成された信用アンカーなしで署名を有効にすることができない、レゾルバ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>.
命名されたRRsetとどんな関連DNSSEC RRsも含む全体の答えを含むセキュリティ意識しているレゾルバSHOULDがシングルとして各応答をキャッシュするのを原子エントリー。 それに含まれたRRsのどれかが期限が切れると、レゾルバSHOULDは全体の原子エントリーを捨てます。 多くの場合、原子エントリーへの適切なキャッシュインデックスは三重の<QNAMEになるでしょう、QTYPE、QCLASS>、しかし、セクション3.1.3で説明された応答形式などの場合では、適切なキャッシュが索引をつける.2が二重<QNAMEになるでしょう、QCLASS>。
The reason for these recommendations is that, between the initial query and the expiration of the data from the cache, the authoritative data might have been changed (for example, via dynamic update).
これらの推薦の理由はキャッシュからのデータの初期の質問と満了の間で信頼すべきデータを変えたかもしれないという(例えばダイナミックなアップデートで)ことです。
Arends, et al. Standards Track [Page 21] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[21ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
There are two situations for which this is relevant:
これが関連している2つの状況があります:
1. By using the RRSIG record, it is possible to deduce that an
answer was synthesized from a wildcard. A security-aware
recursive name server could store this wildcard data and use it
to generate positive responses to queries other than the name for
which the original answer was first received.
1. RRSIG記録を使用することによって、答えがワイルドカードから統合されたと推論するのは可能です。 セキュリティ意識している再帰的なネームサーバは、オリジナルの答えが最初に受けられた名前以外の質問への積極的な応答を発生させるのにこのワイルドカードデータを格納して、それを使用するかもしれません。
2. NSEC RRs received to prove the non-existence of a name could be
reused by a security-aware resolver to prove the non-existence of
any name in the name range it spans.
2. NSEC RRsは、セキュリティ意識しているレゾルバがそれがわたる名前範囲のどんな名前の非存在も立証するために名前の非存在を再利用できたと立証するために受信しました。
In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace.
理論上、レゾルバは、問題の記録におけるTTLか署名が期限が切れるまで積極的で否定的な応答(それぞれ)を発生させるのにワイルドカードかNSEC RRsを使用できました。 しかしながら、レゾルバが、新しい信頼すべきデータを妨げるか、またはそれら自身のに関する新しいデータを統合するのを避けるように慎重に思えます。 この推薦に続くレゾルバが名前空間の、より一貫した視点を持つでしょう。
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.
セキュリティ意識しているレゾルバは、レゾルバがローカルの方針がRRsetsで応答で必要とするどんな認証も実行するのに責任を取るのを示すためにクエリーのCDビットを設定するかもしれません。 このビットがセキュリティ意識している再帰的なネームサーバの振舞いのときに持っている効果に関してセクション3.2を見てください。
A security-aware resolver MUST clear the AD bit when composing query messages to protect against buggy name servers that blindly copy header bits that they do not understand from the query message to the response message.
盲目的に、彼らが質問メッセージから応答メッセージまで理解していないヘッダービットをコピーするバギーのネームサーバから守る質問メッセージを構成するとき、セキュリティ意識しているレゾルバはADビットをきれいにしなければなりません。
A resolver MUST disregard the meaning of the CD and AD bits in a response unless the response was obtained by using a secure channel or the resolver was specifically configured to regard the message header bits without using a secure channel.
安全なチャンネルを使用することによって応答を得たか、または安全なチャンネルを使用しないでメッセージヘッダービットを見なすために明確にレゾルバを構成しなかったなら、レゾルバは応答でCDとADビットの意味を無視しなければなりません。
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交通がRRsetsのための繰り返された質問の結果、しつこい合法化失敗で発生するかもしれません。
To prevent such unnecessary DNS traffic, security-aware resolvers MAY cache data with invalid signatures, with some restrictions.
そのような不要なDNS交通を防ぐために、セキュリティ意識しているレゾルバは無効の署名、いくつかの制限でデータをキャッシュするかもしれません。
Arends, et al. Standards Track [Page 22] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[22ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
Conceptually, caching such data is similar to negative caching ([RFC2308]), except that instead of caching a valid negative response, the resolver is caching the fact that a particular answer failed to validate. This document refers to a cache of data with invalid signatures as a "BAD cache".
概念的に、そのようなデータをキャッシュするのは否定的キャッシュ([RFC2308])と同様です、有効な否定応答をキャッシュすることの代わりにレゾルバが特定の答えが有効にしなかった事実をキャッシュしているのを除いて。 このドキュメントは無効の署名で「BADキャッシュ」とデータのキャッシュを呼びます。
Resolvers that implement a BAD cache MUST take steps to prevent the cache from being useful as a denial-of-service attack amplifier, particularly the following:
BADキャッシュを実行するレゾルバはキャッシュがサービス不能攻撃アンプとして役に立つのを防ぐために手を打たなければなりません、特に以下:
o Since RRsets that fail to validate do not have trustworthy TTLs,
the implementation MUST assign a TTL. This TTL SHOULD be small,
in order to mitigate the effect of caching the results of an
attack.
o それが有効にしないRRsetsが信頼できるTTLsを持っていないので、実現はTTLを割り当てなければなりません。 この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 その特定の<QNAME、QTYPE、QCLASS>のための質問への応答が有効にしていない回数が閾値を超えた後に、キャッシュするのを防ぐために、一時的な合法化失敗(攻撃の結果であるかもしれない)では、合法化失敗とSHOULDをもたらすレゾルバSHOULD道の質問にBADキャッシュから答えるだけです。
Resolvers MUST NOT return RRsets from the BAD cache unless the resolver is not required to validate the signatures of the RRsets in question under the rules given in Section 4.2 of this document. See Section 3.2.2 for discussion of how the responses returned by a security-aware recursive name server interact with a BAD cache.
レゾルバがこのドキュメントのセクション4.2で与えられた規則の下で問題のRRsetsの署名を有効にしなければならない場合、レゾルバはBADキャッシュからRRsetsを返してはいけません。 セキュリティ意識している再帰的なネームサーバによって返された応答がどうBADキャッシュと対話するかに関する議論に関してセクション3.2.2を見てください。
4.8. Synthesized CNAMEs
4.8. 統合CNAMEs
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]で少なくとも唯一そのようなCNAME RRsを含んでいるので応答メッセージを拒絶しない範囲まで説明されるようにDNAME RRから統合されたかもしれない無記名のCNAME RRsを覆うとセキュリティレゾルバが有効なサインされたDNAME RRの署名を扱わなければならないのを意識している有効にすること。 レゾルバは、キャッシュかそれが返す答えでそのようなCNAME RRsを保有するかもしれませんが、そうする必要はありません。
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 RRsを含んでいるので、セキュリティ意識しているスタッブレゾルバは少なくとも誤って扱う応答でない範囲へのDNSSEC RRタイプを支持しなければなりません。
Arends, et al. Standards Track [Page 23] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[23ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
4.9.1. Handling of the DO Bit
4.9.1. 取り扱い、ビットをしてください。
A non-validating security-aware stub resolver MAY include the DNSSEC RRs returned by a security-aware recursive name server as part of the data that the stub resolver hands back to the application that invoked it, but is not required to do so. A non-validating stub resolver that seeks to do this will need to set the DO bit in order to receive DNSSEC RRs from the recursive name server.
非有効にしているセキュリティ意識しているスタッブレゾルバは、スタッブレゾルバ手がそれを呼び出したアプリケーションに支持するデータの一部としてセキュリティ意識している再帰的なネームサーバで返されたDNSSEC RRsを含むかもしれませんが、そうするのに必要ではありません。 これをしようとする非有効にしているスタッブレゾルバが、セットする必要がある、再帰的なネームサーバからDNSSEC RRsを受けるためにビットをしてください。
A validating security-aware stub resolver MUST set the DO bit, because otherwise it will not receive the DNSSEC RRs it needs to perform signature validation.
セキュリティスタッブレゾルバがセットしなければならないのを意識している有効にする、ビットをしてください、さもなければ、署名合法化を実行するのが必要であるDNSSEC RRsを受けないので。
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.
非有効にしているセキュリティ定義上非の有効にするスタッブとして意識しているそれが応用層によって要求されない場合質問を送るとき、スタッブレゾルバSHOULD NOTがCDビットを設定するのをレゾルバは、利益に合法化を実行するためにセキュリティ意識している再帰的なネームサーバを当てにします。
A validating security-aware stub resolver SHOULD set the CD bit, because otherwise the security-aware recursive name server will answer the query using the name server's local policy, which may prevent the stub resolver from receiving data that would be acceptable to the stub resolver's local policy.
セキュリティスタッブレゾルバSHOULDがCDを設定するのを意識している有効にすることに噛み付きました、スタッブレゾルバがスタッブリゾルバのローカルの方針に許容できるデータを受け取ることができないかもしれないネームサーバのローカルの方針を使用することでセキュリティ意識している再帰的なネームサーバがさもなければ、質問に答えるので。
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.
セキュリティスタッブレゾルバがそうするかもしれないのを意識している非の有効にするのは、それが持っている応答クレームを送ったセキュリティ意識している再帰的なネームサーバが暗号で応答メッセージのAnswerとAuthority部のデータについて確かめたかどうか決定するために受ける応答メッセージでADビットの設定を調べるのを選びました。 しかしながら、セキュリティ意識しているスタッブレゾルバによって受けられた応答がずっしりとセキュリティ意識している再帰的なネームサーバのローカルの方針に依存していることに注意してください。したがって、ADビットの状態をチェックするのにおいて少ない実用的な値があるかもしれません、恐らくデバッギング・エイドを除いて。 どのような場合でも、セキュリティ意識しているスタッブレゾルバは利益に実行されたとされている署名合法化への少しの信用も置いてはいけません、セキュリティ意識しているスタッブレゾルバが信じられたセキュリティ意識している再帰的なネームサーバから安全なチャンネルで問題のデータを得た時を除いて。
A validating security-aware stub resolver SHOULD NOT examine the setting of the AD bit in response messages, as, by definition, the stub resolver performs its own signature validation regardless of the setting of the AD bit.
セキュリティスタッブレゾルバSHOULD NOTがADの設定を調べるのを意識している有効にすることに応答メッセージで噛み付きました、スタッブレゾルバがADビットの設定にかかわらず定義上それ自身の署名合法化を実行するとき。
Arends, et al. Standards Track [Page 24] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[24ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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 RRsを使用するために、セキュリティ意識しているレゾルバは少なくとも1認証されたDNSKEYかDS RRに関する構成された知識を必要とします。 この初期の信用アンカーを得て、認証するための過程は何らかの外部のメカニズムで獲得されます。 例えば、レゾルバは、ゾーンのDNSKEY RRを入手するか、またはゾーンのDNSKEY RRを特定して、認証するDS RRを入手するのに何らかのオフライン認証された交換を使用できました。 このセクションの残りは、レゾルバがどうにか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 RRsetを認証するのに初期のDNSKEY RRを使用できます。 頂点を認証するために、初期のキー、レゾルバを使用するのによるDNSKEY RRsetはそうしなければなりません:
1. verify that the initial DNSKEY RR appears in the apex DNSKEY
RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
bit 7) set; and
1. 初期のDNSKEY RRが頂点DNSKEY RRsetで見えて、DNSKEY RRがZone Key Flag(DNSKEY RDATAビット7)を用意ができさせることを確かめてください。 そして
2. verify that there is some RRSIG RR that covers the apex DNSKEY
RRset, and that the combination of the RRSIG RR and the initial
DNSKEY RR authenticates the DNSKEY RRset. The process for using
an RRSIG RR to authenticate an RRset is described in Section 5.3.
2. 頂点DNSKEY RRsetを覆ういくらかのRRSIG RRがあって、RRSIG RRと初期のDNSKEY RRの組み合わせがDNSKEY RRsetを認証することを確かめてください。 RRsetを認証するのにRRSIG RRを使用するための過程はセクション5.3で説明されます。
Once the resolver has authenticated the apex DNSKEY RRset by using an initial DNSKEY RR, delegations from that zone can be authenticated by using DS RRs. This allows a resolver to start from an initial key and use DS RRsets to proceed recursively down the DNS tree, obtaining other apex DNSKEY RRsets. If the resolver were configured with a root DNSKEY RR, and if every delegation had a DS RR associated with it, then the resolver could obtain and validate any apex DNSKEY RRset. The process of using DS RRs to authenticate referrals is described in Section 5.2.
レゾルバが初期のDNSKEY RRを使用することによっていったん頂点DNSKEY RRsetを認証すると、DS RRsを使用することによって、そのゾーンからの代表団を認証できます。 これで、レゾルバは、初期のキーから始めて、DNS木の下側に再帰的に続くのにDS RRsetsを使用します、他の頂点DNSKEY RRsetsを入手して。 レゾルバが根のDNSKEY RRによって構成されて、あらゆる代表団がそれに関連しているDS RRを持っているなら、レゾルバは、どんな頂点DNSKEY RRsetも得て、有効にすることができるでしょうに。 紹介を認証するのにDS RRsを使用する過程はセクション5.2で説明されます。
Section 5.3 shows how the resolver can use DNSKEY RRs in the apex DNSKEY RRset and RRSIG RRs from the zone to authenticate any other RRsets in the zone once the resolver has authenticated a zone's apex DNSKEY RRset. Section 5.4 shows how the resolver can use authenticated NSEC RRsets from the zone to prove that an RRset is not present in the zone.
セクション5.3はレゾルバがレゾルバがいったんゾーンの頂点DNSKEY RRsetを認証したあとにゾーンでいかなる他のRRsetsも認証するのに頂点のDNSKEY RRsetとRRSIG RRsでゾーンからDNSKEY RRsをどう使用できるかを示しています。 セクション5.4はゾーンにレゾルバがRRsetが存在していないと立証するのにゾーンから認証されたNSEC RRsetsをどう使用できるかを示しています。
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
レゾルバがDNSSECのサポートを示す、(設定、する、ビット)、セキュリティ意識しているネームサーバは応答(セクション3を見る)における必要なDNSKEYを提供する試み、RRSIG、NSEC、およびDS RRsetsがそうするべきです。 しかしながら、セキュリティ意識しているレゾルバはまだ適切なDNSSEC RRsを欠いている応答を受けているかもしれません、構成への支払われるべきものが上流のセキュリティ忘れっぽい再帰的なネームサーバのようにそれを発行するか否かに関係なく
Arends, et al. Standards Track [Page 25] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[25ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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.
DNSSEC RRsか敵が応答を鍛造するか、応答からDNSSEC RRsを剥取るか、または質問を変更するのでDNSSEC RRsが要求されていないように見える計画的犯行のため偶然干渉します。 認証情報が全く存在していないという指示としてそれ自体で応答における、DNSSECデータの欠如をみなしてはいけません。
A resolver SHOULD expect authentication information from signed zones. A resolver SHOULD believe that a zone is signed if the resolver has been configured with public key information for the zone, or if the zone's parent is signed and the delegation from the parent contains a DS RRset.
SHOULDが認証情報を予想するレゾルバはゾーンにサインしました。 レゾルバSHOULDは、レゾルバがゾーンのための公開鍵情報によって構成されたか、またはゾーンの親がサインされるならゾーンがサインされると信じています、そして、親からの代表団はDS RRsetを含みます。
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]を見る)の諸島は親からゾーンに認証チェーンを組み立てるのが可能でないサインされたゾーンです。 セキュリティの島の中で署名を有効にするのは、validatorには島に、主要な初期の認証されたゾーンを得るある他の手段があるのを必要とします。 aであるなら、validatorはそのようなキーを入手できないで、それはまるでセキュリティの島のゾーンが無記名であるかのように作動することへの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.
応答を有効にするためのすべての正常な過程がセキュリティの島に適用されます。 セキュリティの島の中の通常の合法化と合法化の唯一の違いがvalidatorがどう信用アンカーを認証チェーンとして得るかであります。
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 RRsetがいったん認証されると、サインされた子供ゾーンに代表団を認証するのにDS RRsetsを使用できます。 DS RRは子供ゾーンの頂点DNSKEY RRsetでDNSKEY RRを特定して、子供ゾーンのDNSKEY RRの暗号のダイジェストを含んでいます。 強い暗号のダイジェストアルゴリズムの使用は敵がダイジェストに合っているDNSKEY RRを発生させるのが確実に計算上実行不可能になるようにします。 したがって、ダイジェストを認証するのに、レゾルバは合っているDNSKEY RRを認証できます。 そして、レゾルバは、全体の子供頂点DNSKEY RRsetを認証するのにこの子供DNSKEY RRを使用できます。
Given a DS RR for a delegation, the child zone's apex DNSKEY RRset can be authenticated if all of the following hold:
代表団のためのDS RRを考えて、以下の保持のすべてなら子供ゾーンの頂点DNSKEY RRsetを認証できます:
o The DS RR has been authenticated using some DNSKEY RR in the
parent's apex DNSKEY RRset (see Section 5.3).
o DS RRは、親の頂点DNSKEY RRsetのいくらかのDNSKEY RRを使用することで認証されました(セクション5.3を見てください)。
Arends, et al. Standards Track [Page 26] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[26ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
o The Algorithm and Key Tag in the DS RR match the Algorithm field
and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
RRset, and, when the DNSKEY RR's owner name and RDATA are hashed
using the digest algorithm specified in the DS RR's Digest Type
field, the resulting digest value matches the Digest field of the
DS RR.
o DS RRのAlgorithmとKey Tagは子供ゾーンの頂点DNSKEY RRsetでAlgorithm分野とDNSKEY RRのキー・タグに合っています、そして、DNSKEY RRの所有者の名前とRDATAがDS RRのDigest Type分野で指定されたダイジェストアルゴリズムを使用することで論じ尽くされるとき、結果として起こるダイジェスト値はDS RRのDigest分野に合っています。
o The matching DNSKEY RR in the child zone has the Zone Flag bit
set, the corresponding private key has signed the child zone's
apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
child zone's apex DNSKEY RRset.
o 子供ゾーンの合っているDNSKEY RRはZone Flagビットを設定させます、そして、対応する秘密鍵は子供ゾーンの頂点DNSKEY RRsetにサインしました、そして、結果として起こるRRSIG RRは子供ゾーンの頂点DNSKEY RRsetを認証します。
If the referral from the parent zone did not contain a DS RRset, the response should have included a signed NSEC RRset proving that no DS RRset exists for the delegated name (see Section 3.1.4). A security-aware resolver MUST query the name servers for the parent zone for the DS RRset if the referral includes neither a DS RRset nor a NSEC RRset proving that the DS RRset does not exist (see Section 4).
親ゾーンからの紹介がDS RRsetを含まなかったなら、応答はどんなDS RRsetも代表として派遣された名前のために存在しないと立証するサインされたNSEC RRsetを含むべきでした(セクション3.1.4を見てください)。 紹介がDS RRsetが存在しないと立証しないDS RRsetもNSEC RRsetも含んでいるなら(セクション4を見てください)、セキュリティ意識しているレゾルバはDS RRsetのために親ゾーンにネームサーバについて質問しなければなりません。
If the validator authenticates an NSEC RRset that proves that no DS RRset is present for this zone, then there is no authentication path leading from the parent to the child. If the resolver has an initial DNSKEY or DS RR that belongs to the child zone or to any delegation below the child zone, this initial DNSKEY or DS RR MAY be used to re-establish an authentication path. If no such initial DNSKEY or DS RR exists, the validator cannot authenticate RRsets in or below the child zone.
validatorがどんなDS RRsetもこのゾーンに存在していないと立証するNSEC RRsetを認証するなら、親から子供まで導く認証経路が全くありません。 レゾルバが子供ゾーン、または、どんな代表団にも属する初期のDNSKEYかDS RRを持っているならこの子供ゾーン、初期のDNSKEYまたはDS RR MAYの下では、使用されて、認証経路を復職させてください。 どれかそのような初期のDNSKEYもDS RRも存在していないなら、validatorはゾーンか子供ゾーンの下のRRsetsを認証できません。
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.
validatorが認証されたDS RRsetに記載されたアルゴリズムのいずれも支持しないなら、レゾルバには、親から子供まで導かない支持された認証経路が全くあります。 上で説明されるようにどんなDS RRsetも存在しないと立証する認証されたNSEC RRsetに関するケースを扱うようにレゾルバは本件を扱うはずです。
Note that, for a signed delegation, there are two NSEC RRs associated with the delegated name. One NSEC RR resides in the parent zone and can be used to prove whether a DS RRset exists for the delegated name. The second NSEC RR resides in the child zone and identifies which RRsets are present at the apex of the child zone. The parent NSEC RR and child NSEC RR can always be distinguished because the SOA bit will be set in the child NSEC RR and clear in the parent NSEC RR. A security-aware resolver MUST use the parent NSEC RR when attempting to prove that a DS RRset does not exist.
代表として派遣された名前に関連している2NSEC RRsがサインされた代表団のためにあることに注意してください。 1NSEC RRは親ゾーンに住んでいて、DS RRsetが代表として派遣された名前のために存在するかどうか立証するのに使用できます。 第2NSEC RRは、子供ゾーンの頂点で子供ゾーンに住んでいて、どのRRsetsが存在しているかを特定します。 SOAビットが子供NSEC RRに設定されて、親NSEC RRできれいにされるので、いつも親NSEC RRと子供NSEC RRを区別できます。 DS RRsetが存在しないと立証するのを試みるとき、セキュリティ意識しているレゾルバは親NSEC RRを使用しなければなりません。
Arends, et al. Standards Track [Page 27] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[27ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
If the resolver does not support any of the algorithms listed in an authenticated DS RRset, then the resolver will not be able to verify the authentication path to the child zone. In this case, the resolver SHOULD treat the child zone as if it were unsigned.
レゾルバが認証されたDS RRsetに記載されたアルゴリズムのいずれも支持しないと、レゾルバは子供ゾーンに認証経路について確かめることができないでしょう。 この場合、まるでそれが無記名であるかのようにレゾルバSHOULDは子供ゾーンを扱います。
5.3. Authenticating an RRset with an RRSIG RR
5.3. RRSIG RRとRRsetを認証します。
A validator can use an RRSIG RR and its corresponding DNSKEY RR to attempt to authenticate RRsets. The validator first checks the RRSIG RR to verify that it covers the RRset, has a valid time interval, and identifies a valid DNSKEY RR. The validator then constructs the canonical form of the signed data by appending the RRSIG RDATA (excluding the Signature Field) with the canonical form of the covered RRset. Finally, the validator uses the public key and signature to authenticate the signed data. Sections 5.3.1, 5.3.2, and 5.3.3 describe each step in detail.
validatorは、RRsetsを認証するのを試みるのにRRSIG RRとその対応するDNSKEY RRを使用できます。 validatorは、最初に、RRsetを覆っていて、有効な時間間隔を過して、有効なDNSKEY RRを特定することを確かめるためにRRSIG RRをチェックします。 そして、覆われたRRsetの標準形と共にRRSIG RDATAを追加することによって(Signature Fieldを除いて)、validatorはサインされたデータの標準形を構成します。 最終的に、validatorは、サインされたデータを認証するのに公開鍵と署名を使用します。 セクション5.3 .1 5.3 .2、および.3が各ステップで詳細に説明する5.3。
5.3.1. Checking the RRSIG RR Validity
5.3.1. RRSIG RRの正当性をチェックします。
A security-aware resolver can use an RRSIG RR to authenticate an RRset if all of the following conditions hold:
以下の条件のすべてが成立するなら、セキュリティ意識しているレゾルバはRRsetを認証するのにRRSIG RRを使用できます:
o The RRSIG RR and the RRset MUST have the same owner name and the
same class.
o RRSIG RRとRRsetには、同じ所有者名と同じクラスがなければなりません。
o The RRSIG RR's Signer's Name field MUST be the name of the zone
that contains the RRset.
o RRSIG RRのSignerのName分野はRRsetを含むゾーンの名前であるに違いありません。
o The RRSIG RR's Type Covered field MUST equal the RRset's type.
o RRSIG RRのType Covered分野はRRsetのタイプと等しくなければなりません。
o The number of labels in the RRset owner name MUST be greater than
or equal to the value in the RRSIG RR's Labels field.
o RRset所有者名のラベルの数はそう以上であるに違いありません。RRSIG RRのLabels分野の値。
o The validator's notion of the current time MUST be less than or
equal to the time listed in the RRSIG RR's Expiration field.
o validatorの現在の時間の概念はRRSIG RRのExpiration分野に記載されたより時間以下であるに違いありません。
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 validatorの現在の時間の概念はRRSIG RRのInception分野では、時間が、より記載したということであるに違いありません。
o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
match the owner name, algorithm, and key tag for some DNSKEY RR in
the zone's apex DNSKEY RRset.
o RRSIG RRのSignerのName、Algorithm、およびKey Tag分野はゾーンの頂点DNSKEY RRsetのいくらかのDNSKEY RRのための所有者名、アルゴリズム、およびキー・タグに合わなければなりません。
o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
set.
o 合っているDNSKEY RR MUSTはゾーンの頂点DNSKEY RRsetに存在していて、Zone Flagビット(DNSKEY RDATA Flagビット7)を設定させなければなりません。
Arends, et al. Standards Track [Page 28] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[28ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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.
1DNSKEY RRが上記の状態に合っているのは、可能です。 この場合、validatorは署名を認証する使用へのどのDNSKEY RRを予定できないか、そして、署名が有効にされるか、またはvalidatorが試みるために合っている公開鍵を使い果たすまで、それはそれぞれの合っているDNSKEY RRを試みなければなりません。
Note that this authentication process is only meaningful if the validator authenticates the DNSKEY RR before using it to validate signatures. The matching DNSKEY RR is considered to be authentic if:
署名を有効にするのにそれを使用する前にvalidatorがDNSKEY RRを認証する場合にだけこの認証過程が重要であることに注意してください。 合っているDNSKEY RRが正統であると考えられる、:
o the apex DNSKEY RRset containing the DNSKEY RR is considered
authentic; or
o DNSKEY RRを含む頂点DNSKEY RRsetは正統であると考えられます。 または
o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
and the DNSKEY RR either matches an authenticated DS RR from the
parent zone or matches a trust anchor.
o RRSIG RRで覆われたRRsetが頂点DNSKEY RRset自身であり、DNSKEY RRは親ゾーンから認証されたDS RRを合わせるか、または信用アンカーに合っています。
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:
RRSIG RRがいったんセクション5.3.1で説明された正当性必要条件を満たすと、validatorはオリジナルのサインされたデータを再建しなければなりません。 オリジナルのサインされたデータはRRSIG RDATA(Signature分野を除いた)とRRsetの標準形を含んでいます。 注文することは別として、RRsetの標準形はDNS名前圧縮、減少したTTLs、またはワイルドカード拡大のためまた、容認されたRRsetと異なるかもしれません。 validatorはオリジナルのサインされたデータを再建するのに以下を使用するはずです:
signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
サインされた_データはRRSIG_RDATAと等しいです。| RR(1)| RR(2)… どこ
"|" denotes concatenation
"|「連結を指示します」
RRSIG_RDATA is the wire format of the RRSIG RDATA fields
with the Signature field excluded and the Signer's Name
in canonical form.
RRSIG_RDATAはSignature分野が除かれて、SignerのNameが標準形にあるRRSIG RDATA分野のワイヤ形式です。
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
RR(i)=名| タイプ| クラス| OrigTTL| RDATAの長さ| RDATA
name is calculated according to the function below
以下での機能に従って、名前は計算されます。
class is the RRset's class
クラスはRRsetのクラスです。
type is the RRset type and all RRs in the class
タイプは、RRsetタイプとすべて、クラスでRRsです。
OrigTTL is the value from the RRSIG Original TTL field
OrigTTLはRRSIG Original TTL分野からの値です。
All names in the RDATA field are in canonical form
RDATA分野のすべての名前が標準形にあります。
Arends, et al. Standards Track [Page 29] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[29ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
The set of all RR(i) is sorted into canonical order.
すべてのRR(i)のセットは正準なオーダーに分類されます。
To calculate the name:
let rrsig_labels = the value of the RRSIG Labels field
名前について計算するために: rrsig_ラベルをRRSIG Labels分野の値との等しさにしてください。
let fqdn = RRset's fully qualified domain name in
canonical form
fqdnを標準形のRRsetの完全修飾ドメイン名との等しさにしてください。
let fqdn_labels = Label count of the fqdn above.
fqdn_ラベルを上のfqdnのラベルカウントとの等しさにしてください。
if rrsig_labels = fqdn_labels,
name = fqdn
rrsig_ラベルがfqdn_ラベルと等しいなら、=をfqdnと命名してください。
if rrsig_labels < fqdn_labels,
name = "*." | the rightmost rrsig_label labels of the
fqdn
「rrsig_が<fqdn_ラベルをラベルするなら、」 *と=を命名してください。」| fqdnの一番右のrrsig_ラベルラベル
if rrsig_labels > fqdn_labels
the RRSIG RR did not pass the necessary validation
checks and MUST NOT be used to authenticate this
RRset.
>fqdn_がRRSIG RRをラベルするrrsig_ラベルが通らなかったなら、必要な合法化は、チェックして、このRRsetを認証するのに使用されてはいけません。
The canonical forms for names and RRsets are defined in [RFC4034].
名前とRRsetsのための標準形は[RFC4034]で定義されます。
NSEC RRsets at a delegation boundary require special processing. There are two distinct NSEC RRsets associated with a signed delegated name. One NSEC RRset resides in the parent zone, and specifies which RRsets are present at the parent zone. The second NSEC RRset resides at the child zone and identifies which RRsets are present at the apex in the child zone. The parent NSEC RRset and child NSEC RRset can always be distinguished as only a child NSEC RR will indicate that an SOA RRset exists at the name. When reconstructing the original NSEC RRset for the delegation from the parent zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the child zone. When reconstructing the original NSEC RRset for the apex of the child zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent zone.
代表団境界のNSEC RRsetsは特別な処理を必要とします。 サインされた代表として派遣された名前に関連している2異なったNSEC RRsetsがあります。 1NSEC RRsetが、親ゾーンに住んでいて、親ゾーンでどのRRsetsが存在しているかを指定します。 第2NSEC RRsetは、子供ゾーンの頂点で子供ゾーンに住んでいて、どのRRsetsが存在しているかを特定します。 子供NSEC RRだけが、SOA RRsetが名前で存在するのを示すとき、いつも親NSEC RRsetと子供NSEC RRsetを区別できます。 代表団のために親ゾーンからオリジナルのNSEC RRsetを再建するとき、NSEC RRsを子供ゾーンからNSEC RRsに結合してはいけません。 子供ゾーンの頂点にオリジナルのNSEC RRsetを再建するとき、NSEC RRsを親ゾーンからNSEC RRsに結合してはいけません。
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.
代表団ポイントのそれぞれの2NSEC RRsetsには所有者名が代表として派遣された名前に合っている対応するRRSIG RRがあって、それぞれのこれらのRRSIG RRsが対応するNSEC RRsetを含む同じゾーンに関連している信頼すべきデータであることに注意してください。 必要なら、レゾルバは、これらのRRSIG RRsよりSignerのName分野をチェックすることによって、見分けることができます。
Arends, et al. Standards Track [Page 30] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[30ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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.2で説明されるように一度、セクション5.3.1で説明されるようにRRSIG RRを有効にして、オリジナルのサインされたデータを再建したことがあって、validatorはサインされたデータを認証するのに暗号の署名を使用するのを試みて、その結果、(最終的に)!RRsetを認証できます。
The Algorithm field in the RRSIG RR identifies the cryptographic algorithm used to generate the signature. The signature itself is contained in the Signature field of the RRSIG RDATA, and the public key used to verify the signature is contained in the Public Key field of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034] provides a list of algorithm types and provides pointers to the documents that define each algorithm's use.
RRSIG RRのAlgorithm分野は署名を発生させるのに使用される暗号アルゴリズムを特定します。 署名自体はRRSIG RDATAのSignature分野に保管されています、そして、署名について確かめるのに使用される公開鍵は合っているDNSKEY RR(s)(セクション5.3.1では、見つけられる)のPublic Key分野に保管されています。 [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.
1DNSKEY RRがセクション5.3.1における状態に合っているのが、可能であることに注意してください。 この場合、validatorは、どのDNSKEY RRがvalidatorが署名を有効にするのに成功するか、または試みるためにキーを使い果たすまでそれぞれの合っている公開鍵を試みることによって正しいかを決定できるだけです。
If the Labels field of the RRSIG RR is not equal to the number of labels in the RRset's fully qualified owner name, then the RRset is either invalid or the result of wildcard expansion. The resolver MUST verify that wildcard expansion was applied properly before considering the RRset to be authentic. Section 5.3.4 describes how to determine whether a wildcard was applied properly.
RRSIG RRのLabels分野がRRsetの完全に適切な所有者名のラベルの数と等しくないなら、RRsetはワイルドカード拡大の病人か結果のどちらかです。 レゾルバは、ワイルドカード拡大がRRsetが正統であると考える前に適切に適用されたことを確かめなければなりません。 セクション5.3 .4 ワイルドカードが適切に適用されたかどうか決定する方法を説明します。
If other RRSIG RRs also cover this RRset, the local resolver security policy determines whether the resolver also has to test these RRSIG RRs and how to resolve conflicts if these RRSIG RRs lead to differing results.
また、他のRRSIG RRsがこのRRsetを覆っているなら、これらのRRSIG RRsが異なった結果に通じるなら、ローカルのレゾルバ安全保障政策は、レゾルバがもこれらのRRSIG RRsをテストしなければならないかどうかと、どのように闘争を解決するかを決定します。
If the resolver accepts the RRset as authentic, the validator MUST set the TTL of the RRSIG RR and each RR in the authenticated RRset to a value no greater than the minimum of:
レゾルバが、RRsetが正統であると受け入れて、validatorがRRSIG RRのTTLを設定しなければならなくて、値への認証されたRRsetの各RRが以下の、より最小限を設定するなら
o the RRset's TTL as received in the response;
o 応答で受け取られるRRsetのTTL。
o the RRSIG RR's TTL as received in the response;
o 応答で受け取られるRRSIG RRのTTL。
o the value in the RRSIG RR's Original TTL field; and
o RRSIG RRのOriginal TTL分野の値。 そして
o the difference of the RRSIG RR's Signature Expiration time and the
current time.
o RRSIG RRのSignature Expiration時間と現在の時間の違い。
Arends, et al. Standards Track [Page 31] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[31ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
5.3.4. Authenticating a Wildcard Expanded RRset Positive Response
5.3.4. ワイルドカードを認証すると、RRsetの積極的な応答は広がりました。
If the number of labels in an RRset's owner name is greater than the Labels field of the covering RRSIG RR, then the RRset and its covering RRSIG RR were created as a result of wildcard expansion. Once the validator has verified the signature, as described in Section 5.3, it must take additional steps to verify the non- existence of an exact match or closer wildcard match for the query. Section 5.4 discusses these steps.
RRsetの所有者名のラベルの数が覆いRRSIG RRのLabels分野より大きいなら、RRsetとRRSIG RRを覆うのはワイルドカード拡大の結果、作成されました。 validatorがセクション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 RRsを含むべきであることに注意してください(セクション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.
レゾルバは、RRsetがサインされたゾーンに存在していないと立証するのに認証されたNSEC RRsを使用できます。 セキュリティ意識しているネームサーバはセキュリティ意識しているレゾルバへの彼らの応答に自動的にサインされたゾーンへのどんな必要なNSEC RRsも含むべきです。
Denial of existence is determined by the following rules:
存在の否定は以下の規則で決定します:
o If the requested RR name matches the owner name of an
authenticated NSEC RR, then the NSEC RR's type bit map field lists
all RR types present at that owner name, and a resolver can prove
that the requested RR type does not exist by checking for the RR
type in the bit map. If the number of labels in an authenticated
NSEC RR's owner name equals the Labels field of the covering RRSIG
RR, then the existence of the NSEC RR proves that wildcard
expansion could not have been used to match the request.
o 要求されたRR名が所有者名(認証されたNSEC RR)に合っているなら、NSEC RRのタイプビットマップ分野はその所有者名で出席しているすべてのRRタイプを記載します、そして、レゾルバは要求されたRRタイプがビットマップにRRタイプがないかどうかチェックすることによって存在しないと立証できます。 認証されたNSEC RRの所有者名のラベルの数が覆いRRSIG RRのLabels分野と等しいなら、NSEC RRの存在は、要求に合うのにワイルドカード拡大を使用できなかったと立証します。
o If the requested RR name would appear after an authenticated NSEC
RR's owner name and before the name listed in that NSEC RR's Next
Domain Name field according to the canonical DNS name order
defined in [RFC4034], then no RRsets with the requested name exist
in the zone. However, it is possible that a wildcard could be
used to match the requested RR owner name and type, so proving
that the requested RRset does not exist also requires proving that
no possible wildcard RRset exists that could have been used to
generate a positive response.
o 認証されたNSEC RRの所有者名の後と名前がそのNSEC RRのNext Domain Name分野に記載する前にオーダーという[RFC4034]で定義された正準なDNS名によると、要求されたRR名が現れるなら、要求された名前があるどんなRRsetsもゾーンに存在していません。 しかしながら、また、要求されたRRsetが存在しないと立証するのが積極的な応答を発生させるのに使用されたかもしれない可能なワイルドカードがないRRsetが存在すると立証するのを必要として、要求されたRR所有者名を合わせて、タイプするのにワイルドカードを使用できたのは可能です。
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 RRsetsを認証しなければなりません。
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
RRsetの非存在を立証するために、レゾルバは、質問されたRRsetがする両方が存在していなくて、関連ワイルドカードがないRRsetが存在することを確かめることができなければなりません。 これを立証するのは以上を必要とするかもしれません。
Arends, et al. Standards Track [Page 32] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[32ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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.
ゾーンからの1NSEC RRset。 必要なNSEC RRsetsの完全なセットが応答(恐らくメッセージトランケーションによる)で存在していないなら、セキュリティ意識しているレゾルバは、要求されたRRsetの非存在について確かめるのに必要なNSEC RRsの完全な収集を得るのを試みるために質問を再送しなければなりません。 しかしながら、すべてのDNS操作なら、レゾルバはバウンドしなければなりません。それがどんな特定の質問にも答えるのに入れる仕事。
Since a validated NSEC RR proves the existence of both itself and its corresponding RRSIG RR, a validator MUST ignore the settings of the NSEC and RRSIG bits in an NSEC RR.
有効にされたNSEC RRが、両方の存在がそれ自体とその対応するRRSIG RRであると立証するので、validatorはNSEC RRでNSECとRRSIGビットの設定を無視しなければなりません。
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.
いかなる理由でもRRSIGsのどれかを有効にすることができないで、応答はSHOULDです。BADであると考えられます。 反復クエリーを修理するために合法化していたなら、ネームサーバはRCODE2を由来しているクライアントに返さなければなりません。 そして、しかしながら、完全な応答を返さなければならない、オリジナルの質問にCDビットがあった場合にだけ、セットしてください。 また、それが有効にしない応答をキャッシュするとき、セクション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リソースレコードセットにサインして、認証するのにどう公開鍵暗号を使用するかを説明します。 用語と総合証券のために問題がDNSSECに関連したのを確実にしてください[RFC4033]。 DNSSECリソースレコード種類に特定の問題に関して[RFC4034]を見てください。
Arends, et al. Standards Track [Page 33] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[33ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
An active attacker who can set the CD bit in a DNS query message or the AD bit in a DNS response message can use these bits to defeat the protection that DNSSEC attempts to provide to security-oblivious recursive-mode resolvers. For this reason, use of these control bits by a security-aware recursive-mode resolver requires a secure channel. See Sections 3.2.2 and 4.9 for further discussion.
DNS質問メッセージにCDビットをはめ込むことができる活発な攻撃者かDNS応答メッセージにおけるADビットが、DNSSECがセキュリティ忘れっぽい再帰的なモードレゾルバに提供するのを試みる保護を破るのにこれらのビットを使用できます。 この理由で、セキュリティ意識している再帰的なモードレゾルバによるこれらのコントロールビットの使用は安全なチャンネルを必要とします。 さらなる議論に関してセクション3.2 .2と4.9を見てください。
The protocol described in this document attempts to extend the benefits of DNSSEC to security-oblivious stub resolvers. However, as recovery from validation failures is likely to be specific to particular applications, the facilities that DNSSEC provides for stub resolvers may prove inadequate. Operators of security-aware recursive name servers will have to pay close attention to the behavior of the applications that use their services when choosing a local validation policy; failure to do so could easily result in the recursive name server accidentally denying service to the clients it is intended to support.
本書では説明されたプロトコルは、セキュリティ忘れっぽいスタッブレゾルバにDNSSECの利益を与えるのを試みます。 しかしながら、合法化失敗からの回復が具体的に言うと特定用途にありそうであるので、DNSSECがスタッブレゾルバに提供する施設は不十分であると判明するかもしれません。 セキュリティ意識している再帰的なネームサーバのオペレータはローカルの合法化方針を選ぶとき彼らのサービスを利用するアプリケーションの働きへの周到な注意を支払わなければならないでしょう。 そうしない場合、容易に偶然支持することを意図するクライアントに対するサービスを否定する再帰的なネームサーバをもたらすかもしれません。
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 Extensions作業部会とワーキンググループメーリングリストのメンバーの入力と考えから作成されました。 エディタはこれらのセキュリティファイル拡張仕様書の改正の間に受領されたコメントと提案のために感謝したがっています。 明らかに10年間DNSSECが開発中であった貢献している皆を記載するのは不可能でしょうが、[RFC4033]は何人かのこれらのドキュメントを批評するほど親切であった関係者のリストを含んでいます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
Arends, et al. Standards Track [Page 34] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[34ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡大メカニズム」、RFC2671、1999年8月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999.
[RFC2672] クロフォード、M.、「非端末DNS名前リダイレクション」、RFC2672、1999年8月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001.
[RFC3225] コンラッド、D.、「DNSSECのレゾルバサポートを示します」、RFC3225、2001年12月。
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001.
[RFC3226] グドムンソン、O.、「DNSSECとIPv6 A6の意識しているサーバ/レゾルバメッセージサイズ要件」、RFC3226、2001年12月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for DNS Security Extensions", RFC
4034, March 2005.
[RFC4034]ArendsとR.とAusteinとR.とラーソンとM.とマッシー、D.とS.ローズ、「DNSセキュリティ拡張子のためのリソース記録」RFC4034(2005年3月)。
9.2. Informative References
9.2. 有益な参照
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2308] アンドリュース、M.、「DNS質問(DNS NCACHE)の否定的キャッシュ」、RFC2308、1998年3月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC2535] イーストレーク3番目、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、2000年11月のB.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3655] ウェリントンとB.とO.グドムンソン、「DNS Authenticated Data(AD)のRedefinitionは噛み付いた」RFC3655、2003年11月。
Arends, et al. Standards Track [Page 35] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[35ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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
例。 3600IN SOA ns1.example bugs.x.w.例。 ( 1081539377 3600 300 3600000 3600 ) 3600RRSIG SOA5 1 3600 20040509183619( 20040409183619 38519の例。 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) 3600NS ns1.example。 3600NS 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 Mx5 1 3600 20040509183619( 20040409183619 38519の例。 HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/不-W6OISukd1EQt7a0kygkg+PEDxdI=) 3600NSEC a.の例。 ナノ秒SOA Mx RRSIG nsec DNSKEY3600RRSIG nsec5 1 3600 20040509183619( 20040409183619 38519の例。 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U=) 3600 DNSKEY 256 3 5 ( AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
Arends, et al. Standards Track [Page 36] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[36ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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.
ySFNsgEYvh0z2542lzMKR4Dh8uZffQ=) 3600DNSKEY257 3 5(AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q=) 3600RRSIG DNSKEY5 1 3600 20040509183619( 20040409183619 9465の例。 ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY NC3AHfvCV1Tp4VKDqxqG7R5tTVM=) 3600RRSIG DNSKEY5 1 3600 20040509183619(20040409183619 38519の例eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk 7z5OXogYVaFzHKillDt3HRxHIZM=)a.の例。 3600年のIN NS ns1.a.の例。 3600年のIN NS ns2.a.の例。 3600DS57855 5 1(B6DCD485719ADCA18E5F3D48A2331627FDD3 636B) 3600 RRSIG DS 5 2 3600 20040509183619 ( 20040409183619 38519 example. oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) 3600NSEC ai.example。 NS DS RRSIG NSEC3600RRSIG NSEC5 2 3600 20040509183619(20040409183619 38519の例cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g sdkOW6Zyqtz3Zos8N0BBkEx+2G4=)ns1.a.の例。 3600 IN A192.0.2.5ns2.a.の例。 3600 IN A192.0.2.6ai.example。 3600年のIN A、192.0.2.9 3600RRSIG A5 2 3600 20040509183619 (20040409183619 38519の例。
Arends, et al. Standards Track [Page 37] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[37ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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
pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 6zrTpg9FkS0XGVmYRvOTNYx2HvQ=) 3600 HINFO「KLH-10インチ「ITS」3600RRSIG HINFO5 2 3600 20040509183619」( 20040409183619 38519の例。 Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw FvL8sqlS5QS6FY/ijFEDnI4RkZA=) 3600AAAA2001: db8:、:f00: baa9 3600RRSIG AAAA5 2 3600 20040509183619(20040409183619 38519の例nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 sZM6QjBBLmukH30+w1z3h8PUP2o=) 3600NSEC b.の例。 HINFO AAAA RRSIG nsec3600RRSIG nsec5 2 3600 20040509183619( 20040409183619 38519の例。 QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL AhS+JOVfDI/79QtyTI0SaDWcg8U=) b. 例。 3600年のIN NS ns1.b.の例。 3600年のIN NS ns2.b.の例。 3600NSEC ns1.example。 ナノ秒RRSIG nsec3600RRSIG nsec5 2 3600 20040509183619( 20040409183619 38519の例。 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE=) ns1.b.の例。 3600 IN A192.0.2.7ns2.b.の例。 3600 IN A192.0.2.8ns1.example。 3600年のIN A、192.0.2.1 3600RRSIG A5 2 3600 20040509183619 (20040409183619 38519の例。 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB++iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
Arends, et al. Standards Track [Page 38] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[38ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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
v/iVXSYC0b7mPSU+EOlknFpVECs=) 3600NSEC ns2.example。 RRSIG nsec3600RRSIG nsec5 2 3600 20040509183619( 20040409183619 38519の例。 I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 IZaIGBLryQWGLw6Y6X8dqhlnxJM=) ns2.example。 A192.0.2.2 3600RRSIG A5 2 3600 20040509183619における3600( 20040409183619 38519の例。 V7cQRw1兆+knlaL1z/psxlS1PcD37JJDaCMq Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq rdhx8SZ0yy4ObIRzIzvBFLiSS8o=) 3600年のnsec*.w.の例。 RRSIG nsec3600RRSIG nsec5 2 3600 20040509183619( 20040409183619 38519の例。 N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw Ymx28EtgIpo9A0qmP08rMBqs1Jw=) *.w.の例。 3600IN MX1ai.example。 3600 RRSIG Mx5 2 3600 20040509183619( 20040409183619 38519の例。 OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 4kX18MMR34i8lC36SR5xBni8vHI=) 3600年のNSECのx.w.例。 MX RRSIG NSEC3600RRSIG NSEC5 2 3600 20040509183619(20040409183619 38519の例r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 s1InQ2UoIv6tJEaaKkP701j8OLA=)のx.w.例。 3600IN MX1xx.example。 3600RRSIG MX5 3 3600 20040509183619、(20040409183619 38519の例。 Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/ Y1
Arends, et al. Standards Track [Page 39] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[39ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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/
jNSlwZ2mSWKHfxFQxPtLj8s32+k=) 3600NSEC x.のy.w.例。 MX RRSIG NSEC3600RRSIG NSEC5 3 3600 20040509183619(20040409183619 38519の例aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e IjgiM8PXkBQtxPq37wDKALkyn7Q=)x.のy.w.例。 3600IN MX1xx.example。 3600RRSIG MX5 4 3600 20040509183619(20040409183619 38519の例k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb+gLcMZBnHJ326nb/TOOmrqNmQQE=) 3600NSEC xx.example。 Mx RRSIG nsec3600RRSIG nsec5 4 3600 20040509183619( 20040409183619 38519の例。 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk=) xx.example。 3600 IN A192.0.2.10 3600RRSIG A5 2 3600 20040509183619(20040409183619 38519の例kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx kbIDV6GPPSZVusnZU6OMgdgzHV4=) 3600HINFO、「KLH-10インチは「3600RRSIG HINFO5 2 3600 20040509183619を-何20インチも上回っています」。( 20040409183619 38519の例。 GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+RgNvuwbioFSEuv2pNlkq0goYxNY=) 3600AAAA2001: db8:、:f00: baaa3600RRSIG AAAA5 2 3600 20040509183619、(20040409183619 38519の例。 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
Arends, et al. Standards Track [Page 40] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[40ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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= )
xS9cL2QgW7FChw16mzlkH6/vsfs=) 3600年のNSECの例。 HINFO AAAA RRSIG nsec3600RRSIG nsec5 2 3600 20040509183619( 20040409183619 38519の例。 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が設定する頂点は2DNSKEY RRsを含んでいます、そして、DNSKEY RDATA FlagsはそれぞれのこれらのDNSKEY RRsがゾーンキーであることを示します。 これらのDNSKEY RRsについても1つは、9月の旗を設定させて、頂点DNSKEY RRsetにサインするのに使用されました。 これは親ゾーンに挿入されるためにDS記録を発生させるように論じ尽くされるべきであるキーです。 もう片方のDNSKEYは、ゾーンで他のすべてのRRsetsにサインするのに使用されます。
The zone includes a wildcard entry, "*.w.example". Note that the name "*.w.example" is used in constructing NSEC chains, and that the RRSIG covering the "*.w.example" MX RRset has a label count of 2.
「ゾーンはワイルドカードエントリーを含んでいる」*.w.例、」 「それに注意してください、例という名前」 *.w.、」、NSECチェーン、およびそれを組み立てる中古のコネがRRSIG覆いである、」 」 *.w.例のMX RRsetには、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.の例」への代表団はNS RRset、接着剤アドレス記録、およびNSEC RRを含めます。 NSEC RRsetだけがサインされることに注意してください。 「a.の例」への代表団はDS RRを提供します。 NSECとDS RRsetsだけがサインされることに注意してください。
Appendix B. Example Responses
付録B.例の応答
The examples in this section show response messages using the signed zone example in Appendix A.
このセクションの例は、Appendix Aのサインされたゾーンの例を使用することで応答メッセージを示しています。
B.1. Answer
B.1。 答え
A successful query to an authoritative server.
正式のサーバへのうまくいっている質問。
;; Header: QR AA DO RCODE=0 ;; ;; Question x.w.example. IN MX
;; ヘッダー: QR AAはRCODE=0をします。 ;; x.w.例に質問してください。 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
;; x.w.例に答えてください。 3600IN MX1xx.example x. w. 例。 3600RRSIG MX5 3 3600 20040509183619、(20040409183619 38519の例Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
Arends, et al. Standards Track [Page 41] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[41ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
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= )
;; 権威の例。 3600NS ns1.example例。 3600NS ns2.example例。 3600RRSIGナノ秒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= )
;; 追加xx.example。 3600 IN A192.0.2.10xx.example。 3600 RRSIG A5 2 3600 20040509183619(20040409183619 38519の例kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx kbIDV6GPPSZVusnZU6OMgdgzHV4=)xx.example。 3600AAAA2001: db8:、:f00: baaa xx.example。 3600RRSIG AAAA5 2 3600 20040509183619( 20040409183619 38519の例。 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/xS9cL2QgW7FChw16mzlkH6/vsfs=) ns1.example。 3600 IN A192.0.2.1ns1.example。 3600 RRSIG A5 2 3600 20040509183619( 20040409183619 38519の例。 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB++iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK v/iVXSYC0b7mPSU+EOlknFpVECs=) ns2.example。 3600 IN A192.0.2.2ns2.example。 3600 RRSIG A5 2 3600 20040509183619( 20040409183619 38519の例。 V7cQRw1兆+knlaL1z/psxlS1PcD37JJDaCMq Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq rdhx8SZ0yy4ObIRzIzvBFLiSS8o=)
Arends, et al. Standards Track [Page 42] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[42ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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 RRsは名前が存在していなくて、また覆いワイルドカードが全く存在しないと立証します。
;; Header: QR AA DO RCODE=3 ;; ;; Question ml.example. IN A
;; ヘッダー: QR AAはRCODE=3をします。 ;; ミリリットルに質問してください。例。 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= )
;; 権威の例。 3600IN SOA ns1.example bugs.x.w.例。 ( 1081539377 3600 300 3600000 3600 ) 例。 3600RRSIG SOA5 1 3600 20040509183619( 20040409183619 38519の例。 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) b. 例。 3600NSEC ns1.example。 NS RRSIG NSEC b.の例。 3600RRSIG nsec5 2 3600 20040509183619( 20040409183619 38519の例。 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE=) 例。 3600NSEC a.の例。 NS SOA MX RRSIG NSEC DNSKEYの例。 3600RRSIG nsec5 1 3600 20040509183619( 20040409183619 38519の例。 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U=)
;; Additional ;; (empty)
;; 追加する。 (空)です。
Arends, et al. Standards Track [Page 43] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[43ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
B.3. No Data Error
B.3。 データ誤りがありません。
A "no data" response. The NSEC RR proves that the name exists and that the requested RR type does not.
「データがありません」応答。 NSEC RRは名前が存在していて、要求されたRRタイプがそうしないと立証します。
;; Header: QR AA DO RCODE=0 ;; ;; Question ns1.example. IN MX
;; ヘッダー: QR AAはRCODE=0をします。 ;; ns1.exampleに質問してください。 Mxで
;; Answer ;; (empty)
;; 答えてください。 (空)です。
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
;; 権威の例。 3600IN SOA ns1.example bugs.x.w.例。 ( 1081539377 3600 300 3600000 3600 ) 例。 3600RRSIG SOA5 1 3600 20040509183619( 20040409183619 38519の例。 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) ns1.example。 3600NSEC ns2.example。 RRSIG NSEC ns1.example。 3600RRSIG nsec5 2 3600 20040509183619( 20040409183619 38519の例。 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.
サインされたゾーンへの紹介。 DS RRはレゾルバが子供ゾーンの頂点で対応するDNSKEY RRを有効にするために必要とするデータを含んでいます。
;; Header: QR DO RCODE=0 ;;
;; ヘッダー: QRはRCODE=0をします。
Arends, et al. Standards Track [Page 44] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[44ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
;; Question mc.a.example. IN MX
;; mc.a.の例に質問してください。 Mxで
;; Answer ;; (empty)
;; 答えてください。 (空)です。
;; Authority
a.example. 3600 IN NS ns1.a.example.
a.example. 3600 IN NS ns2.a.example.
a.example. 3600 DS 57855 5 1 (
B6DCD485719ADCA18E5F3D48A2331627FDD3
636B )
a.example. 3600 RRSIG DS 5 2 3600 20040509183619 (
20040409183619 38519 example.
oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
;; 権威a.の例。 3600年のIN NS ns1.a.の例a. 例。 3600年のIN NS ns2.a.の例a. 例。 3600DS57855 5 1(B6DCD485719ADCA18E5F3D48A2331627FDD3 636B)a.の例。 3600RRSIG DS5 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
;; 追加ns1.a.の例。 3600 IN A192.0.2.5ns2.a.の例。 A192.0.2における3600、.6
B.5. Referral to Unsigned Zone
B.5。 無記名のゾーンへの紹介
Referral to an unsigned zone. The NSEC RR proves that no DS RR for this delegation exists in the parent zone.
無記名のゾーンへの紹介。 NSEC RRは、この代表団のためのどんなDS RRも親ゾーンに存在しないと立証します。
;; Header: QR DO RCODE=0 ;; ;; Question mc.b.example. IN MX
;; ヘッダー: QRはRCODE=0をします。 ;; mc.b.の例に質問してください。 Mxで
;; Answer ;; (empty)
;; 答えてください。 (空)です。
;; Authority
b.example. 3600 IN NS ns1.b.example.
b.example. 3600 IN NS ns2.b.example.
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
vhRXgWT7OuFXldoCG6TfVFMs9xE= )
;; 権威b.の例。 3600年のIN NS ns1.b.の例b. 例。 3600年のIN NS ns2.b.の例b. 例。 3600NSEC ns1.example。 NS RRSIG NSEC b.の例。 3600RRSIG nsec5 2 3600 20040509183619( 20040409183619 38519の例。 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE=)
Arends, et al. Standards Track [Page 45] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[45ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
;; Additional ns1.b.example. 3600 IN A 192.0.2.7 ns2.b.example. 3600 IN A 192.0.2.8
;; 追加ns1.b.の例。 3600 IN A192.0.2.7ns2.b.の例。 A192.0.2における3600、.8
B.6. Wildcard Expansion
B.6。 ワイルドカード拡大
A successful query that was answered via wildcard expansion. The label count in the answer's RRSIG RR indicates that a wildcard RRset was expanded to produce this response, and the NSEC RR proves that no closer match exists in the zone.
ワイルドカード拡大を通して答えられたうまくいっている質問。 答えのRRSIG RRでのラベルカウントは、ワイルドカードRRsetがこの応答を起こすために広げられたのを示します、そして、NSEC RRはどんなより近いマッチもゾーンに存在しないと立証します。
;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN MX
;; ヘッダー: QR AAはRCODE=0をします。 ;; a.のz.w.例に質問してください。 Mxで
;; Answer
a.z.w.example. 3600 IN MX 1 ai.example.
a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 (
20040409183619 38519 example.
OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
4kX18MMR34i8lC36SR5xBni8vHI= )
;; a.のz.w.例に答えてください。 3600IN MX1ai.example a. z. w. 例。 3600 RRSIG Mx5 2 3600 20040509183619( 20040409183619 38519の例。 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= )
;; 権威の例。 3600NS ns1.example例。 3600NS ns2.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. 3600NSEC xx.example。 MX RRSIG NSEC x.のy.w.例。 3600RRSIG nsec5 4 3600 20040509183619( 20040409183619 38519の例。 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk=)
;; Additional ai.example. 3600 IN A 192.0.2.9 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
;; 追加ai.example。 3600 IN A192.0.2.9ai.example。 3600RRSIG A5 2 3600 20040509183619、(
Arends, et al. Standards Track [Page 46] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[46ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
20040409183619 38519 example.
pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
ai.example. 3600 AAAA 2001:db8::f00:baa9
ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
20040409183619 38519 example.
nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
sZM6QjBBLmukH30+w1z3h8PUP2o= )
20040409183619 38519の例pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 6zrTpg9FkS0XGVmYRvOTNYx2HvQ=) ai.example。 3600AAAA2001: db8:、:f00: baa9 ai.example。 3600RRSIG AAAA5 2 3600 20040509183619(20040409183619 38519の例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 RRsは合っているワイルドカード名には要求されたタイプの少しのRRsもなくて、またどんなより近いマッチもゾーンに存在しないと立証します。
;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN AAAA
;; ヘッダー: QR AAはRCODE=0をします。 ;; a.のz.w.例に質問してください。 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
;; 権威の例。 3600IN SOA ns1.example bugs.x.w.例。 ( 1081539377 3600 300 3600000 3600 ) 例。 3600RRSIG SOA5 1 3600 20040509183619( 20040409183619 38519の例。 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) x. y. w. 例。 3600NSEC xx.example。 MX RRSIG NSEC x.のy.w.例。 3600RRSIG NSEC5 4 3600 20040509183619、(20040409183619 38519の例OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
Arends, et al. Standards Track [Page 47] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[47ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
*.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
*.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
s1InQ2UoIv6tJEaaKkP701j8OLA= )
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk=) *.w.の例。 3600年のNSECのx.w.例。 Mx RRSIG nsec*.w.の例。 3600RRSIG nsec5 2 3600 20040509183619(20040409183619 38519の例r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 s1InQ2UoIv6tJEaaKkP701j8OLA=)
;; Additional ;; (empty)
;; 追加する。 (空)です。
B.8. DS Child Zone No Data Error
B.8。 DS子供ゾーンいいえデータ誤り
A "no data" response for a QTYPE=DS query that was mistakenly sent to a name server for the child zone.
QTYPE=DSがそれについて質問するので、子供ゾーンのために「データがありません」応答をネームサーバに誤って送りました。
;; Header: QR AA DO RCODE=0 ;; ;; Question example. IN DS
;; ヘッダー: QR AAはRCODE=0をします。 ;; 例に質問してください。 DSで
;; Answer ;; (empty)
;; 答えてください。 (空)です。
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
20040409183619 38519 example.
O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
;; 権威の例。 3600IN SOA ns1.example bugs.x.w.例。 ( 1081539377 3600 300 3600000 3600 ) 例。 3600RRSIG SOA5 1 3600 20040509183619( 20040409183619 38519の例。 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) 例。 3600NSEC a.の例。 NS SOA MX RRSIG NSEC DNSKEYの例。 3600RRSIG NSEC5 1 3600 20040509183619、(20040409183619 38519の例O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
Arends, et al. Standards Track [Page 48] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[48ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
jfFJ5arXf4nPxp/kEowGgBRzY/U= )
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.
このセクションの例はAppendix 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.
Appendix B.1での質問は「x.w.example.com」のためにMX RRsetを返しました。 対応するRRSIGは、MX RRsetがアルゴリズム5とキー・タグ38519で「例」DNSKEYによってサインされたのを示します。 レゾルバは、この答えを認証するために対応するDNSKEY RRを必要とします。 以下での議論はレゾルバがどうこのDNSKEY RRを入手するかもしれないかを説明します。
The RRSIG indicates the original TTL of the MX RRset was 3600, and, for the purpose of authentication, the current TTL is replaced by 3600. The RRSIG labels field value of 3 indicates that the answer was not the result of wildcard expansion. The "x.w.example.com" MX RRset is placed in canonical form, and, assuming the current time falls between the signature inception and expiration dates, the signature is authenticated.
RRSIGは、MX RRsetのオリジナルのTTLが3600であったのを示します、そして、認証の目的のために、3600年までに現在のTTLを取り替えます。 RRSIGは3の値が示す答えがあった分野をワイルドカード拡大のいずれの結果ともラベルしません。 「x.w.example.com」MX RRsetは標準形に置かれます、そして、現在の時間が署名始まりと有効期限の間に下がると仮定して、署名は認証されます。
C.1.1. Authenticating the Example DNSKEY RR
C.1.1。 例のDNSKEY RRを認証します。
This example shows the logical authentication process that starts from the a configured root DNSKEY (or DS RR) and moves down the tree to authenticate the desired "example" DNSKEY RR. Note that the logical order is presented for clarity. An implementation may choose to construct the authentication as referrals are received or to construct the authentication chain only after all RRsets have been obtained, or in any other combination it sees fit. The example here demonstrates only the logical process and does not dictate any implementation rules.
この例は、aからの始めが根のDNSKEY(または、DS RR)を構成したのを論理的な認証過程に示して、必要な「例」DNSKEY RRを認証するために木を下げます。 論理的順序が明快ために提示されることに注意してください。 実現は、紹介が受け取られているか、結局だけ認証チェーンを組み立てるためにRRsetsを入手した、またはそれが適していると決めるいかなる他の組み合わせにおける認証も構成するのを選ぶかもしれません。 ここの例は、論理的な過程だけを示して、どんな実現規則も決めません。
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
私たちは、レゾルバがルートゾーン(または、ルートゾーンへの構成されたDS RR)に構成されたDNSKEY RRから始まると思います。 レゾルバは、根のDNSKEY RRset(DS RRが根のDNSKEY RRsetのいくらかのDNSKEYに合っているか否かに関係なく)でこの構成されたDNSKEY RRが存在しているかどうかチェックします、このDNSKEY RRが根のDNSKEY RRsetにサインして、署名寿命が有効であるか否かに関係なく。 これらです。
Arends, et al. Standards Track [Page 49] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[49ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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 RRsetのすべてのキーが認証されていると考えられます。 そして、レゾルバは、「例」DS RRsetを認証するのに、根のDNSKEY RRsの1つ(さらに)を使用します。 レゾルバが根のDNSKEY RRsetか「例」DS RRsetを入手するためにルートゾーンについて質問しなければならないかもしれないことに注意してください。
Once the DS RRset has been authenticated using the root DNSKEY, the resolver checks the "example" DNSKEY RRset for some "example" DNSKEY RR that matches one of the authenticated "example" DS RRs. If such a matching "example" DNSKEY is found, the resolver checks whether this DNSKEY RR has signed the "example" DNSKEY RRset and the signature lifetime is valid. If these conditions are met, all keys in the "example" DNSKEY RRset are considered authenticated.
DS RRsetが根のDNSKEYを使用することでいったん認証されると、レゾルバは認証された「例」DS RRsの1つに合っているいくらかの「例」DNSKEY RRがないかどうか「例」DNSKEY RRsetをチェックします。 そのような合っている「例」DNSKEYが見つけられるなら、レゾルバは、このDNSKEY RRが「例」DNSKEY RRsetにサインしたかどうかチェックします、そして、署名寿命は有効です。 これらの条件が満たされるなら、「例」DNSKEY RRsetのすべてのキーが認証されていると考えられます。
Finally, the resolver checks that some DNSKEY RR in the "example" DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY is used to authenticate the RRSIG included in the response. If multiple "example" DNSKEY RRs match this algorithm and key tag, then each DNSKEY RR is tried, and the answer is authenticated if any of the matching DNSKEY RRs validate the signature as described above.
最終的に、レゾルバは、「例」DNSKEY RRsetのいくらかのDNSKEY RRがアルゴリズム5を使用して、38519のキー・タグを持っているのをチェックします。 このDNSKEYは、応答に含まれていたRRSIGを認証するのに使用されます。 複数の「例」DNSKEY RRsがこのアルゴリズムとキー・タグに合っているなら、それぞれのDNSKEY RRは試験済みです、そして、合っているDNSKEY RRsのどれかが上で説明されるように署名を有効にするなら、答えは認証されます。
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.
Appendix B.2での質問は要求されたデータが存在していなくて、またワイルドカードが全く適用されないと立証するNSEC RRsを返しました。 否定的な返事は、両方のNSEC RRsについて確かめることによって、認証されます。 NSEC RRsは上で議論したMX RRsetのものと同じ方法で認証されます。
C.3. No Data Error
C.3。 データ誤りがありません。
The query in Appendix B.3 returned an NSEC RR that proves that the requested name exists, but the requested RR type does not exist. The negative reply is authenticated by verifying the NSEC RR. The NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above.
Appendix B.3での質問は要求された名前が存在していますが、要求されたRRタイプが存在しないと立証するNSEC RRを返しました。 否定的な返事は、NSEC RRについて確かめることによって、認証されます。 NSEC RRは上で議論したMX RRsetのものと同じ方法で認証されます。
C.4. Referral to Signed Zone
C.4。 サインされたゾーンへの紹介
The query in Appendix B.4 returned a referral to the signed "a.example." zone. The DS RR is authenticated in a manner identical to that of the MX RRset discussed above. This DS RR is used to authenticate the "a.example" DNSKEY RRset.
Appendix B.4での質問はサインされた「a.の例」に紹介を返しました。帯状になってください。 DS RRは上で議論したMX RRsetのものと同じ方法で認証されます。 このDS RRは、「a.の例」DNSKEY RRsetを認証するのに使用されます。
Once the "a.example" DS RRset has been authenticated using the "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset for some "a.example" DNSKEY RR that matches the DS RR. If such a matching "a.example" DNSKEY is found, the resolver checks whether
「a.の例」DS RRsetが「例」DNSKEYを使用することでいったん認証されると、レゾルバはDS RRに合っているいくらかの「a.の例」DNSKEY RRがないかどうか「a.の例」DNSKEY RRsetをチェックします。 そのような合っている「a.の例」DNSKEYが見つけられるなら、レゾルバはチェックします。
Arends, et al. Standards Track [Page 50] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[50ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
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.
このDNSKEY RRはサインしました。「a.の例」DNSKEY RRsetであって署名寿命は有効であるかどうか これらのすべての条件が満たされるなら、「a.の例」DNSKEY RRsetのすべてのキーが認証されていると考えられます。
C.5. Referral to Unsigned Zone
C.5。 無記名のゾーンへの紹介
The query in Appendix B.5 returned a referral to an unsigned "b.example." zone. The NSEC proves that no authentication leads from "example" to "b.example", and the NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above.
Appendix B.5での質問は無記名の「b.の例」に紹介を返しました。帯状になってください。 NSECは、認証が全く「例」から「b.の例」まで導かないと立証します、そして、NSEC RRは上で議論したMX RRsetのものと同じ方法で認証されます。
C.6. Wildcard Expansion
C.6。 ワイルドカード拡大
The query in Appendix B.6 returned an answer that was produced as a result of wildcard expansion. The answer section contains a wildcard RRset expanded as it would be in a traditional DNS response, and the corresponding RRSIG indicates that the expanded wildcard MX RRset was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG indicates that the original TTL of the MX RRset was 3600, and, for the purpose of authentication, the current TTL is replaced by 3600. The RRSIG labels field value of 2 indicates that the answer is the result of wildcard expansion, as the "a.z.w.example" name contains 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset is placed in canonical form, and, assuming that the current time falls between the signature inception and expiration dates, the signature is authenticated.
Appendix B.6での質問はワイルドカード拡大の結果、起こされた答えを返しました。 それが伝統的なDNS応答であるように答え部はRRsetが広げたワイルドカードを含みます、そして、対応するRRSIGは拡張ワイルドカードMX RRsetがアルゴリズム5とキー・タグ38519で「例」DNSKEYによってサインされたのを示します。 RRSIGは、MX RRsetのオリジナルのTTLが3600であったのを示します、そして、認証の目的のために、3600年までに現在のTTLを取り替えます。 RRSIGは2の値が示す答えがある分野をワイルドカード拡大の結果とラベルします、「a.のz.w.例」名が4個のラベルを含むとき。 MX RRsetは標準形に置かれます、そして、「名前「a.z.w.w.の例」を」 *.w.例に取り替え」て、現在の時間が署名始まりと有効期限の間に下がると仮定して、署名は認証されます。
The NSEC proves that no closer match (exact or closer wildcard) could have been used to answer this query, and the NSEC RR must also be authenticated before the answer is considered valid.
NSECは、この質問に答えるのに、どんなより近いマッチ(正確であるか、より近いワイルドカード)も使用できなかったと立証します、そして、また、答えが有効であると考えられる前にNSEC RRを認証しなければなりません。
C.7. Wildcard No Data Error
C.7。 ワイルドカードいいえデータ誤り
The query in Appendix B.7 returned NSEC RRs that prove that the requested data does not exist and no wildcard applies. The negative reply is authenticated by verifying both NSEC RRs.
Appendix B.7での質問は要求されたデータが存在していなくて、またワイルドカードが全く適用されないと立証するNSEC RRsを返しました。 否定的な返事は、両方のNSEC RRsについて確かめることによって、認証されます。
C.8. DS Child Zone No Data Error
C.8。 DS子供ゾーンいいえデータ誤り
The query in Appendix B.8 returned NSEC RRs that shows the requested
was answered by a child server ("example" server). The NSEC RR
indicates the presence of an SOA RR, showing that the answer is from
the child . Queries for the "example" DS RRset should be sent to the
parent servers ("root" servers).
Appendix B.8での質問は答えられた子供サーバ(「例」サーバ)でそれが要求に示すNSEC RRsを返しました。 NSEC RRはSOA RRの存在を示します、答えが子供から来ているのを示して。親サーバ(「根」サーバ)に「例」DS RRsetのための質問を送るべきです。
Arends, et al. Standards Track [Page 51] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[51ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
Authors' Addresses
作者のアドレス
Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL
ロイArends Telematica Instituut Brouwerijstraat1 7523XCエンスヘーデNL
EMail: roy.arends@telin.nl
メール: roy.arends@telin.nl
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブAusteinインターネットSystems共同体950憲章通りカリフォルニア94063レッドウッドシティー(米国)
EMail: sra@isc.org
メール: sra@isc.org
Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
マットラーソンベリサインInc.21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
EMail: mlarson@verisign.com
メール: mlarson@verisign.com
Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873
ダン・マッシー・コロラド州立大学コンピュータサイエンス学部フォートコリンズ、CO80523-1873
EMail: massey@cs.colostate.edu
メール: massey@cs.colostate.edu
Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA
スコットRoseの規格の国家の研究所と技術100事務局Drive MD20899-8920ゲイザースバーグ(米国)
EMail: scott.rose@nist.gov
メール: scott.rose@nist.gov
Arends, et al. Standards Track [Page 52] RFC 4035 DNSSEC Protocol Modifications March 2005
Arends、他 標準化過程[52ページ]RFC4035DNSSECは2005年の変更行進のときに議定書を作ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Arends, et al. Standards Track [Page 53]
Arends、他 標準化過程[53ページ]
一覧
スポンサーリンク
