Network Working Group Zheng Wang Internet Draft Cindy Wang Intended status: Informational Xiaodong Li Expires: June 19, 2010 CNNIC December 8, 2009 Glue A RR to the No Data Answer of AAAA RR draft-wang-dns-a-aaaa-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 Wang, et al. Expires June 19, 2010 [Page 1] Internet-Draft draft-wang-dns-a-aaaa-00.txt December 2009 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 June 19, 2010. 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Many existing DNS clients (resolvers) and applications that support IPv6 first search for AAAA Resource Records (RR) of a target host name, and if no data, then for A RR of the same name. This memo proposes adding A RR in the additional section for the no data answer of AAAA RR, which can save a request for A RR. Table of Contents 1. Introduction................................................3 2. Definitions.................................................3 3. Name Server Implementation..................................3 4. Resolver Implementation.....................................3 5. Understanding the Answer....................................4 6. Other Proposals.............................................4 7. Security Considerations.....................................5 8. IANA Considerations.........................................5 9. References..................................................5 Author's Addresses.............................................6 Wang, et al. Expires June 19, 2010 [Page 2] Internet-Draft draft-wang-dns-a-aaaa-00.txt December 2009 1. Introduction During the transition from IPv4 to IPv6, IPv4 (RDATA of A RR) and IPv6 (RDATA of AAAA RR) addresses are expected to coexist for a long time [RFC1035] [RFC3596]. When a DNS resolver or application does not know which addresses, IPv4 or IPv6, does a target host name have, it usually sends a request for AAAA RR first. If a no data answer is returned, it then issues another query for A RR. This fall back mechanism is based on the DNS specifications, but brings unnecessary waste of bandwidth, server load as well as a prolonged response time. This memo proposes piggybacking the answer of A RR in the response to the request of AAAA RR. 2. Definitions 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. Name Server Implementation The name server's the procedure of processing a request for AAAA RR SHOULD include: Step 1 - Check whether there are AAAA RRs for the QNAME. Step 2 - If any, answer with the AAAA RRs for the QNAME and no additional processing is REQUIRED. Step 3 - If none, leave the answer section blank (no data [RFC2308]) and check whether there are A RRs for the QNAME. Step 3.1 - If any, add the A RRs in the additional section. Step 3.2 - If none, leave the additional section blank (similar to no data). In the case of DNSSEC, besides procedures specified in [RFC4033] [RFC4034] [RFC4035] [RFC5155], the appropriate NSEC RR SHOULD be placed into the additional section in Step 3.2 [RFC5155]. 4. Resolver Implementation The resolver's the procedure of processing a request for AAAA RR SHOULD include: Step 1 - Check whether there are AAAA RRs for the QNAME in the cache. Wang, et al. Expires June 19, 2010 [Page 3] Internet-Draft draft-wang-dns-a-aaaa-00.txt December 2009 Step 2 - If any, answer with the AAAA RRs for the QNAME and no additional processing is REQUIRED. Step 3 - If no data cache is found, leave the answer section blank (no data) and check whether there are A RRs for the QNAME in the cache. Step 3.1 - If any, add the A RRs in the additional section. Step 3.2 - If no data cache is found, leave the additional section blank (similar to no data). Step 3.3 - If none, send a request for A RR, and then add the answer of A RR in the additional section (whether no data or not). Step 4 - If none, send a request for A RR, and then get the answer. In the case of DNSSEC, besides procedures specified in [RFC4033] [RFC4034] [RFC4035] [RFC5155], the appropriate NSEC RR SHOULD be placed into the additional section in Step 3.2 and 3.3 [RFC5155] (if no data). 5. Understanding the Answer How does the resolver understand the answer is dependent on whether this "glue" proposal is a must for name servers and resolvers. In other words, if the words "SHOULD" in section 3 and 4 are substituted by "MUST", there will be no ambiguity in the answer and thus no additional queries are required. The main ambiguity comes from a blank in the additional section. Does it mean the "glue" proposal is not implemented by the name servers or resolvers, or no data for the A RR? For the first case, a subsequent query for A RR is required. But for the second case, no additional requests are needed. If at least some name servers and resolvers do not follow the "glue" proposal, the only safest way is to send another request for A RR. However, this ambiguity does not exist for the case of DNSSEC. When no data in the answer section, a simple blank in the additional section means that the "glue" proposal is not implemented by the name servers or resolvers. And the appropriate NSEC RR in the additional section indicates no data for A RR. 6. Other Proposals There are several other proposals to handle the problem. One of these is to include AAAA RR as additional data in A responses and include A Wang, et al. Expires June 19, 2010 [Page 4] Internet-Draft draft-wang-dns-a-aaaa-00.txt December 2009 RR as additional data in AAAA responses. Another is to define a new query type to place both A and AAAA RRs in the answer section [draft- li-dnsext-ipv4-ipv6-02]. The difference is mainly from the definition of the problem. If a DNS resolver or application really wants both A and AAAA RRs, its most appropriate action is to request A and AAAA resource simultaneously. This can not cause any nonignorable increase of response time compared to the two proposals. The problem handled by this "glue" proposal is that many resolvers or applications have to wait for the response of AAAA RR to decide their afterwards actions (whether to request A RR). The "glue" proposal merges the two possible steps (if no data of AAAA RR) into one, therefore decreases the response time. Two separate requests for A and AAAA RR are not so bad if the cache hit rate is taken into consideration. Since most queries of resolvers are hit by the cache, the name servers are less likely to expose to huge amounts of DNS queries. Therefore cache hit rate is of great importance to the DNS specifications and extensions. Suppose the cache hit rates for A and AAAA RR are independent random variables whose value are both p. Then simply accommodating the answer of both A and AAAA in one response is to decrease the cache hit rate to p*p. The "glue" proposal alleviates the problem by only glue A RR to the no data answer of AAAA RR (not both answers of both RRs). 7. Security Considerations This specification is not believed to cause any new security problems, nor to solve any existing ones. 8. IANA Considerations This document does not require any IANA actions. 9. References [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987. [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and Souissi, M., "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. Wang, et al. Expires June 19, 2010 [Page 5] Internet-Draft draft-wang-dns-a-aaaa-00.txt December 2009 [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. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [draft-li-dnsext-ipv4-ipv6-02] Lianyuan, L., Zhenqiang, L. and Xiaodong, D., "DNS Extensions to Support IPv4 and IPv6", draft-li-dnsext-ipv4-ipv6-02, October 2009. Wang, et al. Expires June 19, 2010 [Page 6] Internet-Draft draft-wang-dns-a-aaaa-00.txt December 2009 Authors' Addresses Zheng Wang CNNIC 4, South 4th Street, Zhongguancun Beijing 100190 P.R. China Email: wangzheng@cnnic.cn Cindy Wang CNNIC 4, South 4th Street, Zhongguancun Beijing 100190 P.R. China Email: wangxin@cnnic.cn Xiaodong Li CNNIC 4, South 4th Street, Zhongguancun Beijing 100190 P.R. China Email: lee@cnnic.cn Wang, et al. Expires June 19, 2010 [Page 7]