[要約] 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]、[RFC2136]、[RFC2181]、[RFC2308]、[RFC3225]、[RFC3007]、[RFC3597]、[RFC3597]、[RFC32226]、[RFC3226]、[RFC3007]、[RFC2308]、[RFC2335]、[RFC2181]、[RFC2181]、[RFC2181]、[RFC2181]、[RFC2181]、[RFC2181]、[RFC2181]、[RFC2308]、[RFC23225]、[RFC32226]も廃止されません。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）rrsetsおよび委任署名者（DS）rrsetsの交互のシーケンスは、署名データのチェーンを形成し、チェーンの各リンクは次のリンクを保証します。DNSKEY RRを使用して、DS RRをカバーする署名を検証し、DS RRを認証できるようにします。DS RRには別のDNSKEY RRのハッシュが含まれており、この新しいDNSKEY RRは、DS RRのハッシュを一致させることにより認証されます。この新しいDNSKEY RRは、別のDNSKEY RRSETを認証し、このセットの一部のDNSKEY RRを使用して別のDS RRを認証するために使用できます。データ。たとえば、root dnskey rrsetを使用して、「例」のDS RRSetを認証できます。例。"DS RRSTには、「例」に一致するハッシュが含まれています。dnskey、およびこのdnskeyの対応する秘密鍵は「例」を示しています。dnskey rrset。「例」の秘密鍵のカウンターパート。dnskey rrset「www.example」などのデータレコード。「subzone.example」などの代表団のDS RRS。
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とDSKEY 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は「権威ある」です。ゾーンを子供から分離します。ゾーンアペックスのすべてのrrsetsは権威あるものですが、このドメイン名で特定のrrsetsを除き、存在する場合、このゾーンの親に属します。これらのRRSETには、このDS RRSET（「親NSEC」）を参照するNSEC RRSET、およびこれらのRRSETに関連するRRSIG RRSを含むDS RRSET、すべてが親ゾーンで権威あるものです。同様に、このゾーンに委任ポイントが含まれている場合、親のNSEC RRSET、DS RRSets、およびこれらのRRSetsに関連付けられたRRSIG RRSのみがこのゾーンに対して権威があります。
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」の委任ポイントは、「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.
セキュリティ対応のスタブリゾルバー：スタブリゾルバーの役割（[RFC1034]のセクション5.3.1で定義されている）の役割で作用するエンティティは、このドキュメントで定義されているDNSセキュリティ拡張機能を十分に理解しており、セキュリティに焦点を当てたスタブリゾルバー。セキュリティ認識のスタブリゾルバーは、スタブリゾルバーが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.
署名ゾーン：RRSetsが署名され、適切に構築されたDNSKEY、リソースレコード署名（RRSIG）、次のセキュア（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 hash。検証済みのセキュリティ対応リゾルバーは、この公開キーまたはハッシュを署名した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 rrsetsに関連付けることにより、認証を提供します。これらのデジタル署名は、新しいリソースレコードである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 RRSに署名する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で説明されているセキュリティメカニズムは、ゾーン内の既存のRRSetsに署名する方法のみを提供します。同じレベルの認証と整合性で否定的な応答を提供する問題には、別の新しいリソースレコードタイプである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、「サーバー障害」、[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 RRSはゾーンカットでのRRSの所有権に関する通常のDNSルールに従っていないため、セキュリティ対応のリゾルバーはDS RRSを取得するのが特に困難な場合があります。この問題は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）ビットの設定を調べることを選択できます。Stub Resolverは、このフラグビットをヒントとして使用して、再帰名サーバーが回答の回答と権限のセクションのすべてのデータの署名を検証できるかどうかを調べることができます。
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フィールドによって指定された期間の終了までにキャッシュからrrsetsをパージします。
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 RRSのこれらのフィールドによって指定された期間のみ有効です。TTL値は、リゾルバーのキャッシュで署名されたRRSetsの署名RRSetsの有効期間を延長することはできませんが、リゾルバーは、署名されたRRSETの署名妥当性の有効性期間の有効期限の終了前の残りの時間を使用して、署名されたRRSETおよびそれに関連するRRSIG RRRの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つ以上のrrsetsに再署名すると、1つ以上のRRSIG RRSが変更され、ゾーンの変更が発生したことを示すためにゾーンのSOAシリアル番号を増やし、SOA RRSet自体を再署名する必要があります。したがって、ゾーン内のRRSETに再署名すると、DNSがメッセージとゾーン転送操作を通知することもできます。
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 RRSを含めると、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.
「トランザクション認証プロトコル」ドキュメントセットは、Secret Keyの確立や検証など、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使用」は、他のセキュリティ関連の目的で提案されている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 RRSを改ざんするか、不必要に複雑な署名チェーンを構築することにより、セキュリティ対応Resolverの署名検証コードでリソースを消費できる場合があります。攻撃者は、セキュリティ対応の名前サーバーにゾーン内のいくつかのrrsetsを強制的にゾーン内のいくつかのrrsetsに再装うように強制する更新メッセージのストリームを送信することにより、DNSダイナミックアップデートをサポートするセキュリティ対応の名前サーバーでリソースを消費することもできます。そうでなければ必要です。
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 RRSは、ゾーン内のすべての名前の標準的な順序に沿って既存の名前から既存の名前にリンクすることにより、ゾーンに存在しない名前を主張します。したがって、攻撃者はこれらの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に大幅な追加の複雑さを導入するため、実装バグと誤解されたゾーンの多くの新しい機会を導入します。特に、Resolverで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はRRSetsのデータ起源認証とデータの整合性を提供できますが、ゾーンではそうすることはできません。他のメカニズム（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、ロイ・バダミ、アラン・バレット、ダン・バーンスタイン、デビッド・ブラッカ、レン・バドニー、ランディ・ブッシュ、フランシス・デュポン、ドナルド・イーストレイク、ロバート・エルツ、ミーク・ジーベン、マイケル・グラフ、オラフール・グドマンドソン、ジルズ・グエット、アンドレアス・ガスタフソン、ジュン・イチロ・イトジョン・イッジョン・イリップハラム・ベーカー、ボブ・ハレー、テッド・ハーディ、ウォルター・ハワード、グレッグ・ハドソン、クリスチャン・フイテマ、ヨハン・イーレン、スティーブン・ジェイコブ、ジェルテ・ヤンセン、サイモン・ジョセフソン、アンドリス・カルノゾルズ、ピーター・コッホ、オラフ・コルクマン、マーク・コスターズ、スリシュ・クリシュナスワミー、ベン・ラウリー、ローレンス、テッド・レモン、エド・ルイス、テッド・リンドグリーン、ジョシュ・リトルフィールド、リップ・ルーミス、ビル・マニング、ラス・マンディ、トーマス・ナルテン、マンス・ニルソン、マサタカ・オタ、マイク・パットン、ロブ・ペイン、ジム・リード、マイケル・リチャードソン、エリック・ロゼンダル、マルコス・サンズ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エディター機能の資金は現在、インターネット協会によって提供されています。