RFC4033 日本語訳
4033 DNS Security Introduction and Requirements. R. Arends, R.Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=52445 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
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 Security Introduction and Requirements
Status of This Memo
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.
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.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
Abstract
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.
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.
Arends, et al. Standards Track [Page 1] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends, et al. Standards Track [Page 1] RFC 4033 DNS Security Introduction and Requirements March 2005
Table of Contents
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
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
1. Introduction
1. Introduction
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.
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.
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.
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.
Arends, et al. Standards Track [Page 2] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends, et al. Standards Track [Page 2] RFC 4033 DNS Security Introduction and Requirements March 2005
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.
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.
2. Definitions of Important DNSSEC Terms
2. Definitions of Important DNSSEC Terms
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.
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."
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."
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.
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.
Arends, et al. Standards Track [Page 3] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends, et al. Standards Track [Page 3] RFC 4033 DNS Security Introduction and Requirements March 2005
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.
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.
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.
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.
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: 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.
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.
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.
Arends, et al. Standards Track [Page 4] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends, et al. Standards Track [Page 4] RFC 4033 DNS Security Introduction and Requirements March 2005
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.
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.
Non-Validating Stub Resolver: A less tedious term for a
non-validating security-aware stub resolver.
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.
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.
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 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.
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.
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.
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.
Arends, et al. Standards Track [Page 5] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends, et al. Standards Track [Page 5] RFC 4033 DNS Security Introduction and Requirements March 2005
Security-Oblivious <anything>: An <anything> that is not
"security-aware".
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.
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.
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.
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.
Unsigned Zone: A zone that is not signed.
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 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.
Validating Stub Resolver: A less tedious term for a validating security-aware stub resolver.
Zone Apex: Term used to describe the name at the child's side of a
zone cut. See also delegation point.
Zone Apex: 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.
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.
Arends, et al. Standards Track [Page 6] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends, et al. Standards Track [Page 6] RFC 4033 DNS Security Introduction and Requirements March 2005
3. Services Provided by DNS Security
3. Services Provided by DNS Security
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.
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.
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.
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.
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.
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.
3.1. Data Origin Authentication and Data Integrity
3.1. Data Origin Authentication and Data Integrity
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 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.)
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
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
Arends, et al. Standards Track [Page 7] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends, et al. Standards Track [Page 7] RFC 4033 DNS Security Introduction and Requirements March 2005
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.
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.
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.
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.
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.
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.
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.
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.
Arends, et al. Standards Track [Page 8] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends, et al. Standards Track [Page 8] RFC 4033 DNS Security Introduction and Requirements March 2005
3.2. Authenticating Name and Type Non-Existence
3.2. Authenticating Name and Type Non-Existence
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.
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.
4. Services Not Provided by DNS Security
4. Services Not Provided by DNS Security
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 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.
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 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.
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.
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.
5. Scope of the DNSSEC Document Set and Last Hop Issues
5. Scope of the DNSSEC Document Set and Last Hop Issues
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.
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:
A validating resolver can determine the following 4 states:
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: The validating resolver has a trust anchor, has a chain of trust, and is able to verify all the signatures in the response.
Arends, et al. Standards Track [Page 9] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends, et al. Standards Track [Page 9] RFC 4033 DNS Security Introduction and Requirements March 2005
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.
セキュリティ意識しているスタッブレゾルバとセキュリティ意識している再帰的なネームサーバの間の高度なエラーコードと方針に合図するためのメソッドはセキュリティの意識しているレゾルバとそれを使用するアプリケーションとのインタフェースの今後の活動のための話題です。 しかしながら、そのようなコミュニケーションの仕様の不足がにせのデータの伝播をアプリケーションに禁止するセキュリティの意識している再帰的なネームサーバの署名しているゾーンか展開の展開を禁止しないことに注意してください。
6. Resolver Considerations
6. レゾルバ問題
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
セキュリティ意識しているレゾルバは少なくとも実装するために義務的なアルゴリズムを使用することでデジタル署名について確かめるのに必要な暗号の機能を実行できなければなりません。 また、セキュリティ意識しているレゾルバは新たに学習されたゾーンから認証キーまで認証チェーンを形成できなければなりません、上で説明されるように。 このプロセスはDNSが帯状になる中間的に追加質問を必要とするかもしれません。
Arends, et al. Standards Track [Page 10] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends、他 標準化過程[10ページ]RFC4033DNSセキュリティ序論と2005年の要件行進
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記録を入手してください。 セキュリティ意識しているレゾルバはそれが認証チェーンを設立するのを試みる出発点として少なくとも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を入手しながら、特に難しい時間を過すかもしれません、DS RRsがゾーンカットのときにRRsの所有権のための普通のDNS規則に従わないとき。 この問題がNATsに特定でないことに注意してください: セキュリティ意識しているレゾルバと正式のネームサーバの間のどんな種類のどんなセキュリティ忘れっぽい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]がセットしたのを確実にしてください。
7. Stub Resolver Considerations
7. スタッブレゾルバ問題
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
プロトコルでそうするのが厳密に必要ではありませんが、ほとんどのDNS質問がスタッブレゾルバから発します。 スタッブレゾルバは定義上DNS解決の仕事の大部分を再帰的なネームサーバへ積み下ろすのに反復クエリーモードを使用する最小量のDNSレゾルバです。スタッブレゾルバの普及使用を与えました、DNSSEC
Arends, et al. Standards Track [Page 11] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends、他 標準化過程[11ページ]RFC4033DNSセキュリティ序論と2005年の要件行進
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.
アーキテクチャはスタッブレゾルバを考慮に入れなければなりませんが、スタッブレゾルバで必要であるセキュリティ機能はある点でセキュリティ意識している繰り返しのレゾルバで必要であるものと異なっています。
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サービスへのどんな本当の信用も置くように、スタッブレゾルバは問題の再帰的なネームサーバとそれ自体とそれらのネームサーバの間の通信チャネルの両方を信じなければなりません。 これらの問題の1番目はローカルの政策問題です: 本質では、それが使用する再帰的なネームサーバの思うままにセキュリティ忘れっぽいスタッブレゾルバはそれ自体を置かざるを得ません、それ自身のものに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.
いかなる理由でもそれが使用する再帰的なネームサーバとの役に立つ信頼関係を確立できないなら、セキュリティ意識しているスタッブレゾルバが採ることができるもうひとつの方法があります: それは、Checking Disabled(CD)ビットを質問メッセージにはめ込むことによって、それ自身の署名合法化を実行できます。 その結果、有効にしているスタッブレゾルバはゾーンの管理者とスタッブレゾルバ自身との信頼関係としてDNSSEC署名を扱うことができます。
8. Zone Considerations
8. ゾーン問題
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記録は始まり、署名のために有効期間を設置する満了時間、および署名が含んでいるゾーンデータを定義しました。
Arends, et al. Standards Track [Page 12] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends、他 標準化過程[12ページ]RFC4033DNSセキュリティ序論と2005年の要件行進
8.1. TTL Values vs. RRSIG Validity Period
8.1. TTLは、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をカバーするRRSIG RRによって指定されたRRsetのTTL値と署名有効期間の間で区別に注意するのは重要です。 DNSSECはTTL価値の定義か関数を変えません。(価値はキャッシュでデータベースの一貫性を維持されるつもりです)。 キャッシュしているレゾルバはそれらのRRsetsの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の有効期間を延ばすことができませんが、レゾルバは、署名しているRRsetの署名有効期間の満了の前に署名しているRRsetとその関連RRSIG RRのTTLのための上限としてリゾルバのキャッシュに残りながら、時間を費やすかもしれません。
8.2. New Temporal Dependency Issues for Zones
8.2. ゾーンへの新しい時の依存問題
Information in a signed zone has a temporal dependency that did not exist in the original DNS protocol. A signed zone requires regular maintenance to ensure that each RRset in the zone has a current valid RRSIG RR. The signature validity period of an RRSIG RR is an interval during which the signature for one particular signed RRset can be considered valid, and the signatures of different RRsets in a zone may expire at different times. Re-signing one or more RRsets in a zone will change one or more RRSIG RRs, which will in turn require incrementing the zone's SOA serial number to indicate that a zone change has occurred and re-signing the SOA RRset itself. Thus, re-signing any RRset in a zone may also trigger DNS NOTIFY messages and zone transfer operations.
署名しているゾーンの情報には、オリジナルのDNSプロトコルで存在しなかった時の依存があります。 署名しているゾーンは、ゾーンの各RRsetには現在の有効なRRSIG RRがあるのを保証するために定期補修を必要とします。 RRSIG RRの署名有効期間は有効であると1特定の署名しているRRsetのための署名を考えることができる間隔です、そして、ゾーンでの異なったRRsetsの署名はいろいろな時間に期限が切れるかもしれません。 ゾーンのより多くの再契約1RRsetsは1RRSIG RRsを変えるでしょう。(順番に、RRSIG RRsはゾーン変化が起こったのを示すためにゾーンのSOA通し番号を増加して、SOA RRset自身を再契約するのを必要とするでしょう)。 また、したがって、ゾーンのどんなRRsetも再契約すると、DNS NOTIFYメッセージとゾーン転送操作は引き金となるかもしれません。
9. Name Server Considerations
9. ネームサーバ問題
A security-aware name server should include the appropriate DNSSEC records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries from resolvers that have signaled their willingness to receive such records via use of the DO bit in the EDNS header, subject to message size limitations. Because inclusion of these DNSSEC RRs could easily cause UDP message truncation and fallback to TCP, a security-aware name server must also support the EDNS "sender's UDP payload" mechanism.
セキュリティ意識しているネームサーバが使用を通したそのような記録を受け取る彼らの意欲に合図したレゾルバからの質問へのすべての応答に適切なDNSSEC記録(RRSIG、DNSKEY、DS、およびNSEC)を含むべきである、EDNSヘッダーでメッセージサイズ制限を条件としてビットをしてください。 これらのDNSSEC RRsの包含が容易に引き起こすことができたので、TCP(セキュリティ意識しているまた、ネームサーバが、EDNSが「送付者のUDPペイロード」であるとサポートしなければならないのをメカニズム)にUDPメッセージトランケーションと後退を引き起こしてください。
Arends, et al. Standards Track [Page 13] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends、他 標準化過程[13ページ]RFC4033DNSセキュリティ序論と2005年の要件行進
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はゾーン転送操作の間、全体のゾーンの保全を保護するために十分ではありません、ゾーンに何か子供がいるなら署名しているゾーンさえいくつかの未署名のnonauthoritativeデータを含むとき。 したがって、ゾーンメインテナンス操作はいくつかの追加メカニズム(たぶん何らかのフォームのTSIG、SIG(0)、またはIPsecなどのチャンネルセキュリティ)を必要とするでしょう。
10. DNS Security Document Family
10. DNSセキュリティドキュメントファミリー
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 Security拡張子を加えるか、または変えるどんなドキュメントもこのカテゴリになるでしょう。 これはセキュリティ意識しているスタッブレゾルバと上流のセキュリティ意識している再帰的なネームサーバとのコミュニケーションへのどんな今後の活動も含んでいます。
The "Digital Signature Algorithm Specification" document set refers to the group of documents that describe how specific digital signature algorithms should be implemented to fit the DNSSEC resource record format. Each document in this set deals with a specific digital signature algorithm. Please see the appendix on "DNSSEC Algorithm and Digest Types" in [RFC4034] for a list of the algorithms that were defined when this core specification was written.
「デジタル署名アルゴリズム仕様」文献集合は特定のデジタル署名アルゴリズムがDNSSECリソースレコード形式に合うようにどう実装されるべきであるかを説明するドキュメントのグループを示します。 このセットにおける各ドキュメントは特定のデジタル署名アルゴリズムに対処します。 このコア仕様であるときに、定義されたアルゴリズムのリストのための[RFC4034]の「DNSSECアルゴリズムとダイジェストタイプ」の付録が書かれたのを確実にしてください。
The "Transaction Authentication Protocol" document set refers to the group of documents that deal with DNS message authentication, including secret key establishment and verification. Although not
「トランザクション認証プロトコル」文献集合はDNS通報認証に対処するドキュメントのグループを示します、秘密鍵設立と検証を含んでいて。 not
Arends, et al. Standards Track [Page 14] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends、他 標準化過程[14ページ]RFC4033DNSセキュリティ序論と2005年の要件行進
strictly part of the DNSSEC specification as defined in this set of documents, this group is noted because of its relationship to DNSSEC.
このセットのドキュメントで定義されるように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 Security拡張子を使用しようとするドキュメントを示します。 DNSSECは、少しの直接セキュリティもこれらの新しい用途に提供しませんが、それらをサポートするのに使用されるかもしれません。 このカテゴリで落ちるドキュメントはストレージにおけるDNSの使用と証明書([RFC2538])の分配について説明するものを含んでいます。
11. IANA Considerations
11. IANA問題
This overview document introduces no new IANA considerations. Please see [RFC4034] for a complete review of the IANA considerations introduced by DNSSEC.
この概要ドキュメントはどんな新しいIANA問題も紹介しません。 IANA問題の完全なレビューのための[RFC4034]がDNSSECによって導入されるのを見てください。
12. Security Considerations
12. セキュリティ問題
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.
このドキュメントは簡潔にDNSへのセキュリティがIPsecによって固定されているか、またはTSIG([RFC2845])かSIG(0)([RFC2931])などの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
非の有効にすることのセキュリティ意識しているスタッブレゾルバが定義上DNSSEC署名合法化をそれ自身のものに実行しないで、その結果、利益にこれらのチェックを実行するセキュリティ意識の(and by)の再帰的なネームサーバに対する攻撃と、そして、セキュリティ意識しているそれらとのコミュニケーションに対する攻撃に被害を受け易いのを再帰的な名
Arends, et al. Standards Track [Page 15] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends、他 標準化過程[15ページ]RFC4033DNSセキュリティ序論と2005年の要件行進
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 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はDNSをセキュリティ意識しているレゾルバとセキュリティ意識しているネームサーバに対する暗号の操作に基づく新しいクラスのサービス不能攻撃に被害を受け易くします、攻撃者が、犠牲者のリソースを消費するのにDNSSECメカニズムを使用するのを試みることができるとき。 このクラスの攻撃は少なくとも2つの形を取ります。攻撃者は、応答メッセージでRRSIG RRsをいじるか、または不必要に複雑な署名チェーンを組み立てることによって、セキュリティ意識しているリゾルバの署名認証コードのリソースを消費できるかもしれません。 また、攻撃者はDNSがダイナミックなアップデートであるとサポートするセキュリティ意識しているネームサーバにおけるリソースを消費できるかもしれません、そうでなければ、必要とするだろうよりゾーンでさらに頻繁にセキュリティ意識しているネームサーバがやむを得ずいくつかのRRsetsを再契約するアップデートメッセージのストリームを送ることによって。
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 RRsについて質問できます。 これは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に紹介して、その結果、実装バグとmisconfiguredゾーンの多くの新しい機会を紹介します。 特に、全体の正統のゾーンは、レゾルバで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 RRs)における非信頼すべきデータは署名されません。 認証チェーンを有効にするとき、これは問題を設定しませんが、それは、非信頼すべきデータ自体がゾーン転送操作の間、いじるのに被害を受け易いことを意味します。 したがって、DNSSECがRRsetsのために発生源認証とデータ保全をデータに提供できる間、そうゾーンにできません、そして、ゾーン転送操作を保護するのに、他のメカニズム(TSIG、SIG(0)、またはIPsecなどの)を使用しなければなりません。
Arends, et al. Standards Track [Page 16] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends、他 標準化過程[16ページ]RFC4033DNSセキュリティ序論と2005年の要件行進
Please see [RFC4034] and [RFC4035] for additional security considerations.
追加担保問題に関して[RFC4034]と[RFC4035]を見てください。
13. Acknowledgements
13. 承認
This document was created from the input and ideas of the members of the DNS Extensions Working Group. Although explicitly listing everyone who has contributed during the decade in which DNSSEC has been under development would be impossible, the editors would particularly like to thank the following people for their contributions to and comments on this document set: Jaap Akkerhuis, Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and Suzanne Woolf.
このドキュメントはDNS Extensions作業部会のメンバーの入力と考えから作成されました。 明らかに10年間DNSSECが開発中であった貢献している皆を記載するのは不可能でしょうが、エディタは、この文献集合に関して彼らの貢献について以下の人々に感謝するのが特に好きであり、コメントするでしょう: Jaap Akkerhuis、アンドリュースをマークしてください、デリック・アトキンス、ロイBadami、アラン・バーレット、ダン・バーンスタイン、デヴィッドBlacka、レンBudney、ランディ・ブッシュ、フランシス・デュポン、ドナルド・イーストレーク、ロバートElz、Miek Gieben、マイケル・グラフ、Olafurグドムンソン、ジルGuette、アンドレアス・グスタファソン、6月-ichiro Itojun Hagino、フィリップ・ハラム-ベイカー、ボブ・ハレー、テッド・ハーディー、ウォルター・ハワード、グレッグ・ハドソン、クリスチャンのHuitema、ジョハンIhren、スティーブン・ヤコブ、Jelteヤンセン、サイモンJosefsson; Andris Kalnozols、ピーター・コッホ、オラフKolkman、マークKosters、Suresh Krishnaswamy、ベン・ローリー、デヴィッド・ローレンス、テッドLemon、Ed Lewis、テッドLindgreen、ジョッシュ・リトルフィールド、Ripルーミス、ビル・マニング、ラス・マンディ(トーマスNarten)はニルソン、Masataka太田、マイク・パットン、ロブ・ペイン、ジム・リード、マイケル・リチャードソン、エリック・ローゼンダール、マルコス・サンス、ペッカSavola、ジェイコブSchlyter、マイクStJohns、ポールVixie、サム・ウィーラー、ブライアン・ウェリントン、およびスザンヌ・ウルフを配置します。
No doubt the above list is incomplete. We apologize to anyone we left out.
間違いなく、上記のリストは不完全です。 私たちは省いた人はだれにも謝ります。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC2535] イーストレーク3番目、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡張機能」、RFC2671、1999年8月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001.
[RFC3225] コンラッド、D.、「DNSSECのレゾルバサポートを示します」、RFC3225、2001年12月。
Arends, et al. Standards Track [Page 17] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends、他 標準化過程[17ページ]RFC4033DNSセキュリティ序論と2005年の要件行進
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001.
[RFC3226] グドムンソン、O.、「DNSSECとIPv6 A6の意識しているサーバ/レゾルバメッセージサイズ要件」、RFC3226、2001年12月。
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3445] RFC3445、「主要なリソース記録(RR)の範囲を制限し」て、マッシー、D.、およびS.は上昇して、12月は2002です。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for DNS Security Extensions", RFC
4034, March 2005.
[RFC4034]ArendsとR.とAusteinとR.とラーソンとM.とマッシー、D.とS.ローズ、「DNSセキュリティ拡張子のためのリソース記録」RFC4034(2005年3月)。
[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.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
14.2. Informative References
14.2. 有益な参照
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[RFC2136]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2308] アンドリュース、M.、「DNS質問(DNS NCACHE)の否定的キャッシュ」、RFC2308、1998年3月。
[RFC2538] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates
in the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2538] イーストレーク3番目とD.とO.グドムンソン、「ドメインネームシステム(DNS)で証明書を保存します」、RFC2538、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.、グドムンソン、O.、イーストレーク3番目、D.、およびB.ウェリントン、「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, September 2000.
2000年の[RFC2931]イーストレークD.、「DNS要求とトランザクション署名(SIG(0)s)」、RFC2931 9月3日。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、2000年11月のB.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
Signing Authority", RFC 3008, November 2000.
[RFC3008] ウェリントン、B.、「ドメインネームシステムセキュリティ(DNSSEC)署名権威」、RFC3008、2000年11月。
[RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
[RFC3090] ルイス、E.、「ゾーン状態におけるDNSセキュリティ拡大明確化」、RFC3090、2001年3月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC3597]グスタファソン、A.、「未知のDNSリソース記録(RR)タイプの取り扱い」、RFC3597、2003年9月。
Arends, et al. Standards Track [Page 18] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends、他 標準化過程[18ページ]RFC4033DNSセキュリティ序論と2005年の要件行進
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3655] ウェリントンとB.とO.グドムンソン、「DNS Authenticated Data(AD)のRedefinitionは噛み付いた」RFC3655、2003年11月。
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
[RFC3658]グドムンソン、O.、「委譲署名者(DS)リソース記録(RR)」、RFC3658、2003年12月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer (DS)", RFC 3755, May 2004.
[RFC3755]ウィーラー(S.、「委譲署名者(DS)のためのレガシーレゾルバの互換性」、RFC3755)は2004がそうするかもしれません。
[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.ルイス、「ドメインネームシステムの主要な(DNSKEY)リソース記録(RR)安全なエントリー・ポイント(9月)旗」、RFC3757(2004年4月)。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[RFC3833] アトキンスとD.とR.Austein、「ドメインネームシステム(DNS)の脅威分析」、RFC3833、2004年8月。
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
RDATA Format", RFC 3845, August 2004.
[RFC3845] Schlyter、J.、「DNSセキュリティ(DNSSEC)NextSECure(nsec)RDATA形式」、RFC3845、2004年8月。
Arends, et al. Standards Track [Page 19] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends、他 標準化過程[19ページ]RFC4033DNSセキュリティ序論と2005年の要件行進
Authors' Addresses
作者のアドレス
Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL
ロイArends Telematica Instituut Brouwerijstraat1 7523XCエンスヘーデNL
EMail: roy.arends@telin.nl
メール: roy.arends@telin.nl
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブAusteinインターネットSystems共同体950憲章通りカリフォルニア94063レッドウッドシティー(米国)
EMail: sra@isc.org
メール: sra@isc.org
Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
マットラーソンベリサインInc.21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
EMail: mlarson@verisign.com
メール: mlarson@verisign.com
Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873
ダン・マッシー・コロラド州立大学コンピュータサイエンス学部フォートコリンズ、CO80523-1873
EMail: massey@cs.colostate.edu
メール: massey@cs.colostate.edu
Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA
スコットRoseの規格の国家の研究所と技術100事務局Drive MD20899-8920ゲイザースバーグ(米国)
EMail: scott.rose@nist.gov
メール: scott.rose@nist.gov
Arends, et al. Standards Track [Page 20] RFC 4033 DNS Security Introduction and Requirements March 2005
Arends、他 標準化過程[20ページ]RFC4033DNSセキュリティ序論と2005年の要件行進
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Arends, et al. Standards Track [Page 21]
Arends、他 標準化過程[21ページ]
一覧
スポンサーリンク
