From: Evan Hunt Date: Fri, 14 Feb 2014 16:53:06 +0000 (-0800) Subject: [master] updated published drafts X-Git-Tag: v9.10.0b1~118 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f2ea8c2f965be7ff4c59f805712c12d469226b7b;p=thirdparty%2Fbind9.git [master] updated published drafts --- diff --git a/doc/draft/draft-faltstrom-uri-06.txt b/doc/draft/draft-faltstrom-uri-08.txt similarity index 72% rename from doc/draft/draft-faltstrom-uri-06.txt rename to doc/draft/draft-faltstrom-uri-08.txt index cf4fd832e1f..388cce39fb7 100644 --- a/doc/draft/draft-faltstrom-uri-06.txt +++ b/doc/draft/draft-faltstrom-uri-08.txt @@ -1,729 +1,646 @@ - - - -Network Working Group P. Faltstrom -Internet-Draft Cisco -Updates: 3404, 3959 O. Kolkman -(if approved) NLNet -Intended status: Standards Track October 11, 2010 -Expires: April 14, 2011 - - - The Uniform Resource Identifier (URI) DNS Resource Record - draft-faltstrom-uri-06.txt - -Abstract - - This document defines a new DNS resource record, called the Uniform - Resource Identifier (URI) RR, for publishing mappings from hostnames - to URIs. - -Status of this Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - 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." - - This Internet-Draft will expire on April 14, 2011. - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 1] - -Internet-Draft URI Resource Record October 2010 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 - 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 4 - 4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 4 - 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4 - 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 - 5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 6 - 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 6.1. Homepage at one domain, but two domains in use . . . . . . 7 - 7. Relation to S-NAPTR . . . . . . . . . . . . . . . . . . . . . 7 - 8. Relation to U-NAPTR . . . . . . . . . . . . . . . . . . . . . 7 - 9. Relation to SRV . . . . . . . . . . . . . . . . . . . . . . . 8 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 10.1. Registration of the URI Resource Record Type . . . . . . . 8 - 10.2. Registration of services . . . . . . . . . . . . . . . . . 8 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 - Appendix A. RRTYPE Allocation Request . . . . . . . . . . . . . . 9 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 13.2. Non-normative references . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 - - - - - - - - - - - - - - - - - - - - - - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 2] - -Internet-Draft URI Resource Record October 2010 - - -1. Introduction - - This document explains the use of the Domain Name System (DNS) for - the storage of URIs, and how to resolve hostnames to such URIs that - can be used by various applications. For resolution the application - need to know both the hostname and the protocol that the URI is to be - used for. The protocol is registered by IANA. - - Currently, looking up URIs given a hostname uses the DDDS [RFC3401] - application framework with the DNS as a database as specified in RFC - 3404 [RFC3404]. This has a number of implications such as the - inability to select what NAPTR records that match the query are - interesting. The RRSet returned will always consist of all URIs - "connected" with the domain in question. - - The URI resource record specified in this document enables the - querying party to select which ones of the NAPTR records one is - interested in. This because data in the service field of the NAPTR - record is included in the owner part of the URI resource record type. - - Querying for URI resource records is not replacing querying for NAPTR - resource records (or use of S-NAPTR [RFC3958]). Instead, the URI - resource record type provides a complementary mechanism to use when - one already knows what service field is interesting. With it, one - can directly query for the specific subset of the otherwise possibly - large RRSet given back when querying for NAPTR resource records. - - This document updates RFC 3958 and RFC 3404 by adding the flag "D" to - the list of defined terminal flags in section 2.2.3 of RFC 3958 and - 4.3 of RFC 3404. - - 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 BCP 14, RFC 2119 - [RFC2119]. - - -2. Applicability Statement - - In general, it is expected that URI records will be used by clients - for applications where the relevant protocol to be used is known, - but, for example, an extra abstraction is needed in order to separate - a domain name from a point of service (as addressed by the URI). One - example of such a situation is when an organisation has many domain - names, but only one official web page. - - Applications MUST know the specific service fields to prepend the - hostname with. Using repetitive queries for URI records MUST NOT be - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 3] - -Internet-Draft URI Resource Record October 2010 - - - a replacement for querying for NAPTR records according to the NAPTR - (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to - discover the various services and URIs for looking up access points - for a given service. Those are two very different kinds of needs. - - -3. DNS considerations - - Using prefix labels, such as underscored service tags, prevents the - use of wildcards, as constructs as _s2._s1.*.example.net. are not - possible in the DNS, see RFC 4592 [RFC4592]. Besides, underscored - service tags used for the URI RR (based on the NAPTR service - descriptions) may have slightly different semantics than service tags - used for underscored prefix labels that are used in combination with - other (yet unspecified) RR types. This may cause subtle management - problems when delegation structure that has developed within the - context of URI RRs is also to be used for other RR types. Since the - service labels might be overloaded, applications should carefully - check that the application level protocol is indeed the protocol they - expect. - - Subtle management issues may also arise when the delegations from - service to sub service label involves several parties and different - stake holders. - - -4. The format of the URI RR - - This is the presentation format of the URI RR: - - - Ownername TTL Class URI Priority Weight Target - - - The URI RR does not cause any kind of Additional Section processing. - -4.1. Ownername, class and type - - The URI ownername is subject to special conventions. - - Just like the SRV RR [RFC2782] the URI RR has service information - encoded in its ownername. In order to encode the service for a - specific owner name one uses service parameters. Valid service - parameters used are those used for SRV resource records, or - registered by IANA for Enumservice Registrations. The Enumservice - Registration parameters are reversed (subtype(s) before type), - prepended with an underscore (_) and prepended to the owner name in - separate labels. The underscore is prepended to the service - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 4] - -Internet-Draft URI Resource Record October 2010 - - - parameters to avoid collisions with DNS labels that occur in nature, - and the order is reversed to make it possible to do delegations, if - needed, to different zones (and therefore providers of DNS). - - It should be noted that the usage of a prefix must be described in - detail in for example the Enumservice Registration documentation, or - in a specific document that clarifies potential overload of - parameters in the same URI. Specifically, registered URI schemes are - not automatically acceptable as a service. With the HTTP scheme, one - can for example have multiple methods (GET, PUT, etc), and this with - the same URI. - - For example, suppose we are looking for the URI for a service with - Service Parameter "A:B:C" for host example.com.. Then we would query - for (QNAME,QTYPE)=("_C._B._A.example.com","URI") - - The type number for the URI record is TBD1 (to be assigned by IANA). - - The URI resource record is class independent. - - The URI RR has no special TTL requirements. - -4.2. Priority - - The priority of the target URI in this RR. Its range is 0-65535. A - client MUST attempt to contact the URI with the lowest-numbered - priority it can reach; URIs with the same priority SHOULD be tried in - the order defined by the weight field. - -4.3. Weight - - A server selection mechanism. The weight field specifies a relative - weight for entries with the same priority. Larger weights SHOULD be - given a proportionately higher probability of being selected. The - range of this number is 0-65535. - -4.4. Target - - The URI of the target, enclosed in double-quote characters ('"'). - Resolution of the URI is according to the definitions for the Scheme - of the URI. - - The URI is encoded as one or more RFC1035 section - 3.3 [RFC1035]. - - - - - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 5] - -Internet-Draft URI Resource Record October 2010 - - -4.5. URI RDATA Wire Format - - The RDATA for a URI RR consists of a 2 octet Priority field, a two - octet Weight field, and a variable length target field. - - Priority and Weight are unsigned integers in network byte order. - - The Target field contains the URI (without the enclosing double- - quote characters used in the presentation format), encoded as a - sequence of one or more (as specified in section - 3.3 of RFC 1035 [RFC1035]), where all but the last - are filled up to the maximum length of 255 octets. - - The Target field can also contain an IRI, but with the additional - requirements that it is in UTF-8 [RFC3629] and possible to convert to - a URI according to section 3.1 of RFC 3987 [RFC3987] and back again - to an IRI according to section 3.2. Other character sets than UTF-8 - are not allowed. The domain name part of the IRI can be either an - U-LABEL or A-LABEL as defined in RFC 5890 [RFC5890]. - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Priority | Weight | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Target / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -5. Definition of the flag 'D' for NAPTR records - - This document specifies the flag "D" for use as a flag in NAPTR - records. The flag indicate a terminal NAPTR record because it - denotes the end of the DDDS/NAPTR processing rules. In the case of a - "D" flag, the Replacement field in the NAPTR record, prepended with - the service flags, is used as the Owner of a DNS query for URI - records, and normal URI processing as defined in this document is - applied. - - The replacement field MUST NOT include any of the service parameters. - Those are to be prepended (together with underscore) as described in - other places in this document. - - The Regexp field in the NAPTR record MUST be empty when the 'D' flag - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 6] - -Internet-Draft URI Resource Record October 2010 - - - is in use. - - -6. Examples - -6.1. Homepage at one domain, but two domains in use - - An organisation has the domain names example.com and example.net, but - the official URI http://www.example.com/. Given the service type - "web" and subtype "http" (from the IANA registry), the following URI - Resource Records could be made available in the respective zones - (example.com and example.net): - - - $ORIGIN example.com. - _http._web IN URI 10 1 "http://www.example.com/" - - $ORIGIN example.net. - _http._web IN URI 10 1 "http://www.example.com/" - - - -7. Relation to S-NAPTR - - The URI resource record type is not a replacement for the S-NAPTR. - It is instead an extension and the seond step of the S-NAPTR - resolution can resolve a URI resource record instead of using SRV - records and yet another algorithm for how to use SRV records for the - specific protocol. - - - $ORIGIN example.com. - ;; order pref flags - IN NAPTR 100 10 "s" "EM:ProtA" ( ; service - "" ; regexp - _ProtA._tcp.example.com. ; replacement - _ProtA._tcp IN URI "schemeA:service.example.com/example" - - - -8. Relation to U-NAPTR - - The URI Resource Record Type, together with S-NAPTR, can be viewed as - a replacement for the U-NAPTR. The URI Resource Record Type is - though only interesting when one know a base domain name, a protocol - and service so that one can compose the record to look up. NAPTR - records of any kind are used to look up what services exists for a - certain domain, which is one step before the URI resource record is - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 7] - -Internet-Draft URI Resource Record October 2010 - - - used. - - -9. Relation to SRV - - The URI Resource Record Type can be viewed as a replacement for the - SRV record. This because it like the SRV record can only be looked - up if one know the base domain, the protocol and the service. It has - a similar functionality, but instead of returning a hostname and port - number, the URI record return a full URI. As such, it can be viewed - as a more powerful resource record than SRV. - - -10. IANA Considerations - -10.1. Registration of the URI Resource Record Type - - IANA has assigned Resource Record Type TBD1 for the URI Resource - Record Type and added the line depicted below to the registry named - Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 - [RFC5395] and located at - http://www.iana.org/assignments/dns-parameters. - - - TYPE Value and meaning Reference - ----------- --------------------------------------------- --------- - URI TBD1 a URI for a service (per the owner name) [RFCXXXX] - - -10.2. Registration of services - - No new registry is needed for the registration of services as the - Enumservice Registrations registry is used also for the URI resource - record type. - - -11. Security Considerations - - The authors do not believe this resource record cause any new - security problems. Deployment must though be done in a proper way as - misconfiguration of this resource record might make it impossible to - reach the service that was originally intended to be accessed. - - Using the URI resource record together with security mechanisms that - relies on verification of authentication of hostnames, like TLS, - makes it important to choose the correct domain name when doing the - comparison. - - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 8] - -Internet-Draft URI Resource Record October 2010 - - - The basic mechanism works as follows: - - 1. Announce the fact example.com is hosted at example.org (with - some URL) in DNS - 2. Secure the URI resource record with DNSSEC. - 3. Verify the TLS (for example) certificate for the connection to - example.org matches, i.e. use the hostname in the URI and not - the hostname used originally when looking up the URI resource - record. - 4. If needed, do application layer authentication etc over the then - encrypted connection. - - What also can happen is that the URI in the resource record type has - errors in it. Applications using the URI resource record type for - resolution should behave similarly as if the user typed (or copy and - pasted) the URI. At least it must be clear to the user that the - error is not due to any error from his side. - - One SHOULD not include userinfo (see User Information, Section 3.2.1, - in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record - as DNS data must be viewed as publicly available information. - - -12. Acknowledgements - - Ideas on how to split the two different kind of queries "What - services exists for this domain name" and "What is the URI for this - service" came from Scott Bradner and Lawrence Conroy. Other people - that have contributed to this document include Richard Barnes, Leslie - Daigle, Olafur Gudmundsson, Ted Hardie, Peter Koch and Penn Pfautz. - - -Appendix A. RRTYPE Allocation Request - - A. Submission Date: - - May 23, 2009 - - B. Submission Type: - - [X] New RRTYPE - [ ] Modification to existing RRTYPE - - C. Contact Information for submitter: - - Name: Patrik Faltstrom - Email Address: paf@cisco.com - International telephone number: +46-8-6859131 - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 9] - -Internet-Draft URI Resource Record October 2010 - - - Other contact handles: - (Note: This information will be publicly posted.) - - D. Motivation for the new RRTYPE application? - - There is no easy way to get from a domain name to a URI (or - IRI). Some mechanisms exists via use of the NAPTR [RFC3403] - resource record. That implies quite complicated rules that are - simplified via the S-NAPTR [RFC3958] specification. But, the - ability to directly look up a URI still exists. This - specification uses a prefix based naming mechanism originated in - the definition of the SRV [RFC2782] resource record, and the - RDATA is a URI, encoded as one text field. - - See also above (Section 1). - - E. Description of the proposed RR type. - - The format of the URI resource record is as follows: - - - Ownername TTL Class URI Priority Weight Target - - - The URI RR has service information encoded in its ownername. In - order to encode the service for a specific owner name one uses - service parameters. Valid service parameters used are either - Enumservice Registrations registered by IANA, or prefixes used - for the SRV resource record. - - The wire format of the RDATA is as follows: - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Priority | Weight | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Target / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 10] - -Internet-Draft URI Resource Record October 2010 - - - F. What existing RRTYPE or RRTYPEs come closest to filling that - need and why are they unsatisfactory? - - The RRTYPE that come closest is the NAPTR resource record. It - is for example used in the DDDS and S-NAPTR algorithms. The - main problem with the NAPTR is that selection of what record (or - records) one is interested in is based on data stored in the - RDATA portion of the NAPTR resource record. This, as explained - in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, - most applications using NAPTR resource records uses regular - expression based rewrite rules for creation of the URI, and that - has shown be complicated to implement. - - The second closest RRTYPE is the SRV record that given a - prefixed based naming just like is suggested for the URI - resource record, one get back a port number and domain name. - This can also be used for creation of a URI, but, only URIs - without path components. - - G. What mnemonic is requested for the new RRTYPE (optional)? - - URI - - H. Does the requested RRTYPE make use of any existing IANA Registry - or require the creation of a new IANA sub-registry in DNS - Parameters? - - Yes, partially. - - One of the mechanisms to select a service is to use the - Enumservice Registry managed by IANA. Another is to use - services and protocols used for SRV records. - - I. Does the proposal require/expect any changes in DNS servers/ - resolvers that prevent the new type from being processed as an - unknown RRTYPE (see [RFC3597])? - - No - - J. Comments: - - None - - - -13. References - - - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 11] - -Internet-Draft URI Resource Record October 2010 - - -13.1. Normative References - - [E164] ITU-T, "The International Public Telecommunication Number - Plan", Recommendation E.164, May 1997. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application - Service Location Using SRV RRs and the Dynamic Delegation - Discovery Service (DDDS)", RFC 3958, January 2005. - - [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource - Identifiers (IRIs)", RFC 3987, January 2005. - - [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA - Considerations", BCP 42, RFC 5395, November 2008. - - [RFC5890] Klensin, J., "Internationalized Domain Names for - Applications (IDNA): Definitions and Document Framework", - RFC 5890, August 2010. - -13.2. Non-normative references - - [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) - Part One: The Comprehensive DDDS", RFC 3401, October 2002. - - [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) - Part Three: The Domain Name System (DNS) Database", - RFC 3403, October 2002. - - [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) - Part Four: The Uniform Resource Identifiers (URI)", - RFC 3404, October 2002. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, January 2005. - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 12] - -Internet-Draft URI Resource Record October 2010 - - - [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name - System", RFC 4592, July 2006. - - [RFC4848] Daigle, L., "Domain-Based Application Service Location - Using URIs and the Dynamic Delegation Discovery Service - (DDDS)", RFC 4848, April 2007. - - [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design - Choices When Expanding the DNS", RFC 5507, April 2009. - - -Authors' Addresses - - Patrik Faltstrom - Cisco Systems - - Email: paf@cisco.com - - - Olaf Kolkman - NLnet Labs - - Email: olaf@NLnetLabs.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Faltstrom & Kolkman Expires April 14, 2011 [Page 13] - - + + + +Network Working Group P. Faltstrom +Internet-Draft Netnod +Updates: 3404, 3959 (if approved) O. Kolkman +Intended status: Standards Track NLnet Labs +Expires: January 04, 2014 July 5, 2013 + + The Uniform Resource Identifier (URI) DNS Resource Record + draft-faltstrom-uri-08 + +Abstract + + This document defines a new DNS resource record, called the Uniform + Resource Identifier (URI) RR, for publishing mappings from hostnames + to URIs. + + This document updates RFC 3958 and RFC 3404. + +Status of this Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + 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." + + This Internet-Draft will expire on January 04, 2014. + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (http://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Simplified BSD License text + + + + + + + + +Faltstrom & Kolkman Expires January 04, 2014 [Page 1] + +Internet-Draft URI Resource Record July 2013 + + as described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 + 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 3 + 4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 3 + 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4 + 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 + 5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 5 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 6.1. Homepage at one domain, but two domains in use . . . . . . 6 + 7. Relation to S-NAPTR . . . . . . . . . . . . . . . . . . . . . 6 + 8. Relation to U-NAPTR . . . . . . . . . . . . . . . . . . . . . 6 + 9. Relation to SRV . . . . . . . . . . . . . . . . . . . . . . . 7 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 10.1. Registration of the URI Resource Record Type . . . . . . 7 + 10.2. Registration of services . . . . . . . . . . . . . . . . 7 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 13.2. Non-normative references . . . . . . . . . . . . . . . . 8 + Appendix A. The original RRTYPE Allocation Request . . . . . . . . 9 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 + +1. Introduction + + This document explains the use of the Domain Name System (DNS) for + the storage of URIs, and how to resolve hostnames to such URIs that + can be used by various applications. For resolution the application + need to know both the hostname and the protocol that the URI is to be + used for. The protocol is registered by IANA. + + Currently, looking up URIs given a hostname uses the DDDS [RFC3401] + application framework with the DNS as a database as specified in RFC + 3404 [RFC3404]. This has a number of implications such as the + inability to select what NAPTR records that match the query are + interesting. The RRSet returned will always consist of all URIs + "connected" with the domain in question. + + The URI resource record specified in this document enables the + querying party to select which ones of the NAPTR records one is + interested in. This because data in the service field of the NAPTR + record is included in the owner part of the URI resource record type. + + + + + +Faltstrom & Kolkman Expires January 04, 2014 [Page 2] + +Internet-Draft URI Resource Record July 2013 + + + Querying for URI resource records is not replacing querying for NAPTR + resource records (or use of S-NAPTR [RFC3958]). Instead, the URI + resource record type provides a complementary mechanism to use when + one already knows what service field is interesting. With it, one + can directly query for the specific subset of the otherwise possibly + large RRSet given back when querying for NAPTR resource records. + + This document updates RFC 3958 and RFC 3404 by adding the flag "D" to + the list of defined terminal flags in section 2.2.3 of RFC 3958 and + 4.3 of RFC 3404. + + 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 BCP 14, RFC 2119 + [RFC2119]. + +2. Applicability Statement + + In general, it is expected that URI records will be used by clients + for applications where the relevant protocol to be used is known, + but, for example, an extra abstraction is needed in order to separate + a domain name from a point of service (as addressed by the URI). One + example of such a situation is when an organisation has many domain + names, but only one official web page. + + Applications MUST know the specific service fields to prepend the + hostname with. Using repetitive queries for URI records MUST NOT be + a replacement for querying for NAPTR records according to the NAPTR + (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to + discover the various services and URIs for looking up access points + for a given service. Those are two very different kinds of needs. + +3. DNS considerations + + Using prefix labels, such as underscored service tags, prevents the + use of wildcards, as constructs as _s2._s1.*.example.net. are not + possible in the DNS, see RFC 4592 [RFC4592]. Besides, underscored + service tags used for the URI RR (based on the NAPTR service + descriptions) may have slightly different semantics than service tags + used for underscored prefix labels that are used in combination with + other (yet unspecified) RR types. This may cause subtle management + problems when delegation structure that has developed within the + context of URI RRs is also to be used for other RR types. Since the + service labels might be overloaded, applications should carefully + check that the application level protocol is indeed the protocol they + expect. + + Subtle management issues may also arise when the delegations from + service to sub service label involves several parties and different + stake holders. + +4. The format of the URI RR + + +Faltstrom & Kolkman Expires January 04, 2014 [Page 3] + +Internet-Draft URI Resource Record July 2013 + + + This is the presentation format of the URI RR: + + + Ownername TTL Class URI Priority Weight Target + + + The URI RR does not cause any kind of Additional Section processing. + +4.1. Ownername, class and type + + The URI ownername is subject to special conventions. + + Just like the SRV RR [RFC2782] the URI RR has service information + encoded in its ownername. In order to encode the service for a + specific owner name one uses service parameters. Valid service + parameters used are those used for SRV resource records, or + registered by IANA for Enumservice Registrations. The Enumservice + Registration parameters are reversed (subtype(s) before type), + prepended with an underscore (_) and prepended to the owner name in + separate labels. The underscore is prepended to the service + parameters to avoid collisions with DNS labels that occur in nature, + and the order is reversed to make it possible to do delegations, if + needed, to different zones (and therefore providers of DNS). + + It should be noted that the usage of a prefix must be described in + detail in for example the Enumservice Registration documentation, or + in a specific document that clarifies potential overload of + parameters in the same URI. Specifically, registered URI schemes are + not automatically acceptable as a service. With the HTTP scheme, one + can for example have multiple methods (GET, PUT, etc), and this with + the same URI. + + For example, suppose we are looking for the URI for a service with + Service Parameter "A:B:C" for host example.com.. Then we would query + for (QNAME,QTYPE)=("_C._B._A.example.com","URI") + + The type number for the URI record is 256. + + The URI resource record is class independent. + + The URI RR has no special TTL requirements. + +4.2. Priority + + The priority of the target URI in this RR. Its range is 0-65535. A + client MUST attempt to contact the URI with the lowest-numbered + priority it can reach; URIs with the same priority SHOULD be tried in + + + + + + + +Faltstrom & Kolkman Expires January 04, 2014 [Page 4] + +Internet-Draft URI Resource Record July 2013 + + the order defined by the weight field. + +4.3. Weight + + A server selection mechanism. The weight field specifies a relative + weight for entries with the same priority. Larger weights SHOULD be + given a proportionately higher probability of being selected. The + range of this number is 0-65535. + +4.4. Target + + The URI of the target, enclosed in double-quote characters ('"'). + Resolution of the URI is according to the definitions for the Scheme + of the URI. + + Since the URI will not be encoded as a (see + RFC1035 section 3.3 [RFC1035]) there is no 255 character size + limitation. + +4.5. URI RDATA Wire Format + + The RDATA for a URI RR consists of a 2 octet Priority field, a two + octet Weight field, and a variable length target field. + + Priority and Weight are unsigned integers in network byte order. + + The remaining data in the RDATA contains the Target field. The + Target field contains the URI as a sequence of octets (without the + enclosing double- quote characters used in the presentation format). + + The Target field can also contain an IRI, but with the additional + requirements that it are in UTF-8 [RFC3629], and the requirement that + it be possible to convert to a URI according to section 3.1 of RFC + 3987 [RFC3987] and back again to an IRI according to section 3.2. + Other character sets than UTF-8 are not allowed. The domain name + part of the IRI can be either an U-LABEL or A-LABEL as defined in RFC + 5890 [RFC5890]. + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Priority | Weight | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Target / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +5. Definition of the flag 'D' for NAPTR records + + + + +Faltstrom & Kolkman Expires January 04, 2014 [Page 5] + +Internet-Draft URI Resource Record July 2013 + + + This document specifies the flag "D" for use as a flag in NAPTR + records. The flag indicate a terminal NAPTR record because it + denotes the end of the DDDS/NAPTR processing rules. In the case of a + "D" flag, the Replacement field in the NAPTR record, prepended with + the service flags, is used as the Owner of a DNS query for URI + records, and normal URI processing as defined in this document is + applied. + + The replacement field MUST NOT include any of the service parameters. + Those are to be prepended (together with underscore) as described in + other places in this document. + + The Regexp field in the NAPTR record MUST be empty when the 'D' flag + is in use. + +6. Examples + +6.1. Homepage at one domain, but two domains in use + + An organisation has the domain names example.com and example.net, but + the official URI http://www.example.com/. Given the service type + "web" and subtype "http" (from the IANA registry), the following URI + Resource Records could be made available in the respective zones + (example.com and example.net): + + + $ORIGIN example.com. + _http._web IN URI 10 1 "http://www.example.com/" + + $ORIGIN example.net. + _http._web IN URI 10 1 "http://www.example.com/" + + +7. Relation to S-NAPTR + + The URI resource record type is not a replacement for the S-NAPTR. + It is instead an extension and the seond step of the S-NAPTR + resolution can resolve a URI resource record instead of using SRV + records and yet another algorithm for how to use SRV records for the + specific protocol. + + + $ORIGIN example.com. + ;; order pref flags + IN NAPTR 100 10 "s" "EM:ProtA" ( ; service + "" ; regexp + _ProtA._tcp.example.com. ; replacement + _ProtA._tcp IN URI "schemeA:service.example.com/example" + + +8. Relation to U-NAPTR + + + +Faltstrom & Kolkman Expires January 04, 2014 [Page 6] + +Internet-Draft URI Resource Record July 2013 + + + The URI Resource Record Type, together with S-NAPTR, can be viewed as + a replacement for U-NAPTR [RFC4848]. The URI Resource Record Type is + though only interesting when one know a base domain name, a protocol + and service so that one can compose the record to look up. NAPTR + records of any kind are used to look up what services exists for a + certain domain, which is one step before the URI resource record is + used. + +9. Relation to SRV + + The URI Resource Record Type can be viewed as a replacement for the + SRV record. This because it like the SRV record can only be looked + up if one know the base domain, the protocol and the service. It has + a similar functionality, but instead of returning a hostname and port + number, the URI record return a full URI. As such, it can be viewed + as a more powerful resource record than SRV. + +10. IANA Considerations + +10.1. Registration of the URI Resource Record Type + + After an expert review in February 2011 (see Appendix Appendix A) + IANA has allocated RRTYPE 256 for the URI Resource Record Type in the + registry named Resource Record (RR) TYPEs and QTYPEs as defined in + BCP 42 (at the time RFC 6195 [RFC6195]), located at http:// + www.iana.org/assignments/dns-parameters. + + IANA is requested to update the reference with that registration to + this RFC. + +10.2. Registration of services + + No new registry is needed for the registration of services as the + Enumservice Registrations registry is used also for the URI resource + record type. + +11. Security Considerations + + The authors do not believe this resource record cause any new + security problems. Deployment must though be done in a proper way as + misconfiguration of this resource record might make it impossible to + reach the service that was originally intended to be accessed. + + Using the URI resource record together with security mechanisms that + relies on verification of authentication of hostnames, like TLS, + makes it important to choose the correct domain name when doing the + comparison. + + The basic mechanism works as follows: + + 1. Announce the fact example.com is hosted at example.org (with + some URL) in DNS + 2. Secure the URI resource record with DNSSEC. + +Faltstrom & Kolkman Expires January 04, 2014 [Page 7] + +Internet-Draft URI Resource Record July 2013 + + 3. Verify the TLS (for example) certificate for the connection to + example.org matches, i.e. use the hostname in the URI and not + the hostname used originally when looking up the URI resource + record. + 4. If needed, do application layer authentication etc over the then + encrypted connection. + + What also can happen is that the URI in the resource record type has + errors in it. Applications using the URI resource record type for + resolution should behave similarly as if the user typed (or copy and + pasted) the URI. At least it must be clear to the user that the error + is not due to any error from his side. + + One SHOULD NOT include userinfo (see User Information, Section 3.2.1, + in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record + as DNS data must be viewed as publicly available information. + +12. Acknowledgements + + Ideas on how to split the two different kind of queries "What + services exists for this domain name" and "What is the URI for this + service" came from Scott Bradner and Lawrence Conroy. Other people + that have contributed to this document include Richard Barnes, Leslie + Daigle, Olafur Gudmundsson, Ted Hardie, Peter Koch, Penn Pfautz, and + Willem Toorop. + +13. References + +13.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application + Service Location Using SRV RRs and the Dynamic Delegation + Discovery Service (DDDS)", RFC 3958, January 2005. + + [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRIs)", RFC 3987, January 2005. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, August 2010. + + [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 6195, March 2011. + +13.2. Non-normative references + +Faltstrom & Kolkman Expires January 04, 2014 [Page 8] + +Internet-Draft URI Resource Record July 2013 + + + [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) + Part One: The Comprehensive DDDS", RFC 3401, October 2002. + + [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) + Part Three: The Domain Name System (DNS) Database", RFC + 3403, October 2002. + + [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) + Part Four: The Uniform Resource Identifiers (URI)", RFC + 3404, October 2002. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. + + [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name + System", RFC 4592, July 2006. + + [RFC4848] Daigle, L., "Domain-Based Application Service Location + Using URIs and the Dynamic Delegation Discovery Service + (DDDS)", RFC 4848, April 2007. + + [RFC5507] IAB, Faltstrom, P., Austein, R. and P. Koch, "Design + Choices When Expanding the DNS", RFC 5507, April 2009. + +Appendix A. The original RRTYPE Allocation Request + + On February 22, 2011 IANA assigned RRTYPE 256 for the URI resource + record based on a request that followed the procedure documented in + RFC 6195 [RFC6195]. The DNS RRTYPE PARAMETER ALLOCATION form as + submitted to IANA at thet time is replicated below for reference. + + A. Submission Date: + + May 23, 2009 + + B. Submission Type: + + [X] New RRTYPE + [ ] Modification to existing RRTYPE + + C. Contact Information for submitter: + + Name: Patrik Faltstrom + Email Address: paf@cisco.com + International telephone number: +46-8-6859131 + +Faltstrom & Kolkman Expires January 04, 2014 [Page 9] + +Internet-Draft URI Resource Record July 2013 + + Other contact handles: + (Note: This information will be publicly posted.) + + D. Motivation for the new RRTYPE application? + + There is no easy way to get from a domain name to a URI (or + IRI). Some mechanisms exists via use of the NAPTR [RFC3403] + resource record. That implies quite complicated rules that are + simplified via the S-NAPTR [RFC3958] specification. But, the + ability to directly look up a URI still exists. This + specification uses a prefix based naming mechanism originated in + the definition of the SRV [RFC2782] resource record, and the + RDATA is a URI, encoded as one text field. + + See also above (Section 1). + + E. Description of the proposed RR type. + + The format of the URI resource record is as follows: + + + Ownername TTL Class URI Priority Weight Target + + + The URI RR has service information encoded in its ownername. In + order to encode the service for a specific owner name one uses + service parameters. Valid service parameters used are either + Enumservice Registrations registered by IANA, or prefixes used + for the SRV resource record. + + The wire format of the RDATA is as follows: + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Priority | Weight | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Target / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + F. What existing RRTYPE or RRTYPEs come closest to filling that + need and why are they unsatisfactory? + + + + + + + + + +Faltstrom & Kolkman Expires January 04, 2014 [Page 10] + +Internet-Draft URI Resource Record July 2013 + + The RRTYPE that come closest is the NAPTR resource record. It + is for example used in the DDDS and S-NAPTR algorithms. The + main problem with the NAPTR is that selection of what record (or + records) one is interested in is based on data stored in the + RDATA portion of the NAPTR resource record. This, as explained + in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, + most applications using NAPTR resource records uses regular + expression based rewrite rules for creation of the URI, and that + has shown be complicated to implement. + + The second closest RRTYPE is the SRV record that given a + prefixed based naming just like is suggested for the URI + resource record, one get back a port number and domain name. + This can also be used for creation of a URI, but, only URIs + without path components. + + G. What mnemonic is requested for the new RRTYPE (optional)? + + URI + + H. Does the requested RRTYPE make use of any existing IANA Registry + or require the creation of a new IANA sub-registry in DNS + Parameters? + + Yes, partially. + + One of the mechanisms to select a service is to use the + Enumservice Registry managed by IANA. Another is to use services + and protocols used for SRV records. + + I. Does the proposal require/expect any changes in DNS servers/ + resolvers that prevent the new type from being processed as an + unknown RRTYPE (see [RFC3597])? + + No + + J. Comments: + + None + + +Authors' Addresses + + Patrik Faltstrom + Netnod + + Email: paf@netnod.se + + + Olaf Kolkman + NLnet Labs + + Email: olaf@NLnetLabs.nl + +Faltstrom & Kolkman Expires January 04, 2014 [Page 11] diff --git a/doc/draft/draft-ietf-behave-address-format-07.txt b/doc/draft/draft-ietf-behave-address-format-07.txt deleted file mode 100644 index 9c35be27085..00000000000 --- a/doc/draft/draft-ietf-behave-address-format-07.txt +++ /dev/null @@ -1,1009 +0,0 @@ - - - -Network Working Group C. Bao -Internet-Draft CERNET Center/Tsinghua University -Obsoletes: 2765 (if approved) C. Huitema -Updates: 4291 (if approved) Microsoft Corporation -Intended status: Standards Track M. Bagnulo -Expires: October 11, 2010 UC3M - M. Boucadair - France Telecom - X. Li - CERNET Center/Tsinghua University - April 9, 2010 - - - IPv6 Addressing of IPv4/IPv6 Translators - draft-ietf-behave-address-format-07.txt - -Abstract - - This document discusses the algorithmic translation of an IPv6 - address to a corresponding IPv4 address, and vice versa, using only - statically configured information. It defines a well-known prefix - for use in algorithmic translations, while allowing organizations to - also use network-specific prefixes when appropriate. Algorithmic - translation is used in IPv4/IPv6 translators, as well as other types - of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. - -Status of this Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - 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." - - This Internet-Draft will expire on October 11, 2010. - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - - - -Bao, et al. Expires October 11, 2010 [Page 1] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3 - 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 4 - 2.1. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4 - 2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 4 - 2.3. Address Translation Algorithms . . . . . . . . . . . . . . 6 - 2.4. Text Representation . . . . . . . . . . . . . . . . . . . 6 - 3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 7 - 3.1. Restrictions on the use of the Well-Known Prefix . . . . . 7 - 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8 - 3.3. Choice of Prefix for Stateless Translation Deployments . . 8 - 3.4. Choice of Prefix for Stateful Translation Deployments . . 11 - 3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 11 - 3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 13 - 4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 - - - - - - - - - - - - -Bao, et al. Expires October 11, 2010 [Page 2] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - -1. Introduction - - This document is part of a series of IPv4/IPv6 translation documents. - A framework for IPv4/IPv6 translation is discussed in - [I-D.ietf-behave-v6v4-framework], including a taxonomy of scenarios - that will be used in this document. Other documents specify the - behavior of various types of translators and gateways, including - mechanisms for translating between IP headers and other types of - messages that include IP addresses. This document specifies how an - individual IPv6 address is translated to a corresponding IPv4 - address, and vice versa, in cases where an algorithmic mapping is - used. While specific types of devices are used herein as examples, - it is the responsibility of the specification of such devices to - reference this document for algorithmic mapping of the addresses - themselves. - - Section 2 describes the prefixes and the format of "IPv4-Embedded - IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an - IPv4 address. This format is common to both "IPv4-Converted" and - "IPv4-Translatable" IPv6 addresses. This section also defines the - algorithms for translating addresses, and the text representation of - IPv4-Embedded IPv6 addresses. - - Section 3 discusses the choice of prefixes, the conditions in which - they can be used, and the use of IPv4-Embedded IPv6 addresses with - stateless and stateful translation. - - Section 4 discusses security concerns. - - In some scenarios, a dual-stack host will unnecessarily send its - traffic through an IPv6/IPv4 translator. This can be caused by - host's default address selection algorithm [RFC3484], referrals, or - other reasons. Optimizing these scenarios for dual-stack hosts is - for future study. - -1.1. Applicability Scope - - This document is part of a series defining address translation - services. We understand that the address format could also be used - by other interconnection methods between IPv6 and IPv4, e.g., methods - based on encapsulation. If encapsulation methods are developed by - the IETF, we expect that their descriptions will document their - specific use of IPv4-Embedded IPv6 addresses. - -1.2. Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - - - -Bao, et al. Expires October 11, 2010 [Page 3] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - document are to be interpreted as described in RFC 2119 [RFC2119]. - -1.3. Terminology - - This document makes use of the following terms: - - IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6 - packets, and vice versa. It may do "stateless" translation, - meaning that there is no per-flow state required, or "stateful" - translation where per-flow state is created when the first packet - in a flow is received. - Address translator: any entity that has to derive an IPv4 address - from an IPv6 address or vice versa. This applies not only to - devices that do IPv4/IPv6 packet translation, but also to other - entities that manipulate addresses, such as name resolution - proxies (e.g. DNS64 [I-D.ietf-behave-dns64]) and possibly other - types of Application Layer Gateways (ALGs). - Well-Known Prefix: the IPv6 prefix defined in this document for use - in an algorithmic mapping. - Network-Specific Prefix: an IPv6 prefix assigned by an organization - for use in algorithmic mapping. Options for the Network Specific - Prefix are discussed in Section 3.3 and Section 3.4. - IPv4-Embedded IPv6 addresses: IPv6 addresses in which 32 bits - contain an IPv4 address. Their format is described in - Section 2.2. - IPv4-Converted IPv6 addresses: IPv6 addresses used to represent IPv4 - nodes in an IPv6 network. They are a variant of IPv4-Embedded - IPv6 addresses, and follow the format described in Section 2.2. - IPv4-Translatable IPv6 addresses: IPv6 addresses assigned to IPv6 - nodes for use with stateless translation. They are a variant of - IPv4-Embedded IPv6 addresses, and follow the format described in - Section 2.2. - - -2. IPv4-Embedded IPv6 Address Prefix and Format - -2.1. Well Known Prefix - - This document reserves a "Well-Known Prefix" for use in an - algorithmic mapping. The value of this IPv6 prefix is: - - 64:FF9B::/96 - -2.2. IPv4-Embedded IPv6 Address Format - - IPv4-Converted IPv6 addresses and IPv4-Translatable IPv6 addresses - follow the same format, described here as the IPv4-Embedded IPv6 - address Format. IPv4-Embedded IPv6 addresses are composed of a - - - -Bao, et al. Expires October 11, 2010 [Page 4] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - variable length prefix, the embedded IPv4 address, and a variable - length suffix, as presented in the following diagram, in which PL - designates the prefix length: - - - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |32| prefix |v4(32) | u | suffix | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |40| prefix |v4(24) | u |(8)| suffix | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |48| prefix |v4(16) | u | (16) | suffix | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |56| prefix |(8)| u | v4(24) | suffix | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |64| prefix | u | v4(32) | suffix | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |96| prefix | v4(32) | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - Figure 1 - - In these addresses, the prefix shall be either the "Well-Known - Prefix", or a "Network-Specific Prefix" unique to the organization - deploying the address translators. The prefixes can only have one of - the following lengths: 32, 40, 48, 56, 64 or 96. (The Well-Known - prefic is 96 bits long, and can only be used in the last form of the - table.) - - Various deployments justify different prefix lengths with Network- - Specific prefixes. The tradeoff between different prefix lengths are - discussed in Section 3.3 and Section 3.4. - - Bits 64 to 71 of the address are reserved for compatibility with the - host identifier format defined in the IPv6 addressing architecture - [RFC4291]. These bits MUST be set to zero. When using a /96 - Network-Specific Prefix, the administrators MUST ensure that the bits - 64 to 71 are set to zero. A simple way to achieve that is to - construct the /96 Network-Specific Prefix by picking a /64 prefix, - and then adding four octets set to zero. - - The IPv4 address is encoded following the prefix, most significant - bits first. Depending of the prefix length, the 4 octets of the - address may be separated by the reserved octet "u", whose 8 bits MUST - be set to zero. In particular: - - - - -Bao, et al. Expires October 11, 2010 [Page 5] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - o When the prefix is 32 bits long, the IPv4 address is encoded in - positions 32 to 63. - o When the prefix is 40 bits long, 24 bits of the IPv4 address are - encoded in positions 40 to 63, with the remaining 8 bits in - position 72 to 79. - o When the prefix is 48 bits long, 16 bits of the IPv4 address are - encoded in positions 48 to 63, with the remaining 16 bits in - position 72 to 87. - o When the prefix is 56 bits long, 8 bits of the IPv4 address are - encoded in positions 56 to 63, with the remaining 24 bits in - position 72 to 95. - o When the prefix is 64 bits long, the IPv4 address is encoded in - positions 72 to 103. - o When the prefix is 96 bits long, the IPv4 address is encoded in - positions 96 to 127. - - There are no remaining bits, and thus no suffix, if the prefix is 96 - bits long. In the other cases, the remaining bits of the address - constitute the suffix. These bits are reserved for future - extensions, and SHOULD be set to zero. - -2.3. Address Translation Algorithms - - IPv4-Embedded IPv6 addresses are composed according to the following - algorithm: - o Concatenate the prefix, the 32 bits of the IPv4 address and the - null suffix if needed to obtain a 128 bit address. - o If the prefix length is less than 96 bits, insert the null octet - "u" at the appropriate position, thus causing the least - significant octet to be excluded, as documented in Figure 1. - - The IPv4 addresses are extracted from the IPv4-Embedded IPv6 - addresses according to the following algorithm: - o If the prefix is 96 bit long, extract the last 32 bits of the IPv6 - address; - o for the other prefix lengths, extract the "u" octet to obtain a - 120 bit sequence, then extract the 32 bits following the prefix. - -2.4. Text Representation - - IPv4-Embedded IPv6 addresses will be represented in text in - conformity with section 2.2 of [RFC4291]. IPv4-Embedded IPv6 - addresses constructed using the Well-Known Prefix or a /96 Network- - Specific Prefix may be represented using the alternative form - presented in section 2.2 of [RFC4291], with the embedded IPv4 address - represented in dotted decimal notation. Examples of such - representations are presented in Table 1 and Table 2. - - - - -Bao, et al. Expires October 11, 2010 [Page 6] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - +-----------------------+------------+------------------------------+ - | Network-Specific | IPv4 | IPv4-Embedded IPv6 address | - | Prefix | address | | - +-----------------------+------------+------------------------------+ - | 2001:DB8::/32 | 192.0.2.33 | 2001:DB8:C000:221:: | - | 2001:DB8:100::/40 | 192.0.2.33 | 2001:DB8:1C0:2:21:: | - | 2001:DB8:122::/48 | 192.0.2.33 | 2001:DB8:122:C000:2:2100:: | - | 2001:DB8:122:300::/56 | 192.0.2.33 | 2001:DB8:122:3C0:0:221:: | - | 2001:DB8:122:344::/64 | 192.0.2.33 | 2001:DB8:122:344:C0:2:2100:: | - | 2001:DB8:122:344::/96 | 192.0.2.33 | 2001:DB8:122:344::192.0.2.33 | - +-----------------------+------------+------------------------------+ - - Table 1: Text representation of IPv4-Embedded IPv6 addresses using - Network-Specific Prefixes - - +-------------------+--------------+----------------------------+ - | Well Known Prefix | IPv4 address | IPv4-Embedded IPv6 address | - +-------------------+--------------+----------------------------+ - | 64:FF9B::/96 | 192.0.2.33 | 64:FF9B::192.0.2.33 | - +-------------------+--------------+----------------------------+ - - Table 2: Text representation of IPv4-Embedded IPv6 addresses using - the Well-Known Prefix - - The Network-Specific Prefix examples in Table 1 are derived from the - IPv6 prefix reserved for documentation in [RFC3849]. The IPv4 - address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for - documentation in [RFC5735]. - - -3. Deployment Guidelines and Choices - -3.1. Restrictions on the use of the Well-Known Prefix - - The Well-Known Prefix MAY be used by organizations deploying - translation services, as explained in Section 3.4. - - The Well-Known Prefix SHOULD NOT be used to construct IPv4- - Translatable addresses. The nodes served by IPv4-Translatable IPv6 - addresses should be able to receive global IPv6 traffic bound to - their IPv4-Translatable IPv6 address without incurring intermediate - protocol translation. This is only possible if the specific prefix - used to build the IPv4-Translatable IPv6 addresses is advertized in - inter-domain routing, but the advertisement of more specific prefixes - derived from the Well-Known Prefix is not supported, as explained in - Section 3.2. Network-Specific Prefixes SHOULD be used in these - scenarios, as explained in Section 3.3. - - - - -Bao, et al. Expires October 11, 2010 [Page 7] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - The Well-Known Prefix MUST NOT be used to represent non global IPv4 - addresses, such as those defined in [RFC1918]. - -3.2. Impact on Inter-Domain Routing - - The Well-Known Prefix MAY appear in inter-domain routing tables, if - service providers decide to provide IPv6-IPv4 interconnection - services to peers. Advertisement of the Well-Known Prefix SHOULD be - controlled either by upstream and/or downstream service providers - owing to inter-domain routing policies, e.g., through configuration - of BGP [RFC4271]. Organizations that advertize the Well-Known Prefix - in inter-domain routing MUST be able to provide IPv4/IPv6 translation - service. - - When the IPv4/IPv6 translation relies on the Well-Known Prefix, - embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be - advertised in BGP (especially e-BGP) [RFC4271] because this leads to - importing the IPv4 routing table into the IPv6 one and therefore - induces scalability issues to the global IPv6 routing table. - Administrators of BGP nodes SHOULD configure filters that discard - advertisements of embedded IPv6 prefixes longer than the Well-Known - Prefix. - - When the IPv4/IPv6 translation service relies on Network-Specific - Prefixes, the IPv4-Translatable IPv6 prefixes used in stateless - translation MUST be advertised with proper aggregation to the IPv6 - Internet. Similarly, if translators are configured with multiple - Network-Specific Prefixes,these prefixes MUST be advertised to the - IPv6 Internet with proper aggregation. - -3.3. Choice of Prefix for Stateless Translation Deployments - - Organizations may deploy translation services using stateless - translation. In these deployments, internal IPv6 nodes are addressed - using IPv4-Translatable IPv6 addresses, which enable them to be - accessed by IPv4 nodes. The addresses of these external IPv4 nodes - are then represented in IPv4-Converted IPv6 addresses. - - Organizations deploying stateless IPv4/IPv6 translation SHOULD assign - a Network-Specific Prefix to their IPv4/IPv6 translation service. - IPv4-Translatable and IPv4-Converted IPv6 addresses MUST be - constructed as specified in Section 2.2. IPv4-Translatable IPv6 - addresses MUST use the selected Network-Specific Prefix. Both IPv4- - Translatable IPv6 addresses and IPv4-Converted IPv6 addresses SHOULD - use the same prefix. - - Using the same prefix ensures that IPv6 nodes internal to the - organization will use the most efficient paths to reach the nodes - - - -Bao, et al. Expires October 11, 2010 [Page 8] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - served by IPv4-Translatable IPv6 addresses. Specifically, if a node - learns the IPv4 address of a target internal node without knowing - that this target is in fact located behind the same translator that - the node also uses, translation rules will ensure that the IPv6 - address constructed with the Network-Specific prefix is the same as - the IPv4-Translatable IPv6 address assigned to the target. Standard - routing preference (more specific wins) will then ensure that the - IPv6 packets are delivered directly, without requiring "hair-pinning" - at the translator. - - The intra-domain routing protocol must be able to deliver packets to - the nodes served by IPv4-Translatable IPv6 addresses. This may - require routing on some or all of the embedded IPv4 address bits. - Security considerations detailed in Section 4 require that routers - check the validity of the IPv4-Translatable IPv6 source addresses, - using some form of reverse path check. - - The management of stateless address translation can be illustrated - with a small example. We will consider an IPv6 network with the - prefix 2001:DB8:122::/48. The network administrator has selected the - Network-Specific prefix 2001:DB8:122:344::/64 for managing stateless - IPv4/IPv6 translation. The IPv4-Translatable address block is 2001: - DB8:122:344:C0:2::/96 and this block is visible in IPv4 as the subnet - 192.0.2.0/24. In this network, the host A is assigned the IPv4- - Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which - corresponds to the IPv4 address 192.0.2.33. Host A's address is - configured either manually or through DHCPv6. - - In this example, host A is not directly connected to the translator, - but instead to a link managed by a router R. The router R is - configured to forward to A the packets bound to 2001:DB8:122:344:C0: - 2:2100::. To receive these packets, R will advertise reachability of - the prefix 2001:DB8:122:344:C0:2:2100::/104 in the intra-domain - routing protocol -- or perhaps a shorter prefix if many hosts on link - have IPv4-Translatable IPv6 addresses derived from the same IPv4 - subnet. If a packet bound to 192.0.2.33 reaches the translator, the - destination address will be translated to 2001:DB8:122:344:C0:2: - 2100::, and the packet will be routed towards R and then to A. - - Let's suppose now that a host B of the same domain learns the IPv4 - address of A, maybe through an application-specific referral. If B - has translation-aware software, B can compose a destination address - by combining the Network-Specific Prefix 2001:DB8:122:344::/64 and - the IPv4 address 192.0.2.33, resulting in the address 2001:DB8:122: - 344:C0:2:2100::. The packet sent by B will be forwarded towards R, - and then to A, avoiding protocol translation. - - Forwarding, and reverse path checks, should be performed on the - - - -Bao, et al. Expires October 11, 2010 [Page 9] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - combination of the prefix and the IPv4 address. In theory, routers - should be able to route on prefixes of any length. However, routing - on prefixes larger than 64 bits may be slower on some routers. But - routing efficiency is not the only consideration in the choice of a - prefix length. Organizations also need to consider the availability - of prefixes, and the potential impact of all-zeroes identifiers. - - If a /32 prefix is used, all the routing bits are contained in the - top 64 bits of the IPv6 address, leading to excellent routing - properties. These prefixes may however be hard to obtain, and - allocation of a /32 to a small set of IPv4-Translatable IPv6 - addresses may be seen as wasteful. In addition, the /32 prefix and a - zero suffix leads to an all-zeroes interface identifier, an issue - that we discuss in Section 3.5. - - Intermediate prefix lengths such as /40, /48 or /56 appear as - compromises. Only some of the IPv4 bits are part of the /64 - prefixes. Reverse path checks, in particular, may have a limited - efficiency. Reverse path checks limited to the most significant bits - of the IPv4 address will reduce the possibility of spoofing external - IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4- - Translatable IPv6 addresses. - - We propose here a compromise, based on using no more than 1/256th of - an organization's allocation of IPv6 addresses for the IPv4/IPv6 - translation service. For example, if the organization is an Internet - Service Provider with an allocated IPv6 prefix /32 or shorter, the - ISP could dedicate a /40 prefix to the translation service. An end - site with a /48 allocation could dedicate a /56 prefix to the - translation service, or possibly a /96 prefix if all IPv4- - Translatable IPv6 addresses are located on the same link. - - The recommended prefix length is also a function of the deployment - scenario. The stateless translation can be used for Scenario 1, - Scenario 2, Scenario 5, and Scenario 6 defined in - [I-D.ietf-behave-v6v4-framework]. For different scenarios, the - prefix length recommendations are: - o For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario - 2 (the IPv4 Internet to an IPv6 network), we recommend using a /40 - prefix for an ISP holding a /32 allocation, and a /56 prefix for a - site holding a /48 allocation. - o For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6 - (an IPv4 network to an IPv6 network), we recommend using a /64 or - a /96 prefix. - - IPv4-Translatable IPv6 addresses SHOULD follow the IPv6 address - architecture and SHOULD be compatible with the IPv4 address - architecture. The first IPv4-translatable address is the subnet- - - - -Bao, et al. Expires October 11, 2010 [Page 10] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - router anycast address in IPv6 and network identifier in IPv4, the - last IPv4-translatable address is the subnet broadcast addresses in - IPv4. Both of them SHOULD NOT be used for IPv6 nodes. In addition, - the minimum IPv4 subnet can be used for hosts is /30 (the router - interface needs a valid address for the same subnet) and this rule - SHOULD also be applied to the corresponding subnet of the IPv4- - translatable addresses. - -3.4. Choice of Prefix for Stateful Translation Deployments - - Organizations may deploy translation services based on stateful - translation technology. An organization may decide to use either a - Network-Specific Prefix or the Well-Known Prefix for its stateful - IPv4/IPv6 translation service. - - When these services are used, IPv6 nodes are addressed through - standard IPv6 addresses, while IPv4 nodes are represented by IPv4- - Converted IPv6 addresses, as specified in Section 2.2. - - The stateful nature of the translation creates a potential stability - issue when the organization deploys multiple translators. If several - translators use the same prefix, there is a risk that packets - belonging to the same connection may be routed to different - translators as the internal routing state changes. This issue can be - avoided either by assigning different prefixes to different - translators, or by ensuring that all translators using same prefix - coordinate their state. - - Stateful translation can be used in scenarios defined in - [I-D.ietf-behave-v6v4-framework]. The Well Known Prefix SHOULD be - used in these scenarios, with two exceptions: - o In all scenarios, the translation MAY use a Network-Specific - Prefix, if deemed appropriate for management reasons. - o The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 - Internet to an IPv4 network), as this would lead to using the - Well-Known Prefix with non-global IPv4 addresses. That means a - Network-Specific Prefix MUST be used in that scenario, for example - a /96 prefix compatible with the Well-Known prefix format. - -3.5. Choice of Suffix - - The address format described in Section 2.2 recommends a zero suffix. - Before making this recommendation, we considered different options: - checksum neutrality; the encoding of a port range; and a value - different than 0. - - In the case of stateless translation, there would be no need for the - translator to recompute a one's complement checksum if both the IPv4- - - - -Bao, et al. Expires October 11, 2010 [Page 11] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - Translatable and the IPv4-Converted IPv6 addresses were constructed - in a "checksum-neutral" manner, that is if the IPv6 addresses would - have the same one's complement checksum as the embedded IPv4 address. - In the case of stateful translation, checksum neutrality does not - eliminate checksum computation during translation, as only one of the - two addresses would be checksum neutral. We considered reserving 16 - bits in the suffix to guarantee checksum neutrality, but declined - because it would not help with stateful translation, and because - checksum neutrality can also be achieved by an appropriate choice of - the Network-Specific Prefix, as was done for example with the Well- - Known Prefix. - - There have been proposals to complement stateless translation with a - port-range feature. Instead of mapping an IPv4 address to exactly - one IPv6 prefix, the options would allow several IPv6 nodes to share - an IPv4 address, with each node managing a different range of ports. - If a port range extension is needed, it could be defined later, using - bits currently reserved as null in the suffix. - - When a /32 prefix is used, an all-zero suffix results in an all-zero - interface identifier. We understand the conflict with Section 2.6.1 - of RFC4291, which specifies that all zeroes are used for the subnet- - router anycast address. However, in our specification, there would - be only one node with an IPv4-Translatable IPv6 address in the /64 - subnet, and the anycast semantic would not create confusion. We thus - decided to keep the null suffix for now. This issue does not exist - for prefixes larger than 32 bits, such as the /40, /56, /64 and /96 - prefixes that we recommend in Section 3.3. - -3.6. Choice of the Well-Known Prefix - - Before making our recommendation of the Well-Known Prefix, we were - faced with three choices: - o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC - 2765 Section 2.1; - o request IANA to allocate a /32 prefix, - o or request allocation of a new /96 prefix. - - We weighted the pros and cons of these choices before settling on the - recommended /96 Well-Known Prefix. - - The main advantage of the existing IPv4-mapped prefix is that it is - already defined. Reusing that prefix would require minimal - standardization efforts. However, being already defined is not just - an advantage, as there may be side effects of current - implementations. When presented with the IPv4-mapped prefix, current - versions of Windows and MacOS generate IPv4 packets, but will not - send IPv6 packets. If we used the IPv4-mapped prefix, these nodes - - - -Bao, et al. Expires October 11, 2010 [Page 12] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - would not be able to support translation without modification. This - will defeat the main purpose of the translation techniques. We thus - eliminated the first choice, and decided to not reuse the IPv4-mapped - prefix, ::FFFF:0:0/96. - - A /32 prefix would have allowed the embedded IPv4 address to fit - within the top 64 bits of the IPv6 address. This would have - facilitated routing and load balancing when an organization deploys - several translators. However, such destination-address based load - balancing may not be desirable. It is not compatible with STUN in - the deployments involving multiple stateful translators, each one - having a different pool of IPv4 addresses. STUN compatibility would - only be achieved if the translators managed the same pool of IPv4 - addresses and were able to coordinate their translation state, in - which case there is no big advantage to using a /32 prefix rather - than a /96 prefix. - - According to Section 2.2 of [RFC4291], in the legal textual - representations of IPv6 addresses, dotted decimal can only appear at - the end. The /96 prefix is compatible with that requirement. It - enables the dotted decimal notation without requiring an update to - [RFC4291]. This representation makes the address format easier to - use, and log files easier to read. - - The prefix that we recommend has the particularity of being "checksum - neutral". The sum of the hexadecimal numbers "0064" and "FF9B" is - "FFFF", i.e. a value equal to zero in one's complement arithmetic. - An IPv4-Embedded IPv6 address constructed with this prefix will have - the same one's complement checksum as the embedded IPv4 address. - - -4. Security Considerations - -4.1. Protection Against Spoofing - - By and large, IPv4/IPv6 translators can be modeled as special - routers, are subject to the same risks, and can implement the same - mitigations. There is however a particular risk that directly - derives from the practice of embedding IPv4 addresses in IPv6: - address spoofing. - - An attacker could use an IPv4-Embedded IPv6 address as the source - address of malicious packets. After translation, the packets will - appear as IPv4 packets from the specified source, and the attacker - may be hard to track. If left without mitigation, the attack would - allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses. - - The mitigation is to implement reverse path checks, and to verify - - - -Bao, et al. Expires October 11, 2010 [Page 13] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - throughout the network that packets are coming from an authorized - location. - -4.2. Secure Configuration - - The prefixes used for address translation are used by IPv6 nodes to - send packets to IPv6/IPv4 translators. Attackers could attempt to - fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong - values for these parameters, resulting in network disruption, denial - of service, and possible information disclosure. To mitigate such - attacks, network administrators need to ensure that prefixes are - configured in a secure way. - - The mechanisms for achieving secure configuration of prefixes are - beyond the scope of this document. - - -5. IANA Considerations - - The IANA is requested to add a note to the documentation of the - 0000::/8 address block in - http://www.iana.org/assignments/ipv6-address-space to document the - assignment by the IETF of the Well Known Prefix. For example: - - The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic - mapping between IPv4 to IPv6 addresses is defined out of the - 0000::/8 address block, per (this document). - - -6. Acknowledgements - - Many people in the Behave WG have contributed to the discussion that - led to this document, including Andrew Sullivan, Andrew Yourtchenko, - Brian Carpenter, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, - Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus - Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip - Matthews, Remi Denis-Courmont, Remi Despres and William Waites. - - Marcelo Bagnulo is partly funded by Trilogy, a research project - supported by the European Commission under its Seventh Framework - Program. - - -7. Contributors - - The following individuals co-authored drafts from which text has been - incorporated, and are listed in alphabetical order. - - - - -Bao, et al. Expires October 11, 2010 [Page 14] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - Congxiao Bao - CERNET Center/Tsinghua University - Room 225, Main Building, Tsinghua University - Beijing, 100084 - China - Phone: +86 62785983 - Email: congxiao@cernet.edu.cn - - Dave Thaler - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - USA - Phone: +1 425 703 8835 - Email: dthaler@microsoft.com - - Fred Baker - Cisco Systems - Santa Barbara, California 93117 - USA - Phone: +1-408-526-4257 - Fax: +1-413-473-2403 - Email: fred@cisco.com - - Hiroshi Miyata - Yokogawa Electric Corporation - 2-9-32 Nakacho - Musashino-shi, Tokyo 180-8750 - JAPAN - Email: h.miyata@jp.yokogawa.com - - Marcelo Bagnulo - Universidad Carlos III de Madrid - Av. Universidad 30 - Leganes, Madrid 28911 - ESPANA - Email: marcelo@it.uc3m.es - - Xing Li - CERNET Center/Tsinghua University - Room 225, Main Building, Tsinghua University - Beijing, 100084 - China - Phone: +86 62785983 - Email: xing@cernet.edu.cn - - - - - - -Bao, et al. Expires October 11, 2010 [Page 15] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. - -8.2. Informative References - - [I-D.ietf-behave-dns64] - Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, - "DNS64: DNS extensions for Network Address Translation - from IPv6 Clients to IPv4 Servers", - draft-ietf-behave-dns64-04 (work in progress), - December 2009. - - [I-D.ietf-behave-v6v4-framework] - Baker, F., Li, X., Bao, C., and K. Yin, "Framework for - IPv4/IPv6 Translation", - draft-ietf-behave-v6v4-framework-03 (work in progress), - October 2009. - - [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and - E. Lear, "Address Allocation for Private Internets", - BCP 5, RFC 1918, February 1996. - - [RFC3484] Draves, R., "Default Address Selection for Internet - Protocol version 6 (IPv6)", RFC 3484, February 2003. - - [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix - Reserved for Documentation", RFC 3849, July 2004. - - [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway - Protocol 4 (BGP-4)", RFC 4271, January 2006. - - [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", - BCP 153, RFC 5735, January 2010. - - - - - - - - - - - -Bao, et al. Expires October 11, 2010 [Page 16] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - -Authors' Addresses - - Congxiao Bao - CERNET Center/Tsinghua University - Room 225, Main Building, Tsinghua University - Beijing, 100084 - China - - Phone: +86 10-62785983 - Email: congxiao@cernet.edu.cn - - - Christian Huitema - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052-6399 - U.S.A. - - Email: huitema@microsoft.com - - - Marcelo Bagnulo - UC3M - Av. Universidad 30 - Leganes, Madrid 28911 - Spain - - Phone: +34-91-6249500 - Fax: - Email: marcelo@it.uc3m.es - URI: http://www.it.uc3m.es/marcelo - - - Mohamed Boucadair - France Telecom - 3, Av Francois Chateaux - Rennes 350000 - France - - Email: mohamed.boucadair@orange-ftgroup.com - - - - - - - - - - - -Bao, et al. Expires October 11, 2010 [Page 17] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010 - - - Xing Li - CERNET Center/Tsinghua University - Room 225, Main Building, Tsinghua University - Beijing, 100084 - China - - Phone: +86 10-62785983 - Email: xing@cernet.edu.cn - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bao, et al. Expires October 11, 2010 [Page 18] - - diff --git a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt b/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt deleted file mode 100644 index a6d80baa240..00000000000 --- a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt +++ /dev/null @@ -1,504 +0,0 @@ - - - -DNSEXT R. Bellis -Internet-Draft Nominet UK -Updates: 1035, 1123 March 22, 2010 -(if approved) -Intended status: Standards Track -Expires: September 23, 2010 - - - DNS Transport over TCP - Implementation Requirements - draft-ietf-dnsext-dns-tcp-requirements-03 - -Abstract - - This document updates the requirements for the support of TCP as a - transport protocol for DNS implementations. - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - 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 September 23, 2010. - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - - - -Bellis Expires September 23, 2010 [Page 1] - -Internet-Draft DNS over TCP March 2010 - - - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the BSD License. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 2. Terminology used in this document . . . . . . . . . . . . . . . 3 - - 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 4. Transport Protocol Selection . . . . . . . . . . . . . . . . . 4 - - 5. Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5 - - 6. Response re-ordering . . . . . . . . . . . . . . . . . . . . . 6 - - 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 - - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 - - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 - - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8 - - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 - - - - - - - - - - - - - - - - - -Bellis Expires September 23, 2010 [Page 2] - -Internet-Draft DNS over TCP March 2010 - - -1. Introduction - - Most DNS [RFC1035] transactions take place over UDP [RFC0768]. TCP - [RFC0793] is always used for zone transfers and is often used for - messages whose sizes exceed the DNS protocol's original 512 byte - limit. - - Section 6.1.3.2 of [RFC1123] states: - - DNS resolvers and recursive servers MUST support UDP, and SHOULD - support TCP, for sending (non-zone-transfer) queries. - - However, some implementors have taken the text quoted above to mean - that TCP support is an optional feature of the DNS protocol. - - The majority of DNS server operators already support TCP and the - default configuration for most software implementations is to support - TCP. The primary audience for this document is those implementors - whose failure to support TCP restricts interoperability and limits - deployment of new DNS features. - - This document therefore updates the core DNS protocol specifications - such that support for TCP is henceforth a REQUIRED part of a full DNS - protocol implementation. - - Whilst this document makes no specific recommendations to operators - of DNS servers, it should be noted that failure to support TCP (or - blocking of DNS over TCP at the network layer) may result in - resolution failure and/or application-level timeouts. - - -2. Terminology used in this document - - 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]. - - -3. Discussion - - In the absence of EDNS0 (see below) the normal behaviour of any DNS - server needing to send a UDP response that would exceed the 512 byte - limit is for the server to truncate the response so that it fits - within that limit and then set the TC flag in the response header. - When the client receives such a response it takes the TC flag as an - indication that it should retry over TCP instead. - - RFC 1123 also says: - - - -Bellis Expires September 23, 2010 [Page 3] - -Internet-Draft DNS over TCP March 2010 - - - - ... it is also clear that some new DNS record types defined in the - future will contain information exceeding the 512 byte limit that - applies to UDP, and hence will require TCP. Thus, resolvers and - name servers should implement TCP services as a backup to UDP - today, with the knowledge that they will require the TCP service - in the future. - - Existing deployments of DNSSEC [RFC4033] have shown that truncation - at the 512 byte boundary is now commonplace. For example an NXDOMAIN - (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155] - is almost invariably larger than 512 bytes. - - Since the original core specifications for DNS were written, the - Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced. - These extensions can be used to indicate that the client is prepared - to receive UDP responses larger than 512 bytes. An EDNS0 compatible - server receiving a request from an EDNS0 compatible client may send - UDP packets up to that client's announced buffer size without - truncation. - - However, transport of UDP packets that exceed the size of the path - MTU causes IP packet fragmentation, which has been found to be - unreliable in some circumstances. Many firewalls routinely block - fragmented IP packets, and some do not implement the algorithms - necessary to reassemble fragmented packets. Worse still, some - network devices deliberately refuse to handle DNS packets containing - EDNS0 options. Other issues relating to UDP transport and packet - size are discussed in [RFC5625]. - - The MTU most commonly found in the core of the Internet is around - 1500 bytes, and even that limit is routinely exceeded by DNSSEC - signed responses. - - The future that was anticipated in RFC 1123 has arrived, and the only - standardised UDP-based mechanism which may have resolved the packet - size issue has been found inadequate. - - -4. Transport Protocol Selection - - All general purpose DNS implementations MUST support both UDP and TCP - transport. - - o Authoritative server implementations MUST support TCP so that they - do not limit the size of responses. - - - - - -Bellis Expires September 23, 2010 [Page 4] - -Internet-Draft DNS over TCP March 2010 - - - o Recursive resolver (or forwarder) implementations MUST support TCP - so that the do not prevent large responses from a TCP-capable - server from reaching its TCP-capable clients. - o Stub resolver implementations (e.g. an operating system's DNS - resolution library) MUST support TCP since to do otherwise would - limit their interoperability with their own clients and with - upstream servers. - - An exception may be made for proprietary stub resolver - implementations. These MAY omit support for TCP if operating in an - environment where truncation can never occur, or where DNS lookup - failure is acceptable should truncation occur. - - Regarding the choice of when to use UDP or TCP, RFC 1123 says: - - ... a DNS resolver or server that is sending a non-zone-transfer - query MUST send a UDP query first. - - That requirement is hereby relaxed. A resolver SHOULD send a UDP - query first, but MAY elect to send a TCP query instead if it has good - reason to expect the response would be truncated if it were sent over - UDP (with or without EDNS0) or for other operational reasons, in - particular if it already has an open TCP connection to the server. - - -5. Connection Handling - - Section 4.2.2 of [RFC1035] says: - - If the server needs to close a dormant connection to reclaim - resources, it should wait until the connection has been idle for a - period on the order of two minutes. In particular, the server - should allow the SOA and AXFR request sequence (which begins a - refresh operation) to be made on a single connection. Since the - server would be unable to answer queries anyway, a unilateral - close or reset may be used instead of a graceful close. - - Other more modern protocols (e.g. HTTP [RFC2616]) have support for - persistent TCP connections and operational experience has shown that - long timeouts can easily cause resource exhaustion and poor response - under heavy load. Intentionally opening many connections and leaving - them dormant can trivially create a "denial of service" attack. - - This document therefore RECOMMENDS that the default application-level - idle period should be of the order of seconds, but does not specify - any particular value. In practise the idle period may vary - dynamically, and servers MAY allow dormant connections to remain open - for longer periods as resources permit. - - - -Bellis Expires September 23, 2010 [Page 5] - -Internet-Draft DNS over TCP March 2010 - - - To mitigate the risk of unintentional server overload, DNS clients - MUST take care to minimize the number of concurrent TCP connections - made to any individual server. Similarly servers MAY impose limits - on the number of concurrent TCP connections being handled for any - particular client. - - Further recommendations for the tuning of TCP stacks to allow higher - throughput or improved resiliency against denial of service attacks - are outside the scope of this document. - - -6. Response re-ordering - - RFC 1035 is ambiguous on the question of whether TCP queries may be - re-ordered - the only relevant text is in Section 4.2.1 which relates - to UDP: - - Queries or their responses may be reordered by the network, or by - processing in name servers, so resolvers should not depend on them - being returned in order. - - For the avoidance of future doubt, this requirement is clarified. - Client resolvers MUST be able to process responses which arrive in a - different order to that in which the requests were sent, regardless - of the transport protocol in use. - - -7. Security Considerations - - Some DNS server operators have expressed concern that wider use of - DNS over TCP will expose them to a higher risk of denial of service - (DoS) attacks. - - Although there is a higher risk of such attacks against TCP-enabled - servers, techniques for the mitigation of DoS attacks at the network - level have improved substantially since DNS was first designed. - - At the time of writing the vast majority of TLD authority servers and - all of the root name servers support TCP and the author knows of no - evidence to suggest that TCP-based DoS attacks against existing DNS - infrastructure are commonplace. - - That notwithstanding, readers are advised to familiarise themselves - with [CPNI-TCP]. - - Operators of recursive servers should ensure that they only accept - connections from expected clients, and do not accept them from - unknown sources. In the case of UDP traffic this will help protect - - - -Bellis Expires September 23, 2010 [Page 6] - -Internet-Draft DNS over TCP March 2010 - - - against reflector attacks [RFC5358] and in the case of TCP traffic it - will prevent an unknown client from exhausting the server's limits on - the number of concurrent connections. - - -8. IANA Considerations - - This document requests no IANA actions. - - -9. Acknowledgements - - The author would like to thank the document reviewers from the DNSEXT - Working Group, and in particular George Barwood, Alex Bligh, Alfred - Hoenes, Fernando Gont, Jim Reid, Paul Vixie and Nicholas Weaver. - - -10. References - -10.1. Normative References - - [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, - August 1980. - - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, - RFC 793, September 1981. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - -10.2. Informative References - - [CPNI-TCP] - CPNI, "Security Assessment of the Transmission Control - Protocol (TCP)", 2009, . - - [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., - Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext - - - -Bellis Expires September 23, 2010 [Page 7] - -Internet-Draft DNS over TCP March 2010 - - - Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - - [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive - Nameservers in Reflector Attacks", BCP 140, RFC 5358, - October 2008. - - [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", - BCP 152, RFC 5625, August 2009. - - -Appendix A. Change Log - - NB: to be removed by the RFC Editor before publication. - - draft-ietf-dnsext-dns-tcp-requirements-03 - Editorial nits from WGLC - Clarification on "general purpose" - Fixed ref to UDP (RFC 768) - Included more S.4.2.2 text from RFC 1035 and removed some from - this draft relating to connection resets. - s/long/large/ for packet sizes - - draft-ietf-dnsext-dns-tcp-requirements-02 - Change of title - more focus on implementation and not operation - Re-write of some of the security section - Added recommendation for minimal concurrent connections - Minor editorial nits from Alfred Hoenes - - draft-ietf-dnsext-dns-tcp-requirements-01 - Addition of response ordering section - Various minor editorial changes from WG reviewers - - draft-ietf-dnsext-dns-tcp-requirements-00 - Initial draft - - - - - - - - - -Bellis Expires September 23, 2010 [Page 8] - -Internet-Draft DNS over TCP March 2010 - - -Author's Address - - Ray Bellis - Nominet UK - Edmund Halley Road - Oxford OX4 4DQ - United Kingdom - - Phone: +44 1865 332211 - Email: ray.bellis@nominet.org.uk - URI: http://www.nominet.org.uk/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bellis Expires September 23, 2010 [Page 9] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt deleted file mode 100644 index 5ef96c42735..00000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt +++ /dev/null @@ -1,448 +0,0 @@ - - - -DNS Extensions Working Group S. Rose -Internet-Draft NIST -Updates: 2536, 2539, 3110, 4034, August 11, 2010 -4398, 5155, 5702, 5933 -(if approved) -Intended status: Standards Track -Expires: February 12, 2011 - - - Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA - Registry - draft-ietf-dnsext-dnssec-registry-fixes-06 - -Abstract - - The DNS Security Extensions (DNSSEC) requires the use of - cryptographic algorithm suites for generating digital signatures over - DNS data. There is currently an IANA registry for these algorithms - that is incomplete in that it lacks the implementation status of each - algorithm. This document provides an applicability statement on - algorithm status for DNSSEC implementations. This document replaces - that registry table with a new IANA registry table for Domain Name - System Security (DNSSEC) Algorithm Numbers which lists each - algorithm's status based on the current reference. If that status is - not defined in the original specification, this document assigns a - status. - -Status of This Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - 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. - - - - -Rose Expires February 12, 2011 [Page 1] - -Internet-Draft IANA Registry Fixes August 2010 - - - This Internet-Draft will expire on February 12, 2011. - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 - - 2. The DNS Security Algorithm Number Subregistry . . . . . . . . . 3 - 2.1. Individual Changes . . . . . . . . . . . . . . . . . . . . 3 - 2.2. Domain Name System (DNS) Security Algorithm Number - Registry Table . . . . . . . . . . . . . . . . . . . . . . 5 - 2.3. Specifying New Algorithms and Updating Status of - Existing Entries . . . . . . . . . . . . . . . . . . . . . 6 - - 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 - - 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - - 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 - 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 - - - - - - - - - - - - - - - -Rose Expires February 12, 2011 [Page 2] - -Internet-Draft IANA Registry Fixes August 2010 - - -1. Introduction - - The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033], - [RFC4034], and [RFC4035] uses digital signatures over DNS data to - provide source authentication and integrity protection. DNSSEC uses - an IANA registry to allocate codes for digital signature algorithms - (consisting of a cryptographic algorithm and one-way hash function). - - The original list of algorithm status is found in [RFC4034]. Other - DNSSEC documents have added new algorithms or changed the status of - algorithms in the registry. However, currently implementors must - read through all the documents in order to discover the current - status of each algorithm in the registry. - - This document replaces the current IANA registry for Domain Name - System Security (DNSSEC) Algorithm Numbers with a newly defined - registry table. This new table (Section 2.2 below) contains a column - that will list the current status of each digital signature algorithm - in the registry at the time of writing and assigns status for some - algorithms used with DNSSEC that did not have an identified status in - their specification. This document updates the following: [RFC2536], - [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and - [RFC5933]. - -1.1. Requirements Language - - 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]. - -2. The DNS Security Algorithm Number Subregistry - - The DNS Security Algorithm Number subregistry (part of the Domain - Name System (DNS) Security Number registry) will be replaced with the - table below. This table contains a column that contains the current - implementation requirements of the given algorithm. - - There are additional differences to entries that are described in - sub-section 2.1. The overall new registry table is in sub-section - 2.2. The values for the status were obtained from [RFC4034] with - updates for algorithms specified after the original DNSSEC - specification. If no status was listed in the original - specification, this document assigns one. - -2.1. Individual Changes - - This document changes three entries in the Domain Name System - Security (DNSSEC) Algorithm Registry. They are: - - - -Rose Expires February 12, 2011 [Page 3] - -Internet-Draft IANA Registry Fixes August 2010 - - - The description for assignment number 4 is changed to "Reserved until - 2020". - - The description for assignment number 9 is changed to "Reserved until - 2020". - - The description for assignment number 11 is changed to "Reserved - until 2020". - - Registry entries 13-251 remains Unassigned. - - The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are set to - RECOMMENDED and OPTIONAL respectively. The difference is due to the - fact that RSA/SHA-1 is REQUIRED and DSA/SHA-1 is only OPTIONAL. The - status of RSA/SHA-256 and RSA/SHA-512 are set to RECOMMENDED as it is - believed that these algorithms will replace older algorithms (e.g. - RSA/SHA-1) that have a perceived weakness in their hash algorithm - (SHA-1). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rose Expires February 12, 2011 [Page 4] - -Internet-Draft IANA Registry Fixes August 2010 - - -2.2. Domain Name System (DNS) Security Algorithm Number Registry Table - - The Domain Name System (DNS) Security Algorithm Number registry is - hereby specified as follows: - - Zone Transaction -Number Description Mnemonic Sign Sign Status Reference ------- ----------- ------ ---- ----- ------------ --------- - 0 Reserved [RFC4398] - 1 RSA/MD5 RSAMD5 N Y MUST NOT [RFC4034], - IMPLEMENT [RFC3110] - (this memo) - 2 Diffie-Hellman DH N Y [RFC2539] - (this memo) - 3 DSA/SHA-1 DSASHA1 Y Y [RFC2536], - [RFC4034], - FIPS 186-3, - FIPS 180-3 - (this memo) - 4 Reserved until ECC (this memo) - 2020 - 5 RSA/SHA-1 RSASHA1 Y Y REQUIRED [RFC4034] - (this memo) - 6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y [RFC5155] - -SHA1 (this memo) - 7 RSASHA1-NSEC3 RSASHA1- Y Y RECOMMENDED [RFC5155] - -SHA1 NSEC3- (this memo) - SHA1 - 8 RSA/SHA-256 RSASHA256 Y * RECOMMENDED [RFC5702] - (this memo) - 9 Reserved until (this memo) - 2020 - 10 RSA/SHA-512 RSASHA512 Y * RECOMMENDED [RFC5702] - (this memo) - 11 Reserved until (this memo) - 2020 - 12 GOST R GOST-ECC Y * [RFC5933] - 34.10-2001 (this memo) -13-251 Unassigned - 252 Reserved for INDIRECT N N [RFC4034] - Indirect keys (this memo) - 253 private PRIVATE Y Y [RFC4034] - algorithm (this memo) - 254 private PRIVATEOID Y Y [RFC4034] - algorithm OID (this memo) - 255 Reserved - - - - - -Rose Expires February 12, 2011 [Page 5] - -Internet-Draft IANA Registry Fixes August 2010 - - -2.3. Specifying New Algorithms and Updating Status of Existing Entries - - [I-D.ietf-dnsext-dnssec-alg-allocation] establishes a parallel - procedure for obtaining an algorithm number for new algorithms other - than a standards track document. Algorithms entered into the - registry using that procedure do not have a listed status. - Specifications that follow this path do not need to obsolete or - update this document. - - Adding a newly specified algorithm to the registry with a status - SHALL entail obsoleting this document and replacing the registry - table (with the new algorithm entry). Altering the status column - value of any existing algorithm in the registry SHALL entail - obsoleting this document and replacing the registry table. - - This document cannot be updated, only made obsolete and replaced by a - successor document. - -3. IANA Considerations - - This document replaces the Domain Name System (DNS) Security - Algorithm Numbers registry. The new registry table is in Section - 2.2. - - The original Domain Name System (DNS) Security Algorithm Number - registry is available at http://www.iana.org/assignments/ - dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml. - -4. Security Considerations - - This document replaces the Domain Name System (DNS) Security - Algorithm Numbers registry. It is not meant to be a discussion on - algorithm superiority. No new security considerations are raised in - this document. - -5. References - -5.1. Normative References - - [I-D.ietf-dnsext-dnssec-alg-allocation] Hoffman, P., "Cryptographic - Algorithm Identifier - Allocation for DNSSEC", draf - t-ietf-dnsext-dnssec-alg- - allocation-03 (work in - progress), March 2010. - - [RFC2119] Bradner, S., "Key words for - use in RFCs to Indicate - - - -Rose Expires February 12, 2011 [Page 6] - -Internet-Draft IANA Registry Fixes August 2010 - - - Requirement Levels", BCP 14, - RFC 2119, March 1997. - - [RFC2536] Eastlake, D., "DSA KEYs and - SIGs in the Domain Name - System (DNS)", RFC 2536, - March 1999. - - [RFC2539] Eastlake, D., "Storage of - Diffie-Hellman Keys in the - Domain Name System (DNS)", - RFC 2539, March 1999. - - [RFC3110] Eastlake, D., "RSA/SHA-1 - SIGs and RSA KEYs in the - Domain Name System (DNS)", - RFC 3110, May 2001. - - [RFC4033] Arends, R., Austein, R., - Larson, M., Massey, D., and - S. Rose, "DNS Security - Introduction and - Requirements", RFC 4033, - March 2005. - - [RFC4034] Arends, R., Austein, R., - Larson, M., Massey, D., and - S. Rose, "Resource Records - for the DNS Security - Extensions", RFC 4034, - March 2005. - - [RFC4035] Arends, R., Austein, R., - Larson, M., Massey, D., and - S. Rose, "Protocol - Modifications for the DNS - Security Extensions", - RFC 4035, March 2005. - - [RFC4398] Josefsson, S., "Storing - Certificates in the Domain - Name System (DNS)", - RFC 4398, March 2006. - - [RFC5155] Laurie, B., Sisson, G., - Arends, R., and D. Blacka, - "DNS Security (DNSSEC) - Hashed Authenticated Denial - - - -Rose Expires February 12, 2011 [Page 7] - -Internet-Draft IANA Registry Fixes August 2010 - - - of Existence", RFC 5155, - March 2008. - - [RFC5702] Jansen, J., "Use of SHA-2 - Algorithms with RSA in - DNSKEY and RRSIG Resource - Records for DNSSEC", - RFC 5702, October 2009. - - [RFC5933] Dolmatov, V., Chuprina, A., - and I. Ustinov, "Use of GOST - Signature Algorithms in - DNSKEY and RRSIG Resource - Records for DNSSEC", - RFC 5933, July 2010. - -5.2. Informative References - - [FIPS.180-3.2008] National Institute of - Standards and Technology, - "Secure Hash Standard", - FIPS PUB 180-3, - October 2008, . - - [FIPS.186-3.2009] National Institute of - Standards and Technology, - "Digital Signature - Standard", FIPS PUB 186-3, - June 2009, . - -Author's Address - - Scott Rose - NIST - 100 Bureau Dr. - Gaithersburg, MD 20899 - USA - - Phone: +1-301-975-8439 - EMail: scottr.nist@gmail.com - - - - - -Rose Expires February 12, 2011 [Page 8] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-08.txt b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-08.txt new file mode 100644 index 00000000000..15e51522fcb --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-08.txt @@ -0,0 +1,448 @@ + + + +DNS Extensions Working Group S. Rose +Internet-Draft NIST +Updates: 2536, 2539, 3110, 4034, 4398, May 26, 2011 +5155, 5702, 5933 (if approved) +Intended status: Standards Track +Expires: November 27, 2011 + + + Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA + Registry + draft-ietf-dnsext-dnssec-registry-fixes-08 + +Abstract + + The DNS Security Extensions (DNSSEC) requires the use of + cryptographic algorithm suites for generating digital signatures over + DNS data. There is currently an IANA registry for these algorithms + that is incomplete in that it lacks the implementation status of each + algorithm. This document provides an applicability statement on + algorithm implementation compliance status for DNSSEC + implementations. This status is to measure compliance to this RFC + only. This document replaces that registry table with a new IANA + registry table for Domain Name System Security (DNSSEC) Algorithm + Numbers that lists (or assigns) each algorithm's status based on the + current reference. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + 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." + + This Internet-Draft will expire on November 27, 2011. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + + + +Rose Expires November 27, 2011 [Page 1] + +Internet-Draft IANA Registry Fixes May 2011 + + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 + + 2. The DNS Security Algorithm Number Sub-registry . . . . . . . . 3 + 2.1. Updates and Additions . . . . . . . . . . . . . . . . . . . 4 + 2.2. Domain Name System (DNS) Security Algorithm Number + Registry Table . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Specifying New Algorithms and Updating Status of + Existing Entries . . . . . . . . . . . . . . . . . . . . . 6 + + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + + 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + + 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 + + + + + + + + + + + + + + + + + + + + + + + + +Rose Expires November 27, 2011 [Page 2] + +Internet-Draft IANA Registry Fixes May 2011 + + +1. Introduction + + The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033], + [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702] uses + digital signatures over DNS data to provide source authentication and + integrity protection. DNSSEC uses an IANA registry to list codes for + digital signature algorithms (consisting of a cryptographic algorithm + and one-way hash function). + + The original list of algorithm status is found in [RFC4034]. Other + DNSSEC RFC's have added new algorithms or changed the status of + algorithms in the registry. However, implementers must read through + all the documents in order to discover which algorithms are + considered wise to implement, which are not, and which algorithms may + become widely used in the future. This document replaces the + original list with a new table that includes the current compliance + status for certain algorithms. + + This compliance status indication is only to be considered for + implementation, not deployment or operations. Operators are free to + deploy any digital signature algorithm available in implementations + or algorithms chosen by local security policies. This status is to + measure compliance to this RFC only. + + This document replaces the current IANA registry for Domain Name + System Security (DNSSEC) Algorithm Numbers with a newly defined + registry table. This new table (Section 2.2 below) contains a column + that will list the current compliance status of each digital + signature algorithm in the registry at the time of writing and + assigns status for some algorithms used with DNSSEC that did not have + an identified status in their specification. This document updates + the following: [RFC2536], [RFC2539], [RFC3110], [RFC4034], [RFC4398], + [RFC5155], [RFC5702], and [RFC5933]. + +1.1. Requirements Language + + 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]. + +2. The DNS Security Algorithm Number Sub-registry + + The DNS Security Algorithm Number sub-registry (part of the Domain + Name System (DNS) Security Number registry) will be replaced with the + table below. This table is based on the existing DNS Security + Algorithm Number sub-registry and adds a column that contains the + current implementation status of the given algorithm. + + + + +Rose Expires November 27, 2011 [Page 3] + +Internet-Draft IANA Registry Fixes May 2011 + + + There are additional differences to entries that are described in + sub-section 2.1. The overall new registry table is in sub-section + 2.2. The values for the compliance status were obtained from + [RFC4034] with updates for algorithms specified after the original + DNSSEC specification. If no status was listed in the original + specification, this document assigns one. + +2.1. Updates and Additions + + This document updates three entries in the Domain Name System + Security (DNSSEC) Algorithm Registry. They are: + + The description for assignment number 4 is changed to "Reserved until + 2020". + + The description for assignment number 9 is changed to "Reserved until + 2020". + + The description for assignment number 11 is changed to "Reserved + until 2020". + + Registry entries 13-251 remains Unassigned. + + The status of RSASHA1-NSEC3-SHA1 is set to RECOMMENDED TO IMPLEMENT. + This is due to the fact that RSA/SHA-1 is a MUST IMPLEMENT. The + status of RSA/SHA-256 and RSA/SHA-512 are also set to RECOMMENDED TO + IMPLEMENT as it is believed that these algorithms will replace an + older algorithm (e.g. RSA/SHA-1) that have a perceived weakness in + its hash algorithm (SHA-1). + + + + + + + + + + + + + + + + + + + + + + +Rose Expires November 27, 2011 [Page 4] + +Internet-Draft IANA Registry Fixes May 2011 + + +2.2. Domain Name System (DNS) Security Algorithm Number Registry Table + + The Domain Name System (DNS) Security Algorithm Number registry is + hereby specified as follows below. The new column is titled + "Compliance to RFC TBD" (where TBD will change when published) as the + IANA Registry table is not normative. The IANA registry table is + only a reflection of the RFC, which is normative. + + Trans- + Zone action Compliance to + Number Description Mnemonic Sign Sign RFC TBD1 Reference + ------ ----------- ------ ---- ----- ------------ --------- + 0 Reserved [RFC4398] + 1 RSA/MD5 RSAMD5 N Y MUST NOT [RFC2537] + IMPLEMENT + 2 Diffie-Hellman DH N Y [RFC2539] + 3 DSA/SHA-1 DSASHA1 Y Y [RFC2536] + 4 Reserved until + 2020 + 5 RSA/SHA-1 RSASHA1 Y Y MUST [RFC3110] + IMPLEMENT + 6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y [RFC5155] + -SHA1 + 7 RSASHA1-NSEC3 RSASHA1- Y Y RECOMMENDED [RFC5155] + -SHA1 NSEC3- TO IMPLEMENT + SHA1 + 8 RSA/SHA-256 RSASHA256 Y * RECOMMENDED [RFC5702] + TO IMPLEMENT + 9 Reserved until + 2020 + 10 RSA/SHA-512 RSASHA512 Y * RECOMMENDED [RFC5702] + TO IMPLEMENT + 11 Reserved until + 2020 + 12 GOST R GOST-ECC Y * [RFC5933] + 34.10-2001 + 13-251 Unassigned + 252 Reserved for INDIRECT N N [RFC4034] + Indirect keys + 253 private PRIVATE Y Y [RFC4034] + algorithm + 254 private PRIVATEOID Y Y [RFC4034] + algorithm OID + 255 Reserved + + Table rows where the compliance column is not filled in are left to + the discretion of implementers. Their implementation (or lack + thereof) therefore cannot be included when judging compliance to this + + + +Rose Expires November 27, 2011 [Page 5] + +Internet-Draft IANA Registry Fixes May 2011 + + + document. + +2.3. Specifying New Algorithms and Updating Status of Existing Entries + + [RFC6014] establishes a parallel procedure for adding a registry + entry for a new algorithm other than a standards track document. + Algorithms entered into the registry using that procedure do not have + a listed compliance status. Specifications that follow this path do + not need to obsolete or update this document. + + Adding a newly specified algorithm to the registry with a compliance + status SHALL entail obsolescing this document and replacing the + registry table (with the new algorithm entry). Altering the status + column value of any existing algorithm in the registry SHALL entail + obsoleting this document and replacing the registry table. + + This document cannot be updated, only made obsolete and replaced by a + successor document. + +3. IANA Considerations + + This document replaces the Domain Name System (DNS) Security + Algorithm Numbers registry. The new registry table is in Section + 2.2. In the column "Compliance to RFC TBD", "RFC TBD" should be + changed to the official RFC when published. + + The original Domain Name System (DNS) Security Algorithm Number + registry is available at + http://www.iana.org/assignments/dns-sec-alg-numbers. + +4. Security Considerations + + This document replaces the Domain Name System (DNS) Security + Algorithm Numbers registry. It is not meant to be a discussion on + algorithm superiority. No new security considerations are raised in + this document. + +5. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name + System (DNS)", RFC 2537, March 1999. + + + + +Rose Expires November 27, 2011 [Page 6] + +Internet-Draft IANA Registry Fixes May 2011 + + + [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name + System (DNS)", RFC 4398, March 2006. + + [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer + (DS) Resource Records (RRs)", RFC 4509, May 2006. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + + [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY + and RRSIG Resource Records for DNSSEC", RFC 5702, + October 2009. + + [RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST + Signature Algorithms in DNSKEY and RRSIG Resource Records + for DNSSEC", RFC 5933, July 2010. + + [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier + Allocation for DNSSEC", RFC 6014, November 2010. + + + + + + + + + + + + + +Rose Expires November 27, 2011 [Page 7] + +Internet-Draft IANA Registry Fixes May 2011 + + +Author's Address + + Scott Rose + NIST + 100 Bureau Dr. + Gaithersburg, MD 20899 + USA + + Phone: +1-301-975-8439 + EMail: scottr.nist@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Expires November 27, 2011 [Page 8] + diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/doc/draft/draft-ietf-dnsext-ecc-key-10.txt similarity index 66% rename from doc/draft/draft-ietf-dnsext-ecc-key-07.txt rename to doc/draft/draft-ietf-dnsext-ecc-key-10.txt index 2cdcdb16c92..db0aa3a989c 100644 --- a/doc/draft/draft-ietf-dnsext-ecc-key-07.txt +++ b/doc/draft/draft-ietf-dnsext-ecc-key-10.txt @@ -1,12 +1,13 @@ -INTERNET-DRAFT ECC Keys in the DNS -Expires: January 2006 July 2005 +INTERNET-DRAFT Richard C. Schroeppel +Intended status: Proposed Standard Donald E. Eastlake 3rd +Expires: August 2007 March 2007 - Elliptic Curve KEYs in the DNS - -------- ----- ---- -- --- --- - + Elliptic Curve Keys and Signatures in the Domain Name System (DNS) + -------- ----- ---- --- ---------- -- --- ------ ---- ------ ----- + Richard C. Schroeppel Donald Eastlake 3rd @@ -19,7 +20,6 @@ Status of This Document have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. - 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 . @@ -31,7 +31,7 @@ Status of This Document 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." + 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/1id-abstracts.html @@ -42,13 +42,13 @@ Status of This Document Abstract - The standard method for storing elliptic curve cryptographic keys and - signatures in the Domain Name System is specified. + The standard format for storing elliptic curve cryptographic keys and + elliptic curve SHA-1 based signatures in the Domain Name System (DNS) + is specified. + -Copyright Notice - Copyright (C) The Internet Society (2005). All Rights Reserved. @@ -57,7 +57,7 @@ Copyright Notice R. Schroeppel, et al [Page 1] -INTERNET-DRAFT ECC Keys in the DNS +INTERNET-DRAFT ECC in the DNS Acknowledgement @@ -71,27 +71,27 @@ 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 + 2. Elliptic Curve Keys in Resource Records.................3 3. The Elliptic Curve Equation.............................9 4. How do I Compute Q, G, and Y?..........................10 - 5. Elliptic Curve SIG Resource Records....................11 + 5. Elliptic Curve Signatures..............................11 6. Performance Considerations.............................13 7. Security Considerations................................13 8. IANA Considerations....................................13 - Copyright and Disclaimer..................................14 + + Copyright and Additional IPR Provisions...................14 Informational References..................................15 Normative Refrences.......................................15 Author's Addresses........................................16 Expiration and File Name..................................16 - + Disclaimer................................................16 @@ -115,33 +115,33 @@ Table of Contents R. Schroeppel, et al [Page 2] -INTERNET-DRAFT ECC Keys in the DNS +INTERNET-DRAFT ECC 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 4033, 4034, - 4035]. + other information. [RFC1034] [RFC1035] The DNS stores data in + resource records and has been extended to include digital signatures + and cryptographic keys in some of these resource records. - This document describes how to store elliptic curve cryptographic - (ECC) keys and signatures in the DNS so they can be used for a - variety of security purposes. Familiarity with ECC cryptography is - assumed [Menezes]. + This document describes how to format elliptic curve cryptographic + (ECC) key and signature data in the DNS so they can be used for a + variety of purposes. The signatures use the SHA-1 eigest algorithm + [RFC3174]. 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]. + document are to be interpreted as described in [RFC2119]. -2. Elliptic Curve Data in Resource Records +2. Elliptic Curve Keys in Resource Records - Elliptic curve public keys are stored in the DNS within the RDATA - portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the - structure shown below. + Elliptic curve public keys are stored, using the structure described + below, in the DNS within the RDATA portions of key RRs, such as RRKEY + [RFC4034] and IPSECKEY [RFC4025] RRs. 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 @@ -173,7 +173,7 @@ INTERNET-DRAFT ECC Keys in the DNS R. Schroeppel, et al [Page 3] -INTERNET-DRAFT ECC Keys in the DNS +INTERNET-DRAFT ECC 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 @@ -231,7 +231,7 @@ INTERNET-DRAFT ECC Keys in the DNS R. Schroeppel, et al [Page 4] -INTERNET-DRAFT ECC Keys in the DNS +INTERNET-DRAFT ECC in the DNS +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -289,7 +289,7 @@ INTERNET-DRAFT ECC Keys in the DNS R. Schroeppel, et al [Page 5] -INTERNET-DRAFT ECC Keys in the DNS +INTERNET-DRAFT ECC in the DNS A = 1 When P>=5, the curve parameter A is negated. If P=2, then @@ -347,7 +347,7 @@ INTERNET-DRAFT ECC Keys in the DNS R. Schroeppel, et al [Page 6] -INTERNET-DRAFT ECC Keys in the DNS +INTERNET-DRAFT ECC in the DNS determining the bit position of the left most 1-bit in the F data @@ -372,7 +372,7 @@ INTERNET-DRAFT ECC Keys in the DNS 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 + 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. @@ -405,7 +405,7 @@ INTERNET-DRAFT ECC Keys in the DNS R. Schroeppel, et al [Page 7] -INTERNET-DRAFT ECC Keys in the DNS +INTERNET-DRAFT ECC in the DNS values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + @@ -463,7 +463,7 @@ INTERNET-DRAFT ECC Keys in the DNS R. Schroeppel, et al [Page 8] -INTERNET-DRAFT ECC Keys in the DNS +INTERNET-DRAFT ECC in the DNS LA,A is the first parameter of the elliptic curve equation. @@ -489,7 +489,7 @@ INTERNET-DRAFT ECC Keys in the DNS 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 + 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. @@ -521,7 +521,7 @@ INTERNET-DRAFT ECC Keys in the DNS R. Schroeppel, et al [Page 9] -INTERNET-DRAFT ECC Keys in the DNS +INTERNET-DRAFT ECC in the DNS commonly used. @@ -539,7 +539,7 @@ INTERNET-DRAFT ECC Keys in the DNS 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 + 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. @@ -547,7 +547,7 @@ INTERNET-DRAFT ECC Keys in the DNS Q * G = the point at infinity (on the elliptic curve) - G may be chosen by selecting a random [RFC 1750] curve point, and + G may be chosen by selecting a random [RFC4086] 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. @@ -566,7 +566,7 @@ INTERNET-DRAFT ECC Keys in the DNS 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 + 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. @@ -579,10 +579,10 @@ INTERNET-DRAFT ECC Keys in the DNS R. Schroeppel, et al [Page 10] -INTERNET-DRAFT ECC Keys in the DNS +INTERNET-DRAFT ECC in the DNS - During the key generation process, a random [RFC 1750] number X must + During the key generation process, a random [RFC4086] 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 @@ -597,11 +597,11 @@ INTERNET-DRAFT ECC Keys in the DNS -5. Elliptic Curve SIG Resource Records +5. Elliptic Curve Signatures - The signature portion of an RR RDATA area when using the EC - algorithm, for example in the RRSIG and SIG [RFC records] RRs is - shown below. + The signature portion of an RR RDATA area when using the ECC + algorithm, for example in the SIG and RRSIG [RFC4034] RRs is shown + below. 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 @@ -613,178 +613,178 @@ INTERNET-DRAFT ECC Keys in the DNS R and S are integers (mod Q). Their length is specified by the LQ field of the corresponding KEY RR and can also be calculated from the - SIG RR's RDLENGTH. They are right justified, high-order-octet first. + SIG RR$s RDLENGTH. They are right justified, high-order-octet first. The same conditional formula for calculating the length from LQ is used as for all the other length fields above. - The data signed is determined as specified in [RFC 2535]. Then the + The data signed is determined as specified in [RFC4034]. Then the following steps are taken where Q, P, G, and Y are as specified in - the public key [Schneier]: + the public key [Schneier]. For further information on SHA-1, see + [RFC3174]. - hash = SHA-1 ( data ) + hash = SHA-1 ( data ) - Generate random [RFC 4086] K such that 0 < K < Q. (Never sign two - different messages with the same K. K should be chosen from a - very large space: If an opponent learns a K value for a single - signature, the user's signing key is compromised, and a forger - can sign arbitrary messages. There is no harm in signing the - same message multiple times with the same key or different - keys.) + Generate random [RFC4086] K such that 0 < K < Q. (Never sign + two different messages with the same K. K should be chosen + from a very large space: If an opponent learns a K value + for a single signature, the user$s signing key is + compromised, and a forger can sign arbitrary messages. + There is no harm in signing the same message multiple times + with the same key or different keys.) - R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted R. Schroeppel, et al [Page 11] -INTERNET-DRAFT ECC Keys in the DNS +INTERNET-DRAFT ECC in the DNS - as an integer, and reduced (mod Q). (R must not be 0. In - this astronomically unlikely event, generate a new random K - and recalculate R.) + R = (the W-coordinate of ( K*G on the elliptic curve )) + interpreted as an integer, and reduced (mod Q). (R must + not be 0. In this astronomically unlikely event, generate + a new random K and recalculate R.) - S = ( K^(-1) * (hash + X*R) ) mod Q. + S = ( K^(-1) * (hash + X*R) ) mod Q. - S must not be 0. In this astronomically unlikely event, generate a - new random K and recalculate R and S. + S must not be 0. In this astronomically unlikely event, + generate a new random K and recalculate R and S. - If S > Q/2, set S = Q - S. + If S > Q/2, set S = Q - S. - The pair (R,S) is the signature. + The pair (R,S) is the signature. - Another party verifies the signature as follows: + Another party verifies the signature as follows. For further + information on SHA-1, see [RFC3174]. - Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a - valid EC sigature. + Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a + valid EC sigature. - hash = SHA-1 ( data ) + hash = SHA-1 ( data ) - Sinv = S^(-1) mod Q. + Sinv = S^(-1) mod Q. - U1 = (hash * Sinv) mod Q. + U1 = (hash * Sinv) mod Q. - U2 = (R * Sinv) mod Q. + U2 = (R * Sinv) mod Q. - (U1 * G + U2 * Y) is computed on the elliptic curve. + (U1 * G + U2 * Y) is computed on the elliptic curve. - V = (the W-coordinate of this point) interpreted as an integer - and reduced (mod Q). + V = (the W-coordinate of this point) interpreted as an integer + and reduced (mod Q). - The signature is valid if V = R. + The signature is valid if V = R. - The reason for requiring S < Q/2 is that, otherwise, both (R,S) and - (R,Q-S) would be valid signatures for the same data. Note that a - signature that is valid for hash(data) is also valid for - hash(data)+Q or hash(data)-Q, if these happen to fall in the range - [0,2^160-1]. It's believed to be computationally infeasible to - find data that hashes to an assigned value, so this is only a - cosmetic blemish. The blemish can be eliminated by using Q > - 2^160, at the cost of having slightly longer signatures, 42 octets - instead of 40. + The reason for requiring S < Q/2 is that, otherwise, both (R,S) and + (R,Q-S) would be valid signatures for the same data. Note that a + signature that is valid for hash(data) is also valid for hash(data)+Q + or hash(data)-Q, if these happen to fall in the range [0,2^160-1]. + It$s believed to be computationally infeasible to find data that + hashes to an assigned value, so this is only a cosmetic blemish. The + blemish can be eliminated by using Q > 2^160, at the cost of having + slightly longer signatures, 42 octets instead of 40. - We must specify how a field-element E ("the W-coordinate") is to be - interpreted as an integer. The field-element E is regarded as a - radix-P integer, with the digits being the coefficients in the - polynomial basis representation of E. The digits are in the ragne - [0,P-1]. In the two most common cases, this reduces to "the - obvious thing". In the (mod P) case, E is simply a residue mod P, - and is taken as an integer in the range [0,P-1]. In the GF[2^D] + We must specify how a field-element E ("the W-coordinate") is to be + interpreted as an integer. The field-element E is regarded as a + radix-P integer, with the digits being the coefficients in the + polynomial basis representation of E. The digits are in the ragne + [0,P-1]. In the two most common cases, this reduces to "the obvious + thing". In the (mod P) case, E is simply a residue mod P, and is R. Schroeppel, et al [Page 12] -INTERNET-DRAFT ECC Keys in the DNS - - - case, E is in the D-bit polynomial basis representation, and is - simply taken as an integer in the range [0,(2^D)-1]. For other - fields GF[P^D], it's necessary to do some radix conversion - arithmetic. - - +INTERNET-DRAFT ECC in the DNS - 6. 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. + taken as an integer in the range [0,P-1]. In the GF[2^D] case, E is + in the D-bit polynomial basis representation, and is simply taken as + an integer in the range [0,(2^D)-1]. For other fields GF[P^D], it$s + necessary to do some radix conversion arithmetic. - 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. Performance Considerations - 7. Security 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. - 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. + 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 [RFC2671]. + 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. - Some specific key generation considerations are given in the body - of this document. +7. Security Considerations - 8. IANA 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. [RFC4033] [RFC4034] [RFC4035] As with all + cryptographic algorithms, evaluating the necessary strength of the + key is essential and dependent on local policy. - The key and signature data structures defined herein correspond to - the value 4 in the Algorithm number field of the IANA registry + Some specific key generation considerations are given in the body of + this document. - Assignment of meaning to the remaining ECC data flag bits or to - values of ECC fields outside the ranges for which meaning in - defined in this document requires an IETF consensus as defined in - [RFC 2434]. - - - - - -R. Schroeppel, et al [Page 13] - -INTERNET-DRAFT ECC Keys in the DNS +8. IANA Considerations - Copyright and Disclaimer + Assignment of meaning to the remaining ECC data flag bits or to + values of ECC fields outside the ranges for which meaning in defined + in this document requires an IETF consensus as defined in [RFC2434]. - Copyright (C) The Internet Society 2005. This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - 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 13] + +INTERNET-DRAFT ECC in the DNS +Copyright and Additional IPR Provisions + 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. + Copyright (C) The IETF Trust (2007) + 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. @@ -811,104 +811,104 @@ INTERNET-DRAFT ECC Keys in the DNS R. Schroeppel, et al [Page 14] -INTERNET-DRAFT ECC Keys in the DNS - - - Informational References +INTERNET-DRAFT ECC in the DNS - [RFC 1034] - P. Mockapetris, "Domain names - concepts and - facilities", 11/01/1987. - [RFC 1035] - P. Mockapetris, "Domain names - implementation and - specification", 11/01/1987. +Informational References - [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", - August 1999. + [RFC1034] - P. Mockapetris, "Domain names - concepts and facilities", + 11/01/1987. - [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and - S. Rose, "DNS Security Introduction and Requirements", RFC 4033, - March 2005. + [RFC1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. - [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and - S. Rose, "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. + [RFC2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August + 1999. - [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, - "Randomness Requirements for Security", BCP 106, RFC 4086, June - 2005. + [RFC4025] - M. Richardson, "A Method for Storing IPsec Keying + Material in DNS", February 2005. - [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C", 1996, John Wiley and Sons + [RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC 4033, March + 2005. - [Menezes] - Alfred Menezes, "Elliptic Curve Public Key - Cryptosystems", 1993 Kluwer. + [RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. - [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic - Curves", 1986, Springer Graduate Texts in mathematics #106. + [RFC4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. + [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. - Normative Refrences + [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", + 1986, Springer Graduate Texts in mathematics #106. - [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 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and - S. Rose, "Resource Records for the DNS Security Extensions", RFC - 4034, March 2005. +Normative Refrences + [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + [RFC2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", October 1998. + [RFC3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm + 1 (SHA1)", RFC 3174, September 2001. + [RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. R. Schroeppel, et al [Page 15] -INTERNET-DRAFT ECC Keys in the DNS - - - Author's Addresses - - Rich Schroeppel - 500 S. Maple Drive - Woodland Hills, UT 84653 USA - - Telephone: +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-786-7554 (w) - EMail: Donald.Eastlake@motorola.com - +INTERNET-DRAFT ECC in the DNS - Expiration and File Name +Author's Addresses - This draft expires in January 2006. + Rich Schroeppel + 500 S. Maple Drive + Woodland Hills, UT 84653 USA - Its file name is draft-ietf-dnsext-ecc-key-07.txt. + Telephone: +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-786-7554 (w) + EMail: Donald.Eastlake@motorola.com +Expiration and File Name + This draft expires in September 2007. + Its file name is draft-ietf-dnsext-ecc-key-10.txt. +Disclaimer + 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, THE IETF TRUST 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. diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-05.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-05.txt deleted file mode 100644 index a46655affe0..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-05.txt +++ /dev/null @@ -1,728 +0,0 @@ - - - -DNSEXT Working Group J. Damas -Internet-Draft M. Graff -Obsoletes: 2671, 2673 P. Vixie -(if approved) Internet Systems Consortium -Intended status: Standards Track March 7, 2011 -Expires: September 8, 2011 - - - Extension Mechanisms for DNS (EDNS0) - draft-ietf-dnsext-rfc2671bis-edns0-05 - -Abstract - - The Domain Name System's wire protocol includes a number of fixed - fields whose range has been or soon will be exhausted and does not - allow requestors to advertise their capabilities to responders. This - document describes backward compatible mechanisms for allowing the - protocol to grow. - - This document updates the EDNS0 specification [RFC2671] based on 10 - years of deployment experience. - -Status of this Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - 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." - - This Internet-Draft will expire on September 8, 2011. - -Copyright Notice - - Copyright (c) 2011 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - - - -Damas, et al. Expires September 8, 2011 [Page 1] - -Internet-Draft EDNS0 Extensions March 2011 - - - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 - 4. DNS Message changes . . . . . . . . . . . . . . . . . . . . . 4 - 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 4 - 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 - 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 - 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 - 6. The OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 5 - 6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 5 - 6.2. OPT Record Wire Format . . . . . . . . . . . . . . . . . . 5 - 6.3. Cache behaviour . . . . . . . . . . . . . . . . . . . . . 7 - 6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 6.5. Requestor's Payload Size . . . . . . . . . . . . . . . . . 7 - 6.6. Responder's Payload Size . . . . . . . . . . . . . . . . . 7 - 6.7. Payload Size Selection . . . . . . . . . . . . . . . . . . 8 - 6.8. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 8 - 6.9. OPT Record TTL Field Use . . . . . . . . . . . . . . . . . 8 - 6.10. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 6.11. OPT Options Code Allocation Procedure . . . . . . . . . . 9 - 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 10 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - Appendix A. Document Editing History . . . . . . . . . . . . . . 11 - Appendix A.1. Changes since RFC2671 . . . . . . . . . . . . . . . 11 - Appendix A.2. Changes since -02 . . . . . . . . . . . . . . . . . 12 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 - - - - - - - - - - - - -Damas, et al. Expires September 8, 2011 [Page 2] - -Internet-Draft EDNS0 Extensions March 2011 - - -1. Introduction - - DNS [RFC1035] specifies a Message Format and within such messages - there are standard formats for encoding options, errors, and name - compression. The maximum allowable size of a DNS Message is limited - to 512 bytes. Many of DNS's protocol limits are too small for uses - which are commom or desired to become common. RFC 1035 does not - define any way for implementations to advertise their capabilities. - - [RFC2671] added extension mechanism to DNS, this mechanism is widely - supported and number of new DNS uses and protocol extensions depend - on the presence of these extensions. This memo refines that - specification and obsoletes [RFC2671]. - - Unextended agents will not know how to interpret the protocol - extensions defined in [RFC2671] and restated here. Extended agents - must be prepared for handling the interactions with unextended - clients in the face of new protocol elements, and fall back - gracefully to unextended DNS. [RFC2671] proposed extensions to the - basic DNS protocol to overcome these deficiencies. This memo refines - that specification and obsoletes [RFC2671]. - - [RFC2671] specified extended label types. The only one proposed was - in RFC2673 for a label type called "Bitstring Labels." For various - reasons introducing a new label type was found to be extremely - difficult, and RFC2673 was moved to Experimental. This document - Obsoletes Extended Labels. - - -2. Terminology - - "Requestor" is the side which sends a request. "Responder" is an - authoritative, recursive resolver, or other DNS component which - responds to questions. - - 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]. - - -3. EDNS Support Requirement - - EDNS support is practically mandatory in a modern world. DNSSEC - requires EDNS support, and many other features are made possible only - by EDNS support to request or advertise them. Many organizations are - requiring DNSSEC. Without common interoperability, DNSSEC cannot be - as easily deployed. - - - - -Damas, et al. Expires September 8, 2011 [Page 3] - -Internet-Draft EDNS0 Extensions March 2011 - - - DNS publishers are wanting to put more data in answers. DNSSEC - DNSKEY records, negative answers, and many other DNSSEC queries cause - larger answers to be returned. In order to support this, DNS - servers, middleware, and stub resolvers MUST support larger packet - sizes advertised via EDNS0. - - -4. DNS Message changes - -4.1. Message Header - - The DNS Message Header's second full 16-bit word is divided into a - 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see , - section 4.1.1 [RFC1035]). Some of these were marked for future use, - and most these have since been allocated. Also, most of the RCODE - values are now in use. The OPT pseudo-RR specified below contains - extensions to the RCODE bit field as well as additional flag bits. - -4.2. Label Types - - The first two bits of a wire format domain label are used to denote - the type of the label. [RFC1035] allocates two of the four possible - types and reserves the other two. More label types were defined in - [RFC2671]. This document obsoletes the use of the 2-bit combination - defined by [RFC2671] to identify extended label types. - -4.3. UDP Message Size - - Traditional DNS Messages are limited to 512 octets in size when sent - over UDP ([RFC1035]). Today, many organizations wish to return many - records in a single reply, and special tricks are needed to make the - responses fit in this 512-byte limit. Additionally, inclusion of - DNSSEC records frequently requires a much larger response than a 512 - byte message can hold. - - EDNS0 is intended to address these larger packet sizes and continue - to use UDP. It specifies a way to advertise additional features such - as larger response size capability, which is intended to help avoid - truncated UDP responses which then cause retry over TCP. - - -5. Extended Label Types - - The first octet in the on-the-wire representation of a DNS label - specifies the label type; the basic DNS specification [RFC1035] - dedicates the two most significant bits of that octet for this - purpose. - - - - -Damas, et al. Expires September 8, 2011 [Page 4] - -Internet-Draft EDNS0 Extensions March 2011 - - - [RFC2671] defined DNS label type 0b01 for use as an indication for - Extended Label Types. A specific Extended Label Type is selected by - the 6 least significant bits of the first octet. Thus, Extended - Label Types are indicated by the values 64-127 (0b01xxxxxx) in the - first octet of the label. - - Extended Label Types are difficult to use due to support in clients - and intermediate gateways as described in [RFC3364] which moves them - to experimental status and [RFC3363], which describes the pros and - cons. - - Therefore, this document moves them from experimental to historical, - making them obsoleted. Additionally, the registry of Extended Label - Types is requested to be closed. - - -6. The OPT pseudo-RR - -6.1. OPT Record Definition - - An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the - additional data section of a request. - - The OPT RR has RR type 41. - - If present in requests, compliant responders MUST include an OPT - record in their respective responses. - - An OPT record does not carry any DNS data. It is used only to - contain control information pertaining to the question and answer - sequence of a specific transaction. OPT RRs MUST NOT be cached, - forwarded, or stored in or loaded from master files. - - The OPT RR MAY be placed anywhere within the additional data section. - Only one OPT RR MAY be included within any DNS message. If a message - with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be - returned. The placement flexibility for the OPT RR does not override - the need for the TSIG or SIG(0) RRs to be the last in the additional - section whenever they are present. - -6.2. OPT Record Wire Format - - An OPT RR has a fixed part and a variable set of options expressed as - {attribute, value} pairs. The fixed part holds some DNS meta data - and also a small collection of basic extension elements which we - expect to be so popular that it would be a waste of wire space to - encode them as {attribute, value} pairs. - - - - -Damas, et al. Expires September 8, 2011 [Page 5] - -Internet-Draft EDNS0 Extensions March 2011 - - - The fixed part of an OPT RR is structured as follows: - - +------------+--------------+------------------------------+ - | Field Name | Field Type | Description | - +------------+--------------+------------------------------+ - | NAME | domain name | Must be 0 (root domain) | - | TYPE | u_int16_t | OPT (42) | - | CLASS | u_int16_t | requestor's UDP payload size | - | TTL | u_int32_t | extended RCODE and flags | - | RDLEN | u_int16_t | length of all RDATA | - | RDATA | octet stream | {attribute,value} pairs | - +------------+--------------+------------------------------+ - - OPT RR Format - - The variable part of an OPT RR may contain zero or more options in - the RDATA. Each option must be treated as binary. Each option is - encoded as: - - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | OPTION-CODE | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | OPTION-LENGTH | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 4: | | - / OPTION-DATA / - / / - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - OPTION-CODE - Assigned by Expert Review. - - OPTION-LENGTH - Size (in octets) of OPTION-DATA. - - OPTION-DATA - Varies per OPTION-CODE. MUST be treated as binary. - - The order of appearance of option tuples is not defined. If one - option modifies the behavior of another or multiple options are - related to one another in some way, they have the same effect - regardless of ordering in the RDATA wire encoding. - - Any OPTION-CODE values not understood by a responder or requestor - MUST be ignored. Specifications of such options might wish to - include some kind of signaled acknowledgement. For example, an - - - -Damas, et al. Expires September 8, 2011 [Page 6] - -Internet-Draft EDNS0 Extensions March 2011 - - - option specification might say that if a responder sees option XYZ, - it MUST include option XYZ in its response. - -6.3. Cache behaviour - - The OPT record MUST NOT be cached. - -6.4. Fallback - - If a requestor detects that the remote end does not support EDNS0, it - MAY issue queries without an OPT record. It MAY cache this knowledge - for a brief time in order to avoid fallback delays in the future. - However, if DNSSEC or any future option using EDNS is required, no - fallback should be performed as they are only signaled through EDNS0. - If an implementation detects that some servers for the zone support - EDNS(0) while others would force the use of TCP to fetch all data, - preference SHOULD be given to those support EDNS(0). - -6.5. Requestor's Payload Size - - The requestor's UDP payload size (encoded in the RR CLASS field) is - the number of octets of the largest UDP payload that can be - reassembled and delivered in the requestor's network stack. Note - that path MTU, with or without fragmentation, could be smaller than - this. Values lower than 512 MUST be treated as equal to 512. - - The requestor SHOULD place a value in this field that it can actually - receive. For example, if a requestor sits behind a firewall which - will block fragmented IP packets, a requestor SHOULD not choose a - value which will cause fragmentation. Doing so will prevent large - responses from being received, and can cause fallback to occur. - - Note that a 512-octet UDP payload requires a 576-octet IP reassembly - buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over - Ethernet would be reasonable. Choosing a very large value will - guarantee fragmentation at the IP layer, and may prevent answers from - being received due to a single fragment loss or misconfigured - firewalls. - - The requestor's maximum payload size can change over time. It MUST - not be cached for use beyond the transaction in which it is - advertised. - -6.6. Responder's Payload Size - - The responder's maximum payload size can change over time, but can be - reasonably expected to remain constant between two closely spaced - sequential transactions; for example, a meaningless QUERY to discover - - - -Damas, et al. Expires September 8, 2011 [Page 7] - -Internet-Draft EDNS0 Extensions March 2011 - - - a responder's maximum UDP payload size, followed immediately by an - UPDATE which takes advantage of this size. This is considered - preferable to the outright use of TCP for oversized requests, if - there is any reason to suspect that the responder implements EDNS, - and if a request will not fit in the default 512 payload size limit. - -6.7. Payload Size Selection - - Due to transaction overhead, it is unwise to advertise an - architectural limit as a maximum UDP payload size. Just because your - stack can reassemble 64KB datagrams, don't assume that you want to - spend more than about 4KB of state memory per ongoing transaction. - - A requestor MAY choose to implement a fallback to smaller advertised - sizes to work around firewall or other network limitations. A - requestor SHOULD choose to use a fallback mechanism which begins with - a large size, such as 4096. If that fails, a fallback around the - 1280-1410 byte range SHOULD be tried, as it has a reasonable chance - to fit within a single Ethernet frame. Failing that, a requestor MAY - choose a 512 byte packet, which with large answers may cause a TCP - retry. - -6.8. Middleware Boxes - - Middleware boxes (e.g. firewalls, SOHO routers, load balancers, etc) - MUST NOT limit DNS messages over UDP to 512 bytes. - - Middleware boxes which simply forward requests to a recursive - resolver MUST NOT modify and MUST NOT delete the OPT record contents - in either direction. - - Middleware boxes which have additional functionality, such as - answering certain queries or acting like an intelligent forwarder, - MUST understand the OPT record. These boxes MUST consider the - incoming request and any outgoing requests as separate transactions - if the characteristics of the messages are different. - - A complete discussion of middleware boxes acting as DNS proxies and - the impact of EDNS in those implementations is described in - [RFC5625]. - -6.9. OPT Record TTL Field Use - - The extended RCODE and flags (which OPT stores in the RR TTL field) - are structured as follows: - - - - - - -Damas, et al. Expires September 8, 2011 [Page 8] - -Internet-Draft EDNS0 Extensions March 2011 - - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | EXTENDED-RCODE | VERSION | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | DO| Z | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - EXTENDED-RCODE - Forms upper 8 bits of extended 12-bit RCODE (together with the - 4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0 - indicates that an unextended RCODE is in use (values 0 through - 15). - - VERSION - Indicates the implementation level of whoever sets it. Full - conformance with this specification is indicated by version - ``0.'' Requestors are encouraged to set this to the lowest - implemented level capable of expressing a transaction, to - minimize the responder and network load of discovering the - greatest common implementation level between requestor and - responder. A requestor's version numbering strategy MAY - ideally be a run time configuration option. - If a responder does not implement the VERSION level of the - request, then it answers with RCODE=BADVERS. All responses - MUST be limited in format to the VERSION level of the request, - but the VERSION of each response SHOULD be the highest - implementation level of the responder. In this way a requestor - will learn the implementation level of a responder as a side - effect of every response, including error responses and - including RCODE=BADVERS. - -6.10. Flags - - DO - DNSSEC OK bit as defined by [RFC3225]. - - Z - Set to zero by senders and ignored by receivers, unless - modified in a subsequent specification. - -6.11. OPT Options Code Allocation Procedure - - Allocations assigned by expert review. Assignment of Option Codes - should be liberal, but duplicate functionality is to be avoided. - - - - - - - -Damas, et al. Expires September 8, 2011 [Page 9] - -Internet-Draft EDNS0 Extensions March 2011 - - -7. Transport Considerations - - The presence of an OPT pseudo-RR in a request should be taken as an - indication that the requestor fully implements the given version of - EDNS, and can correctly understand any response that conforms to that - feature's specification. - - Lack of presence of an OPT record in a request MUST be taken as an - indication that the requestor does not implement any part of this - specification and that the responder MUST NOT include an OPT record - in its response. - - Responders who do not implement these protocol extensions MUST - respond with FORMERR messages without any OPT record. - - If there is a problem with processing the OPT record itself, such as - an option value that is badly formatted or includes out of range - values, a FORMERR MUST be returned. If this occurs the response MUST - include an OPT record. This is intended to allow the requestor to to - distinguish between servers which do not implement EDNS and format - errors within EDNS. - - The minimal response must be the DNS header, question section, and an - OPT record. This must also occur when an truncated response (using - the DNS header's TC bit) is returned. - - -8. Security Considerations - - Requestor-side specification of the maximum buffer size may open a - DNS denial of service attack if responders can be made to send - messages which are too large for intermediate gateways to forward, - thus leading to potential ICMP storms between gateways and - responders. - - Announcing very large UDP buffer sizes may result in dropping by - middleboxes (see Section 6.8). This could cause retransmissions with - no hope of success. Some devices have been found to reject - fragmented UDP packets. - - Announcing too small UDP buffer sizes may result in fallback to TCP - with a corresponding load impact on DNS servers. This is especially - important with DNSSEC, where answers are much larger. - - -9. IANA Considerations - - The IANA has assigned RR type code 41 for OPT. - - - -Damas, et al. Expires September 8, 2011 [Page 10] - -Internet-Draft EDNS0 Extensions March 2011 - - - [RFC2671] specified a number of IANA sub-registries within "DOMAIN - NAME SYSTEM PARAMETERS:" - - o EDNS Extended Label Type - - o EDNS Option Codes - - o EDNS Version Numbers - - o Domain System Response Code - - IANA is advised to re-parent these sub-registries to this document. - - [RFC2671] created the "EDNS Extended Label Type Registry". We - request that this registry be closed. - - This document assigns option code 65535 in the "EDNS Option Codes" - registry to "Reserved for future expansion." - - [RFC2671] expands the RCODE space from 4 bits to 12 bits. This - allows more than the 16 distinct RCODE values allowed in [RFC1035]. - IETF Standards Action is required to add a new RCODE. Adding new - RCODEs should be avoided due to the difficulty in upgrading the - installed base. - - This document assigns EDNS Extended RCODE 16 to "BADVERS". - - IETF Standards Action is required for assignments of new EDNS0 flags. - Flags SHOULD be used only when necessary for DNS resolution to - function. For many uses, a EDNS Option Code may be preferred. - - IETF Standards Action is required to create new entries in the EDNS - Version Number registry. Expert Review is required for allocation of - an EDNS Option Code. - - -Appendix A. Document Editing History - - Following is a list of high-level changes made to the original - RFC2671. - -Appendix A.1. Changes since RFC2671 - - o Support for the OPT record is now mandatory. - - o Extended label types obsoleted and the registry is closed. - - - - - -Damas, et al. Expires September 8, 2011 [Page 11] - -Internet-Draft EDNS0 Extensions March 2011 - - - o The bitstring label type, which was already moved from draft to - experimental, is requested to be moved to historical. - - o Changes in how EDNS buffer sizes are selected, with - recommendations on how to select them. - - o Front material (IPR notice and such) was updated to current - requirements. - -Appendix A.2. Changes since -02 - - o Specified the method for allocation of constants. - - o Cleaned up a lot of wording, along with quite a bit of document - structure changes. - - -10. References - -10.1. Normative References - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", - RFC 3225, December 2001. - - [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. - Hain, "Representing Internet Protocol version 6 (IPv6) - Addresses in the Domain Name System (DNS)", RFC 3363, - August 2002. - -10.2. Informative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) - Support for Internet Protocol version 6 (IPv6)", RFC 3364, - August 2002. - - [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", - BCP 152, RFC 5625, August 2009. - - - - - -Damas, et al. Expires September 8, 2011 [Page 12] - -Internet-Draft EDNS0 Extensions March 2011 - - -Authors' Addresses - - Joao Damas - Internet Systems Consortium - 950 Charter Street - Redwood City, California 94063 - US - - Phone: +1 650.423.1312 - Email: joao@isc.org - - - Michael Graff - Internet Systems Consortium - 950 Charter Street - Redwood City, California 94063 - US - - Phone: +1 650.423.1304 - Email: mgraff@isc.org - - - Paul Vixie - Internet Systems Consortium - 950 Charter Street - Redwood City, California 94063 - US - - Phone: +1 650.423.1301 - Email: vixie@isc.org - - - - - - - - - - - - - - - - - - - - - -Damas, et al. Expires September 8, 2011 [Page 13] - diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt deleted file mode 100644 index 0855ba358c9..00000000000 --- a/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt +++ /dev/null @@ -1,1232 +0,0 @@ - - - -DNS Operations M. Larson -Internet-Draft P. Barber -Expires: August 14, 2006 VeriSign - February 10, 2006 - - - Observed DNS Resolution Misbehavior - draft-ietf-dnsop-bad-dns-res-05 - -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 BCP 79. - - 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 August 14, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This memo describes DNS iterative resolver behavior that results in a - significant query volume sent to the root and top-level domain (TLD) - name servers. We offer implementation advice to iterative resolver - developers to alleviate these unnecessary queries. The - recommendations made in this document are a direct byproduct of - observation and analysis of abnormal query traffic patterns seen at - two of the thirteen root name servers and all thirteen com/net TLD - name servers. - - - -Larson & Barber Expires August 14, 2006 [Page 1] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - 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 [1]. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. A note about terminology in this memo . . . . . . . . . . 3 - 2. Observed iterative resolver misbehavior . . . . . . . . . . . 5 - 2.1. Aggressive requerying for delegation information . . . . . 5 - 2.1.1. Recommendation . . . . . . . . . . . . . . . . . . . . 6 - 2.2. Repeated queries to lame servers . . . . . . . . . . . . . 7 - 2.2.1. Recommendation . . . . . . . . . . . . . . . . . . . . 7 - 2.3. Inability to follow multiple levels of indirection . . . . 8 - 2.3.1. Recommendation . . . . . . . . . . . . . . . . . . . . 9 - 2.4. Aggressive retransmission when fetching glue . . . . . . . 9 - 2.4.1. Recommendation . . . . . . . . . . . . . . . . . . . . 10 - 2.5. Aggressive retransmission behind firewalls . . . . . . . . 10 - 2.5.1. Recommendation . . . . . . . . . . . . . . . . . . . . 11 - 2.6. Misconfigured NS records . . . . . . . . . . . . . . . . . 11 - 2.6.1. Recommendation . . . . . . . . . . . . . . . . . . . . 12 - 2.7. Name server records with zero TTL . . . . . . . . . . . . 12 - 2.7.1. Recommendation . . . . . . . . . . . . . . . . . . . . 13 - 2.8. Unnecessary dynamic update messages . . . . . . . . . . . 13 - 2.8.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 - 2.9. Queries for domain names resembling IPv4 addresses . . . . 14 - 2.9.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 - 2.10. Misdirected recursive queries . . . . . . . . . . . . . . 15 - 2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15 - 2.11. Suboptimal name server selection algorithm . . . . . . . . 15 - 2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16 - 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 - 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 - 5. Security considerations . . . . . . . . . . . . . . . . . . . 19 - 6. Internationalization considerations . . . . . . . . . . . . . 20 - 7. Informative References . . . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 - Intellectual Property and Copyright Statements . . . . . . . . . . 22 - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 2] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -1. Introduction - - Observation of query traffic received by two root name servers and - the thirteen com/net TLD name servers has revealed that a large - proportion of the total traffic often consists of "requeries". A - requery is the same question () asked - repeatedly at an unexpectedly high rate. We have observed requeries - from both a single IP address and multiple IP addresses (i.e., the - same query received simultaneously from multiple IP addresses). - - By analyzing requery events we have found that the cause of the - duplicate traffic is almost always a deficient iterative resolver, - stub resolver or application implementation combined with an - operational anomaly. The implementation deficiencies we have - identified to date include well-intentioned recovery attempts gone - awry, insufficient caching of failures, early abort when multiple - levels of indirection must be followed, and aggressive retry by stub - resolvers or applications. Anomalies that we have seen trigger - requery events include lame delegations, unusual glue records, and - anything that makes all authoritative name servers for a zone - unreachable (DoS attacks, crashes, maintenance, routing failures, - congestion, etc.). - - In the following sections, we provide a detailed explanation of the - observed behavior and recommend changes that will reduce the requery - rate. None of the changes recommended affects the core DNS protocol - specification; instead, this document consists of guidelines to - implementors of iterative resolvers. - -1.1. A note about terminology in this memo - - To recast an old saying about standards, the nice thing about DNS - terms is that there are so many of them to choose from. Writing or - talking about DNS can be difficult and cause confusion resulting from - a lack of agreed-upon terms for its various components. Further - complicating matters are implementations that combine multiple roles - into one piece of software, which makes naming the result - problematic. An example is the entity that accepts recursive - queries, issues iterative queries as necessary to resolve the initial - recursive query, caches responses it receives, and which is also able - to answer questions about certain zones authoritatively. This entity - is an iterative resolver combined with an authoritative name server - and is often called a "recursive name server" or a "caching name - server". - - This memo is concerned principally with the behavior of iterative - resolvers, which are typically found as part of a recursive name - server. This memo uses the more precise term "iterative resolver", - - - -Larson & Barber Expires August 14, 2006 [Page 3] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - because the focus is usually on that component. In instances where - the name server role of this entity requires mentioning, this memo - uses the term "recursive name server". As an example of the - difference, the name server component of a recursive name server - receives DNS queries and the iterative resolver component sends - queries. - - The advent of IPv6 requires mentioning AAAA records as well as A - records when discussing glue. To avoid continuous repetition and - qualification, this memo uses the general term "address record" to - encompass both A and AAAA records when a particular situation is - relevant to both types. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 4] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -2. Observed iterative resolver misbehavior - -2.1. Aggressive requerying for delegation information - - There can be times when every name server in a zone's NS RRset is - unreachable (e.g., during a network outage), unavailable (e.g., the - name server process is not running on the server host) or - misconfigured (e.g., the name server is not authoritative for the - given zone, also known as "lame"). Consider an iterative resolver - that attempts to resolve a query for a domain name in such a zone and - discovers that none of the zone's name servers can provide an answer. - We have observed a recursive name server implementation whose - iterative resolver then verifies the zone's NS RRset in its cache by - querying for the zone's delegation information: it sends a query for - the zone's NS RRset to one of the parent zone's name servers. (Note - that queries with QTYPE=NS are not required by the standard - resolution algorithm described in section 4.3.2 of RFC 1034 [2]. - These NS queries represent this implementation's addition to that - algorithm.) - - For example, suppose that "example.com" has the following NS RRset: - - example.com. IN NS ns1.example.com. - example.com. IN NS ns2.example.com. - - Upon receipt of a query for "www.example.com" and assuming that - neither "ns1.example.com" nor "ns2.example.com" can provide an - answer, this iterative resolver implementation immediately queries a - "com" zone name server for the "example.com" NS RRset to verify it - has the proper delegation information. This implementation performs - this query to a zone's parent zone for each recursive query it - receives that fails because of a completely unresponsive set of name - servers for the target zone. Consider the effect when a popular zone - experiences a catastrophic failure of all its name servers: now every - recursive query for domain names in that zone sent to this recursive - name server implementation results in a query to the failed zone's - parent name servers. On one occasion when several dozen popular - zones became unreachable, the query load on the com/net name servers - increased by 50%. - - We believe this verification query is not reasonable. Consider the - circumstances: When an iterative resolver is resolving a query for a - domain name in a zone it has not previously searched, it uses the - list of name servers in the referral from the target zone's parent. - If on its first attempt to search the target zone, none of the name - servers in the referral is reachable, a verification query to the - parent would be pointless: this query to the parent would come so - quickly on the heels of the referral that it would be almost certain - - - -Larson & Barber Expires August 14, 2006 [Page 5] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - to contain the same list of name servers. The chance of discovering - any new information is slim. - - The other possibility is that the iterative resolver successfully - contacts one of the target zone's name servers and then caches the NS - RRset from the authority section of a response, the proper behavior - according to section 5.4.1 of RFC 2181 [3], because the NS RRset from - the target zone is more trustworthy than delegation information from - the parent zone. If, while processing a subsequent recursive query, - the iterative resolver discovers that none of the name servers - specified in the cached NS RRset is available or authoritative, - querying the parent would be wrong. An NS RRset from the parent zone - would now be less trustworthy than data already in the cache. - - For this query of the parent zone to be useful, the target zone's - entire set of name servers would have to change AND the former set of - name servers would have to be deconfigured or decommissioned AND the - delegation information in the parent zone would have to be updated - with the new set of name servers, all within the TTL of the target - zone's NS RRset. We believe this scenario is uncommon: - administrative best practices dictate that changes to a zone's set of - name servers happen gradually when at all possible, with servers - removed from the NS RRset left authoritative for the zone as long as - possible. The scenarios that we can envision that would benefit from - the parent requery behavior do not outweigh its damaging effects. - - This section should not be understood to claim that all queries to a - zone's parent are bad. In some cases, such queries are not only - reasonable but required. Consider the situation when required - information, such as the address of a name server (i.e., the address - record corresponding to the RDATA of an NS record), has timed out of - an iterative resolver's cache before the corresponding NS record. If - the name of the name server is below the apex of the zone, then the - name server's address record is only available as glue in the parent - zone. For example, consider this NS record: - - example.com. IN NS ns.example.com. - - If a cache has this NS record but not the address record for - "ns.example.com", it is unable to contact the "example.com" zone - directly and must query the "com" zone to obtain the address record. - Note, however, that such a query would not have QTYPE=NS according to - the standard resolution algorithm. - -2.1.1. Recommendation - - An iterative resolver MUST NOT send a query for the NS RRset of a - non-responsive zone to any of the name servers for that zone's parent - - - -Larson & Barber Expires August 14, 2006 [Page 6] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - zone. For the purposes of this injunction, a non-responsive zone is - defined as a zone for which every name server listed in the zone's NS - RRset: - - 1. is not authoritative for the zone (i.e., lame), or, - - 2. returns a server failure response (RCODE=2), or, - - 3. is dead or unreachable according to section 7.2 of RFC 2308 [4]. - -2.2. Repeated queries to lame servers - - Section 2.1 describes a catastrophic failure: when every name server - for a zone is unable to provide an answer for one reason or another. - A more common occurrence is when a subset of a zone's name servers - are unavailable or misconfigured. Different failure modes have - different expected durations. Some symptoms indicate problems that - are potentially transient; for example, various types of ICMP - unreachable messages because a name server process is not running or - a host or network is unreachable, or a complete lack of a response to - a query. Such responses could be the result of a host rebooting or - temporary outages; these events don't necessarily require any human - intervention and can be reasonably expected to be temporary. - - Other symptoms clearly indicate a condition requiring human - intervention, such as lame server: if a name server is misconfigured - and not authoritative for a zone delegated to it, it is reasonable to - assume that this condition has potential to last longer than - unreachability or unresponsiveness. Consequently, repeated queries - to known lame servers are not useful. In this case of a condition - with potential to persist for a long time, a better practice would be - to maintain a list of known lame servers and avoid querying them - repeatedly in a short interval. - - It should also be noted, however, that some authoritative name server - implementations appear to be lame only for queries of certain types - as described in RFC 4074 [5]. In this case, it makes sense to retry - the "lame" servers for other types of queries, particularly when all - known authoritative name servers appear to be "lame". - -2.2.1. Recommendation - - Iterative resolvers SHOULD cache name servers that they discover are - not authoritative for zones delegated to them (i.e. lame servers). - If this caching is performed, lame servers MUST be cached against the - specific query tuple . Zone - name can be derived from the owner name of the NS record that was - referenced to query the name server that was discovered to be lame. - - - -Larson & Barber Expires August 14, 2006 [Page 7] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - Implementations that perform lame server caching MUST refrain from - sending queries to known lame servers based on a time interval from - when the server is discovered to be lame. A minimum interval of - thirty minutes is RECOMMENDED. - - An exception to this recommendation occurs if all name servers for a - zone are marked lame. In that case, the iterative resolver SHOULD - temporarily ignore the servers' lameness status and query one or more - servers. This behavior is a workaround for the type-specific - lameness issue described in the previous section. - - Implementors should take care not to make lame server avoidance logic - overly broad: note that a name server could be lame for a parent zone - but not a child zone, e.g., lame for "example.com" but properly - authoritative for "sub.example.com". Therefore a name server should - not be automatically considered lame for subzones. In the case - above, even if a name server is known to be lame for "example.com", - it should be queried for QNAMEs at or below "sub.example.com" if an - NS record indicates it should be authoritative for that zone. - -2.3. Inability to follow multiple levels of indirection - - Some iterative resolver implementations are unable to follow - sufficient levels of indirection. For example, consider the - following delegations: - - foo.example. IN NS ns1.example.com. - foo.example. IN NS ns2.example.com. - - example.com. IN NS ns1.test.example.net. - example.com. IN NS ns2.test.example.net. - - test.example.net. IN NS ns1.test.example.net. - test.example.net. IN NS ns2.test.example.net. - - An iterative resolver resolving the name "www.foo.example" must - follow two levels of indirection, first obtaining address records for - "ns1.test.example.net" or "ns2.test.example.net" in order to obtain - address records for "ns1.example.com" or "ns2.example.com" in order - to query those name servers for the address records of - "www.foo.example". While this situation may appear contrived, we - have seen multiple similar occurrences and expect more as new generic - top-level domains (gTLDs) become active. We anticipate many zones in - new gTLDs will use name servers in existing gTLDs, increasing the - number of delegations using out-of-zone name servers. - - - - - - -Larson & Barber Expires August 14, 2006 [Page 8] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -2.3.1. Recommendation - - Clearly constructing a delegation that relies on multiple levels of - indirection is not a good administrative practice. However, the - practice is widespread enough to require that iterative resolvers be - able to cope with it. Iterative resolvers SHOULD be able to handle - arbitrary levels of indirection resulting from out-of-zone name - servers. Iterative resolvers SHOULD implement a level-of-effort - counter to avoid loops or otherwise performing too much work in - resolving pathological cases. - - A best practice that avoids this entire issue of indirection is to - name one or more of a zone's name servers in the zone itself. For - example, if the zone is named "example.com", consider naming some of - the name servers "ns{1,2,...}.example.com" (or similar). - -2.4. Aggressive retransmission when fetching glue - - When an authoritative name server responds with a referral, it - includes NS records in the authority section of the response. - According to the algorithm in section 4.3.2 of RFC 1034 [2], the name - server should also "put whatever addresses are available into the - additional section, using glue RRs if the addresses are not available - from authoritative data or the cache." Some name server - implementations take this address inclusion a step further with a - feature called "glue fetching". A name server that implements glue - fetching attempts to include address records for every NS record in - the authority section. If necessary, the name server issues multiple - queries of its own to obtain any missing address records. - - Problems with glue fetching can arise in the context of - "authoritative-only" name servers, which only serve authoritative - data and ignore requests for recursion. Such an entity will not - normally generate any queries of its own. Instead it answers non- - recursive queries from iterative resolvers looking for information in - zones it serves. With glue fetching enabled, however, an - authoritative server invokes an iterative resolver to look up an - unknown address record to complete the additional section of a - response. - - We have observed situations where the iterative resolver of a glue- - fetching name server can send queries that reach other name servers, - but is apparently prevented from receiving the responses. For - example, perhaps the name server is authoritative-only and therefore - its administrators expect it to receive only queries and not - responses. Perhaps unaware of glue fetching and presuming that the - name server's iterative resolver will generate no queries, its - administrators place the name server behind a network device that - - - -Larson & Barber Expires August 14, 2006 [Page 9] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - prevents it from receiving responses. If this is the case, all glue- - fetching queries will go answered. - - We have observed name server implementations whose iterative - resolvers retry excessively when glue-fetching queries are - unanswered. A single com/net name server has received hundreds of - queries per second from a single such source. Judging from the - specific queries received and based on additional analysis, we - believe these queries result from overly aggressive glue fetching. - -2.4.1. Recommendation - - Implementers whose name servers support glue fetching SHOULD take - care to avoid sending queries at excessive rates. Implementations - SHOULD support throttling logic to detect when queries are sent but - no responses are received. - -2.5. Aggressive retransmission behind firewalls - - A common occurrence and one of the largest sources of repeated - queries at the com/net and root name servers appears to result from - resolvers behind misconfigured firewalls. In this situation, an - iterative resolver is apparently allowed to send queries through a - firewall to other name servers, but not receive the responses. The - result is more queries than necessary because of retransmission, all - of which are useless because the responses are never received. Just - as with the glue-fetching scenario described in Section 2.4, the - queries are sometimes sent at excessive rates. To make matters - worse, sometimes the responses, sent in reply to legitimate queries, - trigger an alarm on the originator's intrusion detection system. We - are frequently contacted by administrators responding to such alarms - who believe our name servers are attacking their systems. - - Not only do some resolvers in this situation retransmit queries at an - excessive rate, but they continue to do so for days or even weeks. - This scenario could result from an organization with multiple - recursive name servers, only a subset of whose iterative resolvers' - traffic is improperly filtered in this manner. Stub resolvers in the - organization could be configured to query multiple recursive name - servers. Consider the case where a stub resolver queries a filtered - recursive name server first. The iterative resolver of this - recursive name server sends one or more queries whose replies are - filtered, so it can't respond to the stub resolver, which times out. - Then the stub resolver retransmits to a recursive name server that is - able to provide an answer. Since resolution ultimately succeeds the - underlying problem might not be recognized or corrected. A popular - stub resolver implementation has a very aggressive retransmission - schedule, including simultaneous queries to multiple recursive name - - - -Larson & Barber Expires August 14, 2006 [Page 10] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - servers, which could explain how such a situation could persist - without being detected. - -2.5.1. Recommendation - - The most obvious recommendation is that administrators SHOULD take - care not to place iterative resolvers behind a firewall that allows - queries to pass through but not the resulting replies. - - Iterative resolvers SHOULD take care to avoid sending queries at - excessive rates. Implementations SHOULD support throttling logic to - detect when queries are sent but no responses are received. - -2.6. Misconfigured NS records - - Sometimes a zone administrator forgets to add the trailing dot on the - domain names in the RDATA of a zone's NS records. Consider this - fragment of the zone file for "example.com": - - $ORIGIN example.com. - example.com. 3600 IN NS ns1.example.com ; Note missing - example.com. 3600 IN NS ns2.example.com ; trailing dots - - The zone's authoritative servers will parse the NS RDATA as - "ns1.example.com.example.com" and "ns2.example.com.example.com" and - return NS records with this incorrect RDATA in responses, including - typically the authority section of every response containing records - from the "example.com" zone. - - Now consider a typical sequence of queries. An iterative resolver - attempting to resolve address records for "www.example.com" with no - cached information for this zone will query a "com" authoritative - server. The "com" server responds with a referral to the - "example.com" zone, consisting of NS records with valid RDATA and - associated glue records. (This example assumes that the - "example.com" zone delegation information is correct in the "com" - zone.) The iterative resolver caches the NS RRset from the "com" - server and follows the referral by querying one of the "example.com" - authoritative servers. This server responds with the - "www.example.com" address record in the answer section and, - typically, the "example.com" NS records in the authority section and, - if space in the message remains, glue address records in the - additional section. According to Section 5.4 of RFC 2181 [3], NS - records in the authority section of an authoritative answer are more - trustworthy than NS records from the authority section of a non- - authoritative answer. Thus the "example.com" NS RRset just received - from the "example.com" authoritative server overrides the - "example.com" NS RRset received moments ago from the "com" - - - -Larson & Barber Expires August 14, 2006 [Page 11] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - authoritative server. - - But the "example.com" zone contains the erroneous NS RRset as shown - in the example above. Subsequent queries for names in "example.com" - will cause the iterative resolver to attempt to use the incorrect NS - records and so it will try to resolve the nonexistent names - "ns1.example.com.example.com" and "ns2.example.com.example.com". In - this example, since all of the zone's name servers are named in the - zone itself (i.e., "ns1.example.com.example.com" and - "ns2.example.com.example.com" both end in "example.com") and all are - bogus, the iterative resolver cannot reach any "example.com" name - servers. Therefore attempts to resolve these names result in address - record queries to the "com" authoritative servers. Queries for such - obviously bogus glue address records occur frequently at the com/net - name servers. - -2.6.1. Recommendation - - An authoritative server can detect this situation. A trailing dot - missing from an NS record's RDATA always results by definition in a - name server name that exists somewhere under the apex of the zone the - NS record appears in. Note that further levels of delegation are - possible, so a missing trailing dot could inadvertently create a name - server name that actually exists in a subzone. - - An authoritative name server SHOULD issue a warning when one of a - zone's NS records references a name server below the zone's apex when - a corresponding address record does not exist in the zone AND there - are no delegated subzones where the address record could exist. - -2.7. Name server records with zero TTL - - Sometimes a popular com/net subdomain's zone is configured with a TTL - of zero on the zone's NS records, which prohibits these records from - being cached and will result in a higher query volume to the zone's - authoritative servers. The zone's administrator should understand - the consequences of such a configuration and provision resources - accordingly. A zero TTL on the zone's NS RRset, however, carries - additional consequences beyond the zone itself: if an iterative - resolver cannot cache a zone's NS records because of a zero TTL, it - will be forced to query that zone's parent's name servers each time - it resolves a name in the zone. The com/net authoritative servers do - see an increased query load when a popular com/net subdomain's zone - is configured with a TTL of zero on the zone's NS records. - - A zero TTL on an RRset expected to change frequently is extreme but - permissible. A zone's NS RRset is a special case, however, because - changes to it must be coordinated with the zone's parent. In most - - - -Larson & Barber Expires August 14, 2006 [Page 12] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - zone parent/child relationships we are aware of, there is typically - some delay involved in effecting changes. Further, changes to the - set of a zone's authoritative name servers (and therefore to the - zone's NS RRset) are typically relatively rare: providing reliable - authoritative service requires a reasonably stable set of servers. - Therefore an extremely low or zero TTL on a zone's NS RRset rarely - makes sense, except in anticipation of an upcoming change. In this - case, when the zone's administrator has planned a change and does not - want iterative resolvers throughout the Internet to cache the NS - RRset for a long period of time, a low TTL is reasonable. - -2.7.1. Recommendation - - Because of the additional load placed on a zone's parent's - authoritative servers resulting from a zero TTL on a zone's NS RRset, - under such circumstances authoritative name servers SHOULD issue a - warning when loading a zone. - -2.8. Unnecessary dynamic update messages - - The UPDATE message specified in RFC 2136 [6] allows an authorized - agent to update a zone's data on an authoritative name server using a - DNS message sent over the network. Consider the case of an agent - desiring to add a particular resource record. Because of zone cuts, - the agent does not necessarily know the proper zone to which the - record should be added. The dynamic update process requires that the - agent determine the appropriate zone so the UPDATE message can be - sent to one of the zone's authoritative servers (typically the - primary master as specified in the zone's SOA MNAME field). - - The appropriate zone to update is the closest enclosing zone, which - cannot be determined only by inspecting the domain name of the record - to be updated, since zone cuts can occur anywhere. One way to - determine the closest enclosing zone entails walking up the name - space tree by sending repeated UPDATE messages until success. For - example, consider an agent attempting to add an address record with - the name "foo.bar.example.com". The agent could first attempt to - update the "foo.bar.example.com" zone. If the attempt failed, the - update could be directed to the "bar.example.com" zone, then the - "example.com" zone, then the "com" zone, and finally the root zone. - - A popular dynamic agent follows this algorithm. The result is many - UPDATE messages received by the root name servers, the com/net - authoritative servers, and presumably other TLD authoritative - servers. A valid question is why the algorithm proceeds to send - updates all the way to TLD and root name servers. This behavior is - not entirely unreasonable: in enterprise DNS architectures with an - "internal root" design, there could conceivably be private, non- - - - -Larson & Barber Expires August 14, 2006 [Page 13] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - public TLD or root zones that would be the appropriate targets for a - dynamic update. - - A significant deficiency with this algorithm is that knowledge of a - given UPDATE message's failure is not helpful in directing future - UPDATE messages to the appropriate servers. A better algorithm would - be to find the closest enclosing zone by walking up the name space - with queries for SOA or NS rather than "probing" with UPDATE - messages. Once the appropriate zone is found, an UPDATE message can - be sent. In addition, the results of these queries can be cached to - aid in determining closest enclosing zones for future updates. Once - the closest enclosing zone is determined with this method, the update - will either succeed or fail and there is no need to send further - updates to higher-level zones. The important point is that walking - up the tree with queries yields cacheable information, whereas - walking up the tree by sending UPDATE messages does not. - -2.8.1. Recommendation - - Dynamic update agents SHOULD send SOA or NS queries to progressively - higher-level names to find the closest enclosing zone for a given - name to update. Only after the appropriate zone is found should the - client send an UPDATE message to one of the zone's authoritative - servers. Update clients SHOULD NOT "probe" using UPDATE messages by - walking up the tree to progressively higher-level zones. - -2.9. Queries for domain names resembling IPv4 addresses - - The root name servers receive a significant number of A record - queries where the QNAME looks like an IPv4 address. The source of - these queries is unknown. It could be attributed to situations where - a user believes an application will accept either a domain name or an - IP address in a given configuration option. The user enters an IP - address, but the application assumes any input is a domain name and - attempts to resolve it, resulting in an A record lookup. There could - also be applications that produce such queries in a misguided attempt - to reverse map IP addresses. - - These queries result in Name Error (RCODE=3) responses. An iterative - resolver can negatively cache such responses, but each response - requires a separate cache entry, i.e., a negative cache entry for the - domain name "192.0.2.1" does not prevent a subsequent query for the - domain name "192.0.2.2". - -2.9.1. Recommendation - - It would be desirable for the root name servers not to have to answer - these queries: they unnecessarily consume CPU resources and network - - - -Larson & Barber Expires August 14, 2006 [Page 14] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - bandwidth. A possible solution is to delegate these numeric TLDs - from the root zone to a separate set of servers to absorb the - traffic. The "black hole servers" used by the AS 112 Project [8], - which are currently delegated the in-addr.arpa zones corresponding to - RFC 1918 [7] private use address space, would be a possible choice to - receive these delegations. Of course, the proper and usual root zone - change procedures would have to be followed to make such a change to - the root zone. - -2.10. Misdirected recursive queries - - The root name servers receive a significant number of recursive - queries (i.e., queries with the RD bit set in the header). Since - none of the root servers offers recursion, the servers' response in - such a situation ignores the request for recursion and the response - probably does not contain the data the querier anticipated. Some of - these queries result from users configuring stub resolvers to query a - root server. (This situation is not hypothetical: we have received - complaints from users when this configuration does not work as - hoped.) Of course, users should not direct stub resolvers to use - name servers that do not offer recursion, but we are not aware of any - stub resolver implementation that offers any feedback to the user - when so configured, aside from simply "not working". - -2.10.1. Recommendation - - When the IP address of a name server that supposedly offers recursion - is configured in a stub resolver using an interactive user interface, - the resolver could send a test query to verify that the server indeed - supports recursion (i.e., verify that the response has the RA bit set - in the header). The user could be immediately notified if the server - is non-recursive. - - The stub resolver could also report an error, either through a user - interface or in a log file, if the queried server does not support - recursion. Error reporting SHOULD be throttled to avoid a - notification or log message for every response from a non-recursive - server. - -2.11. Suboptimal name server selection algorithm - - An entire document could be devoted to the topic of problems with - different implementations of the recursive resolution algorithm. The - entire process of recursion is woefully under specified, requiring - each implementor to design an algorithm. Sometimes implementors make - poor design choices that could be avoided if a suggested algorithm - and best practices were documented, but that is a topic for another - document. - - - -Larson & Barber Expires August 14, 2006 [Page 15] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - Some deficiencies cause significant operational impact and are - therefore worth mentioning here. One of these is name server - selection by an iterative resolver. When an iterative resolver wants - to contact one of a zone's authoritative name servers, how does it - choose from the NS records listed in the zone's NS RRset? If the - selection mechanism is suboptimal, queries are not spread evenly - among a zone's authoritative servers. The details of the selection - mechanism are up to the implementor, but we offer some suggestions. - -2.11.1. Recommendation - - This list is not conclusive, but reflects the changes that would - produce the most impact in terms of reducing disproportionate query - load among a zone's authoritative servers. I.e., these changes would - help spread the query load evenly. - - o Do not make assumptions based on NS RRset order: all NS RRs SHOULD - be treated equally. (In the case of the "com" zone, for example, - most of the root servers return the NS record for "a.gtld- - servers.net" first in the authority section of referrals. - Apparently as a result, this server receives disproportionately - more traffic than the other 12 authoritative servers for "com".) - - o Use all NS records in an RRset. (For example, we are aware of - implementations that hard-coded information for a subset of the - root servers.) - - o Maintain state and favor the best-performing of a zone's - authoritative servers. A good definition of performance is - response time. Non-responsive servers can be penalized with an - extremely high response time. - - o Do not lock onto the best-performing of a zone's name servers. An - iterative resolver SHOULD periodically check the performance of - all of a zone's name servers to adjust its determination of the - best-performing one. - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 16] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -3. Acknowledgments - - The authors would like to thank the following people for their - comments that improved this document: Andras Salamon, Dave Meyer, - Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy, - Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein. We - apologize if we have omitted anyone; any oversight was unintentional. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 17] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -4. IANA considerations - - There are no new IANA considerations introduced by this memo. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 18] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -5. Security considerations - - The iterative resolver misbehavior discussed in this document exposes - the root and TLD name servers to increased risk of both intentional - and unintentional denial of service attacks. - - We believe that implementation of the recommendations offered in this - document will reduce the amount of unnecessary traffic seen at root - and TLD name servers, thus reducing the opportunity for an attacker - to use such queries to his or her advantage. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 19] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -6. Internationalization considerations - - There are no new internationalization considerations introduced by - this memo. - -7. Informative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - - [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS - Queries for IPv6 Addresses", RFC 4074, May 2005. - - [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. - Lear, "Address Allocation for Private Internets", BCP 5, - RFC 1918, February 1996. - - [8] - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 20] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -Authors' Addresses - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - Email: mlarson@verisign.com - - - Piet Barber - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - Email: pbarber@verisign.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 21] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -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 (2006). 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. - - - - -Larson & Barber Expires August 14, 2006 [Page 22] - diff --git a/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt b/doc/draft/draft-ietf-dnsop-dnssec-trust-history-02.txt similarity index 59% rename from doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt rename to doc/draft/draft-ietf-dnsop-dnssec-trust-history-02.txt index c06705b0a71..1700fc3bf2a 100644 --- a/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt +++ b/doc/draft/draft-ietf-dnsop-dnssec-trust-history-02.txt @@ -4,11 +4,11 @@ Domain Name System Operations W. Wijngaards Internet-Draft O. Kolkman Intended status: Standards Track NLnet Labs -Expires: August 26, 2010 February 22, 2010 +Expires: December 31, 2010 June 29, 2010 DNSSEC Trust Anchor History Service - draft-ietf-dnsop-dnssec-trust-history-01 + draft-ietf-dnsop-dnssec-trust-history-02 Abstract @@ -25,49 +25,43 @@ Requirements Language Status of This Memo - This Internet-Draft is submitted to IETF in full conformance with the + This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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. + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. 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 August 26, 2010. + This Internet-Draft will expire on December 31, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the - - - -Wijngaards & Kolkman Expires August 26, 2010 [Page 1] - -Internet-Draft Trust History Service February 2010 - - document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents + + + +Wijngaards & Kolkman Expires December 31, 2010 [Page 1] + +Internet-Draft Trust History Service June 2010 + + carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as - described in the BSD License. + described in the Simplified BSD License. 1. Introduction @@ -80,7 +74,7 @@ Internet-Draft Trust History Service February 2010 trust-anchor. Using a newly defined resource record (RR) that links old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY RRsets and checks they form a chain to the latest key (see - Section 2). The lists of old DNSKEYS, linked with the TALINK RRs, do + Section 3). The lists of old DNSKEYS, linked with the TALINK RRs, do not necessarily need to be published in the zone for which the DNSKEY history is being maintained but can be published in any DNS domain. We will call the entity that offers the trust history the History @@ -88,12 +82,123 @@ Internet-Draft Trust History Service February 2010 maintainer of the validator, possibly based on a hint provided, using the TALINK, by the zone owner. + Section 2 provides background on the mechanism and usage. It looks + at the viewpoints of publishers and consumers of trust anchors, the + use of keys with revocation flags, and SEP flags. + The algorithm that the validator uses to construct a history and - reconfigure a new key is detailed in Section 3. The algorithms for - how providers of trust history can fetch the DNSKEY data as published - by the zone they track and publish that are explained in Section 4. + reconfigure a new key is detailed in Section 4, it uses the TALINK RR + type defined in Section 3. The algorithms for how providers of trust + history can fetch the DNSKEY data as published by the zone they track + and publish that are explained in Section 5. + +2. Motivation and Description + + Validators provide a service in DNSSEC that can be seen from two + ways. Seen from the publisher's point of view, they provide + assurance that the data as received is as it was when it left the + publisher's hands. In this way of looking at things, validators + provide a publication integrity service. The publisher can be + confident that nobody can alter the published data (if it is + validated), because any alteration will be detected. So it protects + a publisher from being seen to send someone to the wrong place. + + From the consumer's point of view, validators provide a reason to + trust the data from the network. In this view, the validator is + + + +Wijngaards & Kolkman Expires December 31, 2010 [Page 2] + +Internet-Draft Trust History Service June 2010 + + + making a claim about whether the data ought to be accepted or not. + This is subtly different from the publisher's point of view, because + the question for the consumer is not whether the data is safe while + the consumer is not looking, but whether the data is safe for the + consumer at the moment of consumption. Validation protects a + consumer from going to the wrong place. + + These two slightly different ways of looking at the situation result + in slightly different operational goals. Whereas publishers want to + make assertions about their data, by controlling the roll over of + keys, consumers want to get the best assurance that they can get that + the data they are consuming is correct. + + If a validator has been offline during a key rollover event for one + of its trust anchors, then the validator will be unable to validate + answers that need that trust anchor. For the publisher, this state + of affairs is acceptable: the publisher is confident that no + validator ever consumes the wrong data. For the consumer, however, + this state of affairs represents an outage. + + Since publishers of trust anchors already use a chained series of + keys to perform rollovers under some circumstances (see [RFC5011]), + it is possible to use the history of that chain to allow a validator + to resume service for the consumer without needing to use an out-of- + band mechanism to obtain a new trust anchor. This improves the + experience for consumers of validated data, and increases the chances + that DNSSEC is useful for consumers of DNS data. + + The mechanism to do this is a double-linked list that recounts a + portion of the history of DNSKEY Resource Records. The list is used + by a validator to catch up with the changes that the validator + somehow missed. This approach may be thought of as replaying the + [RFC5011] rollover history, only at a later time. + +2.1. Considerations for Using a Revoked Key + + The keys that the publisher rolled are marked REVOKED by the RFC5011 + protocol. At this point the publisher considers the keys revoked, + but the validators have not yet seen this or marked the keys as + revoked. In the RFC5011 protocol, the validators probe regularly and + can then see if keys are revoked. If unable to probe, they will be + unable to see if keys are revoked. Hence when using a history to + recount rollovers, the consumer's validator has also missed a number + of revocations. The goal is to pick up the right keys and also the + new revocations along the way. + + Although the keys have been marked by the publisher as REVOKED a long + time ago, for the consumer these REVOKED keys are new information. + + + +Wijngaards & Kolkman Expires December 31, 2010 [Page 3] + +Internet-Draft Trust History Service June 2010 + + + Their storage in the history list makes it possible for consumers to + pick up key revocations if they missed the revocation announcement + because they could not probe. + + This is the allowed usage of REVOKED keys. The publisher is + announcing their presence. And the validators mark them as REVOKED + after verification. The initial part of this verification is the + reverse walk through the history list, which is to avoid exposing + which key is trusted. This means that older signatures with keys + that have in the meantime been revoked are used to construct and + verify the history list by the validator. + + A consequence is that once a publisher marks keys as REVOKED, there + will still be consumers who are using such keys, because they have + not seen the revocation. From the publishers point of view they are + revoked and the revocation is filed in the historical key list. From + the consumers point of view, it has not seen a revocation yet, and a + historical key list lookup algorithm is a state change where a new + trusted key is obtained while the old key is observed to be revoked. -2. The TALINK Resource Record +2.2. Motivation for Requiring the SEP Bit + + The SEP bit is used to differentiate Key Signing Keys from other + keys. It is defined in [RFC3757], it is used to designate trust + anchors in [RFC5011]. The protocol herein specified requires that + DNSKEYs that are subject to use for the trust history service have + the SEP bit set. The reason for this is to keep the set of keys that + need to be stored in history small. + +3. The TALINK Resource Record The DNS Resource Record type TALINK (decimal 58) ties the elements of a linked list of DNSKEY RRs together. @@ -105,17 +210,22 @@ Internet-Draft Trust History Service February 2010 The presentation format is the two domain names. The wire encoding is the two domain names, with no compression so the type can be treated according to [RFC3597]. The list is a double linked list, + because this empowers low memory hosts to perform consistency checks. + The TALINK used at the zone apex holds the endpoints of the list. + The TALINKs that form the lists hold previous and next entries. + These TALINKs are distinguished by their usage (entrypoint or list + connection). The double linked list is not circular, because lookups + must stop when they reach the oldest entry. -Wijngaards & Kolkman Expires August 26, 2010 [Page 2] + +Wijngaards & Kolkman Expires December 31, 2010 [Page 4] -Internet-Draft Trust History Service February 2010 +Internet-Draft Trust History Service June 2010 - because this empowers low memory hosts to perform consistency checks. - -3. Trust History Lookup +4. Trust History Lookup This is the algorithm that a validator uses to detect and resolve the situation in which a trust-anchor is out of sync with the DNSKEYs @@ -123,10 +233,10 @@ Internet-Draft Trust History Service February 2010 which is used to link various old DNSKEYs as published by the History Provider, to arrive from the outdated configured Trust Anchor to one that matches the current DNSKEY. The TALINK RR type is defined in - Section 2. + Section 3. When the algorithm below results in failure the trust history cannot - be build and a new trust anchor will need to be re-configured using + be built and a new trust anchor will need to be re-configured using another mechanism. Step 1: The validator performs a DNSKEY lookup to the target zone, @@ -144,12 +254,14 @@ Internet-Draft Trust History Service February 2010 The results can differ if a key-rollover is in progress and not all nameservers are in sync yet. This case can be detected by checking that the older keyset signs the newer and take the newer - as result keyset. The keysets are distinguished by the average - over the middle of the inception and expiration dates of the - signatures that are validated by the keyset itself. Otherwise, - the history lookup fails. If the check fails then the - inconsistency may be the result of spoofing, or compromise of - (DNS) infrastructure elements. + as result keyset. If both of the keysets sign each other, the + result keyset has the newest rrsig that validates it using the + other keyset. Use the the average over the middle of the + inception and expiration dates of the signatures that are + validated (and for serial arithmetic assume all dates on these + signatures lie within 2^(SERIAL_BITS-1) distance). If the keysets + do not sign each other then this is not a secure change in the + keyset and the history lookup fails. Step 2: Fetch the trust history list end points. Perform a query of QTYPE TALINK and QNAME the domain name that is configured to be @@ -159,24 +271,23 @@ Internet-Draft Trust History Service February 2010 Step 3: Go backwards through the trust history list as provided by the TALINK linked list. Verify that the keyset validly signs the next keyset. This is [RFC4034] validation, but the RRSIG - expiration date is ignored. [Editor note: Are we shure that there - are no server implementations that will not serve expired RRSIG, + expiration date is ignored. Replace the owner domain name with + the target zone name for verification. One of the keys that signs -Wijngaards & Kolkman Expires August 26, 2010 [Page 3] +Wijngaards & Kolkman Expires December 31, 2010 [Page 5] -Internet-Draft Trust History Service February 2010 +Internet-Draft Trust History Service June 2010 - are such 'smart' servers allowed by the specs? In other words do - we need clarification in the DNSSEC-updates document?] Replace - the owner domain name with the target zone name for verification. - One of the keys that signs the next keyset MUST have the SEP bit - set. The middle of inception and expiration date from the valid - signature MUST be older than that of the signature that validates - the next keys in the list. Query type TALINK to get previous and - next locations. + the next keyset MUST have the SEP bit set. The middle of + inception and expiration date from the valid signature MUST be + older than that of the signature that validates the next keys in + the list. Take the average if multiple signatures validate (and + for serial arithmetic assume all dates on these signatures lie + within 2^(SERIAL_BITS-1) distance). Query type TALINK to get + previous and next locations. If all SEP keys have the REVOKE flag set at this step, and the keyset is signed by all SEP keys, then continue but store that the @@ -198,7 +309,7 @@ Internet-Draft Trust History Service February 2010 store the result on stable storage. Use the new trust anchor for validation (if using [RFC5011], put it in state VALID). -4. Trust History Tracker +5. Trust History Tracker External trackers can poll the target zone DNSKEY RRset regularly. Ignore date changes in the RRSIG. Ignore changes to keys with no SEP @@ -220,16 +331,18 @@ Internet-Draft Trust History Service February 2010 -Wijngaards & Kolkman Expires August 26, 2010 [Page 4] + +Wijngaards & Kolkman Expires December 31, 2010 [Page 6] -Internet-Draft Trust History Service February 2010 +Internet-Draft Trust History Service June 2010 -5. Example +6. Example - In this example example.com is the History Provider for example.net. - The DNSKEY rdata and RRSIG rdata is omitted for brevity, it is a copy - and paste of the data from example.net. + In this example the trust history for the 'example.net' zone is + published in the 'example.com' namespace. The DNSKEY rdata and RRSIG + rdata is omitted for brevity, it is a copy and paste of the data from + example.net. $ORIGIN example.com. example.com. TALINK h0.example.com. h2.example.com. @@ -250,7 +363,7 @@ Internet-Draft Trust History Service February 2010 by providing the TALINK shown here at example.com at the apex of the example.net zone. The TALINK at example.com is then not needed. -6. Deployment +7. Deployment The trust history is advertised with TALINK RRs at the zone apex. These represent alternative history sources, that can be searched in @@ -275,10 +388,9 @@ Internet-Draft Trust History Service February 2010 - -Wijngaards & Kolkman Expires August 26, 2010 [Page 5] +Wijngaards & Kolkman Expires December 31, 2010 [Page 7] -Internet-Draft Trust History Service February 2010 +Internet-Draft Trust History Service June 2010 In general, the decision can be that any key - no matter how old or @@ -296,13 +408,11 @@ Internet-Draft Trust History Service February 2010 argument that perceived security is worse than no security. The history lookup can be used on its own. Then, the trust history - is used whenever the key rolls over and no polling is performed. - This has associated risks, in that the immediate rollover without - timeout that it provides could be abused, and certainly when taken - together with leap-of-faith such systems SHOULD inform their user - that the key has changed and urge them to do immediate checks. - Initially we put a hold down timer on such rollovers to mitigate the - abuse risks but these make following normal rollovers impossible. + is used whenever the key rolls over and no polling is performed. The + results of trust history lookup SHOULD be stored on stable storage, + so that the trust history lookup does not need to be performed if the + last results are okay and for use as trusted anchor in the next + history lookup. If a validator is also using [RFC5011] for the target zone, then the trust history algorithm SHOULD only be invoked if the [RFC5011] @@ -320,7 +430,7 @@ Internet-Draft Trust History Service February 2010 History Provider. The test History Provider provides access to a generated back-dated test history. -7. Security Considerations +8. Security Considerations The History Provider only provides copies of old data. If that historic data is altered or withheld the lookup algorithm fails @@ -329,15 +439,15 @@ Internet-Draft Trust History Service February 2010 to the original private keys (through theft, cryptanalisis, or otherwise), history can be altered without failure of the algorithm. Below we only consider MIMAs and assume the History Provider is a + trusted party. -Wijngaards & Kolkman Expires August 26, 2010 [Page 6] - -Internet-Draft Trust History Service February 2010 +Wijngaards & Kolkman Expires December 31, 2010 [Page 8] + +Internet-Draft Trust History Service June 2010 - trusted party. Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of TALINK and DNSKEY data, can present some alternate history. However @@ -376,25 +486,24 @@ Internet-Draft Trust History Service February 2010 Rollover with [RFC5011] revokes keys after use. If a History Provider is used, then such revoked keys SHOULD be used to perform - history tracking and history lookup. The old keys that the validator - starts with and final current keys MUST NOT be trusted if they are - revoked. + history tracking and history lookup. The trust anchor keys that the + validator has in its own storage and final current keys that it + stores MUST NOT be trusted if they are revoked. - Depending on choices by the validator operator, it may accept a leap- - of-faith, and possibly allow non-hold-down rollovers. Although this - allows very fast emergency rollover if all clients are known to do - trust-history lookups without the RFC5011-algorithm, it also allows - an attacker with the private key to attempt to take over a zone + If the validator operator chooses to operate trust history without + also using [RFC5011] the trust anchor does not get hold-down timer + protection. This has associated risks, in that the immediate + rollover without timeout that it provides could be abused (if private + keys are compromised). Such abuse could result in the stored lookup + results to become compromised. The key changes can be logged, to + inform operators and keep an audit trail. -Wijngaards & Kolkman Expires August 26, 2010 [Page 7] +Wijngaards & Kolkman Expires December 31, 2010 [Page 9] -Internet-Draft Trust History Service February 2010 - +Internet-Draft Trust History Service June 2010 - quickly and get validators to roll to a trust anchor of the - attacker's choosing. The SEP bit is checked to make sure that control over the KSK is necessary to change the keyset for the target zone. @@ -409,31 +518,35 @@ Internet-Draft Trust History Service February 2010 enables a replay attack of old DNSSEC data and signatures. This vulnerability exists also in plain DNSSEC. -8. IANA Considerations +9. IANA Considerations Resource record type TALINK has been defined using RFC5395 expert review, it has RR type number 58 (decimal). -9. Acknowledgments +10. Acknowledgments - Thanks to the people who provided review and suggestions, Joe Abley, - George Barwood, Edward Lewis, Michael StJohns, Bert Hubert, Mark - Andrews, Ted Lemon, Steve Crocker, Bill Manning, Eric Osterweil, - Wolfgang Nagele, Alfred Hoenes, Olafur Gudmundsson, Roy Arends and - Matthijs Mekking. + Thanks to the people who provided review and suggestions, Peter Koch, + Andrew Sullivan, Joe Abley, George Barwood, Edward Lewis, Michael + StJohns, Bert Hubert, Mark Andrews, Ted Lemon, Steve Crocker, Bill + Manning, Eric Osterweil, Wolfgang Nagele, Alfred Hoenes, Olafur + Gudmundsson, Roy Arends and Matthijs Mekking. -10. References +11. References -10.1. Informative References +11.1. Informative References [NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendations for Key Management", NIST SP 800-57, March 2007. + [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name + System KEY (DNSKEY) Resource Record (RR) Secure Entry + Point (SEP) Flag", RFC 3757, April 2004. + [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. -10.2. Normative References +11.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -443,10 +556,9 @@ Internet-Draft Trust History Service February 2010 - -Wijngaards & Kolkman Expires August 26, 2010 [Page 8] +Wijngaards & Kolkman Expires December 31, 2010 [Page 10] -Internet-Draft Trust History Service February 2010 +Internet-Draft Trust History Service June 2010 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. @@ -500,5 +612,5 @@ Authors' Addresses -Wijngaards & Kolkman Expires August 26, 2010 [Page 9] +Wijngaards & Kolkman Expires December 31, 2010 [Page 11] diff --git a/doc/draft/draft-ietf-dnsop-respsize-06.txt b/doc/draft/draft-ietf-dnsop-respsize-06.txt deleted file mode 100644 index b041925afbc..00000000000 --- a/doc/draft/draft-ietf-dnsop-respsize-06.txt +++ /dev/null @@ -1,640 +0,0 @@ - - - - - - - DNSOP Working Group Paul Vixie, ISC - INTERNET-DRAFT Akira Kato, WIDE - August 2006 - - DNS Referral Response Size Issues - - 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 BCP 79. - - 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. - - Copyright Notice - - Copyright (C) The Internet Society (2006). All Rights Reserved. - - - - - Abstract - - With a mandated default minimum maximum message size of 512 octets, - the DNS protocol presents some special problems for zones wishing to - expose a moderate or high number of authority servers (NS RRs). This - document explains the operational issues caused by, or related to - this response size limit, and suggests ways to optimize the use of - this limited space. Guidance is offered to DNS server implementors - and to DNS zone operators. - - - - - Expires January 2007 [Page 1] - - INTERNET-DRAFT August 2006 RESPSIZE - - - 1 - Introduction and Overview - - 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512 - octets. Even though this limitation was due to the required minimum IP - reassembly limit for IPv4, it became a hard DNS protocol limit and is - not implicitly relaxed by changes in transport, for example to IPv6. - - 1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits - larger responses by mutual agreement of the requester and responder. - The 512 octet message size limit will remain in practical effect until - there is widespread deployment of EDNS0 in DNS resolvers on the - Internet. - - 1.3. Since DNS responses include a copy of the request, the space - available for response data is somewhat less than the full 512 octets. - Negative responses are quite small, but for positive and delegation - responses, every octet must be carefully and sparingly allocated. This - document specifically addresses delegation response sizes. - - 2 - Delegation Details - - 2.1. RELEVANT PROTOCOL ELEMENTS - - 2.1.1. A delegation response will include the following elements: - - Header Section: fixed length (12 octets) - Question Section: original query (name, class, type) - Answer Section: empty, or a CNAME/DNAME chain - Authority Section: NS RRset (nameserver names) - Additional Section: A and AAAA RRsets (nameserver addresses) - - 2.1.2. If the total response size exceeds 512 octets, and if the data - that does not fit was "required", then the TC bit will be set - (indicating truncation). This will usually cause the requester to retry - using TCP, depending on what information was desired and what - information was omitted. For example, truncation in the authority - section is of no interest to a stub resolver who only plans to consume - the answer section. If a retry using TCP is needed, the total cost of - the transaction is much higher. See [RFC1123 6.1.3.2] for details on - the requirement that UDP be attempted before falling back to TCP. - - 2.1.3. RRsets are never sent partially unless TC bit set to indicate - truncation. When TC bit is set, the final apparent RRset in the final - non-empty section must be considered "possibly damaged" (see [RFC1035 - 6.2], [RFC2181 9]). - - - - Expires January 2007 [Page 2] - - INTERNET-DRAFT August 2006 RESPSIZE - - - 2.1.4. With or without truncation, the glue present in the additional - data section should be considered "possibly incomplete", and requesters - should be prepared to re-query for any damaged or missing RRsets. Note - that truncation of the additional data section might not be signalled - via the TC bit since additional data is often optional (see discussion - in [RFC4472 B]). - - 2.1.5. DNS label compression allows a domain name to be instantiated - only once per DNS message, and then referenced with a two-octet - "pointer" from other locations in that same DNS message (see [RFC1035 - 4.1.4]). If all nameserver names in a message share a common parent - (for example, all ending in ".ROOT-SERVERS.NET"), then more space will - be available for incompressable data (such as nameserver addresses). - - 2.1.6. The query name can be as long as 255 octets of network data. In - this worst case scenario, the question section will be 259 octets in - size, which would leave only 240 octets for the authority and additional - sections (after deducting 12 octets for the fixed length header.) - - 2.2. ADVICE TO ZONE OWNERS - - 2.2.1. Average and maximum question section sizes can be predicted by - the zone owner, since they will know what names actually exist, and can - measure which ones are queried for most often. Note that if the zone - contains any wildcards, it is possible for maximum length queries to - require positive responses, but that it is reasonable to expect - truncation and TCP retry in that case. For cost and performance - reasons, the majority of requests should be satisfied without truncation - or TCP retry. - - 2.2.2. Some queries to non-existing names can be large, but this is not - a problem because negative responses need not contain any answer, - authority or additional records. See [RFC2308 2.1] for more information - about the format of negative responses. - - 2.2.3. The minimum useful number of name servers is two, for redundancy - (see [RFC1034 4.1]). A zone's name servers should be reachable by all - IP transport protocols (e.g., IPv4 and IPv6) in common use. - - 2.2.4. The best case is no truncation at all. This is because many - requesters will retry using TCP immediately, or will automatically re- - query for RRsets that are possibly truncated, without considering - whether the omitted data was actually necessary. - - - - - - Expires January 2007 [Page 3] - - INTERNET-DRAFT August 2006 RESPSIZE - - - 2.3. ADVICE TO SERVER IMPLEMENTORS - - 2.3.1. In case of multi-homed name servers, it is advantageous to - include an address record from each of several name servers before - including several address records for any one name server. If address - records for more than one transport (for example, A and AAAA) are - available, then it is advantageous to include records of both types - early on, before the message is full. - - 2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type, - class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME). - Each A RR will require 16 octets, and each AAAA RR will require 28 - octets. - - 2.3.3. While DNS distinguishes between necessary and optional resource - records, this distinction is according to protocol elements necessary to - signify facts, and takes no official notice of protocol content - necessary to ensure correct operation. For example, a nameserver name - that is in or below the zone cut being described by a delegation is - "necessary content," since there is no way to reach that zone unless the - parent zone's delegation includes "glue records" describing that name - server's addresses. - - 2.3.4. It is also necessary to distinguish between "explicit truncation" - where a message could not contain enough records to convey its intended - meaning, and so the TC bit has been set, and "silent truncation", where - the message was not large enough to contain some records which were "not - required", and so the TC bit was not set. - - 2.3.5. A delegation response should prioritize glue records as follows. - - first - All glue RRsets for one name server whose name is in or below the - zone being delegated, or which has multiple address RRsets (currently - A and AAAA), or preferably both; - - second - Alternate between adding all glue RRsets for any name servers whose - names are in or below the zone being delegated, and all glue RRsets - for any name servers who have multiple address RRsets (currently A - and AAAA); - - thence - All other glue RRsets, in any order. - - - - - Expires January 2007 [Page 4] - - INTERNET-DRAFT August 2006 RESPSIZE - - - Whenever there are multiple candidates for a position in this priority - scheme, one should be chosen on a round-robin or fully random basis. - - The goal of this priority scheme is to offer "necessary" glue first, - avoiding silent truncation for this glue if possible. - - 2.3.6. If any "necessary content" is silently truncated, then it is - advisable that the TC bit be set in order to force a TCP retry, rather - than have the zone be unreachable. Note that a parent server's proper - response to a query for in-child glue or below-child glue is a referral - rather than an answer, and that this referral MUST be able to contain - the in-child or below-child glue, and that in outlying cases, only EDNS - or TCP will be large enough to contain that data. - - 3 - Analysis - - 3.1. An instrumented protocol trace of a best case delegation response - follows. Note that 13 servers are named, and 13 addresses are given. - This query was artificially designed to exactly reach the 512 octet - limit. - - ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 - ;; QUERY SECTION: - ;; [23456789.123456789.123456789.\ - 123456789.123456789.123456789.com A IN] ;; @80 - - ;; AUTHORITY SECTION: - com. 86400 NS E.GTLD-SERVERS.NET. ;; @112 - com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 - com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 - com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 - com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 - com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 - com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 - com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 - com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 - com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 - com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 - com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 - com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 - - - - - - - - - Expires January 2007 [Page 5] - - INTERNET-DRAFT August 2006 RESPSIZE - - - ;; ADDITIONAL SECTION: - A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 - B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 - C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 - D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 - E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 - F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 - G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 - H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 - I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 - J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 - K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 - L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 - M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 - - ;; MSG SIZE sent: 80 rcvd: 512 - - 3.2. For longer query names, the number of address records supplied will - be lower. Furthermore, it is only by using a common parent name (which - is GTLD-SERVERS.NET in this example) that all 13 addresses are able to - fit, due to the use of DNS compression pointers in the last 12 - occurances of the parent domain name. The following output from a - response simulator demonstrates these properties. - - % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br - a.dns.br requires 10 bytes - b.dns.br requires 4 bytes - c.dns.br requires 4 bytes - d.dns.br requires 4 bytes - # of NS: 4 - For maximum size query (255 byte): - only A is considered: # of A is 4 (green) - A and AAAA are considered: # of A+AAAA is 3 (yellow) - preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow) - For average size query (64 byte): - only A is considered: # of A is 4 (green) - A and AAAA are considered: # of A+AAAA is 4 (green) - preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green) - - - - - - - - - - - Expires January 2007 [Page 6] - - INTERNET-DRAFT August 2006 RESPSIZE - - - % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int - ns-ext.isc.org requires 16 bytes - ns.psg.com requires 12 bytes - ns.ripe.net requires 13 bytes - ns.eu.int requires 11 bytes - # of NS: 4 - For maximum size query (255 byte): - only A is considered: # of A is 4 (green) - A and AAAA are considered: # of A+AAAA is 3 (yellow) - preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow) - For average size query (64 byte): - only A is considered: # of A is 4 (green) - A and AAAA are considered: # of A+AAAA is 4 (green) - preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green) - - (Note: The response simulator program is shown in Section 5.) - - Here we use the term "green" if all address records could fit, or - "yellow" if two or more could fit, or "orange" if only one could fit, or - "red" if no address record could fit. It's clear that without a common - parent for nameserver names, much space would be lost. For these - examples we use an average/common name size of 15 octets, befitting our - assumption of GTLD-SERVERS.NET as our common parent name. - - We're assuming a medium query name size of 64 since that is the typical - size seen in trace data at the time of this writing. If - Internationalized Domain Name (IDN) or any other technology which - results in larger query names be deployed significantly in advance of - EDNS, then new measurements and new estimates will have to be made. - - 4 - Conclusions - - 4.1. The current practice of giving all nameserver names a common parent - (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS - responses and allows for more nameservers to be enumerated than would - otherwise be possible, since the common parent domain name only appears - once in a DNS message and is referred to via "compression pointers" - thereafter. - - 4.2. If all nameserver names for a zone share a common parent, then it - is operationally advisable to make all servers for the zone thus served - also be authoritative for the zone of that common parent. For example, - the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively - for the ROOT-SERVERS.NET. This is to ensure that the zone's servers - always have the zone's nameservers' glue available when delegating, and - - - - Expires January 2007 [Page 7] - - INTERNET-DRAFT August 2006 RESPSIZE - - - will be able to respond with answers rather than referrals if a - requester who wants that glue comes back asking for it. In this case - the name server will likely be a "stealth server" -- authoritative but - unadvertised in the glue zone's NS RRset. See [RFC1996 2] for more - information about stealth servers. - - 4.3. Thirteen (13) is the effective maximum number of nameserver names - usable traditional (non-extended) DNS, assuming a common parent domain - name, and given that implicit referral response truncation is - undesirable in the average case. - - 4.4. Multi-homing of name servers within a protocol family is - inadvisable since the necessary glue RRsets (A or AAAA) are atomically - indivisible, and will be larger than a single resource record. Larger - RRsets are more likely to lead to or encounter truncation. - - 4.5. Multi-homing of name servers across protocol families is less - likely to lead to or encounter truncation, partly because multiprotocol - clients are more likely to speak EDNS which can use a larger response - size limit, and partly because the resource records (A and AAAA) are in - different RRsets and are therefore divisible from each other. - - 4.6. Name server names which are at or below the zone they serve are - more sensitive to referral response truncation, and glue records for - them should be considered "less optional" than other glue records, in - the assembly of referral responses. - - 4.7. If a zone is served by thirteen (13) name servers having a common - parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a - single address record in some protocol family (e.g., an A RR), then all - thirteen name servers or any subset thereof could multi-home in a second - protocol family by adding a second address record (e.g., an AAAA RR) - without reducing the reachability of the zone thus served. - - 5 - Source Code - - #!/usr/bin/perl - # - # SYNOPSIS - # repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ... - # if all queries are assumed to have a same zone suffix, - # such as "jp" in JP TLD servers, specify it in -z option - # - use strict; - use Getopt::Std; - - - - Expires January 2007 [Page 8] - - INTERNET-DRAFT August 2006 RESPSIZE - - - my ($sz_msg) = (512); - my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28); - my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2); - my (%namedb, $name, $nssect, %opts, $optz); - my $n_ns = 0; - - getopt('z', %opts); - if (defined($opts{'z'})) { - server_name_len($opts{'z'}); # just register it - } - - foreach $name (@ARGV) { - my $len; - $n_ns++; - $len = server_name_len($name); - print "$name requires $len bytes\n"; - $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl - + $sz_rdlen + $len; - } - print "# of NS: $n_ns\n"; - arsect(255, $nssect, $n_ns, "maximum"); - arsect(64, $nssect, $n_ns, "average"); - - sub server_name_len { - my ($name) = @_; - my (@labels, $len, $n, $suffix); - - $name =~ tr/A-Z/a-z/; - @labels = split(/\./, $name); - $len = length(join('.', @labels)) + 2; - for ($n = 0; $#labels >= 0; $n++, shift @labels) { - $suffix = join('.', @labels); - return length($name) - length($suffix) + $sz_ptr - if (defined($namedb{$suffix})); - $namedb{$suffix} = 1; - } - return $len; - } - - sub arsect { - my ($sz_query, $nssect, $n_ns, $cond) = @_; - my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect); - $ansect = $sz_query + 1 + $sz_type + $sz_class; - $space = $sz_msg - $sz_header - $ansect - $nssect; - $n_a = atmost(int($space / $sz_rr_a), $n_ns); - - - - Expires January 2007 [Page 9] - - INTERNET-DRAFT August 2006 RESPSIZE - - - $n_a_aaaa = atmost(int($space - / ($sz_rr_a + $sz_rr_aaaa)), $n_ns); - $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) - / $sz_rr_aaaa), $n_ns); - printf "For %s size query (%d byte):\n", $cond, $sz_query; - printf " only A is considered: "; - printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns); - printf " A and AAAA are considered: "; - printf "# of A+AAAA is %d (%s)\n", - $n_a_aaaa, &judge($n_a_aaaa, $n_ns); - printf " preferred-glue A is assumed: "; - printf "# of A is %d, # of AAAA is %d (%s)\n", - $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns); - } - - sub judge { - my ($n, $n_ns) = @_; - return "green" if ($n >= $n_ns); - return "yellow" if ($n >= 2); - return "orange" if ($n == 1); - return "red"; - } - - sub atmost { - my ($a, $b) = @_; - return 0 if ($a < 0); - return $b if ($a > $b); - return $a; - } - - 6 - Security Considerations - - The recommendations contained in this document have no known security - implications. - - 7 - IANA Considerations - - This document does not call for changes or additions to any IANA - registry. - - 8 - Acknowledgement - - The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews - for their valuable comments and suggestions. - - - - - Expires January 2007 [Page 10] - - INTERNET-DRAFT August 2006 RESPSIZE - - - This work was supported by the US National Science Foundation (research - grant SCI-0427144) and DNS-OARC. - - 9 - References - - [RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities", - RFC1034, November 1987. - - [RFC1035] Mockapetris, P.V., "Domain names - Implementation and - Specification", RFC1035, November 1987. - - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - - Application and Support", RFC1123, October 1989. - - [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", RFC1996, August 1996. - - [RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification", - RFC2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC2308, March 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671, - August 1999. - - [RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration - and Issues with IPV6 DNS", April 2006. - - 10 - Authors' Addresses - - Paul Vixie - Internet Systems Consortium, Inc. - 950 Charter Street - Redwood City, CA 94063 - +1 650 423 1301 - vixie@isc.org - - Akira Kato - University of Tokyo, Information Technology Center - 2-11-16 Yayoi Bunkyo - Tokyo 113-8658, JAPAN - +81 3 5841 2750 - kato@wide.ad.jp - - - - - Expires January 2007 [Page 11] - - INTERNET-DRAFT August 2006 RESPSIZE - - - Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - 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 provided by the IETF - Administrative Support Activity (IASA). - - - - - Expires January 2007 [Page 12] - - diff --git a/doc/draft/draft-ietf-dnsop-respsize-14.txt b/doc/draft/draft-ietf-dnsop-respsize-14.txt new file mode 100644 index 00000000000..d95634eda38 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-respsize-14.txt @@ -0,0 +1,784 @@ + + + +Internet Engineering Task Force P. Vixie +Internet-Draft Internet Systems Consortium +Intended status: Informational A. Kato +Expires: November 11, 2012 Keio University/WIDE Project + May 10, 2012 + + + DNS Referral Response Size Issues + draft-ietf-dnsop-respsize-14 + +Abstract + + With a mandated default minimum maximum UDP message size of 512 + octets, the DNS protocol presents some special problems for zones + wishing to expose a moderate or high number of authority servers (NS + RRs). This document explains the operational issues caused by, or + related to this response size limit, and suggests ways to optimize + the use of this limited space. Guidance is offered to DNS server + implementors and to DNS zone operators. + +Status of this Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + 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." + + This Internet-Draft will expire on November 11, 2012. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + + + +Vixie & Kato Expires November 11, 2012 [Page 1] + +Internet-Draft DNS Referral Response Size May 2012 + + + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + +1. Introduction and Overview + + The original DNS standard limited the UDP message size to 512 octets + (see Section 4.2.1 of [RFC1035]). Even though this limitation was + due to the required minimum IP reassembly limit for IPv4, it became a + hard DNS protocol limit and is not implicitly relaxed by changes in a + network layer protocol, for example to IPv6. + + The EDNS (Extension Mechanisms for DNS) protocol extension starting + with version 0 permits larger responses by mutual agreement of the + requester and responder (see Section 4.3 and Section 6.2 of + [RFC2671bis]), and it is recommended to support EDNS. The 512 octets + UDP message size limit will remain in practical effect until + virtually all DNS servers and resolvers support EDNS. + + Since DNS responses include a copy of the request, the space + available for response data is somewhat less than the full 512 + octets. Negative responses are quite small, but for positive and + referral responses, every octet must be carefully and sparingly + allocated. While the response size of positive responses is also a + concern in [RFC3226], this document specifically addresses referral + response size. + + While more than twelve years passed since the publication of the + original EDNS0 document [RFC2671], approximately 65% of the clients + support it as observed at a root name server and this fraction has + not changed in recent few years. The long tail of EDNS deployment + may eventually be measured in decades. + + Even if EDNS deployment reached 100% of all DNS initiators and + responders there will still be cases when path MTU limitations or IP + + + +Vixie & Kato Expires November 11, 2012 [Page 2] + +Internet-Draft DNS Referral Response Size May 2012 + + + fragmentation/reassembly problems in firewalls and other middleboxes + will cause EDNS failures which leads to non-extended DNS retries. A + smaller referral response will always be better than a larger one if + the same end result can be achieved either way. See [RFC5625], + [SSAC035], and Section 6.2.6 of [RFC2671bis] for details. + + +2. Delegation Details + +2.1. Relevant Protocol Elements + + A positive delegation response will include the following elements: + + Header Section: fixed length (12 octets) + Question Section: original query (name, class, type) + Answer Section: empty, or a CNAME/DNAME chain + Authority Section: NS RRset (nameserver names) + Additional Section: A and AAAA RRsets (nameserver addresses) + Note: CNAME defines a canonical name ([RFC1034]) while DNAME maps an + entire subtree to another domain ([RFC2672]). + + If the total size of the UDP response exceeds 512 octets or the size + advertised in EDNS, and if the data that does not fit was "required", + then the TC bit will be set (indicating truncation). This will + usually cause the requester to retry using TCP, depending on what + information was desired and what information was omitted. For + example, truncation in the authority section is of no interest to a + stub resolver who only plans to consume the answer section. If a + retry using TCP is needed, the total cost of the transaction is much + higher. See Section 6.1.3.2 of [RFC1123] for details on the + requirement that UDP be attempted before falling back to TCP. + + RRsets (Resource Record Set, see [RFC2136]) are never sent partially + unless the TC bit is set to indicate truncation. When the TC bit is + set, the final apparent RRset in the final non-empty section must be + considered "possibly damaged" (see Section 6.2 of [RFC1035] and + Section 9 of [RFC2181]). + + With or without truncation, the glue present in the additional data + section should be considered "possibly incomplete", and requesters + should be prepared to re-query for any damaged or missing RRsets. + Note that truncation of the additional data section might not be + signaled via the TC bit since additional data is often optional (see + discussion in Appendix B of [RFC4472]). + + DNS label compression allows the component labels of a domain name to + be instantiated exactly once per DNS message, and then referenced + with a two-octet "pointer" from other locations in that same DNS + + + +Vixie & Kato Expires November 11, 2012 [Page 3] + +Internet-Draft DNS Referral Response Size May 2012 + + + message (see Section 4.1.4 of [RFC1035]). If all nameserver names in + a message share a common parent (for example, all of them are in + "ROOT-SERVERS.NET." zone), then more space will be available for + incompressible data (such as nameserver addresses). + + The query name can be as long as 255 octets of network data. In this + worst case scenario, the question section will be 259 octets in size, + which would leave only 240 octets for the authority and additional + sections (after deducting 12 octets for the fixed length header) in a + referral. + +2.2. Advice to Zone Owners + + Average and maximum question section sizes can be predicted by the + zone owner, since they will know what names actually exist and can + measure which ones are queried for most often. Note that if the zone + contains any wildcards, it is possible for maximum length queries to + require positive responses, but that it is reasonable to expect + truncation and TCP retry in that case. For cost and performance + reasons, the majority of requests should be satisfied without + truncation or TCP retry. + + Some queries to non-existing names can be large, but this is not a + problem because negative responses need not contain any answer, + authority or additional records. See Section 2.1 of [RFC2308] for + more information about the format of negative responses. + + The minimum useful number of name servers is two, for redundancy (see + Section 4.1 of [RFC1034]). A zone's name servers should be reachable + by all IP protocols versions (e.g., IPv4 and IPv6) in common use. As + long as the servers are well managed, the server serving IPv6 might + be different from the server serving IPv4 sharing the same server + name. + + The best case is no truncation at all. This is because many + requesters will retry using TCP immediately, or will automatically + requery for RRsets that are possibly truncated, without considering + whether the omitted data was actually necessary. + + Anycasting [RFC3258] is a useful tool for performance and reliability + without increasing the size of referral responses. + + While it is irrelevant to the response size issue, all zones have to + be served via IPv4 as well to avoid name space fragmentation + [RFC3901]. + + + + + + +Vixie & Kato Expires November 11, 2012 [Page 4] + +Internet-Draft DNS Referral Response Size May 2012 + + +2.3. Advice to Server Implementors + + Each NS RR for a zone will add 12 fixed octets (name, type, class, + ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME). + Each A RR will require 16 octets, and each AAAA RR will require 28 + octets. + + While DNS distinguishes between necessary and optional resource + records, this distinction is according to protocol elements necessary + to signify facts, and takes no official notice of protocol content + necessary to ensure correct operation. For example, a nameserver + name that is in or below the zone cut being described by a delegation + is "necessary content", since there is no way to reach that zone + unless the parent zone's delegation includes "glue records" + describing that name server's addresses. + + Recall that the TC bit is only set when a required RRset can not be + included in its entirety (see Section 9 of [RFC2181]). Even when + some of the RRsets to be included in the additional section don't fit + in the response size, the TC bit isn't set. These RRsets may be + important for a referral. Some DNS implementations try to resolve + these missing glue records separately which will introduce extra + queries and extra time to resolve a given name. + + A delegation response should prioritize glue records as follows. + + first: + All glue RRsets for one name server whose name is in or below the + zone being delegated, or which has multiple address RRsets + (currently A and AAAA), or preferably both; + second: + Alternate between adding all glue RRsets for any name servers + whose names are in or below the zone being delegated, and all + glue RRsets for any name servers who have multiple address RRsets + (currently A and AAAA); + thence: + All other glue RRsets, in any order. + + Whenever there are multiple candidates for a position in this + priority scheme, one should be chosen on a round-robin or fully + random basis. The goal of this priority scheme is to offer + "necessary" glue first to fill into the response if possible. + + If any "necessary" content cannot be fit in the response, then it is + advisable that the TC bit be set in order to force a TCP retry, + rather than have the zone be unreachable. Note that a parent + server's proper response to a query for in-child glue or below-child + glue is a referral rather than an answer, and that this referral must + + + +Vixie & Kato Expires November 11, 2012 [Page 5] + +Internet-Draft DNS Referral Response Size May 2012 + + + be able to contain the in-child or below-child glue, and that in + outlying cases, only EDNS or TCP will be large enough to contain that + data. + + The glue record order should be independent of the version of IP used + in the query because the DNS server might just see a query from an + intermediate server rather than the query from the original client. + + +3. Analysis + + An instrumented protocol trace of a best case delegation response is + shown in Figure 1. Note that 13 servers are named, and 13 addresses + are given. This query was artificially designed to exactly reach the + 512 octets limit. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vixie & Kato Expires November 11, 2012 [Page 6] + +Internet-Draft DNS Referral Response Size May 2012 + + + ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 + ;; QUERY SECTION: + ;; [23456789.123456789.123456789.\ + 123456789.123456789.123456789.com A IN] ;; @80 + + ;; AUTHORITY SECTION: + com. 172800 NS E.GTLD-SERVERS.NET. ;; @112 + com. 172800 NS F.GTLD-SERVERS.NET. ;; @128 + com. 172800 NS G.GTLD-SERVERS.NET. ;; @144 + com. 172800 NS H.GTLD-SERVERS.NET. ;; @160 + com. 172800 NS I.GTLD-SERVERS.NET. ;; @176 + com. 172800 NS J.GTLD-SERVERS.NET. ;; @192 + com. 172800 NS K.GTLD-SERVERS.NET. ;; @208 + com. 172800 NS L.GTLD-SERVERS.NET. ;; @224 + com. 172800 NS M.GTLD-SERVERS.NET. ;; @240 + com. 172800 NS A.GTLD-SERVERS.NET. ;; @256 + com. 172800 NS B.GTLD-SERVERS.NET. ;; @272 + com. 172800 NS C.GTLD-SERVERS.NET. ;; @288 + com. 172800 NS D.GTLD-SERVERS.NET. ;; @304 + + + ;; ADDITIONAL SECTION: + A.GTLD-SERVERS.NET. 172800 A 192.5.6.30 ;; @320 + B.GTLD-SERVERS.NET. 172800 A 192.33.14.30 ;; @336 + C.GTLD-SERVERS.NET. 172800 A 192.26.92.30 ;; @352 + D.GTLD-SERVERS.NET. 172800 A 192.31.80.30 ;; @368 + E.GTLD-SERVERS.NET. 172800 A 192.12.94.30 ;; @384 + F.GTLD-SERVERS.NET. 172800 A 192.35.51.30 ;; @400 + G.GTLD-SERVERS.NET. 172800 A 192.42.93.30 ;; @416 + H.GTLD-SERVERS.NET. 172800 A 192.54.112.30 ;; @432 + I.GTLD-SERVERS.NET. 172800 A 192.43.172.30 ;; @448 + J.GTLD-SERVERS.NET. 172800 A 192.48.79.30 ;; @464 + K.GTLD-SERVERS.NET. 172800 A 192.52.178.30 ;; @480 + L.GTLD-SERVERS.NET. 172800 A 192.41.162.30 ;; @496 + M.GTLD-SERVERS.NET. 172800 A 192.55.83.30 ;; @512 + + ;; MSG SIZE sent: 80 rcvd: 512 + + + Figure 1 + + For longer query names, the number of address records supplied will + be lower. Furthermore, it is only by using a common parent name + (which is "GTLD-SERVERS.NET." in this example) that all 13 addresses + are able to fit, due to the use of DNS compression pointers in the + last 12 occurrences of the parent domain name. The outputs from the + response simulator in Appendix A (written in perl [PERL]) shown in + Figure 2 and Figure 3 demonstrate these properties. + + + +Vixie & Kato Expires November 11, 2012 [Page 7] + +Internet-Draft DNS Referral Response Size May 2012 + + + % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br + a.dns.br requires 10 bytes + b.dns.br requires 4 bytes + c.dns.br requires 4 bytes + d.dns.br requires 4 bytes + # of NS: 4 + For maximum size query (255 byte): + only A is considered: # of A is 4 (green) + A and AAAA are considered: # of A+AAAA is 3 (yellow) + preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow) + For average size query (64 byte): + only A is considered: # of A is 4 (green) + A and AAAA are considered: # of A+AAAA is 4 (green) + preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green) + + + Figure 2 + + + % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int + ns-ext.isc.org requires 16 bytes + ns.psg.com requires 12 bytes + ns.ripe.net requires 13 bytes + ns.eu.int requires 11 bytes + # of NS: 4 + For maximum size query (255 byte): + only A is considered: # of A is 4 (green) + A and AAAA are considered: # of A+AAAA is 3 (yellow) + preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow) + For average size query (64 byte): + only A is considered: # of A is 4 (green) + A and AAAA are considered: # of A+AAAA is 4 (green) + preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green) + + Figure 3 + + Here we use the term "green" if all address records could fit, or + "yellow" if two or more could fit, or "orange" if only one could fit, + or "red" if no address record could fit. It's clear that without a + common parent for nameserver names, much space would be lost. For + these examples we use an average/common name size of 15 octets, + befitting our assumption of "GTLD-SERVERS.NET." as our common parent + name. + + We're assuming a medium query name size of 64 since that is the + typical size seen in trace data at the time of this writing. If + Internationalized Domain Name (IDN) or any other technology that + results in larger query names be deployed significantly in advance of + + + +Vixie & Kato Expires November 11, 2012 [Page 8] + +Internet-Draft DNS Referral Response Size May 2012 + + + EDNS, then new measurements and new estimates will have to be made. + + +4. Conclusions + + The current practice of giving all nameserver names a common parent + (such as "GTLD-SERVERS.NET." or "ROOT-SERVERS.NET.") saves space in + DNS responses and allows for more nameservers to be enumerated than + would otherwise be possible, since the common parent domain name only + appears once in a DNS message and is referred to via "compression + pointers" thereafter. + + If all nameserver names for a zone share a common parent, then it is + operationally advisable to make all servers for the zone thus served + also be authoritative for the zone of that common parent. For + example, the root name servers (?.ROOT-SERVERS.NET.) can answer + authoritatively for the ROOT-SERVERS.NET. zone. This is to ensure + that the zone's servers always have the zone's nameservers' glue + available when delegating, and will be able to respond with answers + rather than referrals if a requester who wants that glue comes back + asking for it. In this case the name server will likely be a + "stealth server" -- authoritative but unadvertised in the glue zone's + NS RRset. See Section 2 of [RFC1996] for more information about + stealth servers. + + Thirteen (13) is the effective maximum number of nameserver names + usable with traditional (non-extended) DNS, assuming a common parent + domain name, and given that implicit referral response truncation is + undesirable in the average case. + + More than one address record in a protocol family per server is + inadvisable since the necessary glue RRsets (A or AAAA) are + atomically indivisible, and will be larger than a single resource + record. Larger RRsets are more likely to lead to or encounter + truncation. + + More than one address record across protocol families is less likely + to lead to or encounter truncation, partly because multiprotocol + clients, which are required to handle larger RRsets such as AAAA RRs, + are more likely to speak EDNS, which can use a larger UDP response + size limit, and partly because the resource records (A and AAAA) are + in different RRsets and are therefore divisible from each other. + + Name server names that are at or below the zone they serve are more + sensitive to referral response truncation, and glue records for them + should be considered "more important" than other glue records, in the + assembly of referral responses. + + + + +Vixie & Kato Expires November 11, 2012 [Page 9] + +Internet-Draft DNS Referral Response Size May 2012 + + +5. Security Considerations + + The recommendations contained in this document have no known security + implications. + + +6. IANA Considerations + + This document does not call for changes or additions to any IANA + registry. + + +7. Acknowledgement + + The authors thank Peter Koch, Rob Austein, Joe Abley, Mark Andrews, + Kenji Rikitake, Stephane Bortzmeyer, Olafur Gudmundsson, Alfred + Hoenes, Alexander Mayrhofer, and Ray Bellis for their valuable + comments and suggestions. + + This work was supported by the US National Science Foundation + (research grant SCI-0427144) and DNS-OARC. + + +8. References + +8.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + +8.2. Informative References + + [PERL] Wall, L., Christiansen, T., and J. Orwant, "Programming + Perl, 3rd ed.", ISBN 0-596-00027-8, July 2000. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - Application + and Support", STD 3, RFC 1123, October 1989. + + [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, August 1996. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + + + +Vixie & Kato Expires November 11, 2012 [Page 10] + +Internet-Draft DNS Referral Response Size May 2012 + + + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC2671bis] + Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms + for DNS (EDNS0)", draft-ietf-dnsext-rfc2671bis-edns0-08 , + February 2012. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", + RFC 2672, August 1999. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via + Shared Unicast Addresses", RFC 3258, April 2002. + + [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational + Guidelines", BCP 91, RFC 3901, September 2004. + + [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational + Considerations and Issues with IPv6 DNS", RFC 4472, + April 2006. + + [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", + BCP 152, RFC 5625, August 2009. + + [SSAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on + Broadband Routers and Firewalls", SSAC 035, + September 2008. + + +Appendix A. The response simulator program + + + #!/usr/bin/perl + # + # SYNOPSIS + # respsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ... + # if all queries are assumed to have a same zone suffix, + # such as "jp" in JP TLD servers, specify it in -z option + # + + + +Vixie & Kato Expires November 11, 2012 [Page 11] + +Internet-Draft DNS Referral Response Size May 2012 + + + use strict; + use Getopt::Std; + + my ($sz_msg) = (512); + my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28); + my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2); + my (%namedb, $name, $nssect, %opts, $optz); + my $n_ns = 0; + + getopt('z', %opts); + if (defined($opts{'z'})) { + server_name_len($opts{'z'}); # just register it + } + + foreach $name (@ARGV) { + my $len; + $n_ns++; + $len = server_name_len($name); + print "$name requires $len bytes\n"; + $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl + + $sz_rdlen + $len; + } + print "# of NS: $n_ns\n"; + arsect(255, $nssect, $n_ns, "maximum"); + arsect(64, $nssect, $n_ns, "average"); + + sub server_name_len { + my ($name) = @_; + my (@labels, $len, $n, $suffix); + + $name =~ tr/A-Z/a-z/; + @labels = split(/\./, $name); + $len = length(join('.', @labels)) + 2; + for ($n = 0; $#labels >= 0; $n++, shift @labels) { + $suffix = join('.', @labels); + return length($name) - length($suffix) + $sz_ptr + if (defined($namedb{$suffix})); + $namedb{$suffix} = 1; + } + return $len; + } + + sub arsect { + my ($sz_query, $nssect, $n_ns, $cond) = @_; + my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect); + $ansect = $sz_query + $sz_type + $sz_class; + $space = $sz_msg - $sz_header - $ansect - $nssect; + $n_a = atmost(int($space / $sz_rr_a), $n_ns); + + + +Vixie & Kato Expires November 11, 2012 [Page 12] + +Internet-Draft DNS Referral Response Size May 2012 + + + $n_a_aaaa = atmost(int($space + / ($sz_rr_a + $sz_rr_aaaa)), $n_ns); + $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) + / $sz_rr_aaaa), $n_ns); + printf "For %s size query (%d byte):\n", $cond, $sz_query; + printf " only A is considered: "; + printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns); + printf " A and AAAA are considered: "; + printf "# of A+AAAA is %d (%s)\n", + $n_a_aaaa, &judge($n_a_aaaa, $n_ns); + printf " preferred-glue A is assumed: "; + printf "# of A is %d, # of AAAA is %d (%s)\n", + $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns); + } + + sub judge { + my ($n, $n_ns) = @_; + return "green" if ($n >= $n_ns); + return "yellow" if ($n >= 2); + return "orange" if ($n == 1); + return "red"; + } + + sub atmost { + my ($a, $b) = @_; + return 0 if ($a < 0); + return $b if ($a > $b); + return $a; + } + + +Authors' Addresses + + Paul Vixie + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + US + + Phone: +1 650 423 1300 + Email: vixie@isc.org + + + + + + + + + + +Vixie & Kato Expires November 11, 2012 [Page 13] + +Internet-Draft DNS Referral Response Size May 2012 + + + Akira Kato + Keio University/WIDE Project + Graduate School of Media Design, 4-1-1 Hiyoshi + Kohoku, Yokohama 223-8526 + JP + + Phone: +81 45 564 2490 + Email: kato@wide.ad.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vixie & Kato Expires November 11, 2012 [Page 14] + diff --git a/doc/draft/draft-irtf-rrg-ilnp-dns-05.txt b/doc/draft/draft-irtf-rrg-ilnp-dns-05.txt deleted file mode 100644 index 840a8caede4..00000000000 --- a/doc/draft/draft-irtf-rrg-ilnp-dns-05.txt +++ /dev/null @@ -1,1235 +0,0 @@ - - - - - - -Internet Draft RJ Atkinson -draft-irtf-rrg-ilnp-dns-05.txt Consultant -Expires: 29 NOV 2012 SN Bhatti -Category: Experimental U. St Andrews - Scott Rose - US NIST - 29 May 2012 - - - DNS Resource Records for ILNP - draft-irtf-rrg-ilnp-dns-05.txt - - -STATUS OF THIS MEMO - - Distribution of this memo is unlimited. - - Copyright (c) 2012 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with - respect to this document. Code Components extracted from this - document must include Simplified BSD License text as described in - Section 4.e of the Trust Legal Provisions and are provided - without warranty as described in the Simplified BSD License. - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - This document may contain material from IETF Documents or - IETF Contributions published or made publicly available - before November 10, 2008. The person(s) controlling the - copyright in some of this material may not have granted the - IETF Trust the right to allow modifications of such material - outside the IETF Standards Process. Without obtaining an - adequate license from the person(s) controlling the copyright - in such materials, this document may not be modified outside - the IETF Standards Process, and derivative works of it may not - be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages - other than English. - - Internet-Drafts are working documents of the Internet - Engineering Task Force (IETF), its areas, and its working - - - -Atkinson et alia Expires in 6 months [Page 1] - -Internet Draft -2-29 MAY 2012 - - - 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/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - This document is not on the IETF standards-track and does not - specify any level of standard. This document merely provides - information for the Internet community. - - This document is part of the ILNP document set, which has had - extensive review within the IRTF Routing Research Group. ILNP is - one of the recommendations made by the RG Chairs. Separately, - various refereed research papers on ILNP have also been published - during this decade. So the ideas contained herein have had much - broader review than the IRTF Routing RG. The views in this - document were considered controversial by the Routing RG, but the - RG reached a consensus that the document still should be - published. The Routing RG has had remarkably little consensus on - anything, so virtually all Routing RG outputs are considered - controversial. - -ABSTRACT - - This note describes additional optional Resource Records for use - with the Domain Name System (DNS). These optional resource - records are for use with the Identifier-Locator Network Protocol - (ILNP). This document is a product of the IRTF Routing RG. - -TABLE OF CONTENTS - - 1. Introduction.............................2 - 2. New Resource Records.....................3 - 2.1 NID Resource Record.....................3 - 2.2 L32 Resource Record......................5 - 2.3 L64 Resource Record......................6 - 2.4 LP Resource Record.......................7 - 3. Usage Example............................8 - 4. Security Considerations..................9 - - - -Atkinson et alia Expires in 6 months [Page 2] - -Internet Draft -3-29 MAY 2012 - - - 5. IANA Considerations......................9 - 6. References...............................9 - -1. INTRODUCTION - - The Identifier-Locator Network Protocol (ILNP) was developed to - explore a possible evolutionary direction for the Internet - Architecture. An description of the ILNP architecture is - available in a separate document [ILNP-ARCH]. Implementation and - engineering details are largely isolated into a second document - [ILNP-ENG]. - - The Domain Name System (DNS) is the standard way that Internet - nodes locate information about addresses, mail exchangers, and - other data relating to remote Internet nodes [RFC1034] [RFC1035]. - - More recently, the IETF have defined standards-track security - extensions to the DNS [RFC4033]. These security extensions can - be used to authenticate signed DNS data records and can also be - used to store signed public keys in the DNS. Further, the IETF - have defined a standards-track approach to enable secure dynamic - update of DNS records over the network [RFC3007]. - - This document defines several new optional data Resource - Records. This note specifies the syntax and other items - required for independent implementations of these DNS resource - records. The reader is assumed to be familiar with the basics - of DNS, including familiarity with [RFC1034] [RFC1035]. - - The concept of using DNS for rendezvous with mobile nodes or - mobile networks has been proposed earlier, more than once, - independently, by several other researchers; for example, - please see [SB00] [SBK01] and [PHG02]. - -1.1 Terminology - - In this document, the term "ILNP-aware" applied to a DNS - component (either authoritative server or cache) is used to - indicate that the component attempts to include other ILNP - RRTypes to the Additional section of a DNS response to - increase performance and reduce the number of follow-up - queries for other ILNP RRTypes. These other RRsets MAY be added - to the Additional section if space permits and only when the - QTYPE equals NID, L64, L32, or LP. There is no method for a - server to signal that it is ILNP-aware. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - - - -Atkinson et alia Expires in 6 months [Page 3] - -Internet Draft -4-29 MAY 2012 - - - "OPTIONAL" in this document are to be interpreted as described - in RFC 2119 [RFC2119]. - -2. NEW RESOURCE RECORDS - - This document specifies several new and closely related DNS data - Resource Records (RRs). These new RR types have the mnemonics - "NID", "L32", "L64", and "LP". These resource record types are - associated with a Fully-Qualified Domain Name (FQDN), that is - hereafter called the "owner name". These are part of work on the - Identifier-Locator Network Protocol (ILNP) [ILNP-ARCH]. - - For clarity, throughout this section of this document, the - "RDATA" subsections specify the on-the-wire format for these - records, while the "Presentation Format" subsections specify the - human-readable format used in a DNS configuration file - (i.e. "master file" as defined by RFC-1035, Section 5.1). - -2.1 The NID Resource Record - - The NID DNS Resource Record (RR) is used hold values for Node - Identifiers that will be used for ILNP-capable nodes. - - NID records are present only for ILNP-capable nodes. This - restriction is important; ILNP-capable nodes use the presence of - NID records in the DNS to learn that a correspondent node is also - ILNP-capable. While erroneous NID records in the DNS for an node - that is not ILNP-capable would not prevent communication, such - erroneous DNS records could increase the delay at the start of an - IP communications session. - - A given owner name may have zero or more NID records at a given - time. In normal operation, nodes that support the Identifier- - Locator Network Protocol (ILNP) will have at least one valid NID - record. - - The type value for the NID RR type is X-NID-X . - - The NID RR is class independent. - - The NID RR has no special TTL requirements. - -2.1.1 NID RDATA wire format - - The RDATA for an NID RR consists of: - - - a 16 bit Preference field - - a 64 bit NodeID field - - - -Atkinson et alia Expires in 6 months [Page 4] - -Internet Draft -5-29 MAY 2012 - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Preference | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | NodeID | - + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -2.1.1.1 The Preference field - - The field contains a 16-bit unsigned integer in - network byte-order that indicates the owner name's relative - preference for this NID record among other NID records associated - with this owner name. Lower Preference values are preferred over - higher Preference values. - - -2.1.1.2 The NodeID field - - The NodeID field is an unsigned 64-bit value in network - byte-order. It complies with the syntactic rules of IPv6 - Interface Identifiers [RFC-4291, Section 2.5.1], but has slightly - different semantics. Unlike IPv6 Interface Identifiers, which are - bound to a specific *interface* of a specific node, NodeID values - are bound to a specific *node*, and MAY be used with *any - interface* of that node. - -2.1.2 NID RR Presentation Format - - The presentation of the format of the RDATA portion is as follows: - - - The Preference field MUST be represented as a 16-bit unsigned - decimal integer. - - - The NodeID field MUST be represented using the same syntax - (i.e. groups of 4 hexadecimal digits, with each group - separated by a colon) that is already used for DNS AAAA - records (and also used for IPv6 Interface IDs). - - - The NodeID value MUST NOT be in the 'compressed' format - (e.g. using "::") that is defined in RFC-4291, Section 2.2 - (2). This restriction exists to avoid confusion with 128-bit - IPv6 addresses, because the NID is a 64-bit field. - - - - - - -Atkinson et alia Expires in 6 months [Page 5] - -Internet Draft -6-29 MAY 2012 - - -2.1.3 NID RR Examples - - An NID record has the following logical components: - IN NID - - In the above, is the owner name string, - is an unsigned 16-bit value, and is an unsigned 64-bit - value. - - host1.example.com. IN NID 10 0014:4fff:ff20:ee64 - host1.example.com. IN NID 20 0015:5fff:ff21:ee65 - host2.example.com. IN NID 10 0016:6fff:ff22:ee66 - - As NodeID values use the same syntax as IPv6 interface - identifiers, when displayed for human readership, the NodeID - values are presented in the same hexadecimal format as IPv6 - interface identifiers. This is shown in the example above. - - -2.1.4 Additional Section Processing - - To improve performance, ILNP-aware DNS servers and DNS resolvers - MAY attempt to return all L32, L64, and LP records for the same - owner name of the NID RRset in the Additional section of the - response, if space permits. - - -2.2 The L32 Resource Record - - An L32 DNS Resource Record (RR) is used to hold 32-bit - Locator values for ILNPv4-capable nodes. - - L32 records are present only for ILNPv4-capable nodes. This - restriction is important; ILNP-capable nodes use the presence of - L32 records in the DNS to learn that a correspondent node is also - ILNPv4-capable. While erroneous L32 records in the DNS for a - node that is not ILNP-capable would not prevent communication, - such erroneous DNS records could increase the delay at the start - of an IP communications session. - - A given owner name might have zero or more L32 values at a given - time. An ILNPv4-capable host SHOULD have at least 1 Locator - (i.e., L32 or LP) DNS resource record while it is connected to - the Internet. An ILNPv4-capable multi-homed host normally - will have multiple Locator values while multi-homed. An IP - host that is NOT ILNPv4-capable MUST NOT have an L32 or LP record - in its DNS entries. A node that is not currently connected to - the Internet might not have any L32 values in the DNS associated - - - -Atkinson et alia Expires in 6 months [Page 6] - -Internet Draft -7-29 MAY 2012 - - - with its owner name. - - A DNS owner name that is naming a subnetwork, rather than naming - a host, MAY have an L32 record as a wild-card entry, thereby - applying to entries under that DNS owner name. This deployment - scenario probably is most common if the named subnetwork is, was, - or might become, mobile. - - The type value for the L32 RR type is X-L32-X . - - The L32 RR is class independent. - - The L32 RR has no special TTL requirements. - -2.2.1 L32 RDATA Wire Format - - The RDATA for an L32 RR consists of: - - - a 16 bit Preference field - - a 32 bit Locator32 field - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Preference | Locator32 (16 MSBs) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Locator32 (16 LSBs) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -2.2.1.1 The Preference field - - The field is an unsigned 16-bit field in network - byte-order that indicates the owner name's relative preference - for this L32 record among other L32 records associated with this - owner name. Lower Preference values are preferred over higher - Preference values. - -2.2.1.2 The Locator32 field - - The field is an unsigned 32-bit integer in network - byte-order that is identical on-the-wire to the ADDRESS field - of the existing DNS A record. - -2.2.2 L32 RR Presentation Format - - The presentation of the format of the RDATA portion is as follows: - - - The Preference field MUST be represented as a 16-bit unsigned - - - -Atkinson et alia Expires in 6 months [Page 7] - -Internet Draft -8-29 MAY 2012 - - - decimal integer. - - - The Locator32 field MUST be represented using the same syntax - used for existing DNS A records (i.e. 4 decimal numbers - separated by periods without any embedded spaces). - -2.2.3 L32 RR Examples - - An L32 record has the following logical components: - IN L32 - - In the above is the owner name string, - is an unsigned 16-bit value, and is an unsigned 32-bit - value. - - host1.example.com. IN L32 10 10.1.02.0 - host1.example.com. IN L32 20 10.1.04.0 - host2.example.com. IN L32 10 10.1.08.0 - - As L32 values have the same syntax and semantics as IPv4 routing - prefixes, when displayed for human readership, the values are - presented in the same dotted-decimal format as IPv4 addresses. - An example of this syntax is shown above. - - In the example above, the owner name is from a FQDN for an - individual host. host1.example.com has two L32 values, so - host1.example.com is multi-homed. - - Another example is when the owner name is that learned from an LP - record (see below for details of LP records). - - l32-subnet1.example.com. IN L32 10 10.1.02.0 - l32-subnet2.example.com. IN L32 20 10.1.04.0 - l32-subnet3.example.com. IN L32 30 10.1.08.0 - - In this example above, the owner name is for a subnetwork rather - than an individual node. - -2.2.4 Additional Section Processing - - To improve performance, ILNP-aware DNS servers and DNS resolvers - MAY attempt to return all NID, L64, and LP records for the same - owner name of the L32 RRset in the Additional section of the - response, if space permits. - - - - - - - -Atkinson et alia Expires in 6 months [Page 8] - -Internet Draft -9-29 MAY 2012 - - -2.3 The L64 Resource Record - - The L64 resource record (RR) is used to hold unsigned 64-bit - Locator Values for ILNPv6-capable nodes. - - L64 records are present only for ILNPv6-capable nodes. This - restriction is important; ILNP-capable nodes use the presence of - L64 records in the DNS to learn that a correspondent node is also - ILNPv6-capable. While erroneous L64 records in the DNS for a - node that is not ILNP-capable would not prevent communication, - such erroneous DNS records could increase the delay at the start - of an IP communications session. - - A given owner name might have zero or more L64 values at a given - time. An ILNPv6-capable host SHOULD have at least 1 Locator - (i.e., L64 or LP) DNS resource record while it is connected to - the Internet. An ILNPv6-capable multi-homed host normally - will have multiple Locator values while multi-homed. An IP - host that is NOT ILNPv6-capable MUST NOT have an L64 or LP record - in its DNS entries. A node that is not currently connected to - the Internet might not have any L64 values in the DNS associated - with its owner name. - - A DNS owner name that is naming a subnetwork, rather than naming - a host, MAY have an L64 record as a wild-card entry, thereby - applying to entries under that DNS owner name. This deployment - scenario probably is most common if the named subnetwork is, was, - or might become, mobile. - - The type value for the L64 RR type is X-L64-X . - - The L64 RR is class independent. - - The L64 RR has no special TTL requirements. - -2.3.1 The L64 RDATA Wire Format - - The RDATA for an L64 RR consists of: - - - a 16 bit Preference field - - a 64 bit Locator64 field - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Preference | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | Locator64 | - - - -Atkinson et alia Expires in 6 months [Page 9] - -Internet Draft -10-29 MAY 2012 - - - + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -2.3.1.1 The Preference field - - The field is an unsigned 16-bit integer in network - byte-order that indicates the owner name's relative preference - for this L64 record among other L64 records associated with this - owner name. Lower Preference values are preferred over higher - Preference values. - -2.3.1.2 The Locator64 field - - The field is an unsigned 64-bit integer in network - byte-order that has the same syntax and semantics as a 64-bit - IPv6 routing prefix. - -2.3.2 L64 RR Presentation Format - - The presentation of the format of the RDATA portion is as follows: - - - The Preference field MUST be represented as a 16-bit unsigned - decimal integer. - - - The Locator64 field MUST be represented using the same syntax - used for AAAA records (i.e. groups of 4 hexadecimal digits - separated by colons). However, the 'compressed' display - format (e.g. using "::") that is specified in RFC-4291, - Section 2.2 (2), MUST NOT be used. This is done to avoid - confusion with a 128-bit IPv6 address, since the Locator64 is - a 64-bit value, while the IPv6 address is a 128-bit value. - - -2.3.3 L64 RR Examples - - An L64 record has the following logical components: - IN L64 - - In the above, is the owner name string, - is an unsigned 16-bit value, while is an unsigned - 64-bit value. - - - host1.example.com. IN L64 10 2001:0DB8:1140:1000 - host1.example.com. IN L64 20 2001:0DB8:2140:2000 - host2.example.com. IN L64 10 2001:0DB8:4140:4000 - - - - -Atkinson et alia Expires in 6 months [Page 10] - -Internet Draft -11-29 MAY 2012 - - - As L64 values have the same syntax and semantics as IPv6 routing - prefixes, when displayed for human readership, the values might - conveniently be presented in hexadecimal format, as above. - - In the example above, the owner name is from a FQDN for an - individual host. host1.example.com has two L64 values, so it will - be multi-homed. - - Another example is when the owner name is that learned from an LP - record (see below for details of LP records). - - l64-subnet1.example.com. IN L64 10 2001:0DB8:1140:1000 - l64-subnet2.example.com. IN L64 20 2001:0DB8:2140:2000 - l64-subnet3.example.com. IN L64 30 2001:0DB8:4140:4000 - - Here, the owner name is for a subnetwork rather than an individual - node. - -2.3.4 Additional Section Processing - - To improve performance, ILNP-aware DNS servers and DNS resolvers - MAY attempt to return all NID, L32, and LP records for the same - owner name of the L64 RRset in the Additional section of the - response, if space permits. - - -2.4 The LP Resource Record - - The LP DNS resource record (RR) is used to hold the name of a - subnetwork for ILNP. The name is an FQDN which can then be used - to look up L32 or L64 records. LP is, effectively, a Locator - Pointer to L32 and/or L64 records. - - As described in [ILNP-ARCH], the LP RR provides one level of - indirection within the DNS in naming a Locator value. This is - useful in several deployment scenarios, such as for a multi-homed - site where the multi-homing is handled entirely by the site's - border routers (e.g. via Locator rewriting) or in some mobile - network deployment scenarios [ILNP-ADV]. - - LP records MUST NOT be present for owner name values that are not - ILNP-capable nodes. This restriction is important; ILNP-capable - nodes use the presence of LP records in the DNS to infer that - a correspondent node is also ILNP-capable. While erroneous LP - records in the DNS for an owner name would not prevent - communication, presence of such erroneous DNS records could - increase the delay at the start of a communications session. - - - - -Atkinson et alia Expires in 6 months [Page 11] - -Internet Draft -12-29 MAY 2012 - - - The type value for the LP RR type is X-LP-X . - - The LP RR is class independent. - - The LP RR has no special TTL requirements. - - -2.4.1 LP RDATA Wire Format - - The RDATA for an LPP RR consists of: - - - an unsigned 16 bit Preference field - - a variable-length FQDN field - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Preference | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / - / / - / FQDN / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -2.4.1.1 The Preference field - - The field contains an unsigned 16-bit integer in - network-byte order that indicates the owner name's relative - preference for this LP record among other LP records associated - with this owner name. Lower Preference values are preferred over - higher Preference values. - -2.4.1.2 The FQDN field - - The variable-length FQDN field contains the DNS target name that - is used to reference L32 and/or L64 records. This field MUST NOT - have the same value as the owner name of the LP RR instance. - - -2.4.2 LP RR Presentation Format - - The presentation of the format of the RDATA portion is as follows: - - - The Preference field MUST be represented as a 16-bit unsigned - decimal integer. - - - The FQDN field MUST be represented as a wire-encoded domain - name, as described in Section 3.3 of RFC 1035 [RFC1035]. The - - - -Atkinson et alia Expires in 6 months [Page 12] - -Internet Draft -13-29 MAY 2012 - - - wire-encoded format is self-describing, so the length is - implicit. The domain names MUST NOT be compressed. - - -2.4.3 LP RR Examples - - An LP record has the following logical components: - IN LP - - In the above, is the owner name string, - is an unsigned 16-bit value, while is the domain name - which should be resolved further. - - host1.example.com. IN LP 10 l64-subnet1.example.com. - host1.example.com. IN LP 10 l64-subnet2.example.com. - host1.example.com. IN LP 20 l32-subnet1.example.com. - - In the example above, host1.example.com is multi-homed on three - subnets. Resolving the FQDNs return in the LP records would - allow the actual subnet prefixes to be resolved, e.g. as in the - examples for the L32 and L64 RR descriptions, above. This level - of indirection allows the same L32 and/or L64 records to be used - by many hosts in the same subnetwork, easing management of the - ILNP network and potentially reducing the number of DNS Update - transactions, especially when that network is mobile [RAB09] or - multi-homed [ABH09a]. - -2.4.4 Additional Section Processing - - To improve performance, ILNP-aware DNS servers and DNS resolvers - MAY attempt to return all L32 and L64 records for the same owner - name of the LP RRset in the Additional section of the response, - if space permits. - - -3. DEPLOYMENT EXAMPLE - - Given a domain name, one can use the Domain Name System (DNS) to - discover the set of NID records, the set of L32 records, the set - of L64 records, and the set of LP records that are associated - with that DNS owner name. - - For example: - - host1.example.com. IN NID 10 0014:4fff:ff20:ee64 - host1.example.com. IN L64 10 2001:0DB8:1140:1000 - - would be the minimum requirement for an ILNPv6 node that has - - - -Atkinson et alia Expires in 6 months [Page 13] - -Internet Draft -14-29 MAY 2012 - - - owner name host1.example.com and is connected to the Internet at - the subnetwork having routing prefix 2001:0DB8:1140:1000. - - If that host were multi-homed on two different IPv6 subnets: - - host1.example.com. IN NID 10 0014:4fff:ff20:ee64 - host1.example.com. IN L64 10 2001:0DB8:1140:1000 - host1.example.com. IN L64 20 2001:0DB8:2140:2000 - - would indicate the Identifier and two subnets that - host1.example.com is attached to, along with the relative - preference that a client would use in selecting the - Locator value for use in initiating communication. - - If host1.example.com were part of a mobile network, - a DNS query might return: - - host1.example.com. IN NID 10 0014:4fff:ff20:ee64 - host1.example.com. IN LP 10 mobile-net1.example.com. - - and then a DNS query to find the current Locator value(s) - for the node named by the LP record: - - mobile-net1.example.com. IN L64 2001:0DB8:8140:8000 - -3.1 Use of ILNP records - - As these DNS records are only used with the Identifier-Locator - Network Protocol (ILNP), these records MUST NOT be present for a - node that does not support ILNP. This lookup process is - considered to be in the "forward" direction. - - The Preference fields associated with the NID, L32, L64, and LP - records are used to indicate the owner name's preference for - others to use one particular NID, L32, L64, or LP record, rather - than use another NID, L32, L64, or LP record also associated with - that owner name. Lower Preference field values are preferred - over higher Preference field values. - - It is possible that a DNS stub resolver querying for one of these - record types will not receive all NID, L32, L64, and LP RR's in a - single response. Credible anecdotal reports indicate at least - one DNS recursive cache implementation actively drops all - Additional Data records that were not expected by that DNS - recursive cache. So even if the authoritative DNS server includes - all the relevant records in the Additional Data section of the - DNS response, the querying DNS stub resolver might not receive - all of those Additional Data records. DNS resolvers also might - - - -Atkinson et alia Expires in 6 months [Page 14] - -Internet Draft -15-29 MAY 2012 - - - purge some ILNP RRsets before others, for example if NID RRsets - have a longer DNS TTL value than Locator-related (e.g. LP, L32, - L64) RRsets. So a DNS stub resolver sending queries to a DNS - resolver cannot be certain if they have obtained all available - RRtypes for a given owner name. Therefore, the DNS stub resolver - SHOULD send follow-up DNS queries for RRTYPE values that were - missing and are desired, to ensure that the DNS stub resolver - receives all the necessary information. - - Note nodes likely either to be mobile or to be multi-homed - normally will have very low DNS TTL values for L32 and L64 - records, as those values might change frequently. However, the - DNS TTL values for NID and LP records normally will be higher, - as those values are not normally impacted by node location - changes. Previous trace-driven DNS simulations from MIT [JSBM02] - and more recent experimental validation of operational DNS from - U. of St Andrews [BA11] both indicate deployment and use of very - short DNS TTL values within 'stub' or 'leaf' DNS domains is not - problematic. - - An ILNP node MAY use any NID value associated with its DNS owner - name with any or all Locator (L32 or L64) values also associated - with its DNS owner name. - - -3.2 Additional Section Processing - - For all the records above, Additional Section Processing MAY be - used. This is intended to improve performance for both the DNS - client and the DNS server. For example, a node sending DNS query - for an NID owner name, such as host1.example.com, would benefit - from receiving all ILNP DNS records related to that owner name - being returned, as it is quite likely that the client will need - that information to initiate an ILNP communication session. - - However, this is not always the case: a DNS query for L64 for a - particular owner name might be made because the DNS TTL for a - previously resolved L64 RR has expired, while the NID RR for that - same owner name has a DNS TTL that has not expired. - -4. SECURITY CONSIDERATIONS - - These new DNS resource record types do not create any new - vulnerabilities in the Domain Name System. - - Existing mechanisms for DNS Security can be used unchanged with - these record types [RFC4033] [RFC3007]. As of this writing, the - DNS Security mechanisms are believed to be widely implemented - - - -Atkinson et alia Expires in 6 months [Page 15] - -Internet Draft -16-29 MAY 2012 - - - in currently available DNS servers and DNS clients. Deployment - of DNS Security appears to be growing rapidly. - - In situations where authentication of DNS data is a concern, - the DNS Security extensions SHOULD be used [RFC4033]. - - If these DNS records are updated dynamically over the network, - then the Secure Dynamic DNS Update [RFC3007] mechanism SHOULD be - used to secure such transactions. - -5. IANA CONSIDERATIONS - - IANA is requested to allocate each of these DNS Resource Records - - NID - L32 - L64 - LP - - (described above in Section 2) a Data RRTYPE value according to - the procedures of Section 3.1 and 3.1.1 on pages 7 through 9 of - RFC 6195 [RFC6195]. - -6. REFERENCES - - -6.1 Normative References - - [RFC1034] P. Mockapetris, "Domain names - Concepts and - Facilities", RFC-1034, 1 November 1987 - - [RFC1035] P. Mockapetris, "Domain names - Implementation and - Specification", RFC-1035, 1 November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to - Indicate Requirement Levels", BCP 14, RFC 2119, - March 1997. - - [RFC3007] B. Wellington, "Secure Domain Name System Dynamic - Update", RFC 3007, RFC Editor, November 2000. - - [RFC3597] A. Gustafsson, "Handling of Unknown DNS Resource - Record (RR) Types", RFC 3597, September 2003. - - [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, & - S. Rose, "DNS Security Introduction & Requirements", - RFC 4033, RFC Editor, March 2005. - - - - -Atkinson et alia Expires in 6 months [Page 16] - -Internet Draft -17-29 MAY 2012 - - - [RFC6195] D. Eastlake 3rd, "Domain Name System IANA - Considerations", RFC 6195, March 2011. - - [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, "ILNP Architecture", - draft-irtf-rrg-ilnp-arch, May 2012. - - [ILNP-ADV] R.J. Atkinson & S.N. Bhatti, - "Optional Advanced Deployment Scenarios for ILNP", - draft-irtf-rrg-ilnp-adv, May 2012 - - [ILNP-ENG] R. Atkinson & S. Bhatti, "ILNP Engineering and - Implementation Considerations", - draft-irtf-rrg-ilnp-eng, May 2012. - -6.2 INFORMATIVE REFERENCES - - [ABH09a] R. Atkinson, S. Bhatti, & S. Hailes, - "Site-Controlled Secure Multi-Homing and Traffic - Engineering For IP", Proc. MILCOM2009 - 28th IEEE - Military Communications Conference, Boston, MA, USA. - Oct 2009. - - [BA11] S. Bhatti & R. Atkinson, - "Reducing DNS Caching", - Proc. GI2011 - 14th IEEE Global Internet Symposium, - Shanghai, China. 15 Apr 2011. - - - [JSBM02] J. Jung, E. Sit, H. Balakrishnan, and R. Morris, - DNS performance and the effectiveness of caching. - IEEE/ACM Trans. Netw. 10(5) (October 2002), 589-603. - - - [PHG02] Andreas Pappas, Stephen Hailes, Raffaele Giaffreda, - "Mobile Host Location Tracking through DNS", - IEEE London Communications Symposium, London, - England, UK, September 2002. - - - [RAB09] D. Rehunthan, R. Atkinson, S. Bhatti, - "Enabling Mobile Networks Through Secure Naming", - Proc. MILCOM2009 - 28th IEEE Military Communications - Conference (MILCOM), Boston, MA, USA, Oct 2009 - - [SB00] Alex C. Snoeren and Hari Balakrishnan. 2000. - "An End-To-End Approach To Host Mobility", Proc. - 6th Conference on Mobile Computing And Networking - (MobiCom), ACM, Boston, MA, USA, pp. 155-166, - - - -Atkinson et alia Expires in 6 months [Page 17] - -Internet Draft -18-29 MAY 2012 - - - August 2000. - - [SBK01] Alex C. Snoeren, Hari Balakrishnan, & M. Frans - Kaashoek, "Reconsidering Internet Mobility", - Proceedings of 8th Workshop on Hot Topics in - Operating Systems (HotOS), IEEE Computer Society, - Washington, DC, USA, May 2001. - -ACKNOWLEDGEMENTS - - Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel - Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, - Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, - Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical - order) provided review and feedback on earlier versions of this - document. Steve Blake provided an especially thorough review of - an early version of the entire ILNP document set, which was - extremely helpful. We also wish to thank the anonymous reviewers - of the various ILNP papers for their feedback. - - Roy Arends provided expert guidance on technical and procedural - aspects of DNS issues, for which the authors are greatly obliged. - - -RFC EDITOR NOTE - - This section is to be removed prior to publication. - - Please note that this document is written in British English, so - British English spelling is used throughout. This is consistent - with existing practice in several other RFCs, for example - RFC-5887. - - This document tries to be very careful with history, in the - interest of correctly crediting ideas to their earliest - identifiable author(s). So in several places the first published - RFC about a topic is cited rather than the most recent published - RFC about that topic. - -Authors' Addresses: - - RJ Atkinson - Consultant - San Jose, CA - 95125 USA - - Email: rja.lists@gmail.com - - - - -Atkinson et alia Expires in 6 months [Page 18] - -Internet Draft -19-29 MAY 2012 - - - SN Bhatti - School of Computer Science - University of St Andrews - North Haugh, St Andrews - Fife, Scotland, UK - KY16 9SX - - Email: saleem@cs.st-andrews.ac.uk - - - Scott Rose - US National Institute for Standards & Technology - 100 Bureau Drive - Gaithersburg, MD - 20899 USA - - Email: scottr.nist@gmail.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Atkinson et alia Expires in 6 months [Page 19] - -Internet Draft -20-29 MAY 2012 - - - [NOTE: Appendix A is to be removed by the - RFC Editor prior to publication.] - - Appendix A: - - - DNS RRTYPE PARAMETER ALLOCATION TEMPLATE - - When ready for formal consideration, this template is - to be submitted to IANA for processing by emailing the - template to dns-rrtype-applications@ietf.org. - - A. Submission Date: To be determined. - - B. Submission Type: - [X] New RRTYPE - - C. Contact Information for submitter: - Name: R. Atkinson - Email Address: rja.lists@gmail.com - International telephone number: unlisted - Other contact handles: - - D. Motivation for the new RRTYPE application? - - Support for an experimental set of IP extensions - that replace the concept of an "IP Address" with - distinct "Locator" and "Identifier" values. - - E. Description of the proposed RR type. - - Please see: - - http://tools.ietf.org/id/draft-irtf-rrg-ilnp-dns-03.txt - - for a full description. - - F. What existing RRTYPE or RRTYPEs come closest to filling - that need and why are they unsatisfactory? - - There is no RRTYPE that fulfils the need due to the - new semantics of Locator and Identifier values. - - The AAAA record combines both Locator and Identifier, - so has significantly different semantics than having - separate L64 and NID record values. The AAAA record also - lacks scalability and flexibility in the context of the - experimental protocol extensions that will use the NID - - - -Atkinson et alia Expires in 6 months [Page 20] - -Internet Draft -21-29 MAY 2012 - - - and L64 records, as any valid NID record value for a node - can be used on the wire with any valid L64 record value - for the same node. - - The CNAME record is closest conceptually to an LP - record, but a CNAME is a node name referral scheme, - while the LP record is indicating that the given node - has the same routing prefix as some other domain name, - but does not necessarily have any other values that are - the same. - - Lastly, the AAAA and CNAME RR Types lack a Preference - field to rank responses. Such Preference information - is required for ILNP in order to support the use of multiple - instances of NID, L32, L64 and LP records. - - G. What mnemonic is requested for the new RRTYPE (optional)? - - As described in this draft, "NID", "L32", "L64", and "LP". - - H. Does the requested RRTYPE make use of any existing IANA - Registry or require the creation of a new IANA - sub-registry in DNS Parameters? - - Existing registry of DNS Resource Record (RR) data TYPE - values should be used. - - I. Does the proposal require/expect any changes in DNS - servers/resolvers that prevent the new type from being - processed as an unknown RRTYPE (see [RFC3597]) ? - - No. - - J. Comments: - This document defines "ILNP-aware" DNS servers - or DNS resolver as a DNS server (authoritative or recursive) - that MAY include other ILNP RRTypes in the Additional - section of a DNS response that match a QNAME (if - size permits). This is to reduce the number of - DNS stub resolver follow-up DNS queries. and only applies - when the QTYPE is either NID, L32, L64, or LP. There is no - signalling mechanism for this Additional section - processing, and this is believed to be compatible - with existing non-ILNP-aware DNS servers and DNS stub - resolvers. - - No changes are required for existing deployed - DNS servers or DNS resolvers. - - - -Atkinson et alia Expires in 6 months [Page 21] - -Internet Draft -22-29 MAY 2012 - - - Expires: 29 NOV 2012 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Atkinson et alia Expires in 6 months [Page 22] - \ No newline at end of file diff --git a/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt b/doc/draft/draft-mekking-dnsop-auto-cpsync-01.txt similarity index 55% rename from doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt rename to doc/draft/draft-mekking-dnsop-auto-cpsync-01.txt index 0a7516bd64a..d11e93329cc 100644 --- a/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt +++ b/doc/draft/draft-mekking-dnsop-auto-cpsync-01.txt @@ -3,19 +3,22 @@ Domain Name System Operations W. Mekking Internet-Draft NLnet Labs -Intended status: Standards Track June 29, 2010 -Expires: December 31, 2010 +Intended status: Standards Track December 21, 2010 +Expires: June 24, 2011 Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE - draft-mekking-dnsop-auto-cpsync-00 + draft-mekking-dnsop-auto-cpsync-01 Abstract This document proposes a way to synchronise existing trust anchors - automatically between a child zone and its parent. The algorithm can + automatically between a child zone and its parent. The protocol can be used for other Resource Records that are required to delegate from - a parent to a child such as NS and glue records. + a parent to a child such as NS and glue records. The synchronization + allows for a third party to be involved, thus the protocol is + suitable for both cases, whether you have to communicate to the + registry or to the registrar. Requirements Language @@ -38,7 +41,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 31, 2010. + This Internet-Draft will expire on June 24, 2011. Copyright Notice @@ -46,17 +49,17 @@ Copyright Notice document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents -Mekking Expires December 31, 2010 [Page 1] +Mekking Expires June 24, 2011 [Page 1] -Internet-Draft Child Parent Synchronization June 2010 +Internet-Draft Child Parent Synchronization December 2010 + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of @@ -66,9 +69,12 @@ Internet-Draft Child Parent Synchronization June 2010 1. Introduction This memo defines a way to synchronise existing trust anchors - automatically between a child zone and its parent. The algorithm can + automatically between a child zone and its parent. The protocol can be used for other Resource Records that are required to delegate from - a parent to a child such as NS and glue records. + a parent to a child such as NS and glue records. The synchronization + allows for a third party to be involved, thus the protocol is + suitable for both cases, whether you have to communicate to the + registry or to the registrar. To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones must submit their DNSKEYs, or hashes of their DNSKEYs, to their @@ -82,37 +88,60 @@ Internet-Draft Child Parent Synchronization June 2010 The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone changes to the parent. - To bootstrap the direct communication channel, information must be - exchanged in order to detect service location and granting update - privileges. A new or existing child zone can request a direct - communication channel with the parent. If the parent allows for - direct communication with child zones, the parent can share the - required data to set up the channel to the child zone. Once the - child has the required credentials, it can use the direct - communication channel with the parent to request zone changes related - to its delegation. + To bootstrap the communication channel, information must be exchanged + in order to detect service location and granting update privileges. + A new or existing child zone is in need of a communication channel + with the parent. This can be a direct channel or a channel through a + third party: - If a third party is involved, the third party can act on behalf of - the parent. In this case, the third party will give out the required - credentials to set up the communication channel. + If the parent allows for direct communication channel with child + zones, the parent can share the required data to set up the + channel to the child zone. Once the child has the required + credentials, it can use the direct communication channel with the + parent to request zone changes related to its delegation. - It is RECOMMENDED that the direct communication channel is secured - with TSIG [RFC2845] or SIG0 [RFC2931]. + If a third party is involved, the third party acts on behalf of + the parent. In this case, the third party will give out the + required credentials to set up the communication channel. -2. Access and Update Control - - The DNS UPDATE normally is used for granting update permissions to a - machine that is within the boundary of the same organization. This - document proposes to grant child zones the same permissions. - However, it MUST NOT be possible that a child zone updates + Allowing for a third party in the communication channel ensures -Mekking Expires December 31, 2010 [Page 2] +Mekking Expires June 24, 2011 [Page 2] -Internet-Draft Child Parent Synchronization June 2010 +Internet-Draft Child Parent Synchronization December 2010 + + flexibility of the service location. + Please note that the document only describes the front end of the + synchronization service. The first reason for that is that it is not + necessary to write down how the DNS UPDATE is processed after it is + accepted. It is merely a goal to provide a way for the child zone to + automatically update the records at the zone cut. The second reason + is that flexibility is needed in order to fit the protocol into the + multifarious policies that exist among the great number of + registrars. + + Thus, it is not required that the DNS UPDATE immediately updates the + name server. Thus, it would still be possible to monitor the + incoming updates with the tools of your choice. It is not a + replacement of your RR provisioning system. The records in the DNS + UPDATE can be converted into any kind of format. + +2. Service Discovery + + The service location is handed out during bootstrap. If this + information is missing or incorrect, the normal guidelines for + sending DNS UPDATE messages SHOULD be followed. + +3. Access and Update Control + + The DNS UPDATE normally is used for granting update permissions to a + machine that is within the boundary of the same organization. This + document proposes to grant child zones the same permissions. + However, it MUST NOT be possible that a child zone updates information in the parent zone that falls outside the administrative domain of the corresponding delegation. For example, it MUST NOT be possible for a child zone to update the data that the parent is @@ -124,23 +153,34 @@ Internet-Draft Child Parent Synchronization June 2010 delegation specific. Currently those are records with RRtype NS or DS. - Or: The owner name is a subdomain of the child zone name and RRtype - is glue specific. Currently those are records with RRtype A or - AAAA. + Or: The owner name exists in the right side of the NS RRset + belonging to the child zone and RRtype is is glue specific. + Currently those are records with RRtype A or AAAA. + + We can make a distinction here between narrow and wide glue records. + Narrow glue records are said to be glue specific records with an + owner name that is a subdomain of the child zone. Wide glue records + are glue specific records with an owner name that is outside of the + - This list may be expanded in the future, if there is need for more - delegation related zone content. + +Mekking Expires June 24, 2011 [Page 3] + +Internet-Draft Child Parent Synchronization December 2010 + + + delegated child domain. + + These updates MAY be refused if it conflicts with the local policy. + This list may be expanded, if there is need for more delegation + related zone content. In case of adding or deleting delegation specific records, the DNSSEC related RRs in the parent zone might need to be updated. - The service location may be handed out by the registrar during - bootstrap If this information is missing, the normal guidelines for - sending DNS UPDATE messages SHOULD be followed. - -3. Update Mechanism +4. Update Mechanism -3.1. Child Duties +4.1. Update Request Updating the NS RRset or corresponding glue at the parent, an update can be sent at any time. Updating the DS RRset is part of key @@ -156,34 +196,35 @@ Internet-Draft Child Parent Synchronization June 2010 this document, the child should poll the parent zone for a short time, until the DS is visible at all parent name servers. - To discuss: A child zone might be unable to reach all parent name - servers. + [Author's note] To discuss: A child zone might be unable to reach all + parent name servers. The child notifies the parent of the requested changes by sending a DNS UPDATE message. If it receives a NOERROR reply in return, the - - - -Mekking Expires December 31, 2010 [Page 3] - -Internet-Draft Child Parent Synchronization June 2010 - - update is acknowledged by the parent zone. Otherwise, the child MAY retry transmitting the update. In order to prevent duplicate updates, it SHOULD follow the guidelines described in RFC 2136 [RFC2136]. -3.2. Parent Duties +4.2. Processing the Update - When the master DNS server of the parent receives a DNS UPDATE from - one of its children the following must be done: + An incoming DNS UPDATE message is processed as follows: Step 1: Check the TSIG/SIG0 credentials. In case of TSIG, the parent should follow the TSIG processing described in section 3.2 of RFC 2845. In case of SIG0, the parent should follow the SIG0 processing described in section 3.2 of RFC 2931. + + + + + +Mekking Expires June 24, 2011 [Page 4] + +Internet-Draft Child Parent Synchronization December 2010 + + Step 2: Verify that the updates matches the update policy for child zones. @@ -193,15 +234,9 @@ Internet-Draft Child Parent Synchronization June 2010 Step 4: If verified, apply changes. How that is done is a matter of policy. -3.3. Proxy considerations +5. Examples - Some environments don't allow for direct communication between parent - and child zone. In these case, the parent duties can be performed by - a different party (for example, the registar). The third party will - forward the update to the parent zone. In what format depends on - local policy. - -4. Example BIND9 Configuration +5.1. Example BIND9 Configuration This is how a parent zone can configure a policy to enable a child zone synchronize delegation specific records. The first rule of the @@ -217,14 +252,6 @@ Internet-Draft Child Parent Synchronization June 2010 key math.example.com. { algorithm HMAC-MD5; - - - -Mekking Expires December 31, 2010 [Page 4] - -Internet-Draft Child Parent Synchronization June 2010 - - secret "secretformath"; } @@ -238,31 +265,79 @@ Internet-Draft Child Parent Synchronization June 2010 }; }; -5. Security Considerations +6. Security Considerations Automating the synchronization of (DNSSEC) records between the parent - and child created a new channel. We have recommended that this - channel should be secured with TSIG or SIG0. There is an advantage - and a disadvantage of the new security channel. The disadvantage is - that you create a new attack window for your DNSSEC credentials. If - the automated synchronization is used for updating DS records at the - parent, you SHOULD pick a cryptographically an equally strong or - stronger TSIG/SIG0 key than the strength of your DNSSEC keys. + and child creates a new communication channel. It is up to the + policy of the parent, or the third party acting on behalf of the + parent, who is allowed such privileges. A policy would usually + include a form of access control. It is recommended that it involves + transaction authentication, for example TSIG [RFC2845] or SIG0 + + + +Mekking Expires June 24, 2011 [Page 5] + +Internet-Draft Child Parent Synchronization December 2010 + + + [RFC2931]. + + In the jungle of the DNS, many stakeholders exist. The registrant of + a zone might not be the one that maintains the zone. That can + possibly mean that many stakeholders need to possess the security + credentials in order to use this synchronization channel. However, + this problem exist with any kind of transaction authentication. + + The disadvantage of adding a new communication channel is that you + create a new attack window onto your DNS and DNSSEC records. When + using this synchronization method for your DNSSEC records, a + cryptographically equally strong, or stronger private key SHOULD be + used, compared to the strength of your DNSSEC keys. The advantage is that if somehow your DNSSEC keys are compromised, you can still use this channel to perform an emergency key rollover. -6. IANA Considerations +7. IANA Considerations None. -7. Acknowledgments +8. Acknowledgments + + Mark Andrews, Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards. + +9. Changelog + + 01: + + - Make it clear that the solution is flexible and it can fit into + many and diverse environments of registrars. + + - Short section about service discovery. + + - Add text about narrow glue records. + + - Add text about transaction authentication concerns with respect + to many stakeholders involved. + + 00: + + - Initial document + +10. References + - Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards and more. -8. References -8.1. Informative References + + + +Mekking Expires June 24, 2011 [Page 6] + +Internet-Draft Child Parent Synchronization December 2010 + + +10.1. Informative References [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS @@ -274,14 +349,7 @@ Internet-Draft Child Parent Synchronization June 2010 [keytiming] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key Timing Considerations", March 2010. - - -Mekking Expires December 31, 2010 [Page 5] - -Internet-Draft Child Parent Synchronization June 2010 - - -8.2. Normative References +10.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -320,17 +388,5 @@ Author's Address - - - - - - - - - - - - -Mekking Expires December 31, 2010 [Page 6] +Mekking Expires June 24, 2011 [Page 7] diff --git a/doc/draft/draft-yao-dnsext-bname-04.txt b/doc/draft/draft-yao-dnsext-bname-05.txt similarity index 78% rename from doc/draft/draft-yao-dnsext-bname-04.txt rename to doc/draft/draft-yao-dnsext-bname-05.txt index 8b6615aa9b4..2cf21110577 100644 --- a/doc/draft/draft-yao-dnsext-bname-04.txt +++ b/doc/draft/draft-yao-dnsext-bname-05.txt @@ -3,13 +3,13 @@ Network Working Group J. Yao Internet-Draft X. Lee Intended status: Standards Track CNNIC -Expires: February 12, 2011 P. Vixie +Expires: February 20, 2011 P. Vixie Internet Software Consortium - August 11, 2010 + August 19, 2010 - Bundle DNS Name Redirection - draft-yao-dnsext-bname-04.txt + Bundled DNS Name Redirection + draft-yao-dnsext-bname-05.txt Abstract @@ -34,7 +34,7 @@ Status of this Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 12, 2011. + This Internet-Draft will expire on February 20, 2011. Copyright Notice @@ -51,7 +51,7 @@ Copyright Notice -Yao, et al. Expires February 12, 2011 [Page 1] +Yao, et al. Expires February 20, 2011 [Page 1] Internet-Draft bname August 2010 @@ -81,33 +81,33 @@ Table of Contents 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. The BNAME Substitution . . . . . . . . . . . . . . . . . . 4 3.3. The BNAME Rules . . . . . . . . . . . . . . . . . . . . . 4 - 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.4. BNAME Examples . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Processing by Servers . . . . . . . . . . . . . . . . . . 5 4.2. Processing by Resolvers . . . . . . . . . . . . . . . . . 8 5. BNAME in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. BNAME validating . . . . . . . . . . . . . . . . . . . . . 9 5.2. BNAME alias algorithm identifiers . . . . . . . . . . . . 10 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 - 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11 - 9.1. draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 11 - 9.2. draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 11 - 9.3. draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 11 - 9.4. draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 11 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 - - - - - - - - -Yao, et al. Expires February 12, 2011 [Page 2] + 5.3. Signaling of BNAME . . . . . . . . . . . . . . . . . . . . 10 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9.1. draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 12 + 9.2. draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 12 + 9.3. draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 12 + 9.4. draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 12 + 9.5. draft-yao-dnsext-bname: Version 04 . . . . . . . . . . . . 13 + 9.6. draft-yao-dnsext-bname: Version 05 . . . . . . . . . . . . 13 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 + + + + +Yao, et al. Expires February 20, 2011 [Page 2] Internet-Draft bname August 2010 @@ -163,7 +163,7 @@ Internet-Draft bname August 2010 -Yao, et al. Expires February 12, 2011 [Page 3] +Yao, et al. Expires February 20, 2011 [Page 3] Internet-Draft bname August 2010 @@ -212,18 +212,46 @@ Internet-Draft bname August 2010 restriction applies only to records of the same class as the BNAME record. +3.4. BNAME Examples -4. Query Processing + The table below shows some examples of the BNAME usage. - To exploit the BNAME mechanism the name resolution algorithms -Yao, et al. Expires February 12, 2011 [Page 4] +Yao, et al. Expires February 20, 2011 [Page 4] Internet-Draft bname August 2010 + QNAME owner BNAME target result + ---------------- -------------- -------------- ----------------- + com. example.com. example.net. + com. com. net. net. + example.com. example.com. example.net. example.net. + a.example.com. example.com. example.net. a.example.net. + a.b.example.com. example.com. example.net. a.b.example.net. + ab.example.com. b.example.com. example.net. + bar.example.com. example.com. example.net. bar.example.net. + a.b.example.com. b.example.com. example.net. a.example.net. + a.example.com. example.com. b.example.net. a.b.example.net. + + Table 1. BNAME Usage Examples. + + + If the owner name of the CNAME RR is regarded as the target of the MX + RR, it may cause some problems. Some mail servers may directly + connect the owner name of the CNAME instead of the name pointed by + CNAME for mail delivery and cause the undelivery of the mails. BNAME + has the similar problems with CNAME. This document specifies that + the owner name of the BNAME should not be the targets of some RRs + such as MX, SRV and PTR. In case that the owner name of the BNAME RR + is the target of some RRs, it should be cautious. + + +4. Query Processing + + To exploit the BNAME mechanism the name resolution algorithms [RFC1034] must be modified slightly for both servers and resolvers. Both modified algorithms incorporate the operation of making a substitution on a name (either QNAME or SNAME) under control of a @@ -244,40 +272,20 @@ Internet-Draft bname August 2010 If the owner name of the bname is same with the name queryed, when preparing a response, a server performing a BNAME substitution will - not include the relevant BNAME RR in the answer section unless the - type queryed is BNAME. A CNAME RR will be synthesized and included - in the answer section unless the type queryed is BNAME or the query - is the DNSSEC query. - - The provided synthesized CNAME RR if there has one, MUST have - - - - - - - - - - - - - - - - - - +Yao, et al. Expires February 20, 2011 [Page 5] + +Internet-Draft bname August 2010 + not include the relevant BNAME RR in the answer section unless the + type queryed is BNAME. A CNAME RR will be synthesized and included + in the answer section unless the type queryed is BNAME. + The provided synthesized CNAME RR if there has one, MUST have -Yao, et al. Expires February 12, 2011 [Page 5] - -Internet-Draft bname August 2010 The same CLASS as the QCLASS of the query, @@ -323,15 +331,7 @@ Internet-Draft bname August 2010 - - - - - - - - -Yao, et al. Expires February 12, 2011 [Page 6] +Yao, et al. Expires February 20, 2011 [Page 6] Internet-Draft bname August 2010 @@ -387,7 +387,7 @@ Internet-Draft bname August 2010 -Yao, et al. Expires February 12, 2011 [Page 7] +Yao, et al. Expires February 20, 2011 [Page 7] Internet-Draft bname August 2010 @@ -443,7 +443,7 @@ Internet-Draft bname August 2010 -Yao, et al. Expires February 12, 2011 [Page 8] +Yao, et al. Expires February 20, 2011 [Page 8] Internet-Draft bname August 2010 @@ -499,7 +499,7 @@ Internet-Draft bname August 2010 -Yao, et al. Expires February 12, 2011 [Page 9] +Yao, et al. Expires February 20, 2011 [Page 9] Internet-Draft bname August 2010 @@ -535,7 +535,64 @@ Internet-Draft bname August 2010 algorithm identifiers are used with the BNAME hash algorithm SHA1. Using other BNAME hash algorithms requires allocation of a new alias. Validating resolvers which follow the BNAME specification MUST - recognize the new alias algorithm identifier. + recognize the new alias algorithm identifier. The future new DNSSEC + algorithms are suggested to indicate the support of BNAME. + +5.3. Signaling of BNAME + + A new UB (Understand BNAME) bit in the EDNS flags field [RFC2671]can + be used to signal that the resolvers can understand BNAME in DNSSEC. + BNAME aware resolvers can set the Understand-BNAME (UB bit) to + receive a response without the synthesized CNAMEs. The UB bit is + part of the EDNS extended RCODE and Flags field[RFC2671]. Resolvers + should set this in a query to request omission of the synthesized + CNAMEs. + + If the query is a DNSSEC query, the BNAME enabled resolvers MUST set + the UB bit in the query. The server receiving the UB bit MUST not + issue synthesized CNAMEs. Servers copy the UB bit to the response, + and should delete the synthesized CNAMEs from the answer if there has + + + +Yao, et al. Expires February 20, 2011 [Page 10] + +Internet-Draft bname August 2010 + + + one. + + If the query is the DNSSEC query but the UB bit is not set, the + server should follow the rules below: + o If the owner name of the bname is the suffix of the name queryed + but different, when preparing a response, a server performing a + BNAME substitution will in all cases include the relevant BNAME RR + in the answer section. An unsigned CNAME RR is synthesized and + included in the answer section. This will help the client to + reach the correct DNS data. + o If the owner name of the bname is same with the name queryed, when + preparing a response, a DNSSEC enabled server performing a BNAME + substitution will not include the relevant BNAME RR and its RRSIG + RR in the answer section unless the type queryed is BNAME. An + unsigned CNAME RR will be synthesized and included in the answer + section unless the type queryed is BNAME. + o Since the BNAME-unaware DNSSEC resolvers do not know the alias + algorithm defined in secton 5.2 of this document, any response + from these zones signed with these alias algorithms unknown to + them will be regarded as the insecure one according to section 5.2 + of [RFC4035]. + + Below are Updated EDNS extended RCODE and Flags fields [RFC2671]: + + + +0 (MSB) +1 (LSB) + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 0: | EXTENDED-RCODE | VERSION | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 2: |DO|UB| Z | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + 6. IANA Considerations @@ -544,22 +601,24 @@ Internet-Draft bname August 2010 the IANA registry "DNS SECURITY ALGORITHM NUMBERS". IANA is requested to assign the number to Y and Z. - [[anchor14: Note in draft: before this document goes to WG Last call, + [[anchor15: Note in draft: before this document goes to WG Last call, it is better that we list all DNSSEC algorithms that need to be aliased to reflect compatibility with this extension.]] -7. Security Considerations - Both ASCII domain name labels and non-ASCII ones have some aliases. -Yao, et al. Expires February 12, 2011 [Page 10] + +Yao, et al. Expires February 20, 2011 [Page 11] Internet-Draft bname August 2010 +7. Security Considerations + + Both ASCII domain name labels and non-ASCII ones have some aliases. We can bundle the domain name labels and their aliases through BNAME in the DNS resolutions. The name labels and their aliases in the particular languages are only known by those who know these @@ -583,7 +642,7 @@ Internet-Draft bname August 2010 9. Change History - [[anchor17: RFC Editor: Please remove this section.]] + [[anchor18: RFC Editor: Please remove this section.]] 9.1. draft-yao-dnsext-bname: Version 00 @@ -605,17 +664,26 @@ Internet-Draft bname August 2010 o Update the IANA consideration -10. References - - -Yao, et al. Expires February 12, 2011 [Page 11] +Yao, et al. Expires February 20, 2011 [Page 12] Internet-Draft bname August 2010 +9.5. draft-yao-dnsext-bname: Version 04 + + o Improve the text + +9.6. draft-yao-dnsext-bname: Version 05 + + o add section: bname examples + o add section: Signaling of BNAME + + +10. References + 10.1. Normative References [ASCII] American National Standards Institute (formerly United @@ -652,6 +720,14 @@ Internet-Draft bname August 2010 (RR) Types", RFC 3597, September 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + + + +Yao, et al. Expires February 20, 2011 [Page 13] + +Internet-Draft bname August 2010 + + 10646", RFC 3629, November 2003. [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint @@ -664,14 +740,6 @@ Internet-Draft bname August 2010 RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - - - -Yao, et al. Expires February 12, 2011 [Page 12] - -Internet-Draft bname August 2010 - - Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. @@ -702,6 +770,20 @@ Authors' Addresses Email: yaojk@cnnic.cn + + + + + + + + + +Yao, et al. Expires February 20, 2011 [Page 14] + +Internet-Draft bname August 2010 + + Xiaodong LEE CNNIC No.4 South 4th Street, Zhongguancun @@ -723,7 +805,37 @@ Authors' Addresses -Yao, et al. Expires February 12, 2011 [Page 13] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yao, et al. Expires February 20, 2011 [Page 15] diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt b/doc/rfc/rfc5936.txt similarity index 58% rename from doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt rename to doc/rfc/rfc5936.txt index f33a3fa96de..7a58c49c651 100644 --- a/doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt +++ b/doc/rfc/rfc5936.txt @@ -2,15 +2,16 @@ -DNS Extensions Working Group Edward Lewis -Internet-Draft NeuStar, Inc. -Updates: 1034, 1035 (if approved) A. Hoenes, Ed. -Intended status: Standards Track TR-Sys -Expires: September 26, 2010 March 26, 2010 - DNS Zone Transfer Protocol (AXFR) - draft-ietf-dnsext-axfr-clarify-14 +Internet Engineering Task Force (IETF) E. Lewis +Request for Comments: 5936 NeuStar, Inc. +Updates: 1034, 1035 A. Hoenes, Ed. +Category: Standards Track TR-Sys +ISSN: 2070-1721 June 2010 + + + DNS Zone Transfer Protocol (AXFR) Abstract @@ -26,44 +27,38 @@ Abstract definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. -Status of this Memo +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5936. + + + + + - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. This document may contain material - from IETF Documents or IETF Contributions published or made publicly - available before November 10, 2008. The person(s) controlling the - copyright in some of this material may not have granted the IETF - Trust the right to allow modifications of such material outside the - IETF Standards Process. Without obtaining an adequate license from - the person(s) controlling the copyright in such materials, this - document may not be modified outside the IETF Standards Process, and - derivative works of it may not be created outside the IETF Standards - Process, except to format it for publication as an RFC or to - translate it into languages other than English. - 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/1id-abstracts.html -Lewis & Hoenes Expires September 26, 2010 [Page 1] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - This Internet-Draft will expire on September 26, 2010. + +Lewis & Hoenes Standards Track [Page 1] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + Copyright Notice @@ -80,6 +75,17 @@ Copyright Notice the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. @@ -105,71 +111,65 @@ Copyright Notice - - - - - - -Lewis & Hoenes Expires September 26, 2010 [Page 2] +Lewis & Hoenes Standards Track [Page 2] -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 - 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3. Context . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.4. Coverage and Relationship to Original AXFR Specification . 5 - 2. AXFR Messages . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.1. AXFR query . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.1.1. Header Values . . . . . . . . . . . . . . . . . . . . . 9 - 2.1.2. Question Section . . . . . . . . . . . . . . . . . . . . 10 - 2.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 10 - 2.1.4. Authority Section . . . . . . . . . . . . . . . . . . . 10 - 2.1.5. Additional Section . . . . . . . . . . . . . . . . . . . 10 - 2.2. AXFR Response . . . . . . . . . . . . . . . . . . . . . . 11 - 2.2.1. Header Values . . . . . . . . . . . . . . . . . . . . . 12 - 2.2.2. Question Section . . . . . . . . . . . . . . . . . . . . 14 - 2.2.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 14 - 2.2.4. Authority Section . . . . . . . . . . . . . . . . . . . 14 - 2.2.5. Additional Section . . . . . . . . . . . . . . . . . . . 14 - 2.3. TCP Connection Aborts . . . . . . . . . . . . . . . . . . 15 - 3. Zone Contents . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.1. Records to Include . . . . . . . . . . . . . . . . . . . . 15 - 3.2. Delegation Records . . . . . . . . . . . . . . . . . . . . 16 - 3.3. Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.4. Name Compression . . . . . . . . . . . . . . . . . . . . . 18 - 3.5. Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19 - 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 4.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1.1. AXFR client TCP . . . . . . . . . . . . . . . . . . . . 20 - 4.1.2. AXFR server TCP . . . . . . . . . . . . . . . . . . . . 21 - 4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . 22 - 6. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23 - 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . 24 - 7.1. Server . . . . . . . . . . .. . . . . . . . . . . . . . . 24 - 7.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 8. Security Considerations . . . . . . . . . . . . . . . . . . 25 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 - 10. Internationalization Considerations . . . . . . . . . . . . 25 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . 26 - 12.1. Normative References . .. . . . . . . . . . . . . . . . 26 - 12.2. Informative References . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 - - - - - - -Lewis & Hoenes Expires September 26, 2010 [Page 3] + 1. Introduction ....................................................4 + 1.1. Definition of Terms ........................................4 + 1.2. Scope ......................................................5 + 1.3. Context ....................................................5 + 1.4. Coverage and Relationship to Original AXFR Specification ...5 + 2. AXFR Messages ...................................................6 + 2.1. AXFR Query .................................................8 + 2.1.1. Header Values .......................................8 + 2.1.2. Question Section ...................................10 + 2.1.3. Answer Section .....................................10 + 2.1.4. Authority Section ..................................10 + 2.1.5. Additional Section .................................10 + 2.2. AXFR Response .............................................11 + 2.2.1. Header Values ......................................12 + 2.2.2. Question Section ...................................14 + 2.2.3. Answer Section .....................................14 + 2.2.4. Authority Section ..................................14 + 2.2.5. Additional Section .................................14 + 2.3. TCP Connection Aborts .....................................15 + 3. Zone Contents ..................................................15 + 3.1. Records to Include ........................................15 + 3.2. Delegation Records ........................................16 + 3.3. Glue Records ..............................................18 + 3.4. Name Compression ..........................................19 + 3.5. Occluded Names ............................................19 + 4. Transport ......................................................20 + 4.1. TCP .......................................................20 + 4.1.1. AXFR Client TCP ....................................21 + 4.1.2. AXFR Server TCP ....................................22 + 4.2. UDP .......................................................22 + 5. Authorization ..................................................22 + 6. Zone Integrity .................................................23 + 7. Backwards Compatibility ........................................24 + 7.1. Server ....................................................24 + 7.2. Client ....................................................25 + 8. Security Considerations ........................................25 + 9. IANA Considerations ............................................25 + 10. Internationalization Considerations ...........................25 + 11. Acknowledgments ...............................................25 + 12. References ....................................................26 + 12.1. Normative References .....................................26 + 12.2. Informative References ...................................28 + + + + + + + +Lewis & Hoenes Standards Track [Page 3] -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 1. Introduction @@ -178,13 +178,13 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 servers for a zone consist of three elements. Authoritative Transfer (AXFR) is defined in "Domain Names - Concepts and Facilities" [RFC1034] (referred to in this document as RFC 1034) and "Domain - Names - Implementation and Specification" [RFC1035] (henceforth - RFC 1035). Incremental Zone Transfer (IXFR) is defined in - "Incremental Zone Transfer in DNS" [RFC1995]. A mechanism for prompt - notification of zone changes (NOTIFY) is defined in "A Mechanism for - Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The - goal of these mechanisms is to enable a set of DNS name servers to - remain coherently authoritative for a given zone. + Names - Implementation and Specification" [RFC1035] (henceforth RFC + 1035). Incremental Zone Transfer (IXFR) is defined in "Incremental + Zone Transfer in DNS" [RFC1995]. A mechanism for prompt notification + of zone changes (NOTIFY) is defined in "A Mechanism for Prompt + Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of + these mechanisms is to enable a set of DNS name servers to remain + coherently authoritative for a given zone. This document re-specifies the AXFR mechanism as it is deployed in the Internet at large, hopefully with the precision expected from @@ -200,34 +200,40 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 Use of "newer"/"new" and "older"/"old" DNS refers to implementations written after and prior to the publication of this document. - "General purpose DNS implementation" refers to DNS software developed + "General-purpose DNS implementation" refers to DNS software developed for widespread use. This includes resolvers and servers freely accessible as libraries and standalone processes. This also includes proprietary implementations used only in support of DNS service offerings. - "Turnkey DNS implementation" refers to custom made, single use + "Turnkey DNS implementation" refers to custom-made, single-use implementations of DNS. Such implementations consist of software that employs the DNS protocol message format yet does not conform to the entire range of DNS functionality. - The terms "AXFR session", "AXFR server" and "AXFR client" will be + The terms "AXFR session", "AXFR server", and "AXFR client" will be introduced in the first paragraph of Section 2, after some more context has been established. -1.2. Scope - In general terms, authoritative name servers for a given zone can use - various means to achieve coherency of the zone contents they serve. - For example, there are DNS implementations that assemble answers from - data stored in relational databases (as opposed to master files), -Lewis & Hoenes Expires September 26, 2010 [Page 4] + + + + + +Lewis & Hoenes Standards Track [Page 4] -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 +1.2. Scope + + In general terms, authoritative name servers for a given zone can use + various means to achieve coherency of the zone contents they serve. + For example, there are DNS implementations that assemble answers from + data stored in relational databases (as opposed to master files), relying on the database's non-DNS means to synchronize the database instances. Some of these non-DNS solutions interoperate in some fashion. However, AXFR, IXFR, and NOTIFY are the only protocol- @@ -241,7 +247,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 A DNS implementation is not required to support AXFR, IXFR, and NOTIFY, but it should have some means for maintaining name server - coherency. A general purpose DNS implementation will likely support + coherency. A general-purpose DNS implementation will likely support AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS implementations may exist without AXFR. @@ -270,6 +276,14 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant flaw in that specification. Section 3.2.3 of RFC 1035 has assigned the code point for the AXFR QTYPE (see Section 2.1.2 below for more + + + +Lewis & Hoenes Standards Track [Page 5] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + details). Section 4.2 of RFC 1035 discusses how the DNS uses the transport layer and briefly explains why UDP transport is deemed inappropriate for AXFR; the last paragraph of Section 4.2.2 gives @@ -278,142 +292,124 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 when zone data changes occur during an ongoing zone transfer using AXFR. - -Lewis & Hoenes Expires September 26, 2010 [Page 5] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - - This document will update the specification of AXFR. To this end, it fully specifies the record formats and processing rules for AXFR, largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it details the transport considerations for AXFR, thus amending Section - 4.2.2 of RFC 1035. Furthermore, it discusses backward compatibility - issues and provides policy/management considerations as well as - specific Security Considerations for AXFR. The goal of this document + 4.2.2 of RFC 1035. Furthermore, it discusses backward-compatibility + issues and provides policy/management considerations, as well as + specific security considerations for AXFR. The goal of this document is to define AXFR as it is understood by the DNS community to exist today. +2. AXFR Messages + An AXFR session consists of an AXFR query message and the sequence of + AXFR response messages returned for it. In this document, the AXFR + client is the sender of the AXFR query, and the AXFR server is the + responder. (Use of terms such as master, slave, primary, and + secondary are not important for defining AXFR.) The use of the word + "session" without qualification refers to an AXFR session. + An important aspect to keep in mind is that the definition of AXFR is + restricted to TCP [RFC0793] (see Section 4 for details). The design + of the AXFR process has certain inherent features that are not easily + ported to UDP [RFC0768]. + The basic format of an AXFR message is the DNS message as defined in + Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the + following documents. + o The "Basic" DNS specification: + - "A Mechanism for Prompt Notification of Zone Changes + (DNS NOTIFY)" [RFC1996] + - "Dynamic Updates in the Domain Name System (DNS UPDATE)" + [RFC2136] + - "Clarifications to the DNS Specification" [RFC2181] + - "Extension Mechanisms for DNS (EDNS0)" [RFC2671] +Lewis & Hoenes Standards Track [Page 6] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + - "Secret Key Transaction Authentication for DNS (TSIG)" + [RFC2845] + - "Secret Key Establishment for DNS (TKEY RR)" [RFC2930] + - "Obsoleting IQUERY" [RFC3425] + - "Handling of Unknown DNS Resource Record (RR) Types" + [RFC3597] + - "HMAC SHA (Hashed Message Authentication Code, Secure Hash + Algorithm) TSIG Algorithm Identifiers" [RFC4635] + - "Domain Name System (DNS) IANA Considerations" [RFC5395] + o Further additions related to the DNS Security Extensions (DNSSEC), + defined in these base documents: + - "DNS Security Introduction and Requirements" [RFC4033] + - "Resource Records for the DNS Security Extensions" + [RFC4034] + - "Protocol Modifications for the DNS Security Extensions" + [RFC4035] + - "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource + Records (RRs)" [RFC4509] + - "DNS Security (DNSSEC) Hashed Authenticated Denial of + Existence" [RFC5155] + - "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG + Resource Records for DNSSEC" [RFC5702] - - - - - - - - - - - - - - -Lewis & Hoenes Expires September 26, 2010 [Page 6] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - - -2. AXFR Messages - - An AXFR session consists of an AXFR query message and the sequence of - AXFR response messages returned for it. In this document, the AXFR - client is the sender of the AXFR query and the AXFR server is the - responder. (Use of terms such as master, slave, primary, secondary - are not important for defining AXFR.) The use of the word "session" - without qualification refers to an AXFR session. - - An important aspect to keep in mind is that the definition of AXFR is - restricted to TCP [RFC0793] (see Section 4 for details). The design - of the AXFR process has certain inherent features that are not easily - ported to UDP [RFC0768]. - - The basic format of an AXFR message is the DNS message as defined in - Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the - following documents. - - o The 'Basic' DNS specification: - - - "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)" - [RFC1996] - - "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136] - - "Clarifications to the DNS Specification" [RFC2181] - - "Extension Mechanisms for DNS (EDNS0)" [RFC2671] - - "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] - - "Secret Key Establishment for DNS (TKEY RR)" [RFC2930] - - "Obsoleting IQUERY" [RFC3425] - - "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597] - - "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] - - "Domain Name System (DNS) IANA Considerations" [RFC5395] - - o Further additions related to the DNS Security Extensions (DNSSEC), - defined in these base documents: - - - "DNS Security Introduction and Requirements" [RFC4033] - - "Resource Records for the DNS Security Extensions" [RFC4034] - - "Protocol Modifications for the DNS Security Extensions" [RFC4035] - - "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509] - - "DNS Security Hashed Authenticated Denial of Existence" [RFC5155] - - "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource - Records for DNSSEC" [RFC5702] - - "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U] + - "Clarifications and Implementation Notes for DNSSECbis" + [DNSSEC-U] These documents contain information about the syntax and semantics of DNS messages. They do not interfere with AXFR but are also helpful in understanding what will be carried via AXFR. + For convenience, the synopsis of the DNS message header from + [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is + reproduced here informally: -Lewis & Hoenes Expires September 26, 2010 [Page 7] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - For convenience, the synopsis of the DNS message header from - [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is - reproduced here informally: - 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ID | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT/ZOCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT/PRCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT/UPCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +Lewis & Hoenes Standards Track [Page 7] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT/ZOCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT/PRCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT/UPCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ This document makes use of the field names as they appear in this diagram. The names of sections in the body of DNS messages are @@ -430,7 +426,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 Note that the TC (truncation) bit is never set by an AXFR server nor considered/read by an AXFR client. -2.1. AXFR query +2.1. AXFR Query An AXFR query is sent by a client whenever there is a reason to ask. This might be because of scheduled or triggered zone maintenance @@ -438,38 +434,32 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 respectively) or as a result of a command line request, say for debugging. +2.1.1. Header Values + These are the DNS message header values for an AXFR query. + ID Selected by client; see Note a) + QR MUST be 0 (Query) + OPCODE MUST be 0 (Standard Query) - -Lewis & Hoenes Expires September 26, 2010 [Page 8] +Lewis & Hoenes Standards Track [Page 8] -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 -2.1.1. Header Values - - These are the DNS message header values for an AXFR query. - - ID Selected by client; see Note a) - - QR MUST be 0 (Query) - - OPCODE MUST be 0 (Standard Query) Flags: - AA 'n/a' -- see Note b) - TC 'n/a' -- see Note b) - RD 'n/a' -- see Note b) - RA 'n/a' -- see Note b) - Z 'mbz' -- see Note c) - AD 'n/a' -- see Note b) - CD 'n/a' -- see Note b) + AA "n/a" -- see Note b) + TC "n/a" -- see Note b) + RD "n/a" -- see Note b) + RA "n/a" -- see Note b) + Z "mbz" -- see Note c) + AD "n/a" -- see Note b) + CD "n/a" -- see Note b) RCODE MUST be 0 (No error) @@ -486,33 +476,37 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 a) Set to any value that the client is not already using with the same server. There is no specific means for selecting the value in this field. (Recall that AXFR is done only via TCP connections - -- see Section 4 "Transport".) + -- see Section 4, "Transport".) A server MUST reply using messages that use the same message ID to allow a client to have multiple queries outstanding concurrently over the same TCP connection -- see Note a) in Section 2.2.1 for more details. - b) 'n/a' -- The value in this field has no meaning in the context of + b) "n/a" -- The value in this field has no meaning in the context of AXFR query messages. For the client, it is RECOMMENDED that the value be zero. The server MUST ignore this value. - c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore + c) "mbz" -- The client MUST set this bit to 0; the server MUST ignore it. + d) The client MUST set this field to the number of resource records + it places into the Additional section. In the absence of explicit + specification of new RRs to be carried in the Additional section + of AXFR queries, the value MAY be 0, 1, or 2. See Section 2.1.5, + "Additional Section", for details on the currently applicable RRs. + -Lewis & Hoenes Expires September 26, 2010 [Page 9] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - d) The client MUST set this field to the number of resource records - it places into the Additional section. In the absence of explicit - specification of new RRs to be carried in the Additional section - of AXFR queries, the value MAY be 0, 1 or 2. See Section 2.1.5 - "Additional Section" for details on the currently applicable RRs. + + +Lewis & Hoenes Standards Track [Page 9] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + 2.1.2. Question Section @@ -543,38 +537,38 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 carried in the Additional section of normal DNS transactions need to explicitly describe their use with AXFR, should that be desired. - The client MAY include one OPT resource record [RFC2671]. If - the server does not support EDNS0, the client MUST send this section - without an OPT resource record if there is a retry. However, - the protocol does not define an explicit indication that the server - does not support EDNS0; that needs to be inferred by the client. - Often, the server will return a FormErr(1) which might be related to - the OPT resource record. Note that, at the time of this writing, - only the EXTENDED-RCODE field of the OPT RR is meaningful in - the context of AXFR; future specifications of EDNS flags and/or - EDNS options must describe their usage in the context of AXFR, if - applicable. + The client MAY include one OPT resource record [RFC2671]. If the + server does not support EDNS0, the client MUST send this section + without an OPT resource record if there is a retry. However, the + protocol does not define an explicit indication that the server does + not support EDNS0; that needs to be inferred by the client. Often, + the server will return a FormErr(1) that might be related to the OPT + resource record. Note that, at the time of this writing, only the + EXTENDED-RCODE field of the OPT RR is meaningful in the context of + AXFR; future specifications of EDNS flags and/or EDNS options must + describe their usage in the context of AXFR, if applicable. The client MAY include one transaction integrity and authentication resource record, currently a choice of TSIG [RFC2845] or SIG(0) - - -Lewis & Hoenes Expires September 26, 2010 [Page 10] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - - [RFC2931]. If the server has indicated that it does not recognize the resource record, and that the error is indeed caused by the resource record, the client probably should not try again. Removing the security data in the face of an obstacle ought to only be done with full awareness of the implication of doing so. + + + +Lewis & Hoenes Standards Track [Page 10] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + In general, if an AXFR client is aware that an AXFR server does not support a particular mechanism, the client SHOULD NOT attempt to - engage the server using the mechanism (or at all). A client could - become aware of a server's abilities via a configuration setting or - via some other (as yet) undefined means. + engage the server using the mechanism (or engage the server at all). + A client could become aware of a server's abilities via a + configuration setting or via some other (as yet) undefined means. The range of permissible resource records that MAY appear in the Additional section might change over time. If either a change to an @@ -582,25 +576,25 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 Additional section record is created, the new definitions ought to include a discussion on the applicability and impact upon AXFR. Future resource records residing in the Additional section might have - an effect that is orthogonal to AXFR, so can ride through the session - as opaque data. In this case, a "wise" implementation ought to be - able to pass these records through without disruption. + an effect that is orthogonal to AXFR, and so can ride through the + session as opaque data. In this case, a "wise" implementation ought + to be able to pass these records through without disruption. 2.2. AXFR Response The AXFR response will consist of one or more messages. The special case of a server closing the TCP connection without sending an AXFR - response is covered in section 2.3. + response is covered in Section 2.3. An AXFR response that is transferring the zone's contents will consist of a series (which could be a series of length 1) of DNS messages. In such a series, the first message MUST begin with the - SOA resource record of the zone, the last message MUST conclude with - the same SOA resource record. Intermediate messages MUST NOT contain - the SOA resource record. The AXFR server MUST copy the Question - section from the corresponding AXFR query message into the first - response message's Question section. For subsequent messages, it MAY - do the same or leave the Question section empty. + SOA resource record of the zone, and the last message MUST conclude + with the same SOA resource record. Intermediate messages MUST NOT + contain the SOA resource record. The AXFR server MUST copy the + Question section from the corresponding AXFR query message into the + first response message's Question section. For subsequent messages, + it MAY do the same or leave the Question section empty. The AXFR protocol treats the zone contents as an unordered collection (or to use the mathematical term, a "set") of RRs. Except for the @@ -614,16 +608,18 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 of the non-SOA RRs. Each RR SHOULD be transmitted only once, and AXFR clients MUST ignore any duplicate RRs received. - -Lewis & Hoenes Expires September 26, 2010 [Page 11] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - - Each AXFR response message SHOULD contain a sufficient number of RRs to reasonably amortize the per-message overhead, up to the largest number that will fit within a DNS message (taking the required content of the other sections into account, as described below). + + + +Lewis & Hoenes Standards Track [Page 11] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + Some old AXFR clients expect each response message to contain only a single RR. To interoperate with such clients, the server MAY restrict response messages to a single RR. As there is no standard @@ -633,7 +629,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 To indicate an error in an AXFR response, the AXFR server sends a single DNS message when the error condition is detected, with the response code set to the appropriate value for the condition - encountered, Such a message terminates the AXFR session; it MUST + encountered. Such a message terminates the AXFR session; it MUST contain a copy of the Question section from the AXFR query in its Question section, but the inclusion of the terminating SOA resource record is not necessary. @@ -654,11 +650,11 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 Flags: AA normally 1 -- see Note b) TC MUST be 0 (Not truncated) - RD RECOMMENDED: copy request's value, MAY be set to 0 + RD RECOMMENDED: copy request's value; MAY be set to 0 RA SHOULD be 0 -- see Note c) - Z 'mbz' -- see Note d) - AD 'mbz' -- see Note d) - CD 'mbz' -- see Note d) + Z "mbz" -- see Note d) + AD "mbz" -- see Note d) + CD "mbz" -- see Note d) RCODE See Note e) @@ -670,13 +666,15 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 NSCOUNT MUST be 0 + ARCOUNT See Note g) -Lewis & Hoenes Expires September 26, 2010 [Page 12] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - ARCOUNT See Note g) + +Lewis & Hoenes Standards Track [Page 12] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + Notes: @@ -685,55 +683,57 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 DNS servers MUST set this field to the value of the AXFR query ID in each AXFR response message for the session. AXFR clients MUST be able to manage sessions resulting from the issuance of multiple - outstanding queries, whether AXFR queries or other DNS queries. - A client SHOULD discard responses that do not correspond (via the + outstanding queries, whether AXFR queries or other DNS queries. A + client SHOULD discard responses that do not correspond (via the message ID) to any outstanding queries. Unless the client is sure that the server will consistently set the ID field to the query's ID, the client is NOT RECOMMENDED to - issue any other queries until the end of the zone transfer. - A client MAY become aware of a server's abilities via a + issue any other queries until the end of the zone transfer. A + client MAY become aware of a server's abilities via a configuration setting. - b) If the RCODE is 0 (no error), then the AA bit MUST be 1. - For any other value of RCODE, the AA bit MUST be set according to - the rules for that error code. If in doubt, it is RECOMMENDED - that it be set to 1. It is RECOMMENDED that the value be ignored - by the AXFR client. + b) If the RCODE is 0 (no error), then the AA bit MUST be 1. For any + other value of RCODE, the AA bit MUST be set according to the + rules for that error code. If in doubt, it is RECOMMENDED that it + be set to 1. It is RECOMMENDED that the value be ignored by the + AXFR client. - c) It is RECOMMENDED that the server set the value to 0, the client + c) It is RECOMMENDED that the server set the value to 0; the client MUST ignore this value. The server MAY set this value according to the local policy regarding recursive service, but doing so might confuse the - interpretation of the response as AXFR can not be retrieved + interpretation of the response, as AXFR cannot be retrieved recursively. A client MAY note the server's policy regarding recursive service from this value, but SHOULD NOT conclude that - the AXFR response was obtained recursively even if the RD bit was + the AXFR response was obtained recursively, even if the RD bit was 1 in the query. - d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore + d) "mbz" -- The server MUST set this bit to 0; the client MUST ignore it. e) In the absence of an error, the server MUST set the value of this field to NoError(0). If a server is not authoritative for the queried zone, the server SHOULD set the value to NotAuth(9). - (Reminder, consult the appropriate IANA registry [DNSVALS].) If a + (Reminder: Consult the appropriate IANA registry [DNSVALS].) If a client receives any other value in response, it MUST act according to the error. For example, a malformed AXFR query or the presence - of an OPT resource record sent to an old server will result - in a FormErr(1) value. This value is not set as part of the AXFR- + of an OPT resource record sent to an old server will result in a + FormErr(1) value. This value is not set as part of the AXFR- specific response processing. The same is true for other values indicating an error. -Lewis & Hoenes Expires September 26, 2010 [Page 13] + + +Lewis & Hoenes Standards Track [Page 13] -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 f) The count of answer records MUST equal the number of resource - records in the AXFR Answer Section. When a server is aware that a + records in the AXFR Answer section. When a server is aware that a client will only accept response messages with a single resource record, then the value MUST be 1. A server MAY be made aware of a client's limitations via configuration data. @@ -741,7 +741,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 g) The server MUST set this field to the number of resource records it places into the Additional section. In the absence of explicit specification of new RRs to be carried in the Additional section - of AXFR response messages, the value MAY be 0, 1 or 2. See + of AXFR response messages, the value MAY be 0, 1, or 2. See Section 2.1.5 above for details on the currently applicable RRs and Section 2.2.5 for additional considerations specific to AXFR servers. @@ -750,9 +750,9 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 In the first response message, this section MUST be copied from the query. In subsequent messages, this section MAY be copied from the - query or it MAY be empty. However, in an error response message (see - Section 2.2), this section MUST be copied as well. The content of - this section MAY be used to determine the context of the message, + query, or it MAY be empty. However, in an error response message + (see Section 2.2), this section MUST be copied as well. The content + of this section MAY be used to determine the context of the message, that is, the name of the zone being transferred. 2.2.3. Answer Section @@ -773,21 +773,24 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 The following considerations specifically apply to AXFR responses: If the client has supplied an EDNS OPT RR in the AXFR query and if - the server supports EDNS as well, it SHOULD include one OPT RR - in the first response message and MAY do so in subsequent response - messages (see Section 2.2); the specifications of EDNS options to be - carried in the OPT RR may impose stronger requirements. + the server supports EDNS as well, it SHOULD include one OPT RR in the + first response message and MAY do so in subsequent response messages + (see Section 2.2); the specifications of EDNS options to be carried + in the OPT RR may impose stronger requirements. + + - If the client has supplied a transaction security resource record - (currently a choice of TSIG and SIG(0)) and the server supports the - method chosen by the client, it MUST place the corresponding resource -Lewis & Hoenes Expires September 26, 2010 [Page 14] + +Lewis & Hoenes Standards Track [Page 14] -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + If the client has supplied a transaction security resource record + (currently a choice of TSIG and SIG(0)) and the server supports the + method chosen by the client, it MUST place the corresponding resource record into the AXFR response message(s), according to the rules specified for that method. @@ -805,13 +808,12 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 to react, but the implemented reaction SHOULD NOT be either an endless cycle of retries or an increasing (in frequency) retry rate. - An AXFR server implementor should take into consideration the dilemma + An AXFR server implementer should take into consideration the dilemma described above when a connection is closed with an outstanding query in the pipeline. For this reason, a server ought to reserve this course of action for situations in which it believes beyond a doubt that the AXFR client is attempting abusive behavior. - 3. Zone Contents The objective of the AXFR session is to request and transfer the @@ -834,29 +836,31 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 In the Answer section of AXFR response messages, the resource records within a zone for the given serial number MUST appear. The definition of what belongs in a zone is described in RFC 1034, - Section 4.2, "How the database is divided into zones" (in particular - Section 4.2.1, "Technical considerations"), and it has been clarified - in Section 6 of RFC 2181. -Lewis & Hoenes Expires September 26, 2010 [Page 15] + +Lewis & Hoenes Standards Track [Page 15] -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + Section 4.2, "How the database is divided into zones" (in particular + Section 4.2.1, "Technical considerations"), and it has been clarified + in Section 6 of RFC 2181. + Zones for which it is impractical to list the entire zone for a serial number are not suitable for AXFR retrieval. A typical (but not limiting) description of such a zone is a zone consisting of responses generated via other database lookups and/or computed based - upon ever changing data. + upon ever-changing data. 3.2. Delegation Records In Section 4.2.1 of RFC 1034, this text appears (keep in mind that the "should" in the quotation predates [BCP14], cf. Section 1.1): - "The RRs that describe cuts ... should be exactly the same as the - corresponding RRs in the top node of the subzone." + The RRs that describe cuts ... should be exactly the same as the + corresponding RRs in the top node of the subzone. There has been some controversy over this statement and the impact on which NS resource records are included in a zone transfer. @@ -865,7 +869,8 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 applicable glue records. It does not mean that the cut point and apex resource records are identical. For example, the SOA resource record is only found at the apex. The discussion here is restricted - to just the NS resource record set and glue as these "describe cuts". + to just the NS resource record set and glue, as these "describe + cuts". DNSSEC resource records have special specifications regarding their occurrence at a zone cut and the apex of a zone. This was first @@ -875,16 +880,26 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 in Section 2 above) gives the full details for DNSSEC(bis) resource record placement, and Section 3.1.5 of RFC 4035 normatively specifies their treatment during AXFR; the alternate NSEC3 resource record - defined later in RFC 5155 behaves identically as the NSEC RR, for the + defined later in RFC 5155 behaves identically to the NSEC RR, for the purpose of AXFR. + Informally: o The DS RRSet only occurs at the parental side of a zone cut and is authoritative data in the parent zone, not the secure child zone. - o The DNSKEY RRSet only occurs at the APEX of a signed zone and is + o The DNSKEY RRSet only occurs at the apex of a signed zone and is part of the authoritative data of the zone it serves. + + + + +Lewis & Hoenes Standards Track [Page 16] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + o Independent RRSIG RRSets occur at the signed parent side of a zone cut and at the apex of a signed zone; they are authoritative data in the respective zone; simple queries for RRSIG resource records @@ -894,12 +909,6 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 does not occur for AXFR, since each such RRSIG RRset belongs to a single zone. - -Lewis & Hoenes Expires September 26, 2010 [Page 16] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - - o Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records equally may occur at the parental side of a zone cut and at the apex of a zone; each such resource record belongs to exactly one @@ -907,15 +916,14 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 One issue is that in operations there are times when the NS resource records for a zone might be different at a cut point in the parent - and at the apex of a zone. Sometimes this is the result of an error + and at the apex of a zone. Sometimes this is the result of an error, and sometimes it is part of an ongoing change in name servers. The DNS protocol is robust enough to overcome inconsistencies up to (but not including) there being no parent-indicated NS resource record referencing a server that is able to serve the child zone. This robustness is one quality that has fueled the success of the DNS. - Still, the inconsistency is an error state and steps need to be taken - to make it apparent (if it is unplanned) and to make it clear once - the inconsistency has been removed. + Still, the inconsistency is an error state, and steps need to be + taken to make it apparent (if it is unplanned). Another issue is that the AXFR server could be authoritative for a different set of zones than the AXFR client. It is possible that the @@ -935,34 +943,42 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 number (in zone file environments) or as any data configured to be in the zone (database), statically or dynamically. - The reasons for this requirement are: - 1) The AXFR server might not be able to determine that there is an - inconsistency given local data, hence requiring consistency would - mean a lot more needed work and even network retrieval of data. An - authoritative server ought not be required to perform any queries. - 2) By transferring the inconsistent NS resource records from a server - that is authoritative for both the cut point and the apex to a client - that is not authoritative for both, the error is exposed. For - example, an authorized administrator can manually request the AXFR - and inspect the results to see the inconsistent records. (A server - authoritative for both halves would otherwise always answer from the - more authoritative set, concealing the error.) -Lewis & Hoenes Expires September 26, 2010 [Page 17] + + + + +Lewis & Hoenes Standards Track [Page 17] -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + The reasons for this requirement are: + + 1) The AXFR server might not be able to determine that there is an + inconsistency given local data; hence, requiring consistency would + mean a lot more needed work and even network retrieval of data. + An authoritative server ought not be required to perform any + queries. + + 2) By transferring the inconsistent NS resource records from a server + that is authoritative for both the cut point and the apex to a + client that is not authoritative for both, the error is exposed. + For example, an authorized administrator can manually request the + AXFR and inspect the results to see the inconsistent records. (A + server authoritative for both halves would otherwise always answer + from the more authoritative set, concealing the error.) 3) The inconsistent NS resource record set might indicate a problem - in a registration database. + in a registration database. 4) This requirement is necessary to ensure that retrieving a given - (zone,serial) pair by AXFR yields the exact same set of resource - records no matter which of the zone's authoritative servers is chosen - as the source of the transfer. + (zone, serial) pair by AXFR yields the exact same set of resource + records, no matter which of the zone's authoritative servers is + chosen as the source of the transfer. If an AXFR server were allowed to respond with the authoritative NS RRset of a child zone instead of a parent-side NS RRset in the zone @@ -970,25 +986,32 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 on whether or not the server happened to be authoritative for the child zone as well. - The property that a given (zone,serial) pair corresponds to a single, - well-defined set of records is necessary for the correct operation of - incremental transfer protocols such as IXFR [RFC1995]. For example, - a client may retrieve a zone by AXFR from one server, and then apply - an incremental change obtained by IXFR from a different server. If - the two servers have different ideas of the zone contents, the client - can end up attempting to incrementally add records that already exist - or to delete records that do not exist. + The property that a given (zone, serial) pair corresponds to a + single, well-defined set of records is necessary for the correct + operation of incremental transfer protocols such as IXFR [RFC1995]. + For example, a client may retrieve a zone by AXFR from one server, + and then apply an incremental change obtained by IXFR from a + different server. If the two servers have different ideas of the + zone contents, the client can end up attempting to incrementally add + records that already exist or to delete records that do not exist. 3.3. Glue Records As quoted in the previous section, Section 4.2.1 of RFC 1034 provides guidance and rationale for the inclusion of glue records as part of - an AXFR transfer. And, as also argued in the previous section of + an AXFR response. And, as also argued in the previous section of this document, even when there is an inconsistency between the address in a glue record and the authoritative copy of the name server's address, the glue resource record that is registered as part of the zone for that serial number is to be included. + + +Lewis & Hoenes Standards Track [Page 18] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + This applies to glue records for any address family [IANA-AF]. The AXFR response MUST contain the appropriate glue records as @@ -1001,23 +1024,19 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 Compression of names in DNS messages is described in RFC 1035, Section 4.1.4, "Message compression". The issue highlighted here relates to a comment made in RFC 1034, Section 3.1, "Name space - specifications and terminology" which says "When you receive a domain - name or label, you should preserve its case." ("Should" in the quote - predates [BCP14].) - + specifications and terminology", which says: + When you receive a domain name or label, you should preserve its + case. -Lewis & Hoenes Expires September 26, 2010 [Page 18] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - + ("Should" in the quote predates [BCP14].) Since the primary objective of AXFR is to enable the client to serve the same zone content as the server, unlike such normal DNS responses that are expected to preserve the case in the query, the actual zone transfer needs to retain the case of the labels in the zone content. Hence, name compression in an AXFR message SHOULD be performed in a - case-preserving manner, unlike how it is done for 'normal' DNS + case-preserving manner, unlike how it is done for "normal" DNS responses. That is, although when comparing a domain name for matching, "a" equals "A", when comparing for the purposes of message compression for AXFR, "a" is not equal to "A". Note that this is not @@ -1031,7 +1050,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 3.5. Occluded Names - Dynamic Update [RFC2136] operations, and in particular its + Dynamic Update [RFC2136] operations, and in particular their interaction with DNAME [RFC2672], can have a side effect of occluding names in a zone. The addition of a delegation point via dynamic update will render all subordinate domain names to be in a limbo, @@ -1039,19 +1058,32 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 addition of a DNAME resource record has the same impact. The subordinate names are said to be "occluded". + + + + + +Lewis & Hoenes Standards Track [Page 19] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + Occluded names MUST be included in AXFR responses. An AXFR client MUST be able to identify and handle occluded names. The rationale for this action is based on a speedy recovery if the dynamic update operation was in error and is to be undone. - 4. Transport AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC - 1034 that states: "Because accuracy is essential, TCP or some other - reliable protocol must be used for AXFR requests." The restriction - to TCP is also mentioned in Section 6.1.3.2. of "Requirements for - Internet Hosts - Application and Support" [RFC1123]. + 1034, which states: + + Because accuracy is essential, TCP or some other reliable protocol + must be used for AXFR requests. + + The restriction to TCP is also mentioned in Section 6.1.3.2 of + "Requirements for Internet Hosts - Application and Support" + [RFC1123]. The most common scenario is for an AXFR client to open a TCP connection to the AXFR server, send an AXFR query, receive the AXFR @@ -1060,38 +1092,38 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 query for the zone's SOA resource record first over the same TCP connection, and reusing an existing TCP connection for other queries. - - - -Lewis & Hoenes Expires September 26, 2010 [Page 19] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - - Therefore, the assumption that a TCP connection is dedicated to a single AXFR session is incorrect. This wrong assumption has led to implementation choices that prevent either multiple concurrent zone transfers or the use of an open connection for other queries. Since the early days of the DNS, operators who have sets of name - servers that are authoritative for a common set of zones found it - desirable to be able to have multiple concurrent zone transfers in - progress; this way a name server does not have to wait for one zone + servers that are authoritative for a common set of zones have found + it desirable to be able to have multiple concurrent zone transfers in + progress; this way, a name server does not have to wait for one zone transfer to complete before the next can begin. RFC 1035 did not exclude this possibility, but legacy implementations failed to support this functionality efficiently, over a single TCP connection. The remaining presence of such legacy implementations makes it - necessary that new general purpose client implementations still + necessary that new general-purpose client implementations still provide options for graceful fallback to the old behavior in their support of concurrent DNS transactions and AXFR sessions on a single TCP connection. 4.1. TCP - In the original definition there arguably is an implicit assumption + In the original definition, there arguably is an implicit assumption (probably unintentional) that a TCP connection is used for one and only one AXFR session. This is evidenced in the lack of an explicit requirement to copy the Question section and/or the message ID into + + + +Lewis & Hoenes Standards Track [Page 20] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + responses, no explicit ordering information within the AXFR response messages, and the lack of an explicit notice indicating that a zone transfer continues in the next message. @@ -1101,11 +1133,11 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 older software. Better performance includes being able to multiplex DNS message exchanges including zone transfer sessions. Guidelines for interacting with older software are generally applicable to new - AXFR clients. In the reverse situation, older AXFR client and newer - AXFR server, the server ought to operate within the specification for - an older server. + AXFR clients. In the reverse situation -- older AXFR client and + newer AXFR server -- the server ought to operate within the + specification for an older server. -4.1.1. AXFR client TCP +4.1.1. AXFR Client TCP An AXFR client MAY request a connection to an AXFR server for any reason. An AXFR client SHOULD close the connection when there is no @@ -1114,15 +1146,9 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 connection closure ought to be on the client. "Apparent need" for the connection is a judgment for the AXFR client and the DNS client. If the connection is used for multiple sessions, or if it is known - sessions will be coming, or if there is other query/response traffic - anticipated or currently on the open connection, then there is - "apparent need". - - -Lewis & Hoenes Expires September 26, 2010 [Page 20] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - + that sessions will be coming, or if there is other query/response + traffic anticipated or currently on the open connection, then there + is "apparent need". An AXFR client can cancel the delivery of a zone only by closing the connection. However, this action will also cancel all other @@ -1145,17 +1171,27 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 This exemplifies the general complications for clients in connection- oriented protocols not receiving meaningful error responses. + + + + +Lewis & Hoenes Standards Track [Page 21] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + An AXFR client MAY use an already opened TCP connection to start an AXFR session. Using an existing open connection is RECOMMENDED over opening a new connection. (Non-AXFR session traffic can also use an open connection.) If in doing so the AXFR client realizes that the responses cannot be properly differentiated (lack of matching query - IDs for example) or the connection is terminated for a remote reason, - then the AXFR client SHOULD NOT attempt to reuse an open connection - with the specific AXFR server until the AXFR server is updated (which - is, of course, not an event captured in the DNS protocol). + IDs, for example) or the connection is terminated for a remote + reason, then the AXFR client SHOULD NOT attempt to reuse an open + connection with the specific AXFR server until the AXFR server is + updated (which is, of course, not an event captured in the DNS + protocol). -4.1.2. AXFR server TCP +4.1.2. AXFR Server TCP An AXFR server MUST be able to handle multiple AXFR sessions on a single TCP connection, as well as to handle other query/response @@ -1174,23 +1210,16 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 response with the appropriate response code and not see the connection broken. - -Lewis & Hoenes Expires September 26, 2010 [Page 21] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - - 4.2. UDP - With the addition of EDNS0 and applications which require many small - zones such as in web hosting and some ENUM scenarios, AXFR sessions + With the addition of EDNS0 and applications that require many small + zones, such as in web hosting and some ENUM scenarios, AXFR sessions on UDP would now seem desirable. However, there are still some aspects of AXFR sessions that are not easily translated to UDP. Therefore, this document does not update RFC 1035 in this respect: AXFR sessions over UDP transport are not defined. - 5. Authorization A zone administrator has the option to restrict AXFR access to a @@ -1199,6 +1228,14 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 AXFR could be for various reasons including a desire (or in some instances, having a legal requirement) to keep the bulk version of the zone concealed or to prevent the servers from handling the load + + + +Lewis & Hoenes Standards Track [Page 22] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + incurred in serving AXFR. It has been argued that these reasons are questionable, but this document, driven by the desire to leverage the interoperable practice that has evolved since RFC 1035, acknowledges @@ -1210,55 +1247,55 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 An implementation SHOULD allow access to be granted to Internet Protocol addresses and ranges, regardless of whether a source address could be spoofed. Combining this with techniques such as Virtual - Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be + Private Networks (VPNs) [RFC2764] or Virtual LANs has proven to be effective. - A general purpose implementation is RECOMMENDED to implement access - controls based upon "Secret Key Transaction Authentication for DNS" - [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" - [RFC2931]. + A general-purpose implementation is RECOMMENDED to implement access + controls based upon "Secret Key Transaction Authentication for DNS + (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures + ( SIG(0)s )" [RFC2931]. - A general purpose implementation SHOULD allow access to be open to - all AXFR requests. I.e., an operator ought to be able to allow any - AXFR query to be granted. + A general-purpose implementation SHOULD allow access to be open to + all AXFR requests. That is, an operator ought to be able to allow + any AXFR query to be granted. - A general purpose implementation SHOULD NOT have a default policy for + A general-purpose implementation SHOULD NOT have a default policy for AXFR requests to be "open to all". For example, a default could be to restrict transfers to addresses selected by the DNS administrator(s) for zones on the server. +6. Zone Integrity + + An AXFR client MUST ensure that only a successfully transferred copy + of the zone data can be used to serve this zone. Previous + description and implementation practice has introduced a two-stage + model of the whole zone synchronization procedure: Upon a trigger + event (e.g., when polling of a SOA resource record detects a change + in the SOA serial number, or when a DNS NOTIFY request [RFC1996] is + received), the AXFR session is initiated, whereby the zone data are + saved in a zone file or database (this latter step is necessary + anyway to ensure proper restart of the server); upon successful + completion of the AXFR operation and some sanity checks, this data + set is "loaded" and made available for serving the zone in an atomic + operation, and flagged "valid" for use during the next restart of the + DNS server; if any error is detected, this data set MUST be deleted, + and the AXFR client MUST continue to serve the previous version of + the zone, if it did before. The externally visible behavior of an + AXFR client implementation MUST be equivalent to that of this two- + stage model. -Lewis & Hoenes Expires September 26, 2010 [Page 22] +Lewis & Hoenes Standards Track [Page 23] -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 -6. Zone Integrity - - An AXFR client MUST ensure that only a successfully transferred copy - of the zone data can be used to serve this zone. Previous - description and implementation practice have introduced a two-stage - model of the whole zone synchronization procedure: Upon a trigger - event (e.g., polling of a SOA resource record detects change in the - SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session is - initiated, whereby the zone data are saved in a zone file or data - base (this latter step is necessary anyway to ensure proper restart - of the server); upon successful completion of the AXFR operation and - some sanity checks, this data set is 'loaded' and made available for - serving the zone in an atomic operation, and flagged 'valid' for use - during the next restart of the DNS server; if any error is detected, - this data set MUST be deleted, and the AXFR client MUST continue to - serve the previous version of the zone, if it did before. The - externally visible behavior of an AXFR client implementation MUST be - equivalent to that of this two-stage model. - - If an AXFR client rejects data contained in an AXFR session, it - SHOULD remember the serial number and MAY attempt to retrieve the - same zone version again. The reason the same retrieval could make - sense is that the reason for the rejection could be rooted in an + If an AXFR client rejects data obtained in an AXFR session, it SHOULD + remember the serial number and MAY attempt to retrieve the same zone + version again. The reason the same retrieval could make sense is + that the reason for the rejection could be rooted in an implementation detail of one AXFR server used for the zone and not present in another AXFR server used for the zone. @@ -1271,43 +1308,27 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 Besides best attempts at securing TCP connections, DNS implementations SHOULD provide means to make use of "Secret Key - Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and - Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients - to verify the contents. These techniques MAY also be used for - authorization. - - - - - - - - - - - - -Lewis & Hoenes Expires September 26, 2010 [Page 23] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - + Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS + Request and Transaction Signatures ( SIG(0)s )" [RFC2931] to allow + AXFR clients to verify the contents. These techniques MAY also be + used for authorization. 7. Backwards Compatibility Describing backwards compatibility is difficult because of the lack - of specifics in the original definition. In this section some hints + of specifics in the original definition. In this section, some hints at building in backwards compatibility are given, mostly repeated from the relevant earlier sections. Backwards compatibility is not necessary, but the greater the extent - of an implementation's compatibility the greater its - interoperability. For turnkey implementations this is not usually a - concern. For general purpose implementations this takes on varying - levels of importance depending on the implementer's desire to + of an implementation's compatibility, the greater its + interoperability. For turnkey implementations, this is not usually a + concern. For general-purpose implementations, this takes on varying + levels of importance, depending on the implementer's desire to maintain interoperability. It is unfortunate that a need to fall back to older behavior cannot - be discovered, hence needs to be noted in a configuration file. An + be discovered, and thus has to be noted in a configuration file. An implementation SHOULD, in its documentation, encourage operators to periodically review AXFR clients and servers it has made notes about repeatedly, as old software gets updated from time to time. @@ -1315,15 +1336,22 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 7.1. Server An AXFR server has the luxury of being able to react to an AXFR - client's abilities with the exception of knowing whether the client + client's abilities, with the exception of knowing whether the client can accept multiple resource records per AXFR response message. The - knowledge that a client is so restricted cannot be discovered, hence + knowledge that a client is so restricted cannot be discovered; hence, it has to be set by configuration. + + +Lewis & Hoenes Standards Track [Page 24] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + An implementation of an AXFR server MAY permit configuring, on a per - AXFR client basis, the necessity to revert to single resource record - per message; in that case, the default SHOULD be to use multiple - records per message. + AXFR client basis, the necessity to revert to a single resource + record per message; in that case, the default SHOULD be to use + multiple records per message. 7.2. Client @@ -1336,18 +1364,6 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 close the connection immediately upon completion of the original (connection-causing) zone transfer. - - - - - - - -Lewis & Hoenes Expires September 26, 2010 [Page 24] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 - - 8. Security Considerations This document is a clarification of a mechanism outlined in RFCs 1034 @@ -1358,8 +1374,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 Concerns regarding authorization, traffic flooding, and message integrity are mentioned in "Authorization" (Section 5), "TCP" - (Section 4.2) and "Zone Integrity" (Section 6). - + (Section 4.1), and "Zone Integrity" (Section 6). 9. IANA Considerations @@ -1367,7 +1382,6 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry. - 10. Internationalization Considerations The AXFR protocol is transparent to the parts of DNS zone content @@ -1376,178 +1390,196 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 been solved via "Internationalizing Domain Names in Applications (IDNA)" [RFC3490] or its successor(s). - 11. Acknowledgments - Earlier editions of this document have been edited by Andreas - Gustafsson. In his latest version, this acknowledgment appeared: + Earlier draft versions of this document have been edited by Andreas + Gustafsson. In his latest draft version, this acknowledgment + appeared: + + + + +Lewis & Hoenes Standards Track [Page 25] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 - "Many people have contributed input and commentary to earlier - versions of this document, including but not limited to Bob Halley, - Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert - Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam - Trenholme, and Brian Wellington." - Comments since the -05 version have come from these individuals: + Many people have contributed input and commentary to earlier + versions of this document, including but not limited to Bob + Halley, Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin + Darcy, Robert Elz, Levon Esibov, Mark Andrews, Michael Patton, + Peter Koch, Sam Trenholme, and Brian Wellington. + + Comments on later draft versions have come from these individuals: Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly, Bill Manning, and other participants of the DNSEXT working group. + Significant comments from the IETF at large have been received from + Subramanian Moonesamy, Chris Lonvick, and Vijay K. Gurbani. Edward Lewis served as a patiently listening sole document editor for two years. +12. References + All "RFC" references below -- like all RFCs -- and information about + the RFC series can be obtained from the RFC Editor web site at + http://www.rfc-editor.org. +12.1. Normative References -Lewis & Hoenes Expires September 26, 2010 [Page 25] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 + [BCP14] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. -12. References + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. - All "RFC" references by can be obtained from the RFC Editor web site - at the URLs: http://rfc-editor.org/rfc.html - or http://rfc-editor.org/rfcsearch.html ; - information regarding this organization can be found at the following - URL: http://rfc-editor.org/ + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. -12.1. Normative References + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, October 1989. + + [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. + + [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, August 1996. + + + + +Lewis & Hoenes Standards Track [Page 26] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 + + + [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. - [BCP14] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, - RFC 793, September 1981. + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. - [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, - August 1980. + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC + 2672, August 1999. - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for + DNS (TSIG)", RFC 2845, May 2000. - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. + [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. - [RFC1123] Braden, R., "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, October 1989. + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. - [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, - August 1996. + [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November + 2002. - [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", RFC 1996, August 1996. + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. - [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", - RFC 2672, August 1999. + [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer + (DS) Resource Records (RRs)", RFC 4509, May 2006. + [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message + Authentication Code, Secure Hash Algorithm) TSIG + Algorithm Identifiers", RFC 4635, August 2006. -Lewis & Hoenes Expires September 26, 2010 [Page 26] +Lewis & Hoenes Standards Track [Page 27] -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. - [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. + [RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 5395, November 2008. - [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures - ( SIG(0)s )", RFC 2931, September 2000. + [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY + and RRSIG Resource Records for DNSSEC", RFC 5702, October + 2009. - [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, - November 2002. +12.2. Informative References - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. + [DNSVALS] IANA Registry "Domain Name System (DNS) Parameters", + http://www.iana.org/. - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. + [IANA-AF] IANA Registry "Address Family Numbers", + http://www.iana.org/. - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. + [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. + Malis, "A Framework for IP Based Virtual Private + Networks", RFC 2764, February 2000. - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", + RFC 3490, March 2003. - [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer - (DS) Resource Records (RRs)", RFC 4509, May 2006 + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004. - [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication - Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", - RFC 4635, August 2006. + [DNSSEC-U] Weiler, S. and D. Blacka, "Clarifications and + Implementation Notes for DNSSECbis", Work in Progress, + March 2010. - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008 - [RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA - Considerations", BCP 42, RFC 5395, November 2008. - [RFC5702] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY - and RRSIG Resource Records for DNSSEC", RFC 5702, - October 2009. -Lewis & Hoenes Expires September 26, 2010 [Page 27] - -Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010 -12.2. Informative References - [DNSVALS] IANA Registry "Domain Name System (DNS) Parameters", - http://www.iana.org/assignments/dns-parameters - [IANA-AF] IANA Registry "Address Family Numbers", - http://www.iana.org/assignments/Address-family-numbers/ . - [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. - Malis, "A Framework for IP Based Virtual Private - Networks", RFC 2764, February 2000. - [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", - RFC 3490, March 2003. - [RFC3833] Atkins, D., and R. Austein, "Threat Analysis of the Domain - Name System (DNS)", RFC 3833, August 2004. - [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and - Implementation Notes for DNSSECbis", - draft-ietf-dnsext-dnssec-bis-updates-10 (work in - progress), March 2010. + +Lewis & Hoenes Standards Track [Page 28] + +RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 Authors' Addresses Edward Lewis 46000 Center Oak Plaza - Sterling, VA, 22033, US + Sterling, VA 20166 + US - Email: ed.lewis@neustar.biz + EMail: ed.lewis@neustar.biz Alfred Hoenes, Editor @@ -1556,16 +1588,40 @@ Authors' Addresses Ditzingen D-71254 Germany - Email: ah@TR-Sys.de + EMail: ah@TR-Sys.de + + + + + + + + + + + + + + + + + + + + + + + + + + + -Editorial Note: Discussion [[ to be removed by RFC-Editor ]] - Comments on this draft ought to be addressed to the editors and/or to - namedroppers@ops.ietf.org. -Lewis & Hoenes Expires September 26, 2010 [Page 28] +Lewis & Hoenes Standards Track [Page 29] diff --git a/doc/draft/draft-ietf-6man-text-addr-representation-07.txt b/doc/rfc/rfc5952.txt similarity index 54% rename from doc/draft/draft-ietf-6man-text-addr-representation-07.txt rename to doc/rfc/rfc5952.txt index 3a9f1112f9f..56a0e0c355e 100644 --- a/doc/draft/draft-ietf-6man-text-addr-representation-07.txt +++ b/doc/rfc/rfc5952.txt @@ -1,62 +1,67 @@ -IPv6 Maintenance Working Group S. Kawamura -Internet-Draft NEC BIGLOBE, Ltd. -Updates: 4291 (if approved) M. Kawashima -Intended status: Standards Track NEC AccessTechnica, Ltd. -Expires: August 29, 2010 February 25, 2010 + + + +Internet Engineering Task Force (IETF) S. Kawamura +Request for Comments: 5952 NEC BIGLOBE, Ltd. +Updates: 4291 M. Kawashima +Category: Standards Track NEC AccessTechnica, Ltd. +ISSN: 2070-1721 August 2010 A Recommendation for IPv6 Address Text Representation - draft-ietf-6man-text-addr-representation-07 Abstract - As IPv6 deployment increases there will be a dramatic increase in the - need to use IPv6 addresses in text. While the IPv6 address - architecture in RFC 4291 section 2.2 describes a flexible model for - text representation of an IPv6 address this flexibility has been + As IPv6 deployment increases, there will be a dramatic increase in + the need to use IPv6 addresses in text. While the IPv6 address + architecture in Section 2.2 of RFC 4291 describes a flexible model + for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an - application or database. It is expected that the canonical format is - followed by humans and systems when representing IPv6 addresses as - text, but all implementations must accept and be able to handle any - legitimate RFC 4291 format. + application or database. It is expected that the canonical format + will be followed by humans and systems when representing IPv6 + addresses as text, but all implementations must accept and be able to + handle any legitimate RFC 4291 format. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5952. -Status of this Memo - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - 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 August 29, 2010. -Copyright Notice -Kawamura & Kawashima Expires August 29, 2010 [Page 1] + + + + +Kawamura & Kawashima Standards Track [Page 1] -Internet-Draft IPv6 Text Representation February 2010 +RFC 5952 IPv6 Text Representation August 2010 +Copyright Notice + Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. @@ -68,9 +73,7 @@ Internet-Draft IPv6 Text Representation February 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as - described in the BSD License. - - + described in the Simplified BSD License. @@ -108,19 +111,19 @@ Internet-Draft IPv6 Text Representation February 2010 -Kawamura & Kawashima Expires August 29, 2010 [Page 2] +Kawamura & Kawashima Standards Track [Page 2] -Internet-Draft IPv6 Text Representation February 2010 +RFC 5952 IPv6 Text Representation August 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 - 2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4 - 2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 4 + 2. Text Representation Flexibility of RFC 4291 . . . . . . . . . 4 + 2.1. Leading Zeros in a 16-Bit Field . . . . . . . . . . . . . 4 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5 - 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5 + 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 6 3. Problems Encountered with the Flexible Model . . . . . . . . . 6 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6 @@ -130,43 +133,43 @@ Table of Contents 3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7 3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7 3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 7 + 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8 3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8 3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8 3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8 3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8 - 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 8 + 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9 3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9 3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9 3.4.2. Preference in Documentation . . . . . . . . . . . . . 9 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 9 - 4. A Recommendation for IPv6 Text Representation . . . . . . . . 9 - 4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10 + 4. A Recommendation for IPv6 Text Representation . . . . . . . . 10 + 4.1. Handling Leading Zeros in a 16-Bit Field . . . . . . . . . 10 4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2.1. Shorten As Much As Possible . . . . . . . . . . . . . 10 - 4.2.2. Handling One 16 Bit 0 Field . . . . . . . . . . . . . 10 + 4.2.1. Shorten as Much as Possible . . . . . . . . . . . . . 10 + 4.2.2. Handling One 16-Bit 0 Field . . . . . . . . . . . . . 10 4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10 - 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5. Text Representation of Special Addresses . . . . . . . . . . . 10 + 4.3. Lowercase . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. Text Representation of Special Addresses . . . . . . . . . . . 11 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 7. Prefix Representation . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 14 -Kawamura & Kawashima Expires August 29, 2010 [Page 3] + + +Kawamura & Kawashima Standards Track [Page 3] -Internet-Draft IPv6 Text Representation February 2010 +RFC 5952 IPv6 Text Representation August 2010 1. Introduction @@ -192,9 +195,9 @@ Internet-Draft IPv6 Text Representation February 2010 All of the above examples represent the same IPv6 address. This flexibility has caused many problems for operators, systems - engineers, and customers. The problems are noted in Section 3. - Also, a canonical representation format to avoid problems is - introduced in Section 4. + engineers, and customers. The problems are noted in Section 3. A + canonical representation format to avoid problems is introduced in + Section 4. 1.1. Requirements Language @@ -202,27 +205,27 @@ Internet-Draft IPv6 Text Representation February 2010 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. - -2. Text Representation Flexibility of RFC4291 +2. Text Representation Flexibility of RFC 4291 Examples of flexibility in Section 2.2 of [RFC4291] are described below. -2.1. Leading Zeros in a 16 Bit Field +2.1. Leading Zeros in a 16-Bit Field 'It is not necessary to write the leading zeros in an individual field.' - Conversely it is also not necessary to omit leading zeros. This - means that, it is possible to select from such as the following - example. The final 16 bit field is different, but all these - addresses represent the same address. + Conversely, it is also not necessary to omit leading zeros. This + means that it is possible to select from representations such as + those in the following example. The final 16-bit field is different, + but all of these addresses represent the same address. + -Kawamura & Kawashima Expires August 29, 2010 [Page 4] +Kawamura & Kawashima Standards Track [Page 4] -Internet-Draft IPv6 Text Representation February 2010 +RFC 5952 IPv6 Text Representation August 2010 2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001 @@ -238,15 +241,15 @@ Internet-Draft IPv6 Text Representation February 2010 'A special syntax is available to compress the zeros. The use of "::" indicates one or more groups of 16 bits of zeros.' - It is possible to select whether or not to omit just one 16 bits of - zeros. + It is possible to select whether or not to omit just one 16-bit 0 + field. 2001:db8:aaaa:bbbb:cccc:dddd::1 2001:db8:aaaa:bbbb:cccc:dddd:0:1 - In case where there is more than one zero fields, there is a choice - of how many fields can be shortened. + In cases where there is more than one field of only zeros, there is a + choice of how many fields can be shortened. 2001:db8:0:0:0::1 @@ -256,7 +259,7 @@ Internet-Draft IPv6 Text Representation February 2010 2001:db8::1 - In addition, [RFC4291] in section 2.2 notes, + In addition, Section 2.2 of [RFC4291] notes, 'The "::" can only appear once in an address.' @@ -267,27 +270,30 @@ Internet-Draft IPv6 Text Representation February 2010 2001:db8:0:0:aaaa::1 -2.3. Uppercase or Lowercase - [RFC4291] does not mention any preference of uppercase or lowercase. -Kawamura & Kawashima Expires August 29, 2010 [Page 5] + + +Kawamura & Kawashima Standards Track [Page 5] -Internet-Draft IPv6 Text Representation February 2010 +RFC 5952 IPv6 Text Representation August 2010 +2.3. Uppercase or Lowercase + + [RFC4291] does not mention any preference of uppercase or lowercase. + 2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa - 3. Problems Encountered with the Flexible Model 3.1. Searching @@ -295,53 +301,53 @@ Internet-Draft IPv6 Text Representation February 2010 3.1.1. General Summary A search of an IPv6 address if conducted through a UNIX system is - usually case sensitive and extended options to allow for regular + usually case sensitive and extended options that allow for regular expression use will come in handy. However, there are many applications in the Internet today that do not provide this capability. When searching for an IPv6 address in such systems, the system engineer will have to try each and every possibility to search - for an address. This has critical impacts especially when trying to + for an address. This has critical impacts, especially when trying to deploy IPv6 over an enterprise network. 3.1.2. Searching Spreadsheets and Text Files - Spreadsheet applications and text editors on GUI systems, rarely have - the ability to search for a text using regular expression. Moreover, + Spreadsheet applications and text editors on GUI systems rarely have + the ability to search for text using regular expression. Moreover, there are many non-engineers (who are not aware of case sensitivity - and regular expression use) that use these application to manage IP + and regular expression use) that use these applications to manage IP addresses. This has worked quite well with IPv4 since text representation in IPv4 has very little flexibility. There is no incentive to encourage these non-engineers to change their tool or learn regular expression when they decide to go dual-stack. If the entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was conducted as 2001:db8:0:0:1::1, this will show a result of no match. - One example where this will cause problem is, when the search is - being conducted to assign a new address from a pool, and a check was - being done to see if it was not in use. This may cause problems to + One example where this will cause a problem is, when the search is + being conducted to assign a new address from a pool, and a check is + being done to see if it is not in use. This may cause problems for the end-hosts or end-users. This type of address management is very - often seen in enterprise networks and also in ISPs. + often seen in enterprise networks and ISPs. 3.1.3. Searching with Whois The "whois" utility is used by a wide range of people today. When a record is set to a database, one will likely check the output to see if the entry is correct. If an entity was recorded as 2001:db8::/48, - but the whois output showed 2001:0db8:0000::/48, most non-engineers - would think that their input was wrong and will likely retry several - times or make a frustrated call to the database hostmaster. If there -Kawamura & Kawashima Expires August 29, 2010 [Page 6] +Kawamura & Kawashima Standards Track [Page 6] -Internet-Draft IPv6 Text Representation February 2010 +RFC 5952 IPv6 Text Representation August 2010 - was a need to register the same address on different systems, and - each system showed a different text representation, this would - confuse people even more. Although this document focuses on - addresses rather than prefixes, this is worth mentioning since the - problems encountered are mostly equal. + but the whois output showed 2001:0db8:0000::/48, most non-engineers + would think that their input was wrong and will likely retry several + times or make a frustrated call to the database hostmaster. If there + was a need to register the same prefix on different systems, and each + system showed a different text representation, this would confuse + people even more. Although this document focuses on addresses rather + than prefixes, it is worth mentioning the prefix problems because the + problems encountered with addresses and prefixes are mostly equal. 3.1.4. Searching for an Address in a Network Diagram @@ -352,20 +358,21 @@ Internet-Draft IPv6 Text Representation February 2010 search the diagram for that address). This is a technique quite often in use in enterprise networks and managed services. Again, the different flavors of text representation will result in a time- - consuming search leading to longer MTTR in times of trouble. + consuming search leading to longer mean times to restoration (MTTR) + in times of trouble. 3.2. Parsing and Modifying 3.2.1. General Summary - With all the possible methods of text representation each application - must include a module, object, link, etc. to a function that will - parse IPv6 addresses in a manner that no matter how it is - represented, they will mean the same address. Many system engineers - who integrate complex computer systems for corporate customers will - have difficulties finding that their favorite tool will not have this - function, or will encounter difficulties such as having to rewrite - their macros or scripts for their customers. + With all the possible methods of text representation, each + application must include a module, object, link, etc. to a function + that will parse IPv6 addresses in a manner such that no matter how it + is represented, they will mean the same address. Many system + engineers who integrate complex computer systems for corporate + customers will have difficulties finding that their favorite tool + will not have this function, or will encounter difficulties such as + having to rewrite their macros or scripts for their customers. 3.2.2. Logging @@ -375,27 +382,30 @@ Internet-Draft IPv6 Text Representation February 2010 The address would have to be parsed and reformed to make it useful for human reading. Sometimes logging for critical systems is done by mirroring the same traffic to two different systems. Care must be - taken so that no matter what the log output is the logs should be - parsed so they will mean the same. + taken so that no matter what the log output is, the logs should be + parsed so they are equivalent. -3.2.3. Auditing: Case 1 - When a router or any other network appliance machine configuration is - audited, there are many methods to compare the configuration - information of a node. Sometimes auditing will be done by just - comparing the changes made each day. In this case if configuration - was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: -Kawamura & Kawashima Expires August 29, 2010 [Page 7] + + +Kawamura & Kawashima Standards Track [Page 7] -Internet-Draft IPv6 Text Representation February 2010 +RFC 5952 IPv6 Text Representation August 2010 +3.2.3. Auditing: Case 1 + + When a router or any other network appliance machine configuration is + audited, there are many methods to compare the configuration + information of a node. Sometimes auditing will be done by just + comparing the changes made each day. In this case, if configuration + was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: 0000:0000:0000:0001 just because the new engineer on the block felt it was better, a simple diff will show that a different address was - configured. If this was done on a wide scale network people will be + configured. If this was done on a wide scale network, people will be focusing on 'why the extra zeros were put in' instead of doing any real auditing. Lots of tools are just plain diffs that do not take into account address representation rules. @@ -403,7 +413,7 @@ Internet-Draft IPv6 Text Representation February 2010 3.2.4. Auditing: Case 2 Node configurations will be matched against an information system - that manages IP addresses. If output notation is different there + that manages IP addresses. If output notation is different, there will need to be a script that is implemented to cover for this. The result of an SNMP GET operation, converted to text and compared to a textual address written by a human is highly unlikely to match on the @@ -435,24 +445,23 @@ Internet-Draft IPv6 Text Representation February 2010 representation will know that the right address is set, but not everyone may understand this. -3.3.2. Customer Calls - - When a customer calls to inquire about a suspected outage, IPv6 - address representation should be handled with care. Not all - customers are engineers nor have the same skill in IPv6 technology. - The network operations center will have to take extra steps to - -Kawamura & Kawashima Expires August 29, 2010 [Page 8] +Kawamura & Kawashima Standards Track [Page 8] -Internet-Draft IPv6 Text Representation February 2010 +RFC 5952 IPv6 Text Representation August 2010 - humanly parse the address to avoid having to explain to the customers - that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1. This is one - thing that will never happen in IPv4 because IPv4 address cannot be - abbreviated. +3.3.2. Customer Calls + + When a customer calls to inquire about a suspected outage, IPv6 + address representation should be handled with care. Not all + customers are engineers, nor do they have a similar skill level in + IPv6 technology. The network operations center will have to take + extra steps to humanly parse the address to avoid having to explain + to the customers that 2001:db8:0:1::1 is the same as + 2001:db8::1:0:0:0:1. This is one thing that will never happen in + IPv4 because IPv4 addresses cannot be abbreviated. 3.3.3. Abuse @@ -463,9 +472,9 @@ Internet-Draft IPv6 Text Representation February 2010 placement of the "::" will result in a critical situation. A system that handles these incidents should be able to handle any type of input and parse it in a correct manner. Also, incidents are reported - over the phone. It is unnecessary to report if the letter is an + over the phone. It is unnecessary to report if the letter is uppercase or lowercase. However, when a letter is spelled uppercase, - people tend to clarify that it is uppercase, which is unnecessary + people tend to specify that it is uppercase, which is unnecessary information. 3.4. Other Minor Problems @@ -474,7 +483,7 @@ Internet-Draft IPv6 Text Representation February 2010 When an engineer decides to change the platform of a running service, the same code may not work as expected due to the difference in IPv6 - address text representation. Usually, a change in a platform (e.g. + address text representation. Usually, a change in a platform (e.g., Unix to Windows, Cisco to Juniper) will result in a major change of code anyway, but flexibility in address representation will increase the work load. @@ -490,105 +499,104 @@ Internet-Draft IPv6 Text Representation February 2010 also be misread. -4. A Recommendation for IPv6 Text Representation - A recommendation for a canonical text representation format of IPv6 - addresses is presented in this section. The recommendation in this - document is one that, complies fully with [RFC4291], is implemented - by various operating systems, and is human friendly. The - recommendation in this section SHOULD be followed by systems when -Kawamura & Kawashima Expires August 29, 2010 [Page 9] +Kawamura & Kawashima Standards Track [Page 9] -Internet-Draft IPv6 Text Representation February 2010 +RFC 5952 IPv6 Text Representation August 2010 - generating an address to represent as text, but all implementations - MUST accept and be able to handle any legitimate [RFC4291] format. - It is advised that humans also follow these recommendations when - spelling an address. +4. A Recommendation for IPv6 Text Representation + + A recommendation for a canonical text representation format of IPv6 + addresses is presented in this section. The recommendation in this + document is one that complies fully with [RFC4291], is implemented by + various operating systems, and is human friendly. The recommendation + in this section SHOULD be followed by systems when generating an + address to be represented as text, but all implementations MUST + accept and be able to handle any legitimate [RFC4291] format. It is + advised that humans also follow these recommendations when spelling + an address. -4.1. Handling Leading Zeros in a 16 Bit Field +4.1. Handling Leading Zeros in a 16-Bit Field - Leading zeros MUST be suppressed. For example 2001:0db8::0001 is not - acceptable and must be represented as 2001:db8::1. A single 16 bit - 0000 field MUST be represented as 0. + Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is + not acceptable and must be represented as 2001:db8::1. A single 16- + bit 0000 field MUST be represented as 0. 4.2. "::" Usage -4.2.1. Shorten As Much As Possible +4.2.1. Shorten as Much as Possible - The use of symbol "::" MUST be used to its maximum capability. For - example, 2001:db8::0:1 is not acceptable, because the symbol "::" + The use of the symbol "::" MUST be used to its maximum capability. + For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1. + Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::" could have been used to produce a shorter representation 2001:db8::1. -4.2.2. Handling One 16 Bit 0 Field +4.2.2. Handling One 16-Bit 0 Field - The symbol "::" MUST NOT be used to shorten just one 16 bit 0 field. + The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. 4.2.3. Choice in Placement of "::" When there is an alternative choice in the placement of a "::", the - longest run of consecutive 16 bit 0 fields MUST be shortened (i.e. + longest run of consecutive 16-bit 0 fields MUST be shortened (i.e., the sequence with three consecutive zero fields is shortened in 2001: - 0:0:1:0:0:0:1). When the length of the consecutive 16 bit 0 fields - are equal (i.e. 2001:db8:0:0:1:0:0:1), the first sequence of zero - bits MUST be shortened. For example 2001:db8::1:0:0:1 is correct + 0:0:1:0:0:0:1). When the length of the consecutive 16-bit 0 fields + are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero + bits MUST be shortened. For example, 2001:db8::1:0:0:1 is correct representation. -4.3. Lower Case - - The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST - be represented in lower case. +4.3. Lowercase + The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address + MUST be represented in lowercase. -5. Text Representation of Special Addresses - - Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and - IPv4-translatable addresses [I-D.ietf-behave-address-format] have - IPv4 addresses embedded in the low-order 32 bits of the address. - These addresses have special representation that may mix hexadecimal - and dot decimal notations. The decimal notation may be used only for -Kawamura & Kawashima Expires August 29, 2010 [Page 10] +Kawamura & Kawashima Standards Track [Page 10] -Internet-Draft IPv6 Text Representation February 2010 +RFC 5952 IPv6 Text Representation August 2010 + +5. Text Representation of Special Addresses - the last 32 bits of the address. For these addresses, mixed notation - is RECOMMENDED if the following condition is met: The address can be + Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and + IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses + embedded in the low-order 32 bits of the address. These addresses + have a special representation that may mix hexadecimal and dot + decimal notations. The decimal notation may be used only for the + last 32 bits of the address. For these addresses, mixed notation is + RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits - solely from the address field through the use of a well known prefix. + solely from the address field through the use of a well-known prefix. Such prefixes are defined in [RFC4291] and [RFC2765] at the time of - writing. If it is known by some external method that a given prefix - is used to embed IPv4, it MAY be represented as mixed notation. - Tools that provide options to specify prefixes that are (or are not) - to be represented as mixed notation may be useful. - - There is a trade-off here where a recommendation to achieve exact - match in a search (no dot decimals whatsoever) and recommendation to - help the readability of an addresses (dot decimal whenever possible) + this writing. If it is known by some external method that a given + prefix is used to embed IPv4, it MAY be represented as mixed + notation. Tools that provide options to specify prefixes that are + (or are not) to be represented as mixed notation may be useful. + + There is a trade-off here where a recommendation to achieve an exact + match in a search (no dot decimals whatsoever) and a recommendation + to help the readability of an address (dot decimal whenever possible) does not result in the same solution. The above recommendation is aimed at fixing the representation as much as possible while leaving - the opportunity for future well known prefixes to be represented in a - human friendly manner as tools adjust to newly assigned prefixes. + the opportunity for future well-known prefixes to be represented in a + human-friendly manner as tools adjust to newly assigned prefixes. The text representation method noted in Section 4 should be applied - for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of + for the leading hexadecimal part (i.e., ::ffff:192.0.2.1 instead of 0:0:0:0:0:ffff:192.0.2.1). - 6. Notes on Combining IPv6 Addresses with Port Numbers - When IPv6 addresses and port numbers are represented in text combined - together, there are many different ways to do so. Examples are shown - below. + There are many different ways to combine IPv6 addresses and port + numbers that are represented in text. Examples are shown below. o [2001:db8::1]:80 @@ -604,30 +612,28 @@ Internet-Draft IPv6 Text Representation February 2010 The situation is not much different in IPv4, but the most ambiguous case with IPv6 is the second bullet. This is due to the "::"usage in - IPv6 addresses. This style is NOT RECOMMENDED for its ambiguity. - The [] style as expressed in [RFC3986] SHOULD be employed, and is the - default unless otherwise specified. Other styles are acceptable when - there is exactly one style for the given context and cross-platform - portability does not become an issue. For URIs containing IPv6 -Kawamura & Kawashima Expires August 29, 2010 [Page 11] +Kawamura & Kawashima Standards Track [Page 11] -Internet-Draft IPv6 Text Representation February 2010 +RFC 5952 IPv6 Text Representation August 2010 - address literals, [RFC3986] MUST be followed, as well as the rules in - this document. - + IPv6 addresses. This style is NOT RECOMMENDED because of its + ambiguity. The [] style as expressed in [RFC3986] SHOULD be + employed, and is the default unless otherwise specified. Other + styles are acceptable when there is exactly one style for the given + context and cross-platform portability does not become an issue. For + URIs containing IPv6 address literals, [RFC3986] MUST be followed, as + well as the rules defined in this document. 7. Prefix Representation - Problems with prefixes are just the same as problems encountered with + Problems with prefixes are the same as problems encountered with addresses. The text representation method of IPv6 prefixes should be no different from that of IPv6 addresses. - 8. Security Considerations This document notes some examples where IPv6 addresses are compared @@ -635,87 +641,67 @@ Internet-Draft IPv6 Text Representation February 2010 security risk if used for access control. The common practice of comparing X.509 data is done in binary format. +9. Acknowledgements -9. IANA Considerations + The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, + and Toshimitsu Matsuura for their generous and helpful comments in + kick starting this document. We also would like to thank Brian + Carpenter, Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave + Thaler, Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, + Heikki Vatiainen, Dan Wing, and Doug Barton for their input. Also, a + very special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert + Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing + this document to light in IETF working groups. - None. +10. References +10.1. Normative References -10. Acknowledgements + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. - The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, - Toshimitsu Matsuura for their generous and helpful comments in kick - starting this document. We also would like to thank Brian Carpenter, - Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, - Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki - Vatiainen ,Dan Wing, and Doug Barton for their input. Also a very - special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert - Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing - this document to the light of IETF working groups. + [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm + (SIIT)", RFC 2765, February 2000. + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. -11. References -11.1. Normative References - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm - (SIIT)", RFC 2765, February 2000. - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform +Kawamura & Kawashima Standards Track [Page 12] + +RFC 5952 IPv6 Text Representation August 2010 + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. -Kawamura & Kawashima Expires August 29, 2010 [Page 12] - -Internet-Draft IPv6 Text Representation February 2010 +10.2. Informative References + [ADDR-FORMAT] Bao, C., "IPv6 Addressing of IPv4/IPv6 Translators", + Work in Progress, July 2010. - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, January 2005. + [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. + Castro, "Application Aspects of IPv6 Transition", + RFC 4038, March 2005. - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. + [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site + Automatic Tunnel Addressing Protocol (ISATAP)", + RFC 5214, March 2008. -11.2. Informative References - [I-D.ietf-behave-address-format] - Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. - Li, "IPv6 Addressing of IPv4/IPv6 Translators", - draft-ietf-behave-address-format-04 (work in progress), - January 2010. - [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. - Castro, "Application Aspects of IPv6 Transition", - RFC 4038, March 2005. - [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site - Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, - March 2008. -Appendix A. For Developers - We recommend that developers use display routines that conform to - these rules. For example, the usage of getnameinfo() with flags - argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output, - except for the special addresses notes in Section 5. The function - inet_ntop() of FreeBSD7.0 is a good C code reference, but should not - be called directly. See [RFC4038] for details. -Authors' Addresses - Seiichi Kawamura - NEC BIGLOBE, Ltd. - 14-22, Shibaura 4-chome - Minatoku, Tokyo 108-8558 - JAPAN - Phone: +81 3 3798 6085 - Email: kawamucho@mesh.ad.jp @@ -724,19 +710,9 @@ Authors' Addresses -Kawamura & Kawashima Expires August 29, 2010 [Page 13] - -Internet-Draft IPv6 Text Representation February 2010 - Masanobu Kawashima - NEC AccessTechnica, Ltd. - 800, Shimomata - Kakegawa-shi, Shizuoka 436-8501 - JAPAN - Phone: +81 537 23 9655 - Email: kawashimam@necat.nec.co.jp @@ -751,14 +727,40 @@ Internet-Draft IPv6 Text Representation February 2010 +Kawamura & Kawashima Standards Track [Page 13] + +RFC 5952 IPv6 Text Representation August 2010 +Appendix A. For Developers + We recommend that developers use display routines that conform to + these rules. For example, the usage of getnameinfo() with flags + argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output, + except for the special addresses notes in Section 5. The function + inet_ntop() of FreeBSD7.0 is a good C code reference, but should not + be called directly. See [RFC4038] for details. +Authors' Addresses + Seiichi Kawamura + NEC BIGLOBE, Ltd. + 14-22, Shibaura 4-chome + Minatoku, Tokyo 108-8558 + JAPAN + Phone: +81 3 3798 6085 + EMail: kawamucho@mesh.ad.jp + Masanobu Kawashima + NEC AccessTechnica, Ltd. + 800, Shimomata + Kakegawa-shi, Shizuoka 436-8501 + JAPAN + + Phone: +81 537 23 9655 + EMail: kawashimam@necat.nec.co.jp @@ -780,6 +782,6 @@ Internet-Draft IPv6 Text Representation February 2010 -Kawamura & Kawashima Expires August 29, 2010 [Page 14] - +Kawamura & Kawashima Standards Track [Page 14] + diff --git a/doc/rfc/rfc5966.txt b/doc/rfc/rfc5966.txt new file mode 100644 index 00000000000..470796f823f --- /dev/null +++ b/doc/rfc/rfc5966.txt @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Bellis +Request for Comments: 5966 Nominet UK +Updates: 1035, 1123 August 2010 +Category: Standards Track +ISSN: 2070-1721 + + + DNS Transport over TCP - Implementation Requirements + +Abstract + + This document updates the requirements for the support of TCP as a + transport protocol for DNS implementations. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5966. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + +Bellis Standards Track [Page 1] + +RFC 5966 DNS over TCP August 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology Used in This Document . . . . . . . . . . . . . . . 3 + 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Transport Protocol Selection . . . . . . . . . . . . . . . . . 4 + 5. Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Response Reordering . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 + +1. Introduction + + Most DNS [RFC1034] transactions take place over UDP [RFC0768]. TCP + [RFC0793] is always used for zone transfers and is often used for + messages whose sizes exceed the DNS protocol's original 512-byte + limit. + + Section 6.1.3.2 of [RFC1123] states: + + DNS resolvers and recursive servers MUST support UDP, and SHOULD + support TCP, for sending (non-zone-transfer) queries. + + However, some implementors have taken the text quoted above to mean + that TCP support is an optional feature of the DNS protocol. + + The majority of DNS server operators already support TCP and the + default configuration for most software implementations is to support + TCP. The primary audience for this document is those implementors + whose failure to support TCP restricts interoperability and limits + deployment of new DNS features. + + This document therefore updates the core DNS protocol specifications + such that support for TCP is henceforth a REQUIRED part of a full DNS + protocol implementation. + + Whilst this document makes no specific recommendations to operators + of DNS servers, it should be noted that failure to support TCP (or + the blocking of DNS over TCP at the network layer) may result in + resolution failure and/or application-level timeouts. + + + + + + + + +Bellis Standards Track [Page 2] + +RFC 5966 DNS over TCP August 2010 + + +2. Terminology Used in This Document + + 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]. + +3. Discussion + + In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below), + the normal behaviour of any DNS server needing to send a UDP response + that would exceed the 512-byte limit is for the server to truncate + the response so that it fits within that limit and then set the TC + flag in the response header. When the client receives such a + response, it takes the TC flag as an indication that it should retry + over TCP instead. + + RFC 1123 also says: + + ... it is also clear that some new DNS record types defined in the + future will contain information exceeding the 512 byte limit that + applies to UDP, and hence will require TCP. Thus, resolvers and + name servers should implement TCP services as a backup to UDP + today, with the knowledge that they will require the TCP service + in the future. + + Existing deployments of DNS Security (DNSSEC) [RFC4033] have shown + that truncation at the 512-byte boundary is now commonplace. For + example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from + a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost + invariably larger than 512 bytes. + + Since the original core specifications for DNS were written, the + Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced. + These extensions can be used to indicate that the client is prepared + to receive UDP responses larger than 512 bytes. An EDNS0-compatible + server receiving a request from an EDNS0-compatible client may send + UDP packets up to that client's announced buffer size without + truncation. + + However, transport of UDP packets that exceed the size of the path + MTU causes IP packet fragmentation, which has been found to be + unreliable in some circumstances. Many firewalls routinely block + fragmented IP packets, and some do not implement the algorithms + necessary to reassemble fragmented packets. Worse still, some + network devices deliberately refuse to handle DNS packets containing + EDNS0 options. Other issues relating to UDP transport and packet + size are discussed in [RFC5625]. + + + + +Bellis Standards Track [Page 3] + +RFC 5966 DNS over TCP August 2010 + + + The MTU most commonly found in the core of the Internet is around + 1500 bytes, and even that limit is routinely exceeded by DNSSEC- + signed responses. + + The future that was anticipated in RFC 1123 has arrived, and the only + standardised UDP-based mechanism that may have resolved the packet + size issue has been found inadequate. + +4. Transport Protocol Selection + + All general-purpose DNS implementations MUST support both UDP and TCP + transport. + + o Authoritative server implementations MUST support TCP so that they + do not limit the size of responses to what fits in a single UDP + packet. + + o Recursive server (or forwarder) implementations MUST support TCP + so that they do not prevent large responses from a TCP-capable + server from reaching its TCP-capable clients. + + o Stub resolver implementations (e.g., an operating system's DNS + resolution library) MUST support TCP since to do otherwise would + limit their interoperability with their own clients and with + upstream servers. + + Stub resolver implementations MAY omit support for TCP when + specifically designed for deployment in restricted environments where + truncation can never occur or where truncated DNS responses are + acceptable. + + Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of + RFC 1123 also says: + + ... a DNS resolver or server that is sending a non-zone-transfer + query MUST send a UDP query first. + + That requirement is hereby relaxed. A resolver SHOULD send a UDP + query first, but MAY elect to send a TCP query instead if it has good + reason to expect the response would be truncated if it were sent over + UDP (with or without EDNS0) or for other operational reasons, in + particular, if it already has an open TCP connection to the server. + + + + + + + + + +Bellis Standards Track [Page 4] + +RFC 5966 DNS over TCP August 2010 + + +5. Connection Handling + + Section 4.2.2 of [RFC1035] says: + + If the server needs to close a dormant connection to reclaim + resources, it should wait until the connection has been idle for a + period on the order of two minutes. In particular, the server + should allow the SOA and AXFR request sequence (which begins a + refresh operation) to be made on a single connection. Since the + server would be unable to answer queries anyway, a unilateral + close or reset may be used instead of a graceful close. + + Other more modern protocols (e.g., HTTP [RFC2616]) have support for + persistent TCP connections and operational experience has shown that + long timeouts can easily cause resource exhaustion and poor response + under heavy load. Intentionally opening many connections and leaving + them dormant can trivially create a "denial-of-service" attack. + + It is therefore RECOMMENDED that the default application-level idle + period should be of the order of seconds, but no particular value is + specified. In practise, the idle period may vary dynamically, and + servers MAY allow dormant connections to remain open for longer + periods as resources permit. + + To mitigate the risk of unintentional server overload, DNS clients + MUST take care to minimize the number of concurrent TCP connections + made to any individual server. Similarly, servers MAY impose limits + on the number of concurrent TCP connections being handled for any + particular client. + + Further recommendations for the tuning of TCP stacks to allow higher + throughput or improved resiliency against denial-of-service attacks + are outside the scope of this document. + +6. Response Reordering + + RFC 1035 is ambiguous on the question of whether TCP queries may be + reordered -- the only relevant text is in Section 4.2.1, which + relates to UDP: + + Queries or their responses may be reordered by the network, or by + processing in name servers, so resolvers should not depend on them + being returned in order. + + For the avoidance of future doubt, this requirement is clarified. + Client resolvers MUST be able to process responses that arrive in a + different order to that in which the requests were sent, regardless + of the transport protocol in use. + + + +Bellis Standards Track [Page 5] + +RFC 5966 DNS over TCP August 2010 + + +7. Security Considerations + + Some DNS server operators have expressed concern that wider use of + DNS over TCP will expose them to a higher risk of denial-of-service + (DoS) attacks. + + Although there is a higher risk of such attacks against TCP-enabled + servers, techniques for the mitigation of DoS attacks at the network + level have improved substantially since DNS was first designed. + + At the time of writing, the vast majority of Top Level Domain (TLD) + authority servers and all of the root name servers support TCP and + the author knows of no evidence to suggest that TCP-based DoS attacks + against existing DNS infrastructure are commonplace. + + That notwithstanding, readers are advised to familiarise themselves + with [CPNI-TCP]. + + Operators of recursive servers should ensure that they only accept + connections from expected clients, and do not accept them from + unknown sources. In the case of UDP traffic, this will help protect + against reflector attacks [RFC5358] and in the case of TCP traffic it + will prevent an unknown client from exhausting the server's limits on + the number of concurrent connections. + +8. Acknowledgements + + The author would like to thank the document reviewers from the DNSEXT + Working Group, and in particular, George Barwood, Alex Bligh, Alfred + Hoenes, Fernando Gont, Olafur Gudmondsson, Jim Reid, Paul Vixie, and + Nicholas Weaver. + +9. References + +9.1. Normative References + + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + + + +Bellis Standards Track [Page 6] + +RFC 5966 DNS over TCP August 2010 + + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + +9.2. Informative References + + [CPNI-TCP] CPNI, "Security Assessment of the Transmission Control + Protocol (TCP)", 2009, . + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + + [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive + Nameservers in Reflector Attacks", BCP 140, RFC 5358, + October 2008. + + [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", + BCP 152, RFC 5625, August 2009. + +Author's Address + + Ray Bellis + Nominet UK + Edmund Halley Road + Oxford OX4 4DQ + United Kingdom + + Phone: +44 1865 332211 + EMail: ray.bellis@nominet.org.uk + URI: http://www.nominet.org.uk/ + + + + + + +Bellis Standards Track [Page 7] + diff --git a/doc/rfc/rfc6052.txt b/doc/rfc/rfc6052.txt new file mode 100644 index 00000000000..5b4389858ea --- /dev/null +++ b/doc/rfc/rfc6052.txt @@ -0,0 +1,1011 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Bao +Request for Comments: 6052 CERNET Center/Tsinghua University +Updates: 4291 C. Huitema +Category: Standards Track Microsoft Corporation +ISSN: 2070-1721 M. Bagnulo + UC3M + M. Boucadair + France Telecom + X. Li + CERNET Center/Tsinghua University + October 2010 + + + IPv6 Addressing of IPv4/IPv6 Translators + +Abstract + + This document discusses the algorithmic translation of an IPv6 + address to a corresponding IPv4 address, and vice versa, using only + statically configured information. It defines a well-known prefix + for use in algorithmic translations, while allowing organizations to + also use network-specific prefixes when appropriate. Algorithmic + translation is used in IPv4/IPv6 translators, as well as other types + of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6052. + + + + + + + + + + + + + +Bao, et al. Standards Track [Page 1] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3 + 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 5 + 2.1. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 5 + 2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 5 + 2.3. Address Translation Algorithms . . . . . . . . . . . . . . 7 + 2.4. Text Representation . . . . . . . . . . . . . . . . . . . 7 + 3. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 8 + 3.1. Restrictions on the Use of the Well-Known Prefix . . . . . 8 + 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8 + 3.3. Choice of Prefix for Stateless Translation Deployments . . 9 + 3.4. Choice of Prefix for Stateful Translation Deployments . . 11 + 4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.1. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12 + 4.2. Choice of the Well-Known Prefix . . . . . . . . . . . . . 13 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 5.1. Protection against Spoofing . . . . . . . . . . . . . . . 14 + 5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 15 + 5.3. Firewall Configuration . . . . . . . . . . . . . . . . . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 + + + + + + + +Bao, et al. Standards Track [Page 2] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + +1. Introduction + + This document is part of a series of IPv4/IPv6 translation documents. + A framework for IPv4/IPv6 translation is discussed in + [v4v6-FRAMEWORK], including a taxonomy of scenarios that will be used + in this document. Other documents specify the behavior of various + types of translators and gateways, including mechanisms for + translating between IP headers and other types of messages that + include IP addresses. This document specifies how an individual IPv6 + address is translated to a corresponding IPv4 address, and vice + versa, in cases where an algorithmic mapping is used. While specific + types of devices are used herein as examples, it is the + responsibility of the specification of such devices to reference this + document for algorithmic mapping of the addresses themselves. + + Section 2 describes the prefixes and the format of "IPv4-embedded + IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an + IPv4 address. This format is common to both "IPv4-converted" and + "IPv4-translatable" IPv6 addresses. This section also defines the + algorithms for translating addresses, and the text representation of + IPv4-embedded IPv6 addresses. + + Section 3 discusses the choice of prefixes, the conditions in which + they can be used, and the use of IPv4-embedded IPv6 addresses with + stateless and stateful translation. + + Section 4 provides a summary of the discussions behind two specific + design decisions, the choice of a null suffix and the specific value + of the selected prefix. + + Section 5 discusses security concerns. + + In some scenarios, a dual-stack host will unnecessarily send its + traffic through an IPv6/IPv4 translator. This can be caused by the + host's default address selection algorithm [RFC3484], referrals, or + other reasons. Optimizing these scenarios for dual-stack hosts is + for future study. + +1.1. Applicability Scope + + This document is part of a series defining address translation + services. We understand that the address format could also be used + by other interconnection methods between IPv6 and IPv4, e.g., methods + based on encapsulation. If encapsulation methods are developed by + the IETF, we expect that their descriptions will document their + specific use of IPv4-embedded IPv6 addresses. + + + + + +Bao, et al. Standards Track [Page 3] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + +1.2. Conventions + + 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]. + +1.3. Terminology + + This document makes use of the following terms: + + Address translator: any entity that has to derive an IPv4 address + from an IPv6 address or vice versa. This applies not only to + devices that do IPv4/IPv6 packet translation, but also to other + entities that manipulate addresses, such as name resolution + proxies (e.g., DNS64 [DNS64]) and possibly other types of + Application Layer Gateways (ALGs). + + IPv4-converted IPv6 addresses: IPv6 addresses used to represent IPv4 + nodes in an IPv6 network. They are a variant of IPv4-embedded + IPv6 addresses and follow the format described in Section 2.2. + + IPv4-embedded IPv6 addresses: IPv6 addresses in which 32 bits + contain an IPv4 address. Their format is described in + Section 2.2. + + IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6 + packets, and vice versa. It may do "stateless" translation, + meaning that there is no per-flow state required, or "stateful" + translation, meaning that per-flow state is created when the first + packet in a flow is received. + + IPv4-translatable IPv6 addresses: IPv6 addresses assigned to IPv6 + nodes for use with stateless translation. They are a variant of + IPv4-embedded IPv6 addresses and follow the format described in + Section 2.2. + + Network-Specific Prefix: an IPv6 prefix assigned by an organization + for use in algorithmic mapping. Options for the Network-Specific + Prefix are discussed in Sections 3.3 and 3.4. + + Well-Known Prefix: the IPv6 prefix defined in this document for use + in an algorithmic mapping. + + + + + + + + + +Bao, et al. Standards Track [Page 4] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + +2. IPv4-Embedded IPv6 Address Prefix and Format + +2.1. Well-Known Prefix + + This document reserves a "Well-Known Prefix" for use in an + algorithmic mapping. The value of this IPv6 prefix is: + + 64:ff9b::/96 + +2.2. IPv4-Embedded IPv6 Address Format + + IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses + follow the same format, described here as the IPv4-embedded IPv6 + address Format. IPv4-embedded IPv6 addresses are composed of a + variable-length prefix, the embedded IPv4 address, and a variable- + length suffix, as presented in the following diagram, in which PL + designates the prefix length: + + +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------| + +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + |32| prefix |v4(32) | u | suffix | + +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + |40| prefix |v4(24) | u |(8)| suffix | + +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + |48| prefix |v4(16) | u | (16) | suffix | + +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + |56| prefix |(8)| u | v4(24) | suffix | + +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + |64| prefix | u | v4(32) | suffix | + +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + |96| prefix | v4(32) | + +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + Figure 1 + + In these addresses, the prefix shall be either the "Well-Known + Prefix" or a "Network-Specific Prefix" unique to the organization + deploying the address translators. The prefixes can only have one of + the following lengths: 32, 40, 48, 56, 64, or 96. (The Well-Known + Prefix is 96 bits long, and can only be used in the last form of the + table.) + + Various deployments justify different prefix lengths with Network- + Specific Prefixes. The trade-off between different prefix lengths + are discussed in Sections 3.3 and 3.4. + + + + + +Bao, et al. Standards Track [Page 5] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + + Bits 64 to 71 of the address are reserved for compatibility with the + host identifier format defined in the IPv6 addressing architecture + [RFC4291]. These bits MUST be set to zero. When using a /96 + Network-Specific Prefix, the administrators MUST ensure that the bits + 64 to 71 are set to zero. A simple way to achieve that is to + construct the /96 Network-Specific Prefix by picking a /64 prefix, + and then adding 4 octets set to zero. + + The IPv4 address is encoded following the prefix, most significant + bits first. Depending of the prefix length, the 4 octets of the + address may be separated by the reserved octet "u", whose 8 bits MUST + be set to zero. In particular: + + o When the prefix is 32 bits long, the IPv4 address is encoded in + positions 32 to 63. + + o When the prefix is 40 bits long, 24 bits of the IPv4 address are + encoded in positions 40 to 63, with the remaining 8 bits in + position 72 to 79. + + o When the prefix is 48 bits long, 16 bits of the IPv4 address are + encoded in positions 48 to 63, with the remaining 16 bits in + position 72 to 87. + + o When the prefix is 56 bits long, 8 bits of the IPv4 address are + encoded in positions 56 to 63, with the remaining 24 bits in + position 72 to 95. + + o When the prefix is 64 bits long, the IPv4 address is encoded in + positions 72 to 103. + + o When the prefix is 96 bits long, the IPv4 address is encoded in + positions 96 to 127. + + There are no remaining bits, and thus no suffix, if the prefix is 96 + bits long. In the other cases, the remaining bits of the address + constitute the suffix. These bits are reserved for future extensions + and SHOULD be set to zero. Address translators who receive IPv4- + embedded IPv6 addresses where these bits are not zero SHOULD ignore + the bits' value and proceed as if the bits' value were zero. (Future + extensions may specify a different behavior.) + + + + + + + + + + +Bao, et al. Standards Track [Page 6] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + +2.3. Address Translation Algorithms + + IPv4-embedded IPv6 addresses are composed according to the following + algorithm: + + o Concatenate the prefix, the 32 bits of the IPv4 address, and the + suffix (if needed) to obtain a 128-bit address. + + o If the prefix length is less than 96 bits, insert the null octet + "u" at the appropriate position (bits 64 to 71), thus causing the + least significant octet to be excluded, as documented in Figure 1. + + The IPv4 addresses are extracted from the IPv4-embedded IPv6 + addresses according to the following algorithm: + + o If the prefix is 96 bits long, extract the last 32 bits of the + IPv6 address; + + o For the other prefix lengths, remove the "u" octet to obtain a + 120-bit sequence (effectively shifting bits 72-127 to positions + 64-119), then extract the 32 bits following the prefix. + +2.4. Text Representation + + IPv4-embedded IPv6 addresses will be represented in text in + conformity with Section 2.2 of [RFC4291]. IPv4-embedded IPv6 + addresses constructed using the Well-Known Prefix or a /96 Network- + Specific Prefix may be represented using the alternative form + presented in Section 2.2 of [RFC4291], with the embedded IPv4 address + represented in dotted decimal notation. Examples of such + representations are presented in Tables 1 and 2. + + +-----------------------+------------+------------------------------+ + | Network-Specific | IPv4 | IPv4-embedded IPv6 address | + | Prefix | address | | + +-----------------------+------------+------------------------------+ + | 2001:db8::/32 | 192.0.2.33 | 2001:db8:c000:221:: | + | 2001:db8:100::/40 | 192.0.2.33 | 2001:db8:1c0:2:21:: | + | 2001:db8:122::/48 | 192.0.2.33 | 2001:db8:122:c000:2:2100:: | + | 2001:db8:122:300::/56 | 192.0.2.33 | 2001:db8:122:3c0:0:221:: | + | 2001:db8:122:344::/64 | 192.0.2.33 | 2001:db8:122:344:c0:2:2100:: | + | 2001:db8:122:344::/96 | 192.0.2.33 | 2001:db8:122:344::192.0.2.33 | + +-----------------------+------------+------------------------------+ + + Table 1: Text Representation of IPv4-Embedded IPv6 Addresses Using + Network-Specific Prefixes + + + + + +Bao, et al. Standards Track [Page 7] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + + +-------------------+--------------+----------------------------+ + | Well-Known Prefix | IPv4 address | IPv4-Embedded IPv6 address | + +-------------------+--------------+----------------------------+ + | 64:ff9b::/96 | 192.0.2.33 | 64:ff9b::192.0.2.33 | + +-------------------+--------------+----------------------------+ + + Table 2: Text Representation of IPv4-Embedded IPv6 Addresses Using + the Well-Known Prefix + + The Network-Specific Prefix examples in Table 1 are derived from the + IPv6 prefix reserved for documentation in [RFC3849]. The IPv4 + address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for + documentation in [RFC5735]. The representation of IPv6 addresses is + compatible with [RFC5952]. + +3. Deployment Guidelines + +3.1. Restrictions on the Use of the Well-Known Prefix + + The Well-Known Prefix MUST NOT be used to represent non-global IPv4 + addresses, such as those defined in [RFC1918] or listed in Section 3 + of [RFC5735]. Address translators MUST NOT translate packets in + which an address is composed of the Well-Known Prefix and a non- + global IPv4 address; they MUST drop these packets. + + The Well-Known Prefix SHOULD NOT be used to construct IPv4- + translatable IPv6 addresses. The nodes served by IPv4-translatable + IPv6 addresses should be able to receive global IPv6 traffic bound to + their IPv4-translatable IPv6 address without incurring intermediate + protocol translation. This is only possible if the specific prefix + used to build the IPv4-translatable IPv6 addresses is advertised in + inter-domain routing, but the advertisement of more specific prefixes + derived from the Well-Known Prefix is not supported, as explained in + Section 3.2. Network-Specific Prefixes SHOULD be used in these + scenarios, as explained in Section 3.3. + + The Well-Known Prefix MAY be used by organizations deploying + translation services, as explained in Section 3.4. + +3.2. Impact on Inter-Domain Routing + + The Well-Known Prefix MAY appear in inter-domain routing tables, if + service providers decide to provide IPv6-IPv4 interconnection + services to peers. Advertisement of the Well-Known Prefix SHOULD be + controlled either by upstream and/or downstream service providers + according to inter-domain routing policies, e.g., through + + + + + +Bao, et al. Standards Track [Page 8] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + + configuration of BGP [RFC4271]. Organizations that advertise the + Well-Known Prefix in inter-domain routing MUST be able to provide + IPv4/IPv6 translation service. + + When the IPv4/IPv6 translation relies on the Well-Known Prefix, IPv4- + embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be + advertised in BGP (especially External BGP) [RFC4271] because this + leads to importing the IPv4 routing table into the IPv6 one and + therefore introduces scalability issues to the global IPv6 routing + table. Administrators of BGP nodes SHOULD configure filters that + discard advertisements of embedded IPv6 prefixes longer than the + Well-Known Prefix. + + When the IPv4/IPv6 translation service relies on Network-Specific + Prefixes, the IPv4-translatable IPv6 prefixes used in stateless + translation MUST be advertised with proper aggregation to the IPv6 + Internet. Similarly, if translators are configured with multiple + Network-Specific Prefixes, these prefixes MUST be advertised to the + IPv6 Internet with proper aggregation. + +3.3. Choice of Prefix for Stateless Translation Deployments + + Organizations may deploy translation services using stateless + translation. In these deployments, internal IPv6 nodes are addressed + using IPv4-translatable IPv6 addresses, which enable them to be + accessed by IPv4 nodes. The addresses of these external IPv4 nodes + are then represented in IPv4-converted IPv6 addresses. + + Organizations deploying stateless IPv4/IPv6 translation SHOULD assign + a Network-Specific Prefix to their IPv4/IPv6 translation service. + IPv4-translatable and IPv4-converted IPv6 addresses MUST be + constructed as specified in Section 2.2. IPv4-translatable IPv6 + addresses MUST use the selected Network-Specific Prefix. Both IPv4- + translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD + use the same prefix. + + Using the same prefix ensures that IPv6 nodes internal to the + organization will use the most efficient paths to reach the nodes + served by IPv4-translatable IPv6 addresses. Specifically, if a node + learns the IPv4 address of a target internal node without knowing + that this target is in fact located behind the same translator that + the node also uses, translation rules will ensure that the IPv6 + address constructed with the Network-Specific Prefix is the same as + the IPv4-translatable IPv6 address assigned to the target. Standard + routing preference (i.e., "most specific match wins") will then + ensure that the IPv6 packets are delivered directly, without + requiring that translators receive the packets and then return them + in the direction from which they came. + + + +Bao, et al. Standards Track [Page 9] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + + The intra-domain routing protocol must be able to deliver packets to + the nodes served by IPv4-translatable IPv6 addresses. This may + require routing on some or all of the embedded IPv4 address bits. + Security considerations detailed in Section 5 require that routers + check the validity of the IPv4-translatable IPv6 source addresses, + using some form of reverse path check. + + The management of stateless address translation can be illustrated + with a small example: + + We will consider an IPv6 network with the prefix 2001:db8: + 122::/48. The network administrator has selected the Network- + Specific Prefix 2001:db8:122:344::/64 for managing stateless IPv4/ + IPv6 translation. The IPv4-translatable address block for IPv4 + subnet 192.0.2.0/24 is 2001:db8:122:344:c0:2::/96. In this + network, the host A is assigned the IPv4-translatable IPv6 address + 2001:db8:122:344:c0:2:2100::, which corresponds to the IPv4 + address 192.0.2.33. Host A's address is configured either + manually or through DHCPv6. + + In this example, host A is not directly connected to the + translator, but instead to a link managed by a router R. The + router R is configured to forward to A the packets bound to 2001: + db8:122:344:c0:2:2100::. To receive these packets, R will + advertise reachability of the prefix 2001:db8:122:344:c0:2:2100::/ + 104 in the intra-domain routing protocol -- or perhaps a shorter + prefix if many hosts on link have IPv4-translatable IPv6 addresses + derived from the same IPv4 subnet. If a packet bound to + 192.0.2.33 reaches the translator, the destination address will be + translated to 2001:db8:122:344:c0:2:2100::, and the packet will be + routed towards R and then to A. + + Let's suppose now that a host B of the same domain learns the IPv4 + address of A, maybe through an application-specific referral. If + B has translation-aware software, B can compose a destination + address by combining the Network-Specific Prefix 2001:db8:122: + 344::/64 and the IPv4 address 192.0.2.33, resulting in the address + 2001:db8:122:344:c0:2:2100::. The packet sent by B will be + forwarded towards R, and then to A, avoiding protocol translation. + + Forwarding, and reverse path checks, are more efficient when + performed on the combination of the prefix and the IPv4 address. In + theory, routers are able to route on prefixes of any length, but in + practice there may be routers for which routing on prefixes larger + than 64 bits is slower. However, routing efficiency is not the only + consideration in the choice of a prefix length. Organizations also + need to consider the availability of prefixes, and the potential + impact of all-zero identifiers. + + + +Bao, et al. Standards Track [Page 10] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + + If a /32 prefix is used, all the routing bits are contained in the + top 64 bits of the IPv6 address, leading to excellent routing + properties. These prefixes may however be hard to obtain, and + allocation of a /32 to a small set of IPv4-translatable IPv6 + addresses may be seen as wasteful. In addition, the /32 prefix and a + zero suffix lead to an all-zero interface identifier, which is an + issue that we discuss in Section 4.1. + + Intermediate prefix lengths such as /40, /48, or /56 appear as + compromises. Only some of the IPv4 bits are part of the /64 + prefixes. Reverse path checks, in particular, may have a limited + efficiency. Reverse path checks limited to the most significant bits + of the IPv4 address will reduce the possibility of spoofing external + IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4- + translatable IPv6 addresses. + + We propose a compromise, based on using no more than 1/256th of an + organization's allocation of IPv6 addresses for the IPv4/IPv6 + translation service. For example, if the organization is an Internet + Service Provider with an allocated IPv6 prefix /32 or shorter, the + ISP could dedicate a /40 prefix to the translation service. An end + site with a /48 allocation could dedicate a /56 prefix to the + translation service, or possibly a /96 prefix if all IPv4- + translatable IPv6 addresses are located on the same link. + + The recommended prefix length is also a function of the deployment + scenario. The stateless translation can be used for Scenario 1, + Scenario 2, Scenario 5, and Scenario 6 defined in [v4v6-FRAMEWORK]. + For different scenarios, the prefix length recommendations are: + + o For Scenario 1 (an IPv6 network to the IPv4 Internet) and Scenario + 2 (the IPv4 Internet to an IPv6 network), an ISP holding a /32 + allocation SHOULD use a /40 prefix, and a site holding a /48 + allocation SHOULD use a /56 prefix. + + o For Scenario 5 (an IPv6 network to an IPv4 network) and Scenario 6 + (an IPv4 network to an IPv6 network), the deployment SHOULD use a + /64 or a /96 prefix. + +3.4. Choice of Prefix for Stateful Translation Deployments + + Organizations may deploy translation services based on stateful + translation technology. An organization may decide to use either a + Network-Specific Prefix or the Well-Known Prefix for its stateful + IPv4/IPv6 translation service. + + + + + + +Bao, et al. Standards Track [Page 11] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + + When these services are used, IPv6 nodes are addressed through + standard IPv6 addresses, while IPv4 nodes are represented by IPv4- + converted IPv6 addresses, as specified in Section 2.2. + + The stateful nature of the translation creates a potential stability + issue when the organization deploys multiple translators. If several + translators use the same prefix, there is a risk that packets + belonging to the same connection may be routed to different + translators as the internal routing state changes. This issue can be + avoided either by assigning different prefixes to different + translators or by ensuring that all translators using the same prefix + coordinate their state. + + Stateful translation can be used in scenarios defined in + [v4v6-FRAMEWORK]. The Well-Known Prefix SHOULD be used in these + scenarios, with two exceptions: + + o In all scenarios, the translation MAY use a Network-Specific + Prefix, if deemed appropriate for management reasons. + + o The Well-Known Prefix MUST NOT be used for Scenario 3 (the IPv6 + Internet to an IPv4 network), as this would lead to using the + Well-Known Prefix with non-global IPv4 addresses. That means a + Network-Specific Prefix (for example, a /96 prefix) MUST be used + in that scenario. + +4. Design Choices + + The prefix that we have chosen reflects two design choices, the null + suffix and the specific value of the Well-Known Prefix. We provide + here a summary of the discussions leading to those two choices. + +4.1. Choice of Suffix + + The address format described in Section 2.2 recommends a zero suffix. + Before making this recommendation, we considered different options: + checksum neutrality, the encoding of a port range, and a value + different than 0. + + In the case of stateless translation, there would be no need for the + translator to recompute a one's complement checksum if both the IPv4- + translatable and the IPv4-converted IPv6 addresses were constructed + in a "checksum-neutral" manner, that is, if the IPv6 addresses would + have the same one's complement checksum as the embedded IPv4 address. + In the case of stateful translation, checksum neutrality does not + eliminate checksum computation during translation, as only one of the + two addresses would be checksum neutral. We considered reserving 16 + bits in the suffix to guarantee checksum neutrality, but declined + + + +Bao, et al. Standards Track [Page 12] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + + because it would not help with stateful translation and because + checksum neutrality can also be achieved by an appropriate choice of + the Network-Specific Prefix, i.e., selecting a prefix whose one's + complement checksum equals either 0 or 0xffff. + + There have been proposals to complement stateless translation with a + port-range feature. Instead of mapping an IPv4 address to exactly + one IPv6 prefix, the options would allow several IPv6 nodes to share + an IPv4 address, with each node managing a different range of ports. + If a port range extension is needed, it could be defined later, using + bits currently reserved as null in the suffix. + + When a /32 prefix is used, an all-zero suffix results in an all-zero + interface identifier. We understand the conflict with Section 2.6.1 + of RFC4291, which specifies that all zeroes are used for the subnet- + router anycast address. However, in our specification, there is only + one node with an IPv4-translatable IPv6 address in the /64 subnet, so + the anycast semantic does not create confusion. We thus decided to + keep the null suffix for now. This issue does not exist for prefixes + larger than 32 bits, such as the /40, /56, /64, and /96 prefixes that + we recommend in Section 3.3. + +4.2. Choice of the Well-Known Prefix + + Before making our recommendation of the Well-Known Prefix, we were + faced with three choices: + + o reuse the IPv4-mapped prefix, ::ffff:0:0/96, as specified in RFC + 2765, Section 2.1; + + o request IANA to allocate a /32 prefix, or + + o request allocation of a new /96 prefix. + + We weighted the pros and cons of these choices before settling on the + recommended /96 Well-Known Prefix. + + The main advantage of the existing IPv4-mapped prefix is that it is + already defined. Reusing that prefix would require minimal + standardization efforts. However, being already defined is not just + an advantage, as there may be side effects of current + implementations. When presented with the IPv4-mapped prefix, current + versions of Windows and Mac OS generate IPv4 packets, but will not + send IPv6 packets. If we used the IPv4-mapped prefix, these nodes + would not be able to support translation without modification. This + will defeat the main purpose of the translation techniques. We thus + eliminated the first choice, i.e., decided to not reuse the IPv4- + mapped prefix, ::ffff:0:0/96. + + + +Bao, et al. Standards Track [Page 13] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + + A /32 prefix would have allowed the embedded IPv4 address to fit + within the top 64 bits of the IPv6 address. This would have + facilitated routing and load balancing when an organization deploys + several translators. However, such destination-address-based load + balancing may not be desirable. It is not compatible with Session + Traversal Utilities for NAT (STUN) [RFC5389] in the deployments + involving multiple stateful translators, each one having a different + pool of IPv4 addresses. STUN compatibility would only be achieved if + the translators managed the same pool of IPv4 addresses and were able + to coordinate their translation state, in which case there is no big + advantage to using a /32 prefix rather than a /96 prefix. + + According to Section 2.2 of [RFC4291], in the legal textual + representations of IPv6 addresses, dotted decimal can only appear at + the end. The /96 prefix is compatible with that requirement. It + enables the dotted decimal notation without requiring an update to + [RFC4291]. This representation makes the address format easier to + use and the log files easier to read. + + The prefix that we recommend has the particularity of being "checksum + neutral". The sum of the hexadecimal numbers "0064" and "ff9b" is + "ffff", i.e., a value equal to zero in one's complement arithmetic. + An IPv4-embedded IPv6 address constructed with this prefix will have + the same one's complement checksum as the embedded IPv4 address. + +5. Security Considerations + +5.1. Protection against Spoofing + + IPv4/IPv6 translators can be modeled as special routers, are subject + to the same risks, and can implement the same mitigations. (The + discussion of generic threats to routers and their mitigations is + beyond the scope of this document.) There is, however, a particular + risk that directly derives from the practice of embedding IPv4 + addresses in IPv6: address spoofing. + + An attacker could use an IPv4-embedded IPv6 address as the source + address of malicious packets. After translation, the packets will + appear as IPv4 packets from the specified source, and the attacker + may be hard to track. If left without mitigation, the attack would + allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses. + + The mitigation is to implement reverse path checks and to verify + throughout the network that packets are coming from an authorized + location. + + + + + + +Bao, et al. Standards Track [Page 14] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + +5.2. Secure Configuration + + The prefixes used for address translation are used by IPv6 nodes to + send packets to IPv6/IPv4 translators. Attackers could attempt to + fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong + values for these parameters, resulting in network disruption, denial + of service, and possible information disclosure. To mitigate such + attacks, network administrators need to ensure that prefixes are + configured in a secure way. + + The mechanisms for achieving secure configuration of prefixes are + beyond the scope of this document. + +5.3. Firewall Configuration + + Many firewalls and other security devices filter traffic based on + IPv4 addresses. Attackers could attempt to fool these firewalls by + sending IPv6 packets to or from IPv6 addresses that translate to the + filtered IPv4 addresses. If the attack is successful, traffic that + was previously blocked might be able to pass through the firewalls + disguised as IPv6 packets. In all such scenarios, administrators + should assure that packets that send to or from IPv4-embedded IPv6 + addresses are subject to the same filtering as those directly sent to + or from the embedded IPv4 addresses. + + The mechanisms for configuring firewalls and security devices to + achieve this filtering are beyond the scope of this document. + +6. IANA Considerations + + IANA has made the following changes in the "Internet Protocol Version + 6 Address Space" registry located at http://www.iana.org. + + OLD: + + IPv6 Prefix Allocation Reference Note + ----------- ---------------- ------------ ---------------- + 0000::/8 Reserved by IETF [RFC4291] [1][5] + + NEW: + + IPv6 Prefix Allocation Reference Note + ----------- ---------------- ------------ ---------------- + 0000::/8 Reserved by IETF [RFC4291] [1][5][6] + + [6] The "Well-Known Prefix" 64:ff9b::/96 used in an algorithmic + mapping between IPv4 to IPv6 addresses is defined out of the + 0000::/8 address block, per RFC 6052. + + + +Bao, et al. Standards Track [Page 15] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + +7. Acknowledgements + + Many people in the BEHAVE WG have contributed to the discussion that + led to this document, including Andrew Sullivan, Andrew Yourtchenko, + Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler, + David Harrington, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch + van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus + Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip + Matthews, Remi Denis-Courmont, Remi Despres, and William Waites. + + Marcelo Bagnulo is partly funded by Trilogy, a research project + supported by the European Commission under its Seventh Framework + Program. + +8. Contributors + + The following individuals co-authored documents from which text has + been incorporated, and are listed in alphabetical order. + + Dave Thaler + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + USA + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + Fred Baker + Cisco Systems + Santa Barbara, California 93117 + USA + Phone: +1-408-526-4257 + Fax: +1-413-473-2403 + EMail: fred@cisco.com + + Hiroshi Miyata + Yokogawa Electric Corporation + 2-9-32 Nakacho + Musashino-shi, Tokyo 180-8750 + JAPAN + EMail: h.miyata@jp.yokogawa.com + + + + + + + + + + +Bao, et al. Standards Track [Page 16] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + +9.2. Informative References + + [DNS64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, + "DNS64: DNS extensions for Network Address Translation + from IPv6 Clients to IPv4 Servers", Work in Progress, + October 2010. + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and + E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC3484] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + + [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix + Reserved for Documentation", RFC 3849, July 2004. + + [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway + Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + October 2008. + + [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", + BCP 153, RFC 5735, January 2010. + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, August 2010. + + [v4v6-FRAMEWORK] + Baker, F., Li, X., Bao, C., and K. Yin, "Framework for + IPv4/IPv6 Translation", Work in Progress, August 2010. + + + + + + + + +Bao, et al. Standards Track [Page 17] + +RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 + + +Authors' Addresses + + Congxiao Bao + CERNET Center/Tsinghua University + Room 225, Main Building, Tsinghua University + Beijing, 100084 + China + Phone: +86 10-62785983 + EMail: congxiao@cernet.edu.cn + + + Christian Huitema + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052-6399 + U.S.A. + EMail: huitema@microsoft.com + + + Marcelo Bagnulo + UC3M + Av. Universidad 30 + Leganes, Madrid 28911 + Spain + Phone: +34-91-6249500 + EMail: marcelo@it.uc3m.es + URI: http://www.it.uc3m.es/marcelo + + + Mohamed Boucadair + France Telecom + 3, Av Francois Chateaux + Rennes 350000 + France + EMail: mohamed.boucadair@orange-ftgroup.com + + + Xing Li + CERNET Center/Tsinghua University + Room 225, Main Building, Tsinghua University + Beijing, 100084 + China + Phone: +86 10-62785983 + EMail: xing@cernet.edu.cn + + + + + + + +Bao, et al. Standards Track [Page 18] + diff --git a/doc/draft/draft-ietf-behave-dns64-11.txt b/doc/rfc/rfc6147.txt similarity index 57% rename from doc/draft/draft-ietf-behave-dns64-11.txt rename to doc/rfc/rfc6147.txt index 3c5ac813f79..0ccd9335309 100644 --- a/doc/draft/draft-ietf-behave-dns64-11.txt +++ b/doc/rfc/rfc6147.txt @@ -1,20 +1,22 @@ -BEHAVE WG M. Bagnulo -Internet-Draft UC3M -Intended status: Standards Track A. Sullivan -Expires: April 4, 2011 Shinkuro + + + +Internet Engineering Task Force (IETF) M. Bagnulo +Request for Comments: 6147 UC3M +Category: Standards Track A. Sullivan +ISSN: 2070-1721 Shinkuro P. Matthews Alcatel-Lucent I. van Beijnum IMDEA Networks - October 1, 2010 + April 2011 -DNS64: DNS extensions for Network Address Translation from IPv6 Clients - to IPv4 Servers - draft-ietf-behave-dns64-11 + DNS64: DNS Extensions for Network Address Translation + from IPv6 Clients to IPv4 Servers Abstract @@ -26,37 +28,44 @@ Abstract specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. -Status of this Memo +Status of This Memo - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6147. - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - 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." - This Internet-Draft will expire on April 4, 2011. -Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - This document is subject to BCP 78 and the IETF Trust's Legal -Bagnulo, et al. Expires April 4, 2011 [Page 1] + + + + + +Bagnulo, et al. Standards Track [Page 1] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 + + +Copyright Notice + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -102,196 +111,139 @@ Internet-Draft DNS64 October 2010 - - - - - - -Bagnulo, et al. Expires April 4, 2011 [Page 2] +Bagnulo, et al. Standards Track [Page 2] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Background to DNS64-DNSSEC interaction . . . . . . . . . . . . 8 - 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 11 - 5.1. Resolving AAAA queries and the answer section . . . . . . 11 - 5.1.1. The answer when there is AAAA data available . . . . . 12 - 5.1.2. The answer when there is an error . . . . . . . . . . 12 - 5.1.3. Dealing with timeouts . . . . . . . . . . . . . . . . 12 - 5.1.4. Special exclusion set for AAAA records . . . . . . . . 13 - 5.1.5. Dealing with CNAME and DNAME . . . . . . . . . . . . . 13 - 5.1.6. Data for the answer when performing synthesis . . . . 13 - 5.1.7. Performing the synthesis . . . . . . . . . . . . . . . 14 - 5.1.8. Querying in parallel . . . . . . . . . . . . . . . . . 14 - 5.2. Generation of the IPv6 representations of IPv4 - addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 - 5.3. Handling other Resource Records and the Additional - Section . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.3.1. PTR Resource Record . . . . . . . . . . . . . . . . . 16 - 5.3.2. Handling the additional section . . . . . . . . . . . 17 - 5.3.3. Other Resource Records . . . . . . . . . . . . . . . . 17 - 5.4. Assembling a synthesized response to a AAAA query . . . . 18 - 5.5. DNSSEC processing: DNS64 in validating resolver mode . . . 18 - 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 19 - 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 19 - 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 20 - 6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 20 - 6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 20 - 6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 21 - 6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 21 - 7. Deployment scenarios and examples . . . . . . . . . . . . . . 22 - 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with - DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 22 - 7.2. An example of an-IPv6-network-to-IPv4-Internet setup - with DNS64 in stub-resolver mode . . . . . . . . . . . . . 24 - 7.3. Example of IPv6-Internet-to-an-IPv4-network setup - DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 25 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 - Appendix A. Motivations and Implications of synthesizing AAAA - Resource Records when real AAAA Resource Records - - - -Bagnulo, et al. Expires April 4, 2011 [Page 3] + 1. Introduction ....................................................4 + 2. Overview ........................................................5 + 3. Background to DNS64-DNSSEC Interaction ..........................7 + 4. Terminology .....................................................9 + 5. DNS64 Normative Specification ..................................10 + 5.1. Resolving AAAA Queries and the Answer Section .............11 + 5.1.1. The Answer when There is AAAA Data Available .......11 + 5.1.2. The Answer when There is an Error ..................11 + 5.1.3. Dealing with Timeouts ..............................12 + 5.1.4. Special Exclusion Set for AAAA Records .............12 + 5.1.5. Dealing with CNAME and DNAME .......................12 + 5.1.6. Data for the Answer when Performing Synthesis ......13 + 5.1.7. Performing the Synthesis ...........................13 + 5.1.8. Querying in Parallel ...............................14 + 5.2. Generation of the IPv6 Representations of IPv4 Addresses ..14 + 5.3. Handling Other Resource Records and the Additional + Section ...................................................15 + 5.3.1. PTR Resource Record ................................15 + 5.3.2. Handling the Additional Section ....................16 + 5.3.3. Other Resource Records .............................17 + 5.4. Assembling a Synthesized Response to a AAAA Query .........17 + 5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode ......17 + 6. Deployment Notes ...............................................19 + 6.1. DNS Resolvers and DNS64 ...................................19 + 6.2. DNSSEC Validators and DNS64 ...............................19 + 6.3. DNS64 and Multihomed and Dual-Stack Hosts .................19 + 6.3.1. IPv6 Multihomed Hosts ..............................19 + 6.3.2. Accidental Dual-Stack DNS64 Use ....................20 + 6.3.3. Intentional Dual-Stack DNS64 Use ...................21 + 7. Deployment Scenarios and Examples ..............................21 + 7.1. Example of "an IPv6 Network to the IPv4 Internet" + Setup with DNS64 in DNS Server Mode .......................22 + 7.2. Example of "an IPv6 Network to the IPv4 Internet" + Setup with DNS64 in Stub-Resolver Mode ....................23 + 7.3. Example of "the IPv6 Internet to an IPv4 Network" + Setup with DNS64 in DNS Server Mode .......................24 + 8. Security Considerations ........................................27 + 9. Contributors ...................................................27 + 10. Acknowledgements ..............................................27 + 11. References ....................................................28 + 11.1. Normative References .....................................28 + 11.2. Informative References ...................................28 + Appendix A. Motivations and Implications of Synthesizing AAAA + Resource Records when Real AAAA Resource Records + Exist ................................................30 + + + + +Bagnulo, et al. Standards Track [Page 3] -Internet-Draft DNS64 October 2010 - - - exist . . . . . . . . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bagnulo, et al. Expires April 4, 2011 [Page 4] - -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 1. Introduction This document specifies DNS64, a mechanism that is part of the - toolbox for IPv6-IPv4 transition and co-existence. DNS64, used + toolbox for IPv4-IPv6 transition and coexistence. DNS64, used together with an IPv6/IPv4 translator such as stateful NAT64 - [I-D.ietf-behave-v6v4-xlate-stateful], allows an IPv6-only client to - initiate communications by name to an IPv4-only server. + [RFC6146], allows an IPv6-only client to initiate communications by + name to an IPv4-only server. DNS64 is a mechanism for synthesizing AAAA resource records (RRs) from A RRs. A synthetic AAAA RR created by the DNS64 from an - original A RR contains the same owner name of the original A RR but + original A RR contains the same owner name of the original A RR, but it contains an IPv6 address instead of an IPv4 address. The IPv6 address is an IPv6 representation of the IPv4 address contained in the original A RR. The IPv6 representation of the IPv4 address is algorithmically generated from the IPv4 address returned in the A RR and a set of parameters configured in the DNS64 (typically, an IPv6 - prefix used by IPv6 representations of IPv4 addresses and optionally - other parameters). + prefix used by IPv6 representations of IPv4 addresses and, + optionally, other parameters). Together with an IPv6/IPv4 translator, these two mechanisms allow an IPv6-only client to initiate communications to an IPv4-only server - using the FQDN of the server. + using the Fully Qualified Domain Name (FQDN) of the server. These mechanisms are expected to play a critical role in the IPv4- - IPv6 transition and co-existence. Due to IPv4 address depletion, it + IPv6 transition and coexistence. Due to IPv4 address depletion, it is likely that in the future, many IPv6-only clients will want to connect to IPv4-only servers. In the typical case, the approach only requires the deployment of IPv6/IPv4 translators that connect an IPv6-only network to an IPv4-only network, along with the deployment of one or more DNS64-enabled name servers. However, some features - require performing the DNS64 function directly in the end-hosts + require performing the DNS64 function directly in the end hosts themselves. - This document is structured as follows: section 2 provides a non- - normative overview of the behaviour of DNS64. Section 3 provides a - non-normative background required to understand the interaction - between DNS64 and DNSSEC. The normative specification of DNS64 is - provided in sections 4, 5 and 6. Section 4 defines the terminology, - section 5 is the actual DNS64 specification and section 6 covers - deployments issues. Section 7 is non-normative and provides a set of - examples and typical deployment scenarios. + This document is structured as follows: Section 2 provides a + non-normative overview of the behavior of DNS64. Section 3 provides + a non-normative background required to understand the interaction + between DNS64 and DNS Security Extensions (DNSSEC). The normative + specification of DNS64 is provided in Sections 4, 5, and 6. + Section 4 defines the terminology, Section 5 is the actual DNS64 + specification, and Section 6 covers deployment issues. Section 7 is + non-normative and provides a set of examples and typical deployment + scenarios. -2. Overview - This section provides an introduction to the DNS64 mechanism. - We assume that we have one or more IPv6/IPv4 translator boxes -Bagnulo, et al. Expires April 4, 2011 [Page 5] + + +Bagnulo, et al. Standards Track [Page 4] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 +2. Overview + + This section provides an introduction to the DNS64 mechanism. + + We assume that we have one or more IPv6/IPv4 translator boxes connecting an IPv4 network and an IPv6 network. The IPv6/IPv4 translator device provides translation services between the two - networks enabling communication between IPv4-only hosts and IPv6-only - hosts. (NOTE: By IPv6-only hosts we mean hosts running IPv6-only - applications, hosts that can only use IPv6, as well as cases where - only IPv6 connectivity is available to the client. By IPv4-only - servers we mean servers running IPv4-only applications, servers that - can only use IPv4, as well as cases where only IPv4 connectivity is - available to the server). Each IPv6/IPv4 translator used in - conjunction with DNS64 must allow communications initiated from the - IPv6-only host to the IPv4-only host. + networks, enabling communication between IPv4-only hosts and + IPv6-only hosts. (NOTE: By "IPv6-only hosts", we mean hosts running + IPv6-only applications and hosts that can only use IPv6, as well as + cases where only IPv6 connectivity is available to the client. By + "IPv4-only servers", we mean servers running IPv4-only applications + and servers that can only use IPv4, as well as cases where only IPv4 + connectivity is available to the server). Each IPv6/IPv4 translator + used in conjunction with DNS64 must allow communications initiated + from the IPv6-only host to the IPv4-only host. To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to learn the address of the responder, DNS64 is used to synthesize a @@ -313,35 +265,35 @@ Internet-Draft DNS64 October 2010 the IPv4 address and additional parameters configured in the DNS64. Among those parameters configured in the DNS64, there is at least one IPv6 prefix. If not explicitly mentioned, all prefixes are treated - equally and the operations described in this document are performed + equally, and the operations described in this document are performed using the prefixes available. So as to be general, we will call any of these prefixes Pref64::/n, and describe the operations made with - the generic prefix Pref64::/n. The IPv6 address representing IPv4 + the generic prefix Pref64::/n. The IPv6 addresses representing IPv4 addresses included in the AAAA RR synthesized by the DNS64 contain - Pref64::/n and they also embed the original IPv4 address. + Pref64::/n, and they also embed the original IPv4 address. The same algorithm and the same Pref64::/n prefix(es) must be configured both in the DNS64 device and the IPv6/IPv4 translator(s), so that both can algorithmically generate the same IPv6 representation for a given IPv4 address. In addition, it is required - that IPv6 packets addressed to an IPv6 destination address that - contains the Pref64::/n be delivered to an IPv6/IPv4 translator that - has that particular Pref64::/n configured, so they can be translated - into IPv4 packets. - -Bagnulo, et al. Expires April 4, 2011 [Page 6] +Bagnulo, et al. Standards Track [Page 5] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 + + that IPv6 packets addressed to an IPv6 destination address that + contains the Pref64::/n be delivered to an IPv6/IPv4 translator that + has that particular Pref64::/n configured, so they can be translated + into IPv4 packets. Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs are passed back to the IPv6 initiator, which will initiate an IPv6 communication with the IPv6 address associated with the IPv4 - receiver. The packet will be routed to an IPv6/IPv4 translator which - will forward it to the IPv4 network. + receiver. The packet will be routed to an IPv6/IPv4 translator, + which will forward it to the IPv4 network. In general, the only shared state between the DNS64 and the IPv6/IPv4 translator is the Pref64::/n and an optional set of static @@ -352,14 +304,14 @@ Internet-Draft DNS64 October 2010 scope of this memo. The prefixes to be used as Pref64::/n and their applicability are - discussed in [I-D.ietf-behave-address-format]. There are two types - of prefixes that can be used as Pref64::/n. + discussed in [RFC6052]. There are two types of prefixes that can be + used as Pref64::/n. - The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved - by [I-D.ietf-behave-address-format] for the purpose of - representing IPv4 addresses in IPv6 address space. + o The Pref64::/n can be the Well-Known Prefix 64:ff9b::/96 reserved + by [RFC6052] for the purpose of representing IPv4 addresses in + IPv6 address space. - The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is + o The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is an IPv6 prefix assigned by an organization to create IPv6 representations of IPv4 addresses. @@ -378,27 +330,29 @@ Internet-Draft DNS64 October 2010 synthetic AAAA RRs for an IPv4-only host in its zone. This is one type of DNS64 server. - Another option is to locate the DNS64 function in recursive name - servers serving end hosts. In this case, when an IPv6-only host - queries the name server for AAAA RRs for an IPv4-only host, the name - server can perform the synthesis of AAAA RRs and pass them back to - the IPv6-only initiator. The main advantage of this mode is that - current IPv6 nodes can use this mechanism without requiring any - modification. This mode is called "DNS64 in DNS recursive resolver -Bagnulo, et al. Expires April 4, 2011 [Page 7] + + +Bagnulo, et al. Standards Track [Page 6] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 + Another option is to locate the DNS64 function in recursive name + servers serving end hosts. In this case, when an IPv6-only host + queries the name server for AAAA RRs for an IPv4-only host, the name + server can perform the synthesis of AAAA RRs and pass them back to + the IPv6-only initiator. The main advantage of this mode is that + current IPv6 nodes can use this mechanism without requiring any + modification. This mode is called "DNS64 in DNS recursive-resolver mode". This is a second type of DNS64 server, and it is also one type of DNS64 resolver. The last option is to place the DNS64 function in the end hosts, coupled to the local (stub) resolver. In this case, the stub - resolver will try to obtain (real) AAAA RRs and in case they are not + resolver will try to obtain (real) AAAA RRs, and in case they are not available, the DNS64 function will synthesize AAAA RRs for internal usage. This mode is compatible with some functions like DNSSEC validation in the end host. The main drawback of this mode is its @@ -406,8 +360,7 @@ Internet-Draft DNS64 October 2010 is called "DNS64 in stub-resolver mode". This is the second type of DNS64 resolver. - -3. Background to DNS64-DNSSEC interaction +3. Background to DNS64-DNSSEC Interaction DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge for DNS64, because DNSSEC is designed to detect changes to DNS @@ -419,7 +372,7 @@ Internet-Draft DNS64 October 2010 non-validating, according to operator policy. In the cases below, the recursive resolver is also performing DNS64, and has a local policy to validate. We call this general case vDNS64, but in all the - cases below the DNS64 functionality should be assumed needed. + cases below, the DNS64 functionality should be assumed to be needed. DNSSEC includes some signaling bits that offer some indicators of what the query originator understands. @@ -432,22 +385,24 @@ Internet-Draft DNS64 October 2010 clear, that is evidence that the querying agent is not aware of DNSSEC. - If a query arrives at a vDNS64 device with the "Checking Disabled" - (CD) bit set, it is an indication that the querying agent wants all - the validation data so it can do checking itself. By local policy, - vDNS64 could still validate, but it must return all data to the - querying agent anyway. - Here are the possible cases: -Bagnulo, et al. Expires April 4, 2011 [Page 8] +Bagnulo, et al. Standards Track [Page 7] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 + + + If a query arrives at a vDNS64 device with the "Checking Disabled" + (CD) bit set, it is an indication that the querying agent wants all + the validation data so it can do checking itself. By local policy, + vDNS64 could still validate, but it must return all data to the + querying agent anyway. + Here are the possible cases: 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with the DO bit clear. In this case, DNSSEC is not a concern, because @@ -463,48 +418,48 @@ Internet-Draft DNS64 October 2010 3. A security-aware and non-validating DNS64 receives a query with the DO bit set and the CD bit clear. Such a resolver is not validating responses, likely due to local policy (see [RFC4035], - section 4.2). For that reason, this case amounts to the same as + Section 4.2). For that reason, this case amounts to the same as the previous case, and no validation happens. 4. A security-aware and non-validating DNS64 receives a query with the DO bit set and the CD bit set. In this case, the DNS64 is supposed to pass on all the data it gets to the query initiator - (see section 3.2.2 of [RFC4035]). This case will not work with + (see Section 3.2.2 of [RFC4035]). This case will not work with DNS64, unless the validating resolver is prepared to do DNS64 itself. If the DNS64 modifies the record, the client will get the data back and try to validate it, and the data will be invalid as far as the client is concerned. 5. A security-aware and validating DNS64 resolver receives a query - with the DO bit clear and CD clear. In this case, the resolver - validates the data. If it fails, it returns RCODE 2 (Server - failure); otherwise, it returns the answer. This is the ideal - case for vDNS64. The resolver validates the data, and then + with the DO bit clear and the CD bit clear. In this case, the + resolver validates the data. If it fails, it returns RCODE 2 + (Server failure); otherwise, it returns the answer. This is the + ideal case for vDNS64. The resolver validates the data, and then synthesizes the new record and passes that to the client. The client, which is presumably not validating (else it should have set DO and CD), cannot tell that DNS64 is involved. 6. A security-aware and validating DNS64 resolver receives a query - with the DO bit set and CD clear. This works like the previous - case, except that the resolver should also set the "Authentic - Data" (AD) bit on the response. - - 7. A security-aware and validating DNS64 resolver receives a query - with the DO bit set and CD set. This is effectively the same as - the case where a security-aware and non-validating recursive - resolver receives a similar query, and the same thing will - happen: the downstream validator will mark the data as invalid if - DNS64 has performed synthesis. The node needs to do DNS64 - itself, or else communication will fail. + with the DO bit set and the CD bit clear. This works like the + previous case, except that the resolver should also set the + "Authentic Data" (AD) bit on the response. -Bagnulo, et al. Expires April 4, 2011 [Page 9] +Bagnulo, et al. Standards Track [Page 8] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 + 7. A security-aware and validating DNS64 resolver receives a query + with the DO bit set and the CD bit set. This is effectively the + same as the case where a security-aware and non-validating + recursive resolver receives a similar query, and the same thing + will happen: the downstream validator will mark the data as + invalid if DNS64 has performed synthesis. The node needs to do + DNS64 itself, or else communication will fail. + 4. Terminology This section provides definitions for the special terms used in the @@ -517,14 +472,14 @@ Internet-Draft DNS64 October 2010 Authoritative server: A DNS server that can answer authoritatively a given DNS request. - DNS64: A logical function that synthesizes DNS resource records (e.g - AAAA records containing IPv6 addresses) from DNS resource records - actually contained in the DNS (e.g., A records containing IPv4 - addresses). + DNS64: A logical function that synthesizes DNS resource records + (e.g., AAAA records containing IPv6 addresses) from DNS resource + records actually contained in the DNS (e.g., A records containing + IPv4 addresses). DNS64 recursive resolver: A recursive resolver that provides the DNS64 functionality as part of its operation. This is the same - thing as "DNS64 in recursive resolver mode". + thing as "DNS64 in recursive-resolver mode". DNS64 resolver: Any resolver (stub resolver or recursive resolver) that provides the DNS64 function. @@ -533,14 +488,26 @@ Internet-Draft DNS64 October 2010 includes the server portion of a recursive resolver when it is providing the DNS64 function. - IPv4-only server: Servers running IPv4-only applications, servers + IPv4-only server: Servers running IPv4-only applications and servers that can only use IPv4, as well as cases where only IPv4 connectivity is available to the server. - IPv6-only hosts: Hosts running IPv6-only applications, hosts that + IPv6-only hosts: Hosts running IPv6-only applications and hosts that can only use IPv6, as well as cases where only IPv6 connectivity is available to the client. + + + + + + + +Bagnulo, et al. Standards Track [Page 9] + +RFC 6147 DNS64 April 2011 + + Recursive resolver: A DNS server that accepts requests from one resolver, and asks another server (of some description) for the answer on behalf of the first resolver. Full discussion of DNS @@ -552,30 +519,20 @@ Internet-Draft DNS64 October 2010 synthesized from other RRs in the same zone. An example is a synthetic AAAA record created from an A record. - - - - -Bagnulo, et al. Expires April 4, 2011 [Page 10] - -Internet-Draft DNS64 October 2010 - - IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 - packets and vice-versa. It is only required that the + packets and vice versa. It is only required that the communication initiated from the IPv6 side be supported. For a detailed understanding of this document, the reader should also - be familiar with DNS terminology from [RFC1034], [RFC1035] and - current NAT terminology from [RFC4787]. Some parts of this document - assume familiarity with the terminology of the DNS security + be familiar with DNS terminology from [RFC1034] and [RFC1035] and + with current NAT terminology from [RFC4787]. Some parts of this + document assume familiarity with the terminology of the DNS security extensions outlined in [RFC4035]. It is worth emphasizing that while DNS64 is a logical function separate from the DNS, it is nevertheless closely associated with that protocol. It depends on the DNS protocol, and some behavior of DNS64 will interact with regular DNS responses. - 5. DNS64 Normative Specification DNS64 is a logical function that synthesizes AAAA records from A @@ -583,23 +540,31 @@ Internet-Draft DNS64 October 2010 in a recursive resolver, or in an authoritative name server. It works within those DNS functions, and appears on the network as though it were a "plain" DNS resolver or name server conforming to - [RFC1034], and [RFC1035]. + [RFC1034] and [RFC1035]. The implementation SHOULD support mapping of separate IPv4 address ranges to separate IPv6 prefixes for AAAA record synthesis. This allows handling of special use IPv4 addresses [RFC5735]. DNS messages contain several sections. The portion of a DNS message - that is altered by DNS64 is the Answer section, which is discussed - below in section Section 5.1. The resulting synthetic answer is put - together with other sections, and that creates the message that is - actually returned as the response to the DNS query. Assembling that - response is covered below in section Section 5.4. + that is altered by DNS64 is the answer section, which is discussed + below in Section 5.1. The resulting synthetic answer is put together + with other sections, and that creates the message that is actually + returned as the response to the DNS query. Assembling that response + is covered below in Section 5.4. DNS64 also responds to PTR queries involving addresses containing any of the IPv6 prefixes it uses for synthesis of AAAA RRs. -5.1. Resolving AAAA queries and the answer section + + + +Bagnulo, et al. Standards Track [Page 10] + +RFC 6147 DNS64 April 2011 + + +5.1. Resolving AAAA Queries and the Answer Section When the DNS64 receives a query for RRs of type AAAA and class IN, it first attempts to retrieve non-synthetic RRs of this type and class, @@ -609,45 +574,36 @@ Internet-Draft DNS64 October 2010 other than IN is undefined, and a DNS64 MUST behave as though no DNS64 function is configured. - - - -Bagnulo, et al. Expires April 4, 2011 [Page 11] - -Internet-Draft DNS64 October 2010 - - -5.1.1. The answer when there is AAAA data available +5.1.1. The Answer when There is AAAA Data Available If the query results in one or more AAAA records in the answer section, the result is returned to the requesting client as per normal DNS semantics, except in the case where any of the AAAA - records match a special exclusion set of prefixes, considered in + records match a special exclusion set of prefixes, as considered in Section 5.1.4. If there is (non-excluded) AAAA data available, DNS64 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A for an analysis of the motivations for and the implications of not - complying with this recommendation). By default DNS64 + complying with this recommendation). By default, DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs exist. -5.1.2. The answer when there is an error - - If the query results in a response with RCODE other than 0 (No error - condition), then there are two possibilities. A result with RCODE=3 - (Name Error) is handled according to normal DNS operation (which is - normally to return the error to the client). This stage is still - prior to any synthesis having happened, so a response to be returned - to the client does not need any special assembly than would usually - happen in DNS operation. - - Any other RCODE is treated as though the RCODE were 0 (see sections - Section 5.1.6 and Section 5.1.7) and the answer section were empty. - This is because of the large number of different responses from - deployed name servers when they receive AAAA queries without a AAAA - record being available (see [RFC4074]). Note that this means, for - practical purposes, that several different classes of error in the - DNS are all treated as though a AAAA record is not available for that - owner name. +5.1.2. The Answer when There is an Error + + If the query results in a response with an RCODE other than 0 (No + error condition), then there are two possibilities. A result with + RCODE=3 (Name Error) is handled according to normal DNS operation + (which is normally to return the error to the client). This stage is + still prior to any synthesis having happened, so a response to be + returned to the client does not need any special assembly other than + what would usually happen in DNS operation. + + Any other RCODE is treated as though the RCODE were 0 (see + Sections 5.1.6 and 5.1.7) and the answer section were empty. This is + because of the large number of different responses from deployed name + servers when they receive AAAA queries without a AAAA record being + available (see [RFC4074]). Note that this means, for practical + purposes, that several different classes of error in the DNS are all + treated as though a AAAA record is not available for that owner name. It is important to note that, as of this writing, some servers respond with RCODE=3 to a AAAA query even if there is an A record @@ -655,32 +611,30 @@ Internet-Draft DNS64 October 2010 of the meaning of RCODE 3, and it is expected that they will decline in use as IPv6 deployment increases. -5.1.3. Dealing with timeouts - - If the query receives no answer before the timeout (which might be - the timeout from every authoritative server, depending on whether the - DNS64 is in recursive resolver mode), it is treated as RCODE=2 - (Server failure). - +Bagnulo, et al. Standards Track [Page 11] + +RFC 6147 DNS64 April 2011 -Bagnulo, et al. Expires April 4, 2011 [Page 12] - -Internet-Draft DNS64 October 2010 +5.1.3. Dealing with Timeouts + If the query receives no answer before the timeout (which might be + the timeout from every authoritative server, depending on whether the + DNS64 is in recursive-resolver mode), it is treated as RCODE=2 + (Server failure). -5.1.4. Special exclusion set for AAAA records +5.1.4. Special Exclusion Set for AAAA Records Some IPv6 addresses are not actually usable by IPv6-only hosts. If they are returned to IPv6-only querying agents as AAAA records, therefore, the goal of decreasing the number of failure modes will not be attained. Examples include AAAA records with addresses in the ::ffff:0:0/96 network, and possibly (depending on the context) AAAA - records with the site's Pref::64/n or the Well-Known Prefix (see + records with the site's Pref64::/n or the Well-Known Prefix (see below for more about the Well-Known Prefix). A DNS64 implementation SHOULD provide a mechanism to specify IPv6 prefix ranges to be treated as though the AAAA containing them were an empty answer. An @@ -694,10 +648,10 @@ Internet-Draft DNS64 October 2010 range(s), then it MUST treat the answer as though it were an empty answer, and proceed accordingly. If it receives an answer with at least one AAAA record containing an address outside any of the - excluded range(s), then it MAY build an answer section for a response - including only the AAAA record(s) that do not contain any of the - addresses inside the excluded ranges. That answer section is used in - the assembly of a response as detailed in Section 5.4. + excluded range(s), then it by default SHOULD build an answer section + for a response including only the AAAA record(s) that do not contain + any of the addresses inside the excluded ranges. That answer section + is used in the assembly of a response as detailed in Section 5.4. Alternatively, it MAY treat the answer as though it were an empty answer, and proceed accordingly. It MUST NOT return the offending AAAA records as part of a response. @@ -715,20 +669,19 @@ Internet-Draft DNS64 October 2010 are included as part of the answer along with the synthetic AAAA (if appropriate). -5.1.6. Data for the answer when performing synthesis - - If the query results in no error but an empty answer section in the - response, the DNS64 attempts to retrieve A records for the name in - question, either by performing another query or, in the case of an - authoritative server, by examining its own results. If this new A RR - -Bagnulo, et al. Expires April 4, 2011 [Page 13] +Bagnulo, et al. Standards Track [Page 12] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 + +5.1.6. Data for the Answer when Performing Synthesis + If the query results in no error but an empty answer section in the + response, the DNS64 attempts to retrieve A records for the name in + question, either by performing another query or, in the case of an + authoritative server, by examining its own results. If this new A RR query results in an empty answer or in an error, then the empty result or error is used as the basis for the answer returned to the querying client. If instead the query results in one or more A RRs, @@ -737,7 +690,7 @@ Internet-Draft DNS64 October 2010 synthesized AAAA records in the answer section, removing the A records that form the basis of the synthesis. -5.1.7. Performing the synthesis +5.1.7. Performing the Synthesis A synthetic AAAA record is created from an A record as follows: @@ -748,18 +701,18 @@ Internet-Draft DNS64 October 2010 o The CLASS field is set to the original CLASS field, 1. Under this specification, DNS64 for any CLASS other than 1 is undefined. - o The TTL field is set to the minimum of the TTL of the original A - RR and the SOA RR for the queried domain. (Note that in order to - obtain the TTL of the SOA RR, the DNS64 does not need to perform a - new query, but it can remember the TTL from the SOA RR in the - negative response to the AAAA query. If the SOA RR was not - delivered with the negative response to the AAAA query, then the - DNS64 SHOULD use a the minimum of the TTL of the original A RR and - 600 seconds. It is possible instead to query explicitly for the - SOA RR and use the result of that query, but this will increase - query load and time to resolution for little additional benefit.) - This is in keeping with the approach used in negative caching - ([RFC2308]. + o The Time to Live (TTL) field is set to the minimum of the TTL of + the original A RR and the SOA RR for the queried domain. (Note + that in order to obtain the TTL of the SOA RR, the DNS64 does not + need to perform a new query, but it can remember the TTL from the + SOA RR in the negative response to the AAAA query. If the SOA RR + was not delivered with the negative response to the AAAA query, + then the DNS64 SHOULD use the TTL of the original A RR or + 600 seconds, whichever is shorter. It is possible instead to + query explicitly for the SOA RR and use the result of that query, + but this will increase query load and time to resolution for + little additional benefit.) This is in keeping with the approach + used in negative caching [RFC2308]. o The RDLENGTH field is set to 16. @@ -770,93 +723,89 @@ Internet-Draft DNS64 October 2010 See Section 5.2 for discussion of the algorithms to be used in effecting the transformation. -5.1.8. Querying in parallel - - The DNS64 MAY perform the query for the AAAA RR and for the A RR in - parallel, in order to minimize the delay. - Note: Querying in parallel will result in performing unnecessary A RR - queries in the case where no AAAA RR synthesis is required. A -Bagnulo, et al. Expires April 4, 2011 [Page 14] +Bagnulo, et al. Standards Track [Page 13] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 - possible trade-off would be to perform them sequentially but with a - very short interval between them, so if we obtain a fast reply, we - avoid doing the additional query. (Note that this discussion is - relevant only if the DNS64 function needs to perform external queries - t fetch the RR. If the needed RR information is available locally, - as in the case of an authoritative server, the issue is no longer - relevant.) +5.1.8. Querying in Parallel -5.2. Generation of the IPv6 representations of IPv4 addresses + The DNS64 MAY perform the query for the AAAA RR and for the A RR in + parallel, in order to minimize the delay. + + NOTE: Querying in parallel will result in performing unnecessary A + RR queries in the case where no AAAA RR synthesis is required. A + possible trade-off would be to perform them sequentially but with + a very short interval between them, so if we obtain a fast reply, + we avoid doing the additional query. (Note that this discussion + is relevant only if the DNS64 function needs to perform external + queries to fetch the RR. If the needed RR information is + available locally, as in the case of an authoritative server, the + issue is no longer relevant.) + +5.2. Generation of the IPv6 Representations of IPv4 Addresses DNS64 supports multiple algorithms for the generation of the IPv6 representation of an IPv4 address. The constraints imposed on the generation algorithms are the following: - The same algorithm to create an IPv6 address from an IPv4 address + o The same algorithm to create an IPv6 address from an IPv4 address MUST be used by both a DNS64 to create the IPv6 address to be returned in the synthetic AAAA RR from the IPv4 address contained - in an original A RR, and by a IPv6/IPv4 translator to create the + in an original A RR, and by an IPv6/IPv4 translator to create the IPv6 address to be included in the source address field of the outgoing IPv6 packets from the IPv4 address included in the source address field of the incoming IPv4 packet. - The algorithm MUST be reversible; i.e., it MUST be possible to + o The algorithm MUST be reversible; i.e., it MUST be possible to derive the original IPv4 address from the IPv6 representation. - The input for the algorithm MUST be limited to the IPv4 address, + o The input for the algorithm MUST be limited to the IPv4 address; the IPv6 prefix (denoted Pref64::/n) used in the IPv6 - representations and optionally a set of stable parameters that are - configured in the DNS64 and in the NAT64 (such as fixed string to - be used as a suffix). + representations; and, optionally, a set of stable parameters that + are configured in the DNS64 and in the NAT64 (such as a fixed + string to be used as a suffix). - For each prefix Pref64::/n, n MUST be less than or equal to 96. + * For each prefix Pref64::/n, n MUST be less than or equal to 96. If one or more Pref64::/n are configured in the DNS64 through - any means (such as manually configured, or other automatic + any means (such as manual configuration, or other automatic means not specified in this document), the default algorithm MUST use these prefixes (and not use the Well-Known Prefix). - If no prefix is available, the algorithm MUST use the Well- - Known Prefix 64:FF9B::/96 defined in - [I-D.ietf-behave-address-format] to represent the IPv4 unicast - address range + If no prefix is available, the algorithm MUST use the + Well-Known Prefix 64:ff9b::/96 defined in [RFC6052] to + represent the IPv4 unicast address range. - [[anchor6: Note in document: The value 64:FF9B::/96 is proposed as - the value for the Well-Known prefix and needs to be confirmed - whenis published as RFC.]][I-D.ietf-behave-address-format] - A DNS64 MUST support the algorithm for generating IPv6 - representations of IPv4 addresses defined in Section 2 of - [I-D.ietf-behave-address-format]. Moreover, the aforementioned -Bagnulo, et al. Expires April 4, 2011 [Page 15] +Bagnulo, et al. Standards Track [Page 14] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 - algorithm MUST be the default algorithm used by the DNS64. While the - normative description of the algorithm is provided in - [I-D.ietf-behave-address-format], a sample description of the - algorithm and its application to different scenarios is provided in - Section 7 for illustration purposes. + A DNS64 MUST support the algorithm for generating IPv6 + representations of IPv4 addresses defined in Section 2 of [RFC6052]. + Moreover, the aforementioned algorithm MUST be the default algorithm + used by the DNS64. While the normative description of the algorithm + is provided in [RFC6052], a sample description of the algorithm and + its application to different scenarios are provided in Section 7 for + illustration purposes. -5.3. Handling other Resource Records and the Additional Section +5.3. Handling Other Resource Records and the Additional Section 5.3.1. PTR Resource Record If a DNS64 server receives a PTR query for a record in the IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the address portion of the QNAME according to the encoding scheme - outlined in section 2.5 of [RFC3596], and examine the resulting - address to see whether its prefix matches any of the locally- - configured Pref64::/n or the default Well-known prefix. There are + outlined in Section 2.5 of [RFC3596], and examine the resulting + address to see whether its prefix matches any of the locally + configured Pref64::/n or the default Well-Known Prefix. There are two alternatives for a DNS64 server to respond to such PTR queries. A DNS64 server MUST provide one of these, and SHOULD NOT provide both at the same time unless different IP6.ARPA zones require answers of @@ -865,51 +814,53 @@ Internet-Draft DNS64 October 2010 1. The first option is for the DNS64 server to respond authoritatively for its prefixes. If the address prefix matches any Pref64::/n used in the site, either a NSP or the Well-Known - Prefix (i.e. 64:FF9B::/96), then the DNS64 server MAY answer the - query using locally-appropriate RDATA. The DNS64 server MAY use + Prefix (i.e., 64:ff9b::/96), then the DNS64 server MAY answer the + query using locally appropriate RDATA. The DNS64 server MAY use the same RDATA for all answers. Note that the requirement is to - match any Pref64::/n used at the site, and not merely the - locally-configured Pref64::/n. This is because end clients could - ask for a PTR record matching an address received through a - different (site-provided) DNS64, and if this strategy is in - effect, those queries should never be sent to the global DNS. - The advantage of this strategy is that it makes plain to the - querying client that the prefix is one operated by the (DNS64) - site, and that the answers the client is getting are generated by - DNS64. The disadvantage is that any useful reverse-tree - information that might be in the global DNS is unavailable to the - clients querying the DNS64. - - 2. The second option is for the DNS64 nameserver to synthesize a - CNAME mapping the IP6.ARPA namespace to the corresponding IN- - ADDR.ARPA name. In this case, the DNS64 nameserver SHOULD ensure - that there is RDATA at the PTR of the corresponding IN-ADDR.ARPA - name, and that there is not an existing CNAME at that name. This - is in order to avoid synthesizing a CNAME that makes a CNAME - chain longer or that does not actually point to anything. The - rest of the response would be the normal DNS processing. The - CNAME can be signed on the fly if need be. The advantage of this - - - -Bagnulo, et al. Expires April 4, 2011 [Page 16] + match any Pref64::/n used at the site, and not merely the locally + configured Pref64::/n. This is because end clients could ask for + a PTR record matching an address received through a different + (site-provided) DNS64, and if this strategy is in effect, those + queries should never be sent to the global DNS. The advantage of + this strategy is that it makes plain to the querying client that + the prefix is one operated by the (DNS64) site, and that the + answers the client is getting are generated by DNS64. The + disadvantage is that any useful reverse-tree information that + might be in the global DNS is unavailable to the clients querying + the DNS64. + + 2. The second option is for the DNS64 name server to synthesize a + CNAME mapping the IP6.ARPA namespace to the corresponding + IN-ADDR.ARPA name. In this case, the DNS64 name server SHOULD + ensure that there is RDATA at the PTR of the corresponding + IN-ADDR.ARPA name, and that there is not an existing CNAME at + that name. This is in order to avoid synthesizing a CNAME that + makes a CNAME chain longer or that does not actually point to + + + +Bagnulo, et al. Standards Track [Page 15] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 - approach is that any useful information in the reverse tree is - available to the querying client. The disadvantage is that it - adds additional load to the DNS64 (because CNAMEs have to be - synthesized for each PTR query that matches the Pref64::/n), and - that it may require signing on the fly. + anything. The rest of the response would be the normal DNS + processing. The CNAME can be signed on the fly if need be. The + advantage of this approach is that any useful information in the + reverse tree is available to the querying client. The + disadvantages are that it adds additional load to the DNS64 + (because CNAMEs have to be synthesized for each PTR query that + matches the Pref64::/n), and that it may require signing on + the fly. If the address prefix does not match any Pref64::/n, then the DNS64 - server MUST process the query as though it were any other query; i.e. - a recursive nameserver MUST attempt to resolve the query as though it - were any other (non-A/AAAA) query, and an authoritative server MUST - respond authoritatively or with a referral, as appropriate. + server MUST process the query as though it were any other query; + i.e., a recursive name server MUST attempt to resolve the query as + though it were any other (non-A/AAAA) query, and an authoritative + server MUST respond authoritatively or with a referral, as + appropriate. -5.3.2. Handling the additional section +5.3.2. Handling the Additional Section DNS64 synthesis MUST NOT be performed on any records in the additional section of synthesized answers. The DNS64 MUST pass the @@ -917,43 +868,47 @@ Internet-Draft DNS64 October 2010 NOTE: It may appear that adding synthetic records to the additional section is desirable, because clients sometimes use the - data in the additional section to proceed without having to re- - query. There is in general no promise, however, that the + data in the additional section to proceed without having to + re-query. There is in general no promise, however, that the additional section will contain all the relevant records, so any client that depends on the additional section being able to - satisfy its needs (i.e. without additional queries) is necessarily - broken. An IPv6-only client that needs a AAAA record, therefore, - will send a query for the necessary AAAA record if it is unable to - find such a record in the additional section of an answer it is - consuming. For a correctly-functioning client, the effect would - be no different if the additional section were empty.The - alternative, of removing the A records in the additional section - and replacing them with synthetic AAAA records, may cause a host - behind a NAT64 to query directly a nameserver that is unaware of - the NAT64 in question. The result in this case will be resolution - failure anyway, only later in the resolution operation. The - prohibition on synthetic data in the additional section reduces, - but does not eliminate, the possibility of resolution failures due - to cached DNS data from behind the DNS64. See Section 6. + satisfy its needs (i.e., without additional queries) is + necessarily broken. An IPv6-only client that needs a AAAA record, + therefore, will send a query for the necessary AAAA record if it + is unable to find such a record in the additional section of an + answer it is consuming. For a correctly functioning client, the + effect would be no different if the additional section were empty. + The alternative of removing the A records in the additional + section and replacing them with synthetic AAAA records may cause a + host behind a NAT64 to query directly a name server that is + unaware of the NAT64 in question. The result in this case will be + resolution failure anyway, but later in the resolution operation. + The prohibition on synthetic data in the additional section + reduces, but does not eliminate, the possibility of resolution + failures due to cached DNS data from behind the DNS64. See + Section 6. -5.3.3. Other Resource Records - If the DNS64 is in recursive resolver mode, then considerations - outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant. - All other RRs MUST be returned unchanged. This includes responses to - queries for A RRs. -Bagnulo, et al. Expires April 4, 2011 [Page 17] +Bagnulo, et al. Standards Track [Page 16] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 -5.4. Assembling a synthesized response to a AAAA query +5.3.3. Other Resource Records + + If the DNS64 is in recursive-resolver mode, then considerations + outlined in [DEFAULT-LOCAL-ZONES] may be relevant. + + All other RRs MUST be returned unchanged. This includes responses to + queries for A RRs. + +5.4. Assembling a Synthesized Response to a AAAA Query A DNS64 uses different pieces of data to build the response returned to the querying client. @@ -976,12 +931,12 @@ Internet-Draft DNS64 October 2010 The final response from the DNS64 is subject to all the standard DNS rules, including truncation [RFC1035] and EDNS0 handling [RFC2671]. -5.5. DNSSEC processing: DNS64 in validating resolver mode +5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode We consider the case where a recursive resolver that is performing DNS64 also has a local policy to validate the answers according to - the procedures outlined in [RFC4035] Section 5. We call this general - case vDNS64. + the procedures outlined in [RFC4035], Section 5. We call this + general case vDNS64. The vDNS64 uses the presence of the DO and CD bits to make some decisions about what the query originator needs, and can react @@ -992,6 +947,15 @@ Internet-Draft DNS64 October 2010 rules about how to do validation and synthesis. In this case, however, vDNS64 MUST NOT set the AD bit in any response. + + + + +Bagnulo, et al. Standards Track [Page 17] + +RFC 6147 DNS64 April 2011 + + 2. If CD is not set and DO is set, then vDNS64 SHOULD perform validation. Whenever vDNS64 performs validation, it MUST validate the negative answer for AAAA queries before proceeding @@ -1001,88 +965,87 @@ Internet-Draft DNS64 October 2010 as a mechanism to circumvent DNSSEC. If the negative response validates, and the response to the A query validates, then the vDNS64 MAY perform synthesis and SHOULD set the AD bit in the - - - -Bagnulo, et al. Expires April 4, 2011 [Page 18] - -Internet-Draft DNS64 October 2010 - - answer to the client. This is acceptable, because [RFC4035], - section 3.2.3 says that the AD bit is set by the name server side + Section 3.2.3 says that the AD bit is set by the name server side of a security-aware recursive name server if and only if it - considers all the RRSets in the Answer and Authority sections to + considers all the RRSets in the answer and authority sections to be authentic. In this case, the name server has reason to believe the RRSets are all authentic, so it SHOULD set the AD bit. If the data does not validate, the vDNS64 MUST respond with RCODE=2 (Server failure). + A security-aware end point might take the presence of the AD bit as an indication that the data is valid, and may pass the DNS (and DNSSEC) data to an application. If the application attempts to validate the synthesized data, of course, the validation will fail. One could argue therefore that this approach is not - desirable, but security aware stub resolvers must not place any + desirable, but security-aware stub resolvers must not place any reliance on data received from resolvers and validated on their - behalf without certain criteria established by [RFC4035], section - 4.9.3. An application that wants to perform validation on its - own should use the CD bit. + behalf without certain criteria established by [RFC4035], + Section 4.9.3. An application that wants to perform validation + on its own should use the CD bit. 3. If the CD bit is set and DO is set, then vDNS64 MAY perform validation, but MUST NOT perform synthesis. It MUST return the data to the query initiator, just like a regular recursive resolver, and depend on the client to do the validation and the synthesis itself. + The disadvantage to this approach is that an end point that is translation-oblivious but security-aware and validating will not be able to use the DNS64 functionality. In this case, the end point will not have the desired benefit of NAT64. In effect, this strategy means that any end point that wishes to do - validation in a NAT64 context must be upgraded to be translation- - aware as well. + validation in a NAT64 context must be upgraded to be + translation-aware as well. + + -6. Deployment notes + + + + + +Bagnulo, et al. Standards Track [Page 18] + +RFC 6147 DNS64 April 2011 + + +6. Deployment Notes While DNS64 is intended to be part of a strategy for aiding IPv6 deployment in an internetworking environment with some IPv4-only and - IPv6-only networks, it is important to realise that it is + IPv6-only networks, it is important to realize that it is incompatible with some things that may be deployed in an IPv4-only or dual-stack context. -6.1. DNS resolvers and DNS64 +6.1. DNS Resolvers and DNS64 Full-service resolvers that are unaware of the DNS64 function can be (mis)configured to act as mixed-mode iterative and forwarding resolvers. In a native IPv4 context, this sort of configuration may appear to work. It is impossible to make it work properly without it being aware of the DNS64 function, because it will likely at some - - - -Bagnulo, et al. Expires April 4, 2011 [Page 19] - -Internet-Draft DNS64 October 2010 - - point obtain IPv4-only glue records and attempt to use them for resolution. The result that is returned will contain only A records, and without the ability to perform the DNS64 function the resolver will be unable to answer the necessary AAAA queries. -6.2. DNSSEC validators and DNS64 +6.2. DNSSEC Validators and DNS64 - An existing DNSSEC validator (i.e. that is unaware of DNS64) might - reject all the data that comes from DNS64 as having been tampered - with (even if it did not set CD when querying). If it is necessary - to have validation behind the DNS64, then the validator must know how - to perform the DNS64 function itself. Alternatively, the validating - host may establish a trusted connection with a DNS64, and allow the - DNS64 recursive resolver to do all validation on its behalf. + An existing DNSSEC validator (i.e., one that is unaware of DNS64) + might reject all the data that comes from DNS64 as having been + tampered with (even if it did not set CD when querying). If it is + necessary to have validation behind the DNS64, then the validator + must know how to perform the DNS64 function itself. Alternatively, + the validating host may establish a trusted connection with a DNS64, + and allow the DNS64 recursive resolver to do all validation on its + behalf. -6.3. DNS64 and multihomed and dual-stack hosts +6.3. DNS64 and Multihomed and Dual-Stack Hosts -6.3.1. IPv6 multihomed hosts +6.3.1. IPv6 Multihomed Hosts Synthetic AAAA records may be constructed on the basis of the network context in which they were constructed. If a host sends DNS queries @@ -1095,6 +1058,16 @@ Internet-Draft DNS64 October 2010 address contained in that AAAA answer will not connect with anything via i2. + + + + + +Bagnulo, et al. Standards Track [Page 19] + +RFC 6147 DNS64 April 2011 + + +---------------+ +-------------+ | i1 (IPv6)+----NAT64--------+IPv4 Internet| | | +-------------+ @@ -1103,7 +1076,7 @@ Internet-Draft DNS64 October 2010 | i2 (IPv6)+-----------------+IPv6 Internet| +---------------+ +-------------+ - Figure 1: IPv6 multihomed hosts + Figure 1: IPv6 Multihomed Hosts This example illustrates why it is generally preferable that hosts treat DNS answers from one interface as local to that interface. The @@ -1113,23 +1086,15 @@ Internet-Draft DNS64 October 2010 Note that the issue is not that there are two interfaces, but that there are two networks involved. The same results could be achieved - - - -Bagnulo, et al. Expires April 4, 2011 [Page 20] - -Internet-Draft DNS64 October 2010 - - with a single interface routed to two different networks. -6.3.2. Accidental dual-stack DNS64 use +6.3.2. Accidental Dual-Stack DNS64 Use Similarly, suppose that i1 has IPv6 connectivity and can connect to the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity. In this case, i1 could receive an IPv6 address from a synthetic AAAA that would better be reached via native IPv4. Again, it is worth - emphasising that this arises because there are two networks involved. + emphasizing that this arises because there are two networks involved. +---------------+ +-------------+ | i1 (IPv6)+----NAT64--------+IPv4 Internet| @@ -1139,14 +1104,26 @@ Internet-Draft DNS64 October 2010 | i2 (IPv4)+-----------------+IPv4 Internet| +---------------+ +-------------+ - Figure 2: Accidental dual-stack DNS64 use + Figure 2: Accidental Dual-Stack DNS64 Use The default configuration of dual-stack hosts is that IPv6 is - preferred over IPv4 ([RFC3484]). In that arrangement the host will + preferred over IPv4 ([RFC3484]). In that arrangement, the host will often use the NAT64 when native IPv4 would be more desirable. For this reason, hosts with IPv4 connectivity to the Internet should avoid using DNS64. This can be partly resolved by ISPs when providing DNS resolvers to clients, but that is not a guarantee that + + + + + + + +Bagnulo, et al. Standards Track [Page 20] + +RFC 6147 DNS64 April 2011 + + the NAT64 will never be used when a native IPv4 connection should be used. There is no general-purpose mechanism to ensure that native IPv4 transit will always be preferred, because to a DNS64-oblivious @@ -1154,7 +1131,7 @@ Internet-Draft DNS64 October 2010 a NAT64 should expect traffic to pass through the NAT64 even when it is not necessary. -6.3.3. Intentional dual-stack DNS64 use +6.3.3. Intentional Dual-Stack DNS64 Use Finally, consider the case where the IPv4 connectivity on i2 is only with a LAN, and not with the IPv4 Internet. The IPv4 Internet is @@ -1167,16 +1144,6 @@ Internet-Draft DNS64 October 2010 failures to occur because nodes accessible from one context are not accessible from the other. - - - - - -Bagnulo, et al. Expires April 4, 2011 [Page 21] - -Internet-Draft DNS64 October 2010 - - +---------------+ +-------------+ | i1 (IPv6)+----NAT64--------+IPv4 Internet| | | +-------------+ @@ -1185,9 +1152,9 @@ Internet-Draft DNS64 October 2010 | i2 (IPv4)+---(local LAN only) +---------------+ - Figure 3: Intentional dual-stack DNS64 use + Figure 3: Intentional Dual-Stack DNS64 Use - It is important for deployers of DNS64 to realise that, in some + It is important for deployers of DNS64 to realize that, in some circumstances, making the DNS64 available to a dual-stack host will cause the host to prefer to send packets via NAT64 instead of via native IPv4, with the associated loss of performance or functionality @@ -1195,43 +1162,40 @@ Internet-Draft DNS64 October 2010 able to learn about DNS servers provisioned on IPv6 addresses, or simply cannot send DNS packets over IPv6. +7. Deployment Scenarios and Examples -7. Deployment scenarios and examples - - In this section we illustrate how the DNS64 behaves in different - scenarios that are expected to be common. In particular we will - consider the following scenarios defined in - [I-D.ietf-behave-v6v4-framework]: the an-IPv6-network-to-IPv4- - Internet scenario (both with DNS64 in DNS server mode and in stub- - resolver mode) and the IPv6-Internet-to-an-IPv4-network setup (with - DNS64 in DNS server mode only). - - In all the examples below, there is a IPv6/IPv4 translator connecting - the IPv6 domain to the IPv4 one. Also there is a name server that is - a dual-stack node, so it can communicate with IPv6 hosts using IPv6 - and with IPv4 nodes using IPv4. In addition, we assume that in the - examples, the DNS64 function learns which IPv6 prefix it needs to use - to map the IPv4 address space through manual configuration. + In this section, we illustrate how the DNS64 behaves in different + scenarios that are expected to be common. In particular, we will + consider the following scenarios defined in [RFC6144]: the "an IPv6 + network to the IPv4 Internet" scenario (both with DNS64 in DNS server + mode and in stub-resolver mode) and the "IPv6 Internet to an IPv4 + network" setup (with DNS64 in DNS server mode only). -7.1. Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in - DNS server mode - - In this example, we consider an IPv6 node located in an IPv6-only - site that initiates a communication to an IPv4 node located in the - IPv4 Internet. - The scenario for this case is depicted in the following figure: +Bagnulo, et al. Standards Track [Page 21] + +RFC 6147 DNS64 April 2011 + In all the examples below, there is an IPv6/IPv4 translator + connecting the IPv6 domain to the IPv4 one. Also, there is a name + server that is a dual-stack node, so it can communicate with IPv6 + hosts using IPv6 and with IPv4 nodes using IPv4. In addition, we + assume that in the examples, the DNS64 function learns which IPv6 + prefix it needs to use to map the IPv4 address space through manual + configuration. +7.1. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 + in DNS Server Mode -Bagnulo, et al. Expires April 4, 2011 [Page 22] - -Internet-Draft DNS64 October 2010 + In this example, we consider an IPv6 node located in an IPv6-only + site that initiates a communication to an IPv4 node located in the + IPv4 Internet. + The scenario for this case is depicted in the following figure: +---------------------+ +---------------+ |IPv6 network | | IPv4 | @@ -1247,21 +1211,30 @@ Internet-Draft DNS64 October 2010 | | | | | +---------------------+ +---------------+ - Figure 4: An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS - server mode + Figure 4: "An IPv6 Network to the IPv4 Internet" Setup + with DNS64 in DNS Server Mode - The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4 + The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN h2.example.com. - The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to - its IPv4 interface and it is using the WKP 64:FF9B::/96 to create - IPv6 representations of IPv4 addresses. The same prefix is - configured in the DNS64 function in the local name server. + The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned + to its IPv4 interface, and it is using the Well-Known Prefix + 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The + same prefix is configured in the DNS64 function in the local name + server. For this example, assume the typical DNS situation where IPv6 hosts have only stub resolvers, and they are configured with the IP address of a name server that they always have to query and that performs - recursive lookups (henceforth called "the recursive nameserver"). + recursive lookups (henceforth called "the recursive name server"). + + + + +Bagnulo, et al. Standards Track [Page 22] + +RFC 6147 DNS64 April 2011 + The steps by which H1 establishes communication with H2 are: @@ -1274,35 +1247,26 @@ Internet-Draft DNS64 October 2010 there are no AAAA records for H2. 3. The recursive name server performs an A-record query for H2 and - gets back an RRset containing a single A record with the IPv4 + gets back an RRSet containing a single A record with the IPv4 address 192.0.2.1. The name server then synthesizes a AAAA record. The IPv6 address in the AAAA record contains the prefix - assigned to the IPv6/IPv4 Translator in the upper 96 bits and the - received IPv4 address in the lower 32 bits i.e. the resulting - IPv6 address is 64:FF9B::192.0.2.1. - - - - -Bagnulo, et al. Expires April 4, 2011 [Page 23] - -Internet-Draft DNS64 October 2010 - + assigned to the IPv6/IPv4 translator in the upper 96 bits and the + received IPv4 address in the lower 32 bits; i.e., the resulting + IPv6 address is 64:ff9b::192.0.2.1. 4. H1 receives the synthetic AAAA record and sends a packet towards - H2. The packet is sent to the destination address 64:FF9B:: + H2. The packet is sent to the destination address 64:ff9b:: 192.0.2.1. 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 - translator and the subsequent communication flows by means of the - IPv6/IPv4 translator mechanisms. + translator, and the subsequent communication flows by means of + the IPv6/IPv4 translator mechanisms. -7.2. An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in - stub-resolver mode +7.2. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 + in Stub-Resolver Mode This case is depicted in the following figure: - +---------------------+ +---------------+ |IPv6 network | | IPv4 | | | +--------+ | Internet | @@ -1317,34 +1281,34 @@ Internet-Draft DNS64 October 2010 | | | | | +---------------------+ +---------------+ + Figure 5: "An IPv6 Network to the IPv4 Internet" Setup + with DNS64 in Stub-Resolver Mode + + + + +Bagnulo, et al. Standards Track [Page 23] + +RFC 6147 DNS64 April 2011 - Figure 5: An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub- - resolver mode The figure shows an IPv6 node H1 implementing the DNS64 function and - an IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com. + an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN + h2.example.com. - The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to - its IPv4 interface and it is using the WKP 64:FF9B::/96 to create - IPv6 representations of IPv4 addresses. The same prefix is - configured in the DNS64 function in H1. + The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned + to its IPv4 interface, and it is using the Well-Known Prefix + 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The + same prefix is configured in the DNS64 function in H1. For this example, assume the typical DNS situation where IPv6 hosts have only stub resolvers, and they are configured with the IP address of a name server that they always have to query and that performs - recursive lookups (henceforth called "the recursive nameserver"). + recursive lookups (henceforth called "the recursive name server"). The recursive name server does not perform the DNS64 function. The steps by which H1 establishes communication with H2 are: - - - -Bagnulo, et al. Expires April 4, 2011 [Page 24] - -Internet-Draft DNS64 October 2010 - - 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending a DNS query for a AAAA record for H2 to the recursive name server. @@ -1358,73 +1322,90 @@ Internet-Draft DNS64 October 2010 DNS64 function within H1 then synthesizes a AAAA record. The IPv6 address in the AAAA record contains the prefix assigned to the IPv6/IPv4 translator in the upper 96 bits, then the received - IPv4 address i.e. the resulting IPv6 address is 64:FF9B:: - 192.0.2.1. + IPv4 address in the lower 32 bits; the resulting IPv6 address is + 64:ff9b::192.0.2.1. 4. H1 sends a packet towards H2. The packet is sent to the - destination address 64:FF9B::192.0.2.1. + destination address 64:ff9b::192.0.2.1. 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 translator and the subsequent communication flows using the IPv6/ IPv4 translator mechanisms. -7.3. Example of IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS - server mode +7.3. Example of "the IPv6 Internet to an IPv4 Network" Setup with DNS64 + in DNS Server Mode In this example, we consider an IPv6 node located in the IPv6 Internet that initiates a communication to an IPv4 node located in the IPv4 site. - In some cases, this scenario can be addressed without using any form - of DNS64 function. This is so because it is possible to assign a - fixed IPv6 address to each of the IPv4 nodes. Such an IPv6 address - would be constructed using the address transformation algorithm - defined in [I-D.ietf-behave-address-format] that takes as input the - Pref64::/96 and the IPv4 address of the IPv4 node. Note that the - IPv4 address can be a public or a private address; the latter does - not present any additional difficulty, since an NSP must be used as - Pref64::/96 (in this scenario the usage of the Well-Known prefix is - not supported as discussed in [I-D.ietf-behave-address-format]). - Once these IPv6 addresses have been assigned to represent the IPv4 - nodes in the IPv6 Internet, real AAAA RRs containing these addresses - can be published in the DNS under the site's domain. This is the - recommended approach to handle this scenario, because it does not - involve synthesizing AAAA records at the time of query. - However, there are some more dynamic scenarios, where synthesizing - AAAA RRs in this setup may be needed. In particular, when DNS Update -Bagnulo, et al. Expires April 4, 2011 [Page 25] +Bagnulo, et al. Standards Track [Page 24] -Internet-Draft DNS64 October 2010 +RFC 6147 DNS64 April 2011 + In some cases, this scenario can be addressed without using any form + of DNS64 function. This is because it is possible to assign a fixed + IPv6 address to each of the IPv4 nodes. Such an IPv6 address would + be constructed using the address transformation algorithm defined in + [RFC6052] that takes as input the Pref64::/96 and the IPv4 address of + the IPv4 node. Note that the IPv4 address can be a public or a + private address; the latter does not present any additional + difficulty, since an NSP must be used as Pref64::/96 (in this + scenario, the usage of the Well-Known Prefix is not supported as + discussed in [RFC6052]). Once these IPv6 addresses have been + assigned to represent the IPv4 nodes in the IPv6 Internet, real AAAA + RRs containing these addresses can be published in the DNS under the + site's domain. This is the recommended approach to handle this + scenario, because it does not involve synthesizing AAAA records at + the time of query. + + However, there are some more dynamic scenarios, where synthesizing + AAAA RRs in this setup may be needed. In particular, when DNS Update [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 - nodes, there are two options: One option is to modify the DNS server + nodes, there are two options. One option is to modify the DNS server that receives the dynamic DNS updates. That would normally be the authoritative server for the zone. So the authoritative zone would have normal AAAA RRs that are synthesized as dynamic updates occur. - The other option is modify all the authoritative servers to generate - synthetic AAAA records for a zone, possibly based on additional - constraints, upon the receipt of a DNS query for the AAAA RR. The - first option -- in which the AAAA is synthesized when the DNS update - message is received, and the data published in the relevant zone -- - is recommended over the second option (i.e. the synthesis upon - receipt of the AAAA DNS query). This is because it is usually easier - to solve problems of misconfiguration when the DNS responses are not - being generated dynamically. However, it may be the case where the - primary server (that receives all the updates) cannot be upgraded for - whatever reason, but where a secondary can be upgraded in order to - handle the (comparatively small amount) of AAAA queries. In such - case, it is possible to use the DNS64 as described next. The DNS64 - behavior that we describe in this section covers the case of - synthesizing the AAAA RR when the DNS query arrives. + The other option is to modify all of the authoritative servers to + generate synthetic AAAA records for a zone, possibly based on + additional constraints, upon the receipt of a DNS query for the AAAA + RR. The first option -- in which the AAAA is synthesized when the + DNS update message is received, and the data published in the + relevant zone -- is recommended over the second option (i.e., the + synthesis upon receipt of the AAAA DNS query). This is because it is + usually easier to solve problems of misconfiguration when the DNS + responses are not being generated dynamically. However, it may be + the case where the primary server (that receives all the updates) + cannot be upgraded for whatever reason, but where a secondary can be + upgraded in order to handle the (comparatively small amount of) AAAA + queries. In such a case, it is possible to use the DNS64 as + described next. The DNS64 behavior that we describe in this section + covers the case of synthesizing the AAAA RR when the DNS query + arrives. + + + - The scenario for this case is depicted in the following figure: + + + + + + +Bagnulo, et al. Standards Track [Page 25] + +RFC 6147 DNS64 April 2011 + + + The scenario for this case is depicted in the following figure: + +-----------+ +----------------------+ | | | IPv4 site | | IPv6 | +------------+ | +----+ | @@ -1441,22 +1422,14 @@ Internet-Draft DNS64 October 2010 | H1 | +----------------------+ +----+ - Figure 6: IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server - mode + Figure 6: "The IPv6 Internet to an IPv4 Network" Setup + with DNS64 in DNS Server Mode - The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4 + The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN h2.example.com. - The IPv6/IPv4 Translator is using a NSP 2001:DB8::/96 to create IPv6 + The IPv6/IPv4 translator is using an NSP 2001:db8::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in - - - -Bagnulo, et al. Expires April 4, 2011 [Page 26] - -Internet-Draft DNS64 October 2010 - - the DNS64 function in the local name server. The name server that implements the DNS64 function is the authoritative name server for the local domain. @@ -1472,127 +1445,110 @@ Internet-Draft DNS64 October 2010 3. The name server verifies that h2.example.com and its A RR are among those that the local policy defines as allowed to generate - a AAAA RR from. If that is the case, the name server synthesizes - a AAAA record from the A RR and the prefix 2001:DB8::/96. The - IPv6 address in the AAAA record is 2001:DB8::192.0.2.1. + a AAAA RR. If that is the case, the name server synthesizes a + AAAA record from the A RR and the prefix 2001:db8::/96. The IPv6 + address in the AAAA record is 2001:db8::192.0.2.1. 4. H1 receives the synthetic AAAA record and sends a packet towards - H2. The packet is sent to the destination address 2001:DB8:: + H2. The packet is sent to the destination address 2001:db8:: 192.0.2.1. + + +Bagnulo, et al. Standards Track [Page 26] + +RFC 6147 DNS64 April 2011 + + 5. The packet is routed through the IPv6 Internet to the IPv6 interface of the IPv6/IPv4 translator and the communication flows using the IPv6/IPv4 translator mechanisms. - 8. Security Considerations DNS64 operates in combination with the DNS, and is therefore subject to whatever security considerations are appropriate to the DNS mode - in which the DNS64 is operating (i.e. authoritative, recursive, or - stub resolver mode). + in which the DNS64 is operating (i.e., authoritative, recursive, or + stub-resolver mode). DNS64 has the potential to interfere with the functioning of DNSSEC, because DNS64 modifies DNS answers, and DNSSEC is designed to detect - such modification and to treat modified answers as bogus. See the - discussion above in Section 3, Section 5.5, and Section 6.2. + such modifications and to treat modified answers as bogus. See the + discussion above in Sections 3, 5.5, and 6.2. Additionally, for the correct functioning of the translation services, the DNS64 and the NAT64 need to use the same Pref64. If an attacker manages to change the Pref64 used by the DNS64, the traffic generated by the host that receives the synthetic reply will be - delivered to the altered Pref64. This can result in either a DoS - attack (if resulting IPv6 addresses are not assigned to any device) - or in a flooding attack (if the resulting IPv6 addresses are assigned - to devices that do not wish to receive the traffic) or in - - - -Bagnulo, et al. Expires April 4, 2011 [Page 27] - -Internet-Draft DNS64 October 2010 - - - eavesdropping attack (in case the Pref64 is routed through the - attacker). - + delivered to the altered Pref64. This can result in either a denial- + of-service (DoS) attack (if the resulting IPv6 addresses are not + assigned to any device), a flooding attack (if the resulting IPv6 + addresses are assigned to devices that do not wish to receive the + traffic), or an eavesdropping attack (in case the Pref64 is routed + through the attacker). -9. IANA Considerations +9. Contributors - This memo makes no request of IANA. + Dave Thaler + Microsoft + dthaler@windows.microsoft.com +10. Acknowledgements -10. Contributors + This document contains the result of discussions involving many + people, including the participants of the IETF BEHAVE Working Group. + The following IETF participants made specific contributions to parts + of the text, and their help is gratefully acknowledged: Jaap + Akkerhuis, Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin, + Fred Baker, Doug Barton, Marc Blanchet, Cameron Byrne, Brian + Carpenter, Zhen Cao, Hui Deng, Francis Dupont, Patrik Faltstrom, + David Harrington, Ed Jankiewicz, Peter Koch, Suresh Krishnan, Martti + Kuparinen, Ed Lewis, Xing Li, Bill Manning, Matthijs Mekking, Hiroshi + Miyata, Simon Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, + Mark Townsley, Rick van Rein, Stig Venaas, Magnus Westerlund, Jeff + Westhead, Florian Weimer, Dan Wing, Xu Xiaohu, and Xiangsong Cui. - Dave Thaler - Microsoft - dthaler@windows.microsoft.com +Bagnulo, et al. Standards Track [Page 27] + +RFC 6147 DNS64 April 2011 -11. Acknowledgements - - This draft contains the result of discussions involving many people, - including the participants of the IETF BEHAVE Working Group. The - following IETF participants made specific contributions to parts of - the text, and their help is gratefully acknowledged: Jaap Akkerhuis, - Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, - Doug Barton, Marc Blanchet, Cameron Byrne, Brian Carpenter, Zhen Cao, - Hui Deng, Francis Dupont, Patrik Faltstrom, David Harrington, Ed - Jankiewicz, Peter Koch, Suresh Krishnan, Martti Kuparinen, Ed Lewis, - Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata, Simon - Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark Townsley, - Rick van Rein, Stig Venaas, Magnus Westerlund, Jeff Westhead, Florian - Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui. Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program. +11. References -12. References - -12.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. +11.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. - - - -Bagnulo, et al. Expires April 4, 2011 [Page 28] - -Internet-Draft DNS64 October 2010 - - [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. - [RFC4787] Audet, F. and C. Jennings, "Network Address Translation - (NAT) Behavioral Requirements for Unicast UDP", BCP 127, - RFC 4787, January 2007. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. - [I-D.ietf-behave-address-format] - Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. - Li, "IPv6 Addressing of IPv4/IPv6 Translators", - draft-ietf-behave-address-format-10 (work in progress), - August 2010. + [RFC4787] Audet, F. and C. Jennings, "Network Address Translation + (NAT) Behavioral Requirements for Unicast UDP", BCP 127, + RFC 4787, January 2007. + + [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. + Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, + October 2010. -12.2. Informative References +11.2. Informative References - [I-D.ietf-behave-v6v4-xlate-stateful] - Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful - NAT64: Network Address and Protocol Translation from IPv6 - Clients to IPv4 Servers", - draft-ietf-behave-v6v4-xlate-stateful-12 (work in - progress), July 2010. + [DEFAULT-LOCAL-ZONES] + Andrews, M., "Locally-served DNS Zones", Work in Progress, + March 2011. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", @@ -1608,6 +1564,14 @@ Internet-Draft DNS64 October 2010 "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. + + + +Bagnulo, et al. Standards Track [Page 28] + +RFC 6147 DNS64 April 2011 + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. @@ -1617,14 +1581,6 @@ Internet-Draft DNS64 October 2010 RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - - - -Bagnulo, et al. Expires April 4, 2011 [Page 29] - -Internet-Draft DNS64 October 2010 - - Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. @@ -1634,35 +1590,61 @@ Internet-Draft DNS64 October 2010 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010. - [I-D.ietf-behave-v6v4-framework] - Baker, F., Li, X., Bao, C., and K. Yin, "Framework for - IPv4/IPv6 Translation", - draft-ietf-behave-v6v4-framework-10 (work in progress), - August 2010. + [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for + IPv4/IPv6 Translation", RFC 6144, April 2011. + + [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from IPv6 + Clients to IPv4 Servers", RFC 6146, April 2011. + + + + + + + + - [I-D.ietf-dnsop-default-local-zones] - Andrews, M., "Locally-served DNS Zones", - draft-ietf-dnsop-default-local-zones-14 (work in - progress), September 2010. -Appendix A. Motivations and Implications of synthesizing AAAA Resource - Records when real AAAA Resource Records exist + + + + + + + + + + + + + + + + +Bagnulo, et al. Standards Track [Page 29] + +RFC 6147 DNS64 April 2011 + + +Appendix A. Motivations and Implications of Synthesizing AAAA Resource + Records when Real AAAA Resource Records Exist The motivation for synthesizing AAAA RRs when real AAAA RRs exist is to support the following scenario: - An IPv4-only server application (e.g. web server software) is + o An IPv4-only server application (e.g., web server software) is running on a dual-stack host. There may also be dual-stack server applications running on the same host. That host has fully - routable IPv4 and IPv6 addresses and hence the authoritative DNS - server has an A and a AAAA record. + routable IPv4 and IPv6 addresses, and hence the authoritative DNS + server has an A record and a AAAA record. - An IPv6-only client (regardless of whether the client application + o An IPv6-only client (regardless of whether the client application is IPv6-only, the client stack is IPv6-only, or it only has an IPv6 address) wants to access the above server. - The client issues a DNS query to a DNS64 resolver. + o The client issues a DNS query to a DNS64 resolver. If the DNS64 only generates a synthetic AAAA if there's no real AAAA, then the communication will fail. Even though there's a real AAAA, @@ -1673,49 +1655,91 @@ Appendix A. Motivations and Implications of synthesizing AAAA Resource The implication of including synthetic AAAA RRs when real AAAA RRs exist is that translated connectivity may be preferred over native - - - -Bagnulo, et al. Expires April 4, 2011 [Page 30] - -Internet-Draft DNS64 October 2010 - - connectivity in some cases where the DNS64 is operated in DNS server mode. - RFC3484 [RFC3484] rules use longest prefix match to select the + RFC 3484 [RFC3484] rules use "longest matching prefix" to select the preferred destination address to use. So, if the DNS64 resolver returns both the synthetic AAAA RRs and the real AAAA RRs, then if the DNS64 is operated by the same domain as the initiating host, and - a global unicast prefix (called an NSP in - [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR - is likely to be preferred. + a global unicast prefix (referred to as a Network-Specific Prefix + (NSP) in [RFC6052]) is used, then a synthetic AAAA RR is likely to be + preferred. This means that without further configuration: - In the "An IPv6 network to the IPv4 Internet" scenario, the host + o In the "an IPv6 network to the IPv4 Internet" scenario, the host will prefer translated connectivity if an NSP is used. If the - Well-Known Prefix defined in [I-D.ietf-behave-address-format] is - used, it will probably prefer native connectivity. + Well-Known Prefix defined in [RFC6052] is used, it will probably + prefer native connectivity. + + + + - In the "IPv6 Internet to an IPv4 network" scenario, it is possible + + +Bagnulo, et al. Standards Track [Page 30] + +RFC 6147 DNS64 April 2011 + + + o In the "IPv6 Internet to an IPv4 network" scenario, it is possible to bias the selection towards the real AAAA RR if the DNS64 resolver returns the real AAAA first in the DNS reply, when an NSP is used (the Well-Known Prefix usage is not supported in this - case) + case). - In the "An IPv6 network to IPv4 network" scenario, for local + o In the "an IPv6 network to an IPv4 network" scenario, for local destinations (i.e., target hosts inside the local site), it is likely that the NSP and the destination prefix are the same, so we can use the order of RR in the DNS reply to bias the selection through native connectivity. If the Well-Known Prefix is used, - the longest prefix match rule will select native connectivity. + the "longest matching prefix" rule will select native + connectivity. - The problem can be solved by properly configuring the RFC3484 + The problem can be solved by properly configuring the RFC 3484 [RFC3484] policy table. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bagnulo, et al. Standards Track [Page 31] + +RFC 6147 DNS64 April 2011 + + Authors' Addresses Marcelo Bagnulo @@ -1725,18 +1749,10 @@ Authors' Addresses Spain Phone: +34-91-6249500 - Fax: - Email: marcelo@it.uc3m.es + EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es/marcelo - - -Bagnulo, et al. Expires April 4, 2011 [Page 31] - -Internet-Draft DNS64 October 2010 - - Andrew Sullivan Shinkuro 4922 Fairmont Avenue, Suite 250 @@ -1744,7 +1760,7 @@ Internet-Draft DNS64 October 2010 USA Phone: +1 301 961 3131 - Email: ajs@shinkuro.com + EMail: ajs@shinkuro.com Philip Matthews @@ -1754,30 +1770,17 @@ Internet-Draft DNS64 October 2010 Canada Phone: +1 613-592-4343 x224 - Fax: - Email: philip_matthews@magma.ca - URI: + EMail: philip_matthews@magma.ca Iljitsch van Beijnum IMDEA Networks - Av. Universidad 30 - Leganes, Madrid 28911 + Avda. del Mar Mediterraneo, 22 + Leganes, Madrid 28918 Spain Phone: +34-91-6246245 - Email: iljitsch@muada.com - - - - - - - - - - - + EMail: iljitsch@muada.com @@ -1788,5 +1791,5 @@ Internet-Draft DNS64 October 2010 -Bagnulo, et al. Expires April 4, 2011 [Page 32] +Bagnulo, et al. Standards Track [Page 32] diff --git a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt b/doc/rfc/rfc6168.txt similarity index 63% rename from doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt rename to doc/rfc/rfc6168.txt index f64e8dd572e..eb6a25c9a21 100644 --- a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt +++ b/doc/rfc/rfc6168.txt @@ -1,41 +1,68 @@ -DNSOP W. Hardaker -Internet-Draft Sparta, Inc. -Intended status: Informational February 12, 2009 -Expires: August 16, 2009 + + + +Internet Engineering Task Force (IETF) W. Hardaker +Request for Comments: 6168 Sparta, Inc. +Category: Informational May 2011 +ISSN: 2070-1721 Requirements for Management of Name Servers for the DNS - draft-ietf-dnsop-name-server-management-reqs-02.txt -Status of this Memo +Abstract + + Management of name servers for the Domain Name System (DNS) has + traditionally been done using vendor-specific monitoring, + configuration, and control methods. Although some service monitoring + platforms can test the functionality of the DNS itself, there is not + an interoperable way to manage (monitor, control, and configure) the + internal aspects of a name server itself. + + This document discusses the requirements of a management system for + name servers and can be used as a shopping list of needed features + for such a system. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6168. - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - 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 August 16, 2009. + + + + + + + + + +Hardaker Informational [Page 1] + +RFC 6168 Name Server Management Requirements May 2011 + Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal @@ -43,39 +70,61 @@ Copyright Notice (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect - to this document. + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + -Abstract - Management of name servers for the Domain Name Service (DNS) has - traditionally been done using vendor-specific monitoring, -Hardaker Expires August 16, 2009 [Page 1] - -Internet-Draft Name Server Management Requirements February 2009 - configuration and control methods. Although some service monitoring - platforms can test the functionality of the DNS itself there is not a - interoperable way to manage (monitor, control and configure) the - internal aspects of a name server itself. - This document discusses the requirements of a management system for - DNS name servers. A management solution that is designed to manage - the DNS can use this document as a shopping list of needed features. + + + + + + + + + +Hardaker Informational [Page 2] + +RFC 6168 Name Server Management Requirements May 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 - 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 - 1.1.2. Document Layout and Requirements . . . . . . . . . . . 5 + 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Document Layout and Requirements . . . . . . . . . . . . . 5 2. Management Architecture Requirements . . . . . . . . . . . . . 5 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5 - 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5 + 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 6 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6 @@ -91,127 +140,78 @@ Table of Contents 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9 - 3.2.5. DNS Protocol Authorization Management . . . . . . . . 9 + 3.2.5. DNS Protocol Authorization Management . . . . . . . . 10 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10 - 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10 + 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11 - 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11 + 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13 - - - -Hardaker Expires August 16, 2009 [Page 2] - -Internet-Draft Name Server Management Requirements February 2009 - - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15 + 7. Document History . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 + Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 16 A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16 A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16 - A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 - - - - - - - - - - - - - - - - - - - - - + A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 17 - - - - - - - - - - - - - - - -Hardaker Expires August 16, 2009 [Page 3] +Hardaker Informational [Page 3] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 1. Introduction - Management of name servers for the Domain Name Service (DNS) - [RFC1034] [RFC1035] has traditionally been done using vendor-specific - monitoring, configuration and control methods. Although some service - monitoring platforms can test the functionality of the DNS itself - there is not a interoperable way to manage (monitor, control and - configure) the internal aspects of a name server itself. + Management of name servers for the Domain Name System (DNS) [RFC1034] + [RFC1035] has traditionally been done using vendor-specific + monitoring, configuration, and control methods. Although some + service monitoring platforms can test the functionality of the DNS + itself, there is not an interoperable way to manage (monitor, + control, and configure) the internal aspects of a name server itself. Previous standardization work within the IETF resulted in the - creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed + creation of two SNMP MIB modules [RFC1611] [RFC1612], but they failed to achieve significant implementation and deployment. The perceived - reasons behind the failure for the two MIB modules are further - documented in [RFC3197]. + reasons behind the failure for the two MIB modules are documented in + [RFC3197]. This document discusses the requirements of a management system for - DNS name servers. A management solution that is designed to manage - the DNS can use this document as a shopping list of needed features. + name servers and can be used as a shopping list of needed features + for such a system. This document only discusses requirements for + managing the name server component of a system -- not other elements + of the system itself. Specifically out of scope for this document are requirements - associated with management of stub resolvers. It is not the intent - of this document to document stub resolver requirements, although - some of the requirements listed are applicable to stub resolvers as - well. - - Also out of scope for this document is management of the host or - other components of the host upon which the name server software is - running. This document only discusses requirements for managing the - name server component of a system. + associated with the management of stub resolvers. It is not the + intent of this document to document stub resolver requirements, + although some of the requirements listed are applicable to stub + resolvers as well. The task of creating a management system for managing DNS servers is not expected to be a small one. It is likely that components of the - solution will need to be designed in parts over time and these + solution will need to be designed in parts over time; these requirements take this into consideration. In particular, Section 5.1 discusses the need for future extensibility of the base - management solution. This document is intended to be a road-map + management solution. This document is intended to be a roadmap towards a desired outcome and is not intended to define an "all-or- - nothing" system. Successful interoperable management of name servers - even in part is expected to be beneficial to network operators - compared to the entirely custom solutions that are used at the time - of this writing. + nothing" system. Successful interoperable management of name + servers, even in part, is expected to be beneficial to network + operators compared to the entirely custom solutions that are used at + the time of this writing. -1.1. Requirements notation +1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -220,12 +220,15 @@ Internet-Draft Name Server Management Requirements February 2009 -Hardaker Expires August 16, 2009 [Page 4] + + + +Hardaker Informational [Page 4] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 -1.1.1. Terminology +1.2. Terminology This document is consistent with the terminology defined in Section 2 of [RFC4033]. Additional terminology needed for this document is @@ -234,16 +237,16 @@ Internet-Draft Name Server Management Requirements February 2009 Name Server: When we are discussing servers that don't fall into a more specific type of server category defined in other documents, this document will refer to them generically as "name servers". - In particular "name servers" can be considered to be any valid + In particular, "name servers" can be considered to be any valid combination of authoritative, recursive, validating, or security- aware. The more specific name server labels will be used when this document refers only to a specific type of server. However, the term "name server", in this document, will not include stub resolvers. -1.1.2. Document Layout and Requirements +1.3. Document Layout and Requirements - The document is written so that each numbered section will contain + This document is written so that each numbered section will contain only a single requirement if it contains one at all. Each requirement will contain needed wording from the terminology described in Section 1.1. Subsections, however, might exist with @@ -252,7 +255,6 @@ Internet-Draft Name Server Management Requirements February 2009 the section number itself and the document version from which it came. - 2. Management Architecture Requirements This section discusses requirements that reflect the needs of the @@ -261,7 +263,7 @@ Internet-Draft Name Server Management Requirements February 2009 2.1. Expected Deployment Scenarios DNS zones vary greatly in the type of content published within them. - Name Servers, too, are deployed with a wide variety of configurations + Name servers, too, are deployed with a wide variety of configurations to support the diversity of the deployed content. It is important that a management solution trying to meet the criteria specified in this document consider supporting the largest number of potential @@ -269,31 +271,35 @@ Internet-Draft Name Server Management Requirements February 2009 not used as direct examples of specific requirements are listed in Appendix A. -2.1.1. Zone Size Constraints - The management solution MUST support both name servers that are - serving a small number of potentially very large zones (e.g. Top -Hardaker Expires August 16, 2009 [Page 5] + + + + +Hardaker Informational [Page 5] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 + +2.1.1. Zone Size Constraints + The management solution MUST support both name servers that are + serving a small number of potentially very large zones (e.g., Top Level Domains (TLDs)) as well as name servers that are serving a very - large number of small zones. These scenarios are both commonly seen - deployments. + large number of small zones. Both deployment scenarios are common. 2.1.2. Name Server Discovery Large enterprise network deployments may contain multiple name servers operating within the boundaries of the enterprise network. These name servers may each be serving multiple zones both in and out - of the parent enterprise's zone. Finding and managing large - quantities of name servers would be a useful feature of the resulting - management solution. The management solution MAY support the ability - to discover previously unknown instances of name servers operating + of the parent enterprise's zone. Finding and managing large numbers + of name servers would be a useful feature of the resulting management + solution. The management solution MAY support the ability to + discover previously unknown instances of name servers operating within a deployed network. 2.1.3. Configuration Data Volatility @@ -301,45 +307,44 @@ Internet-Draft Name Server Management Requirements February 2009 Configuration data is defined as data that relates only to the configuration of a server and the zones it serves. It specifically does not include data from the zone contents that is served through - DNS itself. The solution MUST support servers that remain fairly - statically configured over time as well as servers that have numerous - zones being added and removed within an hour. Both of these - scenarios are also commonly seen deployments. + DNS itself. The solution MUST support servers that remain statically + configured over time as well as servers that have numerous zones + being added and removed within an hour. Both deployment scenarios + are common. 2.1.4. Protocol Selection There are many requirements in this document for many different types of management operations (see Section 3 for further details). It is possible that no one protocol will ideally fill all the needs of the - requirements listed in this document and thus multiple protocols + requirements listed in this document, and thus multiple protocols might be needed to produce a completely functional management system. Multiple protocols might be used to create the complete management - solution, but the number of protocols used SHOULD be reduced to a - reasonable minimum number. + solution, but the solution SHOULD require only one. 2.1.5. Common Data Model Defining a standardized protocol (or set of protocols) to use for managing name servers would be a step forward in achieving an interoperable management solution. However, just defining a protocol - to use by itself would not achieve the complete end goal of a - complete interoperable management solution. Devices also need to - represent their internal management interface using a common - management data model. The solution MUST create a common data model - that management stations can make use of when sending or collecting - data from a managed device so it can successfully manage equipment - from vendors as if they were generic DNS servers. This common data + to use by itself would not achieve the entire end goal of a complete + interoperable management solution. Devices also need to represent + their internal management interface using a common management data + model. The solution MUST create a common data model that management + stations can make use of when sending or collecting data from a -Hardaker Expires August 16, 2009 [Page 6] +Hardaker Informational [Page 6] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 - model is needed for of the operations discussion in Section 3. Note - that this does not preclude the fact that name server vendors might - provide additional management infrastructure beyond a base management + managed device so it can successfully manage equipment from vendors + as if they were generic DNS servers. This common data model is + needed for the operations discussion in Section 3. Note that this + does not preclude the fact that name server vendors might provide + additional management infrastructure beyond a base management specification, as discussed further in Section 5.1. 2.1.6. Operational Impact @@ -347,11 +352,12 @@ Internet-Draft Name Server Management Requirements February 2009 It is impossible to add new features to an existing server (such as the inclusion of a management infrastructure) and not impact the existing service and/or server in some fashion. At a minimum, for - example, more memory, disk and/or CPU resources will be required to + example, more memory, disk, and/or CPU resources will be required to implement a new management system. However, the impact to the existing DNS service MUST be minimized since the DNS service itself is still the primary service to be offered by the modified name - server. + server. The management solution MUST NOT result in an increase of + the number of unhandled DNS requests. 2.2. Name Server Types @@ -371,8 +377,7 @@ Internet-Draft Name Server Management Requirements February 2009 roles are also important to support within any management solution. As stated earlier, the management of stub resolvers is considered out - of scope for this documents. - + of scope for this document. 3. Management Operation Types @@ -383,20 +388,20 @@ Internet-Draft Name Server Management Requirements February 2009 o Configuration - o Health and Monitoring - -Hardaker Expires August 16, 2009 [Page 7] +Hardaker Informational [Page 7] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 + o Health and Monitoring + o Alarms and Events - This section discusses requirements for each of these four management - types in detail. + This section discusses detailed requirements for each of these four + management categories. 3.1. Control Requirements @@ -412,7 +417,9 @@ Internet-Draft Name Server Management Requirements February 2009 o Reloading the service configuration - o Reloading zone data + o Reloading all of the zone data + + o Reloading individual zone data sets o Restarting the name server @@ -431,23 +438,22 @@ Internet-Draft Name Server Management Requirements February 2009 SHOULD take this into consideration and offer a mechanism to ease the burden associated with awaiting the status of a long-running command. This could, for example, result in the use of asynchronous - notifications for returning the status of a long-running task or it + notifications for returning the status of a long-running task, or it might require the management station to poll for the status of a given task using monitoring commands. These and other potential solutions need to be evaluated carefully to select one that balances the result delivery needs with the perceived implementation costs. - Also, see the related discussion in Section 3.4 on notification - messages for supporting delivery of alarm and event messages. - - -Hardaker Expires August 16, 2009 [Page 8] +Hardaker Informational [Page 8] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 + + Also, see the related discussion in Section 3.4 on notification + messages for supporting delivery of alarm and event messages. 3.2. Configuration Requirements @@ -458,21 +464,22 @@ Internet-Draft Name Server Management Requirements February 2009 3.2.1. Served Zone Modification - The ability to add, modify and delete zones being served by name + The ability to add, modify, and delete zones being served by name servers is needed. Although there are already solutions for zone content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007], - AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that - might be used as part of the final management solution, the - management system SHOULD still be able to natively create a new zone - (with enough minimal data to allow the other mechanisms to function - as well) as well as delete a zone. This might be, for example, a - management operation that at least allows for the creation of the - initial SOA record for a new zone as that's the minimum amount of - zone data needed for the other operations to function. + full zone transfer (AXFR) [RFC5936], and incremental zone transfer + (IXFR) [RFC1995]) that might be used as part of the final management + solution, the management system SHOULD still be able to create a new + zone (with enough minimal data to allow the other mechanisms to + function as well) and to delete a zone. This might be, for example, + a management operation that allows for the creation of at least the + initial SOA (Start of Authority) record for a new zone, since that is + the minimum amount of zone data needed for the other operations to + function. 3.2.2. Trust Anchor Management - The solution SHOULD support the ability to add, modify and delete + The solution SHOULD support the ability to add, modify, and delete trust anchors that are used by DNS Security (DNSSEC) [RFC4033] [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust anchors might be configured using the data from the DNSKEY Resource @@ -481,42 +488,42 @@ Internet-Draft Name Server Management Requirements February 2009 3.2.3. Security Expectations - DNSSEC Validating resolvers need to make policy decisions about the + DNSSEC validating resolvers need to make policy decisions about the requests being processed. For example, they need to be configured with a list of zones expected to be secured by DNSSEC. The - management solution SHOULD be able to add, modify and delete + management solution SHOULD be able to add, modify, and delete attributes of DNSSEC security policies. 3.2.4. TSIG Key Management - TSIG [RFC2845] allows transaction level authentication of DNS - traffic. The management solution SHOULD be able to add, modify and + TSIG [RFC2845] allows transaction-level authentication of DNS + traffic. The management solution SHOULD be able to add, modify, and delete TSIG keys known to the name server. -3.2.5. DNS Protocol Authorization Management - - The management solution SHOULD have the ability to add, modify and - delete authorization settings for the DNS protocols itself. Do not -Hardaker Expires August 16, 2009 [Page 9] +Hardaker Informational [Page 9] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 + +3.2.5. DNS Protocol Authorization Management + The management solution SHOULD have the ability to add, modify, and + delete authorization settings for the DNS protocols itself. Do not confuse this with the ability to manage the authorization associated with the management protocol itself, which is discussed later in Section 4.4. There are a number of authorization settings that are used by a name server. Example authorization settings that the solution might need to cover are: - o Access to operations on zone data (e.g. DDNS) + o Access to operations on zone data (e.g., DDNS) - o Access to certain zone data from certain sources (e.g. from + o Access to certain zone data from certain sources (e.g., from particular network subnets) - o Access to specific DNS protocol services (e.g. recursive service) + o Access to specific DNS protocol services (e.g., recursive service) Note: the above list is expected to be used as a collection of examples and is not a complete list of needed authorization @@ -527,57 +534,58 @@ Internet-Draft Name Server Management Requirements February 2009 Monitoring is the process of collecting aspects of the internal state of a name server at a given moment in time. The solution MUST be able to monitor the health of a name server to determine its - operational status, load and other internal attributes. Example - management tasks that the solution might need to cover are: + operational status, load, and other internal attributes. Example + parameters that the solution might need to collect and analyze are: - o Number of requests sent, responses sent, average response latency - and other performance counters + o Number of requests sent, responses sent, number of errors, average + response latency, and other performance counters - o Server status (e.g. "serving data", "starting up", "shutting - down", ...) + o Server status (e.g., "serving data", "starting up", "shutting + down", etc.) o Access control violations o List of zones being served o Detailed statistics about clients interacting with the name server - (e.g. top 10 clients requesting data). + (e.g., top 10 clients requesting data). Note: the above list is expected to be used as a collection of examples and is not a complete list of needed monitoring operations. In particular, some monitoring statistics are expected to be computationally or resource expensive and are considered to be "nice - to haves" as opposed to "necessary to have". - -3.4. Alarm and Event Requirements + to have" as opposed to "necessary to have". - Events occurring at the name server that trigger alarm notifications - can quickly inform a management station about critical issues. A -Hardaker Expires August 16, 2009 [Page 10] +Hardaker Informational [Page 10] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 +3.4. Alarm and Event Requirements + + Events occurring at the name server that trigger alarm notifications + can quickly inform a management station about critical issues. A management solution SHOULD include support for delivery of alarm conditions. Example alarm conditions might include: - o The server's status is changing. (e.g it is starting up, reloading - configuration, restarting or shutting down) + o The server's status is changing (e.g., it is starting up, + reloading configuration, restarting or shutting down). - o A needed resource (e.g. memory or disk space) is exhausted or - nearing exhaustion + o A needed resource (e.g., memory or disk space) is exhausted or + nearing exhaustion. - o An authorization violation was detected + o An authorization violation was detected. - o The server has not received any data traffic (e.g. DNS requests - or NOTIFYs) recently (AKA the "lonely warning"). This condition - might indicate a problem with its deployment. + o The server has not received any data traffic (e.g., DNS requests + or NOTIFYs) recently (aka the "lonely warning"). This condition + might indicate a problem with the server's deployment. + o The number of errors has exceeded a configured threshold. 4. Security Requirements @@ -605,21 +613,21 @@ Internet-Draft Name Server Management Requirements February 2009 necessarily need to provide confidentiality to data that would normally be carried without confidentiality by the DNS system itself. -4.4. Authorization - The solution SHOULD be capable of providing a fine-grained - authorization model for any management protocols it introduces to the - - -Hardaker Expires August 16, 2009 [Page 11] +Hardaker Informational [Page 11] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 + +4.4. Authorization - completed system. This authorization differs from the authorization - previously discussed in Section 3.2.5 in that this requirement is - concerned solely with authorization of the management system itself. + The solution SHOULD provide an authorization model capable of + selectively authorizing individual management requests for any + management protocols it introduces to the completed system. This + authorization differs from the authorization previously discussed in + Section 3.2.5 in that this requirement is concerned solely with + authorization of the management system itself. There are a number of authorization settings that might be used by a managed system to determine whether the managing entity has @@ -651,28 +659,27 @@ Internet-Draft Name Server Management Requirements February 2009 management benefits will be worth the increased risks, the solution still needs to minimize this impact as much as possible. - 5. Other Requirements 5.1. Extensibility The management solution is expected to change and expand over time as lessons are learned and new DNS features are deployed. Thus, the - solution MUST be flexible and be able to accommodate new future + solution MUST be flexible and able to accommodate new future management operations. The solution might, for example, make use of protocol versioning or capability description exchanges to ensure - that management stations and name servers that weren't written to the - same specification version can still interoperate to the best of - their combined ability. - -Hardaker Expires August 16, 2009 [Page 12] +Hardaker Informational [Page 12] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 + that management stations and name servers that weren't written to the + same specification version can still interoperate to the best of + their combined ability. + 5.1.1. Vendor Extensions It MUST be possible for vendors to extend the standardized management @@ -684,81 +691,70 @@ Internet-Draft Name Server Management Requirements February 2009 It MUST be possible for a management station to understand which parts of returned data are specific to a given vendor or other standardized extension. The data returned needs to be appropriately - marked through the use of name spaces or similar mechanisms to ensure - that the base management model data can be logically separated from - extension data without needing to understand the extension data - itself. + marked, through the use of name spaces or similar mechanisms, to + ensure that the base management model data can be logically separated + from the extension data without needing to understand the extension + data itself. 5.1.3. Name-Space Collision Protection It MUST be possible to protect against multiple extensions conflicting with each other. The use of name-space protection mechanisms for communicated management variables is common practice - to protect against problems. Name-space identification techniques - also frequently solve the "Extension Identification" requirement - discussed in Section 5.1.2 as well. - + to protect against such problems. Name-space identification + techniques also frequently solve the "Extension Identification" + requirement discussed in Section 5.1.2. 6. Security Considerations - Any management protocol that meets the criteria discussed in this - document needs to support the criteria discussed in Section 4 in + Any management protocol for which conformance to this document is + claimed needs to fully support the criteria discussed in Section 4 in order to protect the management infrastructure itself. The DNS is a - core Internet service and management traffic that protects it could + core Internet service, and management traffic that protects it could be the target of attacks designed to subvert that service. Because the management infrastructure will be adding additional interfaces to that service, it is critical that the management infrastructure support adequate protections against network attacks. +7. Document History -7. IANA Considerations - - No action is required from IANA for this document. - - -8. Document History - - A requirement gathering discussion was held at the December 2007 IETF - meeting in Vancouver, BC, Canada and a follow up meeting was held at + A requirement-gathering discussion was held at the December 2007 IETF + meeting in Vancouver, BC, Canada, and a follow-up meeting was held at the March 2008 IETF meeting in Philadelphia. This document is a + compilation of the results of those discussions as well as + discussions on the DCOMA mailing list. -Hardaker Expires August 16, 2009 [Page 13] - -Internet-Draft Name Server Management Requirements February 2009 - - compilation of the results of those discussions as well as - discussions on the DCOMA mailing list. +Hardaker Informational [Page 13] + +RFC 6168 Name Server Management Requirements May 2011 -9. Acknowledgments +8. Acknowledgments - This draft is the result of discussions within the DCOMA design team - chaired by Jaap Akkerhuis. This team consisted of a large number of - people all of whom provided valuable insight and input into the - discussions surrounding name server management. The text of this - document was written from notes taken during meetings as well as from - contributions sent to the DCOMA mailing list. This work documents - the consensus of the DCOMA design team. + This document is the result of discussions within the DCOMA design + team chaired by Jaap Akkerhuis. This team consisted of a large + number of people, all of whom provided valuable insight and input + into the discussions surrounding name server management. The text of + this document was written from notes taken during meetings as well as + from contributions sent to the DCOMA mailing list. This work + documents the consensus of the DCOMA design team. In particular, the following team members contributed significantly to the text in the document: Stephane Bortzmeyer - Stephen Morris - Phil Regnauld - Further editing contributions and wording suggestions were made by: - Alfred Hoenes. - + Further editing contributions and wording suggestions were made by + Alfred Hoenes and Doug Barton. -10. References +9. References -10.1. Normative References +9.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. @@ -777,19 +773,20 @@ Internet-Draft Name Server Management Requirements February 2009 RFC 2136, April 1997. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. -Hardaker Expires August 16, 2009 [Page 14] - -Internet-Draft Name Server Management Requirements February 2009 - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. +Hardaker Informational [Page 14] + +RFC 6168 Name Server Management Requirements May 2011 + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", @@ -813,7 +810,10 @@ Internet-Draft Name Server Management Requirements February 2009 Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. -10.2. Informative References + [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol + (AXFR)", RFC 5936, June 2010. + +9.2. Informative References [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions", RFC 1611, May 1994. @@ -829,52 +829,59 @@ Internet-Draft Name Server Management Requirements February 2009 Extensions", RFC 3197, November 2001. -Appendix A. Deployment Scenarios - This appendix documents some additional deployment scenarios that - have been traditionally difficult to manage. They are provided as -Hardaker Expires August 16, 2009 [Page 15] + + + + + + +Hardaker Informational [Page 15] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 +Appendix A. Deployment Scenarios + + This appendix documents some additional deployment scenarios that + have been traditionally difficult to manage. They are provided as guidance to protocol developers as data points of real-world name server management problems. A.1. Non-Standard Zones - If an organization uses non-standard zones (for example a purely- + If an organization uses non-standard zones (for example a purely local TLD), synchronizing all the name servers for these zones is usually a time-consuming task. It is made worse when two organizations with conflicting zones merge. This situation is not a - recommended deployment scenario (and is even heavily discouraged) but - it is, unfortunately, seen in the wild. + recommended deployment scenario (and is even heavily discouraged), + but it is, unfortunately, seen in the wild. It is typically implemented using "forwarding" zones. But there is no way to ensure automatically that all the resolvers have the same set of zones to forward at any given time. New zones might be added to a local forwarding recursive server, for example, without modifying the rest of the deployed forwarding servers. It is hoped - that a management solution which could handle the configuration of + that a management solution that could handle the configuration of zone forwarding would finally allow management of servers deployed in this fashion. A.2. Redundancy Sharing - For reliability reasons it is recommended that zone operators follow - the guidelines documented in [RFC2182] which recommends that multiple - name servers be configured for each zone and that the name servers - are separated both physically and via connectivity routes. A common - solution is to establish DNS-serving partnerships: "I'll host your - zones and you'll host mine". Both entities benefit from increased - DNS reliability via the wider service distribution. This frequently - occurs between cooperating but otherwise unrelated entities (such as - between two distinct companies) as well as between affiliated - organizations (such as between branch offices within a single - company). + For reliability reasons, it is recommended that zone operators follow + the guidelines documented in [RFC2182], which recommends that + multiple name servers be configured for each zone and that the name + servers be separated both physically and via connectivity routes. A + common solution is to establish DNS-serving partnerships: "I'll host + your zones and you'll host mine". Both entities benefit from + increased DNS reliability via the wider service distribution. This + frequently occurs between cooperating but otherwise unrelated + entities (such as between two distinct companies) as well as between + affiliated organizations (such as between branch offices within a + single company). The configuration of these relationships are currently required to be manually configured and maintained. Changes to the list of zones @@ -884,19 +891,20 @@ A.2. Redundancy Sharing Section 4.4, would solve many of the management difficulties between cooperating organizations. -A.3. DNSSEC Management - There are many different DNSSEC deployment strategies that may be - used for mission-critical zones. The following list describes some - example deployment scenarios that might warrant different management -Hardaker Expires August 16, 2009 [Page 16] +Hardaker Informational [Page 16] -Internet-Draft Name Server Management Requirements February 2009 +RFC 6168 Name Server Management Requirements May 2011 + +A.3. DNSSEC Management + There are many different DNSSEC deployment strategies that may be + used for mission-critical zones. The following list describes some + example deployment scenarios that might warrant different management strategies. All contents and DNSSEC keying information controlled and operated @@ -917,13 +925,12 @@ Internet-Draft Name Server Management Requirements February 2009 entities. The end result of all of these strategies, however, will be the same: - a live zone containing DNSSEC related resource records. Many of the + a live zone containing DNSSEC-related resource records. Many of the above strategies are merely different ways of preparing a zone for serving. A management solution that includes support for managing DNSSEC zone data may wish to take into account these potential management scenarios. - Author's Address Wes Hardaker @@ -933,11 +940,7 @@ Author's Address US Phone: +1 530 792 1913 - Email: ietf@hardakers.net - - - - + EMail: ietf@hardakers.net @@ -948,5 +951,5 @@ Author's Address -Hardaker Expires August 16, 2009 [Page 17] +Hardaker Informational [Page 17] diff --git a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt b/doc/rfc/rfc6672.txt similarity index 50% rename from doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt rename to doc/rfc/rfc6672.txt index 34723c4f73e..1534cf4ce85 100644 --- a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt +++ b/doc/rfc/rfc6672.txt @@ -1,65 +1,68 @@ -DNS Extensions Working Group S. Rose -Internet-Draft NIST -Obsoletes: 2672 (if approved) W. Wijngaards -Updates: 3363,4294 NLnet Labs -(if approved) April 20, 2010 -Intended status: Standards Track -Expires: October 22, 2010 - Update to DNAME Redirection in the DNS - draft-ietf-dnsext-rfc2672bis-dname-19 -Abstract +Internet Engineering Task Force (IETF) S. Rose +Request for Comments: 6672 NIST +Obsoletes: 2672 W. Wijngaards +Updates: 3363 NLnet Labs +Category: Standards Track June 2012 +ISSN: 2070-1721 - The DNAME record provides redirection for a sub-tree of the domain - name tree in the DNS system. That is, all names that end with a - particular suffix are redirected to another part of the DNS. This is - a revision of the original specification in RFC 2672, also aligning - RFC 3363 and RFC 4294 with this revision. -Requirements Language + DNAME Redirection in the DNS - 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]. +Abstract + + The DNAME record provides redirection for a subtree of the domain + name tree in the DNS. That is, all names that end with a particular + suffix are redirected to another part of the DNS. This document + obsoletes the original specification in RFC 2672 as well as updates + the document on representing IPv6 addresses in DNS (RFC 3363). Status of This Memo - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6672. + + + + - 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 October 22, 2010. -Rose & Wijngaards Expires October 22, 2010 [Page 1] + + + + + + + + +Rose & Wijngaards Standards Track [Page 1] -Internet-Draft DNAME Redirection April 2010 +RFC 6672 DNAME Redirection June 2012 Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal @@ -70,7 +73,7 @@ Copyright Notice to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as - described in the BSD License. + described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November @@ -108,54 +111,54 @@ Copyright Notice -Rose & Wijngaards Expires October 22, 2010 [Page 2] +Rose & Wijngaards Standards Track [Page 2] -Internet-Draft DNAME Redirection April 2010 +RFC 6672 DNAME Redirection June 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - - 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4 - 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 5 + 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5 - 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 7 - 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7 - 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7 - + 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 6 + 2.4. Names next to and below a DNAME Record . . . . . . . . . . 7 + 2.5. Compression of the DNAME Record . . . . . . . . . . . . . 7 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 9 - 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.1. CNAME Synthesis . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. Server Algorithm . . . . . . . . . . . . . . . . . . . . . 9 + 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11 - - 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 11 - + 3.4.1. Resolver Algorithm . . . . . . . . . . . . . . . . . . 11 + 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 12 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 13 - 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 13 + 5.1. Canonical Hostnames Cannot Be below DNAME Owners . . . . . 13 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13 - 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13 - 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13 + 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 14 + 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 14 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 14 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 14 - 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 14 + 5.3.4.1. Invalid Name Error Response Caused by DNAME in + Bitmap . . . . . . . . . . . . . . . . . . . . . . 15 5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap . . . . . . . . . . . . . . . . . . . . . . 15 - 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 15 - - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 - - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 - - + 5.3.4.3. Response with Synthesized CNAME . . . . . . . . . 16 + 6. Examples of DNAME Use in a Zone . . . . . . . . . . . . . . . 16 + 6.1. Organizational Renaming . . . . . . . . . . . . . . . . . 16 + 6.2. Classless Delegation of Shorter Prefixes . . . . . . . . . 17 + 6.3. Network Renumbering Support . . . . . . . . . . . . . . . 17 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Appendix A. Changes from RFC 2672 . . . . . . . . . . . . . . . . 21 + A.1. Changes to Server Behavior . . . . . . . . . . . . . . . . 21 + A.2. Changes to Client Behavior . . . . . . . . . . . . . . . . 21 @@ -164,14 +167,14 @@ Table of Contents -Rose & Wijngaards Expires October 22, 2010 [Page 3] +Rose & Wijngaards Standards Track [Page 3] -Internet-Draft DNAME Redirection April 2010 +RFC 6672 DNAME Redirection June 2012 1. Introduction - DNAME is a DNS Resource Record type originally defined in RFC 2672 + DNAME is a DNS resource record type originally defined in RFC 2672 [RFC2672]. DNAME provides redirection from a part of the DNS name tree to another part of the DNS name tree. @@ -179,56 +182,64 @@ Internet-Draft DNAME Redirection April 2010 (potentially) return data corresponding to a domain name different from the queried domain name. The difference between the two resource records is that the CNAME RR directs the lookup of data at - its owner to another single name, a DNAME RR directs lookups for data - at descendants of its owner's name to corresponding names under a - different (single) node of the tree. + its owner to another single name, whereas a DNAME RR directs lookups + for data at descendants of its owner's name to corresponding names + under a different (single) node of the tree. - Take for example, looking through a zone (see RFC 1034 [RFC1034], - section 4.3.2, step 3) for the domain name "foo.example.com" and a + For example, take looking through a zone (see RFC 1034 [RFC1034], + Section 4.3.2, step 3) for the domain name "foo.example.com", and a DNAME resource record is found at "example.com" indicating that all queries under "example.com" be directed to "example.net". The lookup process will return to step 1 with the new query name of - "foo.example.net". Had the query name been "www.foo.example.com" the - new query name would be "www.foo.example.net". + "foo.example.net". Had the query name been "www.foo.example.com", + the new query name would be "www.foo.example.net". This document is a revision of the original specification of DNAME in RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of maintaining address-to-name mappings in a context of network - renumbering. With a careful set-up, a renumbering event in the + renumbering. With a careful setup, a renumbering event in the network causes no change to the authoritative server that has the address-to-name mappings. Examples in practice are classless reverse address space delegations. Another usage of DNAME lies in aliasing of name spaces. For example, - a zone administrator may want sub-trees of the DNS to contain the - same information. Examples include punycode alternates for domain - spaces. + a zone administrator may want subtrees of the DNS to contain the same + information. Examples include punycode [RFC3492] alternates for + domain spaces. - This revision to DNAME does not change the wire format or the - handling of DNAME Resource Records. Discussion is added on problems - that may be encountered when using DNAME. + This revision of the DNAME specification does not change the wire + format or the handling of DNAME resource records. Discussion is + added on problems that may be encountered when using DNAME. -2. The DNAME Resource Record - -2.1. Format +1.1. Requirements Language - The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is - not class-sensitive. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED" "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. -Rose & Wijngaards Expires October 22, 2010 [Page 4] +Rose & Wijngaards Standards Track [Page 4] -Internet-Draft DNAME Redirection April 2010 +RFC 6672 DNAME Redirection June 2012 +2. The DNAME Resource Record + +2.1. Format + + The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is + CLASS-insensitive. + Its RDATA is comprised of a single field, , which contains a - fully qualified domain name that must be sent in uncompressed form - [RFC1035], [RFC3597]. The field MUST be present. The + fully qualified domain name that MUST be sent in uncompressed form + [RFC1035] [RFC3597]. The field MUST be present. The presentation format of is that of a domain name [RFC1035]. + The presentation format of the RR is as follows: DNAME @@ -245,9 +256,9 @@ Internet-Draft DNAME Redirection April 2010 2.2. The DNAME Substitution - When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third - step, "start matching down, label by label, in the zone" and a node - is found to own a DNAME resource record a DNAME substitution occurs. + When following step 3 of the algorithm in RFC 1034 [RFC1034], Section + 4.3.2, "start matching down, label by label, in the zone" and a node + is found to own a DNAME resource record, a DNAME substitution occurs. The name being sought may be the original query name or a name that is the result of a CNAME resource record being followed or a previously encountered DNAME. As in the case when finding a CNAME @@ -261,33 +272,21 @@ Internet-Draft DNAME Redirection April 2010 replaced. See the table of examples for common cases and corner cases. + In the table below, the QNAME refers to the query name. The owner is + the DNAME owner domain name, and the target refers to the target of + the DNAME record. The result is the resulting name after performing + the DNAME substitution on the query name. "no match" means that the - - - - - - - - - - - - -Rose & Wijngaards Expires October 22, 2010 [Page 5] +Rose & Wijngaards Standards Track [Page 5] -Internet-Draft DNAME Redirection April 2010 +RFC 6672 DNAME Redirection June 2012 - In the table below, the QNAME refers to the query name. The owner is - the DNAME owner domain name, and the target refers to the target of - the DNAME record. The result is the resulting name after performing - the DNAME substitution on the query name. "no match" means that the - query did not match the DNAME and thus no substitution is performed + query did not match the DNAME, and thus no substitution is performed and a possible error message is returned (if no other result is - possible). Thus every line contains one example substitution. In + possible). Thus, every line contains one example substitution. In the examples below, 'cyc' and 'shortloop' contain loops. QNAME owner DNAME target result @@ -306,176 +305,171 @@ Internet-Draft DNAME Redirection April 2010 shortloop.x. x. . shortloop. [0] The result depends on the QTYPE. If the QTYPE = DNAME, then - the result is "example.com." else "" + the result is "example.com.", else "". - Table 1. DNAME Substitution Examples. + Table 1. DNAME Substitution Examples It is possible for DNAMEs to form loops, just as CNAMEs can form loops. DNAMEs and CNAMEs can chain together to form loops. A single corner case DNAME can form a loop. Resolvers and servers should be cautious in devoting resources to a query, but be aware that fairly long chains of DNAMEs may be valid. Zone content administrators - should take care to insure that there are no loops that could occur + should take care to ensure that there are no loops that could occur when using DNAME or DNAME/CNAME redirection. The domain name can get too long during substitution. For example, suppose the target name of the DNAME RR is 250 octets in length (multiple labels), if an incoming QNAME that has a first label over 5 octets in length, the result would be a name over 255 octets. If - this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The + this occurs, the server returns an RCODE of YXDOMAIN [RFC2136]. The DNAME record and its signature (if the zone is signed) are included in the answer as proof for the YXDOMAIN (value 6) RCODE. +2.3. DNAME Owner Name Matching the QNAME + Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its + owner name; the owner name of a DNAME is not redirected itself. The + domain name that owns a DNAME record is allowed to have other + resource record types at that domain name, except DNAMEs, CNAMEs, or + other types that have restrictions on what they can coexist with. - - -Rose & Wijngaards Expires October 22, 2010 [Page 6] +Rose & Wijngaards Standards Track [Page 6] -Internet-Draft DNAME Redirection April 2010 +RFC 6672 DNAME Redirection June 2012 -2.3. DNAME Owner Name Matching the QNAME - - Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its - owner name; the owner name of a DNAME is not redirected itself. The - domain name that owns a DNAME record is allowed to have other - resource record types at that domain name, except DNAMEs, CNAMEs or - other types that have restrictions on what they can co-exist with. When there is a match of the QTYPE to a type (or types) also owned by - the owner name the response is sourced from the owner name. E.g., a - QTYPE of ANY would return the (available) types at the owner name, - not the target name. + the owner name, the response is sourced from the owner name. For + example, a QTYPE of ANY would return the (available) types at the + owner name, not the target name. DNAME RRs MUST NOT appear at the same owner name as an NS RR unless - the owner name is the zone apex as this would constitute data below a - zone cut. + the owner name is the zone apex; if it is not the zone apex, then the + NS RR signifies a delegation point, and the DNAME RR must in that + case appear below the zone cut at the zone apex of the child zone. If a DNAME record is present at the zone apex, there is still a need to have the customary SOA and NS resource records there as well. Such a DNAME cannot be used to mirror a zone completely, as it does not mirror the zone apex. - These rules also allow DNAME records to be queried through RFC 1034 - [RFC1034] compliant, DNAME-unaware caches. + These rules also allow DNAME records to be queried through caches + that are RFC 1034 [RFC1034] compliant and are DNAME unaware. -2.4. Names Next to and Below a DNAME Record +2.4. Names next to and below a DNAME Record - Resource records MUST NOT exist at any sub-domain of the owner of a + Resource records MUST NOT exist at any subdomain of the owner of a DNAME RR. To get the contents for names subordinate to that owner name, the DNAME redirection must be invoked and the resulting target - queried. A server MAY refuse to load a zone that has data at a sub- - domain of a domain name owning a DNAME RR. If the server does load - the zone, those names below the DNAME RR will be occluded as - described in RFC 2136 [RFC2136], section 7.18. Also a server SHOULD - refuse to load a zone subordinate to the owner of a DNAME record in - the ancestor zone. See Section 5.2 for further discussion related to - dynamic update. + queried. A server MAY refuse to load a zone that has data at a + subdomain of a domain name owning a DNAME RR. If the server does + load the zone, those names below the DNAME RR will be occluded as + described in RFC 2136 [RFC2136], Section 7.18. Also, a server ought + to refuse to load a zone subordinate to the owner of a DNAME record + in the ancestor zone. See Section 5.2 for further discussion related + to dynamic update. DNAME is a singleton type, meaning only one DNAME is allowed per name. The owner name of a DNAME can only have one DNAME RR, and no CNAME RRs can exist at that name. These rules make sure that for a - single domain name only one redirection exists, and thus no confusion - which one to follow. A server SHOULD refuse to load a zone that - violates these rules. + single domain name, only one redirection exists; thus, there's no + confusion about which one to follow. A server ought to refuse to + load a zone that violates these rules. -2.5. Compression of the DNAME record. +2.5. Compression of the DNAME Record The DNAME owner name can be compressed like any other owner name. - The DNAME RDATA target name MUST NOT be sent out in compressed form, + The DNAME RDATA target name MUST NOT be sent out in compressed form + and MUST be downcased for DNS Security Extensions (DNSSEC) + validation. + -Rose & Wijngaards Expires October 22, 2010 [Page 7] - -Internet-Draft DNAME Redirection April 2010 - so that a DNAME RR can be treated as an unknown type [RFC3597]. + +Rose & Wijngaards Standards Track [Page 7] + +RFC 6672 DNAME Redirection June 2012 + Although the previous DNAME specification [RFC2672] (that is obsoleted by this specification) talked about signaling to allow compression of the target name, such signaling has never been - specified and this document also does not specify this signaling - behavior. + specified, nor is it specified in this document. - RFC 2672 (obsoleted by this document) stated that the EDNS version - had a meaning for understanding of DNAME and DNAME target name - compression. This document revises RFC 2672, in that there is no - EDNS version signaling for DNAME. + RFC 2672 (obsoleted by this document) states that the Extended DNS + (EDNS) version has a means for understanding DNAME and DNAME target + name compression. This document revises RFC 2672, in that there is + no EDNS version signaling for DNAME. 3. Processing - The DNAME RR causes type NS additional section processing. This - refers to action at step 6 of the server algorithm outlined in - section 3.2. - -3.1. CNAME synthesis +3.1. CNAME Synthesis When preparing a response, a server performing a DNAME substitution - will in all cases include the relevant DNAME RR in the answer - section. Relevant includes the following cases: + will, in all cases, include the relevant DNAME RR in the answer + section. Relevant cases includes the following: 1. The DNAME is being employed as a substitution instruction. - 2. The DNAME itself matches the QTYPE and the owner name matches + 2. The DNAME itself matches the QTYPE, and the owner name matches QNAME. - When the owner name name matches the QNAME and the QTYPE matches - another type owned there, the DNAME is not included in the answer. + When the owner name matches the QNAME and the QTYPE matches another + type owned there, the DNAME is not included in the answer. - A CNAME RR with TTL equal to the corresponding DNAME RR is - synthesized and included in the answer section when the DNAME is - employed as a substitution instruction. The owner name of the CNAME - is the QNAME of the query. The DNSSEC specification [RFC4033], - [RFC4034], [RFC4035] says that the synthesized CNAME does not have to - be signed. The DNAME has an RRSIG and a validating resolver can - check the CNAME against the DNAME record and validate the signature - over the DNAME RR. + A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME + RR is synthesized and included in the answer section when the DNAME + is employed as a substitution instruction. The owner name of the + CNAME is the QNAME of the query. The DNSSEC specification ([RFC4033] + [RFC4034] [RFC4035]) says that the synthesized CNAME does not have to + be signed. The signed DNAME has an RRSIG, and a validating resolver + can check the CNAME against the DNAME record and validate the + signature over the DNAME RR. Servers MUST be able to answer a query for a synthesized CNAME. Like - other query types this invokes the DNAME, and synthesizes the CNAME - into the answer. If the server in question is a cache, the - synthesized CNAME's TTL SHOULD be equal to the decremented TTL of the - cached DNAME. + other query types, this invokes the DNAME, and then the server + synthesizes the CNAME and places it into the answer section. If the + server in question is a cache, the synthesized CNAME's TTL SHOULD be + equal to the decremented TTL of the cached DNAME. + Resolvers MUST be able to handle a synthesized CNAME TTL of zero or a + value equal to the TTL of the corresponding DNAME record (as some + older, authoritative server implementations set the TTL of + synthesized CNAMEs to zero). A TTL of zero means that the CNAME can + be discarded immediately after processing the answer. -Rose & Wijngaards Expires October 22, 2010 [Page 8] - -Internet-Draft DNAME Redirection April 2010 - Resolvers MUST be able to handle a synthesized CNAME TTL of zero or - equal to the TTL of the corresponding DNAME record (as some older - authoritative server implementations set the TTL of synthesized - CNAMEs to zero). A TTL of zero means that the CNAME can be discarded - immediately after processing the answer. +Rose & Wijngaards Standards Track [Page 8] + +RFC 6672 DNAME Redirection June 2012 + -3.2. Server algorithm +3.2. Server Algorithm - Below is the server algorithm, which appeared in RFC 2672 Section - 4.1. + Below is the revised version of the server algorithm, which appears + in RFC 2672, Section 4.1. 1. Set or clear the value of recursion available in the response depending on whether the name server is willing to provide recursive service. If recursive service is available and - requested via the RD bit in the query, go to step 5, otherwise + requested via the RD bit in the query, go to step 5; otherwise, step 2. - 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. - + ancestor to QNAME. If such a zone is found, go to step 3; + otherwise, step 4. 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: - A. If the whole of QNAME is matched, we have found the node. If the data at the node is a CNAME, and QTYPE does not match @@ -486,7 +480,6 @@ Internet-Draft DNAME Redirection April 2010 Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. - B. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. @@ -497,14 +490,6 @@ Internet-Draft DNAME Redirection April 2010 available from authoritative data or the cache. Go to step 4. - - - -Rose & Wijngaards Expires October 22, 2010 [Page 9] - -Internet-Draft DNAME Redirection April 2010 - - C. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see whether the last label matched has a DNAME record. @@ -512,8 +497,17 @@ Internet-Draft DNAME Redirection April 2010 If a DNAME record exists at that point, copy that record into the answer section. If substitution of its for its in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [RFC2136] and exit; otherwise + name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise, perform the substitution and continue. The server MUST + + + + +Rose & Wijngaards Standards Track [Page 9] + +RFC 6672 DNAME Redirection June 2012 + + synthesize a CNAME record as described above and include it in the answer section. Go back to step 1. @@ -524,7 +518,7 @@ Internet-Draft DNAME Redirection April 2010 are looking for is the original QNAME in the query or a name we have followed due to a CNAME or DNAME. If the name is original, set an authoritative name error in the response and - exit. Otherwise just exit. + exit. Otherwise, just exit. If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but @@ -533,8 +527,7 @@ Internet-Draft DNAME Redirection April 2010 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. Otherwise, Go to step 6. - + CNAME RR, and go back to step 1. Otherwise, go to step 6. 4. Start matching down in the cache. If QNAME is found in the cache, copy all RRs attached to it that match QTYPE into the @@ -544,43 +537,41 @@ Internet-Draft DNAME Redirection April 2010 authoritative data, look for the best one from the cache, and put it in the authority section. Go to step 6. - 5. Use the local resolver or a copy of its algorithm to answer the query. Store the results, including any intermediate CNAMEs and DNAMEs, in the answer section of the response. - - 6. Using local data only, attempt to add other RRs which may be + 6. Using local data only, attempt to add other RRs that may be useful to the additional section of the query. Exit. - - - -Rose & Wijngaards Expires October 22, 2010 [Page 10] - -Internet-Draft DNAME Redirection April 2010 - - Note that there will be at most one ancestor with a DNAME as described in step 4 unless some zone's data is in violation of the - no-descendants limitation in section 3. An implementation might take + no-descendants limitation in Section 3. An implementation might take advantage of this limitation by stopping the search of step 3c or step 4 when a DNAME record is encountered. 3.3. Wildcards The use of DNAME in conjunction with wildcards is discouraged - [RFC4592]. Thus records of the form "*.example.com DNAME + [RFC4592]. Thus, records of the form "*.example.com DNAME example.net" SHOULD NOT be used. + + + +Rose & Wijngaards Standards Track [Page 10] + +RFC 6672 DNAME Redirection June 2012 + + The interaction between the expansion of the wildcard and the - redirection of the DNAME is non-deterministic. Because the - processing is non-deterministic, DNSSEC validating resolvers may not - be able to validate a wildcarded DNAME. + redirection of the DNAME is non-deterministic. Due to the fact that + the processing is non-deterministic, DNSSEC validating resolvers may + not be able to validate a wildcarded DNAME. A server MAY give a warning that the behavior is unspecified if such a wildcarded DNAME is loaded. The server MAY refuse it, refuse to - load the zone or refuse dynamic updates. + load the zone, or refuse dynamic updates. 3.4. Acceptance and Intermediate Storage @@ -596,15 +587,26 @@ Internet-Draft DNAME Redirection April 2010 Recursive caching name servers MUST perform CNAME synthesis on behalf of clients. - If a recursive caching name server encounters a DNAME RR which - contradicts information already in the cache (excluding CNAME - records), it SHOULD NOT cache the DNAME RR, but it MAY cache the + If a recursive caching name server encounters a DNSSEC validated + DNAME RR that contradicts information already in the cache (excluding + CNAME records), it SHOULD cache the DNAME RR, but it MAY cache the CNAME record received along with it, subject to the rules for CNAME. + If the DNAME RR cannot be validated via DNSSEC (i.e., not BOGUS, but + not able to validate), the recursive caching server SHOULD NOT cache + the DNAME RR but MAY cache the CNAME record received along with it, + subject to the rules for CNAME. -4. DNAME Discussions in Other Documents +3.4.1. Resolver Algorithm - In [RFC2181], in Section 10.3., the discussion on MX and NS records - touches on redirection by CNAMEs, but this also holds for DNAMEs. + Below is the revised version of the resolver algorithm, which appears + in RFC 2672, Section 4.2. + + 1. See if the answer is in local information or can be synthesized + from a cached DNAME; if so, return it to the client. + + 2. Find the best servers to ask. + + 3. Send queries until one returns a response. @@ -612,12 +614,43 @@ Internet-Draft DNAME Redirection April 2010 -Rose & Wijngaards Expires October 22, 2010 [Page 11] + +Rose & Wijngaards Standards Track [Page 11] -Internet-Draft DNAME Redirection April 2010 +RFC 6672 DNAME Redirection June 2012 + + + 4. Analyze the response, either: + + A. If the response answers the question or contains a name + error, cache the data as well as return it back to the + client. + + B. If the response contains a better delegation to other + servers, cache the delegation information, and go to step 2. + C. If the response shows a CNAME and that is not the answer + itself, cache the CNAME, change the SNAME to the canonical + name in the CNAME RR, and go to step 1. - Excerpt from 10.3. MX and NS records (in RFC 2181). + D. If the response shows a DNAME and that is not the answer + itself, cache the DNAME (upon successful DNSSEC validation if + the client is a validating resolver). If substitution of the + DNAME's target name for its owner name in the SNAME would + overflow the legal size for a domain name, return an + implementation-dependent error to the application; otherwise, + perform the substitution and go to step 1. + + E. If the response shows a server failure or other bizarre + contents, delete the server from the SLIST and go back to + step 3. + +4. DNAME Discussions in Other Documents + + In Section 10.3 of [RFC2181], the discussion on MX and NS records + touches on redirection by CNAMEs, but this also holds for DNAMEs. + + Section 10.3 ("MX and NS records") of [RFC2181] states: The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be @@ -631,81 +664,77 @@ Internet-Draft DNAME Redirection April 2010 information may be acceptable. It can also have other RRs, but never a CNAME RR. - The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. + The DNAME RR is discussed in RFC 3363, Section 4, on A6 and DNAME. The opening premise of this section is demonstrably wrong, and so the conclusion based on that premise is wrong. In particular, [RFC3363] - deprecates the use of DNAME in the IPv6 reverse tree, which is then - carried forward as a recommendation in [RFC4294]. Based on the - experience gained in the meantime, [RFC3363] should be revised, - dropping all constraints on having DNAME RRs in these zones. This - would greatly improve the manageability of the IPv6 reverse tree. - These changes are made explicit below. - - In [RFC3363], the paragraph - - "The issues for DNAME in the reverse mapping tree appears to be - closely tied to the need to use fragmented A6 in the main tree: if - one is necessary, so is the other, and if one isn't necessary, the - other isn't either. Therefore, in moving RFC 2874 to experimental, - the intent of this document is that use of DNAME RRs in the reverse - tree be deprecated." - - is to be replaced with the word "DELETED". - - In [RFC4294], the reference to DNAME was left in as an editorial - oversight. The paragraph - - "Those nodes are NOT RECOMMENDED to support the experimental A6 and - DNAME Resource Records [RFC3363]." - - is to be replaced by - - "Those nodes are NOT RECOMMENDED to support the experimental - A6 Resource Record [RFC3363]." + deprecates the use of DNAME in the IPv6 reverse tree. Based on the +Rose & Wijngaards Standards Track [Page 12] + +RFC 6672 DNAME Redirection June 2012 + experience gained in the meantime, [RFC3363] is revised, dropping all + constraints on having DNAME RRs in these zones [RFC6434]. This would + greatly improve the manageability of the IPv6 reverse tree. These + changes are made explicit below. -Rose & Wijngaards Expires October 22, 2010 [Page 12] - -Internet-Draft DNAME Redirection April 2010 + In [RFC3363], the following paragraph is updated by this document, + and the use of DNAME RRs in the reverse tree is no longer deprecated. + The issues for DNAME in the reverse mapping tree appears to be + closely tied to the need to use fragmented A6 in the main tree: if + one is necessary, so is the other, and if one isn't necessary, the + other isn't either. Therefore, in moving RFC 2874 to experimental, + the intent of this document is that use of DNAME RRs in the reverse + tree be deprecated. 5. Other Issues with DNAME There are several issues to be aware of about the use of DNAME. -5.1. Canonical hostnames cannot be below DNAME owners +5.1. Canonical Hostnames Cannot Be below DNAME Owners - The names listed as target names of MX, NS, PTR and SRV [RFC2782] + The names listed as target names of MX, NS, PTR, and SRV [RFC2782] records must be canonical hostnames. This means no CNAME or DNAME redirection may be present during DNS lookup of the address records - for the host. This is discussed in RFC 2181 [RFC2181], section 10.3, - and RFC 1912 [RFC1912], section 2.4. For SRV see RFC 2782 [RFC2782] - page 4. + for the host. This is discussed in RFC 2181 [RFC2181], Section 10.3, + and RFC 1912 [RFC1912], Section 2.4. For SRV, see RFC 2782 + [RFC2782], page 4. The upshot of this is that although the lookup of a PTR record can - involve DNAMEs, the name listed in the PTR record can not fall under - a DNAME. The same holds for NS, SRV and MX records. For example, - when punycode alternates for a zone use DNAME then the NS, MX, SRV - and PTR records that point to that zone must use names without - punycode in their RDATA. What must be done then is to have the - domain names with DNAME substitution already applied to it as the MX, - NS, PTR, SRV data. These are valid canonical hostnames. + involve DNAMEs, the name listed in the PTR record cannot fall under a + DNAME. The same holds for NS, SRV, and MX records. For example, + when punycode [RFC3492] alternates for a zone use DNAME, then the NS, + MX, SRV, and PTR records that point to that zone must use names that + are not aliases in their RDATA. Then, what must be done is to have + the domain names with DNAME substitution already applied to it as the + MX, NS, PTR, and SRV data. These are valid canonical hostnames. 5.2. Dynamic Update and DNAME - DNAME records can be added, changed and removed in a zone using + DNAME records can be added, changed, and removed in a zone using dynamic update transactions. Adding a DNAME RR to a zone occludes any domain names that may exist under the added DNAME. - A server MUST ignore a dynamic update message that attempts to add a - non-DNAME/CNAME RR at a name that already has a DNAME RR associated - with that name. Otherwise, replace the DNAME RR with the DNAME (or - CNAME) update RR. This is similar behavior to dynamic updates to an - owner name of a CNAME RR [RFC2136]. + If a dynamic update message attempts to add a DNAME with a given + owner name, but a CNAME is associated with that name, then the server + MUST ignore the DNAME. If a DNAME is already associated with that + name, then it is replaced with the new DNAME. Otherwise, add the + DNAME. If a CNAME is added with a given owner name, but a DNAME is + + + +Rose & Wijngaards Standards Track [Page 13] + +RFC 6672 DNAME Redirection June 2012 + + + associated with that name, then the CNAME MUST be ignored. Similar + behavior occurs for dynamic updates to an owner name of a CNAME RR + [RFC2136]. 5.3. DNSSEC and DNAME @@ -715,45 +744,51 @@ Internet-Draft DNAME Redirection April 2010 5.3.1. Signed DNAME, Unsigned Synthesized CNAME In any response, a signed DNAME RR indicates a non-terminal - redirection of the query. There might or might not be a server + redirection of the query. There might or might not be a server- synthesized CNAME in the answer section; if there is, the CNAME will never be signed. For a DNSSEC validator, verification of the DNAME - RR and then checking that the CNAME was properly synthesized is - sufficient proof. - - - - -Rose & Wijngaards Expires October 22, 2010 [Page 13] - -Internet-Draft DNAME Redirection April 2010 - + RR and then that the CNAME was properly synthesized is sufficient + proof. 5.3.2. DNAME Bit in NSEC Type Map - In any negative response, the NSEC or NSEC3 [RFC5155] record type bit - map SHOULD be checked to see that there was no DNAME that could have - been applied. If the DNAME bit in the type bit map is set and the - query name is a sub-domain of the closest encloser that is asserted, - then DNAME substitution should have been done, but the substitution - has not been done as specified. + In any negative response, the NSEC or NSEC3 [RFC5155] record type + bitmap SHOULD be checked to see that there was no DNAME that could + have been applied. If the DNAME bit in the type bitmap is set and + the query name is a subdomain of the closest encloser that is + asserted, then DNAME substitution should have been done, but the + substitution has not been done as specified. 5.3.3. DNAME Chains as Strong as the Weakest Link A response can contain a chain of DNAME and CNAME redirections. That - chain can end in a positive answer or a negative (no name error or no - data error) reply. Each step in that chain results in resource - records added to the answer or authority section of the response. - Only if all steps are secure can the AD bit be set for the response. - If one of the steps is bogus, the result is bogus. + chain can end in a positive answer or a negative reply (no name error + or no data error). Each step in that chain results in resource + records being added to the answer or authority section of the + response. Only if all steps are secure can the AD (Authentic Data) + bit be set for the response. If one of the steps is bogus, the + result is bogus. 5.3.4. Validators Must Understand DNAME Below are examples of why DNSSEC validators MUST understand DNAME. - In the examples below, SOA records, wildcard denial NSECs and other - material not under discussion has been omitted or shortened. + In the examples, SOA records, wildcard denial NSECs, and other + material not under discussion have been omitted or shortened. + + + + + + + + + +Rose & Wijngaards Standards Track [Page 14] + +RFC 6672 DNAME Redirection June 2012 + -5.3.4.1. DNAME in Bitmap Causes Invalid Name Error +5.3.4.1. Invalid Name Error Response Caused by DNAME in Bitmap ;; Header: QR AA RCODE=3(NXDOMAIN) ;; OPT PSEUDOSECTION: @@ -771,20 +806,9 @@ Internet-Draft DNAME Redirection April 2010 BOGUS reply from an attacker that collated existing records from the DNS to create a confusing reply. - If the DNAME bit had not been set in the NSEC record above then the + If the DNAME bit had not been set in the NSEC record above, then the answer would have validated as a correct name error response. - - - - - - -Rose & Wijngaards Expires October 22, 2010 [Page 14] - -Internet-Draft DNAME Redirection April 2010 - - 5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap ;; Header: QR AA RCODE=3(NXDOMAIN) @@ -801,7 +825,26 @@ Internet-Draft DNAME Redirection April 2010 with this query name (cee.example.com), the answer is validated, because 'cee' does not get redirected by the DNAME at 'bar'. -5.3.4.3. Response With Synthesized CNAME + + + + + + + + + + + + + + +Rose & Wijngaards Standards Track [Page 15] + +RFC 6672 DNAME Redirection June 2012 + + +5.3.4.3. Response with Synthesized CNAME ;; Header: QR AA RCODE=0(NOERROR) ;; OPT PSEUDOSECTION: @@ -820,27 +863,117 @@ Internet-Draft DNAME Redirection April 2010 an attacker to be foo.bar.example.com CNAME bla.bla.example. The DNAME record does have its signature included, since it does not change. The validator must verify the DNAME signature and then - recursively resolve further to query for the foo.bar.example.net A - record. + recursively resolve further in order to query for the + foo.bar.example.net A record. + +6. Examples of DNAME Use in a Zone + + Below are some examples of the use of DNAME in a zone. These + examples are by no means exhaustive. + +6.1. Organizational Renaming + + If an organization with domain name FROBOZZ.EXAMPLE.NET became part + of an organization with domain name ACME.EXAMPLE.COM, it might ease + transition by placing information such as this in its old zone. + + frobozz.example.net. DNAME frobozz-division.acme.example.com. + MX 10 mailhub.acme.example.com. + + The response to an extended recursive query for + www.frobozz.example.net would contain, in the answer section, the + DNAME record shown above and the relevant RRs for www.frobozz- + division.acme.example.com. + + If an organization wants to have aliases for names, for a different + spelling or language, the same example applies. Note that the MX RR + at the zone apex is not redirected and has to be repeated in the + target zone. Also note that the services at mailhub or www.frobozz- + division.acme.example.com. have to recognize and handle the aliases. + + + + + +Rose & Wijngaards Standards Track [Page 16] + +RFC 6672 DNAME Redirection June 2012 + + +6.2. Classless Delegation of Shorter Prefixes + + The classless scheme for in-addr.arpa delegation [RFC2317] can be + extended to prefixes shorter than 24 bits by use of the DNAME record. + For example, the prefix 192.0.8.0/22 can be delegated by the + following records. + + $ORIGIN 0.192.in-addr.arpa. + 8/22 NS ns.slash-22-holder.example.com. + 8 DNAME 8.8/22 + 9 DNAME 9.8/22 + 10 DNAME 10.8/22 + 11 DNAME 11.8/22 + + A typical entry in the resulting reverse zone for some host with + address 192.0.9.33 might be as follows: + + $ORIGIN 8/22.0.192.in-addr.arpa. + 33.9 PTR somehost.slash-22-holder.example.com. + + The advisory remarks in [RFC2317] concerning the choice of the "/" + character apply here as well. + +6.3. Network Renumbering Support + + If IPv4 network renumbering were common, maintenance of address space + delegation could be simplified by using DNAME records instead of NS + records to delegate. + + $ORIGIN new-style.in-addr.arpa. + 189.190 DNAME in-addr.example.net. + + $ORIGIN in-addr.example.net. + 188 DNAME in-addr.customer.example.com. + + $ORIGIN in-addr.customer.example. + 1 PTR www.customer.example.com + 2 PTR mailhub.customer.example.com. + ; etc ... + + This would allow the address space 190.189.0.0/16 assigned to the ISP + "example.net" to be changed without having to alter the zone data + describing the use of that space by the ISP and its customers. + -6. IANA Considerations - The DNAME Resource Record type code 39 (decimal) originally has been - registered by [RFC2672]. IANA should update the DNS resource record - registry to point to this document for RR type 39. -7. Security Considerations - DNAME redirects queries elsewhere, which may impact security based on - policy and the security status of the zone with the DNAME and the -Rose & Wijngaards Expires October 22, 2010 [Page 15] +Rose & Wijngaards Standards Track [Page 17] -Internet-Draft DNAME Redirection April 2010 +RFC 6672 DNAME Redirection June 2012 + Renumbering IPv4 networks is currently so arduous a task that + updating the DNS is only a small part of the labor, so this scheme + may have a low value. But it is hoped that in IPv6 the renumbering + task will be quite different, and the DNAME mechanism may play a + useful part. + +7. IANA Considerations + + The DNAME resource record type code 39 (decimal) originally was + registered by [RFC2672] in the DNS Resource Record (RR) Types + registry table at http://www.iana.org/assignments/dns-parameters. + IANA has updated the DNS resource record registry to point to this + document for RR type 39. + +8. Security Considerations + + DNAME redirects queries elsewhere, which may impact security based on + policy and the security status of the zone with the DNAME and the redirection zone's security status. For validating resolvers, the lowest security status of the links in the chain of CNAME and DNAME redirections is applied to the result. @@ -855,18 +988,33 @@ Internet-Draft DNAME Redirection April 2010 A validating resolver MUST understand DNAME, according to [RFC4034]. The examples in Section 5.3.4 illustrate this need. -8. Acknowledgments +9. Acknowledgments - The authors of this draft would like to acknowledge Matt Larson for - beginning this effort to address the issues related to the DNAME RR - type. The authors would also like to acknowledge Paul Vixie, Ed + The authors of this document would like to acknowledge Matt Larson + for beginning this effort to address the issues related to the DNAME + RR type. The authors would also like to acknowledge Paul Vixie, Ed Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred - Hoenes and Kevin Darcy for their review and comments on this + Hoenes, and Kevin Darcy for their reviews and comments on this document. -9. References -9.1. Normative References + + + + + + + + + +Rose & Wijngaards Standards Track [Page 18] + +RFC 6672 DNAME Redirection June 2012 + + +10. References + +10.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. @@ -884,19 +1032,14 @@ Internet-Draft DNAME Redirection April 2010 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. + [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- + ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - - - -Rose & Wijngaards Expires October 22, 2010 [Page 16] - -Internet-Draft DNAME Redirection April 2010 - - (RR) Types", RFC 3597, September 2003. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. @@ -918,7 +1061,14 @@ Internet-Draft DNAME Redirection April 2010 Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. -9.2. Informative References + + +Rose & Wijngaards Standards Track [Page 19] + +RFC 6672 DNAME Redirection June 2012 + + +10.2. Informative References [RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996. @@ -931,14 +1081,91 @@ Internet-Draft DNAME Redirection April 2010 Addresses in the Domain Name System (DNS)", RFC 3363, August 2002. - [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, - April 2006. + [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in Applications + (IDNA)", RFC 3492, March 2003. + + [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node + Requirements", RFC 6434, December 2011. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose & Wijngaards Standards Track [Page 20] + +RFC 6672 DNAME Redirection June 2012 + + +Appendix A. Changes from RFC 2672 + +A.1. Changes to Server Behavior + + Major changes to server behavior from the original DNAME + specification are summarized below: + + o The rules for DNAME substitution have been clarified in + Section 2.2. + + o The EDNS option to signal DNAME understanding and compression has + never been specified, and this document clarifies that there is no + signaling method (Section 2.5). + + o The TTL for synthesized CNAME RRs is now set to the TTL of the + DNAME, not zero (Section 3.1). + + o Recursive caching servers MUST perform CNAME synthesis on behalf + of clients (Section 3.4). + + o The revised server algorithm is detailed in Section 3.2. + o Rules for dynamic update messages adding a DNAME or CNAME RR to a + zone where a CNAME or DNAME already exists are detailed in + Section 5.2. +A.2. Changes to Client Behavior + Major changes to client behavior from the original DNAME + specification are summarized below: + o Clients MUST be able to accept synthesized CNAME RR's with a TTL + of either zero or the TTL of the DNAME RR that accompanies the + CNAME RR. + o DNSSEC-aware clients SHOULD cache DNAME RRs and MAY cache + synthesized CNAME RRs they receive in the same response. DNSSEC- + aware clients SHOULD also check the NSEC/NSEC3 type bitmap to + verify that DNAME redirection is to be done. DNSSEC validators + MUST understand DNAME (Section 5.3). + o The revised client algorithm is detailed in Section 3.4.1. @@ -948,9 +1175,9 @@ Internet-Draft DNAME Redirection April 2010 -Rose & Wijngaards Expires October 22, 2010 [Page 17] +Rose & Wijngaards Standards Track [Page 21] -Internet-Draft DNAME Redirection April 2010 +RFC 6672 DNAME Redirection June 2012 Authors' Addresses @@ -963,13 +1190,13 @@ Authors' Addresses Phone: +1-301-975-8439 Fax: +1-301-975-6238 - EMail: scottr.nist@gmail.com + EMail: scott.rose@nist.gov Wouter Wijngaards NLnet Labs Science Park 140 - Amsterdam 1098 XG + Amsterdam 1098 XH The Netherlands Phone: +31-20-888-4551 @@ -1004,5 +1231,5 @@ Authors' Addresses -Rose & Wijngaards Expires October 22, 2010 [Page 18] +Rose & Wijngaards Standards Track [Page 22] diff --git a/doc/draft/draft-ietf-dane-protocol-19.txt b/doc/rfc/rfc6698.txt similarity index 54% rename from doc/draft/draft-ietf-dane-protocol-19.txt rename to doc/rfc/rfc6698.txt index ebfc2b74a4b..95e7cf4f5cd 100644 --- a/doc/draft/draft-ietf-dane-protocol-19.txt +++ b/doc/rfc/rfc6698.txt @@ -1,42 +1,41 @@ -Network Working Group P. Hoffman -Internet-Draft VPN Consortium -Intended status: Standards Track J. Schlyter -Expires: October 13, 2012 Kirei AB - April 11, 2012 - The DNS-Based Authentication of Named Entities (DANE) Protocol for - Transport Layer Security (TLS) - draft-ietf-dane-protocol-19 + +Internet Engineering Task Force (IETF) P. Hoffman +Request for Comments: 6698 VPN Consortium +Category: Standards Track J. Schlyter +ISSN: 2070-1721 Kirei AB + August 2012 + + + The DNS-Based Authentication of Named Entities (DANE) + Transport Layer Security (TLS) Protocol: TLSA Abstract - Encrypted communication on the Internet often uses Transport Level + Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. -Status of this Memo +Status of This Memo - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. + This is an Internet Standards Track document. - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. - 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." - - This Internet-Draft will expire on October 13, 2012. + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6698. Copyright Notice @@ -49,147 +48,101 @@ Copyright Notice publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 1] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Background of the Problem . . . . . . . . . . . . . . . . 4 - 1.2. Securing the Association with a Server's Certificate . . . 5 - 1.3. Method For Securing Certificate Associations . . . . . . . 6 - 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 - 2. The TLSA Resource Record . . . . . . . . . . . . . . . . . . . 7 - 2.1. TLSA RDATA Wire Format . . . . . . . . . . . . . . . . . . 7 - 2.1.1. The Certificate Usage Field . . . . . . . . . . . . . 8 - 2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 9 - 2.1.3. The Matching Type Field . . . . . . . . . . . . . . . 9 - 2.1.4. The Certificate Association Data Field . . . . . . . . 10 - 2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 10 - 2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 10 - 3. Domain Names for TLS Certificate Associations . . . . . . . . 11 - 4. Use of TLSA Records in TLS . . . . . . . . . . . . . . . . . . 11 - 5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 13 - 6. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 15 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 15 - 7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 15 - 7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 16 - 7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 16 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 8.1. Comparing DANE to Public CAs . . . . . . . . . . . . . . . 18 - 8.2. DNS Caching . . . . . . . . . . . . . . . . . . . . . . . 19 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 - Appendix A. Operational Considerations for Deploying TLSA - Records . . . . . . . . . . . . . . . . . . . . . . . 21 - A.1. Creating TLSA Records . . . . . . . . . . . . . . . . . . 21 - A.1.1. Ambiguities and Corner Cases When TLS Clients - Build Trust Chains . . . . . . . . . . . . . . . . . . 22 - A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 23 - A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 24 - A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 24 - A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 27 - A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 27 - Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 28 - B.1. Helper Functions . . . . . . . . . . . . . . . . . . . . . 28 - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 2] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - - B.2. Main TLSA Pseudo Code . . . . . . . . . . . . . . . . . . 29 - Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 31 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +Hoffman & Schlyter Standards Track [Page 1] + +RFC 6698 DNS-Based Authentication for TLS August 2012 +Table of Contents -Hoffman & Schlyter Expires October 13, 2012 [Page 3] + 1. Introduction ....................................................3 + 1.1. Background and Motivation ..................................3 + 1.2. Securing the Association of a Domain Name with a + Server's Certificate .......................................4 + 1.3. Method for Securing Certificate Associations ...............5 + 1.4. Terminology ................................................6 + 2. The TLSA Resource Record ........................................7 + 2.1. TLSA RDATA Wire Format .....................................7 + 2.1.1. The Certificate Usage Field .........................7 + 2.1.2. The Selector Field ..................................8 + 2.1.3. The Matching Type Field .............................9 + 2.1.4. The Certificate Association Data Field ..............9 + 2.2. TLSA RR Presentation Format ................................9 + 2.3. TLSA RR Examples ..........................................10 + 3. Domain Names for TLSA Certificate Associations .................10 + 4. Use of TLSA Records in TLS .....................................11 + 4.1. Usable Certificate Associations ...........................11 + 5. TLSA and DANE Use Cases and Requirements .......................13 + 6. Mandatory-to-Implement Features ................................15 + 7. IANA Considerations ............................................15 + 7.1. TLSA RRtype ...............................................15 + 7.2. TLSA Certificate Usages ...................................15 + 7.3. TLSA Selectors ............................................16 + 7.4. TLSA Matching Types .......................................16 + 8. Security Considerations ........................................16 + 8.1. Comparing DANE to Public CAs ..............................18 + 8.1.1. Risk of Key Compromise .............................19 + 8.1.2. Impact of Key Compromise ...........................20 + 8.1.3. Detection of Key Compromise ........................20 + 8.1.4. Spoofing Hostnames .................................20 + 8.2. DNS Caching ...............................................21 + 8.3. External DNSSEC Validators ................................21 + 9. Acknowledgements ...............................................22 + 10. References ....................................................22 + 10.1. Normative References .....................................22 + 10.2. Informative References ...................................23 + Appendix A. Operational Considerations for Deploying TLSA + Records ...............................................25 + A.1. Creating TLSA Records ......................................25 + A.1.1. Ambiguities and Corner Cases When TLS Clients + Build Trust Chains .....................................26 + A.1.2. Choosing a Selector Type ...............................26 + A.2. Provisioning TLSA Records in DNS ...........................28 + A.2.1. Provisioning TLSA Records with Aliases .................28 + A.3. Securing the Last Hop ......................................30 + A.4. Handling Certificate Rollover ..............................31 + + + +Hoffman & Schlyter Standards Track [Page 2] -Internet-Draft DNS-Based Authentication for TLS April 2012 +RFC 6698 DNS-Based Authentication for TLS August 2012 + + Appendix B. Pseudocode for Using TLSA .............................32 + B.1. Helper Functions ...........................................32 + B.2. Main TLSA Pseudocode .......................................33 + Appendix C. Examples ..............................................35 1. Introduction -1.1. Background of the Problem +1.1. Background and Motivation Applications that communicate over the Internet often need to prevent eavesdropping, tampering, or forgery of their communications. The Transport Layer Security (TLS) protocol provides this kind of - communications security over the Internet, using encryption. + communications security over the Internet, using channel encryption. The security properties of encryption systems depend strongly on the keys that they use. If secret keys are revealed, or if public keys - can be replaced by bogus keys, these systems provide little or no - security. + can be replaced by fake keys (that is, a key not corresponding to the + entity identified in the certificate), these systems provide little + or no security. TLS uses certificates to bind keys and names. A certificate combines a published key with other information such as the name of the service that uses the key, and this combination is digitally signed - by another key. Having a certificate for a key is only helpful if - one trusts the other key that signed the certificate. If that other - key was itself revealed or substituted, then its signature is - worthless in proving anything about the first key. + by another key. Having a key in a certificate is only helpful if one + trusts the other key that signed the certificate. If that other key + was itself revealed or substituted, then its signature is worthless + in proving anything about the first key. On the Internet, this problem has been solved for years by entities called "Certification Authorities" (CAs). CAs protect their secret @@ -204,27 +157,28 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 vulnerable because it allows any of these CAs to issue a certificate for any domain name. A single trusted CA that betrays its trust, either voluntarily or by providing less-than-vigorous protection for - its secrets and capabilities, can compromise any other certificate - that TLS uses, by signing a replacement certificate that contains a - bogus key. Recent experiences with compromises of CAs or their - trusted partners have lead to very serious security problems, such as - the subversion of major web sites trusted by millions of users. + its secrets and capabilities, can undermine the security offered by + any certificates employed with TLS. This problem arises because a + compromised CA can issue a replacement certificate that contains a + fake key. Recent experiences with compromises of CAs or their + trusted partners have led to very serious security problems, such as + the governments of multiple countries attempting to wiretap and/or + subvert major TLS-protected web sites trusted by millions of users. + + - The DNS Security Extensions (DNSSEC) provides a similar model that +Hoffman & Schlyter Standards Track [Page 3] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + + The DNS Security Extensions (DNSSEC) provide a similar model that involves trusted keys signing the information for untrusted keys. However, DNSSEC provides three significant improvements. Keys are tied to names in the Domain Name System (DNS), rather than to arbitrary identifying strings; this is more convenient for Internet protocols. Signed keys for any domain are accessible online through a straightforward query using the standard DNSSEC protocol, so there - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 4] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - is no problem distributing the signed keys. Most significantly, the keys associated with a domain name can only be signed by a key associated with the parent of that domain name; for example, the keys @@ -247,23 +201,33 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 DNS hierarchy. As a result, DANE embodies the security "principle of least privilege" that is lacking in the current public CA model. -1.2. Securing the Association with a Server's Certificate +1.2. Securing the Association of a Domain Name with a Server's + Certificate A TLS client begins a connection by exchanging messages with a TLS - server. It looks up the server's name using the DNS to get an - Internet Protocol (IP) address associated with the name. It then - begins a connection to a client-chosen port at that address, and - sends an initial message there. However, the client does not yet - know whether an adversary is intercepting and/or altering its - communication before it reaches the TLS server. It does not even - know whether the real TLS server associated with that domain name has - ever received its initial messages. + server. For many application protocols, it looks up the server's + name using the DNS to get an Internet Protocol (IP) address + associated with the name. It then begins a connection to a + particular port at that address, and sends an initial message there. + However, the client does not yet know whether an adversary is + intercepting and/or altering its communication before it reaches the + TLS server. It does not even know whether the real TLS server + associated with that domain name has ever received its initial + messages. The first response from the server in TLS may contain a certificate. In order for the TLS client to authenticate that it is talking to the expected TLS server, the client must validate that this certificate is associated with the domain name used by the client to get to the server. Currently, the client must extract the domain name from the + + + +Hoffman & Schlyter Standards Track [Page 4] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + certificate and must successfully validate the certificate, including chaining to a trust anchor. @@ -273,14 +237,6 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 is authorized to give identifying information about the zone, it makes sense to allow that administrator to also make an authoritative binding between the domain name and a certificate that might be used - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 5] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - by a host at that domain name. The easiest way to do this is to use the DNS, securing the binding with DNSSEC. @@ -288,36 +244,56 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 ones to which the DNS RRtype in this document apply. [RFC6394] also lists many requirements, most of which this document is believed to meet. Section 5 covers the applicability of this document to the use - cases in detail. + cases in detail. The protocol in this document can generally be + referred to as the "DANE TLSA" protocol. ("TLSA" does not stand for + anything; it is just the name of the RRtype.) + + This document applies to both TLS [RFC5246] and Datagram TLS (DTLS) + [RFC6347]. In order to make the document more readable, it mostly + only talks about "TLS", but in all cases, it means "TLS or DTLS". + Although the references in this paragraph are to TLS and DTLS + version 1.2, the DANE TLSA protocol can also be used with earlier + versions of TLS and DTLS. - This document applies to both TLS [RFC5246] and DTLS [RFC6347]. In - order to make the document more readable, it mostly only talks about - "TLS", but in all cases, it means "TLS or DTLS". This document only - relates to securely associating certificates for TLS and DTLS with - host names; other security protocols and other forms of - identification of TLS servers (such as IP addresses) are handled in - other documents. For example, keys for IPsec are covered in - [RFC4025] and keys for SSH are covered in [RFC4255]. + This document only relates to securely associating certificates for + TLS and DTLS with host names; retrieving certificates from DNS for + other protocols is handled in other documents. For example, keys for + IPsec are covered in [RFC4025], and keys for Secure SHell (SSH) are + covered in [RFC4255]. -1.3. Method For Securing Certificate Associations +1.3. Method for Securing Certificate Associations A certificate association is formed from a piece of information - identifying a certificate and the domain name where the data is - found. The combination of a trust anchor and a domain name can also - be a certificate association. + identifying a certificate and the domain name where the server + application runs. The combination of a trust anchor and a domain + name can also be a certificate association. A DNS query can return multiple certificate associations, such as in - the case of a server is changing from one certificate to another. + the case of a server that is changing from one certificate to another + (described in more detail in Appendix A.4). This document only applies to PKIX [RFC5280] certificates, not certificates of other formats. + + + + +Hoffman & Schlyter Standards Track [Page 5] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + This document defines a secure method to associate the certificate that is obtained from the TLS server with a domain name using DNS; - the DNS information needs to be be protected by DNSSEC. Because the + the DNS information needs to be protected by DNSSEC. Because the certificate association was retrieved based on a DNS query, the domain name in the query is by definition associated with the - certificate. + certificate. Note that this document does not cover how to associate + certificates with domain names for application protocols that depend + on SRV, NAPTR, and similar DNS resource records. It is expected that + future documents will cover methods for making those associations, + and those documents may or may not need to update this one. DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses cryptographic keys and digital signatures to provide authentication @@ -329,14 +305,6 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 This document does not specify how DNSSEC validation occurs because there are many different proposals for how a client might get validated DNSSEC results, such as from a DNSSEC-aware resolver that - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 6] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - is coded in the application, from a trusted DNSSEC resolver on the machine on which the application is running, or from a trusted DNSSEC resolver with which the application is communicating over an @@ -354,49 +322,47 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 document are to be interpreted as described in RFC 2119 [RFC2119]. This document also makes use of standard PKIX, DNSSEC, TLS, and DNS - terminology. See [RFC5280], [RFC4033], [RFC5246], and [STD13] - respectively, for these terms. In addition, terms related to TLS- - protected application services and DNS names are taken from - [RFC6125]. + terminology. See [RFC5280], [RFC4033], [RFC5246], and STD 13 + [RFC1034] [RFC1035], respectively, for these terms. In addition, + terms related to TLS-protected application services and DNS names are + taken from [RFC6125]. -2. The TLSA Resource Record - The TLSA DNS resource record (RR) is used to associate a certificate - with the domain name where the record is found. The semantics of how - the TLSA RR is interpreted are given later in this document. - The type value for the TLSA RR type is defined in Section 7.1. - The TLSA RR is class independent. - - The TLSA RR has no special TTL requirements. - -2.1. TLSA RDATA Wire Format - - The RDATA for a TLSA RR consists of a one octet usage type field, a - one octet selector field, a one octet matching type field and the - certificate association data field. +Hoffman & Schlyter Standards Track [Page 6] + +RFC 6698 DNS-Based Authentication for TLS August 2012 +2. The TLSA Resource Record + The TLSA DNS resource record (RR) is used to associate a TLS server + certificate or public key with the domain name where the record is + found, thus forming a "TLSA certificate association". The semantics + of how the TLSA RR is interpreted are given later in this document. + The type value for the TLSA RR type is defined in Section 7.1. + The TLSA RR is class independent. + The TLSA RR has no special Time to Live (TTL) requirements. -Hoffman & Schlyter Expires October 13, 2012 [Page 7] - -Internet-Draft DNS-Based Authentication for TLS April 2012 +2.1. TLSA RDATA Wire Format + The RDATA for a TLSA RR consists of a one-octet certificate usage + field, a one-octet selector field, a one-octet matching type field, + and the certificate association data field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Usage | Selector | Matching Type | / + | Cert. Usage | Selector | Matching Type | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / / Certificate Association Data / @@ -405,86 +371,96 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 2.1.1. The Certificate Usage Field - A one-octet value, called "certificate usage" or just "usage", - specifies the provided association that will be used to match the - target certificate from the TLS handshake. This value is defined in - a new IANA registry (see Section 7.2) in order to make it easier to - add additional certificate usages in the future. The usages defined - in this document are: + A one-octet value, called "certificate usage", specifies the provided + association that will be used to match the certificate presented in + the TLS handshake. This value is defined in a new IANA registry (see + Section 7.2) in order to make it easier to add additional certificate + usages in the future. The certificate usages defined in this + document are: 0 -- Certificate usage 0 is used to specify a CA certificate, or the public key of such a certificate, that MUST be found in any of the PKIX certification paths for the end entity certificate given - by the server in TLS. This usage is sometimes referred to as "CA - constraint" because it limits which CA can be used to issue - certificates for a given service on a host. The target - certificate MUST pass PKIX certification path validation and a CA - certificate that matches the TLSA record MUST be included as part - of a valid certification path. Because this usage allows both - trust anchors and CA certificates, the certificate might or might - not have the basicConstraints extension present. + by the server in TLS. This certificate usage is sometimes + referred to as "CA constraint" because it limits which CA can be + used to issue certificates for a given service on a host. The + presented certificate MUST pass PKIX certification path + validation, and a CA certificate that matches the TLSA record MUST + be included as part of a valid certification path. Because this + certificate usage allows both trust anchors and CA certificates, - 1 -- Certificate usage 1 is used to specify an end entity - certificate, or the public key of such a certificate, that must be - matched with the end entity certificate given by the server in - TLS. This usage is sometimes referred to as "service certificate - constraint" because it limits which end entity certificate can be - used by a given service on a host. The target certificate MUST - pass PKIX certification path validation and MUST match the TLSA - record. - 2 -- Certificate usage 2 is used to specify a certificate, or the - public key of such a certificate, that must be used as the trust - anchor when validating the end entity certificate given by the - server in TLS. This usage is sometimes referred to as "trust - anchor assertion" and allows a domain name administrator to - specify a new trust anchor. For example, if the domain issues its - own certificates under its own CA that is not expected to be in - the end users' collection of trust anchors. The target +Hoffman & Schlyter Standards Track [Page 7] + +RFC 6698 DNS-Based Authentication for TLS August 2012 -Hoffman & Schlyter Expires October 13, 2012 [Page 8] - -Internet-Draft DNS-Based Authentication for TLS April 2012 + the certificate might or might not have the basicConstraints + extension present. + 1 -- Certificate usage 1 is used to specify an end entity + certificate, or the public key of such a certificate, that MUST be + matched with the end entity certificate given by the server in + TLS. This certificate usage is sometimes referred to as "service + certificate constraint" because it limits which end entity + certificate can be used by a given service on a host. The target + certificate MUST pass PKIX certification path validation and MUST + match the TLSA record. + 2 -- Certificate usage 2 is used to specify a certificate, or the + public key of such a certificate, that MUST be used as the trust + anchor when validating the end entity certificate given by the + server in TLS. This certificate usage is sometimes referred to as + "trust anchor assertion" and allows a domain name administrator to + specify a new trust anchor -- for example, if the domain issues + its own certificates under its own CA that is not expected to be + in the end users' collection of trust anchors. The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation. 3 -- Certificate usage 3 is used to specify a certificate, or the - public key of such a certificate, that must match the end entity - certificate given by the server in TLS. This usage is sometimes - referred to as "domain-issued certificate" because it allows for a - domain name administrator to issue certificates for a domain - without involving a third-party CA. The target certificate MUST - match the TLSA record. The difference between certificate usage 1 - and certificate usage 3 is that certificate usage 1 requires that - the certificate pass PKIX validation, but PKIX validation is not - tested for certificate usage 3. + public key of such a certificate, that MUST match the end entity + certificate given by the server in TLS. This certificate usage is + sometimes referred to as "domain-issued certificate" because it + allows for a domain name administrator to issue certificates for a + domain without involving a third-party CA. The target certificate + MUST match the TLSA record. The difference between certificate + usage 1 and certificate usage 3 is that certificate usage 1 + requires that the certificate pass PKIX validation, but PKIX + validation is not tested for certificate usage 3. The certificate usages defined in this document explicitly only apply - to PKIX-formatted certificates in DER encoding. If TLS allows other - formats later, or if extensions to this RRtype are made that accept - other formats for certificates, those certificates will need their - own certificate usage values. + to PKIX-formatted certificates in DER encoding [X.690]. If TLS + allows other formats later, or if extensions to this RRtype are made + that accept other formats for certificates, those certificates will + need their own certificate usage values. 2.1.2. The Selector Field A one-octet value, called "selector", specifies which part of the TLS certificate presented by the server will be matched against the association data. This value is defined in a new IANA registry (see - Section 7.3. The selectors defined in this document are: + Section 7.3). The selectors defined in this document are: - 0 -- Full certificate - 1 -- SubjectPublicKeyInfo - The SubjectPublicKeyInfo is a binary structure defined in [RFC5280]. + +Hoffman & Schlyter Standards Track [Page 8] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + + 0 -- Full certificate: the Certificate binary structure as defined + in [RFC5280] + + 1 -- SubjectPublicKeyInfo: DER-encoded binary structure as defined + in [RFC5280] (Note that the use of "selector" in this document is completely - unrelated to the use of "selector" in DKIM [RFC6376].) + unrelated to the use of "selector" in DomainKeys Identified Mail + (DKIM) [RFC6376].) 2.1.3. The Matching Type Field @@ -497,14 +473,6 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 1 -- SHA-256 hash of selected content [RFC6234] - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 9] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - 2 -- SHA-512 hash of selected content [RFC6234] If the TLSA record's matching type is a hash, having the record use @@ -514,29 +482,38 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 2.1.4. The Certificate Association Data Field - The "certificate association data" to be matched. This field - contains the data to be matched. These bytes are either raw data - (that is, the full certificate or its SubjectPublicKeyInfo, depending - on the selector) for matching type 0, or the hash of the raw data for - matching types 1 and 2. The data refers to the certificate in the - association, not to the TLS ASN.1 Certificate object. + This field specifies the "certificate association data" to be + matched. These bytes are either raw data (that is, the full + certificate or its SubjectPublicKeyInfo, depending on the selector) + for matching type 0, or the hash of the raw data for matching types 1 + and 2. The data refers to the certificate in the association, not to + the TLS ASN.1 Certificate object. 2.2. TLSA RR Presentation Format - The presentation format of the RDATA portion is as follows: + The presentation format of the RDATA portion (as defined in + [RFC1035]) is as follows: o The certificate usage field MUST be represented as an 8-bit - unsigned decimal integer. + unsigned integer. o The selector field MUST be represented as an 8-bit unsigned - decimal integer. + integer. + + + + +Hoffman & Schlyter Standards Track [Page 9] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + o The matching type field MUST be represented as an 8-bit unsigned - decimal integer. + integer. o The certificate association data field MUST be represented as a string of hexadecimal characters. Whitespace is allowed within - the string of hexadecimal characters. + the string of hexadecimal characters, as described in [RFC1035]. 2.3. TLSA RR Examples @@ -553,14 +530,6 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 An example of a hashed (SHA-512) subject public key association of a PKIX end entity certificate: - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 10] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - _443._tcp.www.example.com. IN TLSA ( 1 1 2 92003ba34942dc74152e2f2c408d29ec a5a520e7f2e06bb944f4dca346baf63c @@ -573,8 +542,7 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 _443._tcp.www.example.com. IN TLSA ( 3 0 0 30820307308201efa003020102020... ) - -3. Domain Names for TLS Certificate Associations +3. Domain Names for TLSA Certificate Associations Unless there is a protocol-specific specification that is different than this one, TLSA resource records are stored at a prefixed DNS @@ -585,14 +553,30 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 character ("_") to become the left-most label in the prepared domain name. This number has no leading zeros. + + + + + + +Hoffman & Schlyter Standards Track [Page 10] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + 2. The protocol name of the transport on which a TLS-based service is assumed to exist is prepended with an underscore character ("_") to become the second left-most label in the prepared domain name. The transport names defined for this protocol are "tcp", - "udp" and "sctp". + "udp", and "sctp". - 3. The domain name is appended to the result of step 2 to complete - the prepared domain name. + 3. The base domain name is appended to the result of step 2 to + complete the prepared domain name. The base domain name is the + fully qualified DNS domain name [RFC1035] of the TLS server, with + the additional restriction that every label MUST meet the rules + of [RFC0952]. The latter restriction means that, if the query is + for an internationalized domain name, it MUST use the A-label + form as defined in [RFC5890]. For example, to request a TLSA resource record for an HTTP server running TLS on port 443 at "www.example.com", @@ -601,7 +585,6 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is used. - 4. Use of TLSA Records in TLS Section 2.1 of this document defines the mandatory matching rules for @@ -609,55 +592,59 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 received from the TLS server. The TLS session that is to be set up MUST be for the specific port - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 11] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - number and transport name that was given in the TLSA query. Some specifications for applications that run over TLS, such as - [RFC2818] for HTTP, require the server's certificate to have a domain - name that matches the host name expected by the client. Some - specifications such as [RFC6125] detail how to match the identity + [RFC2818] for HTTP, require that the server's certificate have a + domain name that matches the host name expected by the client. Some + specifications, such as [RFC6125], detail how to match the identity given in a PKIX certificate with those expected by the user. + If a TLSA record has certificate usage 2, the corresponding TLS + server SHOULD send the certificate that is referenced just like it + currently sends intermediate certificates. + +4.1. Usable Certificate Associations + An implementation of this protocol makes a DNS query for TLSA records, validates these records using DNSSEC, and uses the resulting TLSA records and validation status to modify its responses to the TLS server. - If a TLSA record has usage type 2 for the certifcate, the - corresponding TLS server SHOULD send the certificate that is - referenced just like it currently sends intermediate certificates. - Determining whether a TLSA RRset can be used MUST be based on the + + + +Hoffman & Schlyter Standards Track [Page 11] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + + Determining whether a TLSA RRSet can be used MUST be based on the DNSSEC validation state (as defined in [RFC4033]). - o A TLSA RRset whose DNSSEC validation state is secure MUST be used + o A TLSA RRSet whose DNSSEC validation state is secure MUST be used as a certificate association for TLS unless a local policy would prohibit the use of the specific certificate association in the - secure TLSA RRset. + secure TLSA RRSet. o If the DNSSEC validation state on the response to the request for - the TLSA RRset is bogus, this MUST cause TLS not to be started or, + the TLSA RRSet is bogus, this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, MUST cause the connection to be aborted. - o A TLSA RRset whose DNSSEC validation state is indeterminate or + o A TLSA RRSet whose DNSSEC validation state is indeterminate or insecure cannot be used for TLS and MUST be considered unusable. - Clients which validate the DNSSEC signatures themselves MUST use + Clients that validate the DNSSEC signatures themselves MUST use standard DNSSEC validation procedures. Clients that rely on another entity to perform the DNSSEC signature validation MUST use a secure mechanism between themselves and the validator. Examples of secure transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec [RFC6071]. Note that it is not sufficient to use secure transport to a DNS resolver that does not do DNSSEC signature - validation. + validation. See Section 8.3 for more security considerations related + to external validators. If a certificate association contains a certificate usage, selector, or matching type that is not understood by the TLS client, that @@ -665,14 +652,6 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 comparison data for a certificate is malformed, the certificate association MUST be considered unusable. - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 12] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - If a certificate association contains a matching type or certificate association data that uses a cryptographic algorithm that is considered too weak for the TLS client's policy, the certificate @@ -689,77 +668,101 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 handshake. + + + +Hoffman & Schlyter Standards Track [Page 12] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + + An attacker who is able to divert a user to a server under his + control is also likely to be able to block DNS requests from the user + or DNS responses being sent to the user. Thus, in order to achieve + any security benefit from certificate usage 0 or 1, an application + that sends a request for TLSA records needs to get either a valid + signed response containing TLSA records or verification that the + domain is insecure or indeterminate. If a request for a TLSA record + does not meet one of those two criteria but the application continues + with the TLS handshake anyway, the application has gotten no benefit + from TLSA and SHOULD NOT make any internal or external indication + that TLSA was applied. If an application has a configuration setting + that has turned on TLSA use, or has any indication that TLSA is in + use (regardless of whether or not this is configurable), that + application either MUST NOT start a TLS connection or it MUST abort a + TLS handshake if both of the two criteria above are not met. + + The application can perform the TLSA lookup before initiating the TLS + handshake, or do it during the TLS handshake: the choice is up to the + client. + 5. TLSA and DANE Use Cases and Requirements The different types of certificate associations defined in TLSA are matched with various sections of [RFC6394]. The use cases from Section 3 of [RFC6394] are covered in this document as follows: - 3.1 CA Constraints -- Implemented using certificate usage 0. + 3.1 CA Constraints -- Implemented using certificate usage 0. - 3.2 Certificate Constraints -- Implemented using certificate usage - 1. + 3.2 Certificate Constraints -- Implemented using certificate usage 1. - 3.3 Trust Anchor Assertion and Domain-Issued Certificates -- + 3.3 Trust Anchor Assertion and Domain-Issued Certificates -- Implemented using certificate usages 2 and 3, respectively. The requirements from Section 4 of [RFC6394] are covered in this document as follows: - Multiple Ports -- The TLSA records for different application - services running on a single host can be distinguished through the - service name and port number prefixed to the host name (see - Section 3). + Multiple Ports -- The TLSA records for different application services + running on a single host can be distinguished through the service + name and port number prefixed to the host name (see Section 3). - No Downgrade -- Section 4 specifies the conditions under which a + No Downgrade -- Section 4 specifies the conditions under which a client can process and act upon TLSA records. Specifically, if the DNSSEC status for the TLSA resource record set is determined to be bogus, the TLS connection (if started) will fail. - Encapsulation -- Covered in the TLSA response semantics. - - - + Encapsulation -- Encapsulation is covered in the TLSA response + semantics. -Hoffman & Schlyter Expires October 13, 2012 [Page 13] +Hoffman & Schlyter Standards Track [Page 13] -Internet-Draft DNS-Based Authentication for TLS April 2012 +RFC 6698 DNS-Based Authentication for TLS August 2012 - Predictability -- The appendices of this specification provide + Predictability -- The appendices of this specification provide operational considerations and implementation guidance in order to enable application developers to form a consistent interpretation - of the recommended DANE client behavior. + of the recommended client behavior. - Opportunistic Security -- If a client conformant to this + Opportunistic Security -- If a client conformant to this specification can reliably determine the presence of a TLSA record, it will attempt to use this information. Conversely, if a client can reliably determine the absence of any TLSA record, it will fall back to processing TLS in the normal fashion. This is discussed in Section 4. - Combination -- Multiple TLSA records can be published for a given + Combination -- Multiple TLSA records can be published for a given host name, thus enabling the client to construct multiple TLSA - certificate associations that reflect different DANE assertions. - No support is provided to combine two TLSA certificate - associations in a single operation. + certificate associations that reflect different assertions. No + support is provided to combine two TLSA certificate associations + in a single operation. - Roll-over -- TLSA records are processed in the normal manner within - the scope of DNS protocol, including the TTL expiration of the + Roll-over -- TLSA records are processed in the normal manner within + the scope of the DNS protocol, including the TTL expiration of the records. This ensures that clients will not latch onto assertions made by expired TLSA records, and will be able to transition from - using one DANE public key or certificate usage type to another. + using one public key or certificate usage to another. - Simple Key Management -- The SubjectPublicKeyInfo selector in the + Simple Key Management -- The SubjectPublicKeyInfo selector in the TLSA record provides a mode that enables a domain holder to only have to maintain a single long-lived public/private key pair without the need to manage certificates. Appendix A outlines the usefulness and the potential downsides to using this mode. - Minimal Dependencies -- This specification relies on DNSSEC to + Minimal Dependencies -- This specification relies on DNSSEC to protect the origin authenticity and integrity of the TLSA resource record set. Additionally, if DNSSEC validation is not performed on the system that wishes to use TLSA certificate bindings, this @@ -767,102 +770,90 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 transport. There are no other deployment dependencies for this approach. - Minimal Options -- The operating modes map precisely to the DANE use + Minimal Options -- The operating modes map precisely to the DANE use cases and requirements. DNSSEC use is mandatory in that this specification encourages applications to use only those TLSA records that are shown to be validated. - Wild Cards -- Covered in a limited manner in the TLSA request - syntax; see Appendix A. + Wildcards -- Wildcards are covered in a limited manner in the TLSA + request syntax; see Appendix A. + Redirection -- Redirection is covered in the TLSA request syntax; see + Appendix A. - - -Hoffman & Schlyter Expires October 13, 2012 [Page 14] +Hoffman & Schlyter Standards Track [Page 14] -Internet-Draft DNS-Based Authentication for TLS April 2012 - - - Redirection -- Covered in the TLSA request syntax; see Appendix A. +RFC 6698 DNS-Based Authentication for TLS August 2012 6. Mandatory-to-Implement Features TLS clients conforming to this specification MUST be able to - correctly interpret TLSA records with certificate usages 0, 1, 2, and - 3. TLS clients conforming to this specification MUST be able to + correctly interpret TLSA records with certificate usages 0, 1, 2, + and 3. TLS clients conforming to this specification MUST be able to compare a certificate association with a certificate from the TLS handshake using selector types 0 and 1, and matching type 0 (no hash used) and matching type 1 (SHA-256), and SHOULD be able to make such comparisons with matching type 2 (SHA-512). - At the time this is written, it is expected that there will be a new - family of hash algorithms called SHA-3 within the next few years. It - is expected that some of the SHA-3 algorithms will be mandatory - and/or recommended for TLSA records after the algorithms are fully - defined. At that time, this specification will be updated. - - 7. IANA Considerations - IANA is requested to make the assignments in this section. IANA - might also consider making a "DANE" section in the main IANA registry - to help developers find related registries that might be created in - the future. + IANA has made the assignments in this section. - In the following sections, "RFC Required" was chosen for TLSA usages - and "Specification Required" for selectors and matching types because - of the amount of detail that is likely to be needed for implementers - to correctly implement new usages as compared to new selectors and - matching types. + In the following sections, "RFC Required" was chosen for TLSA + certificate usages and "Specification Required" for selectors and + matching types because of the amount of detail that is likely to be + needed for implementers to correctly implement new certificate usages + as compared to new selectors and matching types. 7.1. TLSA RRtype - This document uses a new DNS RR type, TLSA, whose value is TBD. A - separate request for the RR type will be submitted to the expert - reviewer, and future versions of this document will have that value - instead of TBD. + This document uses a new DNS RR type, TLSA, whose value (52) was + allocated by IANA from the Resource Record (RR) TYPEs subregistry of + the Domain Name System (DNS) Parameters registry. -7.2. TLSA Usages +7.2. TLSA Certificate Usages - This document creates a new registry, "Certificate Usages for TLSA - Resource Records". The registry policy is "RFC Required". The - initial entries in the registry are: + This document creates a new registry, "TLSA Certificate Usages". The + registry policy is "RFC Required". The initial entries in the + registry are: + Value Short description Reference + ---------------------------------------------------------- + 0 CA constraint RFC 6698 + 1 Service certificate constraint RFC 6698 + 2 Trust anchor assertion RFC 6698 + 3 Domain-issued certificate RFC 6698 + 4-254 Unassigned + 255 Private use + Applications to the registry can request specific values that have + yet to be assigned. -Hoffman & Schlyter Expires October 13, 2012 [Page 15] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - Value Short description Reference - ---------------------------------------------------------- - 0 CA constraint [This] - 1 Service certificate constraint [This] - 2 Trust anchor assertion [This] - 3 Domain-issued certificate [This] - 4-254 Unassigned - 255 Private use - Applications to the registry can request specific values that have - yet to be assigned. + +Hoffman & Schlyter Standards Track [Page 15] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + 7.3. TLSA Selectors - This document creates a new registry, "Selectors for TLSA Resource - Records". The registry policy is "Specification Required". The - initial entries in the registry are: + This document creates a new registry, "TLSA Selectors". The registry + policy is "Specification Required". The initial entries in the + registry are: Value Short description Reference ---------------------------------------------------------- - 0 Full Certificate [This] - 1 SubjectPublicKeyInfo [This] + 0 Full certificate RFC 6698 + 1 SubjectPublicKeyInfo RFC 6698 2-254 Unassigned 255 Private use @@ -871,99 +862,99 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 7.4. TLSA Matching Types - This document creates a new registry, "Matching Types for TLSA - Resource Records". The registry policy is "Specification Required". - The initial entries in the registry are: + This document creates a new registry, "TLSA Matching Types". The + registry policy is "Specification Required". The initial entries in + the registry are: - Value Short description Reference - -------------------------------------------------------- - 0 No hash used [This] - 1 SHA-256 RFC 6234 - 2 SHA-512 RFC 6234 + Value Short description Reference + ---------------------------------------------------------- + 0 No hash used RFC 6698 + 1 SHA-256 RFC 6234 + 2 SHA-512 RFC 6234 3-254 Unassigned 255 Private use Applications to the registry can request specific values that have yet to be assigned. +8. Security Considerations + The security of the DNS RRtype described in this document relies on + the security of DNSSEC to verify that the TLSA record has not been + altered. + A rogue DNS administrator who changes the A, AAAA, and/or TLSA + records for a domain name can cause the client to go to an + unauthorized server that will appear authorized, unless the client + performs PKIX certification path validation and rejects the + certificate. That administrator could probably get a certificate + issued by some CA anyway, so this is not an additional threat. -Hoffman & Schlyter Expires October 13, 2012 [Page 16] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - -8. Security Considerations - The security of the DNS RRtype described in this document relies on - the security of DNSSEC as used by the client requesting A/AAAA and - TLSA records. +Hoffman & Schlyter Standards Track [Page 16] + +RFC 6698 DNS-Based Authentication for TLS August 2012 - A DNS administrator who goes rogue and changes both the A/AAAA and - TLSA records for a domain name can cause the user to go to an - unauthorized server that will appear authorized, unless the client - performs PKIX certification path validation and rejects the - certificate. That administrator could probably get a certificate - issued by some CA anyway, so this is not an additional threat. If the authentication mechanism for adding or changing TLSA data in a - zone is weaker than the authentication mechanism for changing the - A/AAAA records, a man-in-the-middle who can redirect traffic to their - site may be able to impersonate the attacked host in TLS if they can - use the weaker authentication mechanism. A better design for + zone is weaker than the authentication mechanism for changing the A + and/or AAAA records, a man-in-the-middle who can redirect traffic to + his site may be able to impersonate the attacked host in TLS if he + can use the weaker authentication mechanism. A better design for authenticating DNS would be to have the same level of authentication used for all DNS additions and changes for a particular domain name. - SSL proxies can sometimes act as a man-in-the-middle for TLS clients. - In these scenarios, the clients add a new trust anchor whose private - key is kept on the SSL proxy; the proxy intercepts TLS requests, - creates a new TLS session with the intended host, and sets up a TLS - session with the client using a certificate that chains to the trust - anchor installed in the client by the proxy. In such environments, - using TLSA records will prevent the SSL proxy from functioning as - expected because the TLS client will get a certificate association - from the DNS that will not match the certificate that the SSL proxy - uses with the client. The client, seeing the proxy's new certificate - for the supposed destination will not set up a TLS session. - - Client treatment of any information included in the certificate trust - anchor is a matter of local policy. This specification does not - mandate that such information be inspected or validated by the - server's domain name administrator. + Secure Socket Layer (SSL) proxies can sometimes act as a man-in-the- + middle for TLS clients. In these scenarios, the clients add a new + trust anchor whose private key is kept on the SSL proxy; the proxy + intercepts TLS requests, creates a new TLS session with the intended + host, and sets up a TLS session with the client using a certificate + that chains to the trust anchor installed in the client by the proxy. + In such environments, using TLSA records will prevent the SSL proxy + from functioning as expected because the TLS client will get a + certificate association from the DNS that will not match the + certificate that the SSL proxy uses with the client. The client, + seeing the proxy's new certificate for the supposed destination, will + not set up a TLS session. + + Client treatment of any information included in the trust anchor is a + matter of local policy. This specification does not mandate that + such information be inspected or validated by the server's domain + name administrator. If a server's certificate is revoked, or if an intermediate CA in a - chain between the end entity and a trust anchor has its certificate - revoked, a TLSA record with a certificate type of 2 that matches the + chain between the server and a trust anchor has its certificate + revoked, a TLSA record with a certificate usage of 2 that matches the revoked certificate would in essence override the revocation because the client would treat that revoked certificate as a trust anchor and thus not check its revocation status. Because of this, domain - administrators need to be responsible for being sure that the key or - certificate used in TLSA records with a certificate type of 2 are in - fact able to be used as reliable trust anchors. + administrators need to be responsible for being sure that the keys or + certificates used in TLSA records with a certificate usage of 2 are + in fact able to be used as reliable trust anchors. - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 17] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - - Certificates that are delivered in TLSA with usage type 2 + Certificates that are delivered in TLSA with certificate usage 2 fundamentally change the way the TLS server's end entity certificate is evaluated. For example, the server's certificate might chain to an existing CA through an intermediate CA that has certain policy restrictions, and the certificate would not pass those restrictions and thus normally be rejected. That intermediate CA could issue itself a new certificate without the policy restrictions and tell its - customers to use that certificate with usage type 2. This in essence - allows an intermediate CA to be come a trust anchor for certificates - that the end user might have expected to chain to an existing trust - anchor. + customers to use that certificate with certificate usage 2. This in + essence allows an intermediate CA to become a trust anchor for + certificates that the end user might have expected to chain to an + existing trust anchor. + + + + +Hoffman & Schlyter Standards Track [Page 17] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + If an administrator wishes to stop using a TLSA record, the administrator can simply remove it from the DNS. Normal clients will @@ -971,53 +962,174 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 against the TLSA record are not possible after the expiration date on the RRsig of the TLSA record that was removed. - The client's full trust of a certificate retrieved from a TLSA record - with a certificate usage type of 2 or 3 may be a matter of local - policy. While such trust is limited to the specific domain name for - which the TLSA query was made, local policy may deny the trust or - further restrict the conditions under which that trust is permitted. + Generators of TLSA records should be aware that the client's full + trust of a certificate association retrieved from a TLSA record may + be a matter of local policy. While such trust is limited to the + specific domain name, protocol, and port for which the TLSA query was + made, local policy may decline to accept the certificate (for reasons + such as weak cryptography), as is also the case with PKIX trust + anchors. 8.1. Comparing DANE to Public CAs - Comparing the risk for current common TLS clients against the risk - for DANE clients using external DNSSEC validators is difficult. The - common model for TLS clients is that they trust a large number of - commercial CAs who can issue certificates for any domain name. A - DANE client trusting an external DNSSEC validator is as vulnerable as - such a TLS client in that any CA or any external validator can assert - any key for any domain. + As stated above, the security of the DNS RRtype described in this + document relies on the security of DNSSEC to verify that the TLSA + record has not been altered. This section describes where the + security of public CAs and the security of TLSA are similar and + different. This section applies equally to other security-related + DNS RRtypes such as keys for IPsec and SSH. + + DNSSEC forms certificates (the binding of an identity to a key) by + combining a DNSKEY, DS, or DLV resource record with an associated + RRSIG record. These records then form a signing chain extending from + the client's trust anchors to the RR of interest. + + Although the DNSSEC protocol does not enforce it, DNSKEYs are often + marked with a SEP flag indicating whether the key is a Zone Signing + Key (ZSK) or a Key Signing Key (KSK). ZSKs protect records in the + zone (including DS and DLV records), and KSKs protect ZSK DNSKEY + records. This allows KSKs to be stored offline. + + The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to + authenticate keys wrapped in PKIX certificates for a particular host + name, protocol, and port. + + With the exception of the DLV RRtype, all of these certificates + constrain the keys they identify to names that are within the zone + signing the certificate. In order for a domain's DLV resource + records to be honored, the domain must be configured as a DLV domain, + and the domain's DNSKEYs must be configured as trust anchors or be + authentic [RFC5074]. + + + + + + + +Hoffman & Schlyter Standards Track [Page 18] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + +8.1.1. Risk of Key Compromise - If it is less likely that a user will hear about its trusted DNSSEC - validators being hacked that it is of a public CA being compromised, - a DANE client with an external validator could be worse off than a - current TLS client that is depending on the current public CAs. A - counter-argument to this is a single external DNSSEC validator is a - much less interesting target than a public CA, particularly if many - DANE clients use their own DNSSEC validators or validators that - reside on the computer on which they are running. + The risk that a given certificate that has a valid signing chain is + fake is related to the number of keys that can contribute to the + validation of the certificate, the quality of protection each private + key receives, the value of each key to an attacker, and the value of + falsifying the certificate. - Current public CAs are assumed to have better defenses than current - DNSSEC validators, but that perception cannot be proven one way or - another. Similarly, if DNSSEC validation becomes more common after - the release of this document, it cannot be predicted whether or not - that will increase the level of security of DNSSEC validators more or + DNSSEC allows any set of domains to be configured as trust anchors + and/or DLVs, but most clients are likely to use the root zone as + their only trust anchor. Also, because a given DNSKEY can only sign + resource records for that zone, the number of private keys capable of + compromising a given TLSA resource record is limited to the number of + zones between the TLSA resource record and the nearest trust anchor, + plus any configured DLV domains. Typically, this will be six keys, + half of which will be KSKs. + PKIX only describes how to validate a certificate based on a client- + chosen set of trust anchors, but says nothing about how many trust + anchors to use or how they should be constrained. As currently + deployed, most PKIX clients use a large number of trust anchors + provided with the client or operating system software. These trust + anchors are selected carefully, but with a desire for broad + interoperability. The trust anchors and CA certificates for public + CAs rarely have name constraints applied. + A combination of technical protections, process controls, and + personnel experience contribute to the quality of security that keys + receive. -Hoffman & Schlyter Expires October 13, 2012 [Page 18] + o The security surrounding DNSSEC DNSKEYs varies significantly. The + KSK/ZSK split allows the KSK to be stored offline and protected + more carefully than the ZSK, but not all domains do so. The + security applied to a zone's DNSKEYs should be proportional to the + value of the domain, but that is difficult to estimate. For + example, the root DNSKEY has protections and controls comparable + to or exceeding those of public CAs. On the other end of the + spectrum, small domains might provide no more protection to their + keys than they do to their other data. + + o The security surrounding public CAs also varies. However, due to + financial incentives and standards imposed by clients for + acceptance into their trust anchor stores, CAs generally employ + security experts and protect their keys carefully, though highly + public compromises have occurred. + + + + + + +Hoffman & Schlyter Standards Track [Page 19] -Internet-Draft DNS-Based Authentication for TLS April 2012 +RFC 6698 DNS-Based Authentication for TLS August 2012 + + +8.1.2. Impact of Key Compromise + + The impact of a key compromise differs significantly between the two + models. + + o DNSKEYs are inherently limited in what they can sign, so a + compromise of the DNSKEY for "example.com" provides no avenue of + attack against "example.org". Even the impact of a compromise of + .com's DNSKEY, while considerable, would be limited to .com + domains. Only the compromise of the root DNSKEY would have the + equivalent impact of an unconstrained public CA. + + o Public CAs are not typically constrained in what names they can + sign, and therefore a compromise of even one CA allows the + attacker to generate a certificate for any name in the DNS. A + domain holder can get a certificate from any willing CA, or even + multiple CAs simultaneously, making it impossible for a client to + determine whether the certificate it is validating is legitimate + or fraudulent. + + Because a TLSA certificate association is constrained to its + associated name, protocol, and port, the PKIX certificate is + similarly constrained, even if its public CAs signing the certificate + (if any) are not. + +8.1.3. Detection of Key Compromise + + If a key is compromised, rapid and reliable detection is important in + order to limit the impact of the compromise. In this regard, neither + model prevents an attacker from near-invisibly attacking their + victim, provided that the necessary keys are compromised. + + If a public CA is compromised, only the victim will see the + fraudulent certificate, as there is typically no publicly accessible + directory of all the certificates issued by a CA that can be + inspected. DNS resource records are typically published publicly. + However, the attacker could also allow the uncompromised records to + be published to the Internet as usual but provide a compromised DNS + view to the victim to achieve the same effect. + +8.1.4. Spoofing Hostnames + + Some CAs implement technical controls to ensure that certificates are + not issued to domains with names similar to domains that are popular + and prone to attack. Of course, an attacker can attempt to + circumvent this restriction by finding a CA willing to issue the + certificate anyway. However, by using DNSSEC and TLSA, the attacker + can circumvent this check completely. - less than the security of public CAs. Thus, it is difficult to - foresee which system has a higher risk. + +Hoffman & Schlyter Standards Track [Page 20] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + 8.2. DNS Caching Implementations of this protocol rely heavily on the DNS, and are - thus prone to security attacks based on the deliberate mis- - association of TLSA records and DNS names. Implementations need to - be cautious in assuming the continuing validity of an assocation + thus prone to security attacks based on the deliberate + mis-association of TLSA records and DNS names. Implementations need + to be cautious in assuming the continuing validity of an association between a TLSA record and a DNS name. In particular, implementations SHOULD rely on their DNS resolver for @@ -1029,12 +1141,43 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 Live) information reported by the DNS makes it likely that the cached information will remain useful. - If implementations cache the results of domain name lookups in order - to achieve a performance improvement, they MUST observe the TTL - information reported by DNS. Implementations that fail to follow - this rule could be spoofed or have access denied when a previously- - accessed server's TLSA record changes, such as during a certificate - rollover. + If implementations cache the results of domain name lookups in order + to achieve a performance improvement, they MUST observe the TTL + information reported by DNS. Implementations that fail to follow + this rule could be spoofed or have access denied when a previously + accessed server's TLSA record changes, such as during a certificate + rollover. + +8.3. External DNSSEC Validators + + Due to a lack of DNSSEC support in the most commonly deployed stub + resolvers today, some ISPs have begun checking DNSSEC in the + recursive resolvers they provide to their customers, setting the + Authentic Data (AD) flag as appropriate. DNSSEC-aware clients could + use that data, ignoring the fact that the DNSSEC data has been + validated externally. Because there is typically no authentication + of the recursive resolver or integrity protection of the data and AD + flag between the client and the recursive resolver, this can be + trivially spoofed by an attacker. + + However, even with secure communications between a host and the + external validating resolver, there is a risk that the external + validator could become compromised. Nothing prevents a compromised + external DNSSEC validator from claiming that all the records it + provides are secure, even if the data is falsified, unless the client + checks the DNSSEC data itself (rendering the external validator + unnecessary). + + For this reason, DNSSEC validation is best performed on-host, even + when a secure path to an external validator is available. + + + + + +Hoffman & Schlyter Standards Track [Page 21] + +RFC 6698 DNS-Based Authentication for TLS August 2012 9. Acknowledgements @@ -1043,7 +1186,7 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 years. More recently, the ideas have been discussed by the authors and others in a more focused fashion. In particular, some of the ideas and words here originated with Paul Vixie, Dan Kaminsky, Jeff - Hodges, Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam + Hodges, Phillip Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Langley, Ben Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit, Ondrej Sury, Richard Barnes, Jim Schaad, Stephen Farrell, Suresh Krishnaswamy, Peter Palfrader, Pieter Lexis, Wouter Wijngaards, John @@ -1052,20 +1195,15 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 This document has also been greatly helped by many active participants of the DANE Working Group. - 10. References +10.1. Normative References + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 19] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - -10.1. Normative References + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -1090,6 +1228,14 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. + + + +Hoffman & Schlyter Standards Track [Page 22] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 @@ -1099,30 +1245,23 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. - [STD13] Mockapetris, P., "Domain Name System", STD 13, - November 1987. - 10.2. Informative References + [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet + host table specification", RFC 952, October 1985. + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. - - -Hoffman & Schlyter Expires October 13, 2012 [Page 20] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s)", RFC 2931, September 2000. [RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005. @@ -1134,24 +1273,80 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006. - [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: - Extension Definitions", RFC 6066, January 2011. + [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, + November 2007. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, August 2010. + + [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) + Extensions: Extension Definitions", RFC 6066, + January 2011. + + + + +Hoffman & Schlyter Standards Track [Page 23] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, February 2011. - [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms + [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. - [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys - Identified Mail (DKIM) Signatures", RFC 6376, + [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., + "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011. [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)", RFC 6394, October 2011. + [X.690] "Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER)", July 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hoffman & Schlyter Standards Track [Page 24] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + Appendix A. Operational Considerations for Deploying TLSA Records @@ -1159,25 +1354,17 @@ A.1. Creating TLSA Records When creating TLSA records, care must be taken to avoid misconfigurations. Section 4 of this document states that a TLSA - RRset whose validation state is secure MUST be used. This means that - the existence of such a RRset effectively disables other forms of - name and path validation. A misconfigured TLSA RRset will + RRSet whose validation state is secure MUST be used. This means that + the existence of such a RRSet effectively disables other forms of + name and path validation. A misconfigured TLSA RRSet will effectively disable access to the TLS server for all conforming clients, and this document does not provide any means of making a gradual transition to using TLSA. - When creating TLSA records with certificate usage type 0 (CA - Certificate) or type 2 (Trust Anchor), one needs to understand the - implications when choosing between selector type 0 (full certificate) - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 21] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - - and 1 (SubjectPublicKeyInfo). A careful choice is required because + When creating TLSA records with certificate usage 0 (CA certificate) + or usage 2 (trust anchor), one needs to understand the implications + when choosing between selector type 0 (Full certificate) and 1 + (SubjectPublicKeyInfo). A careful choice is required because different methods for building trust chains are used by different TLS clients. The following outlines the cases that one ought to be aware of and discusses the implications of the choice of selector type. @@ -1205,57 +1392,73 @@ A.1.1. Ambiguities and Corner Cases When TLS Clients Build Trust Chains Information Access X.509v3 extension CAs frequently reissue certificates with different validity periods, - signature algorithms (such as an different hash algorithm in the + signature algorithms (such as a different hash algorithm in the signature algorithm), CA key pairs (such as for a cross-certificate), - or PKIX extensions where the public key and subject remain the same. - These reissued certificates are the certificates TLS client can use - in place of an original certificate. - Clients are known to exchange or remove certificates that could cause - TLSA associations that rely on the full certificate to fail. For - example: - - o The client considers the signature algorithm of a certificate to - no longer be sufficiently secure - o The client might not have an associated root certificate in its - trust store and instead uses a cross-certificate with an identical - subject and public key. +Hoffman & Schlyter Standards Track [Page 25] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + or PKIX extensions where the public key and subject remain the same. + These reissued certificates are the certificates that the TLS client + can use in place of an original certificate. + Clients are known to exchange or remove certificates that could cause + TLSA certificate associations that rely on the full certificate to + fail. For example: -Hoffman & Schlyter Expires October 13, 2012 [Page 22] - -Internet-Draft DNS-Based Authentication for TLS April 2012 + o The client considers the signature algorithm of a certificate to + no longer be sufficiently secure. + o The client might not have an associated root certificate in its + trust store and instead uses a cross-certificate with an identical + subject and public key. A.1.2. Choosing a Selector Type In this section, "false-negative failure" means that a client will - not accept the TLSA association for a certificate designated by DNS - administrator. Also, "false-positive acceptance" means that the - client accepts a TLSA association for a certificate that is not - designated by the DNS administrator. + not accept the TLSA certificate association for a certificate + designated by the DNS administrator. Also, "false-positive + acceptance" means that the client accepts a TLSA association for a + certificate that is not designated by the DNS administrator. A.1.2.1. Selector Type 0 (Full Certificate) The "Full certificate" selector provides the most precise - specification of a TLS certificate association, capturing all fields - of the PKIX certificate. For a DNS administrator, the best course to - avoid false-negative failures in the client when using this selector - is: + specification of a TLSA certificate association, capturing all + fields of the PKIX certificate. For a DNS administrator, the best + course to avoid false-negative failures in the client when using this + selector is: 1. If a CA issued a replacement certificate, don't associate to CA certificates that have a signature algorithm with a hash that is considered weak by local policy. 2. Determine how common client applications process the TLSA - association using a fresh client installation, that is, with the - local certificate cache empty. + certificate association using a fresh client installation -- that + is, with the local certificate cache empty. + + + + + + + + + + + + + +Hoffman & Schlyter Standards Track [Page 26] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + A.1.2.2. Selector Type 1 (SubjectPublicKeyInfo) @@ -1263,9 +1466,10 @@ A.1.2.2. Selector Type 1 (SubjectPublicKeyInfo) some false-negative failures caused by trust-chain-building algorithms used in clients. - One specific use-case ought to be noted: creating a TLSA association - to CA certificate I1 that directly signed end entity certificate S1 - of the server. The case can be illustrated by following graph: + One specific use case ought to be noted: creating a TLSA certificate + association to CA certificate I1 that directly signed end entity + certificate S1 of the server. The case can be illustrated by the + following graph: +----+ +----+ | I1 | | I2 | @@ -1281,36 +1485,37 @@ A.1.2.2. Selector Type 1 (SubjectPublicKeyInfo) I2 is a reissued version of CA certificate I1 (that is, it has a different hash in its signature algorithm). - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 23] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - In the above scenario, both certificates I1 and I2 that sign S1 need - to have identical SubjectPublicKeyInfos because the key used to sign - S1 is fixed. An association to SubjectPublicKeyInfo (selector type - 1) will always succeed in such a case, but an association with a full - certificate (selector type 0) might not work due to a false-negative - failure. + to have identical SubjectPublicKeyInfo fields because the key used to + sign S1 is fixed. An association to SubjectPublicKeyInfo (selector + type 1) will always succeed in such a case, but an association with a + full certificate (selector type 0) might not work due to a false- + negative failure. - The attack surface is a bit broader compared to "full certificate" - selector: the DNS administrator might unintentionally specify an - association that would lead to false-positive acceptance. + The attack surface is a bit broader compared to the "Full + certificate" selector: the DNS administrator might unintentionally + specify an association that would lead to false-positive acceptance. o The administrator must know or trust that the CA does not engage in bad practices, such as not sharing the key of I1 for unrelated - CA certificates leading to trust-chain redirect. If possible, the - administrator ought to review all CA certificates that have the - same SPKI. + CA certificates (which would lead to trust-chain redirection). If + possible, the administrator ought to review all CA certificates + that have the same SubjectPublicKeyInfo field. o The administrator ought to understand whether some PKIX extension may adversely affect security of the association. If possible, administrators ought to review all CA certificates that share the SubjectPublicKeyInfo. + + + + +Hoffman & Schlyter Standards Track [Page 27] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + o The administrator ought to understand that any CA could, in the future, issue a certificate that contains the same SubjectPublicKeyInfo. Therefore, new chains can crop up in the @@ -1337,14 +1542,6 @@ A.2.1. Provisioning TLSA Records with Aliases If that happens in the future, those aliases might affect TLSA records, hopefully in a good way. - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 24] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - A.2.1.1. Provisioning TLSA Records with CNAME Records Using CNAME to alias in DNS only aliases from the exact name given, @@ -1364,6 +1561,17 @@ A.2.1.1. Provisioning TLSA Records with CNAME Records would in fact return whatever value for the A record exists at bottom.sub4.example.com. + + + + + + +Hoffman & Schlyter Standards Track [Page 28] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + Application implementations and full-service resolvers request DNS records using libraries that automatically follow CNAME (and DNAME) aliasing. This allows hosts to put TLSA records in their own zones @@ -1394,13 +1602,6 @@ A.2.1.1. Provisioning TLSA Records with CNAME Records target domain to have TLSA records, but the two records are unrelated. Consider the following: - - -Hoffman & Schlyter Expires October 13, 2012 [Page 25] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - ; TLSA record in both the original and target domain ; sub5.example.com. IN CNAME sub6.example.com. @@ -1410,14 +1611,23 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49... In this example, someone looking for the TLSA record for - sub5.example.com would always get the record whose value starts - "308202c5308201ab"; the TLSA record whose value starts + sub5.example.com would always get the record whose value starts with + "308202c5308201ab"; the TLSA record whose value starts with "ac49d9ba4570ac49" would only be sought by someone who is looking for the TLSA record for sub6.example.com, and never for sub5.example.com. Note that deploying different certificates for multiple services located at a shared TLS listener often requires the use of TLS SNI (Server Name Indication) [RFC6066]. + + + + +Hoffman & Schlyter Standards Track [Page 29] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + Note that these methods use the normal method for DNS aliasing using CNAME: the DNS client requests the record type that they actually want. @@ -1449,14 +1659,6 @@ A.2.1.3. Provisioning TLSA Records with Wildcards *._tcp.www.example.com. IN TLSA 1 1 1 5c1502a6549c423b... This is possibly useful in some scenarios where the same service is - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 26] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - offered on many ports or the same certificate and/or key is used for all services on a host. Note that the domain being searched for is not necessarily related to the domain name found in the certificate, @@ -1470,6 +1672,18 @@ A.3. Securing the Last Hop for the application to determine this securely, and this specification does not mandate any single method. + + + + + + + +Hoffman & Schlyter Standards Track [Page 30] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + Some common methods for an application to know the DNSSEC validity of TLSA records include: @@ -1481,18 +1695,18 @@ A.3. Securing the Last Hop running) to a local DNS resolver that does DNSSEC validation. o The application can communicate through a secured channel (such as - requests running over TLS, IPsec, TSIG or SIG(0)) to a non-local + requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local DNS resolver that does DNSSEC validation. o The application can communicate through a secured channel (such as - requests running over TLS, IPsec, TSIG or SIG(0)) to a non-local + requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local DNS resolver that does not do DNSSEC validation, but gets responses through a secured channel from a different DNS resolver that does DNSSEC validation. A.4. Handling Certificate Rollover - Certificate rollover is handled in much the same was as for rolling + Certificate rollover is handled in much the same way as for rolling DNSSEC zone signing keys using the pre-publish key rollover method [RFC4641]. Suppose example.com has a single TLSA record for a TLS service on TCP port 990: @@ -1506,13 +1720,6 @@ A.4. Handling Certificate Rollover _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015... _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30... - - -Hoffman & Schlyter Expires October 13, 2012 [Page 27] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - After the new records have propagated to the authoritative nameservers and the TTL of the old record has expired, switch to the new certificate on the TLS server. Once this has occurred, the old @@ -1523,20 +1730,29 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 This completes the certificate rollover. + + + + + +Hoffman & Schlyter Standards Track [Page 31] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + Appendix B. Pseudocode for Using TLSA - This appendix describes the interactions given earlier in this - specification in pseudocode format. If the steps below disagree with - the text earlier in the document, the steps earlier in the document - ought to be considered correct and this text incorrect. + This appendix describes, in pseudocode format, the interactions given + earlier in this specification. If the steps below disagree with the + text earlier in the document, the steps earlier in the document ought + to be considered correct and this text incorrect. Note that this pseudocode is more strict than the normative text. - For instance, it forces an order on the evaluation of criteria which + For instance, it forces an order on the evaluation of criteria, which is not mandatory from the normative text. B.1. Helper Functions - // implement the function for exiting function Finish (F) = { if (F == ABORT_TLS) { @@ -1561,14 +1777,6 @@ B.1. Helper Functions function Select (S, X) = { // Full certificate if (S == 0) { - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 28] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - return X in DER encoding } @@ -1580,6 +1788,14 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 // unreachable } + + + +Hoffman & Schlyter Standards Track [Page 32] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + // implement the matching function function Match (M, X, Y) { // Exact match on selected content @@ -1600,13 +1816,11 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 // unreachable } - -B.2. Main TLSA Pseudo Code +B.2. Main TLSA Pseudocode TLS connect using [transport] to [name] on [port] and receiving end entity cert C for the TLS server: - (TLSArecords, ValState) = DNSSECValidatedLookup( domainname=_[port]._[transport].[name], RRtype=TLSA) @@ -1617,14 +1831,6 @@ B.2. Main TLSA Pseudo Code if ((ValState == INDETERMINATE) or (ValState == INSECURE)) { Finish(NO_TLSA) } - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 29] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - // if here, ValState must be SECURE for each R in TLSArecords { @@ -1639,10 +1845,17 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 Finish(NO_TLSA) } + + +Hoffman & Schlyter Standards Track [Page 33] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + // A TLS client might have multiple trust anchors that it might use - // when validating the TLS server's end entity certificate. Also, - // there can be multiple PKIX certification paths for the - // certificates given by the server in TLS. Thus, there are + // when validating the TLS server's end entity (EE) certificate. + // Also, there can be multiple PKIX certification paths for the + // certificates given by the server in TLS. Thus, there are // possibly many chains that might need to be tested during // PKIX path validation. @@ -1673,14 +1886,6 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 Finish(ACCEPT) } } - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 30] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - } // pass PKIX certification validation using TLSA record as the @@ -1690,6 +1895,19 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 // "trust anchor" condition for a certificate D matching R assert(Match(R.matchingType, Select(R.selectorType, D), R.cert)) + + + + + + + + +Hoffman & Schlyter Standards Track [Page 34] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + for each PKIX certification path H that has certificate D matching R as the trust anchor { if (C passes PKIX validation in H) { @@ -1711,15 +1929,13 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 // so abort TLS Finish(ABORT_TLS) - Appendix C. Examples The following are examples of self-signed certificates that have been - been generated with various selectors and matching types. They were + generated with various selectors and matching types. They were generated with one piece of software, and validated by an individual using other tools. - S = Selector M = Matching Type @@ -1729,14 +1945,6 @@ Appendix C. Examples 0603550408130D4E6F6F72642D486F6C6C616E643112301006035504 071309416D7374657264616D310C300A060355040A13034F53333123 30210603550403131A64616E652E6B6965762E70726163746963756D - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 31] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - 2E6F73332E6E6C301E170D3132303131363136353730335A170D3232 303131333136353730335A306C310B3009060355040613024E4C3116 30140603550408130D4E6F6F72642D486F6C6C616E64311230100603 @@ -1748,6 +1956,14 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE 281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827 C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5 + + + +Hoffman & Schlyter Standards Track [Page 35] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + 8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172 2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393 37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629 @@ -1785,14 +2001,6 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 7D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B6AD5DEA0C877 1C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24 B9DA1A98DCBE51195B60E42FD7517C328D983E26A827C877AB914EE4 - - - -Hoffman & Schlyter Expires October 13, 2012 [Page 32] - -Internet-Draft DNS-Based Authentication for TLS April 2012 - - C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D58C389CC3D6D8 C20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB38623D008 029A9E4702883F8B977A1A1E5292BF8AD72239D4039337B86A3AC60F @@ -1805,6 +2013,13 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DDFF6B4CAC05 0203010001 + + +Hoffman & Schlyter Standards Track [Page 36] + +RFC 6698 DNS-Based Authentication for TLS August 2012 + + 1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911 D9E30A924138C4 @@ -1812,19 +2027,31 @@ Internet-Draft DNS-Based Authentication for TLS April 2012 C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5 33A934B3A2D7E232C94AB4 - Authors' Addresses Paul Hoffman VPN Consortium - Email: paul.hoffman@vpnc.org + EMail: paul.hoffman@vpnc.org Jakob Schlyter Kirei AB - Email: jakob@kirei.se + EMail: jakob@kirei.se + + + + + + + + + + + + + @@ -1844,5 +2071,5 @@ Authors' Addresses -Hoffman & Schlyter Expires October 13, 2012 [Page 33] +Hoffman & Schlyter Standards Track [Page 37] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-19.txt b/doc/rfc/rfc6840.txt similarity index 67% rename from doc/draft/draft-ietf-dnsext-dnssec-bis-updates-19.txt rename to doc/rfc/rfc6840.txt index 36388012755..7ed54360eda 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-19.txt +++ b/doc/rfc/rfc6840.txt @@ -1,47 +1,68 @@ -Network Working Group S. Weiler -Internet-Draft SPARTA, Inc. -Updates: 4033, 4034, 4035, 5155 D. Blacka -(if approved) Verisign, Inc. -Intended status: Standards Track July 13, 2012 -Expires: January 14, 2013 - Clarifications and Implementation Notes for DNSSEC - draft-ietf-dnsext-dnssec-bis-updates-19 + +Internet Engineering Task Force (IETF) S. Weiler, Ed. +Request for Comments: 6840 SPARTA, Inc. +Updates: 4033, 4034, 4035, 5155 D. Blacka, Ed. +Category: Standards Track Verisign, Inc. +ISSN: 2070-1721 February 2013 + + + Clarifications and Implementation Notes for DNS Security (DNSSEC) Abstract - This document is a collection of technical clarifications to the - DNSSEC document set. It is meant to serve as a resource to - implementors as well as a repository of DNSSEC errata. + This document is a collection of technical clarifications to the DNS + Security (DNSSEC) document set. It is meant to serve as a resource + to implementors as well as a collection of DNSSEC errata that existed + at the time of writing. + + This document updates the core DNSSEC documents (RFC 4033, RFC 4034, + and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also + defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the + DNSSEC specification. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6840. + + + + + + + - This document updates the core DNSSEC documents (RFC4033, RFC4034, - and RFC4035) as well as the NSEC3 specification (RFC5155). It also - defines NSEC3 and SHA-2 as core parts of the DNSSEC specification. -Status of this Memo - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - 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." - This Internet-Draft will expire on January 14, 2013. + + + + +Weiler & Blacka Standards Track [Page 1] + +RFC 6840 DNSSEC Implementation Notes February 2013 + Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal @@ -49,14 +70,6 @@ Copyright Notice (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect - - - -Weiler & Blacka Expires January 14, 2013 [Page 1] - -Internet-Draft DNSSEC Implementation Notes July 2012 - - to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -98,90 +111,80 @@ Internet-Draft DNSSEC Implementation Notes July 2012 - - - - - - - - - - -Weiler & Blacka Expires January 14, 2013 [Page 2] +Weiler & Blacka Standards Track [Page 2] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 Table of Contents - 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 - 1.1. Structure of this Document . . . . . . . . . . . . . . . . 4 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Important Additions to DNSSEC . . . . . . . . . . . . . . . . 4 - 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 5 - 4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 5 - 4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 5 - 4.2. Validating Responses to an ANY Query . . . . . . . . . . . 6 - 4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 6 - 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 7 - 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 7 - 5.1. Errors in Canonical Form Type Code List . . . . . . . . . 7 - 5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 7 - 5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 8 - 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 9 - 5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 9 - 5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 9 - 5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 9 - 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 10 - 5.9. Always set the CD bit on Queries . . . . . . . . . . . . . 10 - 5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 10 - 5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 11 - 5.12. Ignore Extra Signatures From Unknown Keys . . . . . . . . 12 - 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 12 - 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 12 - 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 12 - 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 13 - 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 - Appendix B. Discussion of Setting the CD Bit . . . . . . . . . . 16 - Appendix C. Discussion of Trust Anchor Preference Options . . . . 19 - C.1. Closest Encloser . . . . . . . . . . . . . . . . . . . . . 19 - C.2. Accept Any Success . . . . . . . . . . . . . . . . . . . . 20 - C.3. Preference Based on Source . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 - - - - - - -Weiler & Blacka Expires January 14, 2013 [Page 3] + 1. Introduction and Terminology ....................................4 + 1.1. Structure of This Document .................................4 + 1.2. Terminology ................................................4 + 2. Important Additions to DNSSEC ...................................4 + 2.1. NSEC3 Support ..............................................4 + 2.2. SHA-2 Support ..............................................5 + 3. Scaling Concerns ................................................5 + 3.1. Implement a BAD Cache ......................................5 + 4. Security Concerns ...............................................5 + 4.1. Clarifications on Nonexistence Proofs ......................5 + 4.2. Validating Responses to an ANY Query .......................6 + 4.3. Check for CNAME ............................................6 + 4.4. Insecure Delegation Proofs .................................7 + 5. Interoperability Concerns .......................................7 + 5.1. Errors in Canonical Form Type Code List ....................7 + 5.2. Unknown DS Message Digest Algorithms .......................7 + 5.3. Private Algorithms .........................................8 + 5.4. Caution about Local Policy and Multiple RRSIGs .............9 + 5.5. Key Tag Calculation ........................................9 + 5.6. Setting the DO Bit on Replies ..............................9 + 5.7. Setting the AD Bit on Queries .............................10 + 5.8. Setting the AD Bit on Replies .............................10 + 5.9. Always Set the CD Bit on Queries ..........................10 + 5.10. Nested Trust Anchors .....................................11 + 5.11. Mandatory Algorithm Rules ................................11 + 5.12. Ignore Extra Signatures from Unknown Keys ................12 + 6. Minor Corrections and Clarifications ...........................12 + 6.1. Finding Zone Cuts .........................................12 + 6.2. Clarifications on DNSKEY Usage ............................12 + 6.3. Errors in Examples ........................................13 + 6.4. Errors in RFC 5155 ........................................13 + 7. Security Considerations ........................................13 + 8. References .....................................................14 + 8.1. Normative References ......................................14 + 8.2. Informative References ....................................15 + Appendix A. Acknowledgments .......................................16 + Appendix B. Discussion of Setting the CD Bit ......................16 + Appendix C. Discussion of Trust Anchor Preference Options .........19 + C.1. Closest Encloser ..........................................19 + C.2. Accept Any Success ........................................20 + C.3. Preference Based on Source ................................20 + + + + + + + + +Weiler & Blacka Standards Track [Page 3] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 1. Introduction and Terminology - This document lists some additions, clarifications and corrections to - the core DNSSEC specification, as originally described in [RFC4033], - [RFC4034], and [RFC4035], and later amended by [RFC5155]. (See - section Section 2 for more recent additions to that core document - set.) + This document lists some additions, clarifications, and corrections + to the core DNSSEC specification, as originally described in + [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155]. + (See Section 2 for more recent additions to that core document set.) It is intended to serve as a resource for implementors and as a - repository of items that need to be addressed when advancing the - DNSSEC documents along the Standards Track. + repository of items existing at the time of writing that need to be + addressed when advancing the DNSSEC documents along the Standards + Track. -1.1. Structure of this Document +1.1. Structure of This Document The clarifications and changes to DNSSEC are sorted according to their importance, starting with ones which could, if ignored, lead to @@ -195,7 +198,6 @@ Internet-Draft DNSSEC Implementation Notes July 2012 "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. - 2. Important Additions to DNSSEC This section lists some documents that are now considered core DNSSEC @@ -212,20 +214,24 @@ Internet-Draft DNSSEC Implementation Notes July 2012 large portions of the DNS space. [RFC5155] is now considered part of the DNS Security Document Family - as described by [RFC4033], Section 10. + as described by Section 10 of [RFC4033]. + + + - Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3- - SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512) - signal that a zone might be using NSEC3, rather than NSEC. The zone -Weiler & Blacka Expires January 14, 2013 [Page 4] + +Weiler & Blacka Standards Track [Page 4] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 - may be using either and validators supporting these algorithms MUST + Note that the algorithm identifiers defined in [RFC5155] (DSA-NSEC3- + SHA1 and RSASHA1-NSEC3-SHA1) and [RFC5702] (RSASHA256 and RSASHA512) + signal that a zone might be using NSEC3, rather than NSEC. The zone + may be using either, and validators supporting these algorithms MUST support both NSEC3 and NSEC responses. 2.2. SHA-2 Support @@ -237,63 +243,60 @@ Internet-Draft DNSSEC Implementation Notes July 2012 for these algorithms for DS, DNSKEY, and RRSIG records. Both [RFC4509] and [RFC5702] are now considered part of the DNS - Security Document Family as described by [RFC4033], Section 10. - + Security Document Family as described by Section 10 of [RFC4033]. 3. Scaling Concerns -3.1. Implement a BAD cache +3.1. Implement a BAD Cache - Section 4.7 of RFC4035 permits security-aware resolvers to implement - a BAD cache. That guidance has changed: security-aware resolvers - SHOULD implement a BAD cache as described in RFC4035. + Section 4.7 of [RFC4035] permits security-aware resolvers to + implement a BAD cache. That guidance has changed: security-aware + resolvers SHOULD implement a BAD cache as described in [RFC4035]. This change in guidance is based on operational experience with DNSSEC administrative errors leading to significant increases in DNS traffic, with an accompanying realization that such events are more likely and more damaging than originally supposed. An example of one - such event is documented in "Roll Over and Die" [Huston]. - + such event is documented in "Rolling Over DNSSEC Keys" [Huston]. 4. Security Concerns This section provides clarifications that, if overlooked, could lead to security issues. -4.1. Clarifications on Non-Existence Proofs +4.1. Clarifications on Nonexistence Proofs - [RFC4035] Section 5.4 under-specifies the algorithm for checking non- - existence proofs. In particular, the algorithm as presented would - incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove - the non-existence of RRs in the child zone. + Section 5.4 of [RFC4035] under-specifies the algorithm for checking + nonexistence proofs. In particular, the algorithm as presented would + allow a validator to interpret an NSEC or NSEC3 RR from an ancestor + zone as proving the nonexistence of an RR in a child zone. An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: o the NS bit set, - o the SOA bit clear, and - + o the Start of Authority (SOA) bit clear, and -Weiler & Blacka Expires January 14, 2013 [Page 5] +Weiler & Blacka Standards Track [Page 5] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 o a signer field that is shorter than the owner name of the NSEC RR, or the original owner name for the NSEC3 RR. - Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non- - existence of any RRs below that zone cut, which include all RRs at + Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume + nonexistence of any RRs below that zone cut, which include all RRs at that (original) owner name other than DS RRs, and all RRs below that owner name regardless of type. Similarly, the algorithm would also allow an NSEC RR at the same owner name as a DNAME RR, or an NSEC3 RR at the same original owner - name as a DNAME, to prove the non-existence of names beneath that + name as a DNAME, to prove the nonexistence of names beneath that DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used - to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's + to assume the nonexistence of any subdomain of that NSEC/NSEC3 RR's (original) owner name. 4.2. Validating Responses to an ANY Query @@ -308,9 +311,9 @@ Internet-Draft DNSSEC Implementation Notes July 2012 QNAME and QCLASS MUST be validated. If any of those RRsets fail validation, the answer is considered Bogus. If there are no RRsets matching QNAME and QCLASS, that fact MUST be validated according to - the rules in [RFC4035] Section 5.4 (as clarified in this document). - To be clear, a validator must not expect to receive all records at - the QNAME in response to QTYPE=*. + the rules in Section 5.4 of [RFC4035] (as clarified in this + document). To be clear, a validator must not expect to receive all + records at the QNAME in response to QTYPE=*. 4.3. Check for CNAME @@ -321,25 +324,25 @@ Internet-Draft DNSSEC Implementation Notes July 2012 bit for the query type. Without this check, an attacker could successfully transform a - positive CNAME response into a NOERROR/NODATA response by (e.g.) - simply stripping the CNAME RRset from the response. A naive + positive CNAME response into a NOERROR/NODATA response by (for + example) simply stripping the CNAME RRset from the response. A naive validator would then note that the QTYPE was not present in the matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was - set, and thus the response should have been a positive CNAME - response. + set; thus, the response should have been a positive CNAME response. + -Weiler & Blacka Expires January 14, 2013 [Page 6] +Weiler & Blacka Standards Track [Page 6] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 4.4. Insecure Delegation Proofs - [RFC4035] Section 5.2 specifies that a validator, when proving a + Section 5.2 of [RFC4035] specifies that a validator, when proving a delegation is not secure, needs to check for the absence of the DS and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also MUST check for the presence of the NS bit in the matching NSEC (or @@ -353,45 +356,47 @@ Internet-Draft DNSSEC Implementation Notes July 2012 signed RRsets) is below an unsigned delegation, thus not signed and vulnerable to further attack. - 5. Interoperability Concerns 5.1. Errors in Canonical Form Type Code List When canonicalizing DNS names (for both ordering and signing), DNS - names in the RDATA section of NSEC resource records are not - downcased. DNS names in the RDATA section of RRSIG resource records - are downcased. + names in the RDATA section of NSEC resource records are not converted + to lowercase. DNS names in the RDATA section of RRSIG resource + records are converted to lowercase. The guidance in the above paragraph differs from what has been published before but is consistent with current common practice. - [RFC4034] Section 6.2 item 3 says that names in both of these RR - types should be downcased. The earlier [RFC3755] says that they - should not. Current practice follows neither document fully. + Item 3 of Section 6.2 of [RFC4034] says that names in both of these + RR types should be converted to lowercase. The earlier [RFC3755] + says that they should not. Current practice follows neither document + fully. - Section 6.2 of RFC4034 also erroneously lists HINFO as a record that - needs downcasing, and twice at that. Since HINFO records contain no - domain names, they are not subject to downcasing. + Section 6.2 of [RFC4034] also erroneously lists HINFO as a record + that needs conversion to lowercase, and twice at that. Since HINFO + records contain no domain names, they are not subject to case + conversion. 5.2. Unknown DS Message Digest Algorithms Section 5.2 of [RFC4035] includes rules for how to handle delegations to zones that are signed with entirely unsupported public key - algorithms, as indicated by the key algorithms shown in those zone's + algorithms, as indicated by the key algorithms shown in those zones' DS RRsets. It does not explicitly address how to handle DS records that use unsupported message digest algorithms. In brief, DS records using unknown or unsupported message digest algorithms MUST be treated the same way as DS records referring to DNSKEY RRs of unknown or unsupported public key algorithms. - The existing text says: -Weiler & Blacka Expires January 14, 2013 [Page 7] +Weiler & Blacka Standards Track [Page 7] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 + + The existing text says: If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported @@ -414,9 +419,9 @@ Internet-Draft DNSSEC Implementation Notes July 2012 As discussed above, Section 5.2 of [RFC4035] requires that validators make decisions about the security status of zones based on the public key algorithms shown in the DS records for those zones. In the case - of private algorithms, as described in [RFC4034] Appendix A.1.1, the - eight-bit algorithm field in the DS RR is not conclusive about what - algorithm(s) is actually in use. + of private algorithms, as described in Appendix A.1.1 of [RFC4034], + the eight-bit algorithm field in the DS RR is not conclusive about + what algorithm(s) is actually in use. If no private algorithms appear in the DS RRset, or if any supported algorithm appears in the DS RRset, no special processing is needed. @@ -438,74 +443,80 @@ Internet-Draft DNSSEC Implementation Notes July 2012 DNSKEY RRs use unknown or unsupported private algorithms, then the zone is treated as if it were unsigned. - Note that if none of the private algorithm DS RRs can be securely - matched to DNSKEY RRs and no other DS establishes that the zone is - secure, the referral should be considered Bogus data as discussed in -Weiler & Blacka Expires January 14, 2013 [Page 8] + +Weiler & Blacka Standards Track [Page 8] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 + Note that if none of the private algorithm DS RRs can be securely + matched to DNSKEY RRs and no other DS establishes that the zone is + secure, the referral should be considered Bogus data as discussed in [RFC4035]. This clarification facilitates the broader use of private algorithms, as suggested by [RFC4955]. -5.4. Caution About Local Policy and Multiple RRSIGs +5.4. Caution about Local Policy and Multiple RRSIGs - When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3 + When multiple RRSIGs cover a given RRset, Section 5.3.3 of [RFC4035] suggests that "the local resolver security policy determines whether the resolver also has to test these RRSIG RRs and how to resolve - conflicts if these RRSIG RRs lead to differing results." + conflicts if these RRSIG RRs lead to differing results". This document specifies that a resolver SHOULD accept any valid RRSIG as sufficient, and only determine that an RRset is Bogus if all RRSIGs fail validation. If a resolver adopts a more restrictive policy, there's a danger that - properly-signed data might unnecessarily fail validation due to cache + properly signed data might unnecessarily fail validation due to cache timing issues. Furthermore, certain zone management techniques, like - the Double Signature Zone-signing Key Rollover method described in - section 4.2.1.2 of [RFC4641], will not work reliably. Such a + the Double Signature Zone Signing Key Rollover method described in + Section 4.2.1.2 of [RFC6781], will not work reliably. Such a resolver is also vulnerable to malicious insertion of gibberish signatures. 5.5. Key Tag Calculation - [RFC4034] Appendix B.1 incorrectly defines the Key Tag field + Appendix B.1 of [RFC4034] incorrectly defines the Key Tag field calculation for algorithm 1. It correctly says that the Key Tag is the most significant 16 of the least significant 24 bits of the public key modulus. However, [RFC4034] then goes on to incorrectly - say that this is 4th to last and 3rd to last octets of the public key - modulus. It is, in fact, the 3rd to last and 2nd to last octets. + say that this is fourth-to-last and third-to-last octets of the + public key modulus. It is, in fact, the third-to-last and second-to- + last octets. 5.6. Setting the DO Bit on Replies - As stated in Section 3 of [RFC3225], the DO bit of the query MUST be - copied in the response. However, in order to interoperate with - implementations that ignore this rule on sending, resolvers MUST - ignore the DO bit in responses. + As stated in Section 3 of [RFC3225], the DNSSEC OK (DO) bit of the + query MUST be copied in the response. However, in order to + interoperate with implementations that ignore this rule on sending, + resolvers MUST ignore the DO bit in responses. -5.7. Setting the AD Bit on Queries - The semantics of the AD bit in the query were previously undefined. - Section 4.6 of [RFC4035] instructed resolvers to always clear the AD - bit when composing queries. - This document defines setting the AD bit in a query as a signal - indicating that the requester understands and is interested in the -Weiler & Blacka Expires January 14, 2013 [Page 9] + + +Weiler & Blacka Standards Track [Page 9] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 - value of the AD bit in the response. This allows a requestor to +5.7. Setting the AD Bit on Queries + + The semantics of the Authentic Data (AD) bit in the query were + previously undefined. Section 4.6 of [RFC4035] instructed resolvers + to always clear the AD bit when composing queries. + + This document defines setting the AD bit in a query as a signal + indicating that the requester understands and is interested in the + value of the AD bit in the response. This allows a requester to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit. @@ -516,16 +527,16 @@ Internet-Draft DNSSEC Implementation Notes July 2012 order to interoperate with legacy stub resolvers and middleboxes that neither understand nor ignore the AD bit, validating resolvers SHOULD only set the AD bit when a response both meets the conditions listed - in RFC 4035, section 3.2.3, and the request contained either a set DO - bit or a set AD bit. + in Section 3.2.3 of [RFC4035], and the request contained either a set + DO bit or a set AD bit. -5.9. Always set the CD bit on Queries +5.9. Always Set the CD Bit on Queries - When processing a request with the CD bit set, a resolver SHOULD - attempt to return all response data, even data that has failed DNSSEC - validation. RFC4035 section 3.2.2 requires a resolver processing a - request with the CD bit set to set the CD bit on its upstream - queries. + When processing a request with the Checking Disabled (CD) bit set, a + resolver SHOULD attempt to return all response data, even data that + has failed DNSSEC validation. Section 3.2.2 of [RFC4035] requires a + resolver processing a request with the CD bit set to set the CD bit + on its upstream queries. This document further specifies that validating resolvers SHOULD set the CD bit on every upstream query. This is regardless of whether @@ -546,6 +557,13 @@ Internet-Draft DNSSEC Implementation Notes July 2012 Appendix B discusses more of the logic behind the recommendation presented in this section. + + +Weiler & Blacka Standards Track [Page 10] + +RFC 6840 DNSSEC Implementation Notes February 2013 + + 5.10. Nested Trust Anchors A DNSSEC validator may be configured such that, for a given response, @@ -553,14 +571,6 @@ Internet-Draft DNSSEC Implementation Notes July 2012 trust to the response zone. For example, imagine a validator configured with trust anchors for "example." and "zone.example." When the validator is asked to validate a response to - - - -Weiler & Blacka Expires January 14, 2013 [Page 10] - -Internet-Draft DNSSEC Implementation Notes July 2012 - - "www.sub.zone.example.", either trust anchor could apply. When presented with this situation, DNSSEC validators have a choice @@ -582,9 +592,10 @@ Internet-Draft DNSSEC Implementation Notes July 2012 5.11. Mandatory Algorithm Rules - The last paragraph of RFC4035 Section 2.2 includes rules describing - which algorithms must be used to sign a zone. Since these rules have - been confusing, they are restated using different language here: + The last paragraph of Section 2.2 of [RFC4035] includes rules + describing which algorithms must be used to sign a zone. Since these + rules have been confusing, they are restated using different language + here: The DS RRset and DNSKEY RRset are used to signal which algorithms are used to sign a zone. The presence of an algorithm in either a @@ -595,11 +606,20 @@ Internet-Draft DNSSEC Implementation Notes July 2012 the zone's DS RRset and expected trust anchors for the zone. The zone MUST also be signed with each algorithm (though not each key) present in the DNSKEY RRset. It is possible to add algorithms at - the DNSKEY that aren't in the DS record, but not vice-versa. If + the DNSKEY that aren't in the DS record, but not vice versa. If more than one key of the same algorithm is in the DNSKEY RRset, it is sufficient to sign each RRset with any subset of these DNSKEYs. It is acceptable to sign some RRsets with one subset of keys (or key) and other RRsets with a different subset, so long as at least + + + + +Weiler & Blacka Standards Track [Page 11] + +RFC 6840 DNSSEC Implementation Notes February 2013 + + one DNSKEY of each algorithm is used to sign each RRset. Likewise, if there are DS records for multiple keys of the same algorithm, any subset of those may appear in the DNSKEY RRset. @@ -609,17 +629,9 @@ Internet-Draft DNSSEC Implementation Notes July 2012 algorithms signaled in the DS RRset work, and they MUST NOT insist that all algorithms signaled in the DNSKEY RRset work. A validator MAY have a configuration option to perform a signature completeness - - - -Weiler & Blacka Expires January 14, 2013 [Page 11] - -Internet-Draft DNSSEC Implementation Notes July 2012 - - test to support troubleshooting. -5.12. Ignore Extra Signatures From Unknown Keys +5.12. Ignore Extra Signatures from Unknown Keys Validating resolvers MUST disregard RRSIGs in a zone that do not (currently) have a corresponding DNSKEY in the zone. Similarly, a @@ -627,11 +639,10 @@ Internet-Draft DNSSEC Implementation Notes July 2012 don't exist in the DNSKEY RRset. Good key rollover and algorithm rollover practices, as discussed in - RFC4641 and its successor documents and as suggested by the rules in + RFC 6781 and its successor documents and as suggested by the rules in the previous section, may require that such RRSIGs be present in a zone. - 6. Minor Corrections and Clarifications 6.1. Finding Zone Cuts @@ -656,41 +667,39 @@ Internet-Draft DNSSEC Implementation Notes July 2012 Furthermore, note that the SEP bit setting has no effect on how a DNSKEY may be used -- the validation process is specifically - prohibited from using that bit by [RFC4034] section 2.1.2. It is - possible to use a DNSKEY without the SEP bit set as the sole secure - entry point to the zone, yet use a DNSKEY with the SEP bit set to - sign all RRsets in the zone (other than the DNSKEY RRset). It is - also possible to use a single DNSKEY, with or without the SEP bit - set, to sign the entire zone, including the DNSKEY RRset itself. - + prohibited from using that bit by Section 2.1.2 of [RFC4034]. It is - - -Weiler & Blacka Expires January 14, 2013 [Page 12] +Weiler & Blacka Standards Track [Page 12] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 + possible to use a DNSKEY without the SEP bit set as the sole secure + entry point to the zone, yet use a DNSKEY with the SEP bit set to + sign all RRsets in the zone (other than the DNSKEY RRset). It is + also possible to use a single DNSKEY, with or without the SEP bit + set, to sign the entire zone, including the DNSKEY RRset itself. + 6.3. Errors in Examples - The text in [RFC4035] Section C.1 refers to the examples in B.1 as - "x.w.example.com" while B.1 uses "x.w.example". This is painfully - obvious in the second paragraph where it states that the RRSIG labels - field value of 3 indicates that the answer was not the result of - wildcard expansion. This is true for "x.w.example" but not for - "x.w.example.com", which of course has a label count of 4 + The text in Appendix C.1 of [RFC4035] refers to the examples in + Appendix B.1 as "x.w.example.com" while B.1 uses "x.w.example". This + is painfully obvious in the second paragraph where it states that the + RRSIG labels field value of 3 indicates that the answer was not the + result of wildcard expansion. This is true for "x.w.example" but not + for "x.w.example.com", which of course has a label count of 4 (antithetically, a label count of 3 would imply the answer was the result of a wildcard expansion). - The first paragraph of [RFC4035] Section C.6 also has a minor error: - the reference to "a.z.w.w.example" should instead be "a.z.w.example", - as in the previous line. + The first paragraph of Appendix C.6 of [RFC4035] also has a minor + error: the reference to "a.z.w.w.example" should instead be + "a.z.w.example", as in the previous line. 6.4. Errors in RFC 5155 - A NSEC3 record that matches an Empty Non-Terminal effectively has no + An NSEC3 record that matches an Empty Non-Terminal effectively has no type associated with it. This NSEC3 record has an empty type bit map. Section 3.2.1 of [RFC5155] contains the statement: @@ -704,17 +713,11 @@ Internet-Draft DNSSEC Implementation Notes July 2012 or more of the preceding element. This means that there must be at least one window block. If this window block has no types, it contradicts with the first statement. Therefore, the correct text in - RFC 5155 3.2.1 should be: + Section 3.2.1 of [RFC5155] should be: Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* - -7. IANA Considerations - - This document specifies no IANA Actions. - - -8. Security Considerations +7. Security Considerations This document adds SHA-2 and NSEC3 support to the core DNSSEC protocol. Security considerations for those features are discussed @@ -724,9 +727,9 @@ Internet-Draft DNSSEC Implementation Notes July 2012 -Weiler & Blacka Expires January 14, 2013 [Page 13] +Weiler & Blacka Standards Track [Page 13] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 to security failures. In particular, the validation algorithm @@ -740,10 +743,9 @@ Internet-Draft DNSSEC Implementation Notes July 2012 benefit from more stringent validation rules or a more complete set of trust anchors at an upstream validator. +8. References -9. References - -9.1. Normative References +8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. @@ -780,15 +782,17 @@ Internet-Draft DNSSEC Implementation Notes July 2012 -Weiler & Blacka Expires January 14, 2013 [Page 14] + +Weiler & Blacka Standards Track [Page 14] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 -9.2. Informative References +8.2. Informative References [Huston] Michaelson, G., Wallstrom, P., Arends, R., and G. Huston, - "Roll Over and Die?", February 2010. + "Rolling Over DNSSEC Keys", Internet Protocol + Journal, Vol. 13, No.1, pp. 2-16, March 2010. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. @@ -796,18 +800,49 @@ Internet-Draft DNSSEC Implementation Notes July 2012 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004. - [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", - RFC 4641, September 2006. - [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, July 2007. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) - Trust Anchors", RFC 5011, September 2007. + Trust Anchors", STD 74, RFC 5011, September 2007. [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, November 2007. + [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC + Operational Practices, Version 2", RFC 6781, + December 2012. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Blacka Standards Track [Page 15] + +RFC 6840 DNSSEC Implementation Notes February 2013 + Appendix A. Acknowledgments @@ -833,14 +868,6 @@ Appendix A. Acknowledgments The errors in the [RFC4035] examples were found by Roy Arends, who also contributed text for Section 6.3 of this document. - - - -Weiler & Blacka Expires January 14, 2013 [Page 15] - -Internet-Draft DNSSEC Implementation Notes July 2012 - - Text on the mandatory algorithm rules was derived from suggestions by Matthijs Mekking and Ed Lewis. @@ -854,7 +881,6 @@ Internet-Draft DNSSEC Implementation Notes July 2012 Warren Kumari and Scott Rose for their contributions to this document. - Appendix B. Discussion of Setting the CD Bit [RFC4035] may be read as relying on the implicit assumption that @@ -863,17 +889,27 @@ Appendix B. Discussion of Setting the CD Bit however, for more than one validator to exist between a stub resolver and an authoritative server. If these different validators have disjoint trust anchors configured, then it is possible that each - would be able to validate some portion of the DNS tree but neither is - able to validate all of it. Accordingly, it might be argued that it - is desirable not to set the CD bit on upstream queries, because that - allows for maximal validation. - - In section Section 5.9 of this document, it is recommended to set the - CD bit on an upstream query even when the incoming query arrives with - CD=0. This is for two reasons: it encourages a more predictable - validation experience as only one validator is always doing the - validation, and it ensures that all DNSSEC data that exists may be - available from the local cache should a query with CD=1 arrive. + would be able to validate some portion of the DNS tree, but neither + + + + + +Weiler & Blacka Standards Track [Page 16] + +RFC 6840 DNSSEC Implementation Notes February 2013 + + + is able to validate all of it. Accordingly, it might be argued that + it is desirable not to set the CD bit on upstream queries, because + that allows for maximal validation. + + In Section 5.9 of this document, it is recommended to set the CD bit + on an upstream query even when the incoming query arrives with CD=0. + This is for two reasons: it encourages a more predictable validation + experience as only one validator is always doing the validation, and + it ensures that all DNSSEC data that exists may be available from the + local cache should a query with CD=1 arrive. As a matter of policy, it is possible to set the CD bit differently than suggested in Section 5.9. A different choice will, of course, @@ -889,19 +925,12 @@ Appendix B. Discussion of Setting the CD Bit as local policy or from the API in the case of a stub). The second column indicates whether the query needs to be forwarded for resolution (F) or can be satisfied from a local cache (C). The third - - - -Weiler & Blacka Expires January 14, 2013 [Page 16] - -Internet-Draft DNSSEC Implementation Notes July 2012 - - column is a line number, so that it can be referred to later in the table. The fourth column indicates any relevant conditions at the - resolver: whether the resolver has a covering trust anchor and so on. - If there are no parameters here, the column is empty. The fifth and - final column indicates what action the resolver takes. + resolver, for example, whether the resolver has a covering trust + anchor, and so on. If there are no parameters here, the column is + empty. The fifth and final column indicates what action the resolver + takes. The tables differentiate between "cached data" and "cached RCODE=2". This is a shorthand; the point is that one has to treat RCODE=2 @@ -919,6 +948,14 @@ Internet-Draft DNSSEC Implementation Notes July 2012 This model is so named because the validating resolver sets the CD bit on queries it makes regardless of whether it has a covering trust anchor for the query. The general philosophy represented by this + + + +Weiler & Blacka Standards Track [Page 17] + +RFC 6840 DNSSEC Implementation Notes February 2013 + + table is that only one resolver should be responsible for validation irrespective of the possibility that an upstream resolver may be present with trust anchors that cover different or additional QNAMEs. @@ -933,37 +970,18 @@ Internet-Draft DNSSEC Implementation Notes July 2012 0 C A4 no covering TA Return cache contents (data or RCODE=2) 0 C A5 covering TA Validate cached result and - return it. - - - - - - - - - - - - - - -Weiler & Blacka Expires January 14, 2013 [Page 17] - -Internet-Draft DNSSEC Implementation Notes July 2012 - + return it Model 2: "never set when receiving CD=0" This model is so named because it sets CD=0 on upstream queries for - all received CD=0 queries even if it has a covering trust anchor. + all received CD=0 queries, even if it has a covering trust anchor. The general philosophy represented by this table is that more than one resolver may take responsibility for validating a QNAME and that a validation failure for a QNAME by any resolver in the chain is a validation failure for the query. Using this model is NOT RECOMMENDED. - CD F/C line conditions action ==================================================================== 1 F N1 Set CD=1 on upstream query @@ -980,45 +998,24 @@ Internet-Draft DNSSEC Implementation Notes July 2012 generated with CD=0 + Model 3: "sometimes set" + This model is so named because it sets the CD bit on upstream queries + triggered by received CD=0 queries, based on whether the validator + has a trust anchor configured that covers the query. If there is no + covering trust anchor, the resolver clears the CD bit in the upstream - - - - - - - - - - - - - - - - - - - - -Weiler & Blacka Expires January 14, 2013 [Page 18] +Weiler & Blacka Standards Track [Page 18] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 - Model 3: "sometimes set" - - This model is so named because it sets the CD bit on upstream queries - triggered by received CD=0 queries based on whether the validator has - a trust anchor configured that covers the query. If there is no - covering trust anchor, the resolver clears the CD bit in the upstream query. If there is a covering trust anchor, the resolver sets CD=1 and performs validation itself. The general philosophy represented by this table is that a resolver should try and validate QNAMEs for - which is has trust anchors and should not preclude validation by + which it has trust anchors and should not preclude validation by other resolvers for QNAMEs for which it does not have covering trust anchors. Using this model is NOT RECOMMENDED. @@ -1044,7 +1041,6 @@ Internet-Draft DNSSEC Implementation Notes July 2012 TA - Appendix C. Discussion of Trust Anchor Preference Options This section presents several different policies for validating @@ -1057,19 +1053,21 @@ C.1. Closest Encloser response. For example, consider a validator configured with trust anchors for "example." and "zone.example." When asked to validate a response for "www.sub.zone.example.", a validator using the "Closest + Encloser" policy would choose the "zone.example." trust anchor. + This policy has the advantage of allowing the operator to trivially + override a parent zone's trust anchor with one that the operator can + validate in a stronger way, perhaps because the resolver operator is -Weiler & Blacka Expires January 14, 2013 [Page 19] - -Internet-Draft DNSSEC Implementation Notes July 2012 - Encloser" policy would choose the "zone.example." trust anchor. - This policy has the advantage of allowing the operator to trivially - override a parent zone's trust anchor with one that the operator can - validate in a stronger way, perhaps because the resolver operator is +Weiler & Blacka Standards Track [Page 19] + +RFC 6840 DNSSEC Implementation Notes February 2013 + + affiliated with the zone in question. This policy also minimizes the number of public key operations needed, which is of benefit in resource-constrained environments. @@ -1078,10 +1076,10 @@ Internet-Draft DNSSEC Implementation Notes July 2012 and unnecessary validation failures when sub-zone trust anchors are neglected. As a concrete example, consider a validator that configured a trust anchor for "zone.example." in 2009 and one for - "example." in 2011. In 2012, "zone.example." rolls its KSK and - updates its DS records, but the validator operator doesn't update its - trust anchor. With the "closest encloser" policy, the validator gets - validation failures. + "example." in 2011. In 2012, "zone.example." rolls its Key Signing + Key (KSK) and updates its DS records, but the validator operator + doesn't update its trust anchor. With the "Closest Encloser" policy, + the validator gets validation failures. C.2. Accept Any Success @@ -1098,17 +1096,18 @@ C.2. Accept Any Success get a Secure validation result (and see DNS responses). This policy has the disadvantage of making the validator subject to - the compromise of the weakest of these trust anchors while making it + the compromise of the weakest of these trust anchors, while making it relatively painless to keep old trust anchors configured in perpetuity. C.3. Preference Based on Source - When the trust anchors have come from different sources (e.g. - automated updates ([RFC5011]), one or more DLV registries - ([RFC5074]), and manually configured), a validator may wish to choose - between them based on the perceived reliability of those sources. - The order of precedence might be exposed as a configuration option. + When the trust anchors have come from different sources (e.g., + automated updates ([RFC5011]), one or more DNSSEC Lookaside + Validation (DLV) registries ([RFC5074]), and manual configuration), a + validator may wish to choose between them based on the perceived + reliability of those sources. The order of precedence might be + exposed as a configuration option. For example, a validator might choose to prefer trust anchors found in a DLV registry over those manually configured on the theory that @@ -1116,9 +1115,13 @@ C.3. Preference Based on Source -Weiler & Blacka Expires January 14, 2013 [Page 20] + + + + +Weiler & Blacka Standards Track [Page 20] -Internet-Draft DNSSEC Implementation Notes July 2012 +RFC 6840 DNSSEC Implementation Notes February 2013 Conversely, a validator might choose to prefer manually configured @@ -1128,30 +1131,30 @@ Internet-Draft DNSSEC Implementation Notes July 2012 Or the validator might do something more complex: prefer a sub-set of manually configured trust anchors (based on a configuration option), - then trust anchors that have been updated using the RFC5011 - mechanism, then trust anchors from one DLV registry, then trust + then trust anchors that have been updated using the mechanism in + [RFC5011], then trust anchors from one DLV registry, then trust anchors from a different DLV registry, then the rest of the manually configured trust anchors. - Authors' Addresses - Samuel Weiler + Samuel Weiler (editor) SPARTA, Inc. 7110 Samuel Morse Drive - Columbia, Maryland 21046 + Columbia, MD 21046 US - Email: weiler@tislabs.com + EMail: weiler@tislabs.com - David Blacka + David Blacka (editor) Verisign, Inc. 12061 Bluemont Way Reston, VA 20190 US - Email: davidb@verisign.com + EMail: davidb@verisign.com + @@ -1172,5 +1175,5 @@ Authors' Addresses -Weiler & Blacka Expires January 14, 2013 [Page 21] +Weiler & Blacka Standards Track [Page 21] diff --git a/doc/rfc/rfc6891.txt b/doc/rfc/rfc6891.txt new file mode 100644 index 00000000000..bce1c78622b --- /dev/null +++ b/doc/rfc/rfc6891.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Damas +Request for Comments: 6891 Bond Internet Systems +STD: 75 M. Graff +Obsoletes: 2671, 2673 +Category: Standards Track P. Vixie +ISSN: 2070-1721 Internet Systems Consortium + April 2013 + + + Extension Mechanisms for DNS (EDNS(0)) + +Abstract + + The Domain Name System's wire protocol includes a number of fixed + fields whose range has been or soon will be exhausted and does not + allow requestors to advertise their capabilities to responders. This + document describes backward-compatible mechanisms for allowing the + protocol to grow. + + This document updates the Extension Mechanisms for DNS (EDNS(0)) + specification (and obsoletes RFC 2671) based on feedback from + deployment experience in several implementations. It also obsoletes + RFC 2673 ("Binary Labels in the Domain Name System") and adds + considerations on the use of extended labels in the DNS. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6891. + + + + + + + + + + + + + +Damas, et al. Standards Track [Page 1] + +RFC 6891 EDNS(0) Extensions April 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Damas, et al. Standards Track [Page 2] + +RFC 6891 EDNS(0) Extensions April 2013 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 5 + 4. DNS Message Changes . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 6 + 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 6 + 6. The OPT Pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 6 + 6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 6 + 6.1.1. Basic Elements . . . . . . . . . . . . . . . . . . . . 6 + 6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 7 + 6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 9 + 6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9 + 6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.2.1. Cache Behaviour . . . . . . . . . . . . . . . . . . . 10 + 6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 10 + 6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 11 + 6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 11 + 6.2.6. Support in Middleboxes . . . . . . . . . . . . . . . . 11 + 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 9.1. OPT Option Code Allocation Procedure . . . . . . . . . . . 15 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 + Appendix A. Changes since RFCs 2671 and 2673 . . . . . . . . . . 16 + + + + + + + + + + + + + + + + + + + + +Damas, et al. Standards Track [Page 3] + +RFC 6891 EDNS(0) Extensions April 2013 + + +1. Introduction + + DNS [RFC1035] specifies a message format, and within such messages + there are standard formats for encoding options, errors, and name + compression. The maximum allowable size of a DNS message over UDP + not using the extensions described in this document is 512 bytes. + Many of DNS's protocol limits, such as the maximum message size over + UDP, are too small to efficiently support the additional information + that can be conveyed in the DNS (e.g., several IPv6 addresses or DNS + Security (DNSSEC) signatures). Finally, RFC 1035 does not define any + way for implementations to advertise their capabilities to any of the + other actors they interact with. + + [RFC2671] added extension mechanisms to DNS. These mechanisms are + widely supported, and a number of new DNS uses and protocol + extensions depend on the presence of these extensions. This memo + refines and obsoletes [RFC2671]. + + Unextended agents will not know how to interpret the protocol + extensions defined in [RFC2671] and restated here. Extended agents + need to be prepared for handling the interactions with unextended + clients in the face of new protocol elements and fall back gracefully + to unextended DNS. + + EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is + negotiated between each pair of hosts in a DNS resolution process, + for instance, the stub resolver communicating with the recursive + resolver or the recursive resolver communicating with an + authoritative server. + + [RFC2671] specified extended label types. The only such label + proposed was in [RFC2673] for a label type called "Bit-String Label" + or "Binary Labels", with this latest term being the one in common + use. For various reasons, introducing a new label type was found to + be extremely difficult, and [RFC2673] was moved to Experimental. + This document obsoletes [RFC2673], deprecating Binary Labels. + Extended labels remain defined, but their use is discouraged due to + practical difficulties with deployment; their use in the future + SHOULD only be considered after careful evaluation of the deployment + hindrances. + +2. Terminology + + "Requestor" refers to the side that sends a request. "Responder" + refers to an authoritative, recursive resolver or other DNS component + that responds to questions. Other terminology is used here as + defined in the RFCs cited by this document. + + + + +Damas, et al. Standards Track [Page 4] + +RFC 6891 EDNS(0) Extensions April 2013 + + + 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]. + +3. EDNS Support Requirement + + EDNS provides a mechanism to improve the scalability of DNS as its + uses get more diverse on the Internet. It does this by enabling the + use of UDP transport for DNS messages with sizes beyond the limits + specified in RFC 1035 as well as providing extra data space for + additional flags and return codes (RCODEs). However, implementation + experience indicates that adding new RCODEs should be avoided due to + the difficulty in upgrading the installed base. Flags SHOULD be used + only when necessary for DNS resolution to function. + + For many uses, an EDNS Option Code may be preferred. + + Over time, some applications of DNS have made EDNS a requirement for + their deployment. For instance, DNSSEC uses the additional flag + space introduced in EDNS to signal the request to include DNSSEC data + in a DNS response. + + Given the increase in DNS response sizes when including larger data + items such as AAAA records, DNSSEC information (e.g., RRSIG or + DNSKEY), or large TXT records, the additional UDP payload + capabilities provided by EDNS can help improve the scalability of the + DNS by avoiding widespread use of TCP for DNS transport. + +4. DNS Message Changes + +4.1. Message Header + + The DNS message header's second full 16-bit word is divided into a + 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see Section + 4.1.1 of [RFC1035]). Some of these flag values were marked for + future use, and most of these have since been allocated. Also, most + of the RCODE values are now in use. The OPT pseudo-RR specified + below contains extensions to the RCODE bit field as well as + additional flag bits. + +4.2. Label Types + + The first 2 bits of a wire format domain label are used to denote the + type of the label. [RFC1035] allocates 2 of the 4 possible types and + reserves the other 2. More label types were defined in [RFC2671]. + The use of the 2-bit combination defined by [RFC2671] to identify + extended label types remains valid. However, it has been found that + deployment of new label types is noticeably difficult and so is only + + + +Damas, et al. Standards Track [Page 5] + +RFC 6891 EDNS(0) Extensions April 2013 + + + recommended after careful evaluation of alternatives and the need for + deployment. + +4.3. UDP Message Size + + Traditional DNS messages are limited to 512 octets in size when sent + over UDP [RFC1035]. Fitting the increasing amounts of data that can + be transported in DNS in this 512-byte limit is becoming more + difficult. For instance, inclusion of DNSSEC records frequently + requires a much larger response than a 512-byte message can hold. + + EDNS(0) specifies a way to advertise additional features such as + larger response size capability, which is intended to help avoid + truncated UDP responses, which in turn cause retry over TCP. It + therefore provides support for transporting these larger packet sizes + without needing to resort to TCP for transport. + +5. Extended Label Types + + The first octet in the on-the-wire representation of a DNS label + specifies the label type; the basic DNS specification [RFC1035] + dedicates the 2 most significant bits of that octet for this purpose. + + [RFC2671] defined DNS label type 0b01 for use as an indication for + extended label types. A specific extended label type was selected by + the 6 least significant bits of the first octet. Thus, extended + label types were indicated by the values 64-127 (0b01xxxxxx) in the + first octet of the label. + + Extended label types are extremely difficult to deploy due to lack of + support in clients and intermediate gateways, as described in + [RFC3363], which moved [RFC2673] to Experimental status; and + [RFC3364], which describes the pros and cons. As such, proposals + that contemplate extended labels SHOULD weigh this deployment cost + against the possibility of implementing functionality in other ways. + + Finally, implementations MUST NOT generate or pass Binary Labels in + their communications, as they are now deprecated. + +6. The OPT Pseudo-RR + +6.1. OPT Record Definition + +6.1.1. Basic Elements + + An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the + additional data section of a request. + + + + +Damas, et al. Standards Track [Page 6] + +RFC 6891 EDNS(0) Extensions April 2013 + + + The OPT RR has RR type 41. + + If an OPT record is present in a received request, compliant + responders MUST include an OPT record in their respective responses. + + An OPT record does not carry any DNS data. It is used only to + contain control information pertaining to the question-and-answer + sequence of a specific transaction. OPT RRs MUST NOT be cached, + forwarded, or stored in or loaded from master files. + + The OPT RR MAY be placed anywhere within the additional data section. + When an OPT RR is included within any DNS message, it MUST be the + only OPT RR in that message. If a query message with more than one + OPT RR is received, a FORMERR (RCODE=1) MUST be returned. The + placement flexibility for the OPT RR does not override the need for + the TSIG or SIG(0) RRs to be the last in the additional section + whenever they are present. + +6.1.2. Wire Format + + An OPT RR has a fixed part and a variable set of options expressed as + {attribute, value} pairs. The fixed part holds some DNS metadata, + and also a small collection of basic extension elements that we + expect to be so popular that it would be a waste of wire space to + encode them as {attribute, value} pairs. + + The fixed part of an OPT RR is structured as follows: + + +------------+--------------+------------------------------+ + | Field Name | Field Type | Description | + +------------+--------------+------------------------------+ + | NAME | domain name | MUST be 0 (root domain) | + | TYPE | u_int16_t | OPT (41) | + | CLASS | u_int16_t | requestor's UDP payload size | + | TTL | u_int32_t | extended RCODE and flags | + | RDLEN | u_int16_t | length of all RDATA | + | RDATA | octet stream | {attribute,value} pairs | + +------------+--------------+------------------------------+ + + OPT RR Format + + + + + + + + + + + +Damas, et al. Standards Track [Page 7] + +RFC 6891 EDNS(0) Extensions April 2013 + + + The variable part of an OPT RR may contain zero or more options in + the RDATA. Each option MUST be treated as a bit field. Each option + is encoded as: + + +0 (MSB) +1 (LSB) + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | OPTION-CODE | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | OPTION-LENGTH | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 4: | | + / OPTION-DATA / + / / + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + OPTION-CODE + Assigned by the Expert Review process as defined by the DNSEXT + working group and the IESG. + + OPTION-LENGTH + Size (in octets) of OPTION-DATA. + + OPTION-DATA + Varies per OPTION-CODE. MUST be treated as a bit field. + + The order of appearance of option tuples is not defined. If one + option modifies the behaviour of another or multiple options are + related to one another in some way, they have the same effect + regardless of ordering in the RDATA wire encoding. + + Any OPTION-CODE values not understood by a responder or requestor + MUST be ignored. Specifications of such options might wish to + include some kind of signaled acknowledgement. For example, an + option specification might say that if a responder sees and supports + option XYZ, it MUST include option XYZ in its response. + + + + + + + + + + + + + + + + +Damas, et al. Standards Track [Page 8] + +RFC 6891 EDNS(0) Extensions April 2013 + + +6.1.3. OPT Record TTL Field Use + + The extended RCODE and flags, which OPT stores in the RR Time to Live + (TTL) field, are structured as follows: + + +0 (MSB) +1 (LSB) + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | EXTENDED-RCODE | VERSION | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | DO| Z | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + EXTENDED-RCODE + Forms the upper 8 bits of extended 12-bit RCODE (together with the + 4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0 + indicates that an unextended RCODE is in use (values 0 through + 15). + + VERSION + Indicates the implementation level of the setter. Full + conformance with this specification is indicated by version '0'. + Requestors are encouraged to set this to the lowest implemented + level capable of expressing a transaction, to minimise the + responder and network load of discovering the greatest common + implementation level between requestor and responder. A + requestor's version numbering strategy MAY ideally be a run-time + configuration option. + If a responder does not implement the VERSION level of the + request, then it MUST respond with RCODE=BADVERS. All responses + MUST be limited in format to the VERSION level of the request, but + the VERSION of each response SHOULD be the highest implementation + level of the responder. In this way, a requestor will learn the + implementation level of a responder as a side effect of every + response, including error responses and including RCODE=BADVERS. + +6.1.4. Flags + + DO + DNSSEC OK bit as defined by [RFC3225]. + + Z + Set to zero by senders and ignored by receivers, unless modified + in a subsequent specification. + + + + + + + + +Damas, et al. Standards Track [Page 9] + +RFC 6891 EDNS(0) Extensions April 2013 + + +6.2. Behaviour + +6.2.1. Cache Behaviour + + The OPT record MUST NOT be cached. + +6.2.2. Fallback + + If a requestor detects that the remote end does not support EDNS(0), + it MAY issue queries without an OPT record. It MAY cache this + knowledge for a brief time in order to avoid fallback delays in the + future. However, if DNSSEC or any future option using EDNS is + required, no fallback should be performed, as these options are only + signaled through EDNS. If an implementation detects that some + servers for the zone support EDNS(0) while others would force the use + of TCP to fetch all data, preference MAY be given to servers that + support EDNS(0). Implementers SHOULD analyse this choice and the + impact on both endpoints. + +6.2.3. Requestor's Payload Size + + The requestor's UDP payload size (encoded in the RR CLASS field) is + the number of octets of the largest UDP payload that can be + reassembled and delivered in the requestor's network stack. Note + that path MTU, with or without fragmentation, could be smaller than + this. + + Values lower than 512 MUST be treated as equal to 512. + + The requestor SHOULD place a value in this field that it can actually + receive. For example, if a requestor sits behind a firewall that + will block fragmented IP packets, a requestor SHOULD NOT choose a + value that will cause fragmentation. Doing so will prevent large + responses from being received and can cause fallback to occur. This + knowledge may be auto-detected by the implementation or provided by a + human administrator. + + Note that a 512-octet UDP payload requires a 576-octet IP reassembly + buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over + Ethernet would be reasonable. + + Where fragmentation is not a concern, use of bigger values SHOULD be + considered by implementers. Implementations SHOULD use their largest + configured or implemented values as a starting point in an EDNS + transaction in the absence of previous knowledge about the + destination server. + + + + + +Damas, et al. Standards Track [Page 10] + +RFC 6891 EDNS(0) Extensions April 2013 + + + Choosing a very large value will guarantee fragmentation at the IP + layer, and may prevent answers from being received due to loss of a + single fragment or to misconfigured firewalls. + + The requestor's maximum payload size can change over time. It MUST + NOT be cached for use beyond the transaction in which it is + advertised. + +6.2.4. Responder's Payload Size + + The responder's maximum payload size can change over time but can + reasonably be expected to remain constant between two closely spaced + sequential transactions, for example, an arbitrary QUERY used as a + probe to discover a responder's maximum UDP payload size, followed + immediately by an UPDATE that takes advantage of this size. This is + considered preferable to the outright use of TCP for oversized + requests, if there is any reason to suspect that the responder + implements EDNS, and if a request will not fit in the default + 512-byte payload size limit. + +6.2.5. Payload Size Selection + + Due to transaction overhead, it is not recommended to advertise an + architectural limit as a maximum UDP payload size. Even on system + stacks capable of reassembling 64 KB datagrams, memory usage at low + levels in the system will be a concern. A good compromise may be the + use of an EDNS maximum payload size of 4096 octets as a starting + point. + + A requestor MAY choose to implement a fallback to smaller advertised + sizes to work around firewall or other network limitations. A + requestor SHOULD choose to use a fallback mechanism that begins with + a large size, such as 4096. If that fails, a fallback around the + range of 1280-1410 bytes SHOULD be tried, as it has a reasonable + chance to fit within a single Ethernet frame. Failing that, a + requestor MAY choose a 512-byte packet, which with large answers may + cause a TCP retry. + + Values of less than 512 bytes MUST be treated as equal to 512 bytes. + +6.2.6. Support in Middleboxes + + In a network that carries DNS traffic, there could be active + equipment other than that participating directly in the DNS + resolution process (stub and caching resolvers, authoritative + servers) that affects the transmission of DNS messages (e.g., + firewalls, load balancers, proxies, etc.), referred to here as + "middleboxes". + + + +Damas, et al. Standards Track [Page 11] + +RFC 6891 EDNS(0) Extensions April 2013 + + + Conformant middleboxes MUST NOT limit DNS messages over UDP to 512 + bytes. + + Middleboxes that simply forward requests to a recursive resolver MUST + NOT modify and MUST NOT delete the OPT record contents in either + direction. + + Middleboxes that have additional functionality, such as answering + queries or acting as intelligent forwarders, SHOULD be able to + process the OPT record and act based on its contents. These + middleboxes MUST consider the incoming request and any outgoing + requests as separate transactions if the characteristics of the + messages are different. + + A more in-depth discussion of this type of equipment and other + considerations regarding their interaction with DNS traffic is found + in [RFC5625]. + +7. Transport Considerations + + The presence of an OPT pseudo-RR in a request should be taken as an + indication that the requestor fully implements the given version of + EDNS and can correctly understand any response that conforms to that + feature's specification. + + Lack of presence of an OPT record in a request MUST be taken as an + indication that the requestor does not implement any part of this + specification and that the responder MUST NOT include an OPT record + in its response. + + Extended agents MUST be prepared for handling interactions with + unextended clients in the face of new protocol elements and fall back + gracefully to unextended DNS when needed. + + Responders that choose not to implement the protocol extensions + defined in this document MUST respond with a return code (RCODE) of + FORMERR to messages containing an OPT record in the additional + section and MUST NOT include an OPT record in the response. + + If there is a problem with processing the OPT record itself, such as + an option value that is badly formatted or that includes out-of-range + values, a FORMERR MUST be returned. If this occurs, the response + MUST include an OPT record. This is intended to allow the requestor + to distinguish between servers that do not implement EDNS and format + errors within EDNS. + + + + + + +Damas, et al. Standards Track [Page 12] + +RFC 6891 EDNS(0) Extensions April 2013 + + + The minimal response MUST be the DNS header, question section, and an + OPT record. This MUST also occur when a truncated response (using + the DNS header's TC bit) is returned. + +8. Security Considerations + + Requestor-side specification of the maximum buffer size may open a + DNS denial-of-service attack if responders can be made to send + messages that are too large for intermediate gateways to forward, + thus leading to potential ICMP storms between gateways and + responders. + + Announcing very large UDP buffer sizes may result in dropping of DNS + messages by middleboxes (see Section 6.2.6). This could cause + retransmissions with no hope of success. Some devices have been + found to reject fragmented UDP packets. + + Announcing UDP buffer sizes that are too small may result in fallback + to TCP with a corresponding load impact on DNS servers. This is + especially important with DNSSEC, where answers are much larger. + +9. IANA Considerations + + The IANA has assigned RR type code 41 for OPT. + + [RFC2671] specified a number of IANA subregistries within "DOMAIN + NAME SYSTEM PARAMETERS": + + o DNS EDNS(0) Options + + o EDNS Version Number + + o EDNS Header Flags + + Additionally, two entries were generated in existing registries: + + o EDNS Extended Label Type in the DNS Label Types registry + + o Bad OPT Version in the DNS RCODES registry + + IANA has updated references to [RFC2671] in these entries and + subregistries to this document. + + [RFC2671] created the DNS Label Types registry. This registry is to + remain open. + + The registration procedure for the DNS Label Types registry is + Standards Action. + + + +Damas, et al. Standards Track [Page 13] + +RFC 6891 EDNS(0) Extensions April 2013 + + + This document assigns option code 65535 in the DNS EDNS0 Options + registry to "Reserved for future expansion". + + The current status of the IANA registry for EDNS Option Codes at the + time of publication of this document is + + o 0-4 assigned, per references in the registry + + o 5-65000 Available for assignment, unassigned + + o 65001-65534 Local/Experimental use + + o 65535 Reserved for future expansion + + [RFC2671] expands the RCODE space from 4 bits to 12 bits. This + allows more than the 16 distinct RCODE values allowed in [RFC1035]. + IETF Review is required to add a new RCODE. + + This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS + RCODES registry. + + [RFC2671] called for the recording of assignment of extended label + types 0bxx111111 as "Reserved for future extended label types"; the + IANA registry currently contains "Reserved for future expansion". + This request implied, at that time, a request to open a new registry + for extended label types, but due to the possibility of ambiguity, + new text registrations were instead made within the general DNS Label + Types registry, which also registers entries originally defined by + [RFC1035]. There is therefore no Extended Label Types registry, with + all label types registered in the DNS Label Types registry. + + This document deprecates Binary Labels. Therefore, the status for + the DNS Label Types registration "Binary Labels" is now "Historic". + + IETF Standards Action is required for assignments of new EDNS(0) + flags. Flags SHOULD be used only when necessary for DNS resolution + to function. For many uses, an EDNS Option Code may be preferred. + + IETF Standards Action is required to create new entries in the EDNS + Version Number registry. Within the EDNS Option Code space, Expert + Review is required for allocation of an EDNS Option Code. Per this + document, IANA maintains a registry for the EDNS Option Code space. + + + + + + + + + +Damas, et al. Standards Track [Page 14] + +RFC 6891 EDNS(0) Extensions April 2013 + + +9.1. OPT Option Code Allocation Procedure + + OPT Option Codes are assigned by Expert Review. + + Assignment of Option Codes should be liberal, but duplicate + functionality is to be avoided. + +10. References + +10.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", + RFC 3225, December 2001. + +10.2. Informative References + + [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", + RFC 2673, August 1999. + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. + + [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) + Support for Internet Protocol version 6 (IPv6)", RFC 3364, + August 2002. + + [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", + BCP 152, RFC 5625, August 2009. + + + + + + + + + + + + +Damas, et al. Standards Track [Page 15] + +RFC 6891 EDNS(0) Extensions April 2013 + + +Appendix A. Changes since RFCs 2671 and 2673 + + Following is a list of high-level changes to RFCs 2671 and 2673. + + o Support for the OPT record is now mandatory. + + o Extended label types remain available, but their use is + discouraged as a general solution due to observed difficulties in + their deployment on the Internet, as illustrated by the work with + the "Binary Labels" type. + + o RFC 2673, which defined the "Binary Labels" type and is currently + Experimental, is requested to be moved to Historic. + + o Made changes in how EDNS buffer sizes are selected, and provided + recommendations on how to select them. + +Authors' Addresses + + Joao Damas + Bond Internet Systems + Av Albufera 14 + S.S. Reyes, Madrid 28701 + ES + + Phone: +1 650.423.1312 + EMail: joao@bondis.org + + + Michael Graff + + EMail: explorer@flame.org + + + Paul Vixie + Internet Systems Consortium + 950 Charter Street + Redwood City, California 94063 + US + + Phone: +1 650.423.1301 + EMail: vixie@isc.org + + + + + + + + + +Damas, et al. Standards Track [Page 16] + diff --git a/lib/dns/dns64.c b/lib/dns/dns64.c index 7d47c66933b..9bc3cd8266d 100644 --- a/lib/dns/dns64.c +++ b/lib/dns/dns64.c @@ -63,7 +63,7 @@ dns_dns64_create(isc_mem_t *mctx, isc_netaddr_t *prefix, unsigned int nbytes = 16; REQUIRE(prefix != NULL && prefix->family == AF_INET6); - /* Legal prefix lengths from draft-ietf-behave-address-format-04. */ + /* Legal prefix lengths from rfc6052.txt. */ REQUIRE(prefixlen == 32 || prefixlen == 40 || prefixlen == 48 || prefixlen == 56 || prefixlen == 64 || prefixlen == 96); REQUIRE(isc_netaddr_prefixok(prefix, prefixlen) == ISC_R_SUCCESS); @@ -73,7 +73,7 @@ dns_dns64_create(isc_mem_t *mctx, isc_netaddr_t *prefix, static const unsigned char zeros[16]; REQUIRE(prefix->family == AF_INET6); nbytes = prefixlen / 8 + 4; - /* Bits 64-71 are zeros. draft-ietf-behave-address-format-04 */ + /* Bits 64-71 are zeros. rfc6052.txt */ if (prefixlen >= 32 && prefixlen <= 64) nbytes++; REQUIRE(memcmp(suffix->type.in6.s6_addr, zeros, nbytes) == 0); @@ -169,13 +169,13 @@ dns_dns64_aaaafroma(const dns_dns64_t *dns64, const isc_netaddr_t *reqaddr, INSIST(nbytes <= 12); /* Copy prefix. */ memmove(aaaa, dns64->bits, nbytes); - /* Bits 64-71 are zeros. draft-ietf-behave-address-format-04 */ + /* Bits 64-71 are zeros. rfc6052.txt */ if (nbytes == 8) aaaa[nbytes++] = 0; /* Copy mapped address. */ for (i = 0; i < 4U; i++) { aaaa[nbytes++] = a[i]; - /* Bits 64-71 are zeros. draft-ietf-behave-address-format-04 */ + /* Bits 64-71 are zeros. rfc6052.txt */ if (nbytes == 8) aaaa[nbytes++] = 0; } diff --git a/lib/dns/rdata/generic/tlsa_52.c b/lib/dns/rdata/generic/tlsa_52.c index 11c6d7528f9..856e23975ec 100644 --- a/lib/dns/rdata/generic/tlsa_52.c +++ b/lib/dns/rdata/generic/tlsa_52.c @@ -16,7 +16,7 @@ /* $Id$ */ -/* draft-ietf-dane-protocol-19.txt */ +/* rfc6698.txt */ #ifndef RDATA_GENERIC_TLSA_52_C #define RDATA_GENERIC_TLSA_52_C diff --git a/lib/dns/rdata/generic/tlsa_52.h b/lib/dns/rdata/generic/tlsa_52.h index 83ce9529976..ce5158c9860 100644 --- a/lib/dns/rdata/generic/tlsa_52.h +++ b/lib/dns/rdata/generic/tlsa_52.h @@ -20,7 +20,7 @@ #define GENERIC_TLSA_52_H 1 /*! - * \brief per draft-ietf-dane-protocol-19.txt + * \brief per rfc6698.txt */ typedef struct dns_rdata_tlsa { dns_rdatacommon_t common;