Network Working Group R. Arends
Request for Comments: 4033 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
DNS Security Introduction and Requirements
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC.
ドメインネームシステムセキュリティ拡張機能（DNSSEC）は、ドメインネームシステムにデータ発信元認証とデータ整合性を追加します。 このドキュメントでは、これらの拡張機能を紹介し、その機能と制限について説明します。 このドキュメントでは、DNSセキュリティ拡張機能が提供するサービスと提供しないサービスについても説明します。 最後に、このドキュメントでは、DNSSECをまとめて説明するドキュメント間の相互関係について説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 3
3. Services Provided by DNS Security . . . . . . . . . . . . . 7
3.1. Data Origin Authentication and Data Integrity . . . . 7
3.2. Authenticating Name and Type Non-Existence . . . . . . 9
4. Services Not Provided by DNS Security . . . . . . . . . . . 9
5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . 9
6. Resolver Considerations . . . . . . . . . . . . . . . . . . 10
7. Stub Resolver Considerations . . . . . . . . . . . . . . . . 11
8. Zone Considerations . . . . . . . . . . . . . . . . . . . . 12
8.1. TTL Values vs. RRSIG Validity Period . . . . . . . . . 13
8.2. New Temporal Dependency Issues for Zones . . . . . . . 13
9. Name Server Considerations . . . . . . . . . . . . . . . . . 13
10. DNS Security Document Family . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21
This document introduces the Domain Name System Security Extensions (DNSSEC). This document and its two companion documents ([RFC4034] and [RFC4035]) update, clarify, and refine the security extensions defined in [RFC2535] and its predecessors. These security extensions consist of a set of new resource record types and modifications to the existing DNS protocol ([RFC1035]). The new records and protocol modifications are not fully described in this document, but are described in a family of documents outlined in Section 10. Sections 3 and 4 describe the capabilities and limitations of the security extensions in greater detail. Section 5 discusses the scope of the document set. Sections 6, 7, 8, and 9 discuss the effect that these security extensions will have on resolvers, stub resolvers, zones, and name servers.
このドキュメントでは、ドメインネームシステムセキュリティ拡張（DNSSEC）を紹介しています。 このドキュメントとその2つの付属ドキュメント（[RFC4034]および[RFC4035]）は、[RFC2535]およびその先行バージョンで定義されているセキュリティ拡張機能を更新、明確化、および改良します。 これらのセキュリティ拡張機能は、一連の新しいリソースレコードタイプと既存のDNSプロトコル（[RFC1035]）への変更で構成されます。 新しいレコードとプロトコルの変更については、このドキュメントでは完全に説明していませんが、セクション10で概説したドキュメントファミリで説明しています。セクション3と4では、セキュリティ拡張の機能と制限について詳しく説明します。 セクション5では、ドキュメントセットの範囲について説明します。 セクション6、7、8、および9では、これらのセキュリティ拡張機能がリゾルバ、スタブリゾルバ、ゾーン、およびネームサーバーに与える影響について説明します。
This document and its two companions obsolete [RFC2535], [RFC3008], [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and [RFC3845]. This document set also updates but does not obsolete [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225], [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with DNSSEC.
このドキュメントとその2つのコンパニオンは、[RFC2535]、[RFC3008]、[RFC3090]、[RFC3445]、[RFC3655]、[RFC3658]、[RFC3755]、[RFC3757]、および[RFC3845]を廃止します。 このドキュメントセットも更新されますが、[RFC1034]、[RFC1035]、[RFC2136]、[RFC2181]、[RFC2308]、[RFC3225]、[RFC3007]、[RFC3597]、および[RFC3226]の一部は廃止されません。 DNSSECを使用。
The DNS security extensions provide origin authentication and integrity protection for DNS data, as well as a means of public key distribution. These extensions do not provide confidentiality.
DNSセキュリティ拡張機能は、DNSデータの発信元認証と整合性保護、および公開キー配布の手段を提供します。 これらの拡張機能は機密性を提供しません。
This section defines a number of terms used in this document set. Because this is intended to be useful as a reference while reading the rest of the document set, first-time readers may wish to skim this section quickly, read the rest of this document, and then come back to this section.
このセクションでは、このドキュメントセットで使用される多くの用語を定義します。 これはドキュメントセットの残りの部分を読む際の参照として役立つことを目的としているため、初めて読む人はこのセクションをすばやく読み、このドキュメントの残りの部分を読んでからこのセクションに戻ってください。
Authentication Chain: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of signed data, with each link in the chain vouching for the next. A DNSKEY RR is used to verify the signature covering a DS RR and allows the DS RR to be authenticated. The DS RR contains a hash of another DNSKEY RR and this new DNSKEY RR is authenticated by matching the hash in the DS RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in this set may be used to authenticate another DS RR, and so forth until the chain finally ends with a DNSKEY RR whose corresponding private key signs the desired DNS data. For example, the root DNSKEY RRset can be used to authenticate the DS RRset for "example." The "example." DS RRset contains a hash that matches some "example." DNSKEY, and this DNSKEY's corresponding private key signs the "example." DNSKEY RRset. Private key counterparts of the "example." DNSKEY RRset sign data records such as "www.example." and DS RRs for delegations such as "subzone.example."
認証チェーン：DNS公開キー（DNSKEY）RRsetと委任署名者（DS）RRsetの交互のシーケンスは、チェーン内の各リンクが次を保証して、署名付きデータのチェーンを形成します。 DNSKEY RRは、DS RRをカバーする署名の検証に使用され、DS RRの認証を許可します。 DS RRには別のDNSKEY RRのハッシュが含まれており、この新しいDNSKEY RRはDS RR内のハッシュと一致することにより認証されます。この新しいDNSKEY RRは、別のDNSKEY RRsetを認証し、このセットの一部のDNSKEY RRは、別のDS RRの認証に使用されます。チェーンは、対応する秘密キーが目的のDNSに署名するDNSKEY RRで最終的に終了するまで続きます。データ。たとえば、ルートDNSKEY RRsetを使用して、「example」のDS RRsetを認証できます。例。" DS RRsetには、「例」に一致するハッシュが含まれています。 DNSKEY、およびこのDNSKEYの対応する秘密キーは「例」に署名します。 DNSKEY RRset。 「例」に対応する秘密鍵DNSKEY RRは、「www.example」などのデータレコードに署名します。 「subzone.example」などの委任のDS RR
Authentication Key: A public key that a security-aware resolver has verified and can therefore use to authenticate data. A security-aware resolver can obtain authentication keys in three ways. First, the resolver is generally configured to know about at least one public key; this configured data is usually either the public key itself or a hash of the public key as found in the DS RR (see "trust anchor"). Second, the resolver may use an authenticated public key to verify a DS RR and the DNSKEY RR to which the DS RR refers. Third, the resolver may be able to determine that a new public key has been signed by the private key corresponding to another public key that the resolver has verified. Note that the resolver must always be guided by local policy when deciding whether to authenticate a new public key, even if the local policy is simply to authenticate any new public key for which the resolver is able verify the signature.
認証キー：セキュリティ対応リゾルバーが検証したため、データの認証に使用できる公開キー。 セキュリティ対応リゾルバは、3つの方法で認証キーを取得できます。 最初に、リゾルバは一般に、少なくとも1つの公開鍵について知るように構成されます。 この構成されたデータは通常、公開鍵自体か、DS RRで見つかった公開鍵のハッシュです（「トラストアンカー」を参照）。 次に、リゾルバは認証された公開鍵を使用して、DS RRと、DS RRが参照するDNSKEY RRを検証します。 第三に、リゾルバは、リゾルバが検証した別の公開鍵に対応する秘密鍵によって新しい公開鍵が署名されたことを判断できる場合があります。 リゾルバーが署名を検証できる新しい公開キーを単にローカルポリシーで認証する場合でも、新しい公開キーを認証するかどうかを決定するときは、リゾルバーは常にローカルポリシーに従っている必要があることに注意してください。
Authoritative RRset: Within the context of a particular zone, an RRset is "authoritative" if and only if the owner name of the RRset lies within the subset of the name space that is at or below the zone apex and at or above the cuts that separate the zone from its children, if any. All RRsets at the zone apex are authoritative, except for certain RRsets at this domain name that, if present, belong to this zone's parent. These RRset could include a DS RRset, the NSEC RRset referencing this DS RRset (the "parental NSEC"), and RRSIG RRs associated with these RRsets, all of which are authoritative in the parent zone. Similarly, if this zone contains any delegation points, only the parental NSEC RRset, DS RRsets, and any RRSIG RRs associated with these RRsets are authoritative for this zone.
権限のあるRRset：特定のゾーンのコンテキスト内で、RRsetの所有者名がゾーンの頂点以下およびカット以上の名前空間のサブセット内にある場合にのみ、RRsetは「権限あり」です。 ゾーンをその子から分離します（ある場合）。 ゾーンの頂点にあるすべてのRRsetは権限がありますが、このドメイン名にある特定のRRsetは、存在する場合はこのゾーンの親に属します。 これらのRRsetには、DS RRset、このDS RRsetを参照するNSEC RRset（「親NSEC」）、およびこれらのRRsetに関連付けられたRRSIG RRを含めることができます。これらはすべて親ゾーンで権限があります。 同様に、このゾーンに委任ポイントが含まれる場合、親のNSEC RRset、DS RRset、およびこれらのRRsetに関連付けられたRRSIG RRのみがこのゾーンに対して権限があります。
Delegation Point: Term used to describe the name at the parental side of a zone cut. That is, the delegation point for "foo.example" would be the foo.example node in the "example" zone (as opposed to the zone apex of the "foo.example" zone). See also zone apex.
委任ポイント：ゾーンカットの親側の名前を説明するために使用される用語。 つまり、「foo.example」の委任ポイントは、「example」ゾーンのfoo.exampleノードになります（「foo.example」ゾーンのゾーン頂点とは対照的です）。 ゾーン頂点も参照してください。
Island of Security: Term used to describe a signed, delegated zone that does not have an authentication chain from its delegating parent. That is, there is no DS RR containing a hash of a DNSKEY RR for the island in its delegating parent zone (see [RFC4034]). An island of security is served by security-aware name servers and may provide authentication chains to any delegated child zones. Responses from an island of security or its descendents can only be authenticated if its authentication keys can be authenticated by some trusted means out of band from the DNS protocol.
セキュリティの島：委任する親からの認証チェーンを持たない署名された委任されたゾーンを表すために使用される用語。 つまり、委任する親ゾーンにはアイランドのDNSKEY RRのハッシュを含むDS RRはありません（[RFC4034]を参照）。 セキュリティのアイランドは、セキュリティ対応のネームサーバーによって提供され、委任された子ゾーンに認証チェーンを提供できます。 セキュリティアイランドまたはその子孫からの応答は、その認証キーがDNSプロトコルから帯域外の信頼できる手段によって認証できる場合にのみ認証できます。
Key Signing Key (KSK): An authentication key that corresponds to a private key used to sign one or more other authentication keys for a given zone. Typically, the private key corresponding to a key signing key will sign a zone signing key, which in turn has a corresponding private key that will sign other zone data. Local policy may require that the zone signing key be changed frequently, while the key signing key may have a longer validity period in order to provide a more stable secure entry point into the zone. Designating an authentication key as a key signing key is purely an operational issue: DNSSEC validation does not distinguish between key signing keys and other DNSSEC authentication keys, and it is possible to use a single key as both a key signing key and a zone signing key. Key signing keys are discussed in more detail in [RFC3757]. Also see zone signing key.
キー署名キー（KSK）：特定のゾーンの1つ以上の他の認証キーに署名するために使用される秘密キーに対応する認証キー。 通常、キー署名キーに対応する秘密キーはゾーン署名キーに署名します。ゾーン署名キーには、他のゾーンデータに署名する対応する秘密キーがあります。 ローカルポリシーでは、ゾーンへのより安定した安全なエントリポイントを提供するために、キー署名キーの有効期間を長くする一方で、ゾーン署名キーの頻繁な変更が必要になる場合があります。 認証キーをキー署名キーとして指定することは、純粋に運用上の問題です。DNSSEC検証では、キー署名キーと他のDNSSEC認証キーを区別せず、単一のキーをキー署名キーとゾーン署名キーの両方として使用できます 。 キー署名キーについては、[RFC3757]で詳細に説明されています。 ゾーン署名キーも参照してください。
Non-Validating Security-Aware Stub Resolver: A security-aware stub resolver that trusts one or more security-aware recursive name servers to perform most of the tasks discussed in this document set on its behalf. In particular, a non-validating security-aware stub resolver is an entity that sends DNS queries, receives DNS responses, and is capable of establishing an appropriately secured channel to a security-aware recursive name server that will provide these services on behalf of the security-aware stub resolver. See also security-aware stub resolver, validating security-aware stub resolver.
非検証セキュリティ対応スタブリゾルバー：1つ以上のセキュリティ対応再帰ネームサーバーを信頼して、このドキュメントセットで説明するタスクのほとんどを実行するセキュリティ対応スタブリゾルバー。 特に、検証されていないセキュリティ対応スタブリゾルバは、DNSクエリを送信し、DNS応答を受信し、これらのサービスを提供するセキュリティ対応再帰ネームサーバーへの適切に保護されたチャネルを確立できるエンティティです。 セキュリティ対応のスタブリゾルバ。 セキュリティ対応スタブリゾルバ、セキュリティ対応スタブリゾルバの検証も参照してください。
Non-Validating Stub Resolver: A less tedious term for a non-validating security-aware stub resolver.
非検証スタブリゾルバー：非検証セキュリティ対応スタブリゾルバーの退屈な用語。
Security-Aware Name Server: An entity acting in the role of a name server (defined in section 2.4 of [RFC1034]) that understands the DNS security extensions defined in this document set. In particular, a security-aware name server is an entity that receives DNS queries, sends DNS responses, supports the EDNS0 ([RFC2671]) message size extension and the DO bit ([RFC3225]), and supports the RR types and message header bits defined in this document set.
セキュリティ対応ネームサーバー：このドキュメントセットで定義されているDNSセキュリティ拡張機能を理解するネームサーバー（[RFC1034]のセクション2.4で定義）の役割で動作するエンティティ。 特に、セキュリティ対応のネームサーバーは、DNSクエリを受信し、DNS応答を送信し、EDNS0（[RFC2671]）メッセージサイズ拡張とDOビット（[RFC3225]）をサポートし、RRタイプとメッセージヘッダーをサポートするエンティティです。 このドキュメントセットで定義されているビット。
Security-Aware Recursive Name Server: An entity that acts in both the security-aware name server and security-aware resolver roles. A more cumbersome but equivalent phrase would be "a security-aware name server that offers recursive service".
セキュリティ対応の再帰ネームサーバー：セキュリティ対応ネームサーバーとセキュリティ対応リゾルバーの両方の役割で機能するエンティティ。 より扱いにくいが同等のフレーズは、「再帰サービスを提供するセキュリティ対応のネームサーバー」です。
Security-Aware Resolver: An entity acting in the role of a resolver (defined in section 2.4 of [RFC1034]) that understands the DNS security extensions defined in this document set. In particular, a security-aware resolver is an entity that sends DNS queries, receives DNS responses, supports the EDNS0 ([RFC2671]) message size extension and the DO bit ([RFC3225]), and is capable of using the RR types and message header bits defined in this document set to provide DNSSEC services.
セキュリティ対応リゾルバ：このドキュメントセットで定義されているDNSセキュリティ拡張機能を理解するリゾルバ（[RFC1034]のセクション2.4で定義）の役割で動作するエンティティ。 特に、セキュリティ対応のリゾルバーは、DNSクエリを送信し、DNS応答を受信し、EDNS0（[RFC2671]）メッセージサイズ拡張とDOビット（[RFC3225]）をサポートし、RRタイプと DNSSECサービスを提供するためにこのドキュメントセットで定義されているメッセージヘッダービット。
Security-Aware Stub Resolver: An entity acting in the role of a stub resolver (defined in section 5.3.1 of [RFC1034]) that has enough of an understanding the DNS security extensions defined in this document set to provide additional services not available from a security-oblivious stub resolver. Security-aware stub resolvers may be either "validating" or "non-validating", depending on whether the stub resolver attempts to verify DNSSEC signatures on its own or trusts a friendly security-aware name server to do so. See also validating stub resolver, non-validating stub resolver.
セキュリティ対応スタブリゾルバ：スタブリゾルバの役割で動作するエンティティ（[RFC1034]のセクション5.3.1で定義）。このドキュメントセットで定義されているDNSセキュリティ拡張機能を十分に理解し、利用できない追加サービスを提供します。 セキュリティを意識しないスタブリゾルバ。 セキュリティ対応のスタブリゾルバは、DNSSEC署名を独自に検証しようとするか、フレンドリなセキュリティ対応ネームサーバーを信頼するかによって、「検証」または「非検証」のいずれかになります。 検証スタブリゾルバ、非検証スタブリゾルバも参照してください。
Security-Oblivious <anything>: An <anything> that is not "security-aware".
Security-Oblivious <anything>：「security-aware」ではない<anything>。
Signed Zone: A zone whose RRsets are signed and that contains properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC), and (optionally) DS records.
署名済みゾーン：RRsetが署名され、適切に構築されたDNSKEY、リソースレコード署名（RRSIG）、Next Secure（NSEC）、および（オプションで）DSレコードを含むゾーン。
Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response. In general, a validating resolver will have to obtain the initial values of its trust anchors via some secure or trusted means outside the DNS protocol. Presence of a trust anchor also implies that the resolver should expect the zone to which the trust anchor points to be signed.
トラストアンカー：DNSKEY RRの構成済みDNSKEY RRまたはDS RRハッシュ。 検証セキュリティ対応リゾルバーは、この公開キーまたはハッシュを、署名付きDNS応答への認証チェーンを構築するための開始点として使用します。 一般に、検証リゾルバは、DNSプロトコルの外部の安全な手段または信頼できる手段を介して、トラストアンカーの初期値を取得する必要があります。 トラストアンカーの存在は、リゾルバーがトラストアンカーが指すゾーンに署名されることを期待することも意味します。
Unsigned Zone: A zone that is not signed.
署名されていないゾーン：署名されていないゾーン。
Validating Security-Aware Stub Resolver: A security-aware resolver that sends queries in recursive mode but that performs signature validation on its own rather than just blindly trusting an upstream security-aware recursive name server. See also security-aware stub resolver, non-validating security-aware stub resolver.
セキュリティ対応スタブリゾルバーの検証：クエリを再帰モードで送信するが、上流のセキュリティ対応再帰ネームサーバーを盲目的に信頼するのではなく、独自に署名検証を実行するセキュリティ対応リゾルバー。 セキュリティ対応スタブリゾルバ、検証なしセキュリティ対応スタブリゾルバも参照してください。
Validating Stub Resolver: A less tedious term for a validating security-aware stub resolver.
検証スタブリゾルバー：検証セキュリティ対応スタブリゾルバーの退屈な用語。
Zone Apex: Term used to describe the name at the child's side of a zone cut. See also delegation point.
Zone Apex：ゾーンカットの子供側の名前を表すために使用される用語。 委任ポイントも参照してください。
Zone Signing Key (ZSK): An authentication key that corresponds to a private key used to sign a zone. Typically, a zone signing key will be part of the same DNSKEY RRset as the key signing key whose corresponding private key signs this DNSKEY RRset, but the zone signing key is used for a slightly different purpose and may differ from the key signing key in other ways, such as validity lifetime. Designating an authentication key as a zone signing key is purely an operational issue; DNSSEC validation does not distinguish between zone signing keys and other DNSSEC authentication keys, and it is possible to use a single key as both a key signing key and a zone signing key. See also key signing key.
ゾーン署名キー（ZSK）：ゾーンの署名に使用される秘密キーに対応する認証キー。 通常、ゾーン署名キーは、対応する秘密キーがこのDNSKEY RRsetに署名するキー署名キーと同じDNSKEY RRsetの一部になりますが、ゾーン署名キーはわずかに異なる目的で使用され、他のキー署名キーとは異なる場合があります 有効期間などの方法。 認証キーをゾーン署名キーとして指定することは、純粋に運用上の問題です。 DNSSEC検証では、ゾーン署名キーと他のDNSSEC認証キーを区別しません。また、キー署名キーとゾーン署名キーの両方として単一のキーを使用することもできます。 キー署名キーも参照してください。
The Domain Name System (DNS) security extensions provide origin authentication and integrity assurance services for DNS data, including mechanisms for authenticated denial of existence of DNS data. These mechanisms are described below.
ドメインネームシステム（DNS）セキュリティ拡張機能は、DNSデータの存在の認証された拒否のメカニズムを含む、DNSデータの発信元認証および整合性保証サービスを提供します。 これらのメカニズムを以下に説明します。
These mechanisms require changes to the DNS protocol. DNSSEC adds four new resource record types: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC). It also adds two new message header bits: Checking Disabled (CD) and Authenticated Data (AD). In order to support the larger DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also requires EDNS0 support ([RFC2671]). Finally, DNSSEC requires support for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a security-aware resolver can indicate in its queries that it wishes to receive DNSSEC RRs in response messages.
これらのメカニズムでは、DNSプロトコルの変更が必要です。 DNSSECは、リソースレコード署名（RRSIG）、DNS公開キー（DNSKEY）、委任署名者（DS）、および次のセキュア（NSEC）の4つの新しいリソースレコードタイプを追加します。 また、2つの新しいメッセージヘッダービット（Checking Disabled（CD）およびAuthenticated Data（AD））を追加します。 DNSSEC RRを追加することで生じるより大きなDNSメッセージサイズをサポートするために、DNSSECはEDNS0サポート（[RFC2671]）も必要とします。 最後に、DNSSECは、DNSSEC OK（DO）EDNSヘッダービット（[RFC3225]）のサポートを必要とするため、セキュリティ認識リゾルバーは、応答メッセージでDNSSEC RRを受信することをクエリで示すことができます。
These services protect against most of the threats to the Domain Name System described in [RFC3833]. Please see Section 12 for a discussion of the limitations of these extensions.
これらのサービスは、[RFC3833]で説明されているドメインネームシステムに対するほとんどの脅威から保護します。 これらの拡張機能の制限については、セクション12を参照してください。
DNSSEC provides authentication by associating cryptographically generated digital signatures with DNS RRsets. These digital signatures are stored in a new resource record, the RRSIG record. Typically, there will be a single private key that signs a zone's data, but multiple keys are possible. For example, there may be keys for each of several different digital signature algorithms. If a security-aware resolver reliably learns a zone's public key, it can authenticate that zone's signed data. An important DNSSEC concept is that the key that signs a zone's data is associated with the zone itself and not with the zone's authoritative name servers. (Public keys for DNS transaction authentication mechanisms may also appear in zones, as described in [RFC2931], but DNSSEC itself is concerned with object security of DNS data, not channel security of DNS transactions. The keys associated with transaction security may be stored in different RR types. See [RFC3755] for details.)
DNSSECは、暗号で生成されたデジタル署名をDNS RRsetに関連付けることにより認証を提供します。 これらのデジタル署名は、新しいリソースレコードであるRRSIGレコードに保存されます。 通常、ゾーンのデータに署名する単一の秘密キーがありますが、複数のキーが可能です。 たとえば、いくつかの異なるデジタル署名アルゴリズムのそれぞれにキーがある場合があります。 セキュリティ対応のリゾルバがゾーンの公開キーを確実に学習した場合、そのゾーンの署名付きデータを認証できます。 DNSSECの重要な概念は、ゾーンのデータに署名するキーは、ゾーンの権限のあるネームサーバーではなく、ゾーン自体に関連付けられるということです。 （[RFC2931]で説明されているように、DNSトランザクション認証メカニズムの公開鍵もゾーンに表示される場合がありますが、DNSSEC自体はDNSトランザクションのチャネルセキュリティではなく、DNSデータのオブジェクトセキュリティに関係します。トランザクションセキュリティに関連付けられたキーは 異なるRRタイプ。詳細については、[RFC3755]を参照してください。
A security-aware resolver can learn a zone's public key either by having a trust anchor configured into the resolver or by normal DNS resolution. To allow the latter, public keys are stored in a new type of resource record, the DNSKEY RR. Note that the private keys used to sign zone data must be kept secure and should be stored offline when practical. To discover a public key reliably via DNS resolution, the target key itself has to be signed by either a configured authentication key or another key that has been authenticated previously. Security-aware resolvers authenticate zone information by forming an authentication chain from a newly learned public key back to a previously known authentication public key, which in turn either has been configured into the resolver or must have been learned and verified previously. Therefore, the resolver must be configured with at least one trust anchor.
セキュリティ対応リゾルバは、リゾルバにトラストアンカーを設定するか、通常のDNS解決により、ゾーンの公開キーを学習できます。 後者を許可するために、公開キーは新しいタイプのリソースレコードであるDNSKEY RRに保存されます。 ゾーンデータに署名するために使用される秘密キーは、安全に保ち、実用的な場合はオフラインで保存する必要があります。 DNS解決を介して公開キーを確実に検出するには、設定された認証キーまたは以前に認証された別のキーのいずれかによってターゲットキー自体に署名する必要があります。 セキュリティ対応リゾルバーは、新しく学習した公開キーから既知の認証公開キーに戻る認証チェーンを形成することにより、ゾーン情報を認証します。 したがって、リゾルバーは少なくとも1つのトラストアンカーで構成する必要があります。
If the configured trust anchor is a zone signing key, then it will authenticate the associated zone; if the configured key is a key signing key, it will authenticate a zone signing key. If the configured trust anchor is the hash of a key rather than the key itself, the resolver may have to obtain the key via a DNS query. To help security-aware resolvers establish this authentication chain, security-aware name servers attempt to send the signature(s) needed to authenticate a zone's public key(s) in the DNS reply message along with the public key itself, provided that there is space available in the message.
構成されたトラストアンカーがゾーン署名キーである場合、関連付けられたゾーンを認証します。 構成されたキーがキー署名キーである場合、ゾーン署名キーを認証します。 構成されたトラストアンカーがキー自体ではなくキーのハッシュである場合、リゾルバーはDNSクエリを介してキーを取得する必要があります。 セキュリティ対応リゾルバがこの認証チェーンを確立できるように、セキュリティ対応ネームサーバーは、DNS応答メッセージ内のゾーンの公開キーを認証するために必要な署名を、公開キー自体とともに送信しようとします。 メッセージで使用可能なスペース。
The Delegation Signer (DS) RR type simplifies some of the administrative tasks involved in signing delegations across organizational boundaries. The DS RRset resides at a delegation point in a parent zone and indicates the public key(s) corresponding to the private key(s) used to self-sign the DNSKEY RRset at the delegated child zone's apex. The administrator of the child zone, in turn, uses the private key(s) corresponding to one or more of the public keys in this DNSKEY RRset to sign the child zone's data. The typical authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more DS->DNSKEY subchains. DNSSEC permits more complex authentication chains, such as additional layers of DNSKEY RRs signing other DNSKEY RRs within a zone.
委任署名者（DS）RRタイプは、組織の境界を越えた委任の署名に関連する管理タスクの一部を簡素化します。 DS RRsetは、親ゾーンの委任ポイントにあり、委任された子ゾーンの頂点でDNSKEY RRsetの自己署名に使用される秘密鍵に対応する公開鍵を示します。 子ゾーンの管理者は、このDNSKEY RRset内の1つ以上の公開キーに対応する秘密キーを使用して、子ゾーンのデータに署名します。 したがって、一般的な認証チェーンはDNSKEY-> [DS-> DNSKEY] *-> RRsetです。ここで、「*」はゼロ以上のDS-> DNSKEYサブチェーンを示します。 DNSSECは、ゾーン内の他のDNSKEY RRに署名するDNSKEY RRの追加レイヤーなど、より複雑な認証チェーンを許可します。
A security-aware resolver normally constructs this authentication chain from the root of the DNS hierarchy down to the leaf zones based on configured knowledge of the public key for the root. Local policy, however, may also allow a security-aware resolver to use one or more configured public keys (or hashes of public keys) other than the root public key, may not provide configured knowledge of the root public key, or may prevent the resolver from using particular public keys for arbitrary reasons, even if those public keys are properly signed with verifiable signatures. DNSSEC provides mechanisms by which a security-aware resolver can determine whether an RRset's signature is "valid" within the meaning of DNSSEC. In the final analysis, however, authenticating both DNS keys and data is a matter of local policy, which may extend or even override the protocol extensions defined in this document set. See Section 5 for further discussion.
セキュリティ対応のリゾルバは、通常、ルートの公開キーの設定された知識に基づいて、DNS階層のルートからリーフゾーンまでこの認証チェーンを構築します。 ただし、ローカルポリシーでは、セキュリティ対応のリゾルバーが、ルート公開キー以外の1つ以上の構成済み公開キー（または公開キーのハッシュ）を使用できるようにしたり、ルート公開キーの構成済みの知識を提供したり、 リゾルバは、それらの公開鍵が検証可能な署名で適切に署名されている場合でも、任意の理由で特定の公開鍵を使用することを禁止します。 DNSSECは、RRsetの署名がDNSSECの意味の範囲内で「有効」であるかどうかをセキュリティ対応リゾルバが判断できるメカニズムを提供します。 ただし、最終的な分析では、DNSキーとデータの両方を認証することはローカルポリシーの問題であり、このドキュメントセットで定義されているプロトコル拡張を拡張またはオーバーライドすることもあります。 詳細については、セクション5を参照してください。
The security mechanism described in Section 3.1 only provides a way to sign existing RRsets in a zone. The problem of providing negative responses with the same level of authentication and integrity requires the use of another new resource record type, the NSEC record. The NSEC record allows a security-aware resolver to authenticate a negative reply for either name or type non-existence with the same mechanisms used to authenticate other DNS replies. Use of NSEC records requires a canonical representation and ordering for domain names in zones. Chains of NSEC records explicitly describe the gaps, or "empty space", between domain names in a zone and list the types of RRsets present at existing names. Each NSEC record is signed and authenticated using the mechanisms described in Section 3.1.
セクション3.1で説明されているセキュリティメカニズムは、ゾーン内の既存のRRsetに署名する方法のみを提供します。 同じレベルの認証と整合性で否定的な応答を提供する問題には、別の新しいリソースレコードタイプであるNSECレコードの使用が必要です。 NSECレコードにより、セキュリティ対応のリゾルバーは、他のDNS応答の認証に使用されるのと同じメカニズムを使用して、名前またはタイプが存在しないという否定応答を認証できます。 NSECレコードを使用するには、ゾーン内のドメイン名の正規表現と順序付けが必要です。 NSECレコードのチェーンは、ゾーン内のドメイン名間のギャップまたは「空のスペース」を明示的に記述し、既存の名前に存在するRRsetのタイプをリストします。 各NSECレコードは、セクション3.1で説明されているメカニズムを使用して署名および認証されます。
DNS was originally designed with the assumptions that the DNS will return the same answer to any given query regardless of who may have issued the query, and that all data in the DNS is thus visible. Accordingly, DNSSEC is not designed to provide confidentiality, access control lists, or other means of differentiating between inquirers.
DNSは元々、誰がクエリを発行したかに関係なく、DNSが特定のクエリに同じ回答を返すという前提で設計されたため、DNS内のすべてのデータが表示されます。 したがって、DNSSECは機密性、アクセス制御リスト、または照会者を区別するその他の手段を提供するようには設計されていません。
DNSSEC provides no protection against denial of service attacks. Security-aware resolvers and security-aware name servers are vulnerable to an additional class of denial of service attacks based on cryptographic operations. Please see Section 12 for details.
DNSSECは、サービス拒否攻撃に対する保護を提供しません。 セキュリティ対応リゾルバとセキュリティ対応ネームサーバーは、暗号操作に基づく追加のサービス拒否攻撃に対して脆弱です。 詳細については、セクション12を参照してください。
The DNS security extensions provide data and origin authentication for DNS data. The mechanisms outlined above are not designed to protect operations such as zone transfers and dynamic update ([RFC2136], [RFC3007]). Message authentication schemes described in [RFC2845] and [RFC2931] address security operations that pertain to these transactions.
DNSセキュリティ拡張機能は、DNSデータのデータとオリジン認証を提供します。 上記のメカニズムは、ゾーン転送や動的更新などの操作を保護するようには設計されていません（[RFC2136]、[RFC3007]）。 [RFC2845]および[RFC2931]で説明されているメッセージ認証スキームは、これらのトランザクションに関連するセキュリティ操作に対処します。
The specification in this document set defines the behavior for zone signers and security-aware name servers and resolvers in such a way that the validating entities can unambiguously determine the state of the data.
このドキュメントセットの仕様では、検証エンティティがデータの状態を明確に判断できるように、ゾーン署名者、セキュリティ対応ネームサーバー、リゾルバの動作を定義しています。
A validating resolver can determine the following 4 states:
検証リゾルバは、次の4つの状態を判断できます。
Secure: The validating resolver has a trust anchor, has a chain of trust, and is able to verify all the signatures in the response.
セキュア：検証リゾルバーにはトラストアンカーがあり、信頼チェーンがあり、応答内のすべての署名を検証できます。
Insecure: The validating resolver has a trust anchor, a chain of trust, and, at some delegation point, signed proof of the non-existence of a DS record. This indicates that subsequent branches in the tree are provably insecure. A validating resolver may have a local policy to mark parts of the domain space as insecure.
安全でない：検証リゾルバには、トラストアンカー、チェインチェーンがあり、ある委任ポイントで、DSレコードが存在しないことの署名付き証明があります。 これは、ツリー内の後続のブランチが確実に安全でないことを示しています。 検証リゾルバには、ドメインスペースの一部を安全でないとマークするローカルポリシーがあります。
Bogus: The validating resolver has a trust anchor and a secure delegation indicating that subsidiary data is signed, but the response fails to validate for some reason: missing signatures, expired signatures, signatures with unsupported algorithms, data missing that the relevant NSEC RR says should be present, and so forth.
偽：検証リゾルバーにはトラストアンカーと、補助データが署名されていることを示す安全な委任がありますが、応答は何らかの理由で検証に失敗します：署名の欠落、有効期限の切れた署名、サポートされていないアルゴリズムの署名、関連するNSEC RRが示すデータの欠落 存在するなど。
Indeterminate: There is no trust anchor that would indicate that a specific portion of the tree is secure. This is the default operation mode.
不確定：ツリーの特定の部分が安全であることを示すトラストアンカーはありません。 これがデフォルトの動作モードです。
This specification only defines how security-aware name servers can signal non-validating stub resolvers that data was found to be bogus (using RCODE=2, "Server Failure"; see [RFC4035]).
この仕様では、セキュリティ対応のネームサーバーが、検証されていないスタブリゾルバにデータが偽であることが判明したことを通知する方法のみを定義しています（RCODE = 2、 "Server Failure"を使用。[RFC4035]を参照）。
There is a mechanism for security-aware name servers to signal security-aware stub resolvers that data was found to be secure (using the AD bit; see [RFC4035]).
セキュリティ対応のネームサーバーが、データが安全であることが判明したことをセキュリティ対応のスタブリゾルバに通知するメカニズムがあります（ADビットを使用。[RFC4035]を参照）。
This specification does not define a format for communicating why responses were found to be bogus or marked as insecure. The current signaling mechanism does not distinguish between indeterminate and insecure states.
この仕様では、応答が偽であるか、安全でないとマークされた理由を伝えるためのフォーマットを定義していません。 現在のシグナリングメカニズムは、不確定状態と安全でない状態を区別しません。
A method for signaling advanced error codes and policy between a security-aware stub resolver and security-aware recursive nameservers is a topic for future work, as is the interface between a security-aware resolver and the applications that use it. Note, however, that the lack of the specification of such communication does not prohibit deployment of signed zones or the deployment of security aware recursive name servers that prohibit propagation of bogus data to the applications.
セキュリティ対応スタブリゾルバーとセキュリティ対応再帰ネームサーバー間で高度なエラーコードとポリシーを通知する方法は、セキュリティ対応リゾルバーとそれを使用するアプリケーション間のインターフェイスと同様、今後の作業のトピックです。 ただし、このような通信の仕様がなくても、署名済みゾーンの展開や、アプリケーションへの偽データの伝播を禁止するセキュリティ対応の再帰ネームサーバーの展開は禁止されません。
A security-aware resolver has to be able to perform cryptographic functions necessary to verify digital signatures using at least the mandatory-to-implement algorithm(s). Security-aware resolvers must also be capable of forming an authentication chain from a newly learned zone back to an authentication key, as described above. This process might require additional queries to intermediate DNS zones to obtain necessary DNSKEY, DS, and RRSIG records. A security-aware resolver should be configured with at least one trust anchor as the starting point from which it will attempt to establish authentication chains.
セキュリティ対応リゾルバは、少なくとも実装に必須のアルゴリズムを使用してデジタル署名を検証するために必要な暗号化機能を実行できる必要があります。 セキュリティ対応のリゾルバは、上記のように、新しく学習したゾーンから認証キーに戻る認証チェーンを形成できる必要もあります。 このプロセスでは、必要なDNSKEY、DS、およびRRSIGレコードを取得するために、中間DNSゾーンへの追加クエリが必要になる場合があります。 セキュリティ対応のリゾルバは、認証チェーンの確立を開始する開始点として少なくとも1つのトラストアンカーを使用して構成する必要があります。
If a security-aware resolver is separated from the relevant authoritative name servers by a recursive name server or by any sort of intermediary device that acts as a proxy for DNS, and if the recursive name server or intermediary device is not security-aware, the security-aware resolver may not be capable of operating in a secure mode. For example, if a security-aware resolver's packets are routed through a network address translation (NAT) device that includes a DNS proxy that is not security-aware, the security-aware resolver may find it difficult or impossible to obtain or validate signed DNS data. The security-aware resolver may have a particularly difficult time obtaining DS RRs in such a case, as DS RRs do not follow the usual DNS rules for ownership of RRs at zone cuts. Note that this problem is not specific to NATs: any security-oblivious DNS software of any kind between the security-aware resolver and the authoritative name servers will interfere with DNSSEC.
セキュリティ対応のリゾルバが、再帰ネームサーバーまたはDNSのプロキシとして機能する任意の種類の中間デバイスによって関連する権限ネームサーバーから分離されており、再帰ネームサーバーまたは中間デバイスがセキュリティ対応でない場合、 セキュリティ対応リゾルバは、セキュアモードで動作できない場合があります。 たとえば、セキュリティ対応のリゾルバーのパケットが、セキュリティ対応でないDNSプロキシを含むネットワークアドレス変換（NAT）デバイスを介してルーティングされる場合、セキュリティ対応のリゾルバーは、署名済みDNSの取得または検証が困難または不可能な場合があります データ。 DS RRはゾーンカットでのRRの所有権に関する通常のDNS規則に従っていないため、このような場合、セキュリティ対応リゾルバーはDS RRを取得するのが特に困難な場合があります。 この問題はNATに固有のものではないことに注意してください。セキュリティ対応のリゾルバと権限のあるネームサーバーとの間のセキュリティを意識しないDNSソフトウェアは、DNSSECを妨害します。
If a security-aware resolver must rely on an unsigned zone or a name server that is not security aware, the resolver may not be able to validate DNS responses and will need a local policy on whether to accept unverified responses.
セキュリティ対応のリゾルバが、署名されていないゾーンまたはセキュリティに対応していないネームサーバーに依存する必要がある場合、リゾルバはDNS応答を検証できない場合があり、未検証の応答を受け入れるかどうかのローカルポリシーが必要になります。
A security-aware resolver should take a signature's validation period into consideration when determining the TTL of data in its cache, to avoid caching signed data beyond the validity period of the signature. However, it should also allow for the possibility that the security-aware resolver's own clock is wrong. Thus, a security-aware resolver that is part of a security-aware recursive name server will have to pay careful attention to the DNSSEC "checking disabled" (CD) bit ([RFC4034]). This is in order to avoid blocking valid signatures from getting through to other security-aware resolvers that are clients of this recursive name server. See [RFC4035] for how a secure recursive server handles queries with the CD bit set.
セキュリティ対応のリゾルバは、署名の有効期間を超えて署名付きデータがキャッシュされないように、キャッシュ内のデータのTTLを決定する際に署名の検証期間を考慮する必要があります。 ただし、セキュリティ対応のリゾルバ自身の時計が間違っている可能性も考慮すべきです。 したがって、セキュリティ対応の再帰ネームサーバーの一部であるセキュリティ対応リゾルバは、DNSSECの「チェック無効」（CD）ビット（[RFC4034]）に注意を払う必要があります。 これは、この再帰的なネームサーバーのクライアントである他のセキュリティ対応リゾルバーへの有効な署名のブロックを回避するためです。 セキュリティで保護された再帰サーバーがCDビットを設定したクエリを処理する方法については、[RFC4035]を参照してください。
Although not strictly required to do so by the protocol, most DNS queries originate from stub resolvers. Stub resolvers, by definition, are minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution to a recursive name server. Given the widespread use of stub resolvers, the DNSSEC architecture has to take stub resolvers into account, but the security features needed in a stub resolver differ in some respects from those needed in a security-aware iterative resolver.
プロトコルで厳密に要求されるわけではありませんが、ほとんどのDNSクエリはスタブリゾルバから発生します。 スタブリゾルバーは、定義により、再帰クエリモードを使用してDNS解決のほとんどの作業を再帰ネームサーバーにオフロードする最小限のDNSリゾルバーです。 スタブリゾルバの広範な使用を考えると、DNSSECアーキテクチャはスタブリゾルバを考慮する必要がありますが、スタブリゾルバに必要なセキュリティ機能は、セキュリティ対応の反復リゾルバに必要なセキュリティ機能といくつかの点で異なります。
Even a security-oblivious stub resolver may benefit from DNSSEC if the recursive name servers it uses are security-aware, but for the stub resolver to place any real reliance on DNSSEC services, the stub resolver must trust both the recursive name servers in question and the communication channels between itself and those name servers. The first of these issues is a local policy issue: in essence, a security-oblivious stub resolver has no choice but to place itself at the mercy of the recursive name servers that it uses, as it does not perform DNSSEC validity checks on its own. The second issue requires some kind of channel security mechanism; proper use of DNS transaction authentication mechanisms such as SIG(0) ([RFC2931]) or TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec. Particular implementations may have other choices available, such as operating system specific interprocess communication mechanisms. Confidentiality is not needed for this channel, but data integrity and message authentication are.
使用する再帰的なネームサーバーがセキュリティに対応している場合、セキュリティを意識しないスタブリゾルバーでもDNSSECの恩恵を受ける可能性がありますが、スタブリゾルバーがDNSSECサービスに実際に依存するためには、スタブリゾルバーは問題の再帰的なネームサーバーと自身とそれらのネームサーバー間の通信チャネル。これらの問題の最初の問題はローカルポリシーの問題です。本質的に、セキュリティを意識しないスタブリゾルバは、DNSSECの有効性チェックを独自に実行しないため、使用する再帰ネームサーバーに任せざるを得ません。 。 2番目の問題には、ある種のチャネルセキュリティメカニズムが必要です。 IPsecの適切な使用と同様に、SIG（0）（[RFC2931]）またはTSIG（[RFC2845]）などのDNSトランザクション認証メカニズムの適切な使用で十分です。特定の実装では、オペレーティングシステム固有のプロセス間通信メカニズムなど、他の選択肢が利用できる場合があります。このチャネルには機密性は必要ありませんが、データの整合性とメッセージ認証は必要です。
A security-aware stub resolver that does trust both its recursive name servers and its communication channel to them may choose to examine the setting of the Authenticated Data (AD) bit in the message header of the response messages it receives. The stub resolver can use this flag bit as a hint to find out whether the recursive name server was able to validate signatures for all of the data in the Answer and Authority sections of the response.
再帰的なネームサーバーとその通信チャネルの両方を信頼するセキュリティ対応スタブリゾルバーは、受信する応答メッセージのメッセージヘッダーにある認証済みデータ（AD）ビットの設定を調べることを選択できます。 スタブリゾルバは、このフラグビットをヒントとして使用して、再帰ネームサーバーが応答のAnswerセクションとAuthorityセクションのすべてのデータの署名を検証できたかどうかを確認できます。
There is one more step that a security-aware stub resolver can take if, for whatever reason, it is not able to establish a useful trust relationship with the recursive name servers that it uses: it can perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages. A validating stub resolver is thus able to treat the DNSSEC signatures as trust relationships between the zone administrators and the stub resolver itself.
何らかの理由で、使用する再帰的なネームサーバーとの有用な信頼関係を確立できない場合、セキュリティ対応スタブリゾルバーが実行できるステップがもう1つあります。 クエリメッセージの無効（CD）ビット。 したがって、検証用スタブリゾルバーは、ゾーン管理者とスタブリゾルバー自体の間の信頼関係としてDNSSEC署名を扱うことができます。
There are several differences between signed and unsigned zones. A signed zone will contain additional security-related records (RRSIG, DNSKEY, DS, and NSEC records). RRSIG and NSEC records may be generated by a signing process prior to serving the zone. The RRSIG records that accompany zone data have defined inception and expiration times that establish a validity period for the signatures and the zone data the signatures cover.
署名済みゾーンと未署名ゾーンにはいくつかの違いがあります。 署名済みゾーンには、追加のセキュリティ関連レコード（RRSIG、DNSKEY、DS、およびNSECレコード）が含まれます。 RRSIGおよびNSECレコードは、ゾーンにサービスを提供する前に署名プロセスによって生成される場合があります。 ゾーンデータに付随するRRSIGレコードは、署名と署名がカバーするゾーンデータの有効期間を確立する開始時間と有効期限を定義しています。
It is important to note the distinction between a RRset's TTL value and the signature validity period specified by the RRSIG RR covering that RRset. DNSSEC does not change the definition or function of the TTL value, which is intended to maintain database coherency in caches. A caching resolver purges RRsets from its cache no later than the end of the time period specified by the TTL fields of those RRsets, regardless of whether the resolver is security-aware.
RRsetのTTL値と、そのRRsetをカバーするRRSIG RRで指定された署名の有効期間との違いに注意することが重要です。 DNSSECは、キャッシュ内のデータベースの一貫性を維持することを目的としたTTL値の定義または機能を変更しません。 キャッシングリゾルバは、リゾルバがセキュリティに対応しているかどうかに関係なく、それらのRRsetのTTLフィールドで指定された期間の終了までに、RRsetをキャッシュからパージします。
The inception and expiration fields in the RRSIG RR ([RFC4034]), on the other hand, specify the time period during which the signature can be used to validate the covered RRset. The signatures associated with signed zone data are only valid for the time period specified by these fields in the RRSIG RRs in question. TTL values cannot extend the validity period of signed RRsets in a resolver's cache, but the resolver may use the time remaining before expiration of the signature validity period of a signed RRset as an upper bound for the TTL of the signed RRset and its associated RRSIG RR in the resolver's cache.
一方、RRSIG RR（[RFC4034]）の開始フィールドと有効期限フィールドは、対象のRRsetを検証するために署名を使用できる期間を指定します。 署名済みゾーンデータに関連付けられた署名は、問題のRRSIG RRのこれらのフィールドで指定された期間のみ有効です。 TTL値は、リゾルバーのキャッシュ内の署名付きRRsetの有効期間を延長できませんが、リゾルバーは、署名付きRRsetの署名有効期間の満了までの残り時間を、署名付きRRsetおよび関連するRRSIG RRのTTLの上限として使用できます リゾルバのキャッシュ内。
Information in a signed zone has a temporal dependency that did not exist in the original DNS protocol. A signed zone requires regular maintenance to ensure that each RRset in the zone has a current valid RRSIG RR. The signature validity period of an RRSIG RR is an interval during which the signature for one particular signed RRset can be considered valid, and the signatures of different RRsets in a zone may expire at different times. Re-signing one or more RRsets in a zone will change one or more RRSIG RRs, which will in turn require incrementing the zone's SOA serial number to indicate that a zone change has occurred and re-signing the SOA RRset itself. Thus, re-signing any RRset in a zone may also trigger DNS NOTIFY messages and zone transfer operations.
署名済みゾーンの情報には、元のDNSプロトコルには存在しなかった一時的な依存関係があります。 署名されたゾーンには、ゾーン内の各RRsetに現在有効なRRSIG RRがあることを確認するための定期的なメンテナンスが必要です。 RRSIG RRの署名有効期間は、1つの特定の署名付きRRsetの署名が有効と見なされる間隔であり、ゾーン内の異なるRRsetの署名は異なる時間に期限切れになる場合があります。 ゾーン内の1つ以上のRRsetに再署名すると、1つ以上のRRSIG RRが変更され、ゾーンのSOAシリアル番号をインクリメントして、ゾーンの変更が発生したことを示し、SOA RRset自体に再署名する必要があります。 したがって、ゾーン内のRRsetに再署名すると、DNS NOTIFYメッセージとゾーン転送操作もトリガーされます。
A security-aware name server should include the appropriate DNSSEC records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries from resolvers that have signaled their willingness to receive such records via use of the DO bit in the EDNS header, subject to message size limitations. Because inclusion of these DNSSEC RRs could easily cause UDP message truncation and fallback to TCP, a security-aware name server must also support the EDNS "sender's UDP payload" mechanism.
セキュリティ対応のネームサーバーは、適切なDNSSECレコード（RRSIG、DNSKEY、DS、およびNSEC）を、EDNSヘッダーのDOビットを使用してそのようなレコードを受信する意思があることを示すリゾルバーからのすべての応答に含める必要があります。 メッセージサイズの制限。 これらのDNSSEC RRを含めると、UDPメッセージの切り捨てとTCPへのフォールバックが容易に発生する可能性があるため、セキュリティ対応ネームサーバーはEDNS「送信者のUDPペイロード」メカニズムもサポートする必要があります。
If possible, the private half of each DNSSEC key pair should be kept offline, but this will not be possible for a zone for which DNS dynamic update has been enabled. In the dynamic update case, the primary master server for the zone will have to re-sign the zone when it is updated, so the private key corresponding to the zone signing key will have to be kept online. This is an example of a situation in which the ability to separate the zone's DNSKEY RRset into zone signing key(s) and key signing key(s) may be useful, as the key signing key(s) in such a case can still be kept offline and may have a longer useful lifetime than the zone signing key(s).
可能であれば、各DNSSECキーペアのプライベート半分をオフラインにしておく必要がありますが、DNS動的更新が有効になっているゾーンではこれは不可能です。 動的更新の場合、ゾーンのプライマリマスターサーバーは更新時にゾーンに再署名する必要があるため、ゾーン署名キーに対応する秘密キーはオンラインのままにしておく必要があります。 これは、ゾーンのDNSKEY RRsetをゾーン署名キーとキー署名キーに分離する機能が役立つ場合がある状況の例です。 オフラインのままであり、ゾーン署名キーよりも有効な有効期間が長い場合があります。
By itself, DNSSEC is not enough to protect the integrity of an entire zone during zone transfer operations, as even a signed zone contains some unsigned, nonauthoritative data if the zone has any children. Therefore, zone maintenance operations will require some additional mechanisms (most likely some form of channel security, such as TSIG, SIG(0), or IPsec).
DNSSEC自体では、ゾーン転送操作中にゾーン全体の整合性を保護するのに十分ではありません。ゾーンに子がある場合、署名されたゾーンにも未署名の権限のないデータが含まれるためです。 したがって、ゾーンのメンテナンス操作には、いくつかの追加メカニズム（TSIG、SIG（0）、IPsecなどのチャネルセキュリティの可能性が高い）が必要になります。
The DNSSEC document set can be partitioned into several main groups, under the larger umbrella of the DNS base protocol documents.
DNSSECドキュメントセットは、DNSベースプロトコルドキュメントのより大きな傘の下で、いくつかの主要なグループに分割できます。
The "DNSSEC protocol document set" refers to the three documents that form the core of the DNS security extensions:
「DNSSECプロトコルドキュメントセット」は、DNSセキュリティ拡張機能の中核を形成する3つのドキュメントを指します。
1. DNS Security Introduction and Requirements (this document)
1. DNSセキュリティの概要と要件（このドキュメント）
2. Resource Records for DNS Security Extensions [RFC4034]
2. DNSセキュリティ拡張機能のリソースレコード[RFC4034]
3. Protocol Modifications for the DNS Security Extensions [RFC4035]
3. DNSセキュリティ拡張機能のプロトコル変更[RFC4035]
Additionally, any document that would add to or change the core DNS Security extensions would fall into this category. This includes any future work on the communication between security-aware stub resolvers and upstream security-aware recursive name servers.
さらに、コアDNSセキュリティ拡張機能を追加または変更するドキュメントは、このカテゴリに分類されます。 これには、セキュリティ対応スタブリゾルバと上流のセキュリティ対応再帰ネームサーバー間の通信に関する今後の作業が含まれます。
The "Digital Signature Algorithm Specification" document set refers to the group of documents that describe how specific digital signature algorithms should be implemented to fit the DNSSEC resource record format. Each document in this set deals with a specific digital signature algorithm. Please see the appendix on "DNSSEC Algorithm and Digest Types" in [RFC4034] for a list of the algorithms that were defined when this core specification was written.
「デジタル署名アルゴリズム仕様」ドキュメントセットは、特定のデジタル署名アルゴリズムをDNSSECリソースレコード形式に適合するように実装する方法を説明するドキュメントのグループを指します。 このセットの各ドキュメントは、特定のデジタル署名アルゴリズムを扱っています。 このコア仕様が作成されたときに定義されたアルゴリズムのリストについては、[RFC4034]の「DNSSECアルゴリズムとダイジェストタイプ」の付録を参照してください。
The "Transaction Authentication Protocol" document set refers to the group of documents that deal with DNS message authentication, including secret key establishment and verification. Although not strictly part of the DNSSEC specification as defined in this set of documents, this group is noted because of its relationship to DNSSEC.
「トランザクション認証プロトコル」ドキュメントセットは、秘密キーの確立と検証を含む、DNSメッセージ認証を扱うドキュメントのグループを指します。 このドキュメントセットで定義されているDNSSEC仕様の一部ではありませんが、このグループはDNSSECとの関係から注目されています。
The final document set, "New Security Uses", refers to documents that seek to use proposed DNS Security extensions for other security related purposes. DNSSEC does not provide any direct security for these new uses but may be used to support them. Documents that fall in this category include those describing the use of DNS in the storage and distribution of certificates ([RFC2538]).
最終的なドキュメントセット「New Security Uses」は、提案されたDNSセキュリティ拡張機能を他のセキュリティ関連の目的に使用しようとするドキュメントを指します。 DNSSECは、これらの新しい用途に直接的なセキュリティを提供しませんが、それらをサポートするために使用できます。 このカテゴリに該当するドキュメントには、証明書の保存と配布でのDNSの使用を説明するドキュメントが含まれます（[RFC2538]）。
This overview document introduces no new IANA considerations. Please see [RFC4034] for a complete review of the IANA considerations introduced by DNSSEC.
この概要ドキュメントでは、新しいIANAの考慮事項を紹介していません。 DNSSECによって導入されたIANAの考慮事項の完全なレビューについては、[RFC4034]をご覧ください。
This document introduces DNS security extensions and describes the document set that contains the new security records and DNS protocol modifications. The extensions provide data origin authentication and data integrity using digital signatures over resource record sets. This section discusses the limitations of these extensions.
このドキュメントでは、DNSセキュリティ拡張機能を紹介し、新しいセキュリティレコードとDNSプロトコルの変更を含むドキュメントセットについて説明します。 拡張機能は、リソースレコードセットに対するデジタル署名を使用して、データ発信元認証とデータ整合性を提供します。 このセクションでは、これらの拡張機能の制限について説明します。
In order for a security-aware resolver to validate a DNS response, all zones along the path from the trusted starting point to the zone containing the response zones must be signed, and all name servers and resolvers involved in the resolution process must be security-aware, as defined in this document set. A security-aware resolver cannot verify responses originating from an unsigned zone, from a zone not served by a security-aware name server, or for any DNS data that the resolver is only able to obtain through a recursive name server that is not security-aware. If there is a break in the authentication chain such that a security-aware resolver cannot obtain and validate the authentication keys it needs, then the security-aware resolver cannot validate the affected DNS data.
セキュリティ対応のリゾルバーがDNS応答を検証するには、信頼できる開始点から応答ゾーンを含むゾーンへのパスに沿ったすべてのゾーンに署名する必要があり、解決プロセスに関与するすべてのネームサーバーとリゾルバーがセキュリティ対応でなければなりません このドキュメントセットで定義されているとおりです。 セキュリティ対応のリゾルバーは、署名されていないゾーン、セキュリティ対応のネームサーバーによって処理されないゾーン、またはリゾルバーがセキュリティ以外の再帰ネームサーバーを介してのみ取得できるDNSデータに対する応答を検証できません。 気がついて。 セキュリティ対応リゾルバーが必要な認証キーを取得および検証できないなど、認証チェーンに中断がある場合、セキュリティ対応リゾルバーは影響を受けるDNSデータを検証できません。
This document briefly discusses other methods of adding security to a DNS query, such as using a channel secured by IPsec or using a DNS transaction authentication mechanism such as TSIG ([RFC2845]) or SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC per se.
このドキュメントでは、IPsecで保護されたチャネルを使用したり、TSIG（[RFC2845]）やSIG（0）（[RFC2931]）などのDNSトランザクション認証メカニズムを使用するなど、DNSクエリにセキュリティを追加する他の方法について簡単に説明しますが、トランザクション セキュリティは本質的にDNSSECの一部ではありません。
A non-validating security-aware stub resolver, by definition, does not perform DNSSEC signature validation on its own and thus is vulnerable both to attacks on (and by) the security-aware recursive name servers that perform these checks on its behalf and to attacks on its communication with those security-aware recursive name servers. Non-validating security-aware stub resolvers should use some form of channel security to defend against the latter threat. The only known defense against the former threat would be for the security-aware stub resolver to perform its own signature validation, at which point, again by definition, it would no longer be a non-validating security-aware stub resolver.
非検証のセキュリティ対応スタブリゾルバは、定義上、DNSSEC署名の検証を独自に実行しないため、これらに代わってこれらのチェックを実行するセキュリティ対応の再帰ネームサーバーに対する（および）攻撃の両方に対して脆弱です。 セキュリティを意識した再帰的なネームサーバーとの通信に対する攻撃。 非検証のセキュリティ対応スタブリゾルバは、何らかの形のチャネルセキュリティを使用して、後者の脅威から防御する必要があります。 前者の脅威に対する唯一の既知の防御は、セキュリティ対応スタブリゾルバーが独自の署名検証を実行することであり、この時点でも定義により、それはもはや非検証セキュリティ対応スタブリゾルバーではなくなります。
DNSSEC does not protect against denial of service attacks. DNSSEC makes DNS vulnerable to a new class of denial of service attacks based on cryptographic operations against security-aware resolvers and security-aware name servers, as an attacker can attempt to use DNSSEC mechanisms to consume a victim's resources. This class of attacks takes at least two forms. An attacker may be able to consume resources in a security-aware resolver's signature validation code by tampering with RRSIG RRs in response messages or by constructing needlessly complex signature chains. An attacker may also be able to consume resources in a security-aware name server that supports DNS dynamic update, by sending a stream of update messages that force the security-aware name server to re-sign some RRsets in the zone more frequently than would otherwise be necessary.
DNSSECは、サービス拒否攻撃から保護しません。 DNSSECは、攻撃者がDNSSECメカニズムを使用して被害者のリソースを消費しようとする可能性があるため、セキュリティを意識したリゾルバーおよびセキュリティを意識したネームサーバーに対する暗号操作に基づいた新しいクラスのサービス拒否攻撃に対してDNSを脆弱にします。 このクラスの攻撃には、少なくとも2つの形態があります。 攻撃者は、応答メッセージのRRSIG RRを改ざんするか、不必要に複雑な署名チェーンを構築することにより、セキュリティ対応リゾルバーの署名検証コードのリソースを消費できる可能性があります。 また、攻撃者は、DNS動的更新をサポートするセキュリティ対応ネームサーバーのリソースを消費する可能性があります。これは、セキュリティ対応ネームサーバーに、ゾーン内のRRsetを頻繁に再署名させる更新メッセージのストリームを送信することによって それ以外の場合は必要です。
Due to a deliberate design choice, DNSSEC does not provide confidentiality.
設計上の意図的な選択により、DNSSECは機密性を提供しません。
DNSSEC introduces the ability for a hostile party to enumerate all the names in a zone by following the NSEC chain. NSEC RRs assert which names do not exist in a zone by linking from existing name to existing name along a canonical ordering of all the names within a zone. Thus, an attacker can query these NSEC RRs in sequence to obtain all the names in a zone. Although this is not an attack on the DNS itself, it could allow an attacker to map network hosts or other resources by enumerating the contents of a zone.
DNSSECは、NSECチェーンに従うことにより、敵対者がゾーン内のすべての名前を列挙する機能を導入します。 NSEC RRは、ゾーン内のすべての名前の標準的な順序に沿って既存の名前から既存の名前にリンクすることにより、ゾーンに存在しない名前をアサートします。 したがって、攻撃者はこれらのNSEC RRを順番に照会して、ゾーン内のすべての名前を取得できます。 これはDNS自体に対する攻撃ではありませんが、攻撃者がゾーンのコンテンツを列挙することにより、ネットワークホストまたは他のリソースをマップする可能性があります。
DNSSEC introduces significant additional complexity to the DNS and thus introduces many new opportunities for implementation bugs and misconfigured zones. In particular, enabling DNSSEC signature validation in a resolver may cause entire legitimate zones to become effectively unreachable due to DNSSEC configuration errors or bugs.
DNSSECはDNSに大幅な追加の複雑さをもたらし、したがって、実装のバグやゾーンの構成ミスの多くの新しい機会をもたらします。 特に、リゾルバでDNSSEC署名検証を有効にすると、DNSSEC構成エラーまたはバグにより、正当なゾーン全体が事実上到達不能になる可能性があります。
DNSSEC does not protect against tampering with unsigned zone data. Non-authoritative data at zone cuts (glue and NS RRs in the parent zone) are not signed. This does not pose a problem when validating the authentication chain, but it does mean that the non-authoritative data itself is vulnerable to tampering during zone transfer operations. Thus, while DNSSEC can provide data origin authentication and data integrity for RRsets, it cannot do so for zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be used to protect zone transfer operations.
DNSSECは、署名されていないゾーンデータの改ざんを防止しません。 ゾーンカットでの権限のないデータ（親ゾーンの接着剤とNS RR）は署名されません。 これは、認証チェーンの検証時には問題になりませんが、権限のないデータ自体がゾーン転送操作中の改ざんに対して脆弱であることを意味します。 したがって、DNSSECはRRsetに対してデータ発信元認証とデータ整合性を提供できますが、ゾーンに対しては提供できません。他のメカニズム（TSIG、SIG（0）、IPsecなど）を使用してゾーン転送操作を保護する必要があります。
Please see [RFC4034] and [RFC4035] for additional security considerations.
セキュリティに関する追加の考慮事項については、[RFC4034]および[RFC4035]を参照してください。
This document was created from the input and ideas of the members of the DNS Extensions Working Group. Although explicitly listing everyone who has contributed during the decade in which DNSSEC has been under development would be impossible, the editors would particularly like to thank the following people for their contributions to and comments on this document set: Jaap Akkerhuis, Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and Suzanne Woolf.
このドキュメントは、DNS Extensions Working Groupのメンバーの意見とアイデアから作成されました。 DNSSECが開発中の10年間に貢献したすべての人を明示的にリストすることは不可能ですが、編集者はこのドキュメントセットへの貢献とコメントに対して次の人々に特に感謝します：Jaap Akkerhuis、Mark Andrews、Derek Atkins 、ロイ・バダミ、アラン・バレット、ダン・バーンスタイン、デビッド・ブラッカ、レン・バドニー、ランディ・ブッシュ、フランシス・デュポン、ドナルド・イーストレイク、ロバート・エルツ、ミーク・ギーベン、マイケル・グラフ、オラファー・グムンドソン、ジル・ゲッテ、アンドレアス・グスタフソン、イトージュン・ハギノ、フィリップハラム・ベイカー、ボブ・ハレー、テッド・ハーディ、ウォルター・ハワード、グレッグ・ハドソン、クリスチャン・ユイテマ、ヨハン・アイレン、スティーブン・ジェイコブ、ジェルテ・ヤンセン、サイモン・ジョセフソン、アンドリス・カルノゾル、ピーター・コッホ、オラフ・コルクマン、マーク・コスターズ、シュレシュ・クリシュナワミー、ベン・ローリー、デビッドローレンス、テッド・レモン、エド・ルイス、テッド・リンドグリーン、ジョシュ・リトルフィールド、リップ・ルーミス、ビル・マニング、ラス・マンディ、トーマス・ナルテン、マンズ・ニルソン、太田雅貴、マイク・パットン、ロブ・ペイン、ジム・リード、マイケル・リチャードソン、エリック・ローゼンダール、マルコスサンズ、ペッカサヴォラ、ヤコブシュリター、マイクセントジョンズ、ポールビクシー、サムワイラー、ブライアンウェリントン、スザンヌウルフ。
No doubt the above list is incomplete. We apologize to anyone we left out.
上記のリストが不完全であることは間違いありません。 除外した人には謝罪します。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake 3rd、D。、「ドメインネームシステムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225]コンラッド、D。、「DNSSECのリゾルバーサポートを示す」、RFC 3225、2001年12月。
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001.
[RFC3226] Gudmundsson、O。、「DNSSECおよびIPv6 A6対応サーバー/リゾルバーのメッセージサイズ要件」、RFC 3226、2001年12月
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445] Massey、D。、およびS. Rose、「KEYリソースレコード（RR）の範囲の制限」、RFC 3445、2002年12月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のリソースレコード」、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル修正」、RFC 4035、2005年3月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメインネームシステムの動的更新（DNS更新）」、RFC 2136、1997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。、およびR. Bush、「DNS仕様の明確化」、RFC 2181、1997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308] Andrews、M。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、1998年3月。
[RFC2538] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2538] Eastlake 3rd、D。およびO. Gudmundsson、「ドメインネームシステム（DNS）に証明書を保存する」、RFC 2538、1999年3月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSの秘密鍵トランザクション認証（TSIG）」、RFC 2845、2000年5月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931] Eastlake 3rd、D。、「DNS要求およびトランザクション署名（SIG（0）s）」、RFC 2931、2000年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「セキュアドメインネームシステム（DNS）動的更新」、RFC 3007、2000年11月。
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000.
[RFC3008]ウェリントン、B。、「ドメインネームシステムセキュリティ（DNSSEC）署名機関」、RFC 3008、2000年11月。
[RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001.
[RFC3090]ルイス、E。、「ゾーンステータスに関するDNSセキュリティ拡張の明確化」、RFC 3090、2001年3月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597] Gustafsson、A。、「不明なDNSリソースレコード（RR）タイプの処理」、RFC 3597、2003年9月。
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3655] Wellington、B.およびO. Gudmundsson、「DNS認証データ（AD）ビットの再定義」、RFC 3655、2003年11月。
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003.
[RFC3658] Gudmundsson、O。、「委任署名者（DS）リソースレコード（RR）」、RFC 3658、2003年12月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
[RFC3755] Weiler、S。、「委任署名者（DS）のレガシーリゾルバ互換性」、RFC 3755、2004年5月。
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004.
[RFC3757] Kolkman、O.、Schlyter、J。、およびE. Lewis、「ドメインネームシステムキー（DNSKEY）リソースレコード（RR）セキュアエントリポイント（SEP）フラグ」、RFC 3757、2004年4月
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] Atkins、D。、およびR. Austein、「ドメインネームシステム（DNS）の脅威分析」、RFC 3833、2004年8月
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format", RFC 3845, August 2004.
[RFC3845] Schlyter、J。、「DNSセキュリティ（DNSSEC）NextSECure（NSEC）RDATAフォーマット」、RFC 3845、2004年8月。
Authors' Addresses
著者のアドレス
Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL
Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL
EMail: roy.arends@telin.nl
メール：roy.arends@telin.nl
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City、CA 94063 USA
EMail: sra@isc.org
メール：sra@isc.org
Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Matt Larson VeriSign、Inc. 21345 Ridgetop Circle Dulles、VA 20166-6503アメリカ合衆国
EMail: mlarson@verisign.com
メール：mlarson@verisign.com
Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873
ダンマッセイコロラド州立大学コンピュータサイエンス学部フォートコリンズ、コロラド州80523-1873
EMail: massey@cs.colostate.edu
メール：massey@cs.colostate.edu
Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA
スコットローズ国立標準技術研究所100 Bureau Drive Gaithersburg、MD 20899-8920 USA
EMail: scott.rose@nist.gov
メール：scott.rose@nist.gov
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。