[要約] RFC 4033は、DNSセキュリティ拡張（DNSSEC）の導入と要件に関する文書です。このRFCは、DNS応答の改ざんを防ぐためにデジタル署名を使用してDNS情報の真正性と完全性を保証する方法を定義します。目的は、DNS応答の信頼性を高め、キャッシュポイズニングやその他の攻撃から保護することです。。関連するRFCには、RFC 4034（DNSSECのリソースレコード拡張）、RFC 4035（DNSSECのプロトコルの詳細）、およびRFC 3833（DNS脅威分析）があります。
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
DNSセキュリティの紹介と要件
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
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を認証できます。「example.」DS RRsetには、ある「example.」DNSKEYと一致するハッシュが含まれており、このDNSKEYに対応する秘密鍵が「example.」DNSKEY RRsetに署名します。「example.」DNSKEY RRsetの秘密鍵の対となるものは、「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の所有者名が、ゾーン頂点（zone apex）以下であり、かつ（もしあれば）そのゾーンを子ゾーンから分離するカット（cut）以上である名前空間のサブセット内に存在する場合にのみ、そのRRsetは「権威がある（authoritative）」とされます。ゾーン頂点にあるすべての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.
セキュリティの島（Island of Security）：委任元の親からの認証チェーンを持たない、署名された委任ゾーンを記述するために使用される用語です。つまり、委任元の親ゾーンには、その島の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.
セキュリティ認識スタブリゾルバ：このドキュメントセットで定義されているDNSセキュリティ拡張を十分に理解しており、セキュリティを意識しないスタブリゾルバでは利用できない追加サービスを提供する、スタブリゾルバ（[RFC1034]のセクション5.3.1で定義）の役割を果たすエンティティです。セキュリティ認識スタブリゾルバは、スタブリゾルバが独自にDNSSEC署名を検証しようとするか、信頼できるセキュリティ認識ネームサーバーに検証を任せるかに応じて、「検証」または「非検証」のいずれかになります。検証スタブリゾルバ、非検証スタブリゾルバも参照してください。
Security-Oblivious <anything>: An <anything> that is not "security-aware".
セキュリティ非認識<何か>：「セキュリティ認識」ではない<何か>です。
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 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は、4つの新しいリソースレコードタイプを追加します：リソースレコード署名（RRSIG）、DNS公開キー（DNSKEY）、委任署名者（DS）、およびNext Secure（NSEC）。また、2つの新しいメッセージヘッダービットも追加されます：無効（CD）と認証データ（AD）のチェック。DNSSEC RRSを追加したことから生じるより大きなDNSメッセージサイズをサポートするために、DNSSECにはEDNS0サポートも必要です（[RFC2671]）。最後に、DNSSECは、DNSSEC OK（do）EDNSヘッダービット（[RFC3225]）のサポートを必要としているため、セキュリティ対応のリゾルバーは、応答メッセージでDNSSEC RRSを受け取ることを希望することをクエリで示すことができます。
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.
セキュア（Secure）：検証リゾルバーにはトラストアンカーがあり、信頼の連鎖があり、応答内のすべての署名を検証できます。
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.
インセキュア（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.
ボーガス（Bogus）：検証リゾルバーにはトラストアンカーと、下位データが署名されていることを示す安全な委任がありますが、何らかの理由で応答の検証に失敗します。署名の欠落、期限切れの署名、サポートされていないアルゴリズムによる署名、関連する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.
不確定（Indeterminate）：ツリーの特定の部分が安全であることを示すトラストアンカーがありません。これはデフォルトの操作モードです。
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の「Checking Disabled」（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番目の問題には、何らかのチャネルセキュリティメカニズムが必要です。SIG(0)（[RFC2931]）やTSIG（[RFC2845]）などのDNSトランザクション認証メカニズムを適切に使用すれば十分ですし、IPsecを適切に使用しても十分です。特定の実装では、オペレーティングシステム固有のプロセス間通信メカニズムなど、他の選択肢が利用できる場合があります。このチャネルには機密性は必要ありませんが、データの整合性とメッセージ認証は必要です。
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.
再帰ネームサーバーとそれらへの通信チャネルの両方を信頼するセキュリティ対応スタブリゾルバーは、受信する応答メッセージのメッセージヘッダーにあるAuthenticated Data（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つのステップがあります。それは、クエリメッセージにChecking Disabled（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の署名有効期間は、特定の署名された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.
セキュリティ対応ネームサーバーは、メッセージサイズの制限に従い、EDNSヘッダーのDOビットを使用してそのようなレコードを受信する意思を示したリゾルバーからのクエリへのすべての応答に、適切なDNSSECレコード（RRSIG、DNSKEY、DS、およびNSEC）を含める必要があります。これらの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.
「Digital Signature Algorithm Specification」ドキュメントセットとは、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]).
最後のドキュメントセット「新しいセキュリティ用途」は、提案されている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拡張ワーキンググループのメンバーの入力とアイデアから作成されました。DNSSECが開発されていた10年間に貢献したすべての人を明示的にリストすることは不可能ですが、編集者は特に、このドキュメントセットへの貢献とコメントについて次の人々に感謝したいと思います：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、およびSuzanne Woolf。
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] Conrad、D。、「DNSSECのリゾルバーサポートを示す」、RFC 3225、2001年12月。
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001.
[RFC3226] Gudmundsson、O。、「DNSSECおよびIPv6 A6 Aware Server/Resolverメッセージサイズ要件」、RFC 3226、2001年12月。
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445] Massey、D。およびS. Rose、「主要なリソースレコード（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のシークレットキートランザクション認証」、2000年5月、RFC 2845。
[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）BITの再定義」、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。、「Legacy Resolver compatibility for Dedigation Signer（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 Security（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
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブオーストインインターネットシステムコンソーシアム950チャーターストリートレッドウッドシティ、カリフォルニア94063 USA
EMail: sra@isc.org
Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Matt Larson Verisign、Inc。21345 Ridgetop Circle Dulles、VA 20166-6503 USA
EMail: mlarson@verisign.com
Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873
ダンマッシーコロラド州立大学コンピュータサイエンス学部フォートコリンズ、コロラド州80523-1873
EMail: massey@cs.colostate.edu
Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA
スコットローズ国立標準技術研究所100ビューロードライブゲーサーズバーグ、メリーランド20899-8920 USA
EMail: scott.rose@nist.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。