-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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 <character-string> RFC1035 section
- 3.3 [RFC1035].
-
-
-
-
-
-
-
-Faltstrom & Kolkman Expires April 14, 2011 [Page 5]
-\f
-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 <character-string> (as specified in section
- 3.3 of RFC 1035 [RFC1035]), where all but the last <character-string>
- 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
+\r
+\r
+\r
+Network Working Group P. Faltstrom\r
+Internet-Draft Netnod\r
+Updates: 3404, 3959 (if approved) O. Kolkman\r
+Intended status: Standards Track NLnet Labs\r
+Expires: January 04, 2014 July 5, 2013\r
+\r
+ The Uniform Resource Identifier (URI) DNS Resource Record\r
+ draft-faltstrom-uri-08\r
+\r
+Abstract\r
+\r
+ This document defines a new DNS resource record, called the Uniform\r
+ Resource Identifier (URI) RR, for publishing mappings from hostnames\r
+ to URIs.\r
+\r
+ This document updates RFC 3958 and RFC 3404.\r
+\r
+Status of this Memo\r
+\r
+ This Internet-Draft is submitted in full conformance with the\r
+ provisions of BCP 78 and BCP 79.\r
+\r
+ Internet-Drafts are working documents of the Internet Engineering\r
+ Task Force (IETF). Note that other groups may also distribute\r
+ working documents as Internet-Drafts. The list of current Internet-\r
+ Drafts is at http://datatracker.ietf.org/drafts/current/.\r
+\r
+ Internet-Drafts are draft documents valid for a maximum of six months\r
+ and may be updated, replaced, or obsoleted by other documents at any\r
+ time. It is inappropriate to use Internet-Drafts as reference\r
+ material or to cite them other than as "work in progress."\r
+\r
+ This Internet-Draft will expire on January 04, 2014.\r
+\r
+Copyright Notice\r
+\r
+ Copyright (c) 2013 IETF Trust and the persons identified as the\r
+ document authors. All rights reserved.\r
+\r
+ This document is subject to BCP 78 and the IETF Trust's Legal\r
+ Provisions Relating to IETF Documents (http://trustee.ietf.org/\r
+ license-info) in effect on the date of publication of this document.\r
+ Please review these documents carefully, as they describe your rights\r
+ and restrictions with respect to this document. Code Components\r
+ extracted from this document must include Simplified BSD License text\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Faltstrom & Kolkman Expires January 04, 2014 [Page 1]\r
+\f\r
+Internet-Draft URI Resource Record July 2013\r
+\r
+ as described in Section 4.e of the Trust Legal Provisions and are\r
+ provided without warranty as described in the Simplified BSD License.\r
+\r
+Table of Contents\r
+\r
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2\r
+ 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3\r
+ 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 3\r
+ 4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 3\r
+ 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4\r
+ 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 4\r
+ 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5\r
+ 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5\r
+ 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 5\r
+ 5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 5\r
+ 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6\r
+ 6.1. Homepage at one domain, but two domains in use . . . . . . 6\r
+ 7. Relation to S-NAPTR . . . . . . . . . . . . . . . . . . . . . 6\r
+ 8. Relation to U-NAPTR . . . . . . . . . . . . . . . . . . . . . 6\r
+ 9. Relation to SRV . . . . . . . . . . . . . . . . . . . . . . . 7\r
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7\r
+ 10.1. Registration of the URI Resource Record Type . . . . . . 7\r
+ 10.2. Registration of services . . . . . . . . . . . . . . . . 7\r
+ 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7\r
+ 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8\r
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8\r
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . 8\r
+ 13.2. Non-normative references . . . . . . . . . . . . . . . . 8\r
+ Appendix A. The original RRTYPE Allocation Request . . . . . . . . 9\r
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11\r
+\r
+1. Introduction\r
+\r
+ This document explains the use of the Domain Name System (DNS) for\r
+ the storage of URIs, and how to resolve hostnames to such URIs that\r
+ can be used by various applications. For resolution the application\r
+ need to know both the hostname and the protocol that the URI is to be\r
+ used for. The protocol is registered by IANA.\r
+\r
+ Currently, looking up URIs given a hostname uses the DDDS [RFC3401]\r
+ application framework with the DNS as a database as specified in RFC\r
+ 3404 [RFC3404]. This has a number of implications such as the\r
+ inability to select what NAPTR records that match the query are\r
+ interesting. The RRSet returned will always consist of all URIs\r
+ "connected" with the domain in question.\r
+\r
+ The URI resource record specified in this document enables the\r
+ querying party to select which ones of the NAPTR records one is\r
+ interested in. This because data in the service field of the NAPTR\r
+ record is included in the owner part of the URI resource record type.\r
+\r
+\r
+\r
+\r
+\r
+Faltstrom & Kolkman Expires January 04, 2014 [Page 2]\r
+\f\r
+Internet-Draft URI Resource Record July 2013\r
+\r
+\r
+ Querying for URI resource records is not replacing querying for NAPTR\r
+ resource records (or use of S-NAPTR [RFC3958]). Instead, the URI\r
+ resource record type provides a complementary mechanism to use when\r
+ one already knows what service field is interesting. With it, one\r
+ can directly query for the specific subset of the otherwise possibly\r
+ large RRSet given back when querying for NAPTR resource records.\r
+\r
+ This document updates RFC 3958 and RFC 3404 by adding the flag "D" to\r
+ the list of defined terminal flags in section 2.2.3 of RFC 3958 and\r
+ 4.3 of RFC 3404.\r
+\r
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
+ document are to be interpreted as described in BCP 14, RFC 2119\r
+ [RFC2119].\r
+\r
+2. Applicability Statement\r
+\r
+ In general, it is expected that URI records will be used by clients\r
+ for applications where the relevant protocol to be used is known,\r
+ but, for example, an extra abstraction is needed in order to separate\r
+ a domain name from a point of service (as addressed by the URI). One\r
+ example of such a situation is when an organisation has many domain\r
+ names, but only one official web page.\r
+\r
+ Applications MUST know the specific service fields to prepend the\r
+ hostname with. Using repetitive queries for URI records MUST NOT be\r
+ a replacement for querying for NAPTR records according to the NAPTR\r
+ (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to\r
+ discover the various services and URIs for looking up access points\r
+ for a given service. Those are two very different kinds of needs.\r
+\r
+3. DNS considerations\r
+\r
+ Using prefix labels, such as underscored service tags, prevents the\r
+ use of wildcards, as constructs as _s2._s1.*.example.net. are not\r
+ possible in the DNS, see RFC 4592 [RFC4592]. Besides, underscored\r
+ service tags used for the URI RR (based on the NAPTR service\r
+ descriptions) may have slightly different semantics than service tags\r
+ used for underscored prefix labels that are used in combination with\r
+ other (yet unspecified) RR types. This may cause subtle management\r
+ problems when delegation structure that has developed within the\r
+ context of URI RRs is also to be used for other RR types. Since the\r
+ service labels might be overloaded, applications should carefully\r
+ check that the application level protocol is indeed the protocol they\r
+ expect.\r
+\r
+ Subtle management issues may also arise when the delegations from\r
+ service to sub service label involves several parties and different\r
+ stake holders.\r
+\r
+4. The format of the URI RR\r
+\r
+\r
+Faltstrom & Kolkman Expires January 04, 2014 [Page 3]\r
+\f\r
+Internet-Draft URI Resource Record July 2013\r
+\r
+\r
+ This is the presentation format of the URI RR:\r
+\r
+ \r
+ Ownername TTL Class URI Priority Weight Target\r
+ \r
+\r
+ The URI RR does not cause any kind of Additional Section processing.\r
+\r
+4.1. Ownername, class and type\r
+\r
+ The URI ownername is subject to special conventions.\r
+\r
+ Just like the SRV RR [RFC2782] the URI RR has service information\r
+ encoded in its ownername. In order to encode the service for a\r
+ specific owner name one uses service parameters. Valid service\r
+ parameters used are those used for SRV resource records, or\r
+ registered by IANA for Enumservice Registrations. The Enumservice\r
+ Registration parameters are reversed (subtype(s) before type),\r
+ prepended with an underscore (_) and prepended to the owner name in\r
+ separate labels. The underscore is prepended to the service\r
+ parameters to avoid collisions with DNS labels that occur in nature,\r
+ and the order is reversed to make it possible to do delegations, if\r
+ needed, to different zones (and therefore providers of DNS).\r
+\r
+ It should be noted that the usage of a prefix must be described in\r
+ detail in for example the Enumservice Registration documentation, or\r
+ in a specific document that clarifies potential overload of\r
+ parameters in the same URI. Specifically, registered URI schemes are\r
+ not automatically acceptable as a service. With the HTTP scheme, one\r
+ can for example have multiple methods (GET, PUT, etc), and this with\r
+ the same URI.\r
+\r
+ For example, suppose we are looking for the URI for a service with\r
+ Service Parameter "A:B:C" for host example.com.. Then we would query\r
+ for (QNAME,QTYPE)=("_C._B._A.example.com","URI")\r
+\r
+ The type number for the URI record is 256.\r
+\r
+ The URI resource record is class independent.\r
+\r
+ The URI RR has no special TTL requirements.\r
+\r
+4.2. Priority\r
+\r
+ The priority of the target URI in this RR. Its range is 0-65535. A\r
+ client MUST attempt to contact the URI with the lowest-numbered\r
+ priority it can reach; URIs with the same priority SHOULD be tried in\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Faltstrom & Kolkman Expires January 04, 2014 [Page 4]\r
+\f\r
+Internet-Draft URI Resource Record July 2013\r
+\r
+ the order defined by the weight field.\r
+\r
+4.3. Weight\r
+\r
+ A server selection mechanism. The weight field specifies a relative\r
+ weight for entries with the same priority. Larger weights SHOULD be\r
+ given a proportionately higher probability of being selected. The\r
+ range of this number is 0-65535.\r
+\r
+4.4. Target\r
+\r
+ The URI of the target, enclosed in double-quote characters ('"').\r
+ Resolution of the URI is according to the definitions for the Scheme\r
+ of the URI.\r
+\r
+ Since the URI will not be encoded as a <character-string> (see\r
+ RFC1035 section 3.3 [RFC1035]) there is no 255 character size\r
+ limitation.\r
+\r
+4.5. URI RDATA Wire Format\r
+\r
+ The RDATA for a URI RR consists of a 2 octet Priority field, a two\r
+ octet Weight field, and a variable length target field.\r
+\r
+ Priority and Weight are unsigned integers in network byte order.\r
+\r
+ The remaining data in the RDATA contains the Target field. The\r
+ Target field contains the URI as a sequence of octets (without the\r
+ enclosing double- quote characters used in the presentation format).\r
+\r
+ The Target field can also contain an IRI, but with the additional\r
+ requirements that it are in UTF-8 [RFC3629], and the requirement that\r
+ it be possible to convert to a URI according to section 3.1 of RFC\r
+ 3987 [RFC3987] and back again to an IRI according to section 3.2.\r
+ Other character sets than UTF-8 are not allowed. The domain name\r
+ part of the IRI can be either an U-LABEL or A-LABEL as defined in RFC\r
+ 5890 [RFC5890].\r
+\r
+ \r
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3\r
+ 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\r
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
+ | Priority | Weight |\r
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
+ / /\r
+ / Target /\r
+ / /\r
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
+ \r
+\r
+5. Definition of the flag 'D' for NAPTR records\r
+\r
+\r
+\r
+\r
+Faltstrom & Kolkman Expires January 04, 2014 [Page 5]\r
+\f\r
+Internet-Draft URI Resource Record July 2013\r
+\r
+\r
+ This document specifies the flag "D" for use as a flag in NAPTR\r
+ records. The flag indicate a terminal NAPTR record because it\r
+ denotes the end of the DDDS/NAPTR processing rules. In the case of a\r
+ "D" flag, the Replacement field in the NAPTR record, prepended with\r
+ the service flags, is used as the Owner of a DNS query for URI\r
+ records, and normal URI processing as defined in this document is\r
+ applied.\r
+\r
+ The replacement field MUST NOT include any of the service parameters.\r
+ Those are to be prepended (together with underscore) as described in\r
+ other places in this document.\r
+\r
+ The Regexp field in the NAPTR record MUST be empty when the 'D' flag\r
+ is in use.\r
+\r
+6. Examples\r
+\r
+6.1. Homepage at one domain, but two domains in use\r
+\r
+ An organisation has the domain names example.com and example.net, but\r
+ the official URI http://www.example.com/. Given the service type\r
+ "web" and subtype "http" (from the IANA registry), the following URI\r
+ Resource Records could be made available in the respective zones\r
+ (example.com and example.net):\r
+\r
+ \r
+ $ORIGIN example.com.\r
+ _http._web IN URI 10 1 "http://www.example.com/"\r
+ \r
+ $ORIGIN example.net.\r
+ _http._web IN URI 10 1 "http://www.example.com/"\r
+ \r
+\r
+7. Relation to S-NAPTR\r
+\r
+ The URI resource record type is not a replacement for the S-NAPTR.\r
+ It is instead an extension and the seond step of the S-NAPTR\r
+ resolution can resolve a URI resource record instead of using SRV\r
+ records and yet another algorithm for how to use SRV records for the\r
+ specific protocol.\r
+\r
+ \r
+ $ORIGIN example.com.\r
+ ;; order pref flags\r
+ IN NAPTR 100 10 "s" "EM:ProtA" ( ; service\r
+ "" ; regexp\r
+ _ProtA._tcp.example.com. ; replacement\r
+ _ProtA._tcp IN URI "schemeA:service.example.com/example"\r
+ \r
+\r
+8. Relation to U-NAPTR\r
+\r
+\r
+\r
+Faltstrom & Kolkman Expires January 04, 2014 [Page 6]\r
+\f\r
+Internet-Draft URI Resource Record July 2013\r
+\r
+\r
+ The URI Resource Record Type, together with S-NAPTR, can be viewed as\r
+ a replacement for U-NAPTR [RFC4848]. The URI Resource Record Type is\r
+ though only interesting when one know a base domain name, a protocol\r
+ and service so that one can compose the record to look up. NAPTR\r
+ records of any kind are used to look up what services exists for a\r
+ certain domain, which is one step before the URI resource record is\r
+ used.\r
+\r
+9. Relation to SRV\r
+\r
+ The URI Resource Record Type can be viewed as a replacement for the\r
+ SRV record. This because it like the SRV record can only be looked\r
+ up if one know the base domain, the protocol and the service. It has\r
+ a similar functionality, but instead of returning a hostname and port\r
+ number, the URI record return a full URI. As such, it can be viewed\r
+ as a more powerful resource record than SRV.\r
+\r
+10. IANA Considerations\r
+\r
+10.1. Registration of the URI Resource Record Type\r
+\r
+ After an expert review in February 2011 (see Appendix Appendix A)\r
+ IANA has allocated RRTYPE 256 for the URI Resource Record Type in the\r
+ registry named Resource Record (RR) TYPEs and QTYPEs as defined in\r
+ BCP 42 (at the time RFC 6195 [RFC6195]), located at http://\r
+ www.iana.org/assignments/dns-parameters.\r
+\r
+ IANA is requested to update the reference with that registration to\r
+ this RFC.\r
+\r
+10.2. Registration of services\r
+\r
+ No new registry is needed for the registration of services as the\r
+ Enumservice Registrations registry is used also for the URI resource\r
+ record type.\r
+\r
+11. Security Considerations\r
+\r
+ The authors do not believe this resource record cause any new\r
+ security problems. Deployment must though be done in a proper way as\r
+ misconfiguration of this resource record might make it impossible to\r
+ reach the service that was originally intended to be accessed.\r
+\r
+ Using the URI resource record together with security mechanisms that\r
+ relies on verification of authentication of hostnames, like TLS,\r
+ makes it important to choose the correct domain name when doing the\r
+ comparison.\r
+\r
+ The basic mechanism works as follows:\r
+\r
+ 1. Announce the fact example.com is hosted at example.org (with\r
+ some URL) in DNS\r
+ 2. Secure the URI resource record with DNSSEC.\r
+\r
+Faltstrom & Kolkman Expires January 04, 2014 [Page 7]\r
+\f\r
+Internet-Draft URI Resource Record July 2013\r
+\r
+ 3. Verify the TLS (for example) certificate for the connection to\r
+ example.org matches, i.e. use the hostname in the URI and not\r
+ the hostname used originally when looking up the URI resource\r
+ record.\r
+ 4. If needed, do application layer authentication etc over the then\r
+ encrypted connection.\r
+\r
+ What also can happen is that the URI in the resource record type has\r
+ errors in it. Applications using the URI resource record type for\r
+ resolution should behave similarly as if the user typed (or copy and\r
+ pasted) the URI. At least it must be clear to the user that the error\r
+ is not due to any error from his side.\r
+\r
+ One SHOULD NOT include userinfo (see User Information, Section 3.2.1,\r
+ in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record\r
+ as DNS data must be viewed as publicly available information.\r
+\r
+12. Acknowledgements\r
+\r
+ Ideas on how to split the two different kind of queries "What\r
+ services exists for this domain name" and "What is the URI for this\r
+ service" came from Scott Bradner and Lawrence Conroy. Other people\r
+ that have contributed to this document include Richard Barnes, Leslie\r
+ Daigle, Olafur Gudmundsson, Ted Hardie, Peter Koch, Penn Pfautz, and\r
+ Willem Toorop.\r
+\r
+13. References\r
+\r
+13.1. Normative References\r
+\r
+ [RFC1035] Mockapetris, P., "Domain names - implementation and\r
+ specification", STD 13, RFC 1035, November 1987.\r
+\r
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
+ Requirement Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO\r
+ 10646", STD 63, RFC 3629, November 2003.\r
+\r
+ [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application\r
+ Service Location Using SRV RRs and the Dynamic Delegation\r
+ Discovery Service (DDDS)", RFC 3958, January 2005.\r
+\r
+ [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource\r
+ Identifiers (IRIs)", RFC 3987, January 2005.\r
+\r
+ [RFC5890] Klensin, J., "Internationalized Domain Names for\r
+ Applications (IDNA): Definitions and Document Framework",\r
+ RFC 5890, August 2010.\r
+\r
+ [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA\r
+ Considerations", BCP 42, RFC 6195, March 2011.\r
+\r
+13.2. Non-normative references\r
+\r
+Faltstrom & Kolkman Expires January 04, 2014 [Page 8]\r
+\f\r
+Internet-Draft URI Resource Record July 2013\r
+\r
+\r
+ [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for\r
+ specifying the location of services (DNS SRV)", RFC 2782,\r
+ February 2000.\r
+\r
+ [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)\r
+ Part One: The Comprehensive DDDS", RFC 3401, October 2002.\r
+\r
+ [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)\r
+ Part Three: The Domain Name System (DNS) Database", RFC\r
+ 3403, October 2002.\r
+\r
+ [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)\r
+ Part Four: The Uniform Resource Identifiers (URI)", RFC\r
+ 3404, October 2002.\r
+\r
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record\r
+ (RR) Types", RFC 3597, September 2003.\r
+\r
+ [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform\r
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC\r
+ 3986, January 2005.\r
+\r
+ [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name\r
+ System", RFC 4592, July 2006.\r
+\r
+ [RFC4848] Daigle, L., "Domain-Based Application Service Location\r
+ Using URIs and the Dynamic Delegation Discovery Service\r
+ (DDDS)", RFC 4848, April 2007.\r
+\r
+ [RFC5507] IAB, Faltstrom, P., Austein, R. and P. Koch, "Design\r
+ Choices When Expanding the DNS", RFC 5507, April 2009.\r
+\r
+Appendix A. The original RRTYPE Allocation Request\r
+\r
+ On February 22, 2011 IANA assigned RRTYPE 256 for the URI resource\r
+ record based on a request that followed the procedure documented in\r
+ RFC 6195 [RFC6195]. The DNS RRTYPE PARAMETER ALLOCATION form as\r
+ submitted to IANA at thet time is replicated below for reference.\r
+\r
+ A. Submission Date:\r
+\r
+ May 23, 2009\r
+\r
+ B. Submission Type:\r
+\r
+ [X] New RRTYPE\r
+ [ ] Modification to existing RRTYPE\r
+\r
+ C. Contact Information for submitter:\r
+\r
+ Name: Patrik Faltstrom\r
+ Email Address: paf@cisco.com\r
+ International telephone number: +46-8-6859131\r
+\r
+Faltstrom & Kolkman Expires January 04, 2014 [Page 9]\r
+\f\r
+Internet-Draft URI Resource Record July 2013\r
+\r
+ Other contact handles:\r
+ (Note: This information will be publicly posted.)\r
+\r
+ D. Motivation for the new RRTYPE application?\r
+\r
+ There is no easy way to get from a domain name to a URI (or\r
+ IRI). Some mechanisms exists via use of the NAPTR [RFC3403]\r
+ resource record. That implies quite complicated rules that are\r
+ simplified via the S-NAPTR [RFC3958] specification. But, the\r
+ ability to directly look up a URI still exists. This\r
+ specification uses a prefix based naming mechanism originated in\r
+ the definition of the SRV [RFC2782] resource record, and the\r
+ RDATA is a URI, encoded as one text field.\r
+\r
+ See also above (Section 1).\r
+\r
+ E. Description of the proposed RR type.\r
+\r
+ The format of the URI resource record is as follows:\r
+\r
+ \r
+ Ownername TTL Class URI Priority Weight Target\r
+ \r
+\r
+ The URI RR has service information encoded in its ownername. In\r
+ order to encode the service for a specific owner name one uses\r
+ service parameters. Valid service parameters used are either\r
+ Enumservice Registrations registered by IANA, or prefixes used\r
+ for the SRV resource record.\r
+\r
+ The wire format of the RDATA is as follows:\r
+\r
+ \r
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3\r
+ 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\r
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
+ | Priority | Weight |\r
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
+ / /\r
+ / Target /\r
+ / /\r
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
+ \r
+\r
+ F. What existing RRTYPE or RRTYPEs come closest to filling that\r
+ need and why are they unsatisfactory?\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Faltstrom & Kolkman Expires January 04, 2014 [Page 10]\r
+\f\r
+Internet-Draft URI Resource Record July 2013\r
+\r
+ The RRTYPE that come closest is the NAPTR resource record. It\r
+ is for example used in the DDDS and S-NAPTR algorithms. The\r
+ main problem with the NAPTR is that selection of what record (or\r
+ records) one is interested in is based on data stored in the\r
+ RDATA portion of the NAPTR resource record. This, as explained\r
+ in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further,\r
+ most applications using NAPTR resource records uses regular\r
+ expression based rewrite rules for creation of the URI, and that\r
+ has shown be complicated to implement.\r
+\r
+ The second closest RRTYPE is the SRV record that given a\r
+ prefixed based naming just like is suggested for the URI\r
+ resource record, one get back a port number and domain name.\r
+ This can also be used for creation of a URI, but, only URIs\r
+ without path components.\r
+\r
+ G. What mnemonic is requested for the new RRTYPE (optional)?\r
+\r
+ URI\r
+\r
+ H. Does the requested RRTYPE make use of any existing IANA Registry\r
+ or require the creation of a new IANA sub-registry in DNS\r
+ Parameters?\r
+\r
+ Yes, partially.\r
+\r
+ One of the mechanisms to select a service is to use the\r
+ Enumservice Registry managed by IANA. Another is to use services\r
+ and protocols used for SRV records.\r
+\r
+ I. Does the proposal require/expect any changes in DNS servers/\r
+ resolvers that prevent the new type from being processed as an\r
+ unknown RRTYPE (see [RFC3597])?\r
+\r
+ No\r
+\r
+ J. Comments:\r
+\r
+ None\r
+\r
+\r
+Authors' Addresses\r
+\r
+ Patrik Faltstrom\r
+ Netnod\r
+ \r
+ Email: paf@netnod.se\r
+\r
+\r
+ Olaf Kolkman\r
+ NLnet Labs\r
+ \r
+ Email: olaf@NLnetLabs.nl\r
+\r
+Faltstrom & Kolkman Expires January 04, 2014 [Page 11]\r
+++ /dev/null
-
-
-
-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
-
-
- 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
- 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.
-
-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]
-\f
-Internet-Draft IPv6 Text Representation February 2010
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kawamura & Kawashima Expires August 29, 2010 [Page 2]
-\f
-Internet-Draft IPv6 Text Representation February 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.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5
- 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5
- 3. Problems Encountered with the Flexible Model . . . . . . . . . 6
- 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6
- 3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6
- 3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6
- 3.1.4. Searching for an Address in a Network Diagram . . . . 7
- 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.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.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.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 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
- 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
-
-
-
-
-Kawamura & Kawashima Expires August 29, 2010 [Page 3]
-\f
-Internet-Draft IPv6 Text Representation February 2010
-
-
-1. Introduction
-
- A single IPv6 address can be text represented in many ways. Examples
- are shown below.
-
- 2001:db8:0:0:1:0:0:1
-
- 2001:0db8:0:0:1:0:0:1
-
- 2001:db8::1:0:0:1
-
- 2001:db8::0:1:0:0:1
-
- 2001:0db8::1:0:0:1
-
- 2001:db8:0:0:1::1
-
- 2001:db8:0000:0:1::1
-
- 2001:DB8:0:0:1::1
-
- 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.
-
-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. Text Representation Flexibility of RFC4291
-
- Examples of flexibility in Section 2.2 of [RFC4291] are described
- below.
-
-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.
-
-
-
-Kawamura & Kawashima Expires August 29, 2010 [Page 4]
-\f
-Internet-Draft IPv6 Text Representation February 2010
-
-
- 2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
-
- 2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
-
- 2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
-
- 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
-
-2.2. Zero Compression
-
- '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.
-
- 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.
-
- 2001:db8:0:0:0::1
-
- 2001:db8:0:0::1
-
- 2001:db8:0::1
-
- 2001:db8::1
-
- In addition, [RFC4291] in section 2.2 notes,
-
- 'The "::" can only appear once in an address.'
-
- This gives a choice on where in a single address to compress the
- zero.
-
- 2001:db8::aaaa:0:0:1
-
- 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]
-\f
-Internet-Draft IPv6 Text Representation February 2010
-
-
- 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
-
-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
- 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
- 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,
- there are many non-engineers (who are not aware of case sensitivity
- and regular expression use) that use these application 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
- the end-hosts or end-users. This type of address management is very
- often seen in enterprise networks and also in 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]
-\f
-Internet-Draft IPv6 Text Representation February 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.
-
-3.1.4. Searching for an Address in a Network Diagram
-
- Network diagrams and blueprints often show what IP addresses are
- assigned to a system devices. In times of trouble shooting there may
- be a need to search through a diagram to find the point of failure
- (for example, if a traceroute stopped at 2001:db8::1, one would
- 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.
-
-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.
-
-3.2.2. Logging
-
- If an application were to output a log summary that represented the
- address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
- the output would be highly unreadable compared to the IPv4 output.
- 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.
-
-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]
-\f
-Internet-Draft IPv6 Text Representation February 2010
-
-
- 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
- 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.
-
-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
- 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
- first try.
-
-3.2.5. Verification
-
- Some protocols require certain data fields to be verified. One
- example of this is X.509 certificates. If an IPv6 address field in a
- certificate was incorrectly verified by converting it to text and
- making a simple textual comparison to some other address, the
- certificate may be mistakenly shown as being invalid due to a
- difference in text representation methods.
-
-3.2.6. Unexpected Modifying
-
- Sometimes, a system will take an address and modify it as a
- convenience. For example, a system may take an input of
- 2001:0db8:0::1 and make the output 2001:db8::1. If the zeros were
- input for a reason, the outcome may be somewhat unexpected.
-
-3.3. Operating
-
-3.3.1. General Summary
-
- When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
- 0:0:1, the system may take the address and show the configuration
- result as 2001:DB8::1:0:0:1. Someone familiar with IPv6 address
- 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]
-\f
-Internet-Draft IPv6 Text Representation February 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.3. Abuse
-
- Network abuse reports generally include the abusing IP address. This
- 'reporting' could take any shape or form of the flexible model. A
- team that handles network abuse must be able to tell the difference
- between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the
- 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
- uppercase or lowercase. However, when a letter is spelled uppercase,
- people tend to clarify that it is uppercase, which is unnecessary
- information.
-
-3.4. Other Minor Problems
-
-3.4.1. Changing Platforms
-
- 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.
- 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.
-
-3.4.2. Preference in Documentation
-
- A document that is edited by more than one author may become harder
- to read.
-
-3.4.3. Legibility
-
- Capital case D and 0 can be quite often misread. Capital B and 8 can
- 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]
-\f
-Internet-Draft IPv6 Text Representation February 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.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.
-
-4.2. "::" Usage
-
-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 "::"
- could have been used to produce a shorter representation 2001:db8::1.
-
-4.2.2. Handling 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.
- 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
- representation.
-
-4.3. Lower Case
-
- The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST
- be represented in lower case.
-
-
-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]
-\f
-Internet-Draft IPv6 Text Representation February 2010
-
-
- 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.
- 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)
- 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 text representation method noted in Section 4 should be applied
- 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.
-
- o [2001:db8::1]:80
-
- o 2001:db8::1:80
-
- o 2001:db8::1.80
-
- o 2001:db8::1 port 80
-
- o 2001:db8::1p80
-
- o 2001:db8::1#80
-
- 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]
-\f
-Internet-Draft IPv6 Text Representation February 2010
-
-
- address literals, [RFC3986] MUST be followed, as well as the rules in
- this document.
-
-
-7. Prefix Representation
-
- Problems with prefixes are just 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
- in text format. The example on Section 3.2.5 is one that may cause a
- security risk if used for access control. The common practice of
- comparing X.509 data is done in binary format.
-
-
-9. IANA Considerations
-
- None.
-
-
-10. Acknowledgements
-
- 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.
-
-
-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 Expires August 29, 2010 [Page 12]
-\f
-Internet-Draft IPv6 Text Representation February 2010
-
-
- Resource Identifier (URI): Generic Syntax", STD 66,
- RFC 3986, January 2005.
-
- [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 4291, February 2006.
-
-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
-
-
-
-
-
-
-
-
-Kawamura & Kawashima Expires August 29, 2010 [Page 13]
-\f
-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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kawamura & Kawashima Expires August 29, 2010 [Page 14]
-\f
-
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
+++ /dev/null
-
-
-
-BEHAVE WG M. Bagnulo
-Internet-Draft UC3M
-Intended status: Standards Track A. Sullivan
-Expires: April 4, 2011 Shinkuro
- P. Matthews
- Alcatel-Lucent
- I. van Beijnum
- IMDEA Networks
- October 1, 2010
-
-
-DNS64: DNS extensions for Network Address Translation from IPv6 Clients
- to IPv4 Servers
- draft-ietf-behave-dns64-11
-
-Abstract
-
- DNS64 is a mechanism for synthesizing AAAA records from A records.
- DNS64 is used with an IPv6/IPv4 translator to enable client-server
- communication between an IPv6-only client and an IPv4-only server,
- without requiring any changes to either the IPv6 or the IPv4 node,
- for the class of applications that work through NATs. This document
- specifies DNS64, and provides suggestions on how it should be
- deployed in conjunction with IPv6/IPv4 translators.
-
-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 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]
-\f
-Internet-Draft DNS64 October 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
- the Trust Legal Provisions and are provided without warranty as
- described in the Simplified BSD License.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al. Expires April 4, 2011 [Page 2]
-\f
-Internet-Draft DNS64 October 2010
-
-
-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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- exist . . . . . . . . . . . . . . . . . . . . . . . . 30
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al. Expires April 4, 2011 [Page 4]
-\f
-Internet-Draft DNS64 October 2010
-
-
-1. Introduction
-
- This document specifies DNS64, a mechanism that is part of the
- toolbox for IPv6-IPv4 transition and co-existence. 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.
-
- 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
- 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).
-
- 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.
-
- These mechanisms are expected to play a critical role in the IPv4-
- IPv6 transition and co-existence. 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
- 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.
-
-
-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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- 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.
-
- 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
- AAAA record from an A record containing a real IPv4 address of the
- responder, whenever the DNS64 cannot retrieve a AAAA record for the
- queried name. The DNS64 service appears as a regular DNS server or
- resolver to the IPv6 initiator. The DNS64 receives a AAAA DNS query
- generated by the IPv6 initiator. It first attempts a resolution for
- the requested AAAA records. If there are no AAAA records available
- for the target node (which is the normal case when the target node is
- an IPv4-only node), DNS64 performs a query for A records. For each A
- record discovered, DNS64 creates a synthetic AAAA RR from the
- information retrieved in the A RR.
-
- The owner name of a synthetic AAAA RR is the same as that of the
- original A RR, but an IPv6 representation of the IPv4 address
- contained in the original A RR is included in the AAAA RR. The IPv6
- representation of the IPv4 address is algorithmically generated from
- 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
- 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
- addresses included in the AAAA RR synthesized by the DNS64 contain
- 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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- 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.
-
- In general, the only shared state between the DNS64 and the IPv6/IPv4
- translator is the Pref64::/n and an optional set of static
- parameters. The Pref64::/n and the set of static parameters must be
- configured to be the same on both; there is no communication between
- the DNS64 device and IPv6/IPv4 translator functions. The mechanism
- to be used for configuring the parameters of the DNS64 is beyond the
- 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.
-
- 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.
-
- 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.
-
- The main difference in the nature of the two types of prefixes is
- that the NSP is a locally assigned prefix that is under control of
- the organization that is providing the translation services, while
- the Well-Known Prefix is a prefix that has a global meaning since it
- has been assigned for the specific purpose of representing IPv4
- addresses in IPv6 address space.
-
- The DNS64 function can be performed in any of three places. The
- terms below are more formally defined in Section 4.
-
- The first option is to locate the DNS64 function in authoritative
- servers for a zone. In this case, the authoritative server provides
- 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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- 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
- 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
- deployability, since it requires changes in the end hosts. This mode
- is called "DNS64 in stub-resolver mode". This is the second type of
- DNS64 resolver.
-
-
-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
- answers, and DNS64 may alter answers coming from an authoritative
- server.
-
- A recursive resolver can be security-aware or security-oblivious.
- Moreover, a security-aware recursive resolver can be validating or
- 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.
-
- DNSSEC includes some signaling bits that offer some indicators of
- what the query originator understands.
-
- If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit
- set, the query originator is signaling that it understands DNSSEC.
- The DO bit does not indicate that the query originator will validate
- the response. It only means that the query originator can understand
- responses containing DNSSEC data. Conversely, if the DO bit is
- 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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- 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
- the querying agent does not understand DNSSEC responses. The
- DNS64 can do validation of the response, if dictated by its local
- policy.
-
- 2. A security-oblivious DNS64 receives a query with the DO bit set,
- and the CD bit clear or set. This is just like the case of a
- non-DNS64 case: the server doesn't support it, so the querying
- agent is out of luck.
-
- 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
- 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
- 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
- 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.
-
-
-
-
-Bagnulo, et al. Expires April 4, 2011 [Page 9]
-\f
-Internet-Draft DNS64 October 2010
-
-
-4. Terminology
-
- This section provides definitions for the special terms used in the
- 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 RFC 2119 [RFC2119].
-
- 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 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".
-
- DNS64 resolver: Any resolver (stub resolver or recursive resolver)
- that provides the DNS64 function.
-
- DNS64 server: Any server providing the DNS64 function. This
- includes the server portion of a recursive resolver when it is
- providing the DNS64 function.
-
- IPv4-only server: Servers running IPv4-only applications, 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
- can only use IPv6, as well as cases where only IPv6 connectivity
- is available to the client.
-
- 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
- recursion is beyond the scope of this document; see [RFC1034] and
- [RFC1035] for full details.
-
- Synthetic RR: A DNS resource record (RR) that is not contained in
- the authoritative servers' zone data, but which is instead
- 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]
-\f
-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
- 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
- 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
- records. The DNS64 function may be implemented in a stub resolver,
- 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].
-
- 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.
-
- 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
-
- 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,
- either by performing a query or, in the case of an authoritative
- server, by examining its own results. The query may be answered from
- a local cache, if one is available. DNS64 operation for classes
- 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]
-\f
-Internet-Draft DNS64 October 2010
-
-
-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
- 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
- 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.
-
- 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
- available for that owner name. Those servers are in clear violation
- 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. Expires April 4, 2011 [Page 12]
-\f
-Internet-Draft DNS64 October 2010
-
-
-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
- 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
- implementation SHOULD include the ::ffff/96 network in that range by
- default. Failure to provide this facility will mean that clients
- querying the DNS64 function may not be able to communicate with hosts
- that would be reachable from a dual-stack host.
-
- When the DNS64 performs its initial AAAA query, if it receives an
- answer with only AAAA records containing addresses in the excluded
- 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.
- 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.
-
-5.1.5. Dealing with CNAME and DNAME
-
- If the response contains a CNAME or a DNAME, then the CNAME or DNAME
- chain is followed until the first terminating A or AAAA record is
- reached. This may require the DNS64 to ask for an A record, in case
- the response to the original AAAA query is a CNAME or DNAME without a
- AAAA record to follow. The resulting AAAA or A record is treated
- like any other AAAA or A case, as appropriate.
-
- When assembling the answer section, any chains of CNAME or DNAME RRs
- 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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- 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,
- the DNS64 synthesizes AAAA RRs based on the A RRs according to the
- procedure outlined in Section 5.1.7. The DNS64 returns the
- synthesized AAAA records in the answer section, removing the A
- records that form the basis of the synthesis.
-
-5.1.7. Performing the synthesis
-
- A synthetic AAAA record is created from an A record as follows:
-
- o The NAME field is set to the NAME field from the A record.
-
- o The TYPE field is set to 28 (AAAA).
-
- 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 RDLENGTH field is set to 16.
-
- o The RDATA field is set to the IPv6 representation of the IPv4
- address from the RDATA field of the A record. The DNS64 MUST
- check each A RR against configured IPv4 address ranges and select
- the corresponding IPv6 prefix to use in synthesizing the AAAA RR.
- 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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- 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.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
- 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
- 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
- derive the original IPv4 address from the IPv6 representation.
-
- 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).
-
- 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
- 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
-
- [[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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- 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.
-
-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
- 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
- different sorts:
-
- 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
- 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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- 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.
-
- 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.
-
-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
- additional section unchanged.
-
- 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
- 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.
-
-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]
-\f
-Internet-Draft DNS64 October 2010
-
-
-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.
-
- The query that is used as the basis for synthesis results either in
- an error, an answer that can be used as a basis for synthesis, or an
- empty (authoritative) answer. If there is an empty answer, then the
- DNS64 responds to the original querying client with the answer the
- DNS64 received to the original (initiator's) query. Otherwise, the
- response is assembled as follows.
-
- The header fields are set according to the usual rules for recursive
- or authoritative servers, depending on the role that the DNS64 is
- serving. The question section is copied from the original
- (initiator's) query. The answer section is populated according to
- the rules in Section 5.1.7. The authority and additional sections
- are copied from the response to the final query that the DNS64
- performed, and used as the basis for synthesis.
-
- 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
-
- 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 vDNS64 uses the presence of the DO and CD bits to make some
- decisions about what the query originator needs, and can react
- accordingly:
-
- 1. If CD is not set and DO is not set, vDNS64 SHOULD perform
- validation and do synthesis as needed. See the next item for
- rules about how to do validation and synthesis. In this case,
- however, vDNS64 MUST NOT set the AD bit in any response.
-
- 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
- to query for A records for the same name, in order to be sure
- that there is not a legitimate AAAA record on the Internet.
- Failing to observe this step would allow an attacker to use DNS64
- 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]
-\f
-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
- of a security-aware recursive name server if and only if it
- 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
- 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.
-
- 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.
-
-
-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
- incompatible with some things that may be deployed in an IPv4-only or
- dual-stack context.
-
-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]
-\f
-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
-
- 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.
-
-6.3. DNS64 and multihomed and dual-stack 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
- to resolvers in multiple networks, it is possible that some of them
- will receive answers from a DNS64 without all of them being connected
- via a NAT64. For instance, suppose a system has two interfaces, i1
- and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2
- has native IPv6 connectivity only. I1 might receive a AAAA answer
- from a DNS64 that is configured for a particular NAT64; the IPv6
- address contained in that AAAA answer will not connect with anything
- via i2.
-
- +---------------+ +-------------+
- | i1 (IPv6)+----NAT64--------+IPv4 Internet|
- | | +-------------+
- | host |
- | | +-------------+
- | i2 (IPv6)+-----------------+IPv6 Internet|
- +---------------+ +-------------+
-
- 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
- answer received on one interface will not work on the other
- interface. Hosts that attempt to use DNS answers globally may
- encounter surprising failures in these cases.
-
- 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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- with a single interface routed to two different networks.
-
-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.
-
- +---------------+ +-------------+
- | i1 (IPv6)+----NAT64--------+IPv4 Internet|
- | | +-------------+
- | host |
- | | +-------------+
- | i2 (IPv4)+-----------------+IPv4 Internet|
- +---------------+ +-------------+
-
- 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
- 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
- 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
- host, the DNS64 looks just like an ordinary DNS server. Operators of
- a NAT64 should expect traffic to pass through the NAT64 even when it
- is not necessary.
-
-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
- only accessible using the NAT64. In this case, it is critical that
- the DNS64 not synthesize AAAA responses for hosts in the LAN, or else
- that the DNS64 be aware of hosts in the LAN and provide context-
- sensitive answers ("split view" DNS answers) for hosts inside the
- LAN. As with any split view DNS arrangement, operators must be
- prepared for data to leak from one context to another, and for
- failures to occur because nodes accessible from one context are not
- accessible from the other.
-
-
-
-
-
-
-Bagnulo, et al. Expires April 4, 2011 [Page 21]
-\f
-Internet-Draft DNS64 October 2010
-
-
- +---------------+ +-------------+
- | i1 (IPv6)+----NAT64--------+IPv4 Internet|
- | | +-------------+
- | host |
- | |
- | i2 (IPv4)+---(local LAN only)
- +---------------+
-
- Figure 3: Intentional dual-stack DNS64 use
-
- It is important for deployers of DNS64 to realise 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
- (or both) entailed by the NAT. At the same time, some hosts are not
- able to learn about DNS servers provisioned on IPv6 addresses, or
- simply cannot send DNS packets over IPv6.
-
-
-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.
-
-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. Expires April 4, 2011 [Page 22]
-\f
-Internet-Draft DNS64 October 2010
-
-
- +---------------------+ +---------------+
- |IPv6 network | | IPv4 |
- | | +-------------+ | Internet |
- | |--| Name server |--| |
- | | | with DNS64 | | +----+ |
- | +----+ | +-------------+ | | H2 | |
- | | H1 |---| | | +----+ |
- | +----+ | +------------+ | 192.0.2.1 |
- | |---| IPv6/IPv4 |--| |
- | | | Translator | | |
- | | +------------+ | |
- | | | | |
- +---------------------+ +---------------+
-
- Figure 4: An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS
- server mode
-
- The figure shows an IPv6 node H1 and an IPv4 node H2 with 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.
-
- 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").
-
- The steps by which H1 establishes communication with H2 are:
-
- 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. The recursive name server implements DNS64
- functionality.
-
- 2. The recursive name server resolves the query, and discovers that
- 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
- 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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- 4. H1 receives the synthetic AAAA record and sends a packet towards
- 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.
-
-7.2. An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in
- stub-resolver mode
-
- This case is depicted in the following figure:
-
-
- +---------------------+ +---------------+
- |IPv6 network | | IPv4 |
- | | +--------+ | Internet |
- | |-----| Name |----| |
- | +-----+ | | server | | +----+ |
- | | H1 | | +--------+ | | H2 | |
- | |with |---| | | +----+ |
- | |DNS64| | +------------+ | 192.0.2.1 |
- | +----+ |---| IPv6/IPv4 |--| |
- | | | Translator | | |
- | | +------------+ | |
- | | | | |
- +---------------------+ +---------------+
-
-
- 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.
-
- 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.
-
- 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").
- 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]
-\f
-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.
-
- 2. The recursive DNS server resolves the query, and returns the
- answer to H1. Because there are no AAAA records in the global
- DNS for H2, the answer is empty.
-
- 3. The stub resolver at H1 then queries for an A record for H2 and
- gets back an A record containing the IPv4 address 192.0.2.1. The
- 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.
-
- 4. H1 sends a packet towards 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 using the IPv6/
- IPv4 translator mechanisms.
-
-7.3. Example of IPv6-Internet-to-an-IPv4-network setup 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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- [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
- 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 scenario for this case is depicted in the following figure:
-
-
- +-----------+ +----------------------+
- | | | IPv4 site |
- | IPv6 | +------------+ | +----+ |
- | Internet |----| IPv6/IPv4 |--|---| H2 | |
- | | | Translator | | +----+ |
- | | +------------+ | |
- | | | | 192.0.2.1 |
- | | +------------+ | |
- | |----| Name server|--| |
- | | | with DNS64 | | |
- +-----------+ +------------+ | |
- | | | |
- +----+ | |
- | H1 | +----------------------+
- +----+
-
- Figure 6: IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server
- mode
-
- The figure shows an IPv6 node H1 and an IPv4 node H2 with 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
- representations of IPv4 addresses. The same prefix is configured in
-
-
-
-Bagnulo, et al. Expires April 4, 2011 [Page 26]
-\f
-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.
-
- The steps by which H1 establishes communication with H2 are:
-
- 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
- a DNS query for a AAAA record for H2. The query is eventually
- forwarded to the server in the IPv4 site.
-
- 2. The local DNS server resolves the query (locally), and discovers
- that there are no AAAA records for H2.
-
- 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.
-
- 4. H1 receives the synthetic AAAA record and sends a packet towards
- H2. The packet is sent to the destination address 2001:DB8::
- 192.0.2.1.
-
- 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).
-
- 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.
-
- 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]
-\f
-Internet-Draft DNS64 October 2010
-
-
- eavesdropping attack (in case the Pref64 is routed through the
- attacker).
-
-
-9. IANA Considerations
-
- This memo makes no request of IANA.
-
-
-10. Contributors
-
- Dave Thaler
-
- Microsoft
-
- dthaler@windows.microsoft.com
-
-
-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.
-
-
-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.
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
-
-
-
-Bagnulo, et al. Expires April 4, 2011 [Page 28]
-\f
-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.
-
- [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.
-
-12.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.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "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.
-
- [RFC3484] Draves, R., "Default Address Selection for Internet
- Protocol version 6 (IPv6)", RFC 3484, February 2003.
-
- [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
- "DNS Extensions to Support IP Version 6", RFC 3596,
- October 2003.
-
- [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.
-
-
-
-Bagnulo, et al. Expires April 4, 2011 [Page 29]
-\f
-Internet-Draft DNS64 October 2010
-
-
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
- DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
-
- [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.
-
- [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
-
- 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
- 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.
-
- 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.
-
- 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,
- the only way for communication to succeed is with the translated
- address. So, in order to support this scenario, the administrator of
- a DNS64 service may want to enable the synthesis of AAAA RRs even
- when real AAAA RRs exist.
-
- 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]
-\f
-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
- 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.
-
- This means that without further configuration:
-
- 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.
-
- 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)
-
- In the "An IPv6 network to 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 problem can be solved by properly configuring the RFC3484
- [RFC3484] policy table.
-
-
-Authors' Addresses
-
- 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
-
-
-
-
-Bagnulo, et al. Expires April 4, 2011 [Page 31]
-\f
-Internet-Draft DNS64 October 2010
-
-
- Andrew Sullivan
- Shinkuro
- 4922 Fairmont Avenue, Suite 250
- Bethesda, MD 20814
- USA
-
- Phone: +1 301 961 3131
- Email: ajs@shinkuro.com
-
-
- Philip Matthews
- Unaffiliated
- 600 March Road
- Ottawa, Ontario
- Canada
-
- Phone: +1 613-592-4343 x224
- Fax:
- Email: philip_matthews@magma.ca
- URI:
-
-
- Iljitsch van Beijnum
- IMDEA Networks
- Av. Universidad 30
- Leganes, Madrid 28911
- Spain
-
- Phone: +34-91-6246245
- Email: iljitsch@muada.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al. Expires April 4, 2011 [Page 32]
-\f
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
-<html><head>
-<title>302 Found</title>
-</head><body>
-<h1>Found</h1>
-<p>The document has moved <a href="http://www.ietf.org/id/draft-ietf-dane-protocol-19.txt">here</a>.</p>
-</body></html>
+++ /dev/null
-
-
-
-
-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
-
-Abstract
-
- The standard means within the Domain Name System protocol for
- maintaining coherence among a zone's authoritative name servers
- consists of three mechanisms. Authoritative Transfer (AXFR) is one
- of the mechanisms and is defined in RFC 1034 and RFC 1035.
-
- The definition of AXFR has proven insufficient in detail, thereby
- forcing implementations intended to be compliant to make assumptions,
- impeding interoperability. Yet today we have a satisfactory set of
- implementations that do interoperate. This document is a new
- definition of AXFR -- new in the sense that it records an accurate
- definition of an interoperable AXFR mechanism.
-
-Status of this Memo
-
- 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]
-\f
-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.
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 2]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 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]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
-1. Introduction
-
- The Domain Name System standard facilities for maintaining coherent
- 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.
-
- This document re-specifies the AXFR mechanism as it is deployed in
- the Internet at large, hopefully with the precision expected from
- modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.
-
-1.1. Definition of Terms
-
- 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 "Key words for use in
- RFCs to Indicate Requirement Levels" [BCP14].
-
- 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
- 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
- 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
- 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]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
- 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-
- defined in-band mechanisms to provide coherence of a set of name
- servers, and they are the only mechanisms specified by the IETF.
-
- This document does not cover incoherent DNS situations. There are
- applications of the DNS in which servers for a zone are designed to
- be incoherent. For these configurations, a coherency mechanism as
- described here would be unsuitable.
-
- 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
- AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
- implementations may exist without AXFR.
-
-1.3. Context
-
- Besides describing the mechanisms themselves, there is the context in
- which they operate to consider. In the initial specifications of
- AXFR (and IXFR and NOTIFY), little consideration was given to
- security and privacy issues. Since the original definition of AXFR,
- new opinions have appeared on the access to an entire zone's
- contents. In this document, the basic mechanisms will be discussed
- separately from the permission to use these mechanisms.
-
-1.4. Coverage and Relationship to Original AXFR Specification
-
- This document concentrates on just the definition of AXFR. Any
- effort to update the specification of the IXFR or NOTIFY mechanisms
- is left to different documents.
-
- The original "specification" of the AXFR sub-protocol is scattered
- through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 (on page 5)
- depicts the scenario for which AXFR has been designed. Section 4.3.5
- of RFC 1034 describes the zone synchronization strategies in general
- and rules for the invocation of a full zone transfer via AXFR; the
- fifth paragraph of that section contains a very short sketch of the
- 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
- 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
- details regarding TCP connection management for AXFR. Finally, the
- second paragraph of Section 6.3 in RFC 1035 mandates server behavior
- when zone data changes occur during an ongoing zone transfer using
- AXFR.
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 5]
-\f
-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
- is to define AXFR as it is understood by the DNS community to exist
- today.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 6]
-\f
-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]
-
- 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.
-
-
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 7]
-\f
-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 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- 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
- capitalized in this document for clarity, e.g., "Additional section".
-
- The DNS message size limit from [RFC1035] for DNS over UDP (and its
- extension via the EDNS0 mechanism specified in [RFC2671]) is not
- relevant for AXFR, as explained in Section 4. The upper limit on the
- permissible size of a DNS message over TCP is only restricted by the
- TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a
- two-octet message length field, understood to be unsigned, and thus
- causing a limit of 65535 octets. This limit is not changed by EDNS0.
-
- Note that the TC (truncation) bit is never set by an AXFR server nor
- considered/read by an AXFR client.
-
-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
- activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
- respectively) or as a result of a command line request, say for
- debugging.
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 8]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 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)
-
- RCODE MUST be 0 (No error)
-
- QDCOUNT Number of entries in Question section; MUST be 1
-
- ANCOUNT Number of entries in Answer section; MUST be 0
-
- NSCOUNT Number of entries in Authority section; MUST be 0
-
- ARCOUNT Number of entries in Additional section -- see Note d)
-
- Notes:
-
- 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".)
-
- 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
- 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
- it.
-
-
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 9]
-\f
-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.
-
-2.1.2. Question Section
-
- The Question section of the AXFR query MUST conform to Section 4.1.2
- of RFC 1035, and contain a single resource record with the following
- values:
-
- QNAME the name of the zone requested
-
- QTYPE AXFR (= 252), the pseudo-RR type for zone transfer
- [DNSVALS]
-
- QCLASS the class of the zone requested [DNSVALS]
-
-2.1.3. Answer Section
-
- The Answer section MUST be empty.
-
-2.1.4. Authority Section
-
- The Authority section MUST be empty.
-
-2.1.5. Additional Section
-
- Currently, two kinds of resource records are defined that can appear
- in the Additional section of AXFR queries and responses: EDNS and DNS
- transaction security. Future specifications defining RRs that can be
- 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 transaction integrity and authentication
- resource record, currently a choice of TSIG [RFC2845] or SIG(0)
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 10]
-\f
-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.
-
- 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.
-
- The range of permissible resource records that MAY appear in the
- Additional section might change over time. If either a change to an
- existing resource record (like the OPT RR for EDNS) is made or a new
- 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.
-
-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.
-
- 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.
-
- The AXFR protocol treats the zone contents as an unordered collection
- (or to use the mathematical term, a "set") of RRs. Except for the
- requirement that the transfer must begin and end with the SOA RR,
- there is no requirement to send the RRs in any particular order or
- grouped into response messages in any particular way. Although
- servers typically do attempt to send related RRs (such as the RRs
- forming an RRset, and the RRsets of a name) as a contiguous group or,
- when message space allows, in the same response message, they are not
- required to do so, and clients MUST accept any ordering and grouping
- 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]
-\f
-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).
- 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
- way to automatically detect such clients, this typically requires
- manual configuration at the server.
-
- 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
- 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.
-
- An AXFR server may send a number of AXFR response messages free of an
- error condition before it sends the message indicating an error.
-
-2.2.1. Header Values
-
- These are the DNS message header values for AXFR responses.
-
- ID MUST be copied from request -- see Note a)
-
- QR MUST be 1 (Response)
-
- OPCODE MUST be 0 (Standard Query)
-
- Flags:
- AA normally 1 -- see Note b)
- TC MUST be 0 (Not truncated)
- 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)
-
- RCODE See Note e)
-
- QDCOUNT MUST be 1 in the first message;
- MUST be 0 or 1 in all following messages;
- MUST be 1 if RCODE indicates an error
-
- ANCOUNT See Note f)
-
- NSCOUNT MUST be 0
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 12]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
- ARCOUNT See Note g)
-
- Notes:
-
- a) Because some old implementations behave differently than is now
- desired, the requirement on this field is stated in detail. New
- 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
- 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
- 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.
-
- 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
- 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
- 1 in the query.
-
- 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
- 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-
- specific response processing. The same is true for other values
- indicating an error.
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 13]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 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
- 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.
-
- 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
- Section 2.1.5 above for details on the currently applicable RRs
- and Section 2.2.5 for additional considerations specific to AXFR
- servers.
-
-2.2.2. Question Section
-
- 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,
- that is, the name of the zone being transferred.
-
-2.2.3. Answer Section
-
- The Answer section MUST be populated with the zone contents. See
- Section 3 below on encoding zone contents.
-
-2.2.4. Authority Section
-
- The Authority section MUST be empty.
-
-2.2.5. Additional Section
-
- The contents of this section MUST follow the guidelines for the OPT,
- TSIG, and SIG(0) RRs, or whatever other future record is possible
- here. The contents of Section 2.1.5 apply analogously as well.
-
- 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.
-
- 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]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
- record into the AXFR response message(s), according to the rules
- specified for that method.
-
-2.3. TCP Connection Aborts
-
- If an AXFR client sends a query on a TCP connection and the
- connection is closed at any point, the AXFR client MUST consider the
- AXFR session terminated. The message ID MAY be used again on a new
- connection, even if the question and AXFR server are the same.
-
- Facing a dropped connection, a client SHOULD try to make some
- determination as to whether the connection closure was the result of
- network activity or due to a decision by the AXFR server. This
- determination is not an exact science. It is up to the AXFR client
- 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
- 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
- contents of a zone, in order to permit the AXFR client to faithfully
- reconstruct the zone as it exists at the primary server for the given
- zone serial number. The word "exists" here designates the externally
- visible behavior, i.e., the zone content that is being served (handed
- out to clients) -- not its persistent representation in a zone file
- or database used by the server -- and that for consistency should be
- served subsequently by the AXFR client in an identical manner.
-
- Over time the definition of a zone has evolved from denoting a static
- set of records to also cover a dynamically updated set of records,
- and then a potentially continually regenerated set of records (e.g.,
- RRs synthesized "on the fly" from rule sets or database lookup
- results in other forms than RR format) as well.
-
-3.1. Records to Include
-
- 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]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
- 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.
-
-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."
-
- There has been some controversy over this statement and the impact on
- which NS resource records are included in a zone transfer.
-
- The phrase "that describe cuts" is a reference to the NS set and
- 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".
-
- DNSSEC resource records have special specifications regarding their
- occurrence at a zone cut and the apex of a zone. This was first
- described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
- specification of DNSSEC), which parts of RFC 2181 now in fact are
- historical. The current DNSSEC core document set (see second bullet
- 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
- 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
- part of the authoritative data of the zone it serves.
-
- 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
- may return both RRSets at once if the same server is authoritative
- for the parent zone and the child zone (Section 3.1.5 of RFC 4035
- describes how to distinguish these RRs); this seeming ambiguity
- does not occur for AXFR, since each such RRSIG RRset belongs to a
- single zone.
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 16]
-\f
-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
- of these zones and is to be included in the AXFR of that zone.
-
- 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 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.
-
- 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
- AXFR server be authoritative for both halves of an inconsistent cut
- point and that the AXFR client is authoritative for just the parent
- side of the cut point.
-
- When facing a situation in which a cut point's NS resource records do
- not match the authoritative set, the question arises whether an AXFR
- server responds with the NS resource record set that is in the zone
- being transferred or the one that is at the authoritative location.
-
- The AXFR response MUST contain the cut point NS resource record set
- registered with the zone whether it agrees with the authoritative set
- or not. "Registered with" can be widely interpreted to include data
- residing in the zone file of the zone for the particular serial
- 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]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
- 3) The inconsistent NS resource record set might indicate a problem
- 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.
-
- 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
- being transferred, the set of records returned could vary depending
- 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.
-
-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
- 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.
-
- This applies to glue records for any address family [IANA-AF].
-
- The AXFR response MUST contain the appropriate glue records as
- registered with the zone. The interpretation of "registered with" in
- the previous section applies here. Inconsistent glue records are an
- operational matter.
-
-3.4. Name Compression
-
- 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].)
-
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 18]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
- 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
- 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
- the usual definition of name comparison in the DNS protocol and
- represents a new understanding of the requirement on AXFR servers.
-
- Rules governing name compression of RDATA in an AXFR message MUST
- abide by the specification in "Handling of Unknown DNS Resource
- Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name
- Compression".
-
-3.5. Occluded Names
-
- Dynamic Update [RFC2136] operations, and in particular its
- 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,
- still part of the zone but not available to the lookup process. The
- addition of a DNAME resource record has the same impact. The
- subordinate names are said to be "occluded".
-
- 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].
-
- 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
- response, and then close the connection. But variations of that most
- simple scenario are legitimate and likely: in particular, sending a
- 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]
-\f
-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
- 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
- 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
- (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
- 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.
-
- The guidance given below is intended to enable better performance of
- the AXFR exchange as well as provide guidelines on interactions with
- 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.
-
-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
- apparent need to use the connection for some time period. The AXFR
- server ought not have to maintain idle connections; the burden of
- 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]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
- An AXFR client can cancel the delivery of a zone only by closing the
- connection. However, this action will also cancel all other
- outstanding activity using the connection. There is no other
- mechanism by which an AXFR response can be cancelled.
-
- When a TCP connection is closed remotely (relative to the client),
- whether by the AXFR server or due to a network event, the AXFR client
- MUST cancel all outstanding sessions and non-AXFR transactions.
- Recovery from this situation is not straightforward. If the
- disruption was a spurious event, attempting to restart the connection
- would be proper. If the disruption was caused by a failure that
- proved to be persistent, the AXFR client would be wise not to spend
- too many resources trying to rebuild the connection. Finally, if the
- connection was dropped because of a policy at the AXFR server (as can
- be the case with older AXFR servers), the AXFR client would be wise
- not to retry the connection. Unfortunately, knowing which of the
- three cases above (momentary disruption, failure, policy) applies is
- not possible with certainty, and can only be assessed by heuristics.
- This exemplifies the general complications for clients in connection-
- oriented protocols not receiving meaningful error responses.
-
- 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).
-
-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
- transactions over it.
-
- If a TCP connection is closed remotely, the AXFR server MUST cancel
- all AXFR sessions in place. No retry activity is necessary; that is
- initiated by the AXFR client.
-
- Local policy MAY dictate that a TCP connection is to be closed. Such
- an action SHOULD be in reaction to limits such as those placed on the
- number of outstanding open connections. Closing a connection in
- response to a suspected security event SHOULD be done only in extreme
- cases, when the server is certain the action is warranted. An
- isolated request for a zone not on the AXFR server SHOULD receive a
- response with the appropriate response code and not see the
- connection broken.
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 21]
-\f
-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
- 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
- zone. This was not envisioned in the original design of the DNS but
- has emerged as a requirement as the DNS has evolved. Restrictions on
- 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
- 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
- the factual requirement to provide mechanisms to restrict AXFR.
-
- A DNS implementation SHOULD provide means to restrict AXFR sessions
- to specific clients.
-
- 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
- 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 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 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.
-
-
-
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 22]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 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
- implementation detail of one AXFR server used for the zone and not
- present in another AXFR server used for the zone.
-
- Ensuring that an AXFR client does not accept a forged copy of a zone
- is important to the security of a zone. If a zone operator has the
- opportunity, protection can be afforded via dedicated links, physical
- or virtual via a VPN among the authoritative servers. But there are
- instances in which zone operators have no choice but to run AXFR
- sessions over the global public Internet.
-
- 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]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
-7. Backwards Compatibility
-
- Describing backwards compatibility is difficult because of the lack
- 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
- 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
- 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.
-
-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
- can accept multiple resource records per AXFR response message. The
- knowledge that a client is so restricted cannot be discovered, hence
- it has to be set by configuration.
-
- 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.
-
-7.2. Client
-
- An AXFR client has the opportunity to try other features (i.e., those
- not defined by this document) when querying an AXFR server.
-
- Attempting to issue multiple DNS queries over a TCP transport for an
- AXFR session SHOULD be aborted if it interrupts the original request,
- and SHOULD take into consideration whether the AXFR server intends to
- close the connection immediately upon completion of the original
- (connection-causing) zone transfer.
-
-
-
-
-
-
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 24]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
-8. Security Considerations
-
- This document is a clarification of a mechanism outlined in RFCs 1034
- and 1035 and as such does not add any new security considerations.
- RFC 3833 [RFC3833] is devoted entirely to security considerations for
- the DNS; its Section 4.3 delineates zone transfer security aspects
- from the security threats addressed by DNSSEC.
-
- Concerns regarding authorization, traffic flooding, and message
- integrity are mentioned in "Authorization" (Section 5), "TCP"
- (Section 4.2) and "Zone Integrity" (Section 6).
-
-
-9. IANA Considerations
-
- IANA has added a reference to this RFC in the AXFR (252) row of the
- "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
- that can possibly be subject to Internationalization considerations.
- It is assumed that for DNS labels and domain names, the issue has
- 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:
-
- "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:
- 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.
-
- Edward Lewis served as a patiently listening sole document editor for
- two years.
-
-
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 25]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
-12. References
-
- 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/
-
-12.1. Normative References
-
- [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.
-
- [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
- August 1980.
-
- [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.
-
- [RFC1123] Braden, R., "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.
-
- [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
- RFC 2671, August 1999.
-
- [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
- RFC 2672, August 1999.
-
-
-
-
-
-Lewis & Hoenes Expires September 26, 2010 [Page 26]
-\f
-Internet-Draft DNS Zone Transfer Protocol (AXFR) March 2010
-
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
- [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
- ( SIG(0)s )", RFC 2931, September 2000.
-
- [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
- November 2002.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-
- [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.
-
- [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.
-
- [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]
-\f
-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.
-
-
-Authors' Addresses
-
- Edward Lewis
- 46000 Center Oak Plaza
- Sterling, VA, 22033, US
-
- Email: ed.lewis@neustar.biz
-
-
- Alfred Hoenes, Editor
- TR-Sys
- Gerlinger Str. 12
- Ditzingen D-71254
- Germany
-
- 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]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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, <http://www.cpni.gov.uk/Docs/
- tn-03-09-security-assessment-TCP.pdf>.
-
- [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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-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
-
-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 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.
-
-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
-
-
-
-Weiler & Blacka Expires January 14, 2013 [Page 1]
-\f
-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
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka Expires January 14, 2013 [Page 2]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
-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]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
-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.)
-
- 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.
-
-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
- security problems and progressing down to clarifications that are
- expected to have little operational impact.
-
-1.2. Terminology
-
- 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
- [RFC2119].
-
-
-2. Important Additions to DNSSEC
-
- This section lists some documents that are now considered core DNSSEC
- protocol documents in addition to those originally specified in
- Section 10 of [RFC4033].
-
-2.1. NSEC3 Support
-
- [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
- records for hashed denial of existence. Validator implementations
- are strongly encouraged to include support for NSEC3 because a number
- of highly visible zones use it. Validators that do not support
- validation of responses using NSEC3 will be hampered in validating
- large portions of the DNS space.
-
- [RFC5155] is now considered part of the DNS Security Document Family
- as described by [RFC4033], Section 10.
-
- 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]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
- may be using either and validators supporting these algorithms MUST
- support both NSEC3 and NSEC responses.
-
-2.2. SHA-2 Support
-
- [RFC4509] describes the use of SHA-256 as a digest algorithm in
- Delegation Signer (DS) RRs. [RFC5702] describes the use of the
- RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs.
- Validator implementations are strongly encouraged to include support
- 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.
-
-
-3. Scaling Concerns
-
-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.
-
- 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].
-
-
-4. Security Concerns
-
- This section provides clarifications that, if overlooked, could lead
- to security issues.
-
-4.1. Clarifications on Non-Existence 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.
-
- An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:
-
- o the NS bit set,
- o the SOA bit clear, and
-
-
-
-
-
-Weiler & Blacka Expires January 14, 2013 [Page 5]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
- 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
- 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
- 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
- (original) owner name.
-
-4.2. Validating Responses to an ANY Query
-
- [RFC4035] does not address how to validate responses when QTYPE=*.
- As described in Section 6.2.2 of [RFC1034], a proper response to
- QTYPE=* may include a subset of the RRsets at a given name. That is,
- it is not necessary to include all RRsets at the QNAME in the
- response.
-
- When validating a response to QTYPE=*, all received RRsets that match
- 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=*.
-
-4.3. Check for CNAME
-
- Section 5 of [RFC4035] says nothing explicit about validating
- responses based on (or that should be based on) CNAMEs. When
- validating a NOERROR/NODATA response, validators MUST check the CNAME
- bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the
- 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
- 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.
-
-
-
-
-
-Weiler & Blacka Expires January 14, 2013 [Page 6]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
-4.4. Insecure Delegation Proofs
-
- [RFC4035] Section 5.2 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
- NSEC3) RR (proving that there is, indeed, a delegation), or
- alternately make sure that the delegation is covered by an NSEC3 RR
- with the Opt-Out flag set.
-
- Without this check, an attacker could reuse an NSEC or NSEC3 RR
- matching a non-delegation name to spoof an unsigned delegation at
- that name. This would claim that an existing signed RRset (or set of
- 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.
-
- 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.
-
- 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.
-
-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
- 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]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
- If the validator does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
- In other words, when determining the security status of a zone, a
- validator disregards any authenticated DS records that specify
- unknown or unsupported DNSKEY algorithms. If none are left, the zone
- is treated as if it were unsigned.
-
- This document modifies the above text to additionally disregard
- authenticated DS records using unknown or unsupported message digest
- algorithms.
-
-5.3. Private Algorithms
-
- 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.
-
- If no private algorithms appear in the DS RRset, or if any supported
- algorithm appears in the DS RRset, no special processing is needed.
- Furthermore, if the validator implementation does not support any
- private algorithms, or only supports private algorithms using an
- algorithm number not present in the DS RRset, no special processing
- is needed.
-
- In the remaining cases, the security status of the zone depends on
- whether or not the resolver supports any of the private algorithms in
- use (provided that these DS records use supported message digest
- algorithms, as discussed in Section 5.2 of this document). In these
- cases, the resolver MUST retrieve the corresponding DNSKEY for each
- private algorithm DS record and examine the public key field to
- determine the algorithm in use. The security-aware resolver MUST
- ensure that the hash of the DNSKEY RR's owner name and RDATA matches
- the digest in the DS RR as described in Section 5.2 of [RFC4035],
- authenticating the DNSKEY. If all of the retrieved and authenticated
- 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]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
- [RFC4035].
-
- This clarification facilitates the broader use of private algorithms,
- as suggested by [RFC4955].
-
-5.4. Caution About Local Policy and Multiple RRSIGs
-
- When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3
- 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."
-
- 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
- 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
- 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
- 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.
-
-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.
-
-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]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
- value of the AD bit in the response. This allows a requestor to
- indicate that it understands the AD bit without also requesting
- DNSSEC data via the DO bit.
-
-5.8. Setting the AD Bit on Replies
-
- Section 3.2.3 of [RFC4035] describes under which conditions a
- validating resolver should set or clear the AD bit in a response. In
- 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.
-
-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.
-
- This document further specifies that validating resolvers SHOULD set
- the CD bit on every upstream query. This is regardless of whether
- the CD bit was set on the incoming query or whether it has a trust
- anchor at or above the QNAME.
-
- [RFC4035] is ambiguous about what to do when a cached response was
- obtained with the CD bit unset, a case that only arises when the
- resolver chooses not to set the CD bit on all upstream queries, as
- specified above. In the typical case, no new query is required, nor
- does the cache need to track the state of the CD bit used to make a
- given query. The problem arises when the cached response is a server
- failure (RCODE 2), which may indicate that the requested data failed
- DNSSEC validation at an upstream validating resolver. ([RFC2308]
- permits caching of server failures for up to five minutes.) In these
- cases, a new query with the CD bit set is required.
-
- Appendix B discusses more of the logic behind the recommendation
- presented in this section.
-
-5.10. Nested Trust Anchors
-
- A DNSSEC validator may be configured such that, for a given response,
- more than one trust anchor could be used to validate the chain of
- 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]
-\f
-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
- of which trust anchor(s) to use. Which to use is a matter of
- implementation choice. Appendix C discusses several possible
- algorithms.
-
- It is possible and advisable to expose the choice of policy as a
- configuration option. As a default, it is suggested that validators
- implement the "Accept Any Success" policy described in Appendix C.2
- while exposing other policies as configuration options.
-
- The "Accept Any Success" policy is to try all applicable trust
- anchors until one gives a validation result of Secure, in which case
- the final validation result is Secure. If and only if all applicable
- trust anchors give a result of Insecure, the final validation result
- is Insecure. If one or more trust anchors lead to a Bogus result and
- there is no Secure result, then the final validation result is Bogus.
-
-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 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
- zone's DS or DNSKEY RRset signals that that algorithm is used to
- sign the entire zone.
-
- A signed zone MUST include a DNSKEY for each algorithm present in
- 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
- 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
- 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.
-
- This requirement applies to servers, not validators. Validators
- SHOULD accept any single valid path. They SHOULD NOT insist that all
- 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]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
- test to support troubleshooting.
-
-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
- validating resolver MUST disregard RRSIGs with algorithm types that
- 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
- the previous section, may require that such RRSIGs be present in a
- zone.
-
-
-6. Minor Corrections and Clarifications
-
-6.1. Finding Zone Cuts
-
- Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
- for a parent zone but does not state how to find those servers.
- Specific instructions can be found in Section 4.2 of [RFC4035].
-
-6.2. Clarifications on DNSKEY Usage
-
- It is possible to use different DNSKEYs to sign different subsets of
- a zone, constrained only by the rules in Section 5.11. It is even
- possible to use a different DNSKEY for each RRset in a zone, subject
- only to practical limits on the size of the DNSKEY RRset and the
- above rules. However, be aware that there is no way to tell
- resolvers what a particular DNSKEY is supposed to be used for -- any
- DNSKEY in the zone's signed DNSKEY RRset may be used to authenticate
- any RRset in the zone. For example, if a weaker or less trusted
- DNSKEY is being used to authenticate NSEC RRsets or all dynamically
- updated records, that same DNSKEY can also be used to sign any other
- RRsets from the zone.
-
- 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.
-
-
-
-
-
-
-Weiler & Blacka Expires January 14, 2013 [Page 12]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
-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
- (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.
-
-6.4. Errors in RFC 5155
-
- A 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:
-
- Blocks with no types present MUST NOT be included.
-
- However, the same section contains a regular expression:
-
- Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
- The plus sign in the regular expression indicates that there is one
- 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:
-
- Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
-
-
-7. IANA Considerations
-
- This document specifies no IANA Actions.
-
-
-8. Security Considerations
-
- This document adds SHA-2 and NSEC3 support to the core DNSSEC
- protocol. Security considerations for those features are discussed
- in the documents defining them. Additionally, this document
- addresses some ambiguities and omissions in the core DNSSEC documents
- that, if not recognized and addressed in implementations, could lead
-
-
-
-Weiler & Blacka Expires January 14, 2013 [Page 13]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
- to security failures. In particular, the validation algorithm
- clarifications in Section 4 are critical for preserving the security
- properties DNSSEC offers. Furthermore, failure to address some of
- the interoperability concerns in Section 5 could limit the ability to
- later change or expand DNSSEC, including adding new algorithms.
-
- The recommendation in Section 5.9 to always set the CD bit has
- security implications. By setting the CD bit, a resolver will not
- benefit from more stringent validation rules or a more complete set
- of trust anchors at an upstream validator.
-
-
-9. References
-
-9.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
- RFC 3225, December 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.
-
- [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.
-
-
-
-
-Weiler & Blacka Expires January 14, 2013 [Page 14]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
-9.2. Informative References
-
- [Huston] Michaelson, G., Wallstrom, P., Arends, R., and G. Huston,
- "Roll Over and Die?", February 2010.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2308, March 1998.
-
- [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.
-
- [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
- November 2007.
-
-
-Appendix A. Acknowledgments
-
- The editors would like the thank Rob Austein for his previous work as
- an editor of this document.
-
- The editors are extremely grateful to those who, in addition to
- finding errors and omissions in the DNSSEC document set, have
- provided text suitable for inclusion in this document.
-
- The lack of specificity about handling private algorithms, as
- described in Section 5.3, and the lack of specificity in handling ANY
- queries, as described in Section 4.2, were discovered by David
- Blacka.
-
- The error in algorithm 1 key tag calculation, as described in
- Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake
- contributed text for Section 5.5.
-
- The bug relating to delegation NSEC RR's in Section 4.1 was found by
- Roy Badami. Roy Arends found the related problem with DNAME.
-
- 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]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
- Text on the mandatory algorithm rules was derived from suggestions by
- Matthijs Mekking and Ed Lewis.
-
- The CD bit logic was analyzed in depth by David Blacka, Olafur
- Gudmundsson, Mike St. Johns, and Andrew Sullivan.
-
- The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
- Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
- Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan,
- Jeremy Reed, Paul Hoffman, Mohan Parthasarathy, Florian Weimer,
- 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
- there is at most one validating system between the stub resolver and
- the authoritative server for a given zone. It is entirely possible,
- 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.
-
- 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,
- not always yield the benefits listed above. It is beyond the scope
- of this document to outline all of the considerations and counter
- considerations for all possible policies. Nevertheless, it is
- possible to describe three approaches and their underlying philosophy
- of operation. These are laid out in the tables below.
-
- The table that describes each model has five columns. The first
- column indicates the value of the CD bit that the resolver receives
- (for instance, on the name server side in an iterative resolver, or
- 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]
-\f
-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.
-
- The tables differentiate between "cached data" and "cached RCODE=2".
- This is a shorthand; the point is that one has to treat RCODE=2
- (server failure) as special, because it might indicate a validation
- failure somewhere upstream. The distinction is really between
- "cached RCODE=2" and "cached everything else".
-
- The tables are probably easiest to think of in terms of describing
- what happens when a stub resolver sends a query to an intermediate
- resolver, but they are perfectly general and can be applied to any
- validating resolver.
-
- Model 1: "always set"
-
- 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
- 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.
- It is the model recommended in Section 5.9 of this document.
-
- CD F/C line conditions action
- ====================================================================
- 1 F A1 Set CD=1 on upstream query
- 0 F A2 Set CD=1 on upstream query
- 1 C A3 Return the cache contents
- (data or RCODE=2)
- 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]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
- 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.
- 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
- 0 F N2 Set CD=0 on upstream query
- 1 C N3 cached data Return cached data
- 1 C N4 cached RCODE=2 Treat as line N1
- 0 C N5 no covering TA Return cache contents
- (data or RCODE=2)
- 0 C N6 covering TA & Treat as line N2
- cached data was
- generated with CD=1
- 0 C N7 covering TA & Validate and return
- cached data was
- generated with CD=0
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka Expires January 14, 2013 [Page 18]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
- 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
- other resolvers for QNAMEs for which it does not have covering trust
- anchors. Using this model is NOT RECOMMENDED.
-
- CD F/C line conditions action
- ====================================================================
- 1 F S1 Set CD=1 on upstream query
- 0 F S2 covering TA Set CD=1 on upstream query
- 0 F S3 no covering TA Set CD=0 on upstream query
- 1 C S4 cached data Return cached data
- 1 C S5 cached RCODE=2 Treat as line S1
- 0 C S6 cached data was Return cache contents
- generated with
- CD=0
- 0 C S7 cached data was Validate & return cache
- generated with contents
- CD=1 &
- covering TA
- 0 C S8 cached RCODE=2 Return cache contents
- 0 C S9 cached data Treat as line S3
- was generated
- with CD=1 &
- no covering
- TA
-
-
-
-Appendix C. Discussion of Trust Anchor Preference Options
-
- This section presents several different policies for validating
- resolvers to use when they have a choice of trust anchors available
- for validating a given answer.
-
-C.1. Closest Encloser
-
- One policy is to choose the trust anchor closest to the QNAME of the
- 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
-
-
-
-Weiler & Blacka Expires January 14, 2013 [Page 19]
-\f
-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
- 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.
-
- This policy has the disadvantage of giving the user some unexpected
- 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.
-
-C.2. Accept Any Success
-
- Another policy is to try all applicable trust anchors until one gives
- a validation result of Secure, in which case the final validation
- result is Secure. If and only if all applicable trust anchors give a
- result of Insecure, the final validation result is Insecure. If one
- or more trust anchors lead to a Bogus result and there is no Secure
- result, then the final validation result is Bogus.
-
- This has the advantage of causing the fewest validation failures,
- which may deliver a better user experience. If one trust anchor is
- out of date (as in our above example), the user may still be able to
- 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
- 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.
-
- For example, a validator might choose to prefer trust anchors found
- in a DLV registry over those manually configured on the theory that
- the manually configured ones will not be as aggressively maintained.
-
-
-
-Weiler & Blacka Expires January 14, 2013 [Page 20]
-\f
-Internet-Draft DNSSEC Implementation Notes July 2012
-
-
- Conversely, a validator might choose to prefer manually configured
- trust anchors over those obtained from a DLV registry on the theory
- that the manually configured ones have been more carefully
- authenticated.
-
- 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
- anchors from a different DLV registry, then the rest of the manually
- configured trust anchors.
-
-
-Authors' Addresses
-
- Samuel Weiler
- SPARTA, Inc.
- 7110 Samuel Morse Drive
- Columbia, Maryland 21046
- US
-
- Email: weiler@tislabs.com
-
-
- David Blacka
- Verisign, Inc.
- 12061 Bluemont Way
- Reston, VA 20190
- US
-
- Email: davidb@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka Expires January 14, 2013 [Page 21]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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, <http://
- csrc.nist.gov/publications/
- fips/fips180-3/
- fips180-3.pdf>.
-
- [FIPS.186-3.2009] National Institute of
- Standards and Technology,
- "Digital Signature
- Standard", FIPS PUB 186-3,
- June 2009, <http://
- csrc.nist.gov/publications/
- fips/fips186-3/
- fips_186-3.pdf>.
-
-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]
-\f
--- /dev/null
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
-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
- -------- ----- ---- -- --- ---
- <draft-ietf-dnsext-ecc-key-07.txt>
+ Elliptic Curve Keys and Signatures in the Domain Name System (DNS)
+ -------- ----- ---- --- ---------- -- --- ------ ---- ------ -----
+ <draft-ietf-dnsext-ecc-key-10.txt>
Richard C. Schroeppel
Donald Eastlake 3rd
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 <namedroppers@ops.ietf.org>.
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
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.
R. Schroeppel, et al [Page 1]
\f
-INTERNET-DRAFT ECC Keys in the DNS
+INTERNET-DRAFT ECC in the DNS
Acknowledgement
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
R. Schroeppel, et al [Page 2]
\f
-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
R. Schroeppel, et al [Page 3]
\f
-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
R. Schroeppel, et al [Page 4]
\f
-INTERNET-DRAFT ECC Keys in the DNS
+INTERNET-DRAFT ECC in the DNS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R. Schroeppel, et al [Page 5]
\f
-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
R. Schroeppel, et al [Page 6]
\f
-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
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.
R. Schroeppel, et al [Page 7]
\f
-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 +
R. Schroeppel, et al [Page 8]
\f
-INTERNET-DRAFT ECC Keys in the DNS
+INTERNET-DRAFT ECC in the DNS
LA,A is the first parameter of the elliptic curve equation.
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.
R. Schroeppel, et al [Page 9]
\f
-INTERNET-DRAFT ECC Keys in the DNS
+INTERNET-DRAFT ECC in the DNS
commonly used.
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.
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.
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.
R. Schroeppel, et al [Page 10]
\f
-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
-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
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]
\f
-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]
\f
-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]
-\f
-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]
+\f
+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.
R. Schroeppel, et al [Page 14]
\f
-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]
\f
-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.
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-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
-
- 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
-
- 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].
-
-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 October 22, 2010.
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 1]
-\f
-Internet-Draft DNAME Redirection April 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 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 2]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
-
- 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4
- 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 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
-
- 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8
- 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 9
- 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 11
- 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11
-
- 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 11
-
- 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 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.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.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
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 3]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
-1. Introduction
-
- 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.
-
- The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
- (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.
-
- 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
- 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".
-
- 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
- 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.
-
- 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.
-
-2. The DNAME Resource Record
-
-2.1. Format
-
- The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is
- not class-sensitive.
-
-
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 4]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
- Its RDATA is comprised of a single field, <target>, which contains a
- fully qualified domain name that must be sent in uncompressed form
- [RFC1035], [RFC3597]. The <target> field MUST be present. The
- presentation format of <target> is that of a domain name [RFC1035].
-
- <owner> <ttl> <class> DNAME <target>
-
- The effect of the DNAME RR is the substitution of the record's
- <target> for its owner name, as a suffix of a domain name. This
- substitution is to be applied for all names below the owner name of
- the DNAME RR. This substitution has to be applied for every DNAME RR
- found in the resolution process, which allows fairly lengthy valid
- chains of DNAME RRs.
-
- Details of the substitution process, methods to avoid conflicting
- resource records, and rules for specific corner cases are given in
- the following subsections.
-
-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.
- 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
- resource record or NS resource record set, the processing of a DNAME
- will happen prior to finding the desired domain name.
-
- A DNAME substitution is performed by replacing the suffix labels of
- the name being sought matching the owner name of the DNAME resource
- record with the string of labels in the RDATA field. The matching
- labels end with the root label in all cases. Only whole labels are
- replaced. See the table of examples for common cases and corner
- cases.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 5]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
- 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
- and a possible error message is returned (if no other result is
- possible). Thus every line contains one example substitution. In
- the examples below, 'cyc' and 'shortloop' contain loops.
-
- QNAME owner DNAME target result
- ---------------- -------------- -------------- -----------------
- com. example.com. example.net. <no match>
- example.com. example.com. example.net. [0]
- 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. <no match>
- foo.example.com. example.com. example.net. foo.example.net.
- a.x.example.com. x.example.com. example.net. a.example.net.
- a.example.com. example.com. y.example.net. a.y.example.net.
- cyc.example.com. example.com. example.com. cyc.example.com.
- cyc.example.com. example.com. c.example.com. cyc.c.example.com.
- shortloop.x.x. x. . shortloop.x.
- shortloop.x. x. . shortloop.
-
- [0] The result depends on the QTYPE. If the QTYPE = DNAME, then
- the result is "example.com." else "<no match>"
-
- 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
- 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
- DNAME record and its signature (if the zone is signed) are included
- in the answer as proof for the YXDOMAIN (value 6) RCODE.
-
-
-
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 6]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
-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.
-
- 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.
-
- 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.
-
-2.4. Names Next to and Below a DNAME Record
-
- Resource records MUST NOT exist at any sub-domain 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.
-
- 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.
-
-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,
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 7]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
- so that a DNAME RR can be treated as an unknown type [RFC3597].
-
- 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.
-
- 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.
-
-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
-
- 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:
-
- 1. The DNAME is being employed as a substitution instruction.
-
- 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.
-
- 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.
-
- 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.
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 8]
-\f
-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.
-
-3.2. Server algorithm
-
- Below is the server algorithm, which appeared 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
- 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.
-
-
- 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
- CNAME, copy the CNAME RR into the answer section of the
- response, change QNAME to the canonical name in the CNAME RR,
- and go back to step 1.
-
- 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.
-
- Copy the NS RRs for the sub-zone into the authority section
- of the reply. Put whatever addresses are available into the
- additional section, using glue RRs if the addresses are not
- available from authoritative data or the cache. Go to step
- 4.
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 9]
-\f
-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.
-
- If a DNAME record exists at that point, copy that record into
- the answer section. If substitution of its <target> for its
- <owner> in QNAME would overflow the legal size for a <domain-
- name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
- perform the substitution and continue. The server MUST
- synthesize a CNAME record as described above and include it
- in the answer section. Go back to step 1.
-
- If there was no DNAME record, look to see if the "*" label
- exists.
-
- If the "*" label does not exist, check whether the name we
- are looking for is the original QNAME in the query or a name
- we have followed due to a CNAME or DNAME. If the name is
- original, set an authoritative name error in the response and
- 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
- set the owner of the RR to be QNAME, and not the node with
- the "*" label. If the data at the node with the "*" label is
- a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
- into the answer section of the response changing the owner
- name to the QNAME, change QNAME to the canonical name in the
- CNAME RR, and go back to step 1. 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
- answer section. If QNAME is not found in the cache but a DNAME
- record is present at an ancestor of QNAME, copy that DNAME record
- into the answer section. If there was no delegation from
- 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
- useful to the additional section of the query. Exit.
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 10]
-\f
-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
- 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
- example.net" SHOULD NOT be used.
-
- 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.
-
- 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.
-
-3.4. Acceptance and Intermediate Storage
-
- Recursive caching name servers can encounter data at names below the
- owner name of a DNAME RR, due to a change at the authoritative server
- where data from before and after the change resides in the cache.
- This conflict situation is a transitional phase that ends when the
- old data times out. The caching name server can opt to store both
- old and new data and treat each as if the other did not exist, or
- drop the old data, or drop the longer domain name. In any approach,
- consistency returns after the older data TTL times out.
-
- 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
- CNAME record received along with it, subject to the rules for CNAME.
-
-4. DNAME Discussions in Other Documents
-
- In [RFC2181], in Section 10.3., the discussion on MX and NS records
- touches on redirection by CNAMEs, but this also holds for DNAMEs.
-
-
-
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 11]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
- Excerpt from 10.3. MX and NS records (in RFC 2181).
-
- 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
- an alias. Not only is the specification clear on this
- point, but using an alias in either of these positions
- neither works as well as might be hoped, nor well fulfills
- the ambition that may have led to this approach. This
- domain name must have as its value one or more address
- records. Currently those will be A records, however in
- the future other record types giving addressing
- 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 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]."
-
-
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 12]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
-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
-
- 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.
-
- 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.
-
-5.2. Dynamic Update and DNAME
-
- 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].
-
-5.3. DNSSEC and DNAME
-
- The following subsections specify the behavior of implementations
- that understand both DNSSEC and DNAME (synthesis).
-
-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
- 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]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
-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.
-
-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.
-
-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.
-
-5.3.4.1. DNAME in Bitmap Causes Invalid Name Error
-
- ;; Header: QR AA RCODE=3(NXDOMAIN)
- ;; OPT PSEUDOSECTION:
- ; EDNS: version: 0, flags: do; udp: 4096
-
- ;; Question
- foo.bar.example.com. IN A
- ;; Authority
- bar.example.com. NSEC dub.example.com. A DNAME
- bar.example.com. RRSIG NSEC [valid signature]
-
- If this is the received response, then only by understanding that the
- DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to
- have been redirected by the DNAME, the validator can see that it is a
- 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
- answer would have validated as a correct name error response.
-
-
-
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 14]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
-5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap
-
- ;; Header: QR AA RCODE=3(NXDOMAIN)
- ;; OPT PSEUDOSECTION:
- ; EDNS: version: 0, flags: do; udp: 4096
-
- ;; Question
- cee.example.com. IN A
- ;; Authority
- bar.example.com. NSEC dub.example.com. A DNAME
- bar.example.com. RRSIG NSEC [valid signature]
-
- This response has the same NSEC records as the example above, but
- 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
-
- ;; Header: QR AA RCODE=0(NOERROR)
- ;; OPT PSEUDOSECTION:
- ; EDNS: version: 0, flags: do; udp: 4096
-
- ;; Question
- foo.bar.example.com. IN A
- ;; Answer
- bar.example.com. DNAME bar.example.net.
- bar.example.com. RRSIG DNAME [valid signature]
- foo.bar.example.com. CNAME foo.bar.example.net.
-
- The response shown above has the synthesized CNAME included.
- However, the CNAME has no signature, since the server does not sign
- online. So this response cannot be trusted. It could be altered by
- 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.
-
-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]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
- 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.
-
- If a validating resolver accepts wildcarded DNAMEs, this creates
- security issues. Since the processing of a wildcarded DNAME is non-
- deterministic and the CNAME that was substituted by the server has no
- signature, the resolver may choose a different result than what the
- server meant, and consequently end up at the wrong destination. Use
- of wildcarded DNAMEs is discouraged in any case [RFC4592].
-
- A validating resolver MUST understand DNAME, according to [RFC4034].
- The examples in Section 5.3.4 illustrate this need.
-
-8. 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
- Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred
- Hoenes and Kevin Darcy for their review and comments on this
- document.
-
-9. References
-
-9.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.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [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]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
- (RR) Types", RFC 3597, September 2003.
-
- [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.
-
- [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
- System", RFC 4592, July 2006.
-
- [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of
- Existence", RFC 5155, March 2008.
-
-9.2. Informative References
-
- [RFC1912] Barr, D., "Common DNS Operational and Configuration
- Errors", RFC 1912, February 1996.
-
- [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
- RFC 2672, 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.
-
- [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
- April 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 17]
-\f
-Internet-Draft DNAME Redirection April 2010
-
-
-Authors' Addresses
-
- Scott Rose
- NIST
- 100 Bureau Dr.
- Gaithersburg, MD 20899
- USA
-
- Phone: +1-301-975-8439
- Fax: +1-301-975-6238
- EMail: scottr.nist@gmail.com
-
-
- Wouter Wijngaards
- NLnet Labs
- Science Park 140
- Amsterdam 1098 XG
- The Netherlands
-
- Phone: +31-20-888-4551
- EMail: wouter@nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires October 22, 2010 [Page 18]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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 (<QNAME, QTYPE, QCLASS>) 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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, class, server IP address>. 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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] <http://www.as112.net>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 20]
-\f
-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]
-\f
-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]
-\f
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
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]
-\f
-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]
+\f
+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
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
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]
+\f
+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]
+\f
+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.
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]
\f
-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
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,
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
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]
\f
-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
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
-Wijngaards & Kolkman Expires August 26, 2010 [Page 4]
+
+Wijngaards & Kolkman Expires December 31, 2010 [Page 6]
\f
-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.
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
-
-Wijngaards & Kolkman Expires August 26, 2010 [Page 5]
+Wijngaards & Kolkman Expires December 31, 2010 [Page 7]
\f
-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
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]
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
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]
-\f
-Internet-Draft Trust History Service February 2010
+Wijngaards & Kolkman Expires December 31, 2010 [Page 8]
+\f
+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
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]
\f
-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.
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.
-
-Wijngaards & Kolkman Expires August 26, 2010 [Page 8]
+Wijngaards & Kolkman Expires December 31, 2010 [Page 10]
\f
-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.
-Wijngaards & Kolkman Expires August 26, 2010 [Page 9]
+Wijngaards & Kolkman Expires December 31, 2010 [Page 11]
\f
+++ /dev/null
-
-
-
-DNSOP W. Hardaker
-Internet-Draft Sparta, Inc.
-Intended status: Informational February 12, 2009
-Expires: August 16, 2009
-
-
- Requirements for Management of Name Servers for the DNS
- draft-ietf-dnsop-name-server-management-reqs-02.txt
-
-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 16, 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 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.
-
-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]
-\f
-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.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
- 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5
- 1.1.2. 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.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
- 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
- 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
- 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
- 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
- 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
- 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
- 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
- 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
- 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
- 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
- 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
- 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.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
- 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10
- 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
- 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
- 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
- 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
- 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11
- 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]
-\f
-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
- A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
- A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
- A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 3]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-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.
-
- Previous standardization work within the IETF resulted in the
- 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].
-
- 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.
-
- 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.
-
- 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
- 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
- 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.
-
-1.1. Requirements notation
-
- 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].
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 4]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-1.1.1. Terminology
-
- This document is consistent with the terminology defined in Section 2
- of [RFC4033]. Additional terminology needed for this document is
- described below:
-
- 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
- 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
-
- The 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
- additional related requirements. The document is laid out in this
- way so that a specific requirement can be uniquely referred to using
- 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
- expected deployment environments.
-
-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
- 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
- deployment cases as possible. Further deployment scenarios that are
- 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]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- 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.
-
-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
- within a deployed network.
-
-2.1.3. Configuration Data Volatility
-
- 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.
-
-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
- 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.
-
-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
-
-
-
-Hardaker Expires August 16, 2009 [Page 6]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- 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
- specification, as discussed further in Section 5.1.
-
-2.1.6. Operational Impact
-
- 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
- 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.
-
-2.2. Name Server Types
-
- There are multiple ways in which name servers can be deployed. Name
- servers can take on any of the following roles:
-
- o Master Servers
-
- o Slave Servers
-
- o Recursive Servers
-
- The management solution SHOULD support all of these types of name
- servers as they are all equally important. Note that "Recursive
- Servers" can be further broken down by the security sub-roles they
- might implement, as defined in section 2 of [RFC4033]. These sub-
- 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.
-
-
-3. Management Operation Types
-
- Management operations can traditionally be broken into four
- categories:
-
- o Control
-
- o Configuration
-
- o Health and Monitoring
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 7]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- o Alarms and Events
-
- This section discusses requirements for each of these four management
- types in detail.
-
-3.1. Control Requirements
-
- The management solution MUST be capable of performing basic service
- control operations.
-
-3.1.1. Needed Control Operations
-
- These operations SHOULD include, at a minimum, the following
- operations:
-
- o Starting the name server
-
- o Reloading the service configuration
-
- o Reloading zone data
-
- o Restarting the name server
-
- o Stopping the name server
-
- Note that no restriction is placed on how the management system
- implements these operations. In particular, at least "starting the
- name server" will require a minimal management system component to
- exist independently of the name server itself.
-
-3.1.2. Asynchronous Status Notifications
-
- Some control operations might take a long time to complete. As an
- example, some name servers take a long time to perform reloads of
- large zones. Because of these timing issues, the management solution
- 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
- 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]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-3.2. Configuration Requirements
-
- Many features of name servers need to be configured before the server
- can be considered functional. The management solution MUST be able
- to provide name servers with configuration data. The most important
- data to be configured, for example, is the served zone data itself.
-
-3.2.1. Served Zone Modification
-
- 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.
-
-3.2.2. Trust Anchor Management
-
- 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
- Records (RRs) themselves or by using Delegation Signer (DS)
- fingerprints.
-
-3.2.3. Security Expectations
-
- 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
- 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
- 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]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- 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 certain zone data from certain sources (e.g. from
- particular network subnets)
-
- 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
- protections.
-
-3.3. Monitoring Requirements
-
- 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:
-
- o Number of requests sent, responses sent, average response latency
- and other performance counters
-
- o Server status (e.g. "serving data", "starting up", "shutting
- down", ...)
-
- 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).
-
- 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
-
- 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]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- 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 A needed resource (e.g. memory or disk space) is exhausted or
- nearing exhaustion
-
- 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.
-
-
-4. Security Requirements
-
- The management solution will need to be appropriately secured against
- attacks on the management infrastructure.
-
-4.1. Authentication
-
- The solution MUST support mutual authentication. The management
- client needs to be assured that the management operations are being
- transferred to and from the correct name server. The managed name
- server needs to authenticate the system that is accessing the
- management infrastructure within itself.
-
-4.2. Integrity Protection
-
- Management operations MUST be protected from modification while in
- transit from the management client to the server.
-
-4.3. Confidentiality
-
- The management solution MUST support message confidentiality. The
- potential transfer of sensitive configuration is expected (such as
- TSIG keys or security policies). The solution does not, however,
- 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]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- 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
- authorization to perform the given management task. Example
- authorization settings that the solution might need to cover are:
-
- o Access to the configuration that specifies which zones are to be
- served
-
- o Access to the management system infrastructure
-
- o Access to other control operations
-
- o Access to other configuration operations
-
- o Access to monitoring operations
-
- Note: the above list is expected to be used as a collection of
- examples and is not a complete list of needed authorization
- protections.
-
-4.5. Solution Impacts on Security
-
- The solution MUST minimize the security risks introduced to the
- complete name server system. It is impossible to add new
- infrastructure to a server and not impact the security in some
- fashion as the introduction of a management protocol alone will
- provide a new avenue for potential attack. Although the added
- 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
- 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]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-5.1.1. Vendor Extensions
-
- It MUST be possible for vendors to extend the standardized management
- model with vendor-specific extensions to support additional features
- offered by their products.
-
-5.1.2. Extension Identification
-
- 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.
-
-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.
-
-
-6. Security Considerations
-
- Any management protocol that meets the criteria discussed in this
- document needs to 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
- 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. 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
- the March 2008 IETF meeting in Philadelphia. This document is a
-
-
-
-Hardaker Expires August 16, 2009 [Page 13]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- compilation of the results of those discussions as well as
- discussions on the DCOMA mailing list.
-
-
-9. 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.
-
- 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.
-
-
-10. References
-
-10.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.
-
- [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
- August 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-
-
-
-Hardaker Expires August 16, 2009 [Page 14]
-\f
-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.
-
- [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.
-
- [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
- [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
- Trust Anchors", RFC 5011, September 2007.
-
- [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of
- Existence", RFC 5155, March 2008.
-
-10.2. Informative References
-
- [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions",
- RFC 1611, May 1994.
-
- [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
- RFC 1612, May 1994.
-
- [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
- and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
- July 1997.
-
- [RFC3197] Austein, R., "Applicability Statement for DNS MIB
- 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]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- 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-
- 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.
-
- 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
- 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).
-
- The configuration of these relationships are currently required to be
- manually configured and maintained. Changes to the list of zones
- that are cross-hosted are manually negotiated between the cooperating
- network administrators and configured by hand. A management protocol
- with the ability to provide selective authorization, as discussed in
- 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]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- strategies.
-
- All contents and DNSSEC keying information controlled and operated
- by a single organization
-
- Zone contents controlled and operated by one organization, all
- DNSSEC keying information controlled and operated by a second
- organization.
-
- Zone contents controlled and operated by one organization, zone
- signing keys (ZSKs) controlled and operated by a second
- organization, and key signing keys (KSKs) controlled and operated
- by a third organization.
-
- Although this list is not exhaustive in the potential ways that zone
- data can be divided up, it should be sufficient to illustrate the
- potential ways in which zone data can be controlled by multiple
- 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
- 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
- Sparta, Inc.
- P.O. Box 382
- Davis, CA 95617
- US
-
- Phone: +1 530 792 1913
- Email: ietf@hardakers.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 17]
-\f
+++ /dev/null
-
-
-
-
-
-
- DNSOP Working Group Paul Vixie, ISC
- INTERNET-DRAFT Akira Kato, WIDE
- <draft-ietf-dnsop-respsize-06.txt> 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]
-\f
- 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]
-\f
- 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]
-\f
- 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]
-\f
- 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]
-\f
- 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]
-\f
- 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]
-\f
- 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]
-\f
- 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]
-\f
- 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]
-\f
- 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]
-\f
- 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]
-\f
-
--- /dev/null
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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 <to be assigned>.
-
- 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]
-\f
-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 <Preference> 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]
-\f
-Internet Draft -6-29 MAY 2012
-
-
-2.1.3 NID RR Examples
-
- An NID record has the following logical components:
- <owner-name> IN NID <Preference> <NodeID>
-
- In the above, <owner-name> is the owner name string, <Preference>
- is an unsigned 16-bit value, and <NodeID> 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]
-\f
-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 <to be assigned>.
-
- 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 <Preference> 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 <Locator32> 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]
-\f
-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:
- <owner-name> IN L32 <Preference> <Locator32>
-
- In the above <owner-name> is the owner name string, <Preference>
- is an unsigned 16-bit value, and <Locator32> 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]
-\f
-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 <to be assigned>.
-
- 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]
-\f
-Internet Draft -10-29 MAY 2012
-
-
- + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-2.3.1.1 The Preference field
-
- The <Preference> 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 <Locator64> 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:
- <owner-name> IN L64 <Preference> <Locator64>
-
- In the above, <owner-name> is the owner name string, <Preference>
- is an unsigned 16-bit value, while <Locator64> 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]
-\f
-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]
-\f
-Internet Draft -12-29 MAY 2012
-
-
- The type value for the LP RR type is X-LP-X <to be assigned>.
-
- 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 <Preference> 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]
-\f
-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:
- <owner-name> IN LP <Preference> <FQDN>
-
- In the above, <owner-name> is the owner name string, <Preference>
- is an unsigned 16-bit value, while <FQDN> 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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.
- <http://dx.doi.org/10.1109/INFCOMW.2011.5928919>
-
- [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.
- <http://dx.doi.org/10.1109/TNET.2002.803905>
-
- [PHG02] Andreas Pappas, Stephen Hailes, Raffaele Giaffreda,
- "Mobile Host Location Tracking through DNS",
- IEEE London Communications Symposium, London,
- England, UK, September 2002.
- <http://www.ee.ucl.ac.uk/lcs/papers2002/LCS072.pdf>
-
- [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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-Internet Draft -22-29 MAY 2012
-
-
- Expires: 29 NOV 2012
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Atkinson et alia Expires in 6 months [Page 22]
-\f
\ No newline at end of file
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
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
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]
\f
-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
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
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]
\f
-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
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]
+\f
+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
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]
-\f
-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]
+\f
+Internet-Draft Child Parent Synchronization December 2010
+
+
Step 2: Verify that the updates matches the update policy for child
zones.
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
key math.example.com. {
algorithm HMAC-MD5;
-
-
-
-Mekking Expires December 31, 2010 [Page 4]
-\f
-Internet-Draft Child Parent Synchronization June 2010
-
-
secret "secretformath";
}
};
};
-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]
+\f
+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]
+\f
+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
[keytiming] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
Timing Considerations", March 2010.
-
-
-Mekking Expires December 31, 2010 [Page 5]
-\f
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-Mekking Expires December 31, 2010 [Page 6]
+Mekking Expires June 24, 2011 [Page 7]
\f
Network Working Group J. Yao\r
Internet-Draft X. Lee\r
Intended status: Standards Track CNNIC\r
-Expires: February 12, 2011 P. Vixie\r
+Expires: February 20, 2011 P. Vixie\r
Internet Software Consortium\r
- August 11, 2010\r
+ August 19, 2010\r
\r
\r
- Bundle DNS Name Redirection\r
- draft-yao-dnsext-bname-04.txt\r
+ Bundled DNS Name Redirection\r
+ draft-yao-dnsext-bname-05.txt\r
\r
Abstract\r
\r
time. It is inappropriate to use Internet-Drafts as reference\r
material or to cite them other than as "work in progress."\r
\r
- This Internet-Draft will expire on February 12, 2011.\r
+ This Internet-Draft will expire on February 20, 2011.\r
\r
Copyright Notice\r
\r
\r
\r
\r
-Yao, et al. Expires February 12, 2011 [Page 1]\r
+Yao, et al. Expires February 20, 2011 [Page 1]\r
\f\r
Internet-Draft bname August 2010\r
\r
3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4\r
3.2. The BNAME Substitution . . . . . . . . . . . . . . . . . . 4\r
3.3. The BNAME Rules . . . . . . . . . . . . . . . . . . . . . 4\r
- 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . . 4\r
+ 3.4. BNAME Examples . . . . . . . . . . . . . . . . . . . . . . 4\r
+ 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . . 5\r
4.1. Processing by Servers . . . . . . . . . . . . . . . . . . 5\r
4.2. Processing by Resolvers . . . . . . . . . . . . . . . . . 8\r
5. BNAME in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 9\r
5.1. BNAME validating . . . . . . . . . . . . . . . . . . . . . 9\r
5.2. BNAME alias algorithm identifiers . . . . . . . . . . . . 10\r
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10\r
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10\r
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11\r
- 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11\r
- 9.1. draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 11\r
- 9.2. draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 11\r
- 9.3. draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 11\r
- 9.4. draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 11\r
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12\r
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12\r
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 13\r
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Yao, et al. Expires February 12, 2011 [Page 2]\r
+ 5.3. Signaling of BNAME . . . . . . . . . . . . . . . . . . . . 10\r
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11\r
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12\r
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12\r
+ 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 12\r
+ 9.1. draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 12\r
+ 9.2. draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 12\r
+ 9.3. draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 12\r
+ 9.4. draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 12\r
+ 9.5. draft-yao-dnsext-bname: Version 04 . . . . . . . . . . . . 13\r
+ 9.6. draft-yao-dnsext-bname: Version 05 . . . . . . . . . . . . 13\r
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13\r
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13\r
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 14\r
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14\r
+\r
+\r
+\r
+\r
+Yao, et al. Expires February 20, 2011 [Page 2]\r
\f\r
Internet-Draft bname August 2010\r
\r
\r
\r
\r
-Yao, et al. Expires February 12, 2011 [Page 3]\r
+Yao, et al. Expires February 20, 2011 [Page 3]\r
\f\r
Internet-Draft bname August 2010\r
\r
restriction applies only to records of the same class as the BNAME\r
record.\r
\r
+3.4. BNAME Examples\r
\r
-4. Query Processing\r
+ The table below shows some examples of the BNAME usage.\r
\r
- To exploit the BNAME mechanism the name resolution algorithms\r
\r
\r
\r
-Yao, et al. Expires February 12, 2011 [Page 4]\r
+Yao, et al. Expires February 20, 2011 [Page 4]\r
\f\r
Internet-Draft bname August 2010\r
\r
\r
+ QNAME owner BNAME target result\r
+ ---------------- -------------- -------------- -----------------\r
+ com. example.com. example.net. <no match>\r
+ com. com. net. net.\r
+ example.com. example.com. example.net. example.net.\r
+ a.example.com. example.com. example.net. a.example.net.\r
+ a.b.example.com. example.com. example.net. a.b.example.net.\r
+ ab.example.com. b.example.com. example.net. <no match>\r
+ bar.example.com. example.com. example.net. bar.example.net.\r
+ a.b.example.com. b.example.com. example.net. a.example.net.\r
+ a.example.com. example.com. b.example.net. a.b.example.net.\r
+\r
+ Table 1. BNAME Usage Examples.\r
+\r
+\r
+ If the owner name of the CNAME RR is regarded as the target of the MX\r
+ RR, it may cause some problems. Some mail servers may directly\r
+ connect the owner name of the CNAME instead of the name pointed by\r
+ CNAME for mail delivery and cause the undelivery of the mails. BNAME\r
+ has the similar problems with CNAME. This document specifies that\r
+ the owner name of the BNAME should not be the targets of some RRs\r
+ such as MX, SRV and PTR. In case that the owner name of the BNAME RR\r
+ is the target of some RRs, it should be cautious.\r
+\r
+\r
+4. Query Processing\r
+\r
+ To exploit the BNAME mechanism the name resolution algorithms\r
[RFC1034] must be modified slightly for both servers and resolvers.\r
Both modified algorithms incorporate the operation of making a\r
substitution on a name (either QNAME or SNAME) under control of a\r
\r
If the owner name of the bname is same with the name queryed, when\r
preparing a response, a server performing a BNAME substitution will\r
- not include the relevant BNAME RR in the answer section unless the\r
- type queryed is BNAME. A CNAME RR will be synthesized and included\r
- in the answer section unless the type queryed is BNAME or the query\r
- is the DNSSEC query.\r
-\r
- The provided synthesized CNAME RR if there has one, MUST have\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
\r
\r
\r
+Yao, et al. Expires February 20, 2011 [Page 5]\r
+\f\r
+Internet-Draft bname August 2010\r
\r
\r
+ not include the relevant BNAME RR in the answer section unless the\r
+ type queryed is BNAME. A CNAME RR will be synthesized and included\r
+ in the answer section unless the type queryed is BNAME.\r
\r
+ The provided synthesized CNAME RR if there has one, MUST have\r
\r
-Yao, et al. Expires February 12, 2011 [Page 5]\r
-\f\r
-Internet-Draft bname August 2010\r
\r
\r
The same CLASS as the QCLASS of the query,\r
\r
\r
\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Yao, et al. Expires February 12, 2011 [Page 6]\r
+Yao, et al. Expires February 20, 2011 [Page 6]\r
\f\r
Internet-Draft bname August 2010\r
\r
\r
\r
\r
-Yao, et al. Expires February 12, 2011 [Page 7]\r
+Yao, et al. Expires February 20, 2011 [Page 7]\r
\f\r
Internet-Draft bname August 2010\r
\r
\r
\r
\r
-Yao, et al. Expires February 12, 2011 [Page 8]\r
+Yao, et al. Expires February 20, 2011 [Page 8]\r
\f\r
Internet-Draft bname August 2010\r
\r
\r
\r
\r
-Yao, et al. Expires February 12, 2011 [Page 9]\r
+Yao, et al. Expires February 20, 2011 [Page 9]\r
\f\r
Internet-Draft bname August 2010\r
\r
algorithm identifiers are used with the BNAME hash algorithm SHA1.\r
Using other BNAME hash algorithms requires allocation of a new alias.\r
Validating resolvers which follow the BNAME specification MUST\r
- recognize the new alias algorithm identifier.\r
+ recognize the new alias algorithm identifier. The future new DNSSEC\r
+ algorithms are suggested to indicate the support of BNAME.\r
+\r
+5.3. Signaling of BNAME\r
+\r
+ A new UB (Understand BNAME) bit in the EDNS flags field [RFC2671]can\r
+ be used to signal that the resolvers can understand BNAME in DNSSEC.\r
+ BNAME aware resolvers can set the Understand-BNAME (UB bit) to\r
+ receive a response without the synthesized CNAMEs. The UB bit is\r
+ part of the EDNS extended RCODE and Flags field[RFC2671]. Resolvers\r
+ should set this in a query to request omission of the synthesized\r
+ CNAMEs.\r
+\r
+ If the query is a DNSSEC query, the BNAME enabled resolvers MUST set\r
+ the UB bit in the query. The server receiving the UB bit MUST not\r
+ issue synthesized CNAMEs. Servers copy the UB bit to the response,\r
+ and should delete the synthesized CNAMEs from the answer if there has\r
+\r
+\r
+\r
+Yao, et al. Expires February 20, 2011 [Page 10]\r
+\f\r
+Internet-Draft bname August 2010\r
+\r
+\r
+ one.\r
+\r
+ If the query is the DNSSEC query but the UB bit is not set, the\r
+ server should follow the rules below:\r
+ o If the owner name of the bname is the suffix of the name queryed\r
+ but different, when preparing a response, a server performing a\r
+ BNAME substitution will in all cases include the relevant BNAME RR\r
+ in the answer section. An unsigned CNAME RR is synthesized and\r
+ included in the answer section. This will help the client to\r
+ reach the correct DNS data.\r
+ o If the owner name of the bname is same with the name queryed, when\r
+ preparing a response, a DNSSEC enabled server performing a BNAME\r
+ substitution will not include the relevant BNAME RR and its RRSIG\r
+ RR in the answer section unless the type queryed is BNAME. An\r
+ unsigned CNAME RR will be synthesized and included in the answer\r
+ section unless the type queryed is BNAME.\r
+ o Since the BNAME-unaware DNSSEC resolvers do not know the alias\r
+ algorithm defined in secton 5.2 of this document, any response\r
+ from these zones signed with these alias algorithms unknown to\r
+ them will be regarded as the insecure one according to section 5.2\r
+ of [RFC4035].\r
+\r
+ Below are Updated EDNS extended RCODE and Flags fields [RFC2671]:\r
+\r
+\r
+ +0 (MSB) +1 (LSB)\r
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
+ 0: | EXTENDED-RCODE | VERSION |\r
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
+ 2: |DO|UB| Z |\r
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
+\r
+\r
\r
\r
6. IANA Considerations\r
the IANA registry "DNS SECURITY ALGORITHM NUMBERS". IANA is\r
requested to assign the number to Y and Z.\r
\r
- [[anchor14: Note in draft: before this document goes to WG Last call,\r
+ [[anchor15: Note in draft: before this document goes to WG Last call,\r
it is better that we list all DNSSEC algorithms that need to be\r
aliased to reflect compatibility with this extension.]]\r
\r
\r
-7. Security Considerations\r
\r
- Both ASCII domain name labels and non-ASCII ones have some aliases.\r
\r
\r
\r
-Yao, et al. Expires February 12, 2011 [Page 10]\r
+\r
+Yao, et al. Expires February 20, 2011 [Page 11]\r
\f\r
Internet-Draft bname August 2010\r
\r
\r
+7. Security Considerations\r
+\r
+ Both ASCII domain name labels and non-ASCII ones have some aliases.\r
We can bundle the domain name labels and their aliases through BNAME\r
in the DNS resolutions. The name labels and their aliases in the\r
particular languages are only known by those who know these\r
\r
9. Change History\r
\r
- [[anchor17: RFC Editor: Please remove this section.]]\r
+ [[anchor18: RFC Editor: Please remove this section.]]\r
\r
9.1. draft-yao-dnsext-bname: Version 00\r
\r
o Update the IANA consideration\r
\r
\r
-10. References\r
\r
\r
\r
-\r
-\r
-Yao, et al. Expires February 12, 2011 [Page 11]\r
+Yao, et al. Expires February 20, 2011 [Page 12]\r
\f\r
Internet-Draft bname August 2010\r
\r
\r
+9.5. draft-yao-dnsext-bname: Version 04\r
+\r
+ o Improve the text\r
+\r
+9.6. draft-yao-dnsext-bname: Version 05\r
+\r
+ o add section: bname examples\r
+ o add section: Signaling of BNAME\r
+\r
+\r
+10. References\r
+\r
10.1. Normative References\r
\r
[ASCII] American National Standards Institute (formerly United\r
(RR) Types", RFC 3597, September 2003.\r
\r
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO\r
+\r
+\r
+\r
+Yao, et al. Expires February 20, 2011 [Page 13]\r
+\f\r
+Internet-Draft bname August 2010\r
+\r
+\r
10646", RFC 3629, November 2003.\r
\r
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint\r
RFC 4033, March 2005.\r
\r
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.\r
-\r
-\r
-\r
-Yao, et al. Expires February 12, 2011 [Page 12]\r
-\f\r
-Internet-Draft bname August 2010\r
-\r
-\r
Rose, "Resource Records for the DNS Security Extensions",\r
RFC 4034, March 2005.\r
\r
Email: yaojk@cnnic.cn\r
\r
\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Yao, et al. Expires February 20, 2011 [Page 14]\r
+\f\r
+Internet-Draft bname August 2010\r
+\r
+\r
Xiaodong LEE\r
CNNIC\r
No.4 South 4th Street, Zhongguancun\r
\r
\r
\r
-Yao, et al. Expires February 12, 2011 [Page 13]\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Yao, et al. Expires February 20, 2011 [Page 15]\r
\f\r
\r
\r
projects / thirdparty / bind9.git / commitdiff
