Internet Draft H. Kitamura NEC Corporation S. Ata Osaka City University Expires March 2011 October 18, 2010 Simplified DNS Query under IPv4/IPv6 Mixed Environment 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 January 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 (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. H. Kitamura Expires March 2011 [Page 1] Internet Draft Simplified DNS Query Abstract This document discusses a simplified regular DNS query (resolving from a domain name to IP address(es)) method under IPv4/IPv6 mixed environment. Under IPv4/IPv6 mixed environment, in order to obtain IPv4 and IPv6 addresses of the node with its one domain name argument by the DNS query(ies), it requires for a client to issue two times of DNS queries transaction (one for A(IPv4) record query, the other for AAAA(IPv6) record query). In shortly to say the current DNS query method: "Two DNS queries transaction is required for One domain name resolving." Two DNS queries transaction method is complicated, inefficient and problematic. It is clear that this two DNS queries method is not suitable and not optimized for current IPv4/IPv6 mixed environment, and this method will never last to the future IPv6 fully deployed environment. Goals of this document are: 1. to clarify the problems of current regular DNS query method 2. to propose a simplified regular DNS query method ("One DNS query transaction for One domain name resolving") 1. Introduction This document discusses a simplified regular DNS query (resolving from a domain name to IP address(es)) method under IPv4/IPv6 mixed environment. It is becoming common to set both IPv4 and IPv6 addresses to one node in current IPv4/IPv6 mixed environment. In typical or normal situation, the both IPv4 and IPv6 addresses information of the node are registered to the DNS DB. In other words; for the node (one domain name), both A (IPv4) record entry and AAAA (IPv6) record entry exist in the DNS DB. Under such IPv4/IPv6 mixed environment, in order to obtain IPv4 and IPv6 addresses of the node with its one domain name argument by the DNS query(ies), it requires for a client to issue two times of DNS queries transaction (one for A(IPv4) record query, the other for AAAA(IPv6) record query). In shortly to say the current DNS query method: "Two DNS queries transaction is required for One domain name resolving." H. Kitamura Expires March 2011 [Page 2] Internet Draft Simplified DNS Query There are several historical reasons why we use this two DNS queries transaction method. However, it has proved until now that this two DNS queries method is complicated, inefficient and problematic. It is clear that this two DNS queries method is not suitable and not optimized for current IPv4/IPv6 mixed environment, and this method will never last to the future IPv6 fully deployed environment. Goals of this document are the followings: 1. to clarify the problems of current regular DNS query method 2. to propose a simplified regular DNS query method ("One DNS query transaction for One domain name resolving") 2. Analysis of current regular DNS query method Hereafter, we will discuss the following typical example case on one node under IPv4/IPv6 mixed environment. Domain Name: "hostX" IPv4 addresses: p, q IPv6 addresses: s, t All together four IP addresses are set to one node whose domain name is "hostX" and these addresses and domain name information is registered. Fig. 1 shows how these IP addresses and domain name of this node are registered in the DNS DB (example of zone file configuration). hostX IN A p(IPv4 address) hostX IN A q(IPv4 address) hostX IN AAAA s(IPv6 address) hostX IN AAAA t(IPv6 address) Fig. 1 DNS DB situation: both IPv4 and IPv6 addresses are registered as A and AAAA record entries respectively. H. Kitamura Expires March 2011 [Page 3] Internet Draft Simplified DNS Query Fig. 2 shows typical current regular DNS query method. Two times of DNS queries (one for A (IPv4) record entries, the other for AAAA (IPv6) record entries) are issued from a client in order to resolve One domain name "hostX". DNS Server Client (w/ PF_UNSPEC) | | |<---------Queries 1-----| | Name: hostX | p(IPv4) | Type: A | q(IPv4) | | |== Answers 1===========>| | Name: hostX | | Type: A | | Addr: p(IPv4 addr) | | | | Name: hostX | | Type: A | | Addr: q(IPv4 addr) | | | | | |<---------Queries 2-----| | Name: hostX | s(IPv6) | Type: AAAA | t(IPv6) | | |== Answers 2===========>| | Name: hostX | | Type: AAAA | | Addr: s(IPv6 addr) | | | | Name: hostX | | Type: AAAA | | Addr: t(IPv6 addr) | | | Fig. 2 "Two DNS queries transaction" for One domain name resolving. An idea of the "Two DNS queries" transaction method is invented from an idea (keep the existing DNS query for A record as it is, and add a new DNS query for AAAA record.). Fig. 2 only shows one type of typical DNS query methods; order of DNS queries: [1st for A record, 2nd for AAAA record], queries issued style: [series] With some OSes, DNS queries implementation methods are different. Table 1 shows the categorization of known implementation method types. H. Kitamura Expires March 2011 [Page 4] Internet Draft Simplified DNS Query Table 1 current "Two DNS queries transaction" method types +================+===============+===============+========+ |Type |1st query |2nd query |style | +================+===============+===============+========+ |A-AAAA Series |for A record |for AAAA record|Series | +----------------+---------------+---------------+--------+ |A-AAAA Parallel |for A record |for AAAA record|Parallel| +----------------+---------------+---------------+--------+ |AAAA-A Series |for AAAA record|for A record |Series | +----------------+---------------+---------------+--------+ |AAAA-A Parallel |for AAAA record|for A record |Parallel| +----------------+---------------+---------------+--------+ Some OSes choose more complicated or advanced method (whether 2nd query is issued or not depends on the result of 1st query or configuration status of the node.) 3. Problems of the current Two DNS queries transaction method Two DNS queries transaction method has the following problems. Compared to the "One" DNS query transaction method, "Two" DNS queries transaction method has the following problems. 1. Complicated (not Simple enough) 2. Inefficient 3. Takes Long time to get result 4. Issues Twice large traffics As above section shows that combination of Two queries is many and complicated. In order to obtain the resolving results, we have to wait for two answers for two queries. It takes much time to wait for two answers. If either one of two answers is lost, too complicated recover procedures are requires. It is clear the Two DNS queries transaction method is problematic and not recommendable. This method will never last to the future IPv6 fully deployed environment. Current Two DNS queries transaction method should be improved. One DNS queries transaction for One domain name resolving method solves all of above problems and we propose it in the next section. H. Kitamura Expires March 2011 [Page 5] Internet Draft Simplified DNS Query 4. Proposed three types of "One DNS query transaction for One domain name resolving" methods. We can design the following three types of DNS query methods to achieve the goal "One DNS query transaction for One domain name resolving". 1. Two record types (AAAA and A) set Queries 2. One special new record type (e.g., AAAA+A) set Queries 3. One record type (AAAA) set Queries with transformation of A (IPv4) record entries 4.1 Two record types (AAAA and A) set Queries Fig. 3 shows Two record types (AAAA and A) set Queries method. DNS Server Client (w/ PF_UNSPEC) | | |<---------Queries 1-----| | Name: hostX | p(IPv4) | Type: A | q(IPv4) | | | Name: hostX | s(IPv6) | Type: AAAA | t(IPv6) | | |== Answers 1===========>| | Name: hostX | | Type: A | | Addr: p(IPv4 addr) | | | | Name: hostX | | Type: A | | Addr: q(IPv4 addr) | | | | Name: hostX | | Type: AAAA | | Addr: s(IPv6 addr) | | | | Name: hostX | | Type: AAAA | | Addr: t(IPv6 addr) | | | Fig. 3 Two record types (AAAA and A) set Queries Advantages: Natural extension method Disadvantages: Client side implementation modifications are necessary. Non standard DNS query usage. (Two record types set Queries DNS H. Kitamura Expires March 2011 [Page 6] Internet Draft Simplified DNS Query query examples are not known till now.) 4.2 One special new record type (e.g., AAAA+A) set Queries Fig. 4 shows One special new record type (e.g., AAAA+A) set Queries method. (This function may became possible by introducing new "pseudo" Resource Record type instead of new record type.) DNS Server Client (w/ PF_UNSPEC) | | |<---------Queries 1-----| | Name: hostX | p(IPv4) | Type: AAAA+A | q(IPv4) | | | | s(IPv6) | | t(IPv6) | | |== Answers 1===========>| | Name: hostX | | Type: A | | Addr: p(IPv4 addr) | | | | Name: hostX | | Type: A | | Addr: q(IPv4 addr) | | | | Name: hostX | | Type: AAAA | | Addr: s(IPv6 addr) | | | | Name: hostX | | Type: AAAA | | Addr: t(IPv6 addr) | | | Fig. 4 One special new record type (AAAA+A) set Queries Advantages: Standard DNS query usage. (One record type set Queries) Disadvantages: Client side implementation modifications are necessary. Special record type (e.g., AAAA+A) should be newly introduced. H. Kitamura Expires March 2011 [Page 7] Internet Draft Simplified DNS Query 4.3 One record type (AAAA) set Queries with transformation of A (IPv4) record entries Fig. 5 shows One record type (AAAA) set Queries with transformation of A (IPv4) record entries method. This idea is completely new. All of existing A (IPv4) record entries are assumed to be AAAA (IPv6) entries by using "IPv4 mapped IPv6 address" transformation. If "IPv4 mapped IPv6 address" function is installed and deployed on Client, it is not necessary to install additional reverse transformation function on the Client side. DNS Server Client (w/ PF_UNSPEC) | | |<---------Queries 1-----| transform: | Name: hostX | p(v4) => p'(v6) | Type: AAAA | q(v4) => q'(v6) | | | | s (v6) | | t (v6) | | |== Answers 1===========>| | Name: hostX | | Type: AAAA | | Addr: p'(IPv6 addr) | | | | Name: hostX | | Type: AAAA | | Addr: q'(IPv6 addr) | | | | Name: hostX | | Type: AAAA | | Addr: s(IPv6 addr) | | | | Name: hostX | | Type: AAAA | | Addr: t(IPv6 addr) | | | Fig. 5 One record type (AAAA) set Queries with transformation of A (IPv4) Advantages: NO client side implementation modifications are necessary. Disadvantages: "IPv4 mapped IPv6 address" function should be fully deployed on the Client side. H. Kitamura Expires March 2011 [Page 8] Internet Draft Simplified DNS Query 5. Security Considerations The proposed DNS query methods in this document is based on simplification or natural extension of the current DNS query method. Security considerations of the proposed methods are as same as those of the current normal DNS query method. There are no newly occurred security considerations in this document. 6. IANA Considerations This document describes a new special DNS record type in one of the proposed DNS query methods. So, the value of this new special DNS record type should be managed by the IANA. References Normative References [RFC4291] R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006 [RFC4038] M-K. Shin, et al., "Application Aspects of IPv6 Transition", RFC 4038, March 2005 [RFC1034] P. Mockapetris, "Domain names - concepts and facilities ", RFC 1034, November 1987 [RFC1035] P. Mockapetris, "Domain names - implementation and specification", RFC 1035, November 1987 [RFC2874] M. Crawford and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000 [RFC3596] S. Thomson, C. Huitema, V. Ksinant and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003 [RFC4038] M-K. Shin, et al., "Application Aspects of IPv6 Transition", RFC 4038, March 2005 [RFC4291] R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006 [RFC4472] A. Durand, et al., "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006 H. Kitamura Expires March 2011 [Page 9] Internet Draft Simplified DNS Query Authors' Addresses Hiroshi Kitamura Service Platform Research Laboratories, NEC Corporation (SC building 12F)1753, Shimonumabe, Nakahara-Ku, Kawasaki, Kanagawa 211-8666, JAPAN Graduate School of Information Systems, University of Electro-Communications 5-1 Chofugaoka 1-Chome, Chofu-shi, Tokyo 182-8585, JAPAN Phone: +81 44 431 7686 Fax: +81 44 431 7680 Email: kitamura@da.jp.nec.com Shingo Ata Graduate School of Engineering, Osaka City University 3-3-138, Sugimoto, Sumiyoshi-Ku, Osaka 558-8585, JAPAN Phone: +81 6 6605 2191 Fax: +81 6 6605 2191 Email: ata@info.eng.osaka-cu.ac.jp H. Kitamura Expires March 2011 [Page 10]