INTERNET-DRAFT Eric A. Hall Document: draft-hall-qtype-addr-00.txt August 2002 Expires: February, 2003 The ADDR DNS Query-Type 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. 1. Abstract This document defines a DNS query-type for "all IP address resource records," specifically including any A and AAAA resource records which may be bound to the queried domain name. This query- type would allow IPv6-aware applications to issue a single query and determine the capabilities of the remote host, rather than having to issue a second query for A resource records in those cases where no AAAA resource records are available. Internet Draft draft-hall-qtype-addr-00.txt August 2002 2. Definitions and Terminology Readers are expected to be familiar with the following specifications: RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION RFC 1886 - DNS Extensions to support IP version 6 RFC 2181 - Clarifications to the DNS Specification RFC 2308 - Negative Caching of DNS Queries (DNS NCACHE) 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. 3. Overview Historically, Internet applications have only had to issue a single query for a single resource record type (RRtype) to determine the IPv4 address of a destination node. As more IPv6 applications are deployed, however, there is a significant likelihood that these applications will have to locate two different resource records, which will typically require two different queries for two different RRtypes. Specifically, an IPv6-aware application may first attempt to locate the IPv6 address of a remote host by issuing a query for the AAAA resource record defined in [RFC1886]. If the queried domain name does not have an AAAA record - as signified by a NODATA response, as described in [RFC2308] - then the application may choose to issue a query for any IPv4 addresses which exist, using the A RRtype defined in [RFC1035]. Individually, these queries are minor. However, if the use of multiple queries becomes commonplace, they can cumulatively represent a significant increase in overall query traffic. Furthermore, since the caching rules for negative answers can result in shorter time-to-live values than would normally be encountered, the frequent use of multiple distinct queries may cause the initial query to fail more frequently than usual, resulting in an additional increase in overall query volume. Hall I-D Expires: February 2003 [page 2] Internet Draft draft-hall-qtype-addr-00.txt August 2002 Separately, the Internet's history with [SMTP] illustrates some of the pitfalls surrounding the use of alternate resource records. Specifically, SMTP allows a destination mail domain to be identified using an MX or A resource record, and SMTP transfer agents typically issue queries for MX resource records, followed by queries for A resource records if the original query fails. This same usage scenario of multiple distinct queries is likely to be repeated for IPv6 and IPv4 addresses (more so in the short- term, until IPv6 addresses become the norm, causing the initial query to succeed more often than it fails). Another lesson that can be learned from the history with [SMTP] is that some applications have attempted to streamline this process by issuing a single query with the query-type of "ALL", in the hopes that any MX and/or A resource records which are present will be returned. Unfortunately, this query-type does not guarantee success, since DNS caches are not obligated to store all of the data associated with a domain name, and therefore may not have all of the resource records available. Furthermore, this process can cause multiple additional queries in several different scenarios, resulting in lower efficiency levels. Unfortunately, if history is any indicator of future trends, this approach is somewhat likely to be pursued by IPv6-aware applications as well, particularly since the potential number of IPv6 applications is orders of magnitude higher than the potential number of SMTP agents. In order to help prevent these kinds of problems from developing, this document defines an "ADDR" query-type which allows IPv6-aware applications to issue a single query for all of the AAAA and A resource records which have been bound to a domain name. When used, this query-type will allow the applications to issue a single query and obtain all of the necessary information, without having to issue multiple distinct queries, and without having to resort to the "ALL" query-type. However, the usage of this query-type has specific requirements which have to be met before it can be deployed. In particular, caches which accept this query-type MUST ensure that they have all of the associated resource records before they generate a response. Otherwise, applications will be presented with an incomplete list. Hall I-D Expires: February 2003 [page 3] Internet Draft draft-hall-qtype-addr-00.txt August 2002 4. Query-Type Description The ADDR query-type has a code value of [TBD IANA], and the mnemonic of "ADDR". ADDR is a query-type only, not an resource record type, and therefore does not define any resource record data structures. 5. Implementation Requirements The following sub-sections define handling rules which MUST be implemented by a responder. If a responder is unable or unwilling to comply with each and every one of these rules, it MUST reject queries for the ADDR query-type with a NOTIMPL response. For undefined cases, the rules defined in [RFC1035] and [RFC2308] MUST be followed, as appropriate to the scenario at hand. 5.1. Basic Handling DNS agents 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 known 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 be valid but does not have any associated AAAA or A resource records, a NODATA response MUST be returned, as defined in [RFC2308]. If the queried domain name has either A or AAAA resource records, the existing resource records MUST be provided in the answer set. In those cases where only one type of resource record exists, no indication of the other resource record's absence is to be made. 5.2. Ensuring Valid Answer Sets It is imperative that answer data only be provided by a responder if the data is known to be legitimate. Providing erroneous or Hall I-D Expires: February 2003 [page 4] Internet Draft draft-hall-qtype-addr-00.txt August 2002 incomplete data may cause significant problems to occur with the users of that data, and MUST be avoided. In general terms, this document requires that a responder only answer an ADDR query if the responder is capable of obtaining the underlying data. In the case of non-authoritative servers or caches, this may be achieved by either issuing a subsequent ADDR query for the domain name in question, or by issuing discrete queries for any 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 these queries, but only if the time-to-live values associated with the canonical resource records allow it. If any of the canonical resource records are known not to exist (such as will occur upon receipt of a NODATA response), the negative answer MUST be cached according to the rules defined in [RFC2308], with this knowledge being used to construct the answer to the ADDR query. If any of the canonical resource record sets have not yet been obtained or have expired, the missing data MUST be acquired before the current ADDR query is answered. Since negative answers (such as returned in NODATA responses) typically result in time-to-live values which are significantly shorter than positive answers, this process can result in more queries being generated than necessary. As such, responders SHOULD issue the minimum number of queries necessary (such as issuing a query for the missing AAAA resource record only), and SHOULD NOT refresh data unnecessarily. If the missing data cannot be obtained, a SERVFAIL response MUST be returned, using the appropriate Authoritative Answer flag, as described in [RFC1035]. 5.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. Under no circumstances may a responder increase the time-to-live value of a resource record beyond its original value. Hall I-D Expires: February 2003 [page 5] Internet Draft draft-hall-qtype-addr-00.txt August 2002 Each set of AAAA and A resource records MUST be synchronized to their lowest common values as an individual group (this is in accordance with the rules set forth in [RFC2181]). In the common case, the time-to-live values for the cumulative set of resource records SHOULD reflect the original time-to-live values associated with the original answer(s), minus any local delay penalties. In those cases where the canonical resource records have been obtained through multiple distinct queries, the responder MAY synchronize the time-to-live values in the answer set to the lowest common value, although this is not required. Note that the time-to-live values may be synchronized for reasons unrelated to the ADDR query-type. For example, AAAA and A resource records which may have been learned as glue for a delegation response may have been synchronized by another responder, with the resulting data and time-to-live values being used in subsequent responses to ADDR queries. 5.4. CNAME Processing If the queried 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, but if this processing is not performed, the CNAME resource record and data MUST be returned. 5.5. Additional Processing The ADDR query-type does not cause or require any additional processing. Note well, however, that [RFC1035] and [RFC1886] both define additional processing requirements for the A and AAAA resource records, respectively, and that these requirements are not removed by this specification. Hall I-D Expires: February 2003 [page 6] Internet Draft draft-hall-qtype-addr-00.txt August 2002 6. Examples TBD 7. Security Considerations None at this time. 8. IANA Considerations This document defines a new DNS query-type which will require a code value to be allocated by IANA. 9. Author's Addresses Eric A. Hall ehall@ehsco.com 10. References [RFC1035] RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION; P. Mockapetris; November 1997. [RFC1886] RFC 1886, DNS Extensions to support IP version 6; S. Thomson, et al; December 1995. [RFC2181] RFC 2181, Clarifications to the DNS Specification; R. Elz, et al; July 1997. [RFC2308] RFC 2308, Negative Caching of DNS Queries (DNS NCACHE); M. Andrews; March 1998. [SMTP] RFC 2821, Simple Mail Transfer Protocol; J. Klensin; April 2001. Hall I-D Expires: February 2003 [page 7]