From d7d8197c4bfda7ee63a06c05626ddf2cf9c8ac44 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 27 Oct 2004 00:41:02 +0000 Subject: [PATCH] new draft --- ... => draft-ietf-dnsext-dnssec-intro-13.txt} | 504 +++--- ... draft-ietf-dnsext-dnssec-protocol-09.txt} | 900 +++++----- ...> draft-ietf-dnsext-dnssec-records-11.txt} | 334 ++-- doc/draft/draft-ietf-dnsext-ecc-key-05.txt | 814 +++++++++ ...s-33.txt => draft-ietf-dnsext-mdns-37.txt} | 698 ++++---- .../draft-ietf-dnsext-rfc2536bis-dsa-04.txt | 464 +++++ .../draft-ietf-dnsext-rfc2539bis-dhk-04.txt | 582 +++++++ ...xt-signed-nonexistence-requirements-01.txt | 755 +++++++++ ...raft-ietf-dnsext-tkey-renewal-mode-05.txt} | 313 ++-- ...t-ietf-dnsext-trustupdate-threshold-00.txt | 1501 +++++++++++++++++ .../draft-ietf-dnsext-wcard-clarify-02.txt | 1010 ----------- .../draft-ietf-dnsext-wcard-clarify-03.txt | 818 +++++++++ ...> draft-ietf-dnsop-ipv6-dns-issues-10.txt} | 836 ++++----- 13 files changed, 6784 insertions(+), 2745 deletions(-) rename doc/draft/{draft-ietf-dnsext-dnssec-intro-11.txt => draft-ietf-dnsext-dnssec-intro-13.txt} (76%) rename doc/draft/{draft-ietf-dnsext-dnssec-protocol-07.txt => draft-ietf-dnsext-dnssec-protocol-09.txt} (87%) rename doc/draft/{draft-ietf-dnsext-dnssec-records-09.txt => draft-ietf-dnsext-dnssec-records-11.txt} (87%) create mode 100644 doc/draft/draft-ietf-dnsext-ecc-key-05.txt rename doc/draft/{draft-ietf-dnsext-mdns-33.txt => draft-ietf-dnsext-mdns-37.txt} (80%) create mode 100644 doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-04.txt create mode 100644 doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-04.txt create mode 100644 doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt rename doc/draft/{draft-ietf-dnsext-tkey-renewal-mode-04.txt => draft-ietf-dnsext-tkey-renewal-mode-05.txt} (81%) create mode 100644 doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt delete mode 100644 doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt create mode 100644 doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt rename doc/draft/{draft-ietf-dnsop-ipv6-dns-issues-09.txt => draft-ietf-dnsop-ipv6-dns-issues-10.txt} (81%) diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-13.txt similarity index 76% rename from doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt rename to doc/draft/draft-ietf-dnsext-dnssec-intro-13.txt index 0783e7b26e..aadcd42eb7 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-13.txt @@ -2,7 +2,7 @@ DNS Extensions R. Arends Internet-Draft Telematica Instituut -Expires: January 13, 2005 R. Austein +Expires: April 10, 2005 R. Austein ISC M. Larson VeriSign @@ -10,17 +10,19 @@ Expires: January 13, 2005 R. Austein USC/ISI S. Rose NIST - July 15, 2004 + October 10, 2004 DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-11 + draft-ietf-dnsext-dnssec-intro-13 Status of this Memo - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering @@ -39,24 +41,24 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 13, 2005. + This Internet-Draft will expire on April 10, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2004). Abstract + + + +Arends, et al. Expires April 10, 2005 [Page 1] + +Internet-Draft DNSSEC Introduction and Requirements October 2004 + + The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This - - - -Arends, et al. Expires January 13, 2005 [Page 1] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - 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. @@ -69,7 +71,7 @@ Table of Contents 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 - 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9 + 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 10 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 @@ -106,11 +108,9 @@ Table of Contents - - -Arends, et al. Expires January 13, 2005 [Page 2] +Arends, et al. Expires April 10, 2005 [Page 2] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 1. Introduction @@ -119,25 +119,24 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 (DNSSEC). This document and its two companion documents ([I-D.ietf-dnsext-dnssec-records] and [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the - security extensions defined in RFC 2535 [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. Section 3 and Section 4 describe - the capabilities and limitations of the security extensions in - greater detail. Section 5 discusses the scope of the document set. - Section 6, Section 7, Section 8, and Section 9 discuss the effect - that these security extensions will have on resolvers, stub - resolvers, zones and name servers. + 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. Section 3 and Section 4 describe the capabilities and + limitations of the security extensions in greater detail. Section 5 + discusses the scope of the document set. Section 6, Section 7, + Section 8, and Section 9 discuss the effect that these security + extensions will have on resolvers, stub resolvers, zones and name + servers. - This document and its two companions update and obsolete RFCs 2535 - [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655 - [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress - [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but - does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 - [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts - of 3226 [RFC3226] (dealing 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. The DNS security extensions provide origin authentication and integrity protection for DNS data, as well as a means of public key @@ -164,9 +163,10 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 -Arends, et al. Expires January 13, 2005 [Page 3] + +Arends, et al. Expires April 10, 2005 [Page 3] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 2. Definitions of Important DNSSEC Terms @@ -177,23 +177,24 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 section quickly, read the rest of this document, then come back to this section. - Authentication Chain: An alternating sequence of DNSKEY RRsets and 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." as well as 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." as well as 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 @@ -211,19 +212,32 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 even if the local policy is simply to authenticate any new public key for which the resolver is able verify the signature. + 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 + + + +Arends, et al. Expires April 10, 2005 [Page 4] + +Internet-Draft DNSSEC Introduction and Requirements October 2004 + + + 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 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). - - - - - -Arends, et al. Expires January 13, 2005 [Page 4] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - + 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 @@ -259,6 +273,14 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 responses, and is capable of establishing an appropriately secured channel to a security-aware recursive name server which will provide these services on behalf of the security-aware stub + + + +Arends, et al. Expires April 10, 2005 [Page 5] + +Internet-Draft DNSSEC Introduction and Requirements October 2004 + + resolver. See also: security-aware stub resolver, validating security-aware stub resolver. @@ -270,15 +292,10 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 DNS security extensions defined in this document set. In particular, a security-aware name server is an entity which receives DNS queries, sends DNS responses, supports the EDNS0 - [RFC2671] message size extension and the DO bit [RFC3225], and + ([RFC2671]) message size extension and the DO bit ([RFC3225]), and supports the RR types and message header bits defined in this document set. - - -Arends, et al. Expires January 13, 2005 [Page 5] - - Security-Aware Recursive Name Server: An entity which acts in both the security-aware name server and security-aware resolver roles. A more cumbersome equivalent phrase would be "a security-aware @@ -288,10 +305,10 @@ Arends, et al. Expires January 13, 2005 [Page 5] (defined in section 2.4 of [RFC1034]) which understands the DNS security extensions defined in this document set. In particular, a security-aware resolver is an entity which 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. + 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]) which has enough @@ -307,8 +324,18 @@ Arends, et al. Expires January 13, 2005 [Page 5] "security-aware". Signed Zone: A zone whose RRsets are signed and which contains - properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS - records. + properly constructed DNSKEY, Resource Record Signature (RRSIG), + Next Secure (NSEC) and (optionally) DS records. + + + + + + +Arends, et al. Expires April 10, 2005 [Page 6] + +Internet-Draft DNSSEC Introduction and Requirements October 2004 + 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 @@ -328,18 +355,12 @@ Arends, et al. Expires January 13, 2005 [Page 5] security-aware stub resolver, non-validating security-aware stub resolver. - - - - -Arends, et al. Expires January 13, 2005 [Page 6] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - 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 @@ -367,30 +388,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 7] +Arends, et al. Expires April 10, 2005 [Page 7] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 3. Services Provided by DNS Security @@ -401,16 +401,19 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 data. These mechanisms are described below. These mechanisms require changes to the DNS protocol. DNSSEC adds - four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two - new message header bits (CD and 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 DO bit [RFC3225], so that a security-aware resolver can - indicate in its queries that it wishes to receive DNSSEC RRs in - response messages. + four new resource record types: Resource Record Signature, DNS Public + Key, Delegation Signer, and Next Secure (RRSIG, DNSKEY, DS and NSEC) + and two new message header bits: Checking Disabled and Authenticated + Data (CD and 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 [I-D.ietf-dnsext-dns-threats]. + 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 @@ -438,29 +441,31 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 offline when practical to do so. To discover a public key reliably via DNS resolution, the target key itself needs to be signed by either a configured authentication key or another key that has been + + + +Arends, et al. Expires April 10, 2005 [Page 8] + +Internet-Draft DNSSEC Introduction and Requirements October 2004 + + 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, - - - -Arends, et al. Expires January 13, 2005 [Page 8] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - 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 - key 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 resolver has been configured - with the hash of a key rather than the key itself, the resolver may - need 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 there is space available in the message. + 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 need 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 there is space available in the + message. The Delegation Signer (DS) RR type simplifies some of the administrative tasks involved in signing delegations across @@ -492,19 +497,19 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 protocol extensions defined in this document set. See Section 5 for further discussion. + + + +Arends, et al. Expires April 10, 2005 [Page 9] + +Internet-Draft DNSSEC Introduction and Requirements October 2004 + + 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 - - - -Arends, et al. Expires January 13, 2005 [Page 9] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - 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 @@ -551,14 +556,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - - - -Arends, et al. Expires January 13, 2005 [Page 10] +Arends, et al. Expires April 10, 2005 [Page 10] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 4. Services Not Provided by DNS Security @@ -578,9 +578,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 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 - [RFC3007]. Message authentication schemes described in [RFC2845] and - [RFC2931] address security operations that pertain to these - transactions. + ([RFC2136], [RFC3007]). Message authentication schemes described in + [RFC2845] and [RFC2931] address security operations that pertain to + these transactions. @@ -612,9 +612,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 -Arends, et al. Expires January 13, 2005 [Page 11] +Arends, et al. Expires April 10, 2005 [Page 11] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 5. Scope of the DNSSEC Document Set and Last Hop Issues @@ -668,9 +668,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 -Arends, et al. Expires January 13, 2005 [Page 12] +Arends, et al. Expires April 10, 2005 [Page 12] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 the lack of the specification of such communication does not prohibit @@ -724,9 +724,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 -Arends, et al. Expires January 13, 2005 [Page 13] +Arends, et al. Expires April 10, 2005 [Page 13] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 6. Resolver Considerations @@ -744,13 +744,19 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 If a security-aware resolver is separated from the relevant authoritative name servers by a recursive name server or by any sort - of device which acts as a proxy for DNS, and if the recursive name - server or proxy 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 device that includes a DNS proxy which is not - security-aware, the security-aware resolver may find it difficult or - impossible to obtain or validate signed DNS data. + of intermediary device which 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 which 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, since 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. 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 @@ -764,7 +770,7 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 security-aware resolver's own clock is wrong. Thus, a security-aware resolver which is part of a security-aware recursive name server will need to pay careful attention to the DNSSEC "checking disabled" (CD) - bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid + bit ([I-D.ietf-dnsext-dnssec-records]). This is in order to avoid blocking valid signatures from getting through to other security-aware resolvers which are clients of this recursive name server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure @@ -774,15 +780,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - - - - -Arends, et al. Expires January 13, 2005 [Page 14] +Arends, et al. Expires April 10, 2005 [Page 14] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 7. Stub Resolver Considerations @@ -806,20 +806,20 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 place itself at the mercy of the recursive name servers that it uses, since 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) or - TSIG would suffice, as would appropriate use of IPsec, and 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. + use of DNS transaction authentication mechanisms such as SIG(0) + ([RFC2931]) or TSIG ([RFC2845]) would suffice, as would appropriate + use of IPsec, and 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. 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 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. + 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. 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 @@ -836,9 +836,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 -Arends, et al. Expires January 13, 2005 [Page 15] +Arends, et al. Expires April 10, 2005 [Page 15] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 8. Zone Considerations @@ -862,14 +862,14 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 RRsets, regardless of whether or not the resolver is security-aware. The inception and expiration fields in the RRSIG RR - [I-D.ietf-dnsext-dnssec-records], 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 + ([I-D.ietf-dnsext-dnssec-records]), 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. 8.2 New Temporal Dependency Issues for Zones @@ -892,9 +892,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 -Arends, et al. Expires January 13, 2005 [Page 16] +Arends, et al. Expires April 10, 2005 [Page 16] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 9. Name Server Considerations @@ -948,9 +948,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 -Arends, et al. Expires January 13, 2005 [Page 17] +Arends, et al. Expires April 10, 2005 [Page 17] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 10. DNS Security Document Family @@ -975,7 +975,10 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 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. + digital signature algorithm. Please see the appendix on "DNSSEC + Algorithm and Digest Types" in [I-D.ietf-dnsext-dnssec-records] for a + list of the algorithms that were defined at the time this core + specification was written. The "Transaction Authentication Protocol" document set refers to the group of documents that deal with DNS message authentication, @@ -988,7 +991,7 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 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 the use of DNS in the storage and - distribution of certificates [RFC2538]. + distribution of certificates ([RFC2538]). @@ -1001,12 +1004,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - -Arends, et al. Expires January 13, 2005 [Page 18] +Arends, et al. Expires April 10, 2005 [Page 18] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 11. IANA Considerations @@ -1060,9 +1060,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 -Arends, et al. Expires January 13, 2005 [Page 19] +Arends, et al. Expires April 10, 2005 [Page 19] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 12. Security Considerations @@ -1071,8 +1071,8 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 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 document discusses the capabilities and - limitations of these extensions. + resource record sets. This section discusses the limitations of + these extensions. 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 @@ -1089,8 +1089,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 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, but transaction security is not - part of DNSSEC per se. + transaction authentication mechanism such as TSIG ([RFC2845]) or + SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC + per se. A non-validating security-aware stub resolver, by definition, does not perform DNSSEC signature validation on its own, and thus is @@ -1112,15 +1113,15 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 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 -Arends, et al. Expires January 13, 2005 [Page 20] +Arends, et al. Expires April 10, 2005 [Page 20] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 + needlessly complex signature chains. An attacker may also be able to consume resources in a security-aware name server which 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 @@ -1151,8 +1152,8 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 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 must be used to protect zone transfer - operations. + zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be + used to protect zone transfer operations. Please see [I-D.ietf-dnsext-dnssec-records] and [I-D.ietf-dnsext-dnssec-protocol] for additional security @@ -1171,10 +1172,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 - -Arends, et al. Expires January 13, 2005 [Page 21] +Arends, et al. Expires April 10, 2005 [Page 21] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 13. Acknowledgements @@ -1194,10 +1194,10 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 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, 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. + 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. No doubt the above list is incomplete. We apologize to anyone we left out. @@ -1228,9 +1228,9 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 -Arends, et al. Expires January 13, 2005 [Page 22] +Arends, et al. Expires April 10, 2005 [Page 22] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 14. References @@ -1272,23 +1272,6 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 14.2 Informative References - [I-D.ietf-dnsext-dns-threats] - Atkins, D. and R. Austein, "Threat Analysis Of The Domain - Name System", draft-ietf-dnsext-dns-threats-07 (work in - progress), April 2004. - - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "DNSSEC NSEC RDATA Format", - draft-ietf-dnsext-nsec-rdata-06 (work in progress), May - 2004. - - - -Arends, et al. Expires January 13, 2005 [Page 23] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. @@ -1299,6 +1282,13 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. + + +Arends, et al. Expires April 10, 2005 [Page 23] + +Internet-Draft DNSSEC Introduction and Requirements October 2004 + + [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999. @@ -1333,6 +1323,11 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure Entry Point Flag", RFC 3757, April 2004. + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004. + + [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) + RDATA Format", RFC 3845, August 2004. @@ -1340,9 +1335,14 @@ Internet-Draft DNSSEC Introduction and Requirements July 2004 -Arends, et al. Expires January 13, 2005 [Page 24] + + + + + +Arends, et al. Expires April 10, 2005 [Page 24] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 Authors' Addresses @@ -1396,9 +1396,9 @@ Authors' Addresses -Arends, et al. Expires January 13, 2005 [Page 25] +Arends, et al. Expires April 10, 2005 [Page 25] -Internet-Draft DNSSEC Introduction and Requirements July 2004 +Internet-Draft DNSSEC Introduction and Requirements October 2004 Intellectual Property Statement @@ -1452,6 +1452,6 @@ Acknowledgment -Arends, et al. Expires January 13, 2005 [Page 26] +Arends, et al. Expires April 10, 2005 [Page 26] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-09.txt similarity index 87% rename from doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt rename to doc/draft/draft-ietf-dnsext-dnssec-protocol-09.txt index 5728b35c9b..416f6c9f04 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-09.txt @@ -2,25 +2,27 @@ DNS Extensions R. Arends Internet-Draft Telematica Instituut -Expires: January 13, 2005 M. Larson - VeriSign - R. Austein +Expires: April 10, 2005 R. Austein ISC + M. Larson + VeriSign D. Massey USC/ISI S. Rose NIST - July 15, 2004 + October 10, 2004 Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-07 + draft-ietf-dnsext-dnssec-protocol-09 Status of this Memo - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering @@ -39,24 +41,24 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 13, 2005. + This Internet-Draft will expire on April 10, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2004). Abstract + + + +Arends, et al. Expires April 10, 2005 [Page 1] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + This document is part of a family of documents which describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a - - - -Arends, et al. Expires January 13, 2005 [Page 1] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document @@ -78,7 +80,7 @@ Table of Contents 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7 - 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 7 + 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 8 2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8 2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 @@ -93,68 +95,68 @@ Table of Contents 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18 - 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18 - 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19 - 4.2 Signature Verification Support . . . . . . . . . . . . . . 19 - 4.3 Determining Security Status of Data . . . . . . . . . . . 20 - 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 20 - 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 21 - 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22 - 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22 - 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23 - 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23 - 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23 + 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 19 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.2 Signature Verification Support . . . . . . . . . . . . . . 20 + 4.3 Determining Security Status of Data . . . . . . . . . . . 21 + 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 22 + 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 22 + 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 23 + 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 23 + 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 24 -Arends, et al. Expires January 13, 2005 [Page 2] +Arends, et al. Expires April 10, 2005 [Page 2] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 - 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23 - 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24 - 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 - 5.1 Special Considerations for Islands of Security . . . . . . 26 - 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26 - 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27 - 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28 - 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28 - 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30 + 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 24 + 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 24 + 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 24 + 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 25 + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 26 + 5.1 Special Considerations for Islands of Security . . . . . . 27 + 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 27 + 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 28 + 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 29 + 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 29 + 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 31 5.3.4 Authenticating A Wildcard Expanded RRset Positive - Response . . . . . . . . . . . . . . . . . . . . . . . 31 - 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31 - 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32 - 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 - 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 - A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39 - B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45 - B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45 - B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46 - B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47 - B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48 - B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49 - B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50 - B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51 - B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52 - C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54 - C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54 - C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54 - C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55 - C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55 - C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55 - C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55 - C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56 - C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56 - C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56 - Intellectual Property and Copyright Statements . . . . . . . . 57 + Response . . . . . . . . . . . . . . . . . . . . . . . 32 + 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 32 + 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 33 + 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 33 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 37 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 40 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 46 + B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 46 + B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 47 + B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 48 + B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 49 + B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 50 + B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 51 + B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 52 + B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 53 + C. Authentication Examples . . . . . . . . . . . . . . . . . . . 55 + C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 55 + C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 55 + C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 56 + C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 56 + C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 56 + C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 56 + C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 57 + C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 57 + C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 57 + Intellectual Property and Copyright Statements . . . . . . . . 58 @@ -162,11 +164,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 - - -Arends, et al. Expires January 13, 2005 [Page 3] +Arends, et al. Expires April 10, 2005 [Page 3] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 1. Introduction @@ -184,14 +184,22 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 1.1 Background and Related Documents - The reader is assumed to be familiar with the basic DNS concepts - described in [RFC1034] and [RFC1035]. + This document is part of a family of documents that define DNSSEC, + which should be read together as a set. - This document is part of a family of documents that define DNSSEC. - An introduction to DNSSEC and definition of common terms can be found - in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be - familiar with this document. A definition of the DNSSEC resource - records can be found in [I-D.ietf-dnsext-dnssec-records]. + [I-D.ietf-dnsext-dnssec-intro] contains an introduction to DNSSEC and + definitions of common terms; the reader is assumed to be familiar + with this document. [I-D.ietf-dnsext-dnssec-intro] also contains a + list of other documents updated by and obsoleted by this document + set. + + [I-D.ietf-dnsext-dnssec-records] defines the DNSSEC resource records. + + The reader is also assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035], and the subsequent documents that + update them, particularly [RFC2181] and [RFC2308]. + + This document defines the DNSSEC protocol operations. 1.2 Reserved Words @@ -212,29 +220,23 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 4] +Arends, et al. Expires April 10, 2005 [Page 4] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 2. Zone Signing DNSSEC introduces the concept of signed zones. A signed zone - includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to - the rules specified in Section 2.1, Section 2.2, Section 2.3 and - Section 2.4, respectively. A zone that does not include these - records according to the rules in this section is an unsigned zone. + includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), + Next Secure (NSEC) and (optionally) Delegation Signer (DS) records + according to the rules specified in Section 2.1, Section 2.2, Section + 2.3 and Section 2.4, respectively. A zone that does not include + these records according to the rules in this section is an unsigned + zone. DNSSEC requires a change to the definition of the CNAME resource - record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG + record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs to appear at the same owner name as a CNAME RR. DNSSEC specifies the placement of two new RR types, NSEC and DS, @@ -270,17 +272,18 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 o The RRSIG class is equal to the RRset class; o The RRSIG Type Covered field is equal to the RRset type; o The RRSIG Original TTL field is equal to the TTL of the RRset; + + + + +Arends, et al. Expires April 10, 2005 [Page 5] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + o The RRSIG RR's TTL is equal to the TTL of the RRset; o The RRSIG Labels field is equal to the number of labels in the RRset owner name, not counting the null root label and not - - - -Arends, et al. Expires January 13, 2005 [Page 5] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - counting the leftmost label if it is a wildcard; o The RRSIG Signer's Name field is equal to the name of the zone containing the RRset; and @@ -289,7 +292,11 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 The process for constructing the RRSIG RR for a given RRset is described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have - multiple RRSIG RRs associated with it. + multiple RRSIG RRs associated with it. Note that, because RRSIG RRs + are closely tied to the RRsets whose signatures they contain, RRSIG + RRs, unlike all other DNS RR types, do not form RRsets. In + particular, the TTL values among RRSIG RRs with a common owner name + do not follow the RRset rules described in [RFC2181]. An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR would add no value and would create an infinite loop in the signing @@ -322,6 +329,14 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 not the owner name of any RRset before the zone was signed. The main reasons for this are a desire for namespace consistency between signed and unsigned versions of the same zone and a desire to reduce + + + +Arends, et al. Expires April 10, 2005 [Page 6] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + the risk of response inconsistency in security oblivious recursive name servers. @@ -329,14 +344,6 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 indicate the presence of both the NSEC record itself and its corresponding RRSIG record. - - - -Arends, et al. Expires January 13, 2005 [Page 6] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - The difference between the set of owner names that require RRSIG records and the set of owner names that require NSEC records is subtle and worth highlighting. RRSIG records are present at the @@ -368,13 +375,24 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 A DS RR SHOULD point to a DNSKEY RR which is present in the child's apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed - by the corresponding private key. + by the corresponding private key. DS RRs which fail to meet these + conditions are not useful for validation, but since the DS RR and its + corresponding DNSKEY RR are in different zones, and since the DNS is + only loosely consistent, temporary mismatches can occur. The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset (that is, the NS RRset from the same zone containing the DS RRset). Construction of a DS RR requires knowledge of the corresponding DNSKEY RR in the child zone, which implies communication between the + + + +Arends, et al. Expires April 10, 2005 [Page 7] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + child and parent zones. This communication is an operational matter not covered by this document. @@ -382,16 +400,8 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 If a CNAME RRset is present at a name in a signed zone, appropriate RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that - name for secure dynamic update purposes is also allowed. Other types - MUST NOT be present at that name. - - - - -Arends, et al. Expires January 13, 2005 [Page 7] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - + name for secure dynamic update purposes is also allowed ([RFC3007]). + Other types MUST NOT be present at that name. This is a modification to the original CNAME definition given in [RFC1034]. The original definition of the CNAME RR did not allow any @@ -434,19 +444,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 8] +Arends, et al. Expires April 10, 2005 [Page 8] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 3. Serving @@ -462,9 +462,15 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 The terms "SNAME", "SCLASS", and "STYPE" in the following discussion are as used in [RFC1034]. - A security-aware name server MUST support the EDNS0 [RFC2671] message - size extension, MUST support a message size of at least 1220 octets, - and SHOULD support a message size of 4000 octets [RFC3226]. + A security-aware name server MUST support the EDNS0 ([RFC2671]) + message size extension, MUST support a message size of at least 1220 + octets, and SHOULD support a message size of 4000 octets. Since IPv6 + packets can only be fragmented by the source host, a security aware + name server SHOULD take steps to ensure that UDP datagrams it + transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 + MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460], + and [RFC3226] for further discussion of packet size and fragmentation + issues. A security-aware name server which receives a DNS query that does not include the EDNS OPT pseudo-RR or that has the DO bit clear MUST @@ -491,6 +497,14 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 DNSSEC allocates two new bits in the DNS message header: the CD (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit + + + +Arends, et al. Expires April 10, 2005 [Page 9] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + is controlled by resolvers; a security-aware name server MUST copy the CD bit from a query into the corresponding response. The AD bit is controlled by name servers; a security-aware name server MUST @@ -498,21 +512,14 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details on the behavior of these bits. - - -Arends, et al. Expires January 13, 2005 [Page 9] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - A security aware name server which synthesizes CNAME RRs from DNAME RRs as described in [RFC2672] SHOULD NOT generate signatures for the synthesized CNAME RRs. 3.1 Authoritative Name Servers - Upon receiving a relevant query that has the EDNS [RFC2671] OPT - pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name + Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT + pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name server for a signed zone MUST include additional RRSIG, NSEC, and DS RRs according to the following rules: o RRSIG RRs that can be used to authenticate a response MUST be @@ -545,6 +552,15 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 RRs have a higher priority for inclusion than any other RRsets that may need to be included. If space does not permit inclusion of these RRSIG RRs, the name server MUST set the TC bit. + + + + +Arends, et al. Expires April 10, 2005 [Page 10] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + o When placing a signed RRset in the Authority section, the name server MUST also place its RRSIG RRs in the Authority section. The RRSIG RRs have a higher priority for inclusion than any other @@ -553,17 +569,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 o When placing a signed RRset in the Additional section, the name server MUST also place its RRSIG RRs in the Additional section. If space does not permit inclusion of both the RRset and its - - - -Arends, et al. Expires January 13, 2005 [Page 10] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If - this happens, the name server MUST NOT set the TC bit solely - because these RRSIG RRs didn't fit. + associated RRSIG RRs, the name server MAY retain the RRset while + dropping the RRSIG RRs. If this happens, the name server MUST NOT + set the TC bit solely because these RRSIG RRs didn't fit. 3.1.2 Including DNSKEY RRs In a Response @@ -601,6 +609,14 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 match , does contain one or more RRsets that match via wildcard name expansion, but does not contain any RRsets that match via wildcard name + + + +Arends, et al. Expires April 10, 2005 [Page 11] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + expansion. In each of these cases, the name server includes NSEC RRs in the @@ -608,15 +624,6 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 not present in the zone and that the response that the name server is returning is correct given the data that are in the zone. - - - - -Arends, et al. Expires January 13, 2005 [Page 11] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - 3.1.3.1 Including NSEC RRs: No Data Response If the zone contains RRsets matching but contains no @@ -658,6 +665,14 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 which is not the owner name for any RRset but which is the parent name of one or more RRsets). + + + +Arends, et al. Expires April 10, 2005 [Page 12] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + 3.1.3.3 Including NSEC RRs: Wildcard Answer Response If the zone does not contain any RRsets which exactly match via wildcard name expansion, the name server MUST include the wildcard-expanded answer and the corresponding wildcard-expanded RRSIG RRs in the Answer section, and MUST include in the Authority - - - -Arends, et al. Expires January 13, 2005 [Page 12] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - section an NSEC RR and associated RRSIG RR(s) proving that the zone does not contain a closer match for . If space does not permit inclusion of the answer, NSEC and RRSIG RRs, the name @@ -714,21 +721,22 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 the nonexistent RRsets matching SNAME. The algorithm below is written for clarity, not efficiency. + + + +Arends, et al. Expires April 10, 2005 [Page 13] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + To find the NSEC which proves that no RRsets matching name N exist in the zone Z which would have held them, construct sequence S consisting of the owner names of every RRset in Z, sorted into - canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate + canonical order ([I-D.ietf-dnsext-dnssec-records]), with no duplicate names. Find the name M which would have immediately preceded N in S if any RRsets with owner name N had existed. M is the owner name of the NSEC RR which proves that no RRsets exist with owner name N. - - -Arends, et al. Expires January 13, 2005 [Page 13] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - The algorithm for finding the NSEC RR which proves that a given name is not covered by any applicable wildcard is similar, but requires an extra step. More precisely, the algorithm for finding the NSEC @@ -749,9 +757,7 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 If a DS RRset is present at the delegation point, the name server MUST return both the DS RRset and its associated RRSIG RR(s) in the - Authority section along with the NS RRset. The name server MUST - place the NS RRset before the DS RRset and its associated RRSIG - RR(s). + Authority section along with the NS RRset. If no DS RRset is present at the delegation point, the name server MUST return both the NSEC RR which proves that the DS RRset is not @@ -771,20 +777,20 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 parent zone's side of a zone cut. For example, the DS RRset for the delegation of "foo.example" is stored in the "example" zone rather than in the "foo.example" zone. This requires special processing + + + +Arends, et al. Expires April 10, 2005 [Page 14] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + rules for both name servers and resolvers, since the name server for the child zone is authoritative for the name at the zone cut by the normal DNS rules but the child zone does not contain the DS RRset. A security-aware resolver sends queries to the parent zone when looking for a needed DS RR at a delegation point (see Section 4.2). - - - -Arends, et al. Expires January 13, 2005 [Page 14] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - However, special rules are necessary to avoid confusing security-oblivious resolvers which might become involved in processing such a query (for example, in a network configuration that @@ -827,20 +833,20 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 described in Section 2. The primary objective of a zone transfer is to ensure that all authoritative name servers have identical copies of the zone. An authoritative name server that chooses to perform + + + +Arends, et al. Expires April 10, 2005 [Page 15] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + its own zone validation MUST NOT selectively reject some RRs and accept others. DS RRsets appear only on the parental side of a zone cut and are authoritative data in the parent zone. As with any other authoritative RRset, the DS RRset MUST be included in zone transfers - - - -Arends, et al. Expires January 13, 2005 [Page 15] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - of the zone in which the RRset is authoritative data: in the case of the DS RRset, this is the parent zone. @@ -852,8 +858,8 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 NSEC RR at the zone cut will never indicate the presence of an SOA RR. As with any other authoritative RRs, NSEC RRs MUST be included in zone transfers of the zone in which they are authoritative data: - the parental NSEC RR at a zone cut MUST be included zone transfers of - the parent zone, while the NSEC at the zone apex of the child zone + the parental NSEC RR at a zone cut MUST be included in zone transfers + of the parent zone, while the NSEC at the zone apex of the child zone MUST be included in zone transfers of the child zone. RRSIG RRs appear in both the parent and child zones at a zone cut, @@ -883,20 +889,20 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 composing an authoritative response. A security-aware name server MUST NOT set the AD bit in a response + + + +Arends, et al. Expires April 10, 2005 [Page 16] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic. A security-aware name server's local policy MAY consider data from an authoritative zone to be authentic without further validation, but the name server MUST NOT do so unless the name server obtained the authoritative zone via secure means (such as a secure zone transfer mechanism), and MUST - - - -Arends, et al. Expires January 13, 2005 [Page 16] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - NOT do so unless this behavior has been configured explicitly. A security-aware name server which supports recursion MUST follow the @@ -936,23 +942,23 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 to the corresponding response. The name server side of a security-aware recursive name server MUST - pass the sense of the CD bit to the resolver side along with the rest + pass the state of the CD bit to the resolver side along with the rest of an initiating query, so that the resolver side will know whether or not it is required to verify the response data it returns to the + + + +Arends, et al. Expires April 10, 2005 [Page 17] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + name server side. If the CD bit is set, it indicates that the originating resolver is willing to perform whatever authentication its local policy requires, thus the resolver side of the recursive name server need not perform authentication on the RRsets in the response. When the CD bit is set the recursive name server SHOULD, if possible, return the requested data to the originating resolver - - - -Arends, et al. Expires January 13, 2005 [Page 17] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - even if the recursive name server's local authentication policy would reject the records in question. That is, by setting the CD bit, the originating resolver has indicated that it takes responsibility for @@ -962,7 +968,7 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 If the resolver side implements a BAD cache (see Section 4.7) and the name server side receives a query which matches an entry in the resolver side's BAD cache, the name server side's response depends on - the sense of the CD bit in the original query. If the CD bit is set, + the state of the CD bit in the original query. If the CD bit is set, the name server side SHOULD return the data from the BAD cache; if the CD bit is not set, the name server side MUST return RCODE 2 (server failure). @@ -996,6 +1002,13 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 RR which is also included in the response according to the synthesis rules described in [RFC2672]. + + +Arends, et al. Expires April 10, 2005 [Page 18] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + 3.3 Example DNSSEC Responses See Appendix B for example response packets. @@ -1004,9 +1017,52 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 18] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 10, 2005 [Page 19] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 4. Resolving @@ -1020,16 +1076,17 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 4.1 EDNS Support - A security-aware resolver MUST include an EDNS [RFC2671] OPT - pseudo-RR with the DO [RFC3225] bit set when sending queries. + A security-aware resolver MUST include an EDNS ([RFC2671]) OPT + pseudo-RR with the DO ([RFC3225]) bit set when sending queries. A security-aware resolver MUST support a message size of at least 1220 octets, SHOULD support a message size of 4000 octets, and MUST - advertise the supported message size using the "sender's UDP payload - size" field in the EDNS OPT pseudo-RR. A security-aware resolver - MUST handle fragmented UDP packets correctly regardless of whether - any such fragmented packets were received via IPv4 or IPv6. Please - see [RFC3226] for discussion of these requirements. + advertise the message size it's willing to accept using the "sender's + UDP payload size" field in the EDNS OPT pseudo-RR. A security-aware + resolver's IP layer MUST handle fragmented UDP packets correctly + regardless of whether any such fragmented packets were received via + IPv4 or IPv6. Please see [RFC1122], [RFC2460] and [RFC3226] for + discussion of these requirements. 4.2 Signature Verification Support @@ -1050,21 +1107,23 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 Security aware resolvers MAY query for missing security RRs in an attempt to perform validation; implementations that choose to do so must be aware that the answers received may not be sufficient to - validate the original response. + validate the original response. For example, a zone update may have + changed (or deleted) the desired information between the original and + follow-up queries. When attempting to retrieve missing NSEC RRs which reside on the parental side at a zone cut, a security-aware iterative-mode resolver + + + +Arends, et al. Expires April 10, 2005 [Page 20] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + MUST query the name servers for the parent zone, not the child zone. When attempting to retrieve a missing DS, a security-aware - - - -Arends, et al. Expires January 13, 2005 [Page 19] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - iterative-mode resolver MUST query the name servers for the parent zone, not the child zone. As explained in Section 3.1.4.1, security-aware name servers need to apply special processing rules to @@ -1074,7 +1133,7 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 locate the parent NS RRset, the resolver can start with the delegation name, strip off the leftmost label, and query for an NS RRset by that name; if no NS RRset is present at that name, the - resolver then strips of the leftmost remaining label and retries the + resolver then strips off the leftmost remaining label and retries the query for that name, repeating this process of walking up the tree until it either finds the NS RRset or runs out of labels. @@ -1110,17 +1169,17 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones. + + + +Arends, et al. Expires April 10, 2005 [Page 21] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + 4.4 Configured Trust Anchors A security-aware resolver MUST be capable of being configured with at - - - -Arends, et al. Expires January 13, 2005 [Page 20] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - least one trusted public key or DS RR, and SHOULD be capable of being configured with multiple trusted public keys or DS RRs. Since a security-aware resolver will not be able to validate signatures @@ -1169,12 +1228,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 - - - -Arends, et al. Expires January 13, 2005 [Page 21] +Arends, et al. Expires April 10, 2005 [Page 22] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 4.6 Handling of the CD and AD bits @@ -1207,10 +1263,10 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 To prevent such unnecessary DNS traffic, security-aware resolvers MAY cache data with invalid signatures, with some restrictions. Conceptually, caching such data is similar to negative caching - [RFC2308], except that instead of caching a valid negative response, - the resolver is caching the fact that a particular answer failed to - validate. This document refers to a cache of data with invalid - signatures as a "BAD cache". + ([RFC2308]), except that instead of caching a valid negative + response, the resolver is caching the fact that a particular answer + failed to validate. This document refers to a cache of data with + invalid signatures as a "BAD cache". Resolvers which implement a BAD cache MUST take steps to prevent the cache from being useful as a denial-of-service attack amplifier. In @@ -1228,9 +1284,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 22] +Arends, et al. Expires April 10, 2005 [Page 23] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 Resolvers MUST NOT return RRsets from the BAD cache unless the @@ -1284,9 +1340,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 23] +Arends, et al. Expires April 10, 2005 [Page 24] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 4.9.3 Handling of the AD Bit @@ -1340,9 +1396,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 24] +Arends, et al. Expires April 10, 2005 [Page 25] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 5. Authenticating DNS Responses @@ -1361,7 +1417,7 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 RRset. To authenticate an apex DNSKEY RRset using an initial key, the resolver MUST: 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY - RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag + RRset, and verify that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA bit 7) set. 2. Verify that there is some RRSIG RR that covers the apex DNSKEY RRset, and that the combination of the RRSIG RR and the initial @@ -1389,20 +1445,20 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 a security-aware name server should attempt to provide the necessary DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). However, a security-aware resolver may still receive a response that - that lacks the appropriate DNSSEC RRs, whether due to configuration - issues such as an upstream security-oblivious recursive name server - that accidentally interferes with DNSSEC RRs or due to a deliberate - attack in which an adversary forges a response, strips DNSSEC RRs + lacks the appropriate DNSSEC RRs, whether due to configuration issues + such as an upstream security-oblivious recursive name server that + accidentally interferes with DNSSEC RRs or due to a deliberate attack + in which an adversary forges a response, strips DNSSEC RRs from a -Arends, et al. Expires January 13, 2005 [Page 25] +Arends, et al. Expires April 10, 2005 [Page 26] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 - from a response, or modifies a query so that DNSSEC RRs appear not to - be requested. The absence of DNSSEC data in a response MUST NOT by + response, or modifies a query so that DNSSEC RRs appear not to be + requested. The absence of DNSSEC data in a response MUST NOT by itself be taken as an indication that no authentication information exists. @@ -1433,12 +1489,12 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 authenticated, DS RRsets can be used to authenticate the delegation to a signed child zone. A DS RR identifies a DNSKEY RR in the child zone's apex DNSKEY RRset, and contains a cryptographic digest of the - child zone's DNSKEY RR. A strong cryptographic digest algorithm - ensures that an adversary can not easily generate a DNSKEY RR that - matches the digest. Thus, authenticating the digest allows a - resolver to authenticate the matching DNSKEY RR. The resolver can - then use this child DNSKEY RR to authenticate the entire child apex - DNSKEY RRset. + child zone's DNSKEY RR. Use of a strong cryptographic digest + algorithm ensures that it is computationally infeasible for an + adversary to generate a DNSKEY RR that matches the digest. Thus, + authenticating the digest allows a resolver to authenticate the + matching DNSKEY RR. The resolver can then use this child DNSKEY RR + to authenticate the entire child apex DNSKEY RRset. Given a DS RR for a delegation, the child zone's apex DNSKEY RRset can be authenticated if all of the following hold: @@ -1446,17 +1502,18 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 parent's apex DNSKEY RRset (see Section 5.3); o The Algorithm and Key Tag in the DS RR match the Algorithm field and the key tag of a DNSKEY RR in the child zone's apex DNSKEY - RRset and, when hashed using the digest algorithm specified in the - DS RR's Digest Type field, results in a digest value that matches - the Digest field of the DS RR; and + RRset and, when the DNSKEY RR's owner name and RDATA are hashed + using the digest algorithm specified in the DS RR's Digest Type + field, the resulting digest value matches the Digest field of the -Arends, et al. Expires January 13, 2005 [Page 26] +Arends, et al. Expires April 10, 2005 [Page 27] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 + DS RR; and o The matching DNSKEY RR in the child zone has the Zone Flag bit set, the corresponding private key has signed the child zone's apex DNSKEY RRset, and the resulting RRSIG RR authenticates the @@ -1504,15 +1561,15 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 5.3 Authenticating an RRset Using an RRSIG RR A validator can use an RRSIG RR and its corresponding DNSKEY RR to - attempt to authenticate RRsets. The validator first checks the RRSIG -Arends, et al. Expires January 13, 2005 [Page 27] +Arends, et al. Expires April 10, 2005 [Page 28] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 + attempt to authenticate RRsets. The validator first checks the RRSIG RR to verify that it covers the RRset, has a valid time interval, and identifies a valid DNSKEY RR. The validator then constructs the canonical form of the signed data by appending the RRSIG RDATA @@ -1560,15 +1617,15 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 5.3.2 Reconstructing the Signed Data - Once the RRSIG RR has met the validity requirements described in -Arends, et al. Expires January 13, 2005 [Page 28] +Arends, et al. Expires April 10, 2005 [Page 29] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 + Once the RRSIG RR has met the validity requirements described in Section 5.3.1, the validator needs to reconstruct the original signed data. The original signed data includes RRSIG RDATA (excluding the Signature field) and the canonical form of the RRset. Aside from @@ -1616,15 +1673,15 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 if rrsig_labels > fqdn_labels the RRSIG RR did not pass the necessary validation - checks and MUST NOT be used to authenticate this -Arends, et al. Expires January 13, 2005 [Page 29] +Arends, et al. Expires April 10, 2005 [Page 30] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 + checks and MUST NOT be used to authenticate this RRset. The canonical forms for names and RRsets are defined in @@ -1672,15 +1729,16 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 conditions in Section 5.3.1. In this case, the validator can only determine which DNSKEY RR by trying each matching public key until the validator either succeeds in validating the signature or runs out - of keys to try. -Arends, et al. Expires January 13, 2005 [Page 30] +Arends, et al. Expires April 10, 2005 [Page 31] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 + of keys to try. + If the Labels field of the RRSIG RR is not equal to the number of labels in the RRset's fully qualified owner name, then the RRset is either invalid or the result of wildcard expansion. The resolver @@ -1727,16 +1785,16 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 authenticated NSEC RR, then the NSEC RR's type bit map field lists all RR types present at that owner name, and a resolver can prove that the requested RR type does not exist by checking for the RR + + + +Arends, et al. Expires April 10, 2005 [Page 32] + +Internet-Draft DNSSEC Protocol Modifications October 2004 + + type in the bit map. If the number of labels in an authenticated NSEC RR's owner name equals the Labels field of the covering RRSIG - - - -Arends, et al. Expires January 13, 2005 [Page 31] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - RR, then the existence of the NSEC RR proves that wildcard expansion could not have been used to match the request. o If the requested RR name would appear after an authenticated NSEC @@ -1779,18 +1837,16 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 5.6 Authentication Example - Appendix C shows an example the authentication process. + Appendix C shows an example of the authentication process. - - -Arends, et al. Expires January 13, 2005 [Page 32] +Arends, et al. Expires April 10, 2005 [Page 33] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 6. IANA Considerations @@ -1844,9 +1900,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 33] +Arends, et al. Expires April 10, 2005 [Page 34] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 7. Security Considerations @@ -1855,7 +1911,7 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 key cryptography to sign and authenticate DNS resource record sets. Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general security considerations related to DNSSEC; see - [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the + [I-D.ietf-dnsext-dnssec-records] for considerations specific to the DNSSEC resource record types. An active attacker who can set the CD bit in a DNS query message or @@ -1900,9 +1956,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 34] +Arends, et al. Expires April 10, 2005 [Page 35] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 8. Acknowledgements @@ -1956,9 +2012,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 35] +Arends, et al. Expires April 10, 2005 [Page 36] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 9. References @@ -1983,6 +2039,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. @@ -1992,6 +2051,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. @@ -2004,20 +2066,14 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001. -9.2 Informative References - - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "DNSSEC NSEC RDATA Format", - draft-ietf-dnsext-nsec-rdata-06 (work in progress), May - -Arends, et al. Expires January 13, 2005 [Page 36] +Arends, et al. Expires April 10, 2005 [Page 37] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 - 2004. +9.2 Informative References [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. @@ -2031,12 +2087,18 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000. + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003. [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003. + [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) + RDATA Format", RFC 3845, August 2004. + Authors' Addresses @@ -2049,15 +2111,6 @@ Authors' Addresses EMail: roy.arends@telin.nl - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - Rob Austein Internet Systems Consortium 950 Charter Street @@ -2068,9 +2121,21 @@ Authors' Addresses -Arends, et al. Expires January 13, 2005 [Page 37] + + + +Arends, et al. Expires April 10, 2005 [Page 38] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com Dan Massey @@ -2115,18 +2180,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 38] +Arends, et al. Expires April 10, 2005 [Page 39] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 Appendix A. Signed Zone Example @@ -2180,9 +2236,9 @@ Appendix A. Signed Zone Example -Arends, et al. Expires January 13, 2005 [Page 39] +Arends, et al. Expires April 10, 2005 [Page 40] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== @@ -2236,9 +2292,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 40] +Arends, et al. Expires April 10, 2005 [Page 41] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B @@ -2292,9 +2348,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 41] +Arends, et al. Expires April 10, 2005 [Page 42] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 v/iVXSYC0b7mPSU+EOlknFpVECs= ) @@ -2348,9 +2404,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 42] +Arends, et al. Expires April 10, 2005 [Page 43] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) @@ -2404,9 +2460,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 43] +Arends, et al. Expires April 10, 2005 [Page 44] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 xS9cL2QgW7FChw16mzlkH6/vsfs= ) @@ -2460,9 +2516,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 44] +Arends, et al. Expires April 10, 2005 [Page 45] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 Appendix B. Example Responses @@ -2516,9 +2572,9 @@ B.1 Answer -Arends, et al. Expires January 13, 2005 [Page 45] +Arends, et al. Expires April 10, 2005 [Page 46] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z @@ -2572,9 +2628,9 @@ B.2 Name Error -Arends, et al. Expires January 13, 2005 [Page 46] +Arends, et al. Expires April 10, 2005 [Page 47] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB @@ -2628,9 +2684,9 @@ B.3 No Data Error -Arends, et al. Expires January 13, 2005 [Page 47] +Arends, et al. Expires April 10, 2005 [Page 48] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 ;; Header: QR AA DO RCODE=0 @@ -2684,9 +2740,9 @@ B.4 Referral to Signed Zone -Arends, et al. Expires January 13, 2005 [Page 48] +Arends, et al. Expires April 10, 2005 [Page 49] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 ;; Header: QR DO RCODE=0 @@ -2740,9 +2796,9 @@ B.5 Referral to Unsigned Zone -Arends, et al. Expires January 13, 2005 [Page 49] +Arends, et al. Expires April 10, 2005 [Page 50] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 ;; Header: QR DO RCODE=0 @@ -2796,9 +2852,9 @@ B.6 Wildcard Expansion -Arends, et al. Expires January 13, 2005 [Page 50] +Arends, et al. Expires April 10, 2005 [Page 51] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 example. 3600 NS ns1.example. @@ -2852,9 +2908,9 @@ B.7 Wildcard No Data Error -Arends, et al. Expires January 13, 2005 [Page 51] +Arends, et al. Expires April 10, 2005 [Page 52] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 ;; Answer @@ -2908,9 +2964,9 @@ B.8 DS Child Zone No Data Error -Arends, et al. Expires January 13, 2005 [Page 52] +Arends, et al. Expires April 10, 2005 [Page 53] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 ;; Header: QR AA DO RCODE=0 @@ -2964,9 +3020,9 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 -Arends, et al. Expires January 13, 2005 [Page 53] +Arends, et al. Expires April 10, 2005 [Page 54] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 Appendix C. Authentication Examples @@ -2976,12 +3032,12 @@ Appendix C. Authentication Examples C.1 Authenticating An Answer - The query in section Appendix B.1 returned an MX RRset for - "x.w.example.com". The corresponding RRSIG indicates the MX RRset - was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. - The resolver needs the corresponding DNSKEY RR in order to - authenticate this answer. The discussion below describes how a - resolver might obtain this DNSKEY RR. + The query in Appendix B.1 returned an MX RRset for "x.w.example.com". + The corresponding RRSIG indicates the MX RRset was signed by an + "example" DNSKEY with algorithm 5 and key tag 38519. The resolver + needs the corresponding DNSKEY RR in order to authenticate this + answer. The discussion below describes how a resolver might obtain + this DNSKEY RR. The RRSIG indicates the original TTL of the MX RRset was 3600 and, for the purpose of authentication, the current TTL is replaced by @@ -3020,9 +3076,9 @@ C.1.1 Authenticating the example DNSKEY RR -Arends, et al. Expires January 13, 2005 [Page 54] +Arends, et al. Expires April 10, 2005 [Page 55] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 matching "example" DNSKEY is found, the resolver checks this DNSKEY @@ -3040,15 +3096,15 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 C.2 Name Error - The query in section Appendix B.2 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. The NSEC RRs are + The query in Appendix B.2 returned NSEC RRs that prove the requested + data does not exist and no wildcard applies. The negative reply is + authenticated by verifying both NSEC RRs. The NSEC RRs are authenticated in a manner identical to that of the MX RRset discussed above. C.3 No Data Error - The query in section Appendix B.3 returned an NSEC RR that proves the + The query in Appendix B.3 returned an NSEC RR that proves the requested name exists, but the requested RR type does not exist. The negative reply is authenticated by verifying the NSEC RR. The NSEC RR is authenticated in a manner identical to that of the MX RRset @@ -3056,7 +3112,7 @@ C.3 No Data Error C.4 Referral to Signed Zone - The query in section Appendix B.4 returned a referral to the signed + The query in Appendix B.4 returned a referral to the signed "a.example." zone. The DS RR is authenticated in a manner identical to that of the MX RRset discussed above. This DS RR is used to authenticate the "a.example" DNSKEY RRset. @@ -3071,14 +3127,14 @@ C.4 Referral to Signed Zone C.5 Referral to Unsigned Zone - The query in section Appendix B.5 returned a referral to an unsigned + The query in Appendix B.5 returned a referral to an unsigned "b.example." zone. The NSEC proves that no authentication leads from -Arends, et al. Expires January 13, 2005 [Page 55] +Arends, et al. Expires April 10, 2005 [Page 56] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 "example" to "b.example" and the NSEC RR is authenticated in a manner @@ -3086,18 +3142,19 @@ Internet-Draft DNSSEC Protocol Modifications July 2004 C.6 Wildcard Expansion - The query in section Appendix B.6 returned an answer that was - produced as a result of wildcard expansion. The RRset expanded as - the similar to The corresponding RRSIG indicates the MX RRset was - signed by an "example" DNSKEY with algorithm 5 and key tag 38519. - The RRSIG indicates the original TTL of the MX RRset was 3600 and, - for the purpose of authentication, the current TTL is replaced by - 3600. The RRSIG labels field value of 2 indicates the answer the - result of wildcard expansion since the "a.z.w.example" name contains - 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", - the MX RRset is placed in canonical form and, assuming the current - time falls between the signature inception and expiration dates, the - signature is authenticated. + The query in Appendix B.6 returned an answer that was produced as a + result of wildcard expansion. The answer section contains a wildcard + RRset expanded as in a traditional DNS response and the corresponding + RRSIG indicates that the expanded wildcard MX RRset was signed by an + "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG + indicates the original TTL of the MX RRset was 3600 and, for the + purpose of authentication, the current TTL is replaced by 3600. The + RRSIG labels field value of 2 indicates the answer the result of + wildcard expansion since the "a.z.w.example" name contains 4 labels. + The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset + is placed in canonical form and, assuming the current time falls + between the signature inception and expiration dates, the signature + is authenticated. The NSEC proves that no closer match (exact or closer wildcard) could have been used to answer this query and the NSEC RR must also be @@ -3105,17 +3162,17 @@ C.6 Wildcard Expansion C.7 Wildcard No Data Error - The query in section Appendix B.7 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. + The query in Appendix B.7 returned NSEC RRs that prove the requested + data does not exist and no wildcard applies. The negative reply is + authenticated by verifying both NSEC RRs. C.8 DS Child Zone No Data Error - The query in section Appendix B.8 returned NSEC RRs that shows the - requested was answered by a child server ("example" server). The - NSEC RR indicates the presence of an SOA RR, showing the answer is - from the child . Queries for the "example" DS RRset should be sent - to the parent servers ("root" servers). + The query in Appendix B.8 returned NSEC RRs that shows the requested + was answered by a child server ("example" server). The NSEC RR + indicates the presence of an SOA RR, showing the answer is from the + child . Queries for the "example" DS RRset should be sent to the + parent servers ("root" servers). @@ -3131,10 +3188,9 @@ C.8 DS Child Zone No Data Error - -Arends, et al. Expires January 13, 2005 [Page 56] +Arends, et al. Expires April 10, 2005 [Page 57] -Internet-Draft DNSSEC Protocol Modifications July 2004 +Internet-Draft DNSSEC Protocol Modifications October 2004 Intellectual Property Statement @@ -3188,6 +3244,6 @@ Acknowledgment -Arends, et al. Expires January 13, 2005 [Page 57] +Arends, et al. Expires April 10, 2005 [Page 58] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-11.txt similarity index 87% rename from doc/draft/draft-ietf-dnsext-dnssec-records-09.txt rename to doc/draft/draft-ietf-dnsext-dnssec-records-11.txt index 79a1728435..4f0feabf6d 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-11.txt @@ -2,7 +2,7 @@ DNS Extensions R. Arends Internet-Draft Telematica Instituut -Expires: January 13, 2005 R. Austein +Expires: April 10, 2005 R. Austein ISC M. Larson VeriSign @@ -10,17 +10,19 @@ Expires: January 13, 2005 R. Austein USC/ISI S. Rose NIST - July 15, 2004 + October 10, 2004 Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-09 + draft-ietf-dnsext-dnssec-records-11 Status of this Memo - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering @@ -39,24 +41,24 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 13, 2005. + This Internet-Draft will expire on April 10, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2004). Abstract + + + +Arends, et al. Expires April 10, 2005 [Page 1] + +Internet-Draft DNSSEC Resource Records October 2004 + + This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a - - - -Arends, et al. Expires January 13, 2005 [Page 1] - -Internet-Draft DNSSEC Resource Records July 2004 - - collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital @@ -92,7 +94,7 @@ Table of Contents 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 11 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 11 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 12 - 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12 + 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 13 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 14 @@ -103,16 +105,16 @@ Table of Contents 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 19 + + + +Arends, et al. Expires April 10, 2005 [Page 2] + +Internet-Draft DNSSEC Resource Records October 2004 + + 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 19 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 19 - - - -Arends, et al. Expires January 13, 2005 [Page 2] - -Internet-Draft DNSSEC Resource Records July 2004 - - 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 19 5.2 Processing of DS RRs When Validating Responses . . . . . . 19 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 20 @@ -162,43 +164,46 @@ Internet-Draft DNSSEC Resource Records July 2004 - - -Arends, et al. Expires January 13, 2005 [Page 3] +Arends, et al. Expires April 10, 2005 [Page 3] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 1. Introduction The DNS Security Extensions (DNSSEC) introduce four new DNS resource - record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the - purpose of each resource record (RR), the RR's RDATA format, and its - presentation format (ASCII representation). + record types: DNS Public Key (DNSKEY), Resource Record Signature + (RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This + document defines the purpose of each resource record (RR), the RR's + RDATA format, and its presentation format (ASCII representation). 1.1 Background and Related Documents - The reader is assumed to be familiar with the basic DNS concepts - described in [RFC1034], [RFC1035] and subsequent RFCs that update - them: [RFC2136], [RFC2181] and [RFC2308]. + This document is part of a family of documents that define DNSSEC, + which should be read together as a set. - This document is part of a family of documents that define the DNS - security extensions. The DNS security extensions (DNSSEC) are a - collection of resource records and DNS protocol modifications that - add source authentication and data integrity to the Domain Name - System (DNS). An introduction to DNSSEC and definitions of common - terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is - assumed to be familiar with this document. A description of DNS - protocol modifications can be found in - [I-D.ietf-dnsext-dnssec-protocol]. + [I-D.ietf-dnsext-dnssec-intro] contains an introduction to DNSSEC and + definition of common terms; the reader is assumed to be familiar with + this document. [I-D.ietf-dnsext-dnssec-intro] also contains a list + of other documents updated by and obsoleted by this document set. + + [I-D.ietf-dnsext-dnssec-protocol] defines the DNSSEC protocol + operations. + + The reader is also assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035], and the subsequent documents that + update them, particularly [RFC2181] and [RFC2308]. This document defines the DNSSEC resource records. + All numeric DNS type codes given in this document are decimal + integers. + 1.2 Reserved Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. + document are to be interpreted as described in [RFC2119]. @@ -215,14 +220,9 @@ Internet-Draft DNSSEC Resource Records July 2004 - - - - - -Arends, et al. Expires January 13, 2005 [Page 4] +Arends, et al. Expires April 10, 2005 [Page 4] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 2. The DNSKEY Resource Record @@ -233,7 +233,8 @@ Internet-Draft DNSSEC Resource Records July 2004 described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its authoritative RRsets using a private key and stores the corresponding public key in a DNSKEY RR. A resolver can then use the public key to - authenticate signatures covering the RRsets in the zone. + validate signatures covering the RRsets in the zone, and thus + authenticate them. The DNSKEY RR is not intended as a record for storing arbitrary public keys and MUST NOT be used to store certificates or public keys @@ -272,15 +273,15 @@ Internet-Draft DNSSEC Resource Records July 2004 Bit 15 of the Flags field is the Secure Entry Point flag, described in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a - key intended for use as a secure entry point. This flag is only -Arends, et al. Expires January 13, 2005 [Page 5] +Arends, et al. Expires April 10, 2005 [Page 5] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 + key intended for use as a secure entry point. This flag is only intended to be to a hint to zone signing or debugging software as to the intended use of this DNSKEY record; validators MUST NOT alter their behavior during the signature validation process in any way @@ -328,15 +329,16 @@ Internet-Draft DNSSEC Resource Records July 2004 with a value of 3. The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic as specified in Appendix A.1. -Arends, et al. Expires January 13, 2005 [Page 6] +Arends, et al. Expires April 10, 2005 [Page 6] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 + integer or as an algorithm mnemonic as specified in Appendix A.1. + The Public Key field MUST be represented as a Base64 encoding of the Public Key. Whitespace is allowed within the Base64 text. For a definition of Base64 encoding, see [RFC3548]. @@ -386,11 +388,9 @@ Internet-Draft DNSSEC Resource Records July 2004 - - -Arends, et al. Expires January 13, 2005 [Page 7] +Arends, et al. Expires April 10, 2005 [Page 7] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 3. The RRSIG Resource Record @@ -444,9 +444,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 8] +Arends, et al. Expires April 10, 2005 [Page 8] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 @@ -500,9 +500,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 9] +Arends, et al. Expires April 10, 2005 [Page 9] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 The value of the Labels field MUST NOT count either the null (root) @@ -535,12 +535,12 @@ Internet-Draft DNSSEC Resource Records July 2004 authentication prior to the inception date and MUST NOT be used for authentication after the expiration date. - Signature Expiration and Inception field values are in POSIX.1 time - format: a 32-bit unsigned number of seconds elapsed since 1 January - 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The - longest interval which can be expressed by this format without - wrapping is approximately 136 years. An RRSIG RR can have an - Expiration field value which is numerically smaller than the + The Signature Expiration and Inception field values specify a date + and time in the form of a 32-bit unsigned number of seconds elapsed + since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network + byte order. The longest interval which can be expressed by this + format without wrapping is approximately 136 years. An RRSIG RR can + have an Expiration field value which is numerically smaller than the Inception field value if the expiration field value is near the 32-bit wrap-around point or if the signature is long lived. Because of this, all comparisons involving these fields MUST use "Serial @@ -556,9 +556,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 10] +Arends, et al. Expires April 10, 2005 [Page 10] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 3.1.7 The Signer's Name Field @@ -612,9 +612,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 11] +Arends, et al. Expires April 10, 2005 [Page 11] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 canonical form; and @@ -643,14 +643,19 @@ Internet-Draft DNSSEC Resource Records July 2004 decimal integer. The Signature Expiration Time and Inception Time field values MUST be - represented either as seconds since 1 January 1970 00:00:00 UTC or in - the form YYYYMMDDHHmmSS in UTC, where: + represented either as an unsigned decimal integer indicating seconds + since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in + UTC, where: YYYY is the year (0001-9999, but see Section 3.1.5); MM is the month number (01-12); DD is the day of the month (01-31); HH is the hour in 24 hours notation (00-23); mm is the minute (00-59); and SS is the second (00-59). + Note that it is always be possible to distinguish between these two + formats, because the YYYYMMDDHHmmSS format will always be exactly 14 + digits, while the decimal representation of a 32-bit unsigned integer + can never be longer than 10 digits. The Key Tag field MUST be represented as an unsigned decimal integer. @@ -660,19 +665,19 @@ Internet-Draft DNSSEC Resource Records July 2004 signature. Whitespace is allowed within the Base64 text. See Section 2.2. + + + +Arends, et al. Expires April 10, 2005 [Page 12] + +Internet-Draft DNSSEC Resource Records October 2004 + + 3.3 RRSIG RR Example The following RRSIG RR stores the signature for the A RRset of host.example.com: - - - -Arends, et al. Expires January 13, 2005 [Page 12] - -Internet-Draft DNSSEC Resource Records July 2004 - - host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( 20030220173103 2642 example.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr @@ -719,14 +724,9 @@ Internet-Draft DNSSEC Resource Records July 2004 - - - - - -Arends, et al. Expires January 13, 2005 [Page 13] +Arends, et al. Expires April 10, 2005 [Page 13] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 4. The NSEC Resource Record @@ -756,7 +756,7 @@ Internet-Draft DNSSEC Resource Records July 2004 The NSEC RR is class independent. The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [RFC2308]. + field. This is in the spirit of negative caching ([RFC2308]). 4.1 NSEC RDATA Wire Format @@ -780,9 +780,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 14] +Arends, et al. Expires April 10, 2005 [Page 14] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 last NSEC record in the zone is the name of the zone apex (the owner @@ -836,9 +836,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 15] +Arends, et al. Expires April 10, 2005 [Page 15] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 interpreted as zero octets. @@ -892,9 +892,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 16] +Arends, et al. Expires April 10, 2005 [Page 16] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 0x04 'h' 'o' 's' 't' @@ -948,9 +948,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 17] +Arends, et al. Expires April 10, 2005 [Page 17] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 5. The DS Resource Record @@ -1004,9 +1004,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 18] +Arends, et al. Expires April 10, 2005 [Page 18] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 5.1.1 The Key Tag Field @@ -1060,9 +1060,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 19] +Arends, et al. Expires April 10, 2005 [Page 19] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC @@ -1116,9 +1116,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 20] +Arends, et al. Expires April 10, 2005 [Page 20] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 6. Canonical Form and Order of Resource Records @@ -1172,9 +1172,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 21] +Arends, et al. Expires April 10, 2005 [Page 21] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, @@ -1228,9 +1228,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 22] +Arends, et al. Expires April 10, 2005 [Page 22] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 7. IANA Considerations @@ -1261,9 +1261,10 @@ Internet-Draft DNSSEC Resource Records July 2004 its use with the DNS security extensions. Each algorithm entry could refer to an algorithm that can be used for zone signing, transaction security (see [RFC2931]) or both. Values 6-251 are - available for assignment by IETF standards action. See Appendix A - for a full listing of the DNS Security Algorithm Numbers entries - at the time of writing and their status of use in DNSSEC. + available for assignment by IETF standards action ([RFC3755]). + See Appendix A for a full listing of the DNS Security Algorithm + Numbers entries at the time of writing and their status of use in + DNSSEC. [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and assigned value 0 to reserved and value 1 to SHA-1. @@ -1276,17 +1277,16 @@ Internet-Draft DNSSEC Resource Records July 2004 Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, - this registry only contains an assignment for bit 7 (the ZONE bit) - and a reservation for bit 15 for the Secure Entry Point flag (SEP - bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by - IETF Standards Action. + this registry only contains assignments for bit 7 (the ZONE bit) + and bit 15 (the Secure Entry Point flag (SEP) bit, see [RFC3757]). + As also stated in [RFC3755], bits 0-6 and 8-14 are available for + assignment by IETF Standards Action. - -Arends, et al. Expires January 13, 2005 [Page 23] +Arends, et al. Expires April 10, 2005 [Page 23] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 8. Security Considerations @@ -1315,7 +1315,8 @@ Internet-Draft DNSSEC Resource Records July 2004 resource record. It is possible for two distinct DNSKEY RRs to have the same owner name, the same algorithm type, and the same key tag. An implementation which uses only the key tag to select a DNSKEY RR - might select the wrong public key in some circumstances. + might select the wrong public key in some circumstances. Please see + Appendix B for further details. The table of algorithms in Appendix A and the key tag calculation algorithms in Appendix B include the RSA/MD5 algorithm for @@ -1339,10 +1340,9 @@ Internet-Draft DNSSEC Resource Records July 2004 - -Arends, et al. Expires January 13, 2005 [Page 24] +Arends, et al. Expires April 10, 2005 [Page 24] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 9. Acknowledgments @@ -1396,9 +1396,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 25] +Arends, et al. Expires April 10, 2005 [Page 25] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 10. References @@ -1439,6 +1439,9 @@ Internet-Draft DNSSEC Resource Records July 2004 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. + [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. @@ -1446,17 +1449,17 @@ Internet-Draft DNSSEC Resource Records July 2004 SIG(0)s)", RFC 2931, September 2000. [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + + + +Arends, et al. Expires April 10, 2005 [Page 26] + +Internet-Draft DNSSEC Resource Records October 2004 + + Name System (DNS)", RFC 3110, May 2001. [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - - - -Arends, et al. Expires January 13, 2005 [Page 26] - -Internet-Draft DNSSEC Resource Records July 2004 - - Resource Record (RR)", RFC 3445, December 2002. [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data @@ -1476,17 +1479,21 @@ Internet-Draft DNSSEC Resource Records July 2004 10.2 Informative References - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "DNSSEC NSEC RDATA Format", - draft-ietf-dnsext-nsec-rdata-06 (work in progress), May - 2004. - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. + [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name + System (DNS)", RFC 2537, March 1999. + + [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. + [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) + RDATA Format", RFC 3845, August 2004. + Authors' Addresses @@ -1501,16 +1508,9 @@ Authors' Addresses - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 27] +Arends, et al. Expires April 10, 2005 [Page 27] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 Rob Austein @@ -1564,9 +1564,9 @@ Internet-Draft DNSSEC Resource Records July 2004 -Arends, et al. Expires January 13, 2005 [Page 28] +Arends, et al. Expires April 10, 2005 [Page 28] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 Appendix A. DNSSEC Algorithm and Digest Types @@ -1600,11 +1600,11 @@ A.1 DNSSEC Algorithm Types Value Algorithm [Mnemonic] Signing References Status ----- -------------------- --------- ---------- --------- 0 reserved - 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED - 2 Diffie-Hellman [DH] n RFC 2539 - - 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL + 1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED + 2 Diffie-Hellman [DH] n [RFC2539] - + 3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL 4 Elliptic Curve [ECC] TBA - - 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY + 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY 252 Indirect [INDIRECT] n - 253 Private [PRIVATEDNS] y see below OPTIONAL 254 Private [PRIVATEOID] y see below OPTIONAL @@ -1620,9 +1620,9 @@ A.1.1 Private Algorithm Types -Arends, et al. Expires January 13, 2005 [Page 29] +Arends, et al. Expires April 10, 2005 [Page 29] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 domain name, which MUST NOT be compressed. The domain name indicates @@ -1676,9 +1676,9 @@ A.2 DNSSEC Digest Types -Arends, et al. Expires January 13, 2005 [Page 30] +Arends, et al. Expires April 10, 2005 [Page 30] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 Appendix B. Key Tag Calculation @@ -1713,7 +1713,7 @@ Appendix B. Key Tag Calculation same input. Please note that the algorithm for calculating the Key Tag is almost - but not completely identical to the familiar ones complement checksum + but not completely identical to the familiar ones-complement checksum used in many other Internet protocols. Key Tags MUST be calculated using the algorithm described here rather than the ones complement checksum. @@ -1732,9 +1732,9 @@ Appendix B. Key Tag Calculation -Arends, et al. Expires January 13, 2005 [Page 31] +Arends, et al. Expires April 10, 2005 [Page 31] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 /* @@ -1788,9 +1788,9 @@ B.1 Key Tag for Algorithm 1 (RSA/MD5) -Arends, et al. Expires January 13, 2005 [Page 32] +Arends, et al. Expires April 10, 2005 [Page 32] -Internet-Draft DNSSEC Resource Records July 2004 +Internet-Draft DNSSEC Resource Records October 2004 Intellectual Property Statement @@ -1844,6 +1844,6 @@ Acknowledgment -Arends, et al. Expires January 13, 2005 [Page 33] +Arends, et al. Expires April 10, 2005 [Page 33] diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-05.txt b/doc/draft/draft-ietf-dnsext-ecc-key-05.txt new file mode 100644 index 0000000000..dc156530a9 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ecc-key-05.txt @@ -0,0 +1,814 @@ +©À + +INTERNET-DRAFT ECC Keys in the DNS +Expires: February 2005 August 2004 + + + + Elliptic Curve KEYs in the DNS + -------- ----- ---- -- --- --- + + + Richard C. Schroeppel + Donald Eastlake 3rd + + +Status of This Document + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + or will be disclosed, and any of which I become aware will be + disclosed, in accordance with RFC 3668. + + This draft is intended to be become a Proposed Standard RFC. + Distribution of this document is unlimited. Comments should be sent + to the DNS mailing list . + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + The standard method for storing elliptic curve cryptographic keys in + the Domain Name System is specified. + + +Copyright Notice + + Copyright (C) The Internet Society. All Rights Reserved. + + + + + +R. Schroeppel, et al [Page 1] + + +INTERNET-DRAFT ECC Keys in the DNS + + +Acknowledgement + + The assistance of Hilarie K. Orman in the production of this document + is greatfully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Copyright Notice...........................................1 + + Acknowledgement............................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Elliptic Curve Data in Resource Records.................3 + 3. The Elliptic Curve Equation.............................9 + 4. How do I Compute Q, G, and Y?..........................10 + 5. Performance Considerations.............................11 + 6. Security Considerations................................11 + 7. IANA Considerations....................................11 + Copyright and Disclaimer..................................12 + + Informational References..................................13 + Normative Refrences.......................................13 + + Authors Addresses.........................................14 + Expiration and File Name..................................14 + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 2] + + +INTERNET-DRAFT ECC Keys in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. The DNS has been extended to include digital + signatures and cryptographic keys as described in [RFC intro, + protocol, records]. + + This document describes how to store elliptic curve cryptographic + (ECC) keys in the DNS so they can be used for a variety of security + purposes. A DNS elliptic curve SIG resource record is not defined. + Familiarity with ECC cryptography is assumed [Menezes]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + + + +2. Elliptic Curve Data in Resource Records + + Elliptic curve public keys are stored in the DNS within the RDATA + portions of key RRs with the structure shown below [RFC records]. + + The period of key validity may not be in the RR with the key but + could be indicated by RR(s) with signatures that authenticates the + RR(s) containing the key. + + The research world continues to work on the issue of which is the + best elliptic curve system, which finite field to use, and how to + best represent elements in the field. So, representations are + defined for every type of finite field, and every type of elliptic + curve. The reader should be aware that there is a unique finite + field with a particular number of elements, but many possible + representations of that field and its elements. If two different + representations of a field are given, they are interconvertible with + a tedious but practical precomputation, followed by a fast + computation for each field element to be converted. It is perfectly + reasonable for an algorithm to work internally with one field + representation, and convert to and from a different external + representation. + + + + + + + + + + + +R. Schroeppel, et al [Page 3] + + +INTERNET-DRAFT ECC Keys in the DNS + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S M -FMT- A B Z| + +-+-+-+-+-+-+-+-+ + | LP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | P (length determined from LP) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LF | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | F (length determined from LF) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEG | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGJ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TRDV | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H (length determined from LH) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LK | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | K (length determined from LK) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LQ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Q (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | A (length determined from LA) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ALTA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LB | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | B (length determined from LB) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C (length determined from LC) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LG | + + +R. Schroeppel, et al [Page 4] + + +INTERNET-DRAFT ECC Keys in the DNS + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | G (length determined from LG) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LY | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Y (length determined from LY) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + SMFMTABZ is a flags octet as follows: + + S = 1 indicates that the remaining 7 bits of the octet selects + one of 128 predefined choices of finite field, element + representation, elliptic curve, and signature parameters. + MFMTABZ are omitted, as are all parameters from LP through G. + LY and Y are retained. + + If S = 0, the remaining parameters are as in the picture and + described below. + + M determines the type of field underlying the elliptic curve. + + M = 0 if the field is a GF[2^N] field; + + M = 1 if the field is a (mod P) or GF[P^D] field with P>2. + + FMT is a three bit field describing the format of the field + representation. + + FMT = 0 for a (mod P) field. + > 0 for an extension field, either GF[2^D] or GF[P^D]. + The degree D of the extension, and the field polynomial + must be specified. The field polynomial is always monic + (leading coefficient 1.) + + FMT = 1 The field polynomial is given explicitly; D is implied. + + If FMT >=2, the degree D is given explicitly. + + = 2 The field polynomial is implicit. + = 3 The field polynomial is a binomial. P>2. + = 4 The field polynomial is a trinomial. + = 5 The field polynomial is the quotient of a trinomial by a + short polynomial. P=2. + = 6 The field polynomial is a pentanomial. P=2. + + Flags A and B apply to the elliptic curve parameters. + + + + + + +R. Schroeppel, et al [Page 5] + + +INTERNET-DRAFT ECC Keys in the DNS + + + A = 1 When P>=5, the curve parameter A is negated. If P=2, then + A=1 indicates that the A parameter is special. See the + ALTA parameter below, following A. The combination A=1, + P=3 is forbidden. + + B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, + then B=1 indicates an alternate elliptic curve equation is + used. When P=2 and B=1, an additional curve parameter C + is present. + + The Z bit SHOULD be set to zero on creation of an RR and MUST be + ignored when processing an RR (when S=0). + + Most of the remaining parameters are present in some formats and + absent in others. The presence or absence of a parameter is + determined entirely by the flags. When a parameter occurs, it is in + the order defined by the picture. + + Of the remaining parameters, PFHKQABCGY are variable length. When + present, each is preceded by a one-octet length field as shown in the + diagram above. The length field does not include itself. The length + field may have values from 0 through 110. The parameter length in + octets is determined by a conditional formula: If LL<=64, the + parameter length is LL. If LL>64, the parameter length is 16 times + (LL-60). In some cases, a parameter value of 0 is sensible, and MAY + be represented by an LL value of 0, with the data field omitted. A + length value of 0 represents a parameter value of 0, not an absent + parameter. (The data portion occupies 0 space.) There is no + requirement that a parameter be represented in the minimum number of + octets; high-order 0 octets are allowed at the front end. Parameters + are always right adjusted, in a field of length defined by LL. The + octet-order is always most-significant first, least-significant last. + The parameters H and K may have an optional sign bit stored in the + unused high-order bit of their length fields. + + LP defines the length of the prime P. P must be an odd prime. The + parameters LP,P are present if and only if the flag M=1. If M=0, the + prime is 2. + + LF,F define an explicit field polynomial. This parameter pair is + present only when FMT = 1. The length of a polynomial coefficient is + ceiling(log2 P) bits. Coefficients are in the numerical range + [0,P-1]. The coefficients are packed into fixed-width fields, from + higher order to lower order. All coefficients must be present, + including any 0s and also the leading coefficient (which is required + to be 1). The coefficients are right justified into the octet string + of length specified by LF, with the low-order "constant" coefficient + at the right end. As a concession to storage efficiency, the higher + order bits of the leading coefficient may be elided, discarding high- + order 0 octets and reducing LF. The degree is calculated by + + +R. Schroeppel, et al [Page 6] + + +INTERNET-DRAFT ECC Keys in the DNS + + + determining the bit position of the left most 1-bit in the F data + (counting the right most bit as position 0), and dividing by + ceiling(log2 P). The division must be exact, with no remainder. In + this format, all of the other degree and field parameters are + omitted. The next parameters will be LQ,Q. + + If FMT>=2, the degree of the field extension is specified explicitly, + usually along with other parameters to define the field polynomial. + + DEG is a two octet field that defines the degree of the field + extension. The finite field will have P^DEG elements. DEG is + present when FMT>=2. + + When FMT=2, the field polynomial is specified implicitly. No other + parameters are required to define the field; the next parameters + present will be the LQ,Q pair. The implicit field poynomial is the + lexicographically smallest irreducible (mod P) polynomial of the + correct degree. The ordering of polynomials is by highest-degree + coefficients first -- the leading coefficient 1 is most important, + and the constant term is least important. Coefficients are ordered + by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of + degree D is X^D (which is not irreducible). The next is X^D+1, which + is sometimes irreducible, followed by X^D-1, which isn‚ÇÖt. Assuming + odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + + X, X^D + X + 1, X^D + X - 1, etc. + + When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be + odd. The polynomial is determined by the degree and the low order + term K. Of all the field parameters, only the LK,K parameters are + present. The high-order bit of the LK octet stores on optional sign + for K; if the sign bit is present, the field polynomial is X^DEG - K. + + When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + + K. When P=2, the H and K parameters are implicitly 1, and are + omitted from the representation. Only DEG and DEGH are present; the + next parameters are LQ,Q. When P>2, then LH,H and LK,K are + specified. Either or both of LH, LK may contain a sign bit for its + parameter. + + When FMT=5, then P=2 (only). The field polynomial is the exact + quotient of a trinomial divided by a small polynomial, the trinomial + divisor. The small polynomial is right-adjusted in the two octet + field TRDV. DEG specifies the degree of the field. The degree of + TRDV is calculated from the position of the high-order 1 bit. The + trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If + DEGH is 0, the middle term is omitted from the trinomial. The + quotient must be exact, with no remainder. + + When FMT=6, then P=2 (only). The field polynomial is a pentanomial, + with the degrees of the middle terms given by the three 2-octet + + +R. Schroeppel, et al [Page 7] + + +INTERNET-DRAFT ECC Keys in the DNS + + + values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + + X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI + > DEGJ > 0. + + DEGH, DEGI, DEGJ are two-octet fields that define the degree of + a term in a field polynomial. DEGH is present when FMT = 4, + 5, or 6. DEGI and DEGJ are present only when FMT = 6. + + TRDV is a two-octet right-adjusted binary polynomial of degree < + 16. It is present only for FMT=5. + + LH and H define the H parameter, present only when FMT=4 and P + is odd. The high bit of LH is an optional sign bit for H. + + LK and K define the K parameter, present when FMT = 3 or 4, and + P is odd. The high bit of LK is an optional sign bit for K. + + The remaining parameters are concerned with the elliptic curve and + the signature algorithm. + + LQ defines the length of the prime Q. Q is a prime > 2^159. + + In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data + member of the pair is an element from the finite field defined + earlier. The length field defines a long octet string. Field + elements are represented as (mod P) polynomials of degree < DEG, with + DEG or fewer coefficients. The coefficients are stored from left to + right, higher degree to lower, with the constant term last. The + coefficients are represented as integers in the range [0,P-1]. Each + coefficient is allocated an area of ceiling(log2 P) bits. The field + representation is right-justified; the "constant term" of the field + element ends at the right most bit. The coefficients are fitted + adjacently without regard for octet boundaries. (Example: if P=5, + three bits are used for each coefficient. If the field is GF[5^75], + then 225 bits are required for the coefficients, and as many as 29 + octets may be needed in the data area. Fewer octets may be used if + some high-order coefficients are 0.) If a flag requires a field + element to be negated, each non-zero coefficient K is replaced with + P-K. To save space, 0 bits may be removed from the left end of the + element representation, and the length field reduced appropriately. + This would normally only happen with A,B,C, because the designer + chose curve parameters with some high-order 0 coefficients or bits. + + If the finite field is simply (mod P), then the field elements are + simply numbers (mod P), in the usual right-justified notation. If + the finite field is GF[2^D], the field elements are the usual right- + justified polynomial basis representation. + + + + + +R. Schroeppel, et al [Page 8] + + +INTERNET-DRAFT ECC Keys in the DNS + + + LA,A is the first parameter of the elliptic curve equation. + When P>=5, the flag A = 1 indicates A should be negated (mod + P). When P=2 (indicated by the flag M=0), the flag A = 1 + indicates that the parameter pair LA,A is replaced by the two + octet parameter ALTA. In this case, the parameter A in the + curve equation is x^ALTA, where x is the field generator. + Parameter A often has the value 0, which may be indicated by + LA=0 (with no A data field), and sometimes A is 1, which may + be represented with LA=1 and a data field of 1, or by setting + the A flag and using an ALTA value of 0. + + LB,B is the second parameter of the elliptic curve equation. + When P>=5, the flag B = 1 indicates B should be negated (mod + P). When P=2 or 3, the flag B selects an alternate curve + equation. + + LC,C is the third parameter of the elliptic curve equation, + present only when P=2 (indicated by flag M=0) and flag B=1. + + LG,G defines a point on the curve, of order Q. The W-coordinate + of the curve point is given explicitly; the Z-coordinate is + implicit. + + LY,Y is the user‚ÇÖs public signing key, another curve point of + order Q. The W-coordinate is given explicitly; the Z- + coordinate is implicit. The LY,Y parameter pair is always + present. + + + +3. The Elliptic Curve Equation + + (The coordinates of an elliptic curve point are named W,Z instead of + the more usual X,Y to avoid confusion with the Y parameter of the + signing key.) + + The elliptic curve equation is determined by the flag octet, together + with information about the prime P. The primes 2 and 3 are special; + all other primes are treated identically. + + If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 + + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. + If A and/or B is negative (i.e., in the range from P/2 to P), and + P>=5, space may be saved by putting the sign bit(s) in the A and B + bits of the flags octet, and the magnitude(s) in the parameter + fields. + + If M=1 and P=3, the B flag has a different meaning: it specifies an + alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of + the right-hand-side is different. When P=3, this equation is more + + +R. Schroeppel, et al [Page 9] + + +INTERNET-DRAFT ECC Keys in the DNS + + + commonly used. + + If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + + A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A + parameter can often be 0 or 1, or be chosen as a single-1-bit value. + The flag B is used to select an alternate curve equation, Z^2 + C*Z = + W^3 + A*W + B. This is the only time that the C parameter is used. + + + +4. How do I Compute Q, G, and Y? + + The number of points on the curve is the number of solutions to the + curve equation, + 1 (for the "point at infinity"). The prime Q must + divide the number of points. Usually the curve is chosen first, then + the number of points is determined with Schoof‚ÇÖs algorithm. This + number is factored, and if it has a large prime divisor, that number + is taken as Q. + + G must be a point of order Q on the curve, satisfying the equation + + Q * G = the point at infinity (on the elliptic curve) + + G may be chosen by selecting a random [RFC 1750] curve point, and + multiplying it by (number-of-points-on-curve/Q). G must not itself + be the "point at infinity"; in this astronomically unlikely event, a + new random curve point is recalculated. + + G is specified by giving its W-coordinate. The Z-coordinate is + calculated from the curve equation. In general, there will be two + possible Z values. The rule is to choose the "positive" value. + + In the (mod P) case, the two possible Z values sum to P. The smaller + value is less than P/2; it is used in subsequent calculations. In + GF[P^D] fields, the highest-degree non-zero coefficient of the field + element Z is used; it is chosen to be less than P/2. + + In the GF[2^N] case, the two possible Z values xor to W (or to the + parameter C with the alternate curve equation). The numerically + smaller Z value (the one which does not contain the highest-order 1 + bit of W (or C)) is used in subsequent calculations. + + Y is specified by giving the W-coordinate of the user‚ÇÖs public + signature key. The Z-coordinate value is determined from the curve + equation. As with G, there are two possible Z values; the same rule + is followed for choosing which Z to use. + + + + + + +R. Schroeppel, et al [Page 10] + + +INTERNET-DRAFT ECC Keys in the DNS + + + During the key generation process, a random [RFC 1750] number X must + be generated such that 1 <= X <= Q-1. X is the private key and is + used in the final step of public key generation where Y is computed + as + + Y = X * G (as points on the elliptic curve) + + If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 + in the (mod P) case, or the high-order non-zero coefficient of Z > + P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the + GF[2^N] case), then X must be replaced with Q-X. This will + correspond to the correct Z-coordinate. + + + +5. Performance Considerations + + Elliptic curve signatures use smaller moduli or field sizes than RSA + and DSA. Creation of a curve is slow, but not done very often. Key + generation is faster than RSA or DSA. + + DNS implementations have been optimized for small transfers, + typically less than 512 octets including DNS overhead. Larger + transfers will perform correctly and and extensions have been + standardized to make larger transfers more efficient [RFC 2671]. + However, it is still advisable at this time to make reasonable + efforts to minimize the size of RR sets stored within the DNS + consistent with adequate security. + + + +6. Security Considerations + + Keys retrieved from the DNS should not be trusted unless (1) they + have been securely obtained from a secure resolver or independently + verified by the user and (2) this secure resolver and secure + obtainment or independent verification conform to security policies + acceptable to the user. As with all cryptographic algorithms, + evaluating the necessary strength of the key is essential and + dependent on local policy. + + Some specific key generation considerations are given in the body of + this document. + + + +7. IANA Considerations + + Assignment of meaning to the remaining ECC data flag bits or to + values of ECC fields outside the ranges for which meaning in defined + + +R. Schroeppel, et al [Page 11] + + +INTERNET-DRAFT ECC Keys in the DNS + + + in this document requires an IETF consensus as defined in [RFC 2434]. + + + +Copyright and Disclaimer + + Copyright (C) The Internet Society 2004. 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. + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 12] + + +INTERNET-DRAFT ECC Keys in the DNS + + +Informational References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness + Recommendations for Security", 12/29/1994. + + [RFC intro] - "DNS Security Introduction and Requirements", R. + Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress, + draft-ietf-dnsext-dnssec-intro-*.txt. + + [RFC protocol] - "Protocol Modifications for the DNS Security + Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose, + work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt. + + [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August + 1999. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + [Menezes] - Alfred Menezes, "Elliptic Curve Public Key + Cryptosystems", 1993 Kluwer. + + [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", + 1986, Springer Graduate Texts in mathematics #106. + + + +Normative Refrences + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", October 1998. + + [RFC records] - "Resource Records for the DNS Security Extensions", + R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in + progress, draft-ietf-dnsext-dnssec-records- *.txt. + + + + + + + + +R. Schroeppel, et al [Page 13] + + +INTERNET-DRAFT ECC Keys in the DNS + + +Authors Addresses + + Rich Schroeppel + 500 S. Maple Drive + Woodland Hills, UT 84653 USA + + Telephone: 1-801-423-7998(h) + 1-505-844-9079(w) + Email: rschroe@sandia.gov + + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-634-2066 (h) + +1 508-786-7554 (w) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in February 2004. + + Its file name is draft-ietf-dnsext-ecc-key-05.txt. + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 14] + + diff --git a/doc/draft/draft-ietf-dnsext-mdns-33.txt b/doc/draft/draft-ietf-dnsext-mdns-37.txt similarity index 80% rename from doc/draft/draft-ietf-dnsext-mdns-33.txt rename to doc/draft/draft-ietf-dnsext-mdns-37.txt index 8dcacc8bb9..86d7de88a9 100644 --- a/doc/draft/draft-ietf-dnsext-mdns-33.txt +++ b/doc/draft/draft-ietf-dnsext-mdns-37.txt @@ -7,12 +7,13 @@ DNSEXT Working Group Levon Esibov INTERNET-DRAFT Bernard Aboba Category: Standards Track Dave Thaler - Microsoft -18 July 2004 - + Microsoft +20 October 2004 Linklocal Multicast Name Resolution (LLMNR) +Status of this Memo + By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with @@ -34,7 +35,7 @@ Category: Standards Track Dave Thaler The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 2, 2005. + This Internet-Draft will expire on April 22, 2005. Copyright Notice @@ -54,34 +55,33 @@ Abstract - Esibov, Aboba & Thaler Standards Track [Page 1] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 Table of Contents 1. Introduction .......................................... 3 - 1.1 Requirements .................................... 4 + 1.1 Requirements .................................... 3 1.2 Terminology ..................................... 4 2. Name resolution using LLMNR ........................... 4 2.1 LLMNR packet format ............................. 6 2.2 Sender behavior ................................. 8 - 2.3 Responder behavior .............................. 8 + 2.3 Responder behavior .............................. 9 2.4 Unicast queries ................................. 11 2.5 Off-link detection .............................. 11 2.6 Responder responsibilities ...................... 12 2.7 Retransmission and jitter ....................... 13 - 2.8 DNS TTL ......................................... 13 + 2.8 DNS TTL ......................................... 14 2.9 Use of the authority and additional sections .... 14 3. Usage model ........................................... 14 3.1 LLMNR configuration ............................. 15 -4. Conflict resolution ................................... 16 +4. Conflict resolution ................................... 17 4.1 Considerations for multiple interfaces .......... 18 4.2 API issues ...................................... 19 5. Security considerations ............................... 20 @@ -90,14 +90,14 @@ Table of Contents 5.3 Cache and port separation ....................... 22 5.4 Authentication .................................. 22 6. IANA considerations ................................... 22 -7. References ............................................ 22 - 7.1 Normative References ............................ 22 +7. References ............................................ 23 + 7.1 Normative References ............................ 23 7.2 Informative References .......................... 23 -Acknowledgments .............................................. 24 +Acknowledgments .............................................. 25 Authors' Addresses ........................................... 25 Intellectual Property Statement .............................. 25 Disclaimer of Validity ....................................... 26 -Full Copyright Statement ..................................... 26 +Copyright Statement .......................................... 26 @@ -121,7 +121,7 @@ Esibov, Aboba & Thaler Standards Track [Page 2] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 1. Introduction @@ -156,10 +156,7 @@ INTERNET-DRAFT LLMNR 18 July 2004 occur if LLMNR deployment is successful, the need arises for multicast name resolution beyond the link-scope, or multicast routing becomes ubiquitous. For example, expanded support for multicast name - resolution might be required for mobile ad-hoc networking scenarios, - or where no DNS server is available that is authoritative for the - names of local hosts, and can support dynamic DNS, such as in - wireless hotspots. + resolution might be required for mobile ad-hoc networks. Once we have experience in LLMNR deployment in terms of administrative issues, usability and impact on the network, it will @@ -170,8 +167,11 @@ INTERNET-DRAFT LLMNR 18 July 2004 using LLMNR in particular, is outside of the scope of this document, as is name resolution over non-multicast capable media. +1.1. Requirements - + In this document, several words are used to signify the requirements + of the specification. The key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", @@ -181,14 +181,9 @@ Esibov, Aboba & Thaler Standards Track [Page 3] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 -1.1. Requirements - - In this document, several words are used to signify the requirements - of the specification. The key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. @@ -206,8 +201,9 @@ Routable Address routable addresses, as well as private addresses. Reachable - An address is considered reachable over a link if either an ARP or - neighbor discovery cache entry exists for the address on the link. + An LLMNR responder considers one of its addresses reachable over a + link if it will respond to an ARP or Neighbor Discovery query for + that address sent over the link. Responder A host that listens to LLMNR queries, and responds to those for @@ -216,6 +212,14 @@ Responder Sender A host that sends an LLMNR query. +UNIQUE + There are some scenarios when multiple responders may respond to + the same query. There are other scenarios when only one responder + may respond to a query. Resource records for which only a single + responder is anticipated are referred to as UNIQUE. Resource + record uniqueness is configured on the responder, and therefore + uniqueness verification is the responder's responsibility. + 2. Name resolution using LLMNR LLMNR is a peer-to-peer name resolution protocol that is not intended @@ -228,10 +232,6 @@ Sender queries, is FF02:0:0:0:0:0:1:3. Typically a host is configured as both an LLMNR sender and a - responder. A host MAY be configured as a sender, but not a - responder. However, a host configured as a responder MUST act as a - sender to verify the uniqueness of names as described in Section 4. - This document does not specify how names are chosen or configured. @@ -241,9 +241,13 @@ Esibov, Aboba & Thaler Standards Track [Page 4] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 + responder. A host MAY be configured as a sender, but not a + responder. However, a host configured as a responder MUST act as a + sender to verify the uniqueness of names as described in Section 4. + This document does not specify how names are chosen or configured. This may occur via any mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315]. @@ -252,7 +256,7 @@ INTERNET-DRAFT LLMNR 18 July 2004 all interfaces, at all times. Enabling LLMNR for use in situations where a DNS server has been configured will result in a change in default behavior without a simultaneous update to configuration - information. Where this is considered undesirable, LLMNR SHOULD NOT + information. Where this is considered undesirable, LLMNR SHOULD NOT be enabled by default, so that hosts will neither listen on the link- scope multicast address, nor will they send queries to that address. @@ -261,10 +265,10 @@ INTERNET-DRAFT LLMNR 18 July 2004 conditions are met: [1] No manual or automatic DNS configuration has been - performed. If an interface has been configured with DNS - server address(es), then LLMNR SHOULD NOT be used as the - primary name resolution mechanism on that interface, although - it MAY be used as a name resolution mechanism of last resort. + performed. If DNS server address(es) have been + configured, then LLMNR SHOULD NOT be used as the + primary name resolution mechanism, although it MAY + be used as a secondary name resolution mechanism. [2] DNS servers do not respond. @@ -288,10 +292,6 @@ INTERNET-DRAFT LLMNR 18 July 2004 multicast query by sending a unicast UDP response to the sender. Unicast queries are responded to as indicated in Section 2.4. - [d] Upon reception of the response, the sender processes it. - - Further details of sender and responder behavior are provided in the - sections that follow. @@ -301,9 +301,14 @@ Esibov, Aboba & Thaler Standards Track [Page 5] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 + [d] Upon reception of the response, the sender processes it. + + Further details of sender and responder behavior are provided in the + sections that follow. + 2.1. LLMNR packet format LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 @@ -311,8 +316,8 @@ INTERNET-DRAFT LLMNR 18 July 2004 UDP queries and responses only as large as are known to be permissible without causing fragmentation. When in doubt a maximum packet size of 512 octets SHOULD be used. LLMNR implementations MUST - accept UDP queries and responses as large as permitted by the link - MTU. + accept UDP queries and responses as large as the smaller of the link + MTU or 8192 octets. 2.1.1. LLMNR header format @@ -341,17 +346,12 @@ ID A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied from the query to the response and can be used by the sender to match responses to outstanding queries. The ID field in a query SHOULD be set to a pseudo-random - value. + value. For advice on generation of pseudo-random values, please + consult [RFC1750]. QR A one bit field that specifies whether this message is an LLMNR query (0), or an LLMNR response (1). -OPCODE - A four bit field that specifies the kind of query in this message. - This value is set by the originator of a query and copied into the - response. This specification defines the behavior of standard - queries and responses (opcode value of zero). Future - specifications may define the use of other opcodes with LLMNR. @@ -361,9 +361,15 @@ Esibov, Aboba & Thaler Standards Track [Page 6] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 +OPCODE + A four bit field that specifies the kind of query in this message. + This value is set by the originator of a query and copied into the + response. This specification defines the behavior of standard + queries and responses (opcode value of zero). Future + specifications may define the use of other opcodes with LLMNR. LLMNR senders and responders MUST support standard queries (opcode value of zero). LLMNR queries with unsupported OPCODE values MUST be silently discarded by responders. @@ -371,11 +377,10 @@ INTERNET-DRAFT LLMNR 18 July 2004 TC TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel. The TC bit MUST NOT be set in an LLMNR query and if set is ignored - by an LLMNR responder. If the TC bit is set an LLMNR response, - then the sender MAY use the response if it contains all necessary - information, or the sender MAY discard the response and resend the - LLMNR query over TCP using the unicast address of the responder as - the destination address. See [RFC2181] and Section 2.4 of this + by an LLMNR responder. If the TC bit is set in an LLMNR response, + then the sender SHOULD discard the response and resend the LLMNR + query over TCP using the unicast address of the responder as the + destination address. See [RFC2181] and Section 2.4 of this specification for further discussion of the TC bit. Z Reserved for future use. Implementations of this specification @@ -399,19 +404,14 @@ RCODE LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. This will cause the query to be resent using TCP, and allow the inclusion of a non-zero RCODE in the response to - the TCP query. Responding with the TC bit set is preferrable to - not sending a response, since it enables errors to be diagnosed. + the TCP query. Responding with the TC bit set is preferable to not + sending a response, since it enables errors to be diagnosed. Since LLMNR responders only respond to LLMNR queries for names for which they are authoritative, LLMNR responders MUST NOT respond with an RCODE of 3; instead, they should not respond at all. LLMNR implementations MUST support EDNS0 [RFC2671] and extended - RCODE values. - -QDCOUNT - An unsigned 16 bit integer specifying the number of entries in the - question section. A sender MUST place only one question into the @@ -421,9 +421,14 @@ Esibov, Aboba & Thaler Standards Track [Page 7] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 + RCODE values. + +QDCOUNT + An unsigned 16 bit integer specifying the number of entries in the + question section. A sender MUST place only one question into the question section of an LLMNR query. LLMNR responders MUST silently discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders MUST silently discard LLMNR responses with QDCOUNT not equal to @@ -447,7 +452,7 @@ ARCOUNT 2.2. Sender behavior A sender may send an LLMNR query for any legal resource record type - (e.g. A, AAAA, SRV, etc.) to the link-scope multicast address. + (e.g., A, AAAA, SRV, etc.) to the link-scope multicast address. As described in Section 2.4, a sender may also send a unicast query. Sections 2 and 3 describe the circumstances in which LLMNR queries @@ -465,13 +470,8 @@ ARCOUNT indicate preference, the sender SHOULD preserve ordering in the response to the querying application. -2.3. Responder behavior - - An LLMNR response MUST be sent to the sender via unicast. - - Upon configuring an IP address responders typically will synthesize - corresponding A, AAAA and PTR RRs so as to be able to respond to - LLMNR queries for these RRs. An SOA RR is synthesized only when a + The sender MUST anticipate receiving multiple replies to the same + LLMNR query, in the event that several LLMNR enabled computers @@ -481,30 +481,43 @@ Esibov, Aboba & Thaler Standards Track [Page 8] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 + receive the query and respond with valid answers. When multiple + valid answers are received, they may first be concatenated, and then + treated in the same manner that multiple RRs received from the same + DNS server would; the sender perceives no inherent conflict in the + receipt of multiple responses. + +2.3. Responder behavior + + An LLMNR response MUST be sent to the sender via unicast. + + Upon configuring an IP address, responders typically will synthesize + corresponding A, AAAA and PTR RRs so as to be able to respond to + LLMNR queries for these RRs. An SOA RR is synthesized only when a responder has another RR as well; the SOA RR MUST NOT be the only RR that a responder has. However, in general whether RRs are manually or automatically created is an implementation decision. For example, a host configured to have computer name "host1" and to be a member of the "example.com" domain, and with IPv4 address - 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be + 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the following records: - host1. IN A 10.1.1.1 + host1. IN A 192.0.2.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - host1.example.com. IN A 10.1.1.1 + host1.example.com. IN A 192.0.2.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - 1.1.1.10.in-addr.arpa. IN PTR host1. + 1.2.0.192.in-addr.arpa. IN PTR host1. IN PTR host1.example.com. - 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa - IN PTR host1. - IN PTR host1.example.com + 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2. + ip6.arpa IN PTR host1. (line split for formatting reasons) + IN PTR host1.example.com. An LLMNR responder might be further manually configured with the name of a local mail server with an MX RR included in the "host1." and @@ -519,19 +532,6 @@ INTERNET-DRAFT LLMNR 18 July 2004 [b] Responders MUST direct responses to the port from which the query was sent. When queries are received via TCP this is an inherent - part of the transport protocol. For queries received by UDP the - responder MUST take note of the source port and use that as the - destination port in the response. Responses SHOULD always be sent - from the port to which they were directed. - -[c] Responders MUST respond to LLMNR queries for names and addresses - they are authoritative for. This applies to both forward and - reverse lookups. - -[d] Responders MUST NOT respond to LLMNR queries for names they are not - authoritative for. - - @@ -541,10 +541,23 @@ Esibov, Aboba & Thaler Standards Track [Page 9] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 -[e] Responders MUST NOT respond using cached data. + part of the transport protocol. For queries received by UDP the + responder MUST take note of the source port and use that as the + destination port in the response. Responses MUST always be sent + from the port to which they were directed. + +[c] Responders MUST respond to LLMNR queries for names and addresses + they are authoritative for. This applies to both forward and + reverse lookups. + +[d] Responders MUST NOT respond to LLMNR queries for names they are not + authoritative for. + +[e] Responders MUST NOT respond using data from the LLMNR or DNS + resolver cache. [f] If a DNS server is running on a host that supports LLMNR, the DNS server MUST respond to LLMNR queries only for the RRSets relating @@ -553,7 +566,7 @@ INTERNET-DRAFT LLMNR 18 July 2004 servers also MUST NOT send LLMNR queries in order to resolve DNS queries. -[g] If a responder is authoritative for a name, it MAY respond with +[g] If a responder is authoritative for a name, it SHOULD respond with RCODE=0 and an empty answer section, if the type of query does not match a RR that the responder has. @@ -579,6 +592,18 @@ INTERNET-DRAFT LLMNR 18 July 2004 reply to an LLMNR query for "child.foo.example.com." with RCODE=3 (authoritative name error). The purpose of limiting the name authority scope of a responder is to prevent complications that could + + + +Esibov, Aboba & Thaler Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 20 October 2004 + + be caused by coexistence of two or more hosts with the names representing child and parent (or grandparent) nodes in the DNS tree, for example, "foo.example.com." and "child.foo.example.com.". @@ -592,18 +617,6 @@ INTERNET-DRAFT LLMNR 18 July 2004 grandparent) zone with a delegation to a child zone. In this example a host "child.foo.example.com." would send a dynamic update for the NS and glue A record to "foo.example.com.", but this approach - - - -Esibov, Aboba & Thaler Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - significantly complicates implementation of LLMNR and would not be acceptable for lightweight hosts. @@ -636,8 +649,20 @@ INTERNET-DRAFT LLMNR 18 July 2004 For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. For IPv6 [RFC2460] an "on link" address is either a - link-local address, defined in [RFC2373], or an address whose prefix - belongs to a subnet on the local link. + link-local address, defined in [RFC2373], or one belonging to a + prefix that a Router Advertisement indicates is on-link [RFC2461]. + + + + +Esibov, Aboba & Thaler Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 20 October 2004 + A sender MUST select a source address for LLMNR queries that is "on link". The destination address of an LLMNR query MUST be a link- @@ -652,18 +677,6 @@ INTERNET-DRAFT LLMNR 18 July 2004 sent to another multicast address, then the query MUST be silently discarded. - - - -Esibov, Aboba & Thaler Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - Section 2.4 discusses use of TCP for LLMNR queries and responses. In composing an LLMNR query using TCP, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of the @@ -673,7 +686,7 @@ INTERNET-DRAFT LLMNR 18 July 2004 prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder. - For UDP queries and responses the Hop Limit field in the IPv6 header, + For UDP queries and responses, the Hop Limit field in the IPv6 header and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with Apple Rendezvous. @@ -699,19 +712,6 @@ INTERNET-DRAFT LLMNR 18 July 2004 that address MUST be valid on the local link over which LLMNR is used. - [b] If an IPv4 address is returned, it MUST be reachable - through the link over which LLMNR is used. - - [c] If a name is returned (for example in a CNAME, MX - or SRV RR), the name MUST be resolvable on the local - link over which LLMNR is used. - - Routable addresses MUST be included first in the response, if - available. This encourages use of routable address(es) for - establishment of new connections. - - - @@ -721,9 +721,27 @@ Esibov, Aboba & Thaler Standards Track [Page 12] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 + [b] If an IPv4 address is returned, it MUST be reachable + through the link over which LLMNR is used. + + [c] If a name is returned (for example in a CNAME, MX + or SRV RR), the name MUST be resolvable on the local + link over which LLMNR is used. + + Where multiple addresses represent valid responses to a query, the + order in which the addresses are returned is as follows: + + [d] If the source address of the query is a link-scope address, + then the responder SHOULD include a link-scope address first + in the response, if available. + + [e] If the source address of the query is a routable address, + then the responder MUST include a routable address first + in the response, if available. + 2.7. Retransmission and jitter An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine @@ -731,47 +749,29 @@ INTERNET-DRAFT LLMNR 18 July 2004 to an LLMNR query. If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, - then a sender MAY repeat the transmission of the query in order to + then a sender SHOULD repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Retransmission of UDP queries SHOULD NOT be attempted more than 3 - times. Where LLMNR queries are sent using TCP, retransmission is + times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer. Because an LLMNR sender cannot know in advance if a query sent using multicast will receive no response, one response, or more than one response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the multicast - query answered after the first response is received. A unicast query + query answered after the first response is received. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT - for each transmission. It is suggested that the computation of - LLMNR_TIMEOUT be based on the response times for earlier LLMNR - queries sent on the same interface. - - For example, the algorithms described in RFC 2988 [RFC2988] - (including exponential backoff) compute an RTO, which is used as the - value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial - RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum - RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the - maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). - - Recommended values are an initial RTO of 1 second, a minimum RTO of - 200ms, and a maximum RTO of 5 seconds. In order to avoid - synchronization, the transmission of each LLMNR query and response - SHOULD delayed by a time randomly selected from the interval 0 to 100 - ms. This delay MAY be avoided by responders responding with RRs - which they have previously determined to be UNIQUE (see Section 4 for - details). - -2.8. DNS TTL - - The responder should use a pre-configured TTL value in the records - returned an LLMNR response. A default value of 30 seconds is - RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc - networks), the TTL value may need to be reduced. + for each transmission. For example, the algorithms described in RFC + 2988 [RFC2988] (including exponential backoff) compute an RTO, which + is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used + for the initial RTO (discussed in Section 2 of [RFC2988], paragraph + 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph + 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988], + paragraph 2.5). Recommended values are an initial RTO of 500ms, a @@ -781,9 +781,24 @@ Esibov, Aboba & Thaler Standards Track [Page 13] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 + minimum RTO of 100ms, and a maximum RTO of 5 seconds. + + In order to avoid synchronization, the transmission of each LLMNR + query and response SHOULD delayed by a time randomly selected from + the interval 0 to 100 ms. This delay MAY be avoided by responders + responding with RRs which they have previously determined to be + UNIQUE (see Section 4 for details). + +2.8. DNS TTL + + The responder should insert a pre-configured TTL value in the records + returned in an LLMNR response. A default value of 30 seconds is + RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc + networks), the TTL value may need to be reduced. + Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value. @@ -802,8 +817,10 @@ INTERNET-DRAFT LLMNR 18 July 2004 [RFC2308]. The owner name of this SOA record MUST be equal to the query name. - Responders SHOULD NOT perform DNS additional section processing, - except as required for EDNS0 and DNSSEC. + In LLMNR, the additional section is only intended for use by EDNS0, + TSIG and SIG(0). As a result, senders MAY only include pseudo RR- + types in the additional section of a query; responders MUST ignore + the additional section of queries containing other RR types. Senders MUST NOT cache RRs from the authority or additional section of a response as answers, though they may be used for other purposes @@ -815,6 +832,18 @@ INTERNET-DRAFT LLMNR 18 July 2004 part determined by the behavior of DNS implementations. This document does not specify any changes to DNS resolver behavior, such as searchlist processing or retransmission/failover policy. However, + + + +Esibov, Aboba & Thaler Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 20 October 2004 + + robust DNS resolver implementations are more likely to avoid unnecessary LLMNR queries. @@ -832,18 +861,6 @@ INTERNET-DRAFT LLMNR 18 July 2004 For example, [RFC1536] Section 1 describes issues with retransmission and recommends implementation of a retransmission policy based on - - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - round trip estimates, with exponential backoff. [RFC1536] Section 4 describes issues with failover, and recommends that resolvers try another server when they don't receive a response to a query. These @@ -875,23 +892,6 @@ INTERNET-DRAFT LLMNR 18 July 2004 IPv6. Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], - IPv6-only hosts may not be configured with a DNS server. Where there - is no DNS server authoritative for the name of a host or the - authoritative DNS server does not support dynamic client update over - IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not - be able to do DNS dynamic update, and other hosts will not be able to - resolve its name. - - For example, if the configured DNS server responds to AAAA RR queries - sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), - then it will not be possible to resolve the names of IPv6-only hosts. - In this situation, LLMNR over IPv6 can be used for local name - resolution. - - Similarly, if a DHCPv4 server is available providing DNS server - configuration, and DNS server(s) exist which are authoritative for - the A RRs of local hosts and support either dynamic client update - over IPv4 or DHCPv4-based dynamic update, then the names of local @@ -901,9 +901,26 @@ Esibov, Aboba & Thaler Standards Track [Page 15] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 + IPv6-only hosts may not be configured with a DNS server. Where there + is no DNS server authoritative for the name of a host or the + authoritative DNS server does not support dynamic client update over + IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not + be able to do DNS dynamic update, and other hosts will not be able to + resolve its name. + + For example, if the configured DNS server responds to a AAAA RR query + sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or + RCODE=0 and an empty answer section, then a AAAA RR query sent using + LLMNR over IPv6 may be successful in resolving the name of an + IPv6-only host on the local link. + + Similarly, if a DHCPv4 server is available providing DNS server + configuration, and DNS server(s) exist which are authoritative for + the A RRs of local hosts and support either dynamic client update + over IPv4 or DHCPv4-based dynamic update, then the names of local IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no DNS server is authoritative for the names of local hosts, or the authoritative DNS server(s) do not support dynamic update, then LLMNR @@ -931,27 +948,10 @@ INTERNET-DRAFT LLMNR 18 July 2004 for the DNS configuration mechanism to continue functioning while configured DNS servers fail. - Unless unconfigured hosts periodically retry configuration, an outage - in the DNS configuration mechanism will result in hosts continuing to - use LLMNR even once the outage is repaired. Since LLMNR only enables - linklocal name resolution, this represents an unnecessary degradation - in capabilities. As a result, it is recommended that hosts without a - configured DNS server periodically attempt to obtain DNS - configuration. For example, where DHCP is used for DNS - configuration, [RFC2131] recommends a maximum retry interval of 64 - seconds. In the absence of other guidance, a default retry interval - of one (1) minute is RECOMMENDED. - -4. Conflict resolution - - The sender MUST anticipate receiving multiple replies to the same - LLMNR query, in the event that several LLMNR enabled computers - receive the query and respond with valid answers. When this occurs, - the responses may first be concatenated, and then treated in the same - manner that multiple RRs received from the same DNS server would; the - sender perceives no inherent conflict in the receipt of multiple - responses. - + An outage in the DNS configuration mechanism may result in hosts + continuing to use LLMNR even once the outage is repaired. Since + LLMNR only enables linklocal name resolution, this represents a + degradation in capabilities. As a result, hosts without a configured @@ -961,15 +961,18 @@ Esibov, Aboba & Thaler Standards Track [Page 16] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 - There are some scenarios when multiple responders MAY respond to the - same query. There are other scenarios when only one responder MAY - respond to a query. Resource records for which the latter queries - are submitted are referred as UNIQUE throughout this document. The - uniqueness of a resource record depends on a nature of the name in - the query and type of the query. For example it is expected that: + DNS server may wish to periodically attempt to obtain DNS + configuration if permitted by the configuration mechanism in use. In + the absence of other guidance, a default retry interval of one (1) + minute is RECOMMENDED. + +4. Conflict resolution + + The uniqueness of a resource record depends on the nature of the name + in the query and type of the query. For example it is expected that: - multiple hosts may respond to a query for an SRV type record - multiple hosts may respond to a query for an A or AAAA type @@ -978,40 +981,37 @@ INTERNET-DRAFT LLMNR 18 July 2004 - only a single host may respond to a query for an A or AAAA type record for a name. - Every responder that responds to an LLMNR query AND includes a UNIQUE - record in the response: + By default, a responder SHOULD be configured to behave as though all + RRs are UNIQUE on each interface on which LLMNR is enabled. Prior to + including a UNIQUE resource record in a response, for each UNIQUE + resource record in a given interface's configuration, the host MUST + verify that there is no other host within the scope of LLMNR query + propagation that can return a resource record for the same name, type + and class on that interface. Once a responder has verified the + uniqueness of a UNIQUE resource record, if it receives an LLMNR query + for that resource record, it MUST respond. - [1] MUST verify that there is no other host within the - scope of the LLMNR query propagation that can return - a resource record for the same name, type and class. + To verify uniqueness, a responder MUST send an LLMNR query for each + UNIQUE resource record. If no response is received after a suitable + number of attempts (see Section 2.7), the responder can use the + UNIQUE resource record in response to LLMNR queries. If a response + is received, the responder MUST NOT use the UNIQUE resource record in + response to LLMNR queries. - [2] MUST NOT include a UNIQUE resource record in the - response without having verified its uniqueness. - - Where a host is configured to issue LLMNR queries on more than one - interface, each interface should have its own independent LLMNR - cache. For each UNIQUE resource record in a given interface's - configuration, the host MUST verify resource record uniqueness on - that interface. To accomplish this, the host MUST send an LLMNR - query for each UNIQUE resource record. - - By default, a host SHOULD be configured to behave as though all RRs - are UNIQUE. Uniqueness verification is carried out when the host: + Uniqueness verification is carried out when the host: - starts up or is rebooted - - wakes from sleep (if the network interface was inactive during sleep) - - is configured to respond to the LLMNR queries on an interface + - wakes from sleep (if the network interface was inactive + during sleep) + - is configured to respond to LLMNR queries on an interface enabled for transmission and reception of IP traffic - - is configured to respond to the LLMNR queries using additional + - is configured to respond to LLMNR queries using additional UNIQUE resource records - - detects that an interface is connected and is usable - (e.g. an IEEE 802 hardware link-state change indicating - that a cable was attached or completion of authentication - (and if needed, association) with a wireless base station - or adhoc network + - verifies the acquisition of a new IP address and configuration + on an interface - When a host that has a UNIQUE record receives an LLMNR query for that - record, the host MUST respond. After the client receives a response, + The name conflict detection mechanism doesn't prevent name conflicts + when previously partitioned segments are connected by a bridge. It @@ -1021,19 +1021,15 @@ Esibov, Aboba & Thaler Standards Track [Page 17] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 - it MUST check whether the response arrived on an interface different - from the one on which the query was sent. If the response arrives on - a different interface, the client can use the UNIQUE resource record - in response to LLMNR queries. If not, then it MUST NOT use the - UNIQUE resource record in response to LLMNR queries. + also does not prevent deadlocks where two hosts attempt to verify + uniqueness of the same RR, yet neither can yet respond to queries + since uniqueness has not yet been verified. - The name conflict detection mechanism doesn't prevent name conflicts - when previously partitioned segments are connected by a bridge. In - order to minimize the chance of conflicts in such a situation, it is - recommended that steps be taken to ensure name uniqueness. For + In order to minimize the chance of conflicts in such situations, it + is recommended that steps be taken to ensure name uniqueness. For example, the name could be chosen randomly from a large pool of potential names, or the name could be assigned via a process designed to guarantee uniqueness. @@ -1054,6 +1050,10 @@ INTERNET-DRAFT LLMNR 18 July 2004 take. Implementers who are not planning to support LLMNR on multiple interfaces simultaneously may skip this section. + Where a host is configured to issue LLMNR queries on more than one + interface, each interface maintains its own independent LLMNR + resolver cache, containing the responses to LLMNR queries. + A multi-homed host checks the uniqueness of UNIQUE records as described in Section 4. The situation is illustrated in figure 1. @@ -1081,7 +1081,7 @@ Esibov, Aboba & Thaler Standards Track [Page 18] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 multiple interfaces, and receives replies from more than one, the @@ -1141,7 +1141,7 @@ Esibov, Aboba & Thaler Standards Track [Page 19] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 of both hosts responding to the name 'A'. Link-local addresses will @@ -1155,7 +1155,7 @@ INTERNET-DRAFT LLMNR 18 July 2004 LLMNR is by nature a peer-to-peer name resolution protocol. It is therefore inherently more vulnerable than DNS, since existing DNS security mechanisms are difficult to apply to LLMNR. While tools - exist to alllow an attacker to spoof a response to a DNS query, + exist to allow an attacker to spoof a response to a DNS query, spoofing a response to an LLMNR query is easier since the query is sent to a link-scope multicast address, where every host on the logical link will be made aware of it. @@ -1201,13 +1201,13 @@ Esibov, Aboba & Thaler Standards Track [Page 20] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 - possible for an attacker to spoof a response to a frequent query - (such as an A or AAAA query for a popular Internet host), and by - using a TTL or Hop Limit field larger than one (1), for the forged - response to reach the LLMNR sender. + possible for an attacker to spoof a response to a query (such as an A + or AAAA query for a popular Internet host), and by using a TTL or Hop + Limit field larger than one (1), for the forged response to reach the + LLMNR sender. When LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope @@ -1247,11 +1247,11 @@ INTERNET-DRAFT LLMNR 18 July 2004 response will never be received. The vulnerability is more serious if LLMNR is given higher priority - than DNS among the enabled name resolution mechanisms. In such a + than DNS among the enabled name resolution mechanisms. In such a configuration, a denial of service attack on the DNS server would not be necessary in order to poison the LLMNR cache, since LLMNR queries - would be sent even when the DNS server is available. In addition, the - LLMNR cache, once poisoned, would take precedence over the DNS cache, + would be sent even when the DNS server is available. In addition, + the LLMNR cache, once poisoned, would take precedence over the DNS @@ -1261,11 +1261,11 @@ Esibov, Aboba & Thaler Standards Track [Page 21] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 - eliminating the benefits of cache separation. As a result, LLMNR is - only used as a name resolution mechanism of last resort. + cache, eliminating the benefits of cache separation. As a result, + LLMNR is only used as a name resolution mechanism of last resort. 5.3. Cache and port separation @@ -1281,13 +1281,19 @@ INTERNET-DRAFT LLMNR 18 July 2004 5.4. Authentication - LLMNR implementations may not support DNSSEC or TSIG, and as a - result, responses to LLMNR queries may be unauthenticated. If - authentication is desired, and a pre-arranged security configuration - is possible, then IPsec ESP with a null-transform MAY be used to - authenticate LLMNR responses. In a small network without a - certificate authority, this can be most easily accomplished through - configuration of a group pre-shared key for trusted hosts. + LLMNR implementations MAY support TSIG and/or SIG(0) security + mechanisms. Since LLMNR does not support "delegated trust" (CD or AD + bits), and LLMNR senders are unlikely to be DNSSEC-aware, in practice + LLMNR is not compatible with DNSSEC. + + Since LLMNR implementations MAY NOT support TSIG or SIG(0), responses + to LLMNR queries may be unauthenticated. If authentication is + desired, and a pre-arranged security configuration is possible, then + IPsec ESP with a null-transform MAY be used to authenticate unicast + LLMNR queries and responses or LLMNR responses to multicast queries. + In a small network without a certificate authority, this can be most + easily accomplished through configuration of a group pre-shared key + for trusted hosts. 6. IANA Considerations @@ -1301,15 +1307,9 @@ INTERNET-DRAFT LLMNR 18 July 2004 224.0.0.252, as well as link-scope multicast IPv6 address FF02:0:0:0:0:0:1:3. -7. References -7.1. Normative References -[RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, November 1987. -[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. @@ -1321,9 +1321,19 @@ Esibov, Aboba & Thaler Standards Track [Page 22] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 +7. References + +7.1. Normative References + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. + +[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -1346,6 +1356,9 @@ INTERNET-DRAFT LLMNR 18 July 2004 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. +[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)", RFC 2461, December 1998. + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. @@ -1360,6 +1373,20 @@ INTERNET-DRAFT LLMNR 18 July 2004 [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993. + + +Esibov, Aboba & Thaler Standards Track [Page 23] + + + + + +INTERNET-DRAFT LLMNR 20 October 2004 + + +[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. @@ -1373,23 +1400,15 @@ INTERNET-DRAFT LLMNR 18 July 2004 [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. - - -Esibov, Aboba & Thaler Standards Track [Page 23] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - [RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC 2937, September 2000. [RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. +[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration + of Link-Local IPv4 Addresses", RFC 3927, October 2004. + [DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of Caching", IEEE/ACM Transactions on Networking, Volume 10, Number 5, pp. 589, October 2002. @@ -1399,12 +1418,6 @@ INTERNET-DRAFT LLMNR 18 July 2004 Internet draft (work in progress), draft-ietf-ipv6-dns- discovery-07.txt, October 2002. -[IPV4Link] - Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration - of IPv4 Link-Local Addresses", Internet draft (work in - progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, May - 2004. - [POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX). Open Group Technical Standard: Base Specifications, Issue 6, December @@ -1419,19 +1432,6 @@ INTERNET-DRAFT LLMNR 18 July 2004 (work in progress), draft-ietf-ipn-gwg-icmp-name- lookups-09.txt, May 2002. -Acknowledgments - - This work builds upon original work done on multicast DNS by Bill - Manning and Bill Woodcock. Bill Manning's work was funded under DARPA - grant #F30602-99-1-0523. The authors gratefully acknowledge their - contribution to the current specification. Constructive input has - also been received from Mark Andrews, Stuart Cheshire, Randy Bush, - Robert Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik - Guttman, Myron Hattig, Thomas Narten, Christian Huitema, Erik - Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill, - Keith Moore and Markku Savela. - - @@ -1441,9 +1441,22 @@ Esibov, Aboba & Thaler Standards Track [Page 24] -INTERNET-DRAFT LLMNR 18 July 2004 +INTERNET-DRAFT LLMNR 20 October 2004 +Acknowledgments + + This work builds upon original work done on multicast DNS by Bill + Manning and Bill Woodcock. Bill Manning's work was funded under + DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge + their contribution to the current specification. Constructive input + has also been received from Mark Andrews, Rob Austein, Randy Bush, + Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur + Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, + Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, + Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike + St. Johns, Sander Van-Valkenburg, and Brian Zill. + Authors' Addresses Levon Esibov @@ -1479,6 +1492,18 @@ Intellectual Property Statement has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of + + + +Esibov, Aboba & Thaler Standards Track [Page 25] + + + + + +INTERNET-DRAFT LLMNR 20 October 2004 + + claims of rights made available for publication 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 @@ -1491,19 +1516,6 @@ Intellectual Property Statement this standard. Please address the information to the IETF Executive Director. - - - - -Esibov, Aboba & Thaler Standards Track [Page 25] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - Disclaimer of Validity This document and the information contained herein are provided on an @@ -1534,18 +1546,6 @@ Open Issues - - - - - - - - - - - - diff --git a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-04.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-04.txt new file mode 100644 index 0000000000..12733dc63f --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-04.txt @@ -0,0 +1,464 @@ + +INTERNET-DRAFT DSA Information in the DNS +OBSOLETES: RFC 2536 Donald E. Eastlake 3rd + Motorola Laboratories +Expires: February 2005 August 2004 + + + DSA Keying and Signature Information in the DNS + --- ------ --- --------- ----------- -- --- --- + + Donald E. Eastlake 3rd + + +Status of This Document + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + or will be disclosed, and any of which I become aware will be + disclosed, in accordance with RFC 3668. + + Distribution of this document is unlimited. Comments should be sent + to the DNS extensions working group mailing list + . + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + The standard method of encoding US Government Digital Signature + Algorithm keying and signature information for use in the Domain Name + System is specified. + + +Copyright Notice + + Copyright (C) The Internet Society 2004. All Rights Reserved. + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DSA Information in the DNS + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Copyright Notice...........................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. DSA Keying Information..................................3 + 3. DSA Signature Information...............................4 + 4. Performance Considerations..............................4 + 5. Security Considerations.................................5 + 6. IANA Considerations.....................................5 + Copyright and Disclaimer...................................5 + + Normative References.......................................7 + Informative References.....................................7 + Authors Address............................................8 + Expiration and File Name...................................8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DSA Information in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information [RFC 1034, 1035]. The DNS has been extended to + include digital signatures and cryptographic keys as described in + [RFC intro, proto, records] and additional work is underway which + would require the storage of keying and signature information in the + DNS. + + This document describes how to encode US Government Digital Signature + Algorithm (DSA) keys and signatures in the DNS. Familiarity with the + US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier]. + + + +2. DSA Keying Information + + When DSA public keys are stored in the DNS, the structure of the + relevant part of the RDATA part of the RR being used is as shown + below. + + The period of key validity is not included in this data but is + indicated separately, for example by an RR which signs and + authenticates the RR containing the keying information. + + Field Size + ----- ---- + T 1 octet + Q 20 octets + P 64 + T*8 octets + G 64 + T*8 octets + Y 64 + T*8 octets + + As described in [FIPS 186-2] and [Schneier], T is a key size + parameter chosen such that 0 <= T <= 8. (The meaning if the T octet + is greater than 8 is reserved and the remainder of the data may have + a different format in that case.) Q is a prime number selected at + key generation time such that 2**159 < Q < 2**160 so Q is always 20 + octets long and, as with all other fields, is stored in "big-endian" + network order. P, G, and Y are calculated as directed by the [FIPS + 186-2] key generation algorithm [Schneier]. P is in the range + 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G + and Y are quantities modulo P and so can be up to the same length as + P and are allocated fixed size fields with the same number of octets + as P. + + During the key generation process, a random number X must be + generated such that 1 <= X <= Q-1. X is the private key and is used + in the final step of public key generation where Y is computed as + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DSA Information in the DNS + + + Y = G**X mod P + + + +3. DSA Signature Information + + The portion of the RDATA area used for US Digital Signature Algorithm + signature information is shown below with fields in the order they + occur. + + Field Size + ----- ---- + T 1 octet + R 20 octets + S 20 octets + + The data signed must be determined. Then the following steps are + taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as + specified in the public key [Schneier]: + + hash = SHA-1 ( data ) + + Generate a random K such that 0 < K < Q. + + R = ( G**K mod P ) mod Q + + S = ( K**(-1) * (hash + X*R) ) mod Q + + For infromation on the SHA-1 hash function see [FIPS 180-1] and [RFC + 3174]. + + Since Q is 160 bits long, R and S can not be larger than 20 octets, + which is the space allocated. + + T is copied from the public key. It is not logically necessary in + the SIG but is present so that values of T > 8 can more conveniently + be used as an escape for extended versions of DSA or other algorithms + as later standardized. + + + +4. Performance Considerations + + General signature generation speeds are roughly the same for RSA [RFC + 3110] and DSA. With sufficient pre-computation, signature generation + with DSA is faster than RSA. Key generation is also faster for DSA. + However, signature verification is an order of magnitude slower than + RSA when the RSA public exponent is chosen to be small, as is + recommended for some applications. + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DSA Information in the DNS + + + Current DNS implementations are optimized for small transfers, + typically less than 512 bytes including DNS overhead. Larger + transfers will perform correctly and extensions have been + standardized [RFC 2671] to make larger transfers more efficient, it + is still advisable at this time to make reasonable efforts to + minimize the size of RR sets containing keying and/or signature + inforamtion consistent with adequate security. + + + +5. Security Considerations + + Keys retrieved from the DNS should not be trusted unless (1) they + have been securely obtained from a secure resolver or independently + verified by the user and (2) this secure resolver and secure + obtainment or independent verification conform to security policies + acceptable to the user. As with all cryptographic algorithms, + evaluating the necessary strength of the key is essential and + dependent on local policy. + + The key size limitation of a maximum of 1024 bits ( T = 8 ) in the + current DSA standard may limit the security of DSA. For particular + applications, implementors are encouraged to consider the range of + available algorithms and key sizes. + + DSA assumes the ability to frequently generate high quality random + numbers. See [RFC 1750] for guidance. DSA is designed so that if + biased rather than random numbers are used, high bandwidth covert + channels are possible. See [Schneier] and more recent research. The + leakage of an entire DSA private key in only two DSA signatures has + been demonstrated. DSA provides security only if trusted + implementations, including trusted random number generation, are + used. + + + +6. IANA Considerations + + Allocation of meaning to values of the T parameter that are not + defined herein (i.e., > 8 ) requires an IETF standards actions. It + is intended that values unallocated herein be used to cover future + extensions of the DSS standard. + + + +Copyright and Disclaimer + + Copyright (C) The Internet Society 2004. 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. + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DSA Information in the DNS + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DSA Information in the DNS + + +Normative References + + [FIPS 180-1] - U.S. Federal Information Processing Standard: Secure + Hash Standard, April 1995. + + [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital + Signature Standard, 27 January 2000. + + [RFC records] - "Resource Records for the DNS Security Extensions", + R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in + progress, draft-ietf-dnsext-dnssec-records- *.txt. + + + +Informative References + + [RFC 1034] - "Domain names - concepts and facilities", P. + Mockapetris, 11/01/1987. + + [RFC 1035] - "Domain names - implementation and specification", P. + Mockapetris, 11/01/1987. + + [RFC 1750] - "Randomness Recommendations for Security", D. Eastlake, + S. Crocker, J. Schiller, December 1994. + + [RFC intro] - "DNS Security Introduction and Requirements", R. + Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress, + draft-ietf-dnsext-dnssec-intro-*.txt. + + [RFC protocol] - "Protocol Modifications for the DNS Security + Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose, + work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt. + + [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August + 1999. + + [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System + (DNS)", D. Eastlake 3rd. May 2001. + + [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P. + Jones, September 2001. + + [Schneier] - "Applied Cryptography Second Edition: protocols, + algorithms, and source code in C" (second edition), Bruce Schneier, + 1996, John Wiley and Sons, ISBN 0-471-11709-9. + + + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DSA Information in the DNS + + +Authors Address + + Donald E. Eastlake 3rd + Motorola Labortories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554(w) + +1-508-634-2066(h) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in February 2005. + + Its file name is draft-ietf-dnsext-rfc2536bis-dsa-04.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + + diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-04.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-04.txt new file mode 100644 index 0000000000..fc1b1867dd --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-04.txt @@ -0,0 +1,582 @@ + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS +OBSOLETES: RFC 2539 Donald E. Eastlake 3rd + Motorola Laboratories +Expires: February 2005 August 2004 + + + + + Storage of Diffie-Hellman Keying Information in the DNS + ------- -- -------------- ------ ----------- -- --- --- + + + + +Status of This Document + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + or will be disclosed, and any of which I become aware will be + disclosed, in accordance with RFC 3668. + + Distribution of this document is unlimited. Comments should be sent + to the DNS extensions working group mailing list + . + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + The standard method for encoding Diffie-Hellman keys in the Domain + Name System is specified. + + + +Copyright + + Copyright (C) The Internet Society 2004. + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Acknowledgements + + Part of the format for Diffie-Hellman keys and the description + thereof was taken from a work in progress by Ashar Aziz, Tom Markson, + and Hemma Prafullchandra. In addition, the following persons + provided useful comments that were incorporated into the predecessor + of this document: Ran Atkinson, Thomas Narten. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Copyright..................................................1 + + Acknowledgements...........................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 1.1 About This Document....................................3 + 1.2 About Diffie-Hellman...................................3 + 2. Encoding Diffie-Hellman Keying Information..............4 + 3. Performance Considerations..............................5 + 4. IANA Considerations.....................................5 + 5. Security Considerations.................................5 + Copyright and Disclaimer...................................5 + + Normative References.......................................7 + Informative Refences.......................................7 + Author Address.............................................7 + Expiration and File Name...................................8 + + Appendix A: Well known prime/generator pairs...............9 + A.1. Well-Known Group 1: A 768 bit prime..................9 + A.2. Well-Known Group 2: A 1024 bit prime.................9 + A.3. Well-Known Group 3: A 1536 bit prime................10 + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + similar information [RFC 1034, 1035]. The DNS has been extended to + include digital signatures and cryptographic keys as described in + [RFC intro, proto, records] and additonal work is underway which + would use the storage of keying information in the DNS. + + + +1.1 About This Document + + This document describes how to store Diffie-Hellman keys in the DNS. + Familiarity with the Diffie-Hellman key exchange algorithm is assumed + [Schneier, RFC 2631]. + + + +1.2 About Diffie-Hellman + + Diffie-Hellman requires two parties to interact to derive keying + information which can then be used for authentication. Thus Diffie- + Hellman is inherently a key agreement algorithm. As a result, no + format is defined for Diffie-Hellman "signature information". For + example, assume that two parties have local secrets "i" and "j". + Assume they each respectively calculate X and Y as follows: + + X = g**i ( mod p ) + + Y = g**j ( mod p ) + + They exchange these quantities and then each calculates a Z as + follows: + + Zi = Y**i ( mod p ) + + Zj = X**j ( mod p ) + + Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared + secret between the two parties that an adversary who does not know i + or j will not be able to learn from the exchanged messages (unless + the adversary can derive i or j by performing a discrete logarithm + mod p which is hard for strong p and g). + + The private key for each party is their secret i (or j). The public + key is the pair p and g, which must be the same for the parties, and + their individual X (or Y). + + For further information about Diffie-Hellman and precautions to take + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + + in deciding on a p and g, see [RFC 2631]. + + + +2. Encoding Diffie-Hellman Keying Information + + When Diffie-Hellman keys appear within the RDATA portion of a RR, + they are encoded as shown below. + + The period of key validity is not included in this data but is + indicated separately, for example by an RR which signs and + authenticates the RR containing the keying information. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | KEY flags | protocol | algorithm=2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | prime length (or flag) | prime (p) (or special) / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / prime (p) (variable length) | generator length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | generator (g) (variable length) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | public value length | public value (variable length)/ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / public value (g^i mod p) (variable length) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Prime length is length of the Diffie-Hellman prime (p) in bytes if it + is 16 or greater. Prime contains the binary representation of the + Diffie-Hellman prime with most significant byte first (i.e., in + network order). If "prime length" field is 1 or 2, then the "prime" + field is actually an unsigned index into a table of 65,536 + prime/generator pairs and the generator length SHOULD be zero. See + Appedix A for defined table entries and Section 4 for information on + allocating additional table entries. The meaning of a zero or 3 + through 15 value for "prime length" is reserved. + + Generator length is the length of the generator (g) in bytes. + Generator is the binary representation of generator with most + significant byte first. PublicValueLen is the Length of the Public + Value (g**i (mod p)) in bytes. PublicValue is the binary + representation of the DH public value with most significant byte + first. + + + + + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +3. Performance Considerations + + Current DNS implementations are optimized for small transfers, + typically less than 512 bytes including DNS overhead. Larger + transfers will perform correctly and extensions have been + standardized [RFC 2671] to make larger transfers more efficient, it + is still advisable at this time to make reasonable efforts to + minimize the size of RR sets containing keying information consistent + with adequate security. + + + +4. IANA Considerations + + Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires + an IETF consensus as defined in [RFC 2434]. + + Well known prime/generator pairs number 0x0000 through 0x07FF can + only be assigned by an IETF standards action. [RFC 2539], the + Proposed Standard predecessor of this document, assigned 0x0001 + through 0x0002. This document assigns 0x0003. Pairs number 0s0800 + through 0xBFFF can be assigned based on RFC documentation. Pairs + number 0xC000 through 0xFFFF are available for private use and are + not centrally coordinated. Use of such private pairs outside of a + closed environment may result in conflicts and/or security failures. + + + +5. Security Considerations + + Keying information retrieved from the DNS should not be trusted + unless (1) it has been securely obtained from a secure resolver or + independently verified by the user and (2) this secure resolver and + secure obtainment or independent verification conform to security + policies acceptable to the user. As with all cryptographic + algorithms, evaluating the necessary strength of the key is important + and dependent on security policy. + + In addition, the usual Diffie-Hellman key strength considerations + apply. (p-1)/2 should also be prime, g should be primitive mod p, p + should be "large", etc. [RFC 2631, Schneier] + + + +Copyright and Disclaimer + + Copyright (C) The Internet Society 2004. 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. + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Normative References + + [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June + 1999. + + [RFC 2434] - "Guidelines for Writing an IANA Considerations Section + in RFCs", T. Narten, H. Alvestrand, October 1998. + + [RFC records] - "Resource Records for the DNS Security Extensions", + R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in + progress, draft-ietf-dnsext-dnssec-records- *.txt. + + + +Informative Refences + + [RFC 1034] - "Domain names - concepts and facilities", P. + Mockapetris, November 1987. + + [RFC 1035] - "Domain names - implementation and specification", P. + Mockapetris, November 1987. + + [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name + System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC. + + [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August + 1999. + + [RFC intro] - "DNS Security Introduction and Requirements", R. + Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress, + draft-ietf-dnsext-dnssec-intro-*.txt. + + [RFC protocol] - "Protocol Modifications for the DNS Security + Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose, + work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley + and Sons. + + + +Author Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554 (w) + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + + +1-508-634-2066 (h) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in February 2005. + + Its file name is draft-ietf-dnsext-rfc2539bis-dhk-04.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Appendix A: Well known prime/generator pairs + + These numbers are copied from the IPSEC effort where the derivation of + these values is more fully explained and additional information is available. + Richard Schroeppel performed all the mathematical and computational + work for this appendix. + + + +A.1. Well-Known Group 1: A 768 bit prime + + The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its + decimal value is + 155251809230070893513091813125848175563133404943451431320235 + 119490296623994910210725866945387659164244291000768028886422 + 915080371891804634263272761303128298374438082089019628850917 + 0691316593175367469551763119843371637221007210577919 + + Prime modulus: Length (32 bit words): 24, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + +A.2. Well-Known Group 2: A 1024 bit prime + + The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. + Its decimal value is + 179769313486231590770839156793787453197860296048756011706444 + 423684197180216158519368947833795864925541502180565485980503 + 646440548199239100050792877003355816639229553136239076508735 + 759914822574862575007425302077447712589550957937778424442426 + 617334727629299387668709205606050270810842907692932019128194 + 467627007 + + Prime modulus: Length (32 bit words): 32, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED + EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 + FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +A.3. Well-Known Group 3: A 1536 bit prime + + The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. + Its decimal value is + 241031242692103258855207602219756607485695054850245994265411 + 694195810883168261222889009385826134161467322714147790401219 + 650364895705058263194273070680500922306273474534107340669624 + 601458936165977404102716924945320037872943417032584377865919 + 814376319377685986952408894019557734611984354530154704374720 + 774996976375008430892633929555996888245787241299381012913029 + 459299994792636526405928464720973038494721168143446471443848 + 8520940127459844288859336526896320919633919 + + Prime modulus Length (32 bit words): 48, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED + EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D + C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F + 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D + 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 10] + + diff --git a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt new file mode 100644 index 0000000000..0af13c616f --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt @@ -0,0 +1,755 @@ + + +Network Working Group B. Laurie +Internet-Draft Nominet +Expires: March 2, 2005 R. Loomis + SAIC + September 2004 + + + + Requirements related to DNSSEC Signed Proof of Non-Existence + draft-ietf-dnsext-signed-nonexistence-requirements-01 + + +Status of this Memo + + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + This Internet-Draft will expire on March 2, 2005. + + +Copyright Notice + + + Copyright (C) The Internet Society (2004). + + +Abstract + + + DNSSEC-bis uses the NSEC record to provide authenticated denial of + existence of RRsets. NSEC also has the side-effect of permitting + zone enumeration, even if zone transfers have been forbidden. + Because some see this as a problem, this document has been assembled + to detail the possible requirements for denial of existence A/K/A + signed proof of non-existence. + + + + +Laurie & Loomis Expires March 2, 2005 [Page 1] +Internet-Draft signed-nonexistence-requirements September 2004 + + + +Table of Contents + + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4 + 5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4 + 6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4 + 7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5 + 9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5 + 10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6 + 11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6 + 12. Non-overlap of denial records with possible zone records . . 7 + 13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7 + 14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8 + 15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8 + 16. Minimisation of Client Complexity . . . . . . . . . . . . . 8 + 17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8 + 18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8 + 19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8 + 20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8 + 21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9 + 22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9 + 23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9 + 24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9 + 25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9 + 26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + 28. Requirements notation . . . . . . . . . . . . . . . . . . . 9 + 29. Security Considerations . . . . . . . . . . . . . . . . . . 10 + 30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 30.1 Normative References . . . . . . . . . . . . . . . . . . . 10 + 30.2 Informative References . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 + Intellectual Property and Copyright Statements . . . . . . . 11 + + + + + + + + + + + + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 2] +Internet-Draft signed-nonexistence-requirements September 2004 + + + +1. Introduction + + + NSEC records allow trivial enumeration of zones - a situation that + has existed for several years but which has recently been raised as a + significant concern for DNSSECbis deployment in several zones. + Alternate proposals have been made that make zone enumeration more + difficult, and some previous proposals to modify DNSSEC had related + requirements/desirements that are relevant to the discussion. In + addition the original designs for NSEC/NXT records were based on + working group discussions and the choices made were not always + documented with context and requirements-- so some of those choices + may need to be restated as requirements. Overall, the working group + needs to better understand the requirements for denial of existence + (and certain other requirements related to DNSSECbis deployment) in + order to evaluate the proposals that may replace NSEC. + + + In the remainder of this document, "NSEC++" is used as shorthand for + "a denial of existence proof that will replace NSEC". "NSECbis" has + also been used as shorthand for this, but we avoid that usage since + NSECbis will not be part of DNSSECbis and therefore there might be + some confusion. + + +2. Non-purposes + + + This document does not currently document the reasons why zone + enumeration might be "bad" from a privacy, security, business, or + other perspective--except insofar as those reasons result in + requirements. Once the list of requirements is complete and vaguely + coherent, the trade-offs (reducing zone enumeration will have X cost, + while providing Y benefit) may be revisited. The editors of this + compendium received inputs on the potential reasons why zone + enumeration is bad (and there was significant discussion on the + DNSEXT WG mailing list) but that information fell outside the scope + of this document. + + + Note also that this document does not assume that NSEC *must* be + replaced with NSEC++, if the requirements can be met through other + methods (e.g., "white lies" with the current NSEC). As is stated + above, this document is focused on requirements collection and + (ideally) prioritization rather than on the actual implementation. + + +3. Zone Enumeration + + + Authenticated denial should not permit trivial zone enumeration. + + + Additional discussion: NSEC (and NXT before it) provide a linked + list that could be "walked" to trivially enumerate all the signed + records in a zone. This requirement is primarily (though not + + + + +Laurie & Loomis Expires March 2, 2005 [Page 3] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + exclusively) important for zones that either are delegation-only/ + -mostly or do not have reverse lookup (PTR) records configured, since + enterprises that have PTR records for all A records have already + provided a similar capability to enumerate the contents of DNS zones. + + + Contributor: various + + +4. Zone Enumeration II + + + Zone enumeration should be at least as difficult as it would be to + effect a dictionary attack using simple DNS queries to do the same in + an unsecured zone. + + + (Editor comment: it is not clear how to measure difficulty in this + case. Some examples could be monetary cost, bandwidth, processing + power or some combination of these. It has also been suggested that + the requirement is that the graph of difficulty of enumeration vs. + the fraction of the zone enumerated should be approximately the same + shape in the two cases) + + + Contributor: Nominet + + +5. Zone Enumeration III + + + Enumeration of a zone with random contents should computationally + infeasible. + + + Editor comment: this is proposed as a way of evaluating the + effectiveness of a proposal rather than as a requirement anyone would + actually have in practice. + + + Contributor: Alex Bligh + + +6. Exposure of Contents + + + NSEC++ should not expose any of the contents of the zone (apart from + the NSEC++ records themselves, of course). + + + Editor comment: this is a weaker requirement than prevention of + enumeration, but certainly any zone that satisfied this requirement + would also satisfy the trivial prevention of enumeration requirement. + + + Contributor: Ed Lewis + + +7. Zone Size + + + Requirement: NSEC++ should make it possible to take precautions + against trivial zone size estimates. Since not all zone owners care + + + + +Laurie & Loomis Expires March 2, 2005 [Page 4] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + about others estimation of the size of a zone, it is not always + necessary to prohibit trivial estimation of the size of the zone but + NSEC++ should allow such measures. + + + Additional Discussion: Even with proposals based on obfuscating names + with hashes it is trivial to give very good estimates of the number + of domains in a certain zone. Just send 10 random queries and look + at the range between the two hash values returned in each NSEC++. As + hash output can be assumed to follow a rectangular random + distribution, using the mean difference between the two values, you + can estimate the total number of records. It is probably sufficient + to look at even one NSEC++, since the two hash values should follow a + (I believe) Poisson distribution. + + + The concern is motivated by some wording remembered from NSEC, which + stated that NSEC MUST only be present for existing owner names in the + zone, and MUST NOT be present for non-existing owner names. If + similar wording were carried over to NSEC++, introducing bogus owner + names in the hash chain (an otherwise simple solution to guard + against trivial estimates of zone size) wouldn't be allowed. + + + One simple attempt at solving this is to describe in the + specifications how zone signer tools can add a number of random + "junk" records. + + + Editor's comment: it is interesting that obfuscating names might + actually make it easier to estimate zone size. + + + Contributor: Simon Josefsson. + + +8. Single Method + + + Requirement: A single NSEC++ method must be able to carry both + old-style denial (i.e. plain labels) and whatever the new style + looks like. Having two separate denial methods could result in + cornercases where one method can deny the other and vice versa. + + + Additional discussion: This requirement can help -bis folks to a + smooth upgrade to -ter. First they'd change the method while the + content is the same, then they can change content of the method. + + + Contributor: Roy Arends. + + +9. Empty Non-terminals + + + Requirement: Empty-non-terminals (ENT) should remain empty. In + other words, adding NSEC++ records to an existing DNS structure + should not cause the creation of NSEC++ records (or related records) + + + + +Laurie & Loomis Expires March 2, 2005 [Page 5] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + at points that are otherwise ENT. + + + Additional discussion: Currently NSEC complies with ENT requirement: + b.example.com NSEC a.c.example.com implies the existence of an ENT + with ownername c.example.com. NSEC2 breaks that requirement, since + the ownername is entirely hashed causing the structure to disappear. + This is why EXIST was introduced. But EXIST causes ENT to be + non-empty-terminals. Next to the dissappearance of ENT, it causes + (some) overhead since an EXIST record needs a SIG, NSEC2 and + SIG(NSEC2). DNSNR honours this requirement by hashing individual + labels instead of ownernames. However this causes very long labels. + Truncation is a measure against very long ownernames, but that is + controversial. There is a fair discussion of the validity of + truncation in the DNSNR draft, but that hasn't got proper review yet. + + + Contributor: Roy Arends. + + + (Editor comment: it is not clear to us that an EXIST record needs an + NSEC2 record, since it is a special purpose record only used for + denial of existence) + + +10. Prevention of Precomputed Dictionary Attacks + + + Requirement: NSEC++ needs to provide a method to reduce the + effectiveness of precomputed dictionary attacks. + + + Additional Discussion: Salt is a measure against dictionary attacks. + There are other possible measures (such as iterating hashes in + NSEC2). The salt needs to be communicated in every response, since + it is needed in every verification. Some have suggested to move the + salt to a special record instead of the denial record. I think this + is not wise. Response size has more priority over zone size. An + extra record causes a larger response than a larger existing record. + + + Contributor: Roy Arends. + + + (Editor comment: the current version of NSEC2 also has the salt in + every NSEC2 record) + + +11. DNSSEC-Adoption and Zone-Growth Relationship + + + Background: Currently with NSEC, when a delegation centric zone + deploys DNSSEC, the zone-size multiplies by a non-trivial factor even + when the DNSSEC-adoption rate of the subzones remains low--because + each delegation point creates at least one NSEC record and + corresponding signature in the parent even if the child is not + signed. + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 6] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + Requirements: A delegation-only (or delegation-mostly) zone that is + signed but which has no signed child zones should initially need only + to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some + minimal set of NSEC++ records to cover zone contents. Further, + during the transition of a delegation-only zone from 0% signed + children to 100% signed children, the growth in the delegation-only + zone should be roughly proportional to the percentage of signed child + zones. + + + Additional Discussion: This is why DNSNR has the Authoritative Only + bit. This is similar to opt-in for delegations only. This (bit) is + currently the only method to help delegation-centric zone cope with + zone-growth due to DNSSEC adoption. As an example, A delegation only + zone which deploys DNSSEC with the help of this bit, needs to add + SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No + more than that. + + + Contributor: Roy Arends. + + +12. Non-overlap of denial records with possible zone records + + + Requirement: NSEC++ records should in some way be differentiated + from regular zone records, so that there is no possibility that a + record in the zone could be duplicated by a non-existence proof + (NSEC++) record. + + + Additional discussion: This requirement is derived from a discussion + on the DNSEXT mailing list related to copyrights and domain names. + As was outlined there, one solution is to put NSEC++ records in a + separate namespace, e.g.: $ORIGIN co.uk. + 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your + delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345... + ; for amazon.co.uk. + + + Contributor: various + + + (Editor comment: One of us still does not see why a conflict + matters. Even if there is an apparent conflict or overlap, the + "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the + other name _never_ appears in NSEC2 records.) + + +13. Exposure of Private Keys + + + Private keys associated with the public keys in the DNS should be + exposed as little as possible. It is highly undesirable for private + keys to be distributed to nameservers, or to otherwise be available + in the run-time environment of nameservers. + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 7] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + Contributors: Nominet, Olaf Kolkman, Ed Lewis + + +14. Minimisation of Zone Signing Cost + + + The additional cost of creating an NSEC++ signed zone should not + significantly exceed the cost of creating an ordinary signed zone. + + + Contributor: Nominet + + +15. Minimisation of Asymmetry + + + Nameservers should have to do as little additional work as necessary. + More precisely, it is desirable for any increase in cost incurred by + the nameservers to be offset by a proportionate increase in cost to + DNS `clients', e.g. stub and/or `full-service' resolvers. + + + Contributor: Nominet + + +16. Minimisation of Client Complexity + + + Caching, wildcards, CNAMEs, DNAMEs should continue to work without + adding too much complexity at the client side. + + + Contributor: Olaf Kolkman + + +17. Completeness + + + A proof of nonexistence should be possible for all nonexistent data + in the zone. + + + Contributor: Olaf Kolkman + + +18. Purity of Namespace + + + The name space should not be muddied with fake names or data sets. + + + Contributor: Ed Lewis + + +19. Replay Attacks + + + NSEC++ should not allow a replay to be used to deny existence of an + RR that actually exists. + + + Contributor: Ed Lewis + + +20. Compatibility with NSEC + + + NSEC++ should not introduce changes incompatible with NSEC. + + + + +Laurie & Loomis Expires March 2, 2005 [Page 8] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + Contributor: Ed Lewis + + +21. Compatibility with NSEC II + + + NSEC++ should differ from NSEC in a way that is transparent to the + resolver or validator. + + + Contributor: Ed Lewis + + +22. Compatibility with NSEC III + + + NSEC++ should differ from NSEC as little as possible whilst achieving + other requirements. + + + Contributor: Alex Bligh + + +23. Coexistence with NSEC + + + NSEC++ should be optional, allowing NSEC to be used instead. + + + Contributor: Ed Lewis, Alex Bligh + + +24. Coexistence with NSEC II + + + NSEC++ should not impose extra work on those content with NSEC. + + + Contributor: Ed Lewis + + +25. Protocol Design + + + A good security protocol would allow signing the nonexistence of some + selected names without revealing anything about other names. + + + Contributor: Dan Bernstein + + +26. Process + + + Clearly not all of these requirements can be met. Therefore the next + phase of this document will be to either prioritise them or narrow + them down to a non-contradictory set, which should then allow us to + judge proposals on the basis of their fit. + + +27. Acknowledgements + + +28. Requirements notation + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + + + + +Laurie & Loomis Expires March 2, 2005 [Page 9] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + document are to be interpreted as described in [RFC2119]. + + +29. Security Considerations + + + There are currently no security considerations called out in this + draft. There will be security considerations in the choice of which + requirements will be implemented, but there are no specific security + requirements during the requirements collection process. + + +30. References + + +30.1 Normative References + + + [dnssecbis-protocol] + "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some + Month 2004. + + +30.2 Informative References + + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + + +Authors' Addresses + + + Ben Laurie + Nominet + 17 Perryn Road + London W3 7LR + England + + + Phone: +44 (20) 8735 0686 + EMail: ben@algroup.co.uk + + + + Rip Loomis + Science Applications International Corporation + 7125 Columbia Gateway Drive, Suite 300 + Columbia, MD 21046 + US + + + EMail: gilbert.r.loomis@saic.com + + + + +Laurie & Loomis Expires March 2, 2005 [Page 10] +Internet-Draft signed-nonexistence-requirements September 2004 + + + +Intellectual Property Statement + + + 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. + + + 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. + + + 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. + + + +Disclaimer of Validity + + + 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. + + + +Copyright Statement + + + Copyright (C) The Internet Society (2004). 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. + + + +Acknowledgment + + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 11] \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt similarity index 81% rename from doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt rename to doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt index c5c3b84ba3..9c73c68bef 100644 --- a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt +++ b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt @@ -3,51 +3,106 @@ - -DNSEXT Working Group Yuji Kamite -INTERNET-DRAFT NTT Communications - Masaya Nakayama -Expires: Aug. 2004 The University of Tokyo - Feb. 2004 - +DNS Extensions Yuji Kamite +Internet-Draft NTT Communications +Expires: April 15, 2005 Masaya Nakayama + The University of Tokyo + October 14, 2004 TKEY Secret Key Renewal Mode + draft-ietf-dnsext-tkey-renewal-mode-05 Status of this Memo - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. - Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + This Internet-Draft will expire on April 15, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). Abstract This document defines a new mode in TKEY and proposes an atomic method for changing secret keys used for TSIG periodically. Originally, TKEY provides methods of setting up shared secrets other + + + +Kamite, et. al. Expires April 15, 2005 [Page 1] + +INTERNET-DRAFT October 2004 + + than manual exchange, but it cannot control timing of key renewal very well though it can add or delete shared keys separately. This proposal is a systematical key renewal procedure intended for preventing signing DNS messages with old and non-safe keys permanently. +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4 + 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4 + 2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5 + 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5 + 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6 + 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7 + 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7 + 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7 + 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8 + 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8 + 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10 + 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10 + 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10 + 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11 + 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11 + 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12 + 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13 + 2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14 + 3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15 + 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15 + 4.2 Authentication Methods Considerations . . . . . . . . . . 15 + 5. Special Considerations for Two Servers' Case . . . . . . . . 16 + 5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16 + 6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17 + 7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21 + 11.2 Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 + Intellectual Property and Copyright Statements . . . . . . . . 23 @@ -55,65 +110,9 @@ Abstract -Kamite, et. al. [Page 1] +Kamite, et. al. Expires April 15, 2005 [Page 2] -INTERNET-DRAFT Feb. 2004 - - - Table of Contents - - -1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4 - 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4 -2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5 - 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5 - 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6 - 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 7 - 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . . . 7 - 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . . 7 - 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . . . 8 - 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . . . 8 - 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 10 - 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 10 - 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10 - 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 - 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11 - 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12 - 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13 - 2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14 -3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 15 -4 Compulsory Key Revocation . . . . . . . . . . . . . . . . . . . . 15 - 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . . . 15 - 4.2 Authentication Methods Considerations . . . . . . . . . . . . 15 -5 Special Considerations for Two Servers' Case . . . . . . . . . . 16 - 5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16 -6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 17 -7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17 -8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 20 -9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20 -10 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 21 -11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 -Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22 - - - - - - - - - - - - - - - -Kamite, et. al. [Page 2] - -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 1. Introduction @@ -167,9 +166,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 3] +Kamite, et. al. Expires April 15, 2005 [Page 3] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 and must be updated. It must be between Inception Time and Expiry @@ -223,9 +222,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 4] +Kamite, et. al. Expires April 15, 2005 [Page 4] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 In this state, if a client sends a normal query (e.g., question about @@ -279,9 +278,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 5] +Kamite, et. al. Expires April 15, 2005 [Page 5] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 When the present time is equal to Inception Time, or between @@ -335,9 +334,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 6] +Kamite, et. al. Expires April 15, 2005 [Page 6] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 Server MUST keep track of clients ignoring PartialRevoke, thus @@ -391,9 +390,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 7] +Kamite, et. al. Expires April 15, 2005 [Page 7] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 client, a new shared secret can be established. The details of @@ -447,9 +446,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 8] +Kamite, et. al. Expires April 15, 2005 [Page 8] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 CLASS u_int16_t (defined in [RFC2930]) @@ -494,18 +493,18 @@ INTERNET-DRAFT Feb. 2004 in Other Data filed: - Field Type Comment - ------- ------ ------- - OldNAME domain name of the old key - OldAlgorithm domain algorithm of the old key + Field Type Comment + ------- ------ ------- + OldNAME domain name of the old key + OldAlgorithm domain algorithm of the old key -Kamite, et. al. [Page 9] +Kamite, et. al. Expires April 15, 2005 [Page 9] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 "OldName" indicates the name of the previous key (usually, @@ -559,9 +558,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 10] +Kamite, et. al. Expires April 15, 2005 [Page 10] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 including "OldName" and "OldAlgorithm" that indicate the revoked key. @@ -615,9 +614,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 11] +Kamite, et. al. Expires April 15, 2005 [Page 11] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 TKEY "Mode" field stores the value of "DH exchange for key @@ -671,9 +670,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 12] +Kamite, et. al. Expires April 15, 2005 [Page 12] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 Query @@ -727,9 +726,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 13] +Kamite, et. al. Expires April 15, 2005 [Page 13] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 Query @@ -783,9 +782,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 14] +Kamite, et. al. Expires April 15, 2005 [Page 14] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 client or not. If client has not received yet because of any reasons @@ -839,9 +838,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 15] +Kamite, et. al. Expires April 15, 2005 [Page 15] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 shared secret, they keep using TSIG for queries and responses. @@ -895,9 +894,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 16] +Kamite, et. al. Expires April 15, 2005 [Page 16] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 hosts want to send queries, but it is possible. @@ -951,9 +950,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 17] +Kamite, et. al. Expires April 15, 2005 [Page 17] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 (3) Suppose the present time is 19:55. If Client sends a query @@ -1007,9 +1006,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 18] +Kamite, et. al. Expires April 15, 2005 [Page 18] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 Answer Section also contains KEY RRs for DH. @@ -1063,9 +1062,9 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 19] +Kamite, et. al. Expires April 15, 2005 [Page 19] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 (11) This key is used until next day's 15:00. After that, it will @@ -1119,12 +1118,12 @@ INTERNET-DRAFT Feb. 2004 -Kamite, et. al. [Page 20] +Kamite, et. al. Expires April 15, 2005 [Page 20] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 -10. Acknowledgement +10. Acknowledgements The authors would like to thank Olafur Gudmundsson, whose helpful input and comments contributed greatly to this document. @@ -1132,9 +1131,7 @@ INTERNET-DRAFT Feb. 2004 11. References -[RFC2104] - H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message - Authentication", RFC2104, February 1997. +11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement @@ -1157,6 +1154,11 @@ INTERNET-DRAFT Feb. 2004 D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000. +11.2. Informative References + +[RFC2104] + H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message + Authentication", RFC2104, February 1997. @@ -1172,12 +1174,9 @@ INTERNET-DRAFT Feb. 2004 - - - -Kamite, et. al. [Page 21] +Kamite, et. al. Expires April 15, 2005 [Page 21] -INTERNET-DRAFT Feb. 2004 +INTERNET-DRAFT October 2004 Authors' Addresses @@ -1231,5 +1230,63 @@ Authors' Addresses -Kamite, et. al. [Page 22] +Kamite, et. al. Expires April 15, 2005 [Page 22] +INTERNET-DRAFT October 2004 + + +Intellectual Property Statement + + 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. + + 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. + + 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. + + +Disclaimer of Validity + + 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). 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. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 23] + + + diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt new file mode 100644 index 0000000000..eaf68656cc --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt @@ -0,0 +1,1501 @@ +Network Working Group J. Ihren +Internet-Draft Autonomica AB +Expires: April 18, 2005 O. Kolkman + RIPE NCC + B. Manning + EP.net + October 18, 2004 + + + + An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for + DNSSEC Trust Anchors. + draft-ietf-dnsext-trustupdate-threshold-00 + + +Status of this Memo + + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + This Internet-Draft will expire on April 18, 2005. + + +Copyright Notice + + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + +Abstract + + + The DNS Security Extensions (DNSSEC) works by validating so called + chains of authority. The start of these chains of authority are + usually public keys that are anchored in the DNS clients. These keys + are known as the so called trust anchors. + + + + + +Ihren, et al. Expires April 18, 2005 [Page 1] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + This memo describes a method how these client trust anchors can be + replaced using the DNS validation and querying mechanisms (in-band) + when the key pairs used for signing by zone owner are rolled. + + + This memo also describes a method to establish the validity of trust + anchors for initial configuration, or priming, using out of band + mechanisms. + + +Table of Contents + + + 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry + Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction and Background . . . . . . . . . . . . . . . . . 5 + 2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5 + 3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7 + 3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2 Threshold-based Trust Update . . . . . . . . . . . . . . . 8 + 3.3 Possible Trust Update States . . . . . . . . . . . . . . . 9 + 3.4 Implementation notes . . . . . . . . . . . . . . . . . . . 10 + 3.5 Possible transactions . . . . . . . . . . . . . . . . . . 11 + 3.5.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12 + 3.5.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12 + 3.5.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12 + 3.5.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12 + 3.6 Removal of trust anchors for a trust point . . . . . . . . 12 + 3.7 No need for resolver-side overlap of old and new keys . . 13 + 4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14 + 4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.1.1 Bootstrapping trust anchors using a priming key . . . 14 + 4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15 + 5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 6.1 Threshold-based Trust Update Security Considerations . . . 17 + 6.2 Priming Key Security Considerations . . . . . . . . . . . 17 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 + 8.2 Informative References . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 + A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 + B. Document History . . . . . . . . . . . . . . . . . . . . . . . 23 + B.1 prior to version 00 . . . . . . . . . . . . . . . . . . . 23 + B.2 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23 + Intellectual Property and Copyright Statements . . . . . . . . 24 + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 2] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +1. Terminology + + + The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", + and "MAY" in this document are to be interpreted as described in + RFC2119 [1]. + + + The term "zone" refers to the unit of administrative control in the + Domain Name System. In this document "name server" denotes a DNS + name server that is authoritative (i.e. knows all there is to know) + for a DNS zone. A "zone owner" is the entity responsible for signing + and publishing a zone on a name server. The terms "authentication + chain", "bogus", "trust anchors" and "Island of Security" are defined + in [4]. Throughout this document we use the term "resolver" to mean + "Validating Stub Resolvers" as defined in [4]. + + + We use the term "security apex" as the zone for which a trust anchor + has been configured (by validating clients) and which is therefore, + by definition, at the root of an island of security. The + configuration of trust anchors is a client side issue. Therefore a + zone owner may not always know if their zone has become a security + apex. + + + A "stale anchor" is a trust anchor (a public key) that relates to a + key that is not used for signing. Since trust anchors indicate that + a zone is supposed to be secure a validator will mark the all data in + an island of security as bogus when all trust anchors become stale. + + + It is assumed that the reader is familiar with public key + cryptography concepts [REF: Schneier Applied Cryptography] and is + able to distinguish between the private and public parts of a key + based on the context in which we use the term "key". If there is a + possible ambiguity we will explicitly mention if a private or a + public part of a key is used. + + + The term "administrator" is used loosely throughout the text. In + some cases an administrator is meant to be a person, in other cases + the administrator may be a process that has been delegated certain + responsibilities. + + +1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points + + + Although the DNSSEC protocol does not make a distinction between + different keys the operational practice is that a distinction is made + between zone signing keys and key signing keys. A key signing key is + used to exclusively sign the DNSKEY Resource Record (RR) set at the + apex of a zone and the zone signing keys sign all the data in the + zone (including the DNSKEY RRset at the apex). + + + + + +Ihren, et al. Expires April 18, 2005 [Page 3] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + Keys that are intended to be used as the start of the authentication + chain for a particular zone, either because they are pointed to by a + parental DS RR or because they are configured as a trust anchor, are + called Secure Entry Point (SEP) keys. In practice these SEP keys + will be key signing keys. + + + In order for the mechanism described herein to work the keys that are + intended to be used as secure entry points MUST have the SEP [2] flag + set. In the examples it is assumed that keys with the SEP flag set + are used as key signing keys and thus exclusively sign the DNSKEY + RRset published at the apex of the zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 4] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +2. Introduction and Background + + + When DNSSEC signatures are validated the resolver constructs a chain + of authority from a pre-configured trust anchor to the DNSKEY + Resource Record (RR), which contains the public key that validates + the signature stored in an RRSIG RR. DNSSEC is designed so that the + administrator of a resolver can validate data in multiple islands of + security by configuring multiple trust anchors. + + + It is expected that resolvers will have more than one trust anchor + configured. Although there is no deployment experience it is not + unreasonable to expect resolvers to be configured with a number of + trust anchors that varies between order 1 and order 1000. Because + zone owners are expected to roll their keys, trust anchors will have + to be maintained (in the resolver end) in order not to become stale. + + + Since there is no global key maintenance policy for zone owners and + there are no mechanisms in the DNS to signal the key maintenance + policy it may be very hard for resolvers administrators to keep their + set of trust anchors up to date. For instance, if there is only one + trust anchor configured and the key maintenance policy is clearly + published, through some out of band trusted channel, then a resolver + administrator can probably keep track of key rollovers and update the + trust anchor manually. However, with an increasing number of trust + anchors all rolled according to individual policies that are all + published through different channels this soon becomes an + unmanageable problem. + + +2.1 Dangers of Stale Trust Anchors + + + Whenever a SEP key at a security apex is rolled there exists a danger + that "stale anchors" are created. A stale anchor is a trust anchor + (i.e. a public key configured in a validating resolver) that relates + to a private key that is no longer used for signing. + + + The problem with a stale anchors is that they will (from the + validating resolvers point of view) prove data to be false even + though it is actually correct. This is because the data is either + signed by a new key or is no longer signed and the resolver expects + data to be signed by the old (now stale) key. + + + This situation is arguably worse than not having a trusted key + configured for the secure entry point, since with a stale key no + lookup is typically possible (presuming that the default + configuration of a validating recursive nameserver is to not give out + data that is signed but failed to verify. + + + The danger of making configured trust anchors become stale anchors + + + + +Ihren, et al. Expires April 18, 2005 [Page 5] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + may be a reason for zone owners not to roll their keys. If a + resolver is configured with many trust anchors that need manual + maintenance it may be easy to not notice a key rollover at a security + apex, resulting in a stale anchor. + + + In Section 3 this memo sets out a lightweight, in-DNS, mechanism to + track key rollovers and modify the configured trust anchors + accordingly. The mechanism is stateless and does not need protocol + extensions. The proposed design is that this mechanism is + implemented as a "trust updating machine" that is run entirely + separate from the validating resolver except that the trust updater + will have influence over the trust anchors used by the latter. + + + In Section 4 we describe a method [Editors note: for now only the + frame work and a set of requirements] to install trust anchors. This + method can be used at first configuration or when the trust anchors + became stale (typically due to a failure to track several rollover + events). + + + The choice for which domains trust anchors are to be configured is a + local policy issue. So is the choice which trust anchors has + prevalence if there are multiple chains of trust to a given piece of + DNS data (e.g. when a parent zone and its child both have trust + anchors configured). Both issues are out of the scope of this + document. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 6] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +3. Threshold-based Trust Anchor Rollover + + +3.1 The Rollover + + + When a key pair is replaced all signatures (in DNSSEC these are the + RRSIG records) created with the old key will be replaced by new + signatures created by the new key. Access to the new public key is + needed to verify these signatures. + + + Since zone signing keys are in "the middle" of a chain of authority + they can be verified using the signature made by a key signing key. + Rollover of zone signing keys is therefore transparent to validators + and requires no action in the validator end. + + + But if a key signing key is rolled a resolver can determine its + authenticity by either following the authorization chain from the + parents DS record, an out-of-DNS authentication mechanism or by + relying on other trust anchors known for the zone in which the key is + rolled. + + + The threshold trust anchor rollover mechanism (or trust update), + described below, is based on using existing trust anchors to verify a + subset of the available signatures. This is then used as the basis + for a decision to accept the new keys as valid trust anchors. + + + Our example pseudo zone below contains a number of key signing keys + numbered 1 through Y and two zone signing keys A and B. During a key + rollover key 2 is replaced by key Y+1. The zone content changes + from: + + + example.com. DNSKEY key1 + example.com. DNSKEY key2 + example.com. DNSKEY key3 + ... + example.com. DNSKEY keyY + + + example.com. DNSKEY keyA + example.com. DNSKEY keyB + + + example.com. RRSIG DNSKEY ... (key1) + example.com. RRSIG DNSKEY ... (key2) + example.com. RRSIG DNSKEY ... (key3) + ... + example.com. RRSIG DNSKEY ... (keyY) + example.com. RRSIG DNSKEY ... (keyA) + example.com. RRSIG DNSKEY ... (keyB) + + + to: + + + + +Ihren, et al. Expires April 18, 2005 [Page 7] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + example.com. DNSKEY key1 + example.com. DNSKEY key3 + ... + example.com. DNSKEY keyY + example.com. DNSKEY keyY+1 + + + example.com. RRSIG DNSKEY ... (key1) + example.com. RRSIG DNSKEY ... (key3) + ... + example.com. RRSIG DNSKEY ... (keyY) + example.com. RRSIG DNSKEY ... (keyY+1) + example.com. RRSIG DNSKEY ... (keyA) + example.com. RRSIG DNSKEY ... (keyB) + + + When the rollover becomes visible to the verifying stub resolver it + will be able to verify the RRSIGs associated with key1, key3 ... + keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will + not be used for validation, since that key is previously unknown and + therefore not trusted. + + + Note that this example is simplified. Because of operational + considerations described in [5] having a period during which the two + key signing keys are both available is necessary. + + +3.2 Threshold-based Trust Update + + + The threshold-based trust update algorithm applies as follows. If + for a particular secure entry point + o if the DNSKEY RRset in the zone has been replaced by a more recent + one (as determined by comparing the RRSIG inception dates) + and + o if at least M configured trust anchors directly verify the related + RRSIGs over the new DNSKEY RRset + and + o the number of configured trust anchors that verify the related + RRSIGs over the new DNSKEY RRset exceed a locally defined minimum + number that should be greater than one + then all the trust anchors for the particular secure entry point are + replaced by the set of keys from the zones DNSKEY RRset that have the + SEP flag set. + + + The choices for the rollover acceptance policy parameter M is left to + the administrator of the resolver. To be certain that a rollover is + accepted up by resolvers using this mechanism zone owners should roll + as few SEP keys at a time as possible (preferably just one). That + way they comply to the most strict rollover acceptance policy of + M=N-1. + + + + + +Ihren, et al. Expires April 18, 2005 [Page 8] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + The value of M has an upper bound, limited by the number of of SEP + keys a zone owner publishes (i.e. N). But there is also a lower + bound, since it will not be safe to base the trust in too few + signatures. The corner case is M=1 when any validating RRSIG will be + sufficient for a complete replacement of the trust anchors for that + secure entry point. This is not a recommended configuration, since + that will allow an attacker to initiate rollover of the trust anchors + himself given access to just one compromised key. Hence M should in + be strictly larger than 1 as shown by the third requirement above. + + + If the rollover acceptance policy is M=1 then the result for the + rollover in our example above should be that the local database of + trust anchors is updated by removing key "key2" from and adding key + "keyY+1" to the key store. + + +3.3 Possible Trust Update States + + + We define five states for trust anchor configuration at the client + side. + PRIMING: There are no trust anchors configured. There may be priming + keys available for initial priming of trust anchors. + IN-SYNC: The set of trust anchors configured exactly matches the set + of SEP keys used by the zone owner to sign the zone. + OUT-OF-SYNC: The set of trust anchors is not exactly the same as the + set of SEP keys used by the zone owner to sign the zone but there + are enough SEP key in use by the zone owner that is also in the + trust anchor configuration. + UNSYNCABLE: There is not enough overlap between the configured trust + anchors and the set of SEP keys used to sign the zone for the new + set to be accepted by the validator (i.e. the number of + signatures that verify is not sufficient). + STALE: There is no overlap between the configured trust anchors and + the set of SEP keys used to sign the zone. Here validation of + data is no longer possible and hence we are in a situation where + the trust anchors are stale. + + + Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of + the automatic trust update mechanism. The PRIMING state is where a + validator is located before acquiring an up-to-date set of trust + anchors. The transition from PRIMING to IN-SYNC is manual (see + Section 4 below). + + + Example: assume a secure entry point with four SEP keys and a + validator with the policy that it will accept any update to the set + of trust anchors as long as no more than two signatures fail to + validate (i.e. M >= N-2) and at least two signature does validate + (i.e. M >= 2). In this case the rollover of a single key will move + the validator from IN-SYNC to OUT-OF-SYNC. When the trust update + + + + +Ihren, et al. Expires April 18, 2005 [Page 9] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + state machine updates the trust anchors it returns to state IN-SYNC. + + + If if for some reason it fails to update the trust anchors then the + next rollover (of a different key) will move the validator from + OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys + that are configured as trust anchors and that is sufficient to accpt + an automatic update of the trust anchors. + + + The UNSYNCABLE state is where a validator is located if it for some + reason fails to incorporate enough updates to the trust anchors to be + able to accept new updates according to its local policy. In this + example (i.e. with the policy specified above) this will either be + because M < N-2 or M < 2, which does not suffice to authenticate a + successful update of trust anchors. + + + Continuing with the previous example where two of the four SEP keys + have already rolled, but the validator has failed to update the set + of trust anchors. When the third key rolls over there will only be + one trust anchor left that can do successful validation. This is not + sufficient to enable automatic update of the trust anchors, hence the + new state is UNSYNCABLE. Note, however, that the remaining + up-to-date trust anchor is still enough to do successful validation + so the validator is still "working" from a DNSSEC point of view. + + + The STALE state, finally, is where a validator ends up when it has + zero remaining current trust anchors. This is a dangerous state, + since the stale trust anchors will cause all validation to fail. The + escape is to remove the stale trust anchors and thereby revert to the + PRIMING state. + + +3.4 Implementation notes + + + The DNSSEC protocol specification ordains that a DNSKEY to which a DS + record points should be self-signed. Since the keys that serve as + trust anchors and the keys that are pointed to by DS records serve + the same purpose, they are both secure entry points, we RECOMMEND + that zone owners who want to facilitate the automated rollover scheme + documented herein self-sign DNSKEYs with the SEP bit set and that + implementation check that DNSKEYs with the SEP bit set are + self-signed. + + + In order to maintain a uniform way of determining that a keyset in + the zone has been replaced by a more recent set the automatic trust + update machine SHOULD only accept new DNSKEY RRsets if the + accompanying RRSIGs show a more recent inception date than the + present set of trust anchors. This is also needed as a safe guard + against possible replay attacks where old updates are replayed + "backwards" (i.e. one change at a time, but going in the wrong + + + + +Ihren, et al. Expires April 18, 2005 [Page 10] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + direction, thereby luring the validator into the UNSYNCABLE and + finally STALE states). + + + In order to be resilient against failures the implementation should + collect the DNSKEY RRsets from (other) authoritative servers if + verification of the self signatures fails. + + + The threshold-based trust update mechanism SHOULD only be applied to + algorithms, as represented in the algorithm field in the DNSKEY/RRSIG + [3], that the resolver is aware of. In other words the SEP keys of + unknown algorithms should not be used when counting the number of + available signatures (the N constant) and the SEP keys of unknown + algorithm should not be entered as trust anchors. + + + When in state UNSYNCABLE or STALE manual intervention will be needed + to return to the IN-SYNC state. These states should be flagged. The + most appropriate action is human audit possibly followed by + re-priming (Section 4) the keyset (i.e. manual transfer to the + PRIMING state through removal of the configured trust anchors). + + + An implementation should regularly probe the the authoritative + nameservers for new keys. Since there is no mechanism to publish + rollover frequencies this document RECOMMENDS zone owners not to roll + their key signing keys more often than once per month and resolver + administrators to probe for key rollsovers (and apply the threshold + criterion for acceptance of trust update) not less often than once + per month. If the rollover frequency is higher than the probing + frequency then trust anchors may become stale. The exact relation + between the frequencies depends on the number of SEP keys rolled by + the zone owner and the value M configured by the resolver + administrator. + + + In all the cases below a transaction where the threshold criterion is + not satisfied should be considered bad (i.e. possibly spoofed or + otherwise corrupted data). The most appropriate action is human + audit. + + + There is one case where a "bad" state may be escaped from in an + automated fashion. This is when entering the STALE state where all + DNSSEC validation starts to fail. If this happens it is concievable + that it is better to completely discard the stale trust anchors + (thereby reverting to the PRIMING state where validation is not + possible). A local policy that automates removal of stale trust + anchors is therefore suggested. + + +3.5 Possible transactions + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 11] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +3.5.1 Single DNSKEY replaced + + + This is probably the most typical transaction on the zone owners + part. The result should be that if the threshold criterion is + satisfied then the key store is updated by removal of the old trust + anchor and addition of the new key as a new trust anchor. Note that + if the DNSKEY RRset contains exactly M keys replacement of keys is + not possible, i.e. for automatic rollover to work M must be stricly + less than N. + + +3.5.2 Addition of a new DNSKEY (no removal) + + + If the threshold criterion is satisfied then the new key is added as + a configured trust anchor. Not more than N-M keys can be added at + once, since otherwise the algorithm will fail. + + +3.5.3 Removal of old DNSKEY (no addition) + + + If the threshold criterion is satisfied then the old key is removed + from being a configured trust anchor. Note that it is not possible + to reduce the size of the DNSKEY RRset to a size smaller than the + minimum required value for M. + + +3.5.4 Multiple DNSKEYs replaced + + + Arguably it is not a good idea for the zone administrator to replace + several keys at the same time, but from the resolver point of view + this is exactly what will happen if the validating resolver for some + reason failed to notice a previous rollover event. + + + Not more than N-M keys can be replaced at one time or the threshold + criterion will not be satisfied. Or, expressed another way: as long + as the number of changed keys is less than or equal to N-M the + validator is in state OUT-OF-SYNC. When the number of changed keys + becomes greater than N-M the state changes to UNSYNCABLE and manual + action is needed. + + +3.6 Removal of trust anchors for a trust point + + + If the parent of a secure entry point gets signed and it's trusted + keys get configured in the key store of the validating resolver then + the configured trust anchors for the child should be removed entirely + unless explicitly configured (in the utility configuration) to be an + exception. + + + The reason for such a configuration would be that the resolver has a + local policy that requires maintenance of trusted keys further down + the tree hierarchy than strictly needed from the point of view. + + + + +Ihren, et al. Expires April 18, 2005 [Page 12] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + The default action when the parent zone changes from unsigned to + signed should be to remove the configured trust anchors for the + child. This form of "garbage collect" will ensure that the automatic + rollover machinery scales as DNSSEC deployment progresses. + + +3.7 No need for resolver-side overlap of old and new keys + + + It is worth pointing out that there is no need for the resolver to + keep state about old keys versus new keys, beyond the requirement of + tracking signature inception time for the covering RRSIGs as + described in Section 3.4. + + + From the resolver point of view there are only trusted and not + trusted keys. The reason is that the zone owner needs to do proper + maintenance of RRSIGs regardless of the resolver rollover mechanism + and hence must ensure that no key rolled out out the DNSKEY set until + there cannot be any RRSIGs created by this key still legally cached. + + + Hence the rollover mechanism is entirely stateless with regard to the + keys involved: as soon as the resolver (or in this case the rollover + tracking utility) detects a change in the DNSKEY RRset (i.e. it is + now in the state OUT-OF-SYNC) with a sufficient number of matching + RRSIGs the configured trust anchors are immediately updated (and + thereby the machine return to state IN-SYNC). I.e. the rollover + machine changes states (mostly oscillating between IN-SYNC and + OUT-OF-SYNC), but the status of the DNSSEC keys is stateless. + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 13] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +4. Bootstrapping automatic rollovers + + + It is expected that with the ability to automatically roll trust + anchors at trust points will follow a diminished unwillingness to + roll these keys, since the risks associated with stale keys are + minimized. + + + The problem of "priming" the trust anchors, or bringing them into + sync (which could happen if a resolver is off line for a long period + in which a set of SEP keys in a zone 'evolve' away from its trust + anchor configuration) remains. + + + For (re)priming we can rely on out of band technology and we propose + the following framework. + + +4.1 Priming Keys + + + If all the trust anchors roll somewhat frequently (on the order of + months or at most about a year) then it will not be possible to + design a device, or a software distribution that includes trust + anchors, that after being manufactured is put on a shelf for several + key rollover periods before being brought into use (since no trust + anchors that were known at the time of manufacture remain active). + + + To alleviate this we propose the concept of "priming keys". Priming + keys are ordinary DNSSEC Key Signing Keys with the characteristic + that + o The private part of a priming key signs the DNSKEY RRset at the + security apex, i.e. at least one RRSIG DNSKEY is created by a + priming key rather than by an "ordinary" trust anchor + o the public parts of priming keys are not included in the DNSKEY + RRset. Instead the public parts of priming keys are only + available out-of-band. + o The public parts of the priming keys have a validity period. + Within this period they can be used to obtain trust anchors. + o The priming key pairs are long lived (relative to the key rollover + period.) + + +4.1.1 Bootstrapping trust anchors using a priming key + + + To install the trust anchors for a particular security apex an + administrator of a validating resolver will need to: + o query for the DNSKEY RRset of the zone at the security apex; + o verify the self signatures of all DNSKEYs in the RRset; + o verify the signature of the RRSIG made with a priming key -- + verification using one of the public priming keys that is valid at + that moment is sufficient; + + + + + +Ihren, et al. Expires April 18, 2005 [Page 14] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + o create the trust anchors by extracting the DNSKEY RRs with the SEP + flag set. + The SEP keys with algorithms unknown to the validating resolver + SHOULD be ignored during the creation of the trust anchors. + + +4.1.2 Distribution of priming keys + + + The public parts of the priming keys SHOULD be distributed + exclusively through out-of-DNS mechanisms. The requirements for a + distribution mechanism are: + o it can carry the "validity" period for the priming keys; + o it can carry the self-signature of the priming keys; + o and it allows for verification using trust relations outside the + DNS. + A distribution mechanism would benefit from: + o the availability of revocation lists; + o the ability of carrying zone owners policy information such as + recommended values for "M" and "N" and a rollover frequency; + o and the technology on which is based is readily available. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 15] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +5. The Threshold Rollover Mechanism vs Priming + + + There is overlap between the threshold-based trust updater and the + Priming method. One could exclusively use the Priming method for + maintaining the trust anchors. However the priming method probably + relies on "non-DNS' technology and may therefore not be available for + all devices that have a resolver. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 16] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +6. Security Considerations + + +6.1 Threshold-based Trust Update Security Considerations + + + A clear issue for resolvers will be how to ensure that they track all + rollover events for the zones they have configure trust anchors for. + Because of temporary outages validating resolvers may have missed a + rollover of a KSK. The parameters that determine the robustness + against failures are: the length of the period between rollovers + during which the KSK set is stable and validating resolvers can + actually notice the change; the number of available KSKs (i.e. N) + and the number of signatures that may fail to validate (i.e. N-M). + + + With a large N (i.e. many KSKs) and a small value of M this + operation becomes more robust since losing one key, for whatever + reason, will not be crucial. Unfortunately the choice for the number + of KSKs is a local policy issue for the zone owner while the choice + for the parameter M is a local policy issue for the resolver + administrator. + + + Higher values of M increase the resilience against attacks somewhat; + more signatures need to verify for a rollover to be approved. On the + other hand the number of rollover events that may pass unnoticed + before the resolver reaches the UNSYNCABLE state goes down. + + + The threshold-based trust update intentionally does not provide a + revocation mechanism. In the case that a sufficient number of + private keys of a zone owner are simultaneously compromised the the + attacker may use these private keys to roll the trust anchors of (a + subset of) the resolvers. This is obviously a bad situation but it + is not different from most other public keys systems. + + + However, it is important to point out that since any reasonable trust + anchor rollover policy (in validating resolvers) will require more + than one RRSIG to validate this proposal does provide security + concious zone administrators with the option of not storing the + individual private keys in the same location and thereby decreasing + the likelihood of simultaneous compromise. + + +6.2 Priming Key Security Considerations + + + Since priming keys are not included in the DNSKEY RR set they are + less sensitive to packet size constraints and can be chosen + relatively large. The private parts are only needed to sign the + DNSKEY RR set during the validity period of the particular priming + key pair. Note that the private part of the priming key is used each + time when a DNSKEY RRset has to be resigned. In practice there is + therefore little difference between the usage pattern of the private + + + + +Ihren, et al. Expires April 18, 2005 [Page 17] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + part of key signing keys and priming keys. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 18] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +7. IANA Considerations + + + NONE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 19] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +8. References + + +8.1 Normative References + + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY + (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", + RFC 3757, May 2004. + + + [3] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-10 (work in progress), + September 2004. + + +8.2 Informative References + + + [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-12 (work in progress), September + 2004. + + + [5] Kolkman, O., "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practices-01 (work in + progress), May 2004. + + + [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 + Public Key Infrastructure Certificate and CRL Profile", RFC + 2459, January 1999. + + + +Authors' Addresses + + + Johan Ihren + Autonomica AB + Bellmansgatan 30 + Stockholm SE-118 47 + Sweden + + + EMail: johani@autonomica.se + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 20] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + NL + + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + + Bill Manning + EP.net + Marina del Rey, CA 90295 + USA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 21] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +Appendix A. Acknowledgments + + + The present design for in-band automatic rollovers of DNSSEC trust + anchors is the result of many conversations and it is no longer + possible to remember exactly who contributed what. + + + In addition we've also had appreciated help from (in no particular + order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt + Larson and Mark Kosters. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 22] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +Appendix B. Document History + + + This appendix will be removed if and when the document is submitted + to the RFC editor. + + + The version you are reading is tagged as $Revision: 1.1 $. + + + Text between square brackets, other than references, are editorial + comments and will be removed. + + +B.1 prior to version 00 + + + This draft was initially published as a personal submission under the + name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt. + + + Kolkman documented the ideas provided by Ihren and Manning. In the + process of documenting (and prototyping) Kolkman changed some of the + details of the M-N algorithms working. Ihren did not have a chance + to review the draft before Kolkman posted; + + + Kolkman takes responsibilities for omissions, fuzzy definitions and + mistakes. + + +B.2 version 00 + o The name of the draft was changed as a result of the draft being + adopted as a working group document. + o A small section on the concept of stale trust anchors was added. + o The different possible states are more clearly defined, including + examples of transitions between states. + o The terminology is changed throughout the document. The old term + "M-N" is replaced by "threshold" (more or less). Also the + interpretation of the constants M and N is significantly + simplified to bring the usage more in line with "standard" + threshold terminlogy. + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 23] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +Intellectual Property Statement + + + 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. + + + 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. + + + 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. + + + +Disclaimer of Validity + + + 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. + + + +Copyright Statement + + + Copyright (C) The Internet Society (2004). 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. + + + +Acknowledgment + + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Ihren, et al. Expires April 18, 2005 [Page 24] \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt deleted file mode 100644 index d65fa71042..0000000000 --- a/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt +++ /dev/null @@ -1,1010 +0,0 @@ - - - - - - -dnsext Working Group B. Halley -Internet Draft Nominum -Expiration Date: March 2004 - E. Lewis - ARIN - - September 2003 - - - Clarifying the Role of Wild Card Domains - in the Domain Name System - - - draft-ietf-dnsext-wcard-clarify-02.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - To view the list Internet-Draft Shadow Directories, see - http://www.ietf.org/shadow.html. - -Abstract - - The definition of wild cards is recast from the original in RFC 1034, - in words that are more specific and in line with RFC 2119. This - document is meant to supplement the definition in RFC 1034 and to - alter neither the spirit nor intent of that definition. - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 1] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -Table of Contents - - Abstract ................................................ 1 - 1 Introduction ............................................ 2 - 1.1 Document Limits ......................................... 3 - 1.2 Existence ............................................... 4 - 1.3 An Example .............................................. 4 - 1.4 Empty Non-terminals ..................................... 5 - 1.5 Terminology ............................................. 6 - 2 Defining the Wild Card Domain Name ...................... 7 - 3 Defining Existence ...................................... 8 - 4 Impact of a Wild Card In a Query or in RDATA ............ 8 - 5 Impact of a Wild Card Domain On a Response .............. 9 - 6 Considerations with Special Types ....................... 12 - 6.1 SOA RR's at a Wild Card Domain Name ..................... 12 - 6.2 NS RR's at a Wild Card Domain Name ...................... 12 - 6.3 CNAME RR's at a Wild Card Domain Name ................... 13 - 6.4 DNAME RR's at a Wild Card Domain Name ................... 13 - 7 Security Considerations ................................. 14 - 8 References .............................................. 14 - 9 Others Contributing to This Document .................... 14 - 10 Editors ................................................. 15 - Appendix A: Subdomains of Wild Card Domain Names ........ 16 - Full Copyright Statement ................................ 18 - Acknowledgement ......................................... 18 - - - - -1. Introduction - - The first section of this document will give a crisp overview of what - is begin defined, as well as the motivation rewording of an original - document and making a change to bring the specification in line with - implementations. Examples are included to help orient the reader. - - Wild card domain names are defined in Section 4.3.3. of RFC 1034 as - "instructions for synthesizing RRs." [RFC1034]. The meaning of this - is that a specific, special domain name is used to construct - responses in instances in which the query name is not otherwise - represented in a zone. - - A wild card domain name has a specific range of influence on query - names (QNAMEs) within a given class, which is rooted at the domain - name containing the wild card label, and is limited by explicit - entries, zone cuts and empty non-terminal domains (see section 1.3 of - this document). - - - - -Halley & Lewis [Expires March 2004] [Page 2] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Note that a wild card domain name has no special impact on the search - for a query type (QTYPE). If a domain name is found that matches the - QNAME (exact or a wild card) but the QTYPE is not found at that - point, the proper response is that there is no data available. The - search does not continue on to seek other wild cards that might match - the QTYPE. To illustrate, a wild card owning an MX RR does not - 'cover' other names in the zone that own an A RR. There are certain - special case RR types that will be singled out for discussion, the - SOA RR, NS RR, CNAME RR, and DNAME RR. - - Why is this document needed? Empirical evidence suggests that the - words in RFC 1034 are not clear enough. There exist a number of - implementations that have strayed (each differently) from that - definition. There also exists a misconception of operators that the - wild card can be used to add a specific RR type to all names, such as - the MX RR example cited above. This document is also needed as input - to efforts to extend DNS, such as the DNS Security Extensions [RFC - 2535]. Lack of a clear base specification has proven to result in - extension documents that have unpredictable consequences. (This is - true in general, not just for DNS.) - - Another reason this clarification is needed is to answer questions - regarding authenticated denial of existence, a service introduced in - the DNS Security Extensions [RFC 2535]. Prior to the work leading up - to this document, it had been feared that a large number of proof - records (NXTs) might be needed in each reply because of the unknown - number of potential wild card domains that were thought to be - applicable. One outcome of this fear is a now discontinued document - solving a problem that is now known not to exist. I.e., this - clarification has the impact of defending against unwarranted - protocol surgery. It is not "yet another" effort to just rewrite the - early specifications for the sake of purity. - - Although the effort to define the DNS Security Extensions has - prompted this document, the clarifications herein relate to basic DNS - only. No DNS Security Extensions considerations are mentioned in the - document. - -1.1. Document Limits - - This document limits itself to reinforcing the concepts in RFC 1034. - In the effort to do this, a few issues have been discussed that - change parts of what is in RFC 1034. The discussions have been held - within the DNS Extensions Working Group. - - - - - - - -Halley & Lewis [Expires March 2004] [Page 3] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Briefly, the issues raised include: - - The lack of clarity in the definition of domain name existence - - Implications of a wild card domain name owning any of the - following resource record sets: DNAME [RFC 2672], CNAME, NS, and - SOA - - Whether RFC 1034 meant to allow special processing of CNAME RR's - owned by wild card domain names - -1.2. Existence - - The notion that a domain name 'exists' will arise numerous times in - this discussion. RFC 1034 raises the issue of existence in a number - of places, usually in reference to non-existence and often in - reference to processing involving wild card domain names. RFC 1034 - contains algorithms that describe how domain names impact the - preparation of an answer and does define wild cards as a means of - synthesizing answers. Because of this a discussion on wild card - domain names has to start with the issue of existence. - - To help clarify the topic of wild cards, a positive definition of - existence is needed. Complicating matters, though, is the - realization that existence is relative. To an authoritative server, - a domain name exists if the domain name plays a role following the - algorithms of preparing a response. To a resolver, a domain name - exists if there is any data available corresponding to the name. The - difference between the two is the synthesis of records according to a - wild card. - - For the purposes of this document, the point of view of an - authoritative server is adopted. A domain name is said to exist if - it plays a role in the execution of the algorithms in RFC 1034. - -1.3. An Example - - For example, consider this wild card domain name: *.example. Any - query name under example. is a candidate to be matched (answered) by - this wild card, i.e., to have an response returned that is - synthesized from the wild card's RR sets. Although any name is a - candidate, not all queries will match. - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 4] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - To further illustrate this, consider this zone: - - $ORIGIN example. - @ IN SOA - NS - NS - * TXT "this is a wild card" - MX 10 mailhost.example. - host1 A 10.0.0.1 - _ssh._tcp.host1 SRV - _ssh._tcp.host2 SRV - subdel NS - - - The following queries would be synthesized from the wild card: - - QNAME=host3.example. QTYPE=MX, QCLASS=IN - the answer will be a "host3.example. IN MX ..." - QNAME=host3.example. QTYPE=A, QCLASS=IN - the answer will reflect "no error, but no data" - because there is no A RR set at '*' - - The following queries would not be synthesized from the wild card: - - QNAME=host1.example., QTYPE=MX, QCLASS=IN - because host1.example. exists - QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN - because _tcp.host1.example. exists (without data) - QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN - because host2.example. exists (without data) - QNAME=host.subdel.example., QTYPE=A, QCLASS=IN - because subdel.example. exists and is a zone cut - - To the server, the following domains are considered to exist in the - zone: *, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2, - _ssh._tcp.host2, and subdel. To a resolver, many more domains appear - to exist via the synthesis of the wild card. - -1.4. Empty Non-terminals - - Empty non-terminals are domain names that own no data but have - subdomains. This is defined in section 3.1 of RFC 1034: - -# The domain name space is a tree structure. Each node and leaf on the -# tree corresponds to a resource set (which may be empty). The domain -# system makes no distinctions between the uses of the interior nodes and -# leaves, and this memo uses the term "node" to refer to both. - - - - -Halley & Lewis [Expires March 2004] [Page 5] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - The parenthesized "which may be empty" specifies that empty non- - terminals are explicitly recognized. According to the definition of - existence in this document, empty non-terminals do exist at the - server. - - Carefully reading the above paragraph can lead to an interpretation - that all possible domains exist - up to the suggested limit of 255 - octets for a domain name [RFC 1035]. For example, www.example. may - have an A RR, and as far as is practically concerned, is a leaf of - the domain tree. But the definition can be taken to mean that - sub.www.example. also exists, albeit with no data. By extension, all - possible domains exist, from the root on down. As RFC 1034 also - defines "an authoritative name error indicating that the name does - not exist" in section 4.3.1, this is not the intent of the original - document. - - RFC1034's wording is to be clarified by adding the following - paragraph: - - A node is considered to have an impact on the algorithms of - 4.3.2 if it is a leaf node with any resource sets or an interior - node, with or without a resource set, that has a subdomain that - is a leaf node with a resource set. A QNAME and QCLASS matching - an existing node never results in a response return code of - authoritative name error. - - The terminology in the above paragraph is chosen to remain as close - to that in the original document. The term "with" is a alternate - form for "owning" in this case, hence "a leaf node owning resources - sets, or an interior node, owning or not owning any resource set, - that has a leaf node owning a resource set as a subdomain," is the - proper interpretation of the middle sentence. - - As an aside, an "authoritative name error" has been called NXDOMAIN - in some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic - assigned to such an error by at least one implementation of DNS. As - this mnemonic is specific to implementations, it is avoided in the - remainder of this document. - -1.5. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in the document entitled - "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] - - Requirements are denoted by paragraphs that begin with with the - following convention: 'R'.. - - - -Halley & Lewis [Expires March 2004] [Page 6] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Quotations of RFC 1034 (as has already been done once above) are - denoted by a '#' in the leftmost column. - -2. Defining the Wild Card Domain Name - - A wild card domain name is defined by having the initial label be: - - 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) - - This defines domain names that may play a role in being a wild card, - that is, being a source for synthesized answers. Domain names - conforming to this definition that appear in queries and RDATA - sections do not have any special role. These cases will be described - in more detail in following sections. - - R2.1 A domain name that is to be interpreted as a wild card MUST - begin with a label of '0000 0001 0010 1010' in binary. - - The first octet is the normal label type and length for a 1 octet - long label, the second octet is the ASCII representation [RFC 20] for - the '*' character. In RFC 1034, ASCII encoding is assumed to be the - character encoding. - - In the master file formats used in RFCs, a "*" is a legal - representation for the wild card label. Even if the "*" is escaped, - it is still interpreted as the wild card when it is the only - character in the label. - - R2.2 A server MUST treat a wild card domain name as the basis of - synthesized answers regardless of any "escape" sequences in the - input format. - - RFC 1034 and RFC 1035 ignore the case in which a domain name might be - "the*.example.com." The interpretation is that this domain name in a - zone would only match queries for "the*.example.com" and not have any - other role. - - Note: By virtue of this definition, a wild card domain name may have - a subdomain. The subdomain (or sub-subdomain) itself may also be a - wild card. E.g., *.*.example. is a wild card, so is *.sub.*.example. - More discussion on this is given in Appendix A. - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 7] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -3. Defining Existence - - As described in the Introduction, a precise definition of existence - is needed. - - R3.1 An authoritative server MUST treat a domain name as existing - during the execution of the algorithms in RFC 1034 when the - domain name conforms to the following definition. A domain name - is defined to exist if the domain name owns data and/or has a - subdomain that exists. - - Note that at a zone boundary, the domain name owns data, including - the NS RR set. At the delegating server, the NS RR set is not - authoritative, but that is of no consequence here. The domain name - owns data, therefore, it exists. - - R3.2 An authoritative server MUST treat a domain name that has - neither a resource record set nor an existing subdomain as non- - existent when executing the algorithm in section 4.3.2. of RFC - 1034. - - A note on terminology. A domain transcends zones, i.e., all DNS data - is in the root domain but segmented into zones of control. In this - document, there are references to a "domain name" in the context of - existing "in a zone." In this usage, a domain name is the root of a - domain, not the entire domain. The domain's root point is said to - "exist in a zone" if the zone is authoritative for the name. RR sets - existing in a domain need not be owned by the domain's root domain - name, but are owned by other domain names in the domain. - -4. Impact of a Wild Card In a Query or in RDATA - - When a wild card domain name appears in a question, e.g., the query - name is "*.example.", the response in no way differs from any other - query. In other words, the wild card label in a QNAME has no special - meaning, and query processing will proceed using '*' as a literal - query name. - - R4.1 A wild card domain name acting as a QNAME MUST be treated as any - other QNAME, there MUST be no special processing accorded it. - - If a wild card domain name appears in the RDATA of a CNAME RR or any - other RR that has a domain name in it, the same rule applies. In the - instance of a CNAME RR, the wild card domain name is used in the same - manner of as being the original QNAME. For other RR's, rules vary - regarding what is done with the domain name(s) appearing in them, in - no case does the wild card hold special meaning. - - - - -Halley & Lewis [Expires March 2004] [Page 8] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - R4.2 A wild card domain name appearing in any RR's RDATA MUST be - treated as any other domain name in that situation, there MUST - be no special processing accorded it. - -5. Impact of a Wild Card Domain On a Response - - The description of how wild cards impact response generation is in - RFC 1034, section 4.3.2. That passage contains the algorithm - followed by a server in constructing a response. Within that - algorithm, step 3, part 'c' defines the behavior of the wild card. - The algorithm is directly quoted in lines that begin with a '#' sign. - Commentary is interleaved. - - There is a documentation issue deserving some explanation. The - algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo - code, i.e., it's steps are not intended to be followed in strict - order. The "algorithm" is a suggestion. As such, in step 3, parts - a, b, and c, do not have to be implemented in that order. - - Another issue needing explanation is that RFC 1034 is a full - standard. There is another RFC, RFC 2672, which makes, or proposes - an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME - RR. RFC 2672 is a proposed standard. The dilemma in writing these - clarifications is knowing which document is the one being clarified. - Fortunately, the difference between RFC 1034 and RFC 2672 is not - significant with respect to wild card synthesis, so this document - will continue to state that it is clarifying RFC 1034. If RFC 2672 - progresses along the standards track, it will need to refer to - modifying RFC 1034's algorithm as amended here. - - The context of part 'c' is that the search is progressing label by - label through the QNAME. (Note that the data being searched is the - authoritative data in the server, the cache is searched in step 4.) - Step 3's part 'a' covers the case that the QNAME has been matched in - full, regardless of the presence of a CNAME RR. Step 'b' covers - crossing a cut point, resulting in a referral. All that is left is - to look for the wild card. - - Step 3 of the algorithm also assumes that the search is looking in - the zone closest to the answer, i.e., in the same class as QCLASS and - as close to the authority as possible on this server. If the zone is - not the authority, then a referral is given, possibly one indicating - lameness. - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 9] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if a -# the "*" label exists. - - The above paragraph refers to finding the domain name that exists in - the zone and that most encloses the QNAME. Such a domain name will - mark the boundary of candidate wild card domain names that might be - used to synthesize an answer. (Remember that at this point, if the - most enclosing name is the same as the QNAME, part 'a' would have - recorded an exact match.) The existence of the enclosing name means - that no wild card name higher in the tree is a candidate to answer - the query. - - Once the closest enclosing node is identified, there's the matter of - what exists below it. It may have subdomains, but none will be - closer to the QNAME. One of the subdomains just might be a wild - card. If it exists, this is the only wild card eligible to be used - to synthesize an answer for the query. Even if the closest enclosing - node conforms to the syntax rule in section 2 for being a wild card - domain name, the closest enclosing node is not eligible to be a - source of a synthesized answer. - - The only wild card domain name that is a candidate to synthesize an - answer will be the "*" subdomain of the closest enclosing domain - name. Three possibilities can happen. The "*" subdomain does not - exist, the "*" subdomain does but does not have an RR set of the same - type as the QTYPE, or it exists and has the desired RR set. - - For the sake of brevity, the closest enclosing node can be referred - to as the "closest encloser." The closest encloser is the most - important concept in this clarification. Describing the closest - encloser is a bit tricky, but it is an easy concept. - - To find the closest encloser, you have to first locate the zone that - is the authority for the query name. This eliminates the need to be - concerned that the closest encloser is a cut point. In addition, we - can assume too that the query name does not exist, hence the closest - encloser is not equal to the query name. We can assume away these - two cases because they are handled in steps 2, 3a and 3b of section - 4.3.2.'s algorithm. - - What is left is to identify the existing domain name that would have - been up the tree (closer to the root) from the query name. Knowing - that an exact match is impossible, if there is a "*" label descending - from the unique closest encloser, this is the one and only wild card - from which an answer can be synthesized for the query. - - - - - -Halley & Lewis [Expires March 2004] [Page 10] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - To illustrate, using the example in section 1.2 of this document, the - following chart shows QNAMEs and the closest enclosers. In - Appendix A there is another chart showing unusual cases. - - QNAME Closest Encloser Wild Card Source - host3.example. example. *.example. - _telnet._tcp.host1.example. _tcp.host1.example. no wild card - _telnet._tcp.host2.example. host2.example. no wild card - _telnet._tcp.host3.example. example. *.example. - _chat._udp.host3.example. example. *.example. - - Note that host1.subdel.example. is in a subzone, so the search for it - ends in a referral in part 'b', thus does not enter into finding a - closest encloser. - - The fact that a closest encloser will be the only superdomain that - can have a candidate wild card will have an impact when it comes to - designing authenticated denial of existence proofs. - -# If the "*" label does not exist, check whether the name -# we are looking for is the original QNAME in the query -# or a name we have followed due to a CNAME. If the name -# is original, set an authoritative name error in the -# response and exit. Otherwise just exit. - - The above passage says that if there is not even a wild card domain - name to match at this point (failing to find an explicit answer - elsewhere), we are to return an authoritative name error at this - point. If we were following a CNAME, the specification is unclear, - but seems to imply that a no error return code is appropriate, with - just the CNAME RR (or sequence of CNAME RRs) in the answer section. - -# If the "*" label does exist, match RRs at that node -# against QTYPE. If any match, copy them into the answer -# section, but set the owner of the RR to be QNAME, and -# not the node with the "*" label. Go to step 6. - - This final paragraph covers the role of the QTYPE in the process. - Note that if no resource record set matches the QTYPE the result is - that no data is copied, but the search still ceases ("Go to step - 6."). In the following section, a suggested change is made to this, - under the heading "CNAME RRs at a Wild Card Domain Name." - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 11] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -6. Considerations with Special Types - - For the purposes of this section, "special" means that a record - induces processing at the server beyond simple lookup. The special - types in this section are SOA, NS, CNAME, and DNAME. SOA is special - because it is used as a zone marker and has an impact on step 2 of - the algorithm in 4.3.2. NS denotes a cut point and has an impact on - step 3b. CNAME redirects the query and is mentioned in steps 3a and - 3b. DNAME is a "CNAME generator." - -6.1. SOA RR's at a Wild Card Domain Name - - If the owner of an SOA record conforms to the basic rules of owning - an SOA RR (meaning it is the apex of a zone) the impact on the search - algorithm is not in section 3c (where records are synthesized) as - would be expected. The impact is really in step 2 of the algorithm, - the choice of zone. - - We are no longer talking about whether or not an SOA RR can be - synthesized in a response because we are shifting attention to step - 2. We are now talking about what it means for a name server to - synthesize a zone for a response. To date, no implementation has - done this. Thinking ahead though, anyone choosing to pursue this - would have to be aware that a server would have to be able to - distinguish between queries for data it will have to synthesize and - queries that ought to be treated as if they were prompted by a lame - delegation. - - It is not a protocol error to have an SOA RR owned by a wild card - domain name, just as it is not an error to have zone name be - syntactically equivalent to a domain name. However, this situation - requires careful consideration of how a server chooses the - appropriate zone for an answer. And an SOA RR is not able to be - synthesized as in step 3c. - -6.2. NS RR's at a Wild Card Domain Name - - Complimentary to the issue of an SOA RR owned by a wild card domain - name is the issue of NS RR's owned by a wild card domain name. In - this instance, each machine being referred to in the RDATA of the NS - RR has to be able to understand the impact of this on step 2, the - choosing of the authoritative zone. - - Referring to the same machine in such a NS RR will probably not work - well. This is because the server may become confused as to whether - the query name ought to be answered by the zone owning the NS RR in - question or a synthesized zone. (It isn't known in advance that the - query name will invoke the wild card synthesis.) - - - -Halley & Lewis [Expires March 2004] [Page 12] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - The status of other RR's owned by a wild card domain name is the same - as if the owner name was not a wild card domain name. I.e., when - there is a NS RR at a wild card domain name, other records are - treated as being below the zone cut. - - Is it not a protocol error to have a NS RR owned by a wild card - domian name, complimentary to the case of a SOA RR. However, for - this to work, an implementation has to know how to synthesize a zone. - -6.3. CNAME RR's at a Wild Card Domain Name - - The issue of CNAME RR's owned by wild card domain names has prompted - a suggested change to the last paragraph of step 3c of the algorithm - in 4.3.2. The changed text is this: - - If the "*" label does exist and if the data at the node is a - CNAME and QTYPE doesn't match CNAME, copy the CNAME RR into the - answer section of the response, set the owner of the CNAME RR to - be QNAME, and then change QNAME to the canonical name in the - CNAME RR, and go back to step 1. - - If the "*" label does exist and either QTYPE is CNAME or the - data at the node is not a CNAME, then match RRs at that node - against QTYPE. If any match, copy them into the answer section, - but set the owner of the RR to be QNAME, and not the node with - the "*" label. Go to step 6. - - Apologies if the above isn't clear, but an attempt was made to stitch - together the passage using just the phrases in section 3a and 3c of - the algorithm so as to preserve the original flavor. - - In case the passage as suggested isn't clear enough, the intent is to - make "landing" at a wild card name and finding a CNAME the same as if - this happened as a result of a direct match. I.e., Finding a CNAME - at the name matched in step 3c is supposed to have the same impact as - finding the CNAME in step 3a. - -6.4. DNAME RR's at a Wild Card Domain Name - - The specification of the DNAME RR, which is at the proposed level of - standardization, is not as mature as the full standard in RFC 1034. - Because of this, or the reason for this is, there appears to be a - host of issues with that definition and it's rewrite of the algorithm - in 4.3.2. For the time being, when it comes to wild card processing - issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME - at a wild card domain name is effectively the same as a CNAME at a - wild card domain name. - - - - -Halley & Lewis [Expires March 2004] [Page 13] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -7. Security Considerations - - This document is refining the specifications to make it more likely - that security can be added to DNS. No functional additions are being - made, just refining what is considered proper to allow the DNS, - security of the DNS, and extending the DNS to be more predictable. - -8. References - - Normative References - - [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 - - [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, - Nov-01-1987 - - [RFC 1035] Domain Names - Implementation and Specification, P.V - Mockapetris, Nov-01-1987 - - [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S - Bradner, March 1997 - - Informative References - - [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie, - Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 - - [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 - - [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 - -9. Others Contributing to This Document - - Others who have directly caused text to appear in the document: Paul - Vixie and Olaf Kolkman. Many others have indirect influences on the - content. - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 14] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -10. Editors - - Name: Bob Halley - Affiliation: Nominum, Inc. - Address: 2385 Bay Road, Redwood City, CA 94063 USA - Phone: +1-650-381-6016 - EMail: Bob.Halley@nominum.com - - Name: Edward Lewis - Affiliation: ARIN - Address: 3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA - Phone: +1-703-227-9854 - Email: edlewis@arin.net - - Comments on this document can be sent to the editors or the mailing - list for the DNSEXT WG, namedroppers@ops.ietf.org. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 15] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -Appendix A: Subdomains of Wild Card Domain Names - - In reading the definition of section 2 carefully, it is possible to - rationalize unusual names as legal. In the example given, - *.example. could have subdomains of *.sub.*.example. and even the - more direct *.*.example. (The implication here is that these domain - names own explicit resource records sets.) Although defining these - names is not easy to justify, it is important that implementions - account for the possibility. This section will give some further - guidence on handling these names. - - The first thing to realize is that by all definitions, subdomains of - wild card domain names are legal. In analyzing them, one realizes - that they cause no harm by their existence. Because of this, they - are allowed to exist, i.e., there are no special case rules made to - disallow them. The reason for not preventing these names is that the - prevention would just introduce more code paths to put into - implementations. - - The concept of "closest enclosing" existing names is important to - keep in mind. It is also important to realize that a wild card - domain name can be a closest encloser of a query name. For example, - if *.*.example. is defined in a zone, and the query name is - a.*.example., then the closest enclosing domain name is *.example. - Keep in mind that the closest encloser is not eligible to be a source - of synthesized answers, just the subdomain of it that has the first - label "*". - - To illustrate this, the following chart shows some matches. Assume - that the names *.example., *.*.example., and *.sub.*.example. are - defined in the zone. - - QNAME Closest Encloser Wild Card Source - a.example. example. *.example. - b.a.example. example. *.example. - a.*.example. *.example. *.*.example. - b.a.*.example. *.example. *.*.example. - b.a.*.*.example. *.*.example. no wild card - a.sub.*.example. sub.*.example. *.sub.*.example. - b.a.sub.*.example. sub.*.example. *.sub.*.example. - a.*.sub.*.example. *.sub.*.example. no wild card - *.a.example. example. *.example. - a.sub.b.example. example. *.example. - - Recall that the closest encloser itself cannot be the wild card. - Therefore the match for b.a.*.*.example. has no applicable wild card. - - - - - -Halley & Lewis [Expires March 2004] [Page 16] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Finally, if a query name is sub.*.example., any answer available will - come from an exact name match for sub.*.example. No wild card - synthesis is performed in this case. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 17] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society 2003. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 18] diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt new file mode 100644 index 0000000000..8033c0c1c0 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt @@ -0,0 +1,818 @@ + +DNSEXT Working Group E. Lewis +INTERNET DRAFT NeuStar +Expiration Date: April 2005 October 2004 + + Clarifying the Role of Wild Card Domains + in the Domain Name System + + draft-ietf-dnsext-wcard-clarify-03.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + This Internet-Draft will expire on April 11, 2005. + + +Copyright Notice + + Copyright (C) The Internet Society (2004). + + +Abstract + + The definition of wild cards is recast from the original in RFC 1034, + in words that are more specific and in line with RFC 2119. This + document is meant to supplement the definition in RFC 1034 and not to + significantly alter the spirit or intent of that definition. + +1 Introduction + + In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the synthesis + of answers from special records called wildcards. The original + definitions are incomplete. This document clarifies and describes + the wildcard synthesis by adding to the discussion and making + limited modifications. Modifications are made only where necessary + to close inconsistencies that have led to interoperability issues. + +1.1 Motivation + + Over time many implementations have diverged in different ways from + the original definition, or at least what had been intended. Although + there is clearly a need to clarify the original documents in light + of this, the impetus for this document lay in the engineering of + the DNS security extensions [RFC TBD]. With an unclear definition + of wildcards the design of authenticated denial became entangled. + + Although this document is motivated by DNSSEC and the need to + have a separate document passed for the sake of DNSSEC, other + motivations have risen. The renewed understanding of wildcards gained + is worthy of being documented. + +1.2 The Original Definition + + This document is intended to not make changes. To reinforce + this, sections of RFC 1034 are repeated verbatim for convenience + of the reader, to help in comparison of old and new text. + + There are a few passages which are changed. This may seem to + contradict the goal of not changing the original specification, + but the changes herein are required because of inconsistencies + with the wording in RFC 1034. + + The beginning of the discussion ought to start with the definition + of the term "wildcard" as it appears in RFC 1034, section 4.3.3. + +# In the previous algorithm, special treatment was given to RRs with owner +# names starting with the label "*". Such RRs are called wildcards. +# Wildcard RRs can be thought of as instructions for synthesizing RRs. +# When the appropriate conditions are met, the name server creates RRs +# with an owner name equal to the query name and contents taken from the +# wildcard RRs. + + + This passage appears after the algorithm in which they are used is + presented. The terminology is not consistent, the word "wildcard" + is clearly defined to be a resource record. In the next sentence + the term is shifted to be an adjective, the first step on the + path to overloading the term. Wildcard has also been used to + refer to domain names that begin with a "*". + +1.3 The Clarification + + The clarification effort can be divided into three sections. One + is the use of new terminology to better describe wildcards. Changes + to words in RFC 1034 that have resulted by discovering conflicting + concepts are presented. Descriptions of special type records in the + context of being wildcards is discussed. + +1.3.1 New Terms + + The term "wildcard" has become so overloaded it is virtually useless + as a description. A few new terms will be introduced to be more + descriptive. The new terms that will be introduced are: + + Asterisk Label - a label consisting of an asterisk ("*") and no + other characters. + + Wild Card Domain Name - a domain name whose least significant + label (first when reading left to right) is an asterisk label. + Other labels might also be asterisk labels. + + Source of Synthesis - a Wild Card Domain Name when it is consulted in + the final paragraph of step 3, part c of RFC 1034's 4.3.2 algorithm. + + Closest Encloser - in RFC 1034's 4.3.2 algorithm, the name at which + the last match was possible in step 3, part c. This is the longest + sequence of exactly matching labels from the root downward in both the + sought name (QNAME) and in the zone being examined. + + + Label Match - two labels are equivalent if the label type and label + length are the same bit sequence and if the name is the label is + equivalent bit wise after down casing all of the ASCII characters. + [Ed note: do we still call them ASCII?] + + These terms will be more fully described as needed later. These + terms will be used to describe a few changes to the words in RFC + 1034. A summary of the changes appear next and will be fully + covered in later sections. + +1.3.2 Changed Text + + The definition of "existence" is changed, superficially, to exclude + empty domains that have no subdomains with resource records. This + change will not be apparent to implementations, it is needed to + make descriptions more concise. + + In RFC 1034, there is text that seems to bar having two Asterisk + Labels in a Wild Card Domain Name. There is no further discussion, + no prescribed error handling, nor enforcement described. In this + document, the use of such names will be discouraged, but implementations + will have to account for the possibility of such a name's use. + + The actions when a Source of Synthesis owns a CNAME RR are changed to + mirror the actions if an exact match name owns a CNAME RR. This + is an addition to the words in RFC 1034, section 4.3.2, step 3, + part c. + +1.3.3 Considerations with Special Types + + This clarification will describe in some detail the semantics of + wildcard CNAME RRs, wildcard NS RRs, wildcard SOA RR's, + wildcard DNAME RRs [RFC wxyz], and empty, non-terminal wildcards. + Understanding these types in the context of wildcards has been + clouded because these types incur special processing if they + are the result of an exact match. + + By the definition in RFC 1034, there can be no empty, non-terminal + "wildcards", but in the algorithm, it is possible that an empty + non-terminal is sought as the potential owner of a "wildcard." This + is one example of why the ordering of the discussion in RFC 1034 is + confusing. + + +1.4 Standards Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in the document entitled + "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] + + Quotations of RFC 1034 (as has already been done once above) are + denoted by a '#' in the leftmost column. + + +2 "Wildcard" + + The context of the wildcard concept involves the algorithm by which + a name server prepares a response (in RFC 1034's section 4.3.2) and + the way in which a resource record (set) is identified as being a + source of synthetic data (section 4.3.3). + + Tackling the latter first, there are two objectives in defining a + means to identify a resource record set as a source of synthesis. + First is the desire to maintain all DNS data in a consistent manner. + Avoiding the need for implementations to have many internal data + structures is a good thing. Not that this means limiting quantity, + but rather types of data. The second objective impacts interoperability, + that is a master server of one implementation has to be able to + send the synthesis instructions to the slaves. Although there are + alternatives to the use of zone transfers via port 53, a truly + interoperable record synthesis approach has to be able to insert the + synthesis instructions into a zone transfer. + + The objectives in describing the synthesis of records in the context + of the name server algorithm include knowing when to employ the + process of synthesis and how the synthesis is carried out. + +2.1 Identifying a wildcard + + To provide a more accurate description of "wildcards", the definition + has to start with a discussion of the domain names that appear as + owners. + +2.1.1 Wild Card Domain Name and Asterisk Label + + A "Wild Card Domain Name" is defined by having its initial label be: + + 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) + + + The first octet is the normal label type and length for a 1 octet + long label, the second octet is the ASCII representation [RFC 20] for + the '*' character. In RFC 1034, ASCII encoding is assumed to be the + character encoding. + + A descriptive name of a label equaling that value is an "Asterisk + Label." + + RFC 1034's definition of wildcard would be "a resource record owned + by a Wild Card Domain Name." This is mentioned to help maintain some + orientation between this clarification and RFC 1034. Keep in mind, + that in "Clarifications to the DNS Specification" [RFC 2181] the name + of the basic unit of DNS data became the resource record set (RRSet) and + not the resource record. + +2.1.2 Variations on Wild Card Domain Names + + RFC 1034 and RFC 1035 do not explicitly mention the case in which a + domain name might be something like "the*.example.com." The + interpretation is that this domain name in a zone would only match + queries for "the*.example.com" and not have any other role. An + asterisk ('*') occurring other than as the sole character in + a label is simply a character forming part of the label and has no + special meaning. This is not an Asterisk Label, simply a label + an asterisk in it. The same is true for "**.example.com." and + "*the.example.com." + + [Ed note: the above paragraph reads too strong. The intent ought to + be that such names do not fall under the rules of wildcards. The + intent is not to bar any future attempts to define other forms of + synthesis - nor is the intent to encourage them.] + + The interpretation of a wild card domain specification which is not a + leaf domain is not clearly defined in RFC 1034. E.g., sub.*.example., + is not discussed, not barred. In wanting to minimize changes from + the original specification, such names are permitted. Although + "sub.*.example." is not a Wild Card Domain Name, "*.example." is. + + RRSets used to synthesize records can be owned by a Wild Card Domain + Name that has subdomains. + +2.1.3 Non-terminal Wild Card Domain Names + + In section 4.3.3, the following is stated: + +# .......................... The owner name of the wildcard RRs is of +# the form "*.", where is any domain name. +# should not contain other * labels...................... + + This covers names like "*.foo.*.example." The pre-RFC2119 wording uses + "should not" which has an ambiguous meaning. The specification does not + proscribe actions upon seeing such a name, such as whether or not a + zone containing the name should fail to be served. What if a dynamic + update (RFC2136) requested to add the name to the zone? The failure + semantics are not defined. + + The recommendation is that implementations ought to anticipate the + appearance of such names but generally discourage their use in + operations. No standards statement, such as "MAY NOT" or "SHOULD NOT" + is made here. + + The interpretation of this is, when seeking a Wild Card Domain Name + for the purposes of record synthesis, an implementation ought not to + check the domain name for subdomains. + + It is possible that a Wild Card Domain Name is an empty non-terminal. + (See the upcoming sections on empty non-terminals.) In this case, + the lookup will terminate as would any empty non-terminal match. + +2.2 Existence Rules + + The notion that a domain name 'exists' arises numerous times in + discussions about the wildcard concept. RFC 1034 raises the issue + of existence in a number of places, usually in reference to + non-existence and in reference to processing involving wildcards. + RFC 1034 contains algorithms that describe how domain names impact + the preparation of an answer and does define wildcards as a means of + synthesizing answers. Because of this a discussion on wildcards + needs to cover a definition of existence. + + + To help clarify the topic of wild cards, a positive definition of + existence is needed. Complicating matters, though, is the + realization that existence is relative. To an authoritative server, + a domain name exists if the domain name plays a role following the + algorithms of preparing a response. To a resolver, a domain name + exists if there is any data available corresponding to the name. The + difference between the two is the synthesis of records according to a + wildcard. + + For the purposes of this document, the point of view of an + authoritative server is more interesting. A domain name is said to + exist if it plays a role in the execution of the algorithms in RFC 1034. + +2.2.1. An Example + + To illustrate what is meant by existence consider this complete zone: + + + $ORIGIN example. + example. 3600 IN SOA + example. 3600 NS ns.example.com. + example. 3600 NS ns.example.net. + *.example. 3600 TXT "this is a wild card" + *.example. 3600 MX 10 host1.example. + host1.example. 3600 A 192.0.4.1 + _ssh._tcp.host1.example. 3600 SRV + _ssh._tcp.host2.example. 3600 SRV + subdel.example. 3600 NS ns.example.com. + subdel.example. 3600 NS ns.example.net. + + + A look at the domain names in a tree structure is helpful: + + | + -------------example------------ + / / \ \ + / / \ \ + / / \ \ + * host1 host2 subdel + | | + | | + _tcp _tcp + | | + | | + _ssh _ssh + + The following queries would be synthesized from the wild card: + + QNAME=host3.example. QTYPE=MX, QCLASS=IN + the answer will be a "host3.example. IN MX ..." + + + QNAME=host3.example. QTYPE=A, QCLASS=IN + the answer will reflect "no error, but no data" + because there is no A RR set at '*.example.' + + + QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN + the answer will be "foo.bar.example. IN TXT ..." + because bar.example. does not exist, but the wildcard does. + + The following queries would not be synthesized from the wild card: + + QNAME=host1.example., QTYPE=MX, QCLASS=IN + because host1.example. exists + + QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN + because *.example. exists + + QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN + because _tcp.host1.example. exists (without data) + + + QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN + because host2.example. exists (without data) + + + QNAME=host.subdel.example., QTYPE=A, QCLASS=IN + because subdel.example. exists (and is a zone cut) + + To the server, all of the domains in the tree exist. The resolver will + get answers to some names off the tree, thanks to synthesis. + +2.2.2 Empty Non-terminals + + Empty non-terminals are domain names that own no resource records but + have subdomains which do. This is defined in section 3.1 of RFC 1034: + +# The domain name space is a tree structure. Each node and leaf on the +# tree corresponds to a resource set (which may be empty). The domain +# system makes no distinctions between the uses of the interior nodes and +# leaves, and this memo uses the term "node" to refer to both. + + The parenthesized "which may be empty" specifies that empty non- + terminals are explicitly recognized. According to the definition of + existence in this document, empty non-terminals do exist at the + server. + + Pedantically reading the above paragraph can lead to an + interpretation that all possible domains exist - up to the suggested + limit of 255 octets for a domain name [RFC 1035]. For example, + www.example. may have an A RR, and as far as is practically + concerned, is a leaf of the domain tree. But the definition can be + taken to mean that sub.www.example. also exists, albeit with no data. + By extension, all possible domains exist, from the root on down. As + RFC 1034 also defines "an authoritative name error indicating that + the name does not exist" in section 4.3.1, this is not the intent of + the original document. + +2.2.3 Yet Another Definition of Existence + + RFC1034's wording is clarified by the following paragraph: + + A node is considered to have an impact on the algorithms of + 4.3.2 if it is a leaf node with any resource sets or an interior + node (with or without a resource set) that has a subdomain that + is a leaf node with a resource set. A QNAME and QCLASS matching + an existing node never results in a response code of + authoritative name error (RCODE==3). + + The terminology in the above paragraph is chosen to remain as close + to that in the original document. The term "with" is a alternate + form for "owning" in this case, hence "a leaf node owning resources + sets, or an interior node, owning or not owning any resource set, + that has a leaf node owning a resource set as a subdomain," is the + proper interpretation of the middle sentence. + + As an aside, an "authoritative name error", response code (RCODE) 3, + has been called NXDOMAIN in some RFCs, such as RFC 2136 [RFC 2136]. + NXDOMAIN is the mnemonic assigned to such an error by at least one + implementation of DNS. + + Summarizing the discussion on existence in non-RFC1034 words: + + An authoritative server is to treat a domain name as existing + during the execution of the algorithms in RFC 1034 when the + domain name conforms to the following definition. A domain name + is defined to exist if the domain name owns data or has a + subdomain that exists, or both. + + Note that at a zone boundary, the domain name owns data, including + the NS RR set. At the delegating server, the NS RR set is not + authoritative, but that is of no consequence here. The domain name + owns data, therefore, it exists. + + +2.3 When does a Wild Card Domain Name not own a wildcard (record) + + When a Wild Card Domain Name appears in a message's query section, + no special processing occurs. Asterisk Labels in such a context + only Label Matches other Asterisk Labels in the existing zone tree + when the 4.3.2 algorithm is being followed. + + When a Wild Card Domain Name appears in the resource data of a + record, no special processing occurs. An Asterisk Label in that + context literally means just an asterisk. + + +3. Impact of a Wild Card Domain On a Response + + The description of how wild cards impact response generation is in + RFC 1034, section 4.3.2. That passage contains the algorithm + followed by a server in constructing a response. Within that + algorithm, step 3, part 'c' defines the behavior of the wild card. + The algorithm is directly quoted in lines that begin with a '#' sign. + Commentary is interleaved. + + There is a documentation issue deserving some explanation. The + algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo + code, i.e., it's steps are not intended to be followed in strict + order. The "algorithm" is a suggestion. As such, in step 3, parts + a, b, and c, do not have to be implemented in that order. + + Another issue needing explanation is that RFC 1034 is a full + standard. There is another RFC, RFC 2672, which makes, or proposes + an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME + RR. RFC 2672 is a proposed standard. The dilemma in writing these + clarifications is knowing which document is the one being clarified. + Fortunately, the difference between RFC 1034 and RFC 2672 is not + significant with respect to wild card synthesis, so this document + will continue to state that it is clarifying RFC 1034. If RFC 2672 + progresses along the standards track, it will need to refer to + modifying RFC 1034's algorithm as amended here. + + +3.1 Step 2 + + Step 2 of the RFC 1034's section 4.3.2 reads: + +# 2. Search the available zones for the zone which is the nearest +# ancestor to QNAME. If such a zone is found, go to step 3, +# otherwise step 4. + + In this step, the most appropriate zone for the response is chosen. + There are two reasons to repeat this. One is that this means all + of step 3 is done within the context of a zone, which will constrain + the discussion. The other is the though behind synthesizing entire + zones and the use of Wild Card Domain Names to do so. + +3.2 Step 3 + + Step 3 is dominated by three parts, labelled a, b, and c. But the + beginning of the Step is important and needs explanation. + +# 3. Start matching down, label by label, in the zone. The +# matching process can terminate several ways: + + The word matching in this care refers to Label Matching. The concept + is based in the view of the zone as the tree of existing names. The + Query Name is considered to be an ordered sequence of labels - as + if the name were a path from the root to the owner of the desired + data. + + The process of Label Matching ends in one of three choices, the parts + a, b, and c. Once one of the parts is chosen, the other parts are + not considered. (E.g., do not execute part c and then change the + execution path to finish in part b.) The process of Label Matching + is also done independent of the Query Type. + + Parts a and b are not an issue for this clarification as they do not + relate to record synthesis. Part a generally covers a situation in + which all of the labels in the search (query) name have been matched + down the tree, e.g., the sought name exists as an exact Label Match. + Part b generally covers a situation in which any label in the sought + name Label Matches a tree label and the tree label has a NS RRSet. + +3.3 Part 'c' + + The context of part 'c' is that the process of Label Matching the + labels in the sought name has resulted in a situation in which there + is nothing corresponding in the tree. It is as if the lookup has + "fallen off the tree." + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if a +# the "*" label exists. + + + To help describe the process of looking "to see is a the [sic] + label exists" a term has been coined to describe the last label + matched. The term is "Closest Encloser." + +3.3.1 Closest Encloser and the Source of Synthesis + + The "Closest Encloser" is the node in the zone's tree of existing + domain names that is has the most matching labels with the sought + name. Each match is a "Label Match" and the order of the labels + is also the same. The Closest Encloser is an existing name in the + zone, it may be an empty non-terminal, it may even be a Wild Card + Domain Name itself. In no circumstances is the Closest Encloser + the used to synthesize records though. + + A "Source of Synthesis" is defined in the context of a lookup + process as the Wild Card Domain Name immediately descending from + the Closest Encloser provided the Wild Card Domain Name exists. + A Source of Synthesis does not guarantee having a RRSet to use + for synthesis, a Source of Synthesis may even be an empty + non-terminal. + + If a Source of Synthesis exists, it will be the Wild Card Domain Name + that is identified by an Asterisk Label below the Closest Encloser. + E.g., ". or "*.." + If the Source of Synthesis does not exist (not on the domain tree), + there will be no wildcard synthesis + + The important concept is that for any given lookup process, there + is at most one place at which wildcard synthetic records can be + obtained. If the Source of Synthesis does not exist, the lookup + terminates, the lookup does not look for other wildcard records. + + Other terms have been coined on the mailing list in the past. E.g., + it has been said that existing names block the application of + wildcard records. This is still an appropriate viewpoint, but + replacing this notion with the Closest Encloser and Source of + Synthesis the depiction of the wildcard process is clearer. + +3.3.2 Closest Encloser and Source of Synthesis Examples + + + To illustrate, using the example zone in section 2.2.1 of this document, + the following chart shows QNAMEs and the closest enclosers. + + QNAME Closest Encloser Source of Synthesis + host3.example. example. *.example. + _telnet._tcp.host1.example. _tcp.host1.example. no source + _telnet._tcp.host2.example. host2.example. no source + _telnet._tcp.host3.example. example. *.example. + _chat._udp.host3.example. example. *.example. + + + + The fact that a closest encloser will be the only superdomain that + can have a candidate wild card will have an impact when it comes to + designing pre-calculated authenticated denial of existence proofs. + + +3.3.3 Non-existent Source of Synthesis + + In RFC 1034: + +# If the "*" label does not exist, check whether the name +# we are looking for is the original QNAME in the query +# or a name we have followed due to a CNAME. If the name +# is original, set an authoritative name error in the +# response and exit. Otherwise just exit. + + + The above passage is clear, evidenced by the lack of discussion and + mis-implementation of it over the years. It is included for + completeness only. (No attempt is made to re-interpret it lest + a mistake in editing leads to confusion.) + +3.3.4 Type Matching + + RFC 1034 concludes part c with this: + +# If the "*" label does exist, match RRs at that node +# against QTYPE. If any match, copy them into the answer +# section, but set the owner of the RR to be QNAME, and +# not the node with the "*" label. Go to step 6. + + + This final paragraph covers the role of the QTYPE in the lookup process. + + Based on implementation feedback and similarities between step a and + step c a change to this passage a change has been made. + + The change is to add the following text: + + If the data at the source of synthesis is a CNAME, and + QTYPE doesn't match CNAME, copy the CNAME RR into the + answer section of the response changing the owner name + to the QNAME, change QNAME to the canonical name in the + CNAME RR, and go back to step 1. + + This is essentially the same text in step a covering the processing of + CNAME RRSets. + +4. Considerations with Special Types + + + Five types of RRSets owned by a Wild Card Domain Name have caused + confusion. Four explicit types causing confusion are SOA, NS, CNAME, + DNAME, and the fifth type - "none." + +4.1. SOA RR's at a Wild Card Domain Name + + + A Wild Card Domain Name owning an SOA RRSet means that the domain + is at the root of the zone (apex). The domain can not be a Source of + Synthesis because that is, but definition, a descendent node (of + the Closest Encloser) and a zone apex is at the top of the zone. + + Although a Wild Card Domain Name can not be a Source of Synthesis, + there is no reason to forbid the ownership of an SOA RRSet. This + means that zones with names like "*..", and even + "*..." + + Step 2 (section 3.1) does not provide a means to specify a means to + synthesize a zone. Therefore, according to the rules there, the + only way in which a zone that has a name which is a Wild Card + Domain Name is if the QNAME is in a domain below the zone's name. + + E.g., if *.example. has an SOA record, then only a query like + QNAME=*.example., QTYPE=A, QCLASS=IN would see it. As another + example, a QNAME of www.*.example. would also result in passing + through the zone. + +4.2. NS RR's at a Wild Card Domain Name + + + The semantics of a Wild Card Domain Name ownership of a NS RRSet + has been unclear. Looking through RFC 1034, the recommendation + is to have the NS RRSet act the same a any non-special type, e.g., + like an A RR. + + If the NS RRSet in question is at the top of the zone, i.e., the + name also owns an SOA RRSet, the QNAME equals the zone name. This + would trigger part 'a' of Step 3. + + In any other case, the Wild Card Domain Name owned NS RRSet would + be the only RRSet (prior to changes instituted by DNSSEC) at the + node by DNS rules. If the QNAME equals the Wild Card Domain Name + or is a subdomain of it, then the node would be considered in part + 'b' of Step 3. + + Note that there is no synthesis of records in the authority section + because part 'b' does not account for synthesis. The referral + returned would have the Wild Card Domain Name in the authority section, + unchanged. + + If the QNAME is not the same as the Wild Card Domain Name nor a + subdomain of it, then part 'c' of Step 3 has been triggered. Once + part 'c' is entered, there is no reverting to part 'b' - i.e., + once an NS RRSet is synthesized it does not mean that the server has + to consider the name delegated away. I.e., the server is not + synthesizing a record (the NS RRSet) that means the server does not + have the right to synthesize. + +4.3. CNAME RR's at a Wild Card Domain Name + + The issue of CNAME RR's owned by wild card domain names has prompted + a suggested change to the last paragraph of step 3c of the algorithm + in 4.3.2. The changed text appears in section 3.3.4 of this document. + +4.4. DNAME RR's at a Wild Card Domain Name + + The specification of the DNAME RR, which is at the proposed level of + standardization, is not as mature as the full standard in RFC 1034. + Because of this, or the reason for this is, there appears to be a + a number of issues with that definition and it's rewrite of the algorithm + in 4.3.2. For the time being, when it comes to wild card processing + issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME + at a wild card domain name is effectively the same as a CNAME at a + wild card domain name. + +4.5 Empty Non-terminal Wild Card Domain Name + + + If a Source of Synthesis is an empty non-terminal, then the response + will be one of no error in the return code and no RRSet in the answer + section. + +5. Security Considerations + + This document is refining the specifications to make it more likely + that security can be added to DNS. No functional additions are being + made, just refining what is considered proper to allow the DNS, + security of the DNS, and extending the DNS to be more predictable. + +6. References + + Normative References + + [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 + + [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, + Nov-01-1987 + + [RFC 1035] Domain Names - Implementation and Specification, P.V + Mockapetris, Nov-01-1987 + + [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S + Bradner, March 1997 + + Informative References + + [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. + Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 + + [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 + + [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 + +7. Others Contributing to This Document + + Others who have been editors of this document: Bob Halley and Robert Elz. + Others who have directly caused text to appear in the document: Paul + Vixie and Olaf Kolkman. Many others have indirect influences on the + content. + +8. Editor + + Name: Edward Lewis + Affiliation: NeuStar + Address: tbd + Phone: tbd + Email: tbd (please send comments to namedroppers) + + Comments on this document can be sent to the editors or the mailing + list for the DNSEXT WG, namedroppers@ops.ietf.org. + +9. Trailing Boilerplate + + Copyright (C) The Internet Society (2004). 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. + + 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. + + 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. 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + +Expiration + + This document expires on or about 11 April 2005. diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-10.txt similarity index 81% rename from doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt rename to doc/draft/draft-ietf-dnsop-ipv6-dns-issues-10.txt index b14f711d53..f0ddf003f7 100644 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-10.txt @@ -1,17 +1,16 @@ - DNS Operations WG A. Durand Internet-Draft SUN Microsystems, Inc. -Expires: February 7, 2005 J. Ihren +Expires: April 24, 2005 J. Ihren Autonomica P. Savola CSC/FUNET - August 9, 2004 + October 24, 2004 Operational Considerations and Issues with IPv6 DNS - draft-ietf-dnsop-ipv6-dns-issues-09.txt + draft-ietf-dnsop-ipv6-dns-issues-10.txt Status of this Memo @@ -37,21 +36,21 @@ Status of this Memo material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on February 7, 2005. + This Internet-Draft will expire on April 24, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2004). Abstract @@ -65,8 +64,8 @@ Abstract -Durand, et al. Expires February 7, 2005 [Page 1] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 +Durand, et al. Expires April 24, 2005 [Page 1] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 @@ -99,42 +98,42 @@ Table of Contents 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10 4.4.1 Description of Additional Data Scenarios . . . . . . . 10 - 4.4.2 Discussion of the Problems . . . . . . . . . . . . . . 11 - 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12 - 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 13 - 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 13 - 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14 - 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 15 - 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 16 - 6. Considerations about Forward DNS Updating . . . . . . . . . . 16 - 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 - 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 17 - 7. Considerations about Reverse DNS Updating . . . . . . . . . . 18 - 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 18 - 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19 - 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 19 - 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20 - 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 21 - 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22 - 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 22 - 8.2 Renumbering Procedures and Applications' Use of DNS . . . 22 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 22 + 4.4.2 Which Additional Data to Keep, If Any? . . . . . . . . 11 + 4.4.3 Discussion of the Problems . . . . . . . . . . . . . . 12 + 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 13 + 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 14 + 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 15 + 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 15 + 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 16 + 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 17 + 6. Considerations about Forward DNS Updating . . . . . . . . . . 17 + 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 17 + 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 18 + 7. Considerations about Reverse DNS Updating . . . . . . . . . . 19 + 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 19 + 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 20 + 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 20 + 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 21 + 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 22 + 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 23 + 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 23 + 8.2 Renumbering Procedures and Applications' Use of DNS . . . 23 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 -Durand, et al. Expires February 7, 2005 [Page 2] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 +Durand, et al. Expires April 24, 2005 [Page 2] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 - 11.2 Informative References . . . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 - A. Site-local Addressing Considerations for DNS . . . . . . . . . 28 - B. Issues about Additional Data or TTL . . . . . . . . . . . . . 28 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 24 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 + 11.2 Informative References . . . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 + A. Site-local Addressing Considerations for DNS . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . 30 @@ -181,8 +180,8 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 -Durand, et al. Expires February 7, 2005 [Page 3] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 +Durand, et al. Expires April 24, 2005 [Page 3] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 @@ -247,8 +246,8 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 -Durand, et al. Expires February 7, 2005 [Page 4] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 +Durand, et al. Expires April 24, 2005 [Page 4] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 @@ -288,8 +287,7 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 parts of DNS are only visible using IPv4 (or IPv6) transport, the recommendation is to always keep at least one authoritative server IPv4-enabled, and to ensure that recursive DNS servers support IPv4. - See DNS IPv6 transport guidelines - [I-D.ietf-dnsop-ipv6-transport-guidelines] for more information. + See DNS IPv6 transport guidelines [RFC3901] for more information. 1.4 Query Type '*' and A/AAAA Records @@ -314,8 +312,9 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 -Durand, et al. Expires February 7, 2005 [Page 5] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + +Durand, et al. Expires April 24, 2005 [Page 5] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 @@ -323,10 +322,9 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 The IPv6 addressing architecture [RFC3513] includes two kinds of - local-use addresses: link-local (fe80::/10) and site-local (fec0::/ - 10). The site-local addresses have been deprecated - [I-D.ietf-ipv6-deprecate-site-local], and are only discussed in - Appendix A. + local-use addresses: link-local (fe80::/10) and site-local + (fec0::/10). The site-local addresses have been deprecated + [RFC3879], and are only discussed in Appendix A. Link-local addresses should never be published in DNS (whether in @@ -340,10 +338,11 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 Temporary addresses defined in RFC3041 [RFC3041] (sometimes called "privacy addresses") use a random number as the interface identifier. - Publishing (useful) DNS records relating to such addresses would - defeat the purpose of the mechanism and is not recommended. However, - it would still be possible to return a non-identifiable name (e.g., - the IPv6 address in hexadecimal format), as described in [RFC3041]. + Having DNS AAAA records that are updated to always contain the + current value of a node's temporary address would defeat the purpose + of the mechanism and is not recommended. However, it would still be + possible to return a non-identifiable name (e.g., the IPv6 address in + hexadecimal format), as described in [RFC3041]. 2.3 6to4 Addresses @@ -382,8 +381,8 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 -Durand, et al. Expires February 7, 2005 [Page 6] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 +Durand, et al. Expires April 24, 2005 [Page 6] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 @@ -448,8 +447,8 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 -Durand, et al. Expires February 7, 2005 [Page 7] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 +Durand, et al. Expires April 24, 2005 [Page 7] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 @@ -464,21 +463,36 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 4.1 Use of Service Names instead of Node Names - When a node provides multiple services which should not be - fate-sharing, or might support different IP versions, one should keep - them logically separate in the DNS. Using SRV records [RFC2782] - would avoid these problems. Unfortunately, those are not - sufficiently widely used to be applicable in most cases. Hence an - operation technique is to use service names instead of node names - (or, "hostnames"). This operational technique is not specific to - IPv6, but required to understand the considerations described in - Section 4.2 and Section 4.3. + It makes sense to keep logically separate services by a node separate + in the DNS, due to a number of reasons, for example: + + + o It allows more flexibility and ease for migration of (only a part + of) services from one node to another, + + + o It allows configuring different properties (e.g., TTL) for each + service, and + + + o It allows deciding separately for each service whether to publish + the IPv6 addresses or not (in cases if some services are more + IPv6-ready than others). + + + Using SRV records [RFC2782] would avoid these problems. + Unfortunately, those are not sufficiently widely used to be + applicable in most cases. Hence an operation technique is to use + service names instead of node names (or, "hostnames"). This + operational technique is not specific to IPv6, but required to + understand the considerations described in Section 4.2 and Section + 4.3. For example, assume a node named "pobox.example.com" provides both SMTP and IMAP service. Instead of configuring the MX records to point at "pobox.example.com", and configuring the mail clients to - look up the mail via IMAP from "pobox.example.com", one should use + look up the mail via IMAP from "pobox.example.com", one could use e.g., "smtp.example.com" for SMTP (for both message submission and mail relaying between SMTP servers) and "imap.example.com" for IMAP. Note that in the specific case of SMTP relaying, the server itself @@ -489,15 +503,6 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 should use the hostname rather than a service name.) - This is a good practice with IPv4 as well, because it provides more - flexibility and enables easier migration of services from one host to - another. A specific reason why this is relevant for IPv6 is that the - different services may have a different level of IPv6 support -- that - is, one node providing multiple services might want to enable just - one service to be IPv6-visible while keeping some others as - IPv4-only, improving flexibility. - - 4.2 Separate vs the Same Service Names for IPv4 and IPv6 @@ -505,19 +510,19 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 service is named "service.example.com" for IPv4, the IPv6-enabled service could be either added to "service.example.com", or added separately under a different name, e.g., in a sub-domain, like, + + + + +Durand, et al. Expires April 24, 2005 [Page 8] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + "service.ipv6.example.com". These two methods have different characteristics. Using a different - - - - -Durand, et al. Expires February 7, 2005 [Page 8] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - name allows for easier service piloting, minimizing the disturbance to the "regular" users of IPv4 service; however, the service would not be used transparently, without the user/application explicitly @@ -573,18 +578,18 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 The issues are not always so black-and-white. Usually it's important + + + + +Durand, et al. Expires April 24, 2005 [Page 9] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + if the service offered using both protocols is of roughly equal quality, using the appropriate metrics for the service (e.g., latency, throughput, low packet loss, general reliability, etc.) -- - - - - -Durand, et al. Expires February 7, 2005 [Page 9] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - this is typically very important especially for interactive or real-time services. In many cases, the quality of IPv6 connectivity may not yet be equal to that of IPv4, at least globally -- this has @@ -595,43 +600,67 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments + DNS responses do not always fit in a single UDP packet. We'll + examine the cases which happen when this is due to too much data in + the Additional Section. + + 4.4.1 Description of Additional Data Scenarios - Consider the case where the query name is so long, the number of the - additional records is so high, or for other reasons that the entire - response would not fit in a single UDP packet. In some cases, the - responder truncates the response with the TC bit being set (leading - to a retry with TCP), in order for the querier to get the entire - response later. - - There are two kinds of additional data: - 1. glue, i.e., "critical" additional data; this must be included in - all scenarios, with all the RRsets as possible, and + 1. "critical" additional data; this must be included in all + scenarios, with all the RRsets, and 2. "courtesy" additional data; this could be sent in full, with only a few RRsets, or with no RRsets, and can be fetched separately as - well, but at the cost of additional queries. This data must - never cause setting of the TC bit. + well, but at the cost of additional queries. The responding server can algorithmically determine which type the additional data is by checking whether it's at or below a zone cut. - Meanwhile, resource record sets (RRsets) are never "broken up", so if - a name has 4 A records and 5 AAAA records, you can either return all - 9, all 4 A records, all 5 AAAA records or nothing. In particular, - notice that for the "critical" additional data getting all the RRsets - can be critical. + Only those additional data records (even if sometimes carelessly + termed "glue") are considered "critical" or real "glue" if and only + if they meet the abovementioned condition, as specified in Section + 4.2.1 of [RFC1034]. + + + Remember that resource record sets (RRsets) are never "broken up", so + if a name has 4 A records and 5 AAAA records, you can either return + all 9, all 4 A records, all 5 AAAA records or nothing. In + particular, notice that for the "critical" additional data getting + all the RRsets can be critical. + + + In particular, [RFC2181] specifies (in Section 9) that: + + + a. if all the "critical" RRsets do not fit, the sender should set + the TC bit, and the recipient should discard the whole response + and retry using mechanism allowing larger responses such as TCP. + + + b. "courtesy" additional data should not cause the setting of TC + bit, but instead all the non-fitting additional data RRsets + + + + +Durand, et al. Expires April 24, 2005 [Page 10] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + + should be removed. An example of the "courtesy" additional data is A/AAAA records in - conjunction of MX records as shown in Section 4.5; an example of the + conjunction of MX records is shown in Section 4.5; an example of the "critical" additional data is shown below (where getting both the A and AAAA RRsets is critical): @@ -641,32 +670,97 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 ns.child.example.com. IN AAAA 2001:db8::1 - When there is too much courtesy additional data, some or all of it - need to be removed [RFC2181]; if some is left in the response, the - issue is which data should be retained. When there is too much + When there is too much courtesy additional data, at least the + non-fitting RRsets should be removed [RFC2181]; however, as the + additional data is not critical, even all of it could be safely + removed. + When there is too much critical additional data, TC bit will have to + be set, and the recipient should ignore the response and retry using + TCP; if some data were to be left in the UDP response, the issue is + which data could be retained. -Durand, et al. Expires February 7, 2005 [Page 10] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + Failing to discard the response with TC bit set leads to a protocol + problem. Omitting only some of the RRsets if all would not fit leads + to a performance problem. These are discussed in Section 4.4.3. - - critical additional data, TC bit will have to be set, and some or all - of it need to be removed; if some is left in the response, the issue - is which data should be retained. +4.4.2 Which Additional Data to Keep, If Any? - If the implementation decides to keep as much data as possible, it - might be tempting to use the transport of the DNS query as a hint in - either of these cases: return the AAAA records if the query was done - over IPv6, or return the A records if the query was done over IPv4. + If the implementation decides to keep as much data (whether + "critical" or "courtesy") as possible in the UDP responses, it might + be tempting to use the transport of the DNS query as a hint in either + of these cases: return the AAAA records if the query was done over + IPv6, or return the A records if the query was done over IPv4. However, this breaks the model of independence of DNS transport and resource records, as noted in Section 1.2. - It is worth remembering that often the host using the records is + With courtesy additional data, as long as enough RRsets will be + removed so that TC will not be set, it is allowed to send as many + complete RRsets as the implementations prefers. However, the + implementations are also free to omit all such RRsets, even if + complete. Removing all the RRsets if some would not fit obviates a + performance problem, which would require the users to issue second + queries to obtain consistent information. + + + With critical additional data, the alternatives are either returning + nothing (and absolutely requiring a retry with TCP) or returning + something (working also in the case if the recipient does not discard + the response and retry using TCP) in addition to setting the TC bit. + If the process for selecting "something" from the critical data would + + + + +Durand, et al. Expires April 24, 2005 [Page 11] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + + otherwise be practically "flipping the coin" between A and AAAA + records, it could be argued that if one looked at the transport of + the query, it would have a larger possibility of being right than + just 50/50. In other words, if the returned critical additional data + would have to be selected somehow, using something more sophisticated + than a random process would seem justifiable. + + + That is, leaving in some intelligently selected critical additional + data is a tradeoff between creating an optimization for those + resolvers which ignore the "should discard" recommendation, and a + causing a protocol problem by propagating inconsistent information + about "critical" records in the caches. + + + Similarly, leaving in the complete courtesy additional data RRsets + instead of removing all the RRsets is a performance tradeoff as + described in the next section. + + +4.4.3 Discussion of the Problems + + + As noted above, the temptation for omitting only some of the + additional data based on the transport of the query could be + problematic. In particular, there appears to be little justification + for doing so in the case of "courtesy" data. + + + For courtesy additional data, this causes a performance problem as + this requires that the clients issue re-query for the potentially + omitted RRsets. For critical additional data, this causes a + potential protocol problem if the response is not discarded and the + query not re-tried with TCP, as the nameservers might be reachable + only through the omitted RRsets. + + + If an implementation would look at the transport used for the query, + it is worth remembering that often the host using the records is different from the node requesting them from the authoritative DNS server (or even a caching resolver). So, whichever version the requestor (e.g., a recursive server in the middle) uses makes no @@ -681,49 +775,29 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 to the client to query again. -4.4.2 Discussion of the Problems - - - As noted above, the temptation for omitting only some of the - additional data based on the transport of the query could be - problematic. In particular, there appears to be little justification - for doing so in the case of "courtesy" data. - - - However, with critical additional data, the alternatives are either - returning nothing (and requiring a retry with TCP) or returning - something (possibly obviating the need for a retry with TCP). If the - process for selecting "something" from the critical data would - otherwise be practically "flipping the coin" between A and AAAA - records, it could be argued that if one looked at the transport of - the query, it would have a larger possibility of being right than - just 50/50. In other words, if the returned critical additional data - would have to be selected somehow, using something more sophisticated - than a random process would seem justifiable. - - The problem of too much additional data seems to be an operational one: the zone administrator entering too many records which will be - returned either truncated or missing some RRsets to the users. A - protocol fix for this is using EDNS0 [RFC2671] to signal the capacity - for larger UDP packet sizes, pushing up the relevant threshold. -Durand, et al. Expires February 7, 2005 [Page 11] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 +Durand, et al. Expires April 24, 2005 [Page 12] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - Further, DNS server implementations should rather omit courtesy - additional data completely rather than including only some RRsets - [RFC2181]. An operational fix for this is having the DNS server - implementations return a warning when the administrators create zones - which would result in too much additional data being returned. - Further, DNS server implementations should warn of or disallow such - zone configurations which are recursive or otherwise difficult to - manage by the protocol. + returned either truncated (or missing some RRsets, depending on + implementations) to the users. A protocol fix for this is using + EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes, + pushing up the relevant threshold. Further, DNS server + implementations should rather omit courtesy additional data + completely rather than including only some RRsets [RFC2181]. An + operational fix for this is having the DNS server implementations + return a warning when the administrators create zones which would + result in too much additional data being returned. Further, DNS + server implementations should warn of or disallow such zone + configurations which are recursive or otherwise difficult to manage + by the protocol. Additionally, to avoid the case where an application would not get an @@ -738,10 +812,11 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 In the previous section, we discussed a danger with queries, potentially leading to omitting RRsets from the additional section; - this could happen to both critical and "courtesy" additional data. - This section discusses another problem with the latter, leading to - omitting RRsets in cached data, highlighted in the IPv4/IPv6 - environment. + this could happen to both critical and "courtesy" additional data + (however, both of these are recommended against in [RFC2181]). This + section discusses another problem with courtesy additional data, + leading to omitting RRsets in cached data, highlighted in the + IPv4/IPv6 environment. The behaviour of DNS caching when different TTL values are used for @@ -767,27 +842,26 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 interested in. + + + +Durand, et al. Expires April 24, 2005 [Page 13] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + 2. We get back all the RRsets: this is an optimization as there is no need to perform more queries, causing lower latency. However, it is impossible to guarantee that in fact we would always get back all the records (the only way to ensure that is to send a AAAA query for the name after getting the cached reply with A - - - - -Durand, et al. Expires February 7, 2005 [Page 12] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - records or vice versa). 3. We only get back A or AAAA RRsets even if both existed: this is - indistinguishable from the previous case, and may have problems - at least in certain environments as described in the previous - section. + indistinguishable from the previous case, and may have + performance problems at least in certain environments as + described in the previous section. As the third case was considered in the previous section, we assume @@ -801,8 +875,11 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 caching resolvers to discard the A record when the shorter TTL (in this case, for the AAAA record) expires; this would avoid the situation where there would be a window of 200 seconds when - incomplete information is returned from the cache. The behaviour in - this scenario is unspecified. + incomplete information is returned from the cache. Further argument + for discarding is that in the normal operation, the TTL values are so + high that very likely the incurred additional queries would not be + noticeable, compared to the obtained performance optimization. The + behaviour in this scenario is unspecified. To simplify the situation, it might help to use the same TTL for all @@ -823,14 +900,20 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 4.6 IPv6 Transport Guidelines for DNS Servers - As described in Section 1.3 and - [I-D.ietf-dnsop-ipv6-transport-guidelines], there should continue to + As described in Section 1.3 and [RFC3901], there should continue to be at least one authoritative IPv4 DNS server for every zone, even if the zone has only IPv6 records. (Note that obviously, having more servers with robust connectivity would be preferable, but this is the minimum recommendation; also see [RFC2182].) + + +Durand, et al. Expires April 24, 2005 [Page 14] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + 5. Recommendations for DNS Resolver IPv6 Support @@ -838,15 +921,6 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 to ensure that the process is as smooth as possible. - - - - -Durand, et al. Expires February 7, 2005 [Page 13] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - 5.1 DNS Lookups May Query IPv6 Records Prematurely @@ -897,21 +971,21 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 circumstances, prefer AAAA records over A records even when the node does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. In some cases, the implementation may attempt to connect or send a + + + + +Durand, et al. Expires April 24, 2005 [Page 15] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], incurring very long protocol timeouts, instead of quickly failing back to IPv4. Now, we can consider the issues specific to each of the three - - - - -Durand, et al. Expires February 7, 2005 [Page 14] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - possibilities: @@ -962,21 +1036,21 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 The IETF is considering the development of alternative mechanisms for obtaining the list of DNS recursive name servers when DHCPv6 is unavailable or inappropriate. No decision about taking on this + + + + +Durand, et al. Expires April 24, 2005 [Page 16] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + development work has been reached as of this writing (Aug 2004) [I-D.ietf-dnsop-ipv6-dns-configuration]. In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms under consideration for development include the use of well-known - - - - -Durand, et al. Expires February 7, 2005 [Page 15] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - addresses [I-D.ohta-preconfigured-dns] and the use of Router Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns-discovery]. @@ -993,8 +1067,7 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 5.3 IPv6 Transport Guidelines for Resolvers - As described in Section 1.3 and - [I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers + As described in Section 1.3 and [RFC3901], the recursive resolvers should be IPv4-only or dual-stack to be able to reach any IPv4-only DNS server. Note that this requirement is also fulfilled by an IPv6-only stub resolver pointing to a dual-stack recursive DNS @@ -1030,19 +1103,18 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 The DNS mappings can also be maintained by hand, in a semi-automatic fashion or by running non-standardized protocols. These are not + + + + +Durand, et al. Expires April 24, 2005 [Page 17] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + considered at more length in this memo. - - - - - -Durand, et al. Expires February 7, 2005 [Page 16] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - 6.2 Dynamic DNS @@ -1097,17 +1169,16 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 on the node, e.g., at install time. + + + +Durand, et al. Expires April 24, 2005 [Page 18] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + Care should be observed when updating the addresses not to use longer TTLs for addresses than are preferred lifetimes for the addresses, so - - - - -Durand, et al. Expires February 7, 2005 [Page 17] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - that if the node is renumbered in a managed fashion, the amount of stale DNS information is kept to the minimum. That is, if the preferred lifetime of an address expires, the TTL of the record needs @@ -1146,11 +1217,11 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 the name by the IP address from the reverse tree, and ensuring that a record under the name in the forward tree points to the IP address) and correspond to a configured name or domain. As a security check, - it is typically accompanied by other mechanisms, such as a user/ - password login; the main purpose of the reverse+forward DNS check is - to weed out the majority of unauthorized users, and if someone - managed to bypass the checks, he would still need to authenticate - "properly". + it is typically accompanied by other mechanisms, such as a + user/password login; the main purpose of the reverse+forward DNS + check is to weed out the majority of unauthorized users, and if + someone managed to bypass the checks, he would still need to + authenticate "properly". It may also be desirable to store IPsec keying material corresponding @@ -1161,17 +1232,17 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 It is not clear whether it makes sense to require or recommend that reverse DNS records be updated. In many cases, it would just make more sense to use proper mechanisms for security (or topological + + + + +Durand, et al. Expires April 24, 2005 [Page 19] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + information lookup) in the first place. At minimum, the applications which use it as a generic authorization (in the sense that a record - - - - -Durand, et al. Expires February 7, 2005 [Page 18] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - exists at all) should be modified as soon as possible to avoid such lookups completely. @@ -1209,14 +1280,15 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 The address space administrator decides whether the hosts are trusted - to update their reverse DNS records or not. If they are, a simple + to update their reverse DNS records or not. If they are trusted and + deployed at the same site (e.g., not across the Internet), a simple address-based authorization is typically sufficient (i.e., check that the DNS update is done from the same IP address as the record being updated); stronger security can also be used [RFC3007]. If they - aren't allowed to update the reverses, no update can occur. (Such - address-based update authorization operationally requires that + aren't allowed to update the reverses, no update can occur. However, + such address-based update authorization operationally requires that ingress filtering [RFC3704] has been set up at the border of the site - where the updates occur, and as close to the updater as possible.) + where the updates occur, and as close to the updater as possible. Address-based authorization is simpler with reverse DNS (as there is @@ -1225,18 +1297,20 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 updates are simpler to manage because the host can be assumed to have an association with the domain. Note that the user may roam to different networks, and does not necessarily have any association + + + + +Durand, et al. Expires April 24, 2005 [Page 20] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + with the owner of that address space -- so, assuming stronger form of authorization for reverse DNS updates than an address association is generally unfeasible. - - -Durand, et al. Expires February 7, 2005 [Page 19] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - Moreover, the reverse zones must be cleaned up by an unspecified janitorial process: the node does not typically know a priori that it will be disconnected, and cannot send a DNS update using the correct @@ -1287,20 +1361,20 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 a reverse DNS record instead of inserting one (if an address assignment policy that reassigns disused addresses is adopted) and updating a record seems like a slightly more difficult thing to + + + + +Durand, et al. Expires April 24, 2005 [Page 21] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + secure. However, it is yet uncertain how DHCPv6 is going to be used for address assignment. Note that when using DHCP, either the host or the DHCP server could - - - - -Durand, et al. Expires February 7, 2005 [Page 20] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - perform the DNS updates; see the implications in Section 6.2. @@ -1353,19 +1427,21 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 not, setting up security relationships would be simpler). As there is an explicit (security) relationship between the parties in the third case, setting up the security relationships to allow reverse + + + + +Durand, et al. Expires April 24, 2005 [Page 22] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + DDNS updates should be rather straightforward as well (but IP address-based authentication might not be acceptable). In the first case, however, setting up and managing such relationships might be a lot more difficult. - - -Durand, et al. Expires February 7, 2005 [Page 21] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - 8. Miscellaneous DNS Considerations @@ -1417,6 +1493,15 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 additional data and the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided useful feedback during the WG last call. Thomas + + + + +Durand, et al. Expires April 24, 2005 [Page 23] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + Narten provided extensive feedback during the IESG evaluation. @@ -1424,15 +1509,6 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 This document reviews the operational procedures for IPv6 DNS - - - - -Durand, et al. Expires February 7, 2005 [Page 22] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - operations and does not have security considerations in itself. @@ -1461,14 +1537,8 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 [I-D.ietf-dnsop-ipv6-dns-configuration] Jeong, J., "IPv6 Host Configuration of DNS Server Information Approaches", - draft-ietf-dnsop-ipv6-dns-configuration-02 (work in - progress), July 2004. - - - [I-D.ietf-dnsop-ipv6-transport-guidelines] - Durand, A. and J. Ihren, "DNS IPv6 transport operational - guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02 - (work in progress), March 2004. + draft-ietf-dnsop-ipv6-dns-configuration-04 (work in + progress), September 2004. [I-D.ietf-dnsop-misbehavior-against-aaaa] @@ -1478,12 +1548,6 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 progress), April 2004. - [I-D.ietf-ipv6-deprecate-site-local] - Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work - in progress), March 2004. - - [I-D.ietf-v6ops-application-transition] Shin, M., "Application Aspects of IPv6 Transition", draft-ietf-v6ops-application-transition-03 (work in @@ -1491,21 +1555,24 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 [I-D.ietf-v6ops-renumbering-procedure] - - - - -Durand, et al. Expires February 7, 2005 [Page 23] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", draft-ietf-v6ops-renumbering-procedure-01 (work in progress), July 2004. + + + +Durand, et al. Expires April 24, 2005 [Page 24] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. @@ -1561,18 +1628,17 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 August 2002. - - - -Durand, et al. Expires February 7, 2005 [Page 24] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. + + +Durand, et al. Expires April 24, 2005 [Page 25] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. @@ -1587,6 +1653,14 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 (DHCP) Service for IPv6", RFC 3736, April 2004. + [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. + + + [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational + Guidelines", BCP 91, RFC 3901, September 2004. + + 11.2 Informative References @@ -1603,15 +1677,15 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 [I-D.huston-6to4-reverse-dns] - Huston, G., "6to4 Reverse DNS", - draft-huston-6to4-reverse-dns-02 (work in progress), April - 2004. + Huston, G., "6to4 Reverse DNS Delegation", + draft-huston-6to4-reverse-dns-03 (work in progress), + October 2004. [I-D.ietf-dhc-ddns-resolution] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP - Clients", draft-ietf-dhc-ddns-resolution-07 (work in - progress), July 2004. + Clients", draft-ietf-dhc-ddns-resolution-08 (work in + progress), October 2004. [I-D.ietf-dhc-fqdn-option] @@ -1624,19 +1698,19 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for encoding DHCP information (DHCID RR)", draft-ietf-dnsext-dhcid-rr-08 (work in progress), July + + + + +Durand, et al. Expires April 24, 2005 [Page 26] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + 2004. [I-D.ietf-dnsop-bad-dns-res] - - - - -Durand, et al. Expires February 7, 2005 [Page 25] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - Larson, M. and P. Barber, "Observed DNS Resolution Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in progress), July 2004. @@ -1662,8 +1736,8 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 [I-D.ietf-ipv6-unique-local-addr] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in - progress), June 2004. + Addresses", draft-ietf-ipv6-unique-local-addr-06 (work in + progress), September 2004. [I-D.ietf-send-cga] @@ -1679,8 +1753,8 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 [I-D.ietf-v6ops-mech-v2] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms - for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-04 - (work in progress), July 2004. + for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06 + (work in progress), September 2004. [I-D.ietf-v6ops-onlinkassumption] @@ -1691,18 +1765,20 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 [I-D.ietf-v6ops-v6onbydefault] + + + + +Durand, et al. Expires April 24, 2005 [Page 27] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 + + + Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 (work in progress), July 2004. - - -Durand, et al. Expires February 7, 2005 [Page 26] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - [I-D.jeong-dnsop-ipv6-dns-discovery] Jeong, J., "IPv6 DNS Discovery based on Router Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02 @@ -1761,12 +1837,8 @@ Authors' Addresses - - - - -Durand, et al. Expires February 7, 2005 [Page 27] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 +Durand, et al. Expires April 24, 2005 [Page 28] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 @@ -1820,78 +1892,6 @@ Appendix A. Site-local Addressing Considerations for DNS case. -Appendix B. Issues about Additional Data or TTL - - - [[ note to the RFC-editor: remove this section upon publication. ]] - - - This appendix tries to describe the apparent rought consensus about - additional data and TTL issues (sections 4.4 and 4.5), and present - questions when there appears to be no consensus. The point of - - - - -Durand, et al. Expires February 7, 2005 [Page 28] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - recording them here is to focus the discussion and get feedback. - - - Resolved: - - - a. If some critical additional data RRsets wouldn't fit, you set the - TC bit even if some RRsets did fit. - - - b. If some courtesy additional data RRsets wouldn't fit, you never - set the TC bit, but rather remove (at least some of) the courtesy - RRsets. - - - c. DNS servers should implement sanity checks on the resulting glue, - e.g., to disable circular dependencies. Then the responding - servers can use at-or-below-a-zone-cut criterion to determine - whether the additional data is critical or not. - - - Open issues (at least): - - - 1. if some critical additional data RRsets would fit, but some - wouldn't, and TC has to be set (see above), should one rather - remove the additional data that did fit, keep it, or leave - unspecified? - - - 2. if some courtesy additional data RRsets would fit, but some - wouldn't, and some will have to be removed from the response (no - TC is set, see above), what to do -- remove all courtesy RRsets, - keep all that fit, or leave unspecified? - - - 3. is it acceptable to use the transport used in the DNS query as a - hint which records to keep if not removing all the RRsets, if: a) - having to decide which critical additional data to keep, or b) - having to decide which courtesy additional data to keep? - - - 4. (this issue was discussed in section 4.5) if one RRset has TTL of - 100 seconds, and another the TTL of 300 seconds, what should the - caching server do after 100 seconds? Keep returning just one - RRset when returning additional data, or discard the other RRset - from the cache? - - - 5. how do we move forward from here? If we manage to get to some - form of consensus, how do we record it: a) just in - draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational - category only!), b) a separate BCP or similar by DNSEXT WG(?), - clarifying and giving recommendations, c) something else, what? @@ -1900,8 +1900,10 @@ Internet-Draft Considerations and Issues with IPv6 DNS August 2004 -Durand, et al. Expires February 7, 2005 [Page 29] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 + + +Durand, et al. Expires April 24, 2005 [Page 29] +Internet-Draft Considerations and Issues with IPv6 DNS October 2004 @@ -1966,4 +1968,4 @@ Acknowledgment -Durand, et al. Expires February 7, 2005 [Page 30] \ No newline at end of file +Durand, et al. Expires April 24, 2005 [Page 30] \ No newline at end of file