INTERNET-DRAFT Eric A. Hall Document: draft-hall-qtype-addr-01.txt November 2003 Expires: May 2004 DNS Mechanisms for Providing All Address Types Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract This document defines mechanisms for providing all IP address resource records (specifically including any A and AAAA resource records) in DNS response messages. Specifically, this document defines an "ADDR" query-type which allows a system to issue a single lookup for all of the addressing resource records associated with a domain name (explicitly including any IPv4 and IPv6 resource records), and also defines an algorithm for DNS servers to use when returning supplemental address data in the additional-data section of a response message. Internet Draft draft-hall-qtype-addr-01.txt November 2003 Table of Contents 1. Prerequisites and Terminology..............................2 2. Introduction and Overview..................................2 3. The ADDR Query-Type........................................4 3.1. Basic Handling..........................................4 3.2. Ensuring Valid Answer Sets..............................5 3.3. Time-To-Live Values.....................................6 3.4. CNAME Processing........................................7 3.5. Truncated ADDR Responses................................7 3.6. Error Responses.........................................8 3.7. ADDR Query-Type Examples................................9 4. All-Addresses Additional Data.............................10 4.1. Truncated Additional-Data..............................11 4.2. Additional-Data Examples...............................11 5. Security Considerations...................................12 6. IANA Considerations.......................................12 7. Author's Addresses........................................12 8. Normative References......................................12 9. Informative References....................................12 10. Acknowledgments...........................................12 11. Full Copyright Statement..................................13 1. Prerequisites and Terminology This specification incorporates elements from multiple existing specifications. At a minimum, readers of this document need to be familiar with [RFC1035], [RFC1886], [RFC2181], and [RFC2308]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Introduction and Overview Internet applications have historically only needed to issue a single query for a single resource record type in order to determine the IPv4 address of a destination node. As more IPv6 and dual-stack systems are deployed, however, there is a significant likelihood that these newer systems will have to issue multiple queries in order to locate any available addresses, first asking for the IPv6 addresses of the target host, and then issuing subsequent queries for any IPv4 addresses in those cases where no Hall I-D Expires: May 2004 [page 2] Internet Draft draft-hall-qtype-addr-01.txt November 2003 IPv6 addresses are defined. In these situations, multiple queries are frequently needed in order for the sending host to determine the networking capabilities of the target host. Furthermore, several pre-existing queries and resource records also return IPv4 address resource records as supplemental data, but do not return any related IPv6 address resource records (EG, queries for Mail Exchange resource records usually cause the IPv4 address resource records of the target host to be provided as supplemental data, but not the IPv6 address resource records of that host). When these responses are received, the querying host may be required to issue additional (separate) lookups for any IPv6 addressing resource records defined for the target host, in order to determine its networking capabilities. Individually, each of these additional queries are minor, although they can cumulatively represent a significant amount of overall query traffic. Meanwhile, the Internet's history with the Simple Mail Transfer Protocol (SMTP) [SMTP] illustrates that the use of multiple resource records can sometimes lead implementers towards problematic shortcuts, in that they attempt to streamline the process by issuing a single lookup with the query-type of "ALL", in the hopes that all of the applicable resource records will be returned, although this approach can frequently produce incomplete results. Unfortunately, if history is any indicator of future trends, this approach is somewhat likely to be pursued by at least some IPv6-aware applications as well. In order to prevent these kinds of problems from emerging, this document defines two mechanisms for providing all of the IPv4 and IPv6 address resource records associated with a target host in a single response message, thereby alleviating the need for querying systems to issue multiple discrete lookups in order to determine the networking capabilities of the target host. Specifically, this document defines an "ADDR" query-type which allows a system to issue a single lookup for all of the addressing resource records associated with a domain name (explicitly including any IPv4 and IPv6 resource records), and also defines an algorithm for DNS servers to use to use when returning supplemental address data in the additional-data section of a response message. Note that these mechanisms are intended to serve as transitional aids, in that they do not require infinite maintenance. If and when a querying system moves to a single IPv6 stack (as opposed to the dual-stack approach common during the transitional period), the use of the ADDR query-type can be discontinued. Similarly, as Hall I-D Expires: May 2004 [page 3] Internet Draft draft-hall-qtype-addr-01.txt November 2003 host entries in the DNS move to IPv6 only (as opposed to having IPv4 and IPv6 addresses simultaneously as is common during the transitional period), only the IPv6 answer data will be returned. In this regard, the mechanisms described in this specification provide built-in exit strategies. 3. The ADDR Query-Type The ADDR query-type has a code value of [TBD IANA], and the mnemonic of "ADDR". ADDR is a query-type only, not a resource record type, and therefore does not define any data structures. The following sub-sections define handling rules which MUST be implemented by a responder which claims to support the ADDR query- type. If a responder is unable or unwilling to comply with each and every one of these requirements, it MUST reject queries for the ADDR query-type with an appropriate error response, as defined in section 3.6 below. For undefined cases, the rules defined in [RFC1035] and [RFC2308] MUST be followed, as appropriate to the scenario at hand. 3.1. Basic Handling DNS responders which receive and process requests for the ADDR query-type (including authoritative and non-authoritative servers, local caches, or any other responding agent) MUST respond with all of the A and AAAA resource records associated with the domain name specified in the query name field of the question section. If the queried domain name is known not to exist, a NXDOMAIN response MUST be returned, as defined in [RFC2308]. If the queried domain name is known to exist but does not have any associated AAAA or A resource records, a Type 1 NODATA response MUST be returned, as defined in [RFC2308]. If the queried domain name is known to exist and has A and AAAA resource records, those resource records MUST be provided in the answer section of the response message. Hall I-D Expires: May 2004 [page 4] Internet Draft draft-hall-qtype-addr-01.txt November 2003 In those cases where only one type of resource record exists (such as AAAA resource records, the section of the response MUST contain the Start-of-Authority resource record for the controlling zone. The presence of this resource record in conjunction with an incomplete answer section is intended to provide negative caching hinting data for the missing resource records, essentially emulating the Type 1 NODATA response described in [RFC2308]. 3.2. Ensuring Valid Answer Sets This specification requires that a responder only answer ADDR queries if the responder is capable of obtaining and providing complete and accurate representations of the canonical A and AAAA resource records associated with the target domain name. It is imperative that answers to ADDR queries MUST only be provided in their complete form. Providing erroneous or incomplete data can cause significant problems to occur with the users of that data, and incomplete answers MUST NOT be sent (see the discussion on truncation in section 3.5 below). If any of the canonical resource record sets are missing from the responder's view of the data (either because those resource records have not yet been obtained or have expired), the missing data MUST be acquired before the ADDR query is answered. In the case of authoritative servers responding to ADDR queries, the answer data can (obviously) be sourced from an authoritative database. In the case of a cache or forwarding server, however, this will have to be achieved by either forwarding the original ADDR query to another server (where it will presumably reach an authoritative server sooner or later), or by issuing separate (independent) queries for the AAAA and A resource records associated with the domain name in question. Data which has been cached from previous queries SHOULD be used to answer current queries (assuming that the time-to-live values and other factors allow it), as per usual DNS behavior. In those cases where a non-authoritative responder has existing knowledge of only one resource record, the responder SHOULD issue the minimum number of queries necessary to fill in gaps (such as limiting back-end queries to just the missing resource records), and SHOULD NOT unnecessarily refresh data which is already known. Hall I-D Expires: May 2004 [page 5] Internet Draft draft-hall-qtype-addr-01.txt November 2003 If either or both of the canonical A or AAAA resource records have been discovered not to exist (such as will occur upon receipt of NODATA responses to any of the above queries), the negative answer MUST be associated with the missing resource records according to the rules defined in [RFC2308], with this knowledge being used to construct the query response. Note that caches and forwarding agents will sometimes need to issue discrete queries for the Start-of-Authority resource record associated with the authoritative zone in order to satisfy these requirements. In particular, if a responder receives non-Type 1 NODATA responses to discrete A and AAAA lookups, the responder will need to fetch the SOA resource record in order to provide a complete and accurate answer. If all of the answer data is obtained from an authoritative source as a result of the current ADDR query (regardless of whether or not discrete lookups were used), the Authoritative Answer flag in the response message MUST be enabled, as per usual behavior. If any of the answer data came from a non-authoritative source (EG, one of resource record sets was already cached), the Authoritative Answer flag in the response message MUST NOT be enabled. If a full and complete view of the canonical A and AAAA resource records cannot be obtained, a positive answer MUST NOT be returned, and an appropriate error response MUST be returned instead. Refer to section 3.6 below for more information. 3.3. Time-To-Live Values Choosing the appropriate time-to-live values for an ADDR response will be based upon multiple factors, and will therefore vary for different scenarios. A responder MUST NOT increase the time-to-live value for any of the canonical resources record beyond their original values, under any circumstances. Each set of AAAA and A resource records MUST be synchronized to their lowest common values individually, as per the rules set forth in [RFC2181]. For example, all of the A resource records MUST have the same time-to-live value, but these are not required to be the same time-to-live value of the AAAA resource records. Hall I-D Expires: May 2004 [page 6] Internet Draft draft-hall-qtype-addr-01.txt November 2003 Responders MAY synchronize the time-to-live values of all resource records to the lowest common value, but this is not required. Note that the time-to-live values may be synchronized for reasons unrelated to the ADDR query-type. For example, resource records which were learned as referral glue could have had their time-to- live values synchronized by another responder already, without any input or effort by the current system. 3.4. CNAME Processing If the target domain name has a CNAME resource record which references some other domain name, and if the Recursion Desired bit has been enabled in the query, and if the responder is willing to perform recursion on behalf of the querying agent, then the alias target MUST be queried for any existing A and AAAA resource records which have been defined. In other combinations, the alias target MAY be queried for any existing A and AAAA resource records. If this processing is not performed, either the CNAME resource record or a referral MUST be returned. 3.5. Truncated ADDR Responses In those cases where all of the A and AAAA resource records will not fit within a response message, the responder MUST truncate the message according to the following rules. Incomplete resource record sets MUST NOT be provided. If this means that only one or the other resource record types can be provided in the answer, then only one of those resource record sets are to be provided. Both resource record sets MAY be omitted from the answer section if necessary or desired. If a responder wishes to include one of the resource record sets (and assuming that there is room in the response message for that data), the responder SHOULD give a preference to the network type which was used to transport the original query. For example, if the original query was received over an IPv6 network interface, the responder SHOULD give preference to the AAAA resource records in the response message. In any event, truncated answers to ADDR queries MUST have the TC flag enabled. Clients which receive truncated ADDR responses SHOULD perform whatever recovery steps are available, possibly Hall I-D Expires: May 2004 [page 7] Internet Draft draft-hall-qtype-addr-01.txt November 2003 including retransmitting the query via TCP, or simply requesting the missing resource record set via a separate query. Note that resolvers can avoid the penalties of truncation through a variety of means. At a minimum, applications that do not support IPv4 and IPv6 addresses could always use discrete queries for the only supported address type, rather than using ADDR queries in all cases. Meanwhile, resolvers which are able to determine a preference for a specific address type may be able to issue lookups via that network, thereby triggering the truncation preference mechanism described above (EG, if an application is able to indicate that it prefers IPv6, the resolver could issue the lookup using IPv6, and thus the IPv6 resource record would be preferred in any truncated response). Furthermore, [EDNS] provides larger DNS message sizes, which can further help to avoid problems related to truncated responses. 3.6. Error Responses In general terms, the error responses which are to be used with ADDR queries conform to the requirements specified in [RFC1035] and its updates. If the target domain name is known not to exist, the NXDOMAIN response described in [RFC2308] MUST be returned. If the target domain name is known not to have any A or AAAA resource records associated with it, the absence of that data MUST be signified through the use of a Type 1 NODATA response, as described in [RFC2308] and section 3.2 above. If the responder is unable to obtain full and complete answer data due to a communications failure, the response message MUST use the SERVFAIL response code. If the responder is unwilling to pursue full and complete answer data, the response message MUST either contain a referral or use the NOTIMPL response code. Note that this may happen if the responder is unwilling to perform recursion, or is only willing to forward ADDR queries but is unwilling to issue multiple discrete queries in support of downstream clients. Responders MUST NOT provide incomplete or partial answer data in any scenario, and MUST return an appropriate referral or error. Hall I-D Expires: May 2004 [page 8] Internet Draft draft-hall-qtype-addr-01.txt November 2003 3.7. ADDR Query-Type Examples The following response message illustrates a domain name that only has an IPv4 address defined. In that example, the known absence of any IPv6 address resource records is represented by the presence of the ADDR query-type in the Question section and the SOA resource record in the Authority section. The SOA resource record would be used to cache the negative answer. --Message Header-- Status: NOERROR Flags: QR AA RD RA --Question Section-- Name: host.example.com. Type: ADDR --Answer Section-- A: 192.168.2.14 [...] --Authority Section-- SOA: example.com. [...] The following response message illustrates a truncated response message. In that example, the TC flag is enabled, indicating that the full and complete answer data would not fit within the message. The presence of a single A resource record indicates that only one IPv4 address is defined for the target (section 3.5 of this specification explicitly prohibits incomplete resource record sets, so this must be the full set). --Message Header-- Status: NOERROR Flags: QR AA RD RA TC --Question Section-- Name: host.example.com. Type: ADDR --Answer Section-- A: 192.168.2.14 [...] Hall I-D Expires: May 2004 [page 9] Internet Draft draft-hall-qtype-addr-01.txt November 2003 4. All-Addresses Additional Data Several existing specifications currently define additional- section processing rules which that IPv4 address resource records are to be returned as supplemental data in certain responses. For example, [RFC1035] encourages A resource records to be included whenever NS resource records are provided as part of a referral, while [SMTP] endorses similar behavior whenever MX resource records are returned as answer data. This specification expands all such uses, so that if any A resource records would be provided as additional data in a response message, then any known AAAA resource records for that same domain name SHOULD also be provided at the same time. In general terms, resource records which are provided in the additional-data section of a response message are typically offered as a convenience for the recipient, in that they can preclude any expected subsequent queries which would otherwise be needed. Moreover, the absence of this data is generally non-fatal, and as such the resource records which are provided in this section of the message typically have much lower requirements than data that is provided in most of the other sections. Essentially, the inclusion or omission of any resource records in this section is a matter of mutual convenience and efficiency for the parties involved, and is not usually critical. If a responder would normally provide A resource records as additional data, and if that responder also has existing knowledge of AAAA resource records associated with the same domain name, then the responder SHOULD provide the AAAA data in the additional- data section of the response message in addition to the A resource records which it would already have provided. Responders SHOULD NOT attempt to chase down this data if it is not already known. Responders MUST NOT attempt to indicate that the data is unknown, or that the data is known not to exist. Clients MAY make use of any addressing resource records which are provided in the additional-data section, but MUST NOT assume that the lack of any of resource records indicates full and complete knowledge of the domain name in question. If any addressing resource records are missing from the additional-data section of a response message, it is the client's responsibility to verify that the addressing resource records do not actually exist, either Hall I-D Expires: May 2004 [page 10] Internet Draft draft-hall-qtype-addr-01.txt November 2003 through the use of independent queries for the missing resource records, or through the use of an ADDR query. 4.1. Truncated Additional-Data In those cases where all of the A and AAAA resource records will not fit within a response message, the responder MUST truncate the message according to the following rules. Incomplete resource record sets MUST NOT be provided. If this means that only one or the other resource record types can be provided as additional data, then only one of those resource record sets are to be provided. Both resource record sets MAY be omitted from the additional-data section if necessary or desired. If a responder wishes to include one of the resource record sets (and assuming that there is room in the response message for that data), the responder SHOULD give a preference to the network type which was used to transport the original query. For example, if the original query was received over an IPv6 network interface, the responder SHOULD give preference to the AAAA resource records in the response message. Absent other causes, truncated additional data MUST NOT cause the TC flag to be enabled. Note that resolvers can avoid the penalties of truncation through a variety of means. Resolvers which are able to determine a preference for a specific address type may be able to issue lookups via that network, thereby triggering the truncation preference mechanism described above (EG, if an application is able to indicate that it prefers IPv6, the resolver could issue the lookup using IPv6, and thus the IPv6 resource record would be preferred in any truncated response). Furthermore, [EDNS] provides larger DNS message sizes, which can further help to avoid problems related to truncated responses. 4.2. Additional-Data Examples TBD Hall I-D Expires: May 2004 [page 11] Internet Draft draft-hall-qtype-addr-01.txt November 2003 5. Security Considerations None at this time. 6. IANA Considerations This document defines a new DNS query-type which will require a code value to be allocated by IANA. 7. Author's Addresses Eric A. Hall ehall@ehsco.com 8. Normative References [RFC1035] Mockapetris, P. "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 1035, November 1997. [RFC1886] Thomson, S., and Huitema, C. "DNS Extensions to support IP version 6", RFC 1886, December 1995. [RFC2181] Elz, R., and Bush, R. "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2308] Andrews, M. "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. 9. Informative References [SMTP] Klensin, J. "Simple Mail Transfer Protocol", RFC 2821, April 2001. 10. Acknowledgments Funding for the RFC editor function is currently provided by the Internet Society. Hall I-D Expires: May 2004 [page 12] Internet Draft draft-hall-qtype-addr-01.txt November 2003 11. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hall I-D Expires: May 2004 [page 13]