Internet DRAFT - draft-wang-dns-a-aaaa

draft-wang-dns-a-aaaa



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]