Network Working Group                                   T.  T.  Sajitha
Internet-Draft                                          Hewlett-Packard
Expires:  Aug 28, 2004                                  27 Feb 2003




             DNS QTYPE to retrieve IPv4 and IPv6 address
                draft-sajitha-dnsext-qtype-addr-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 Aug 28, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document proposes a new query type to be used in the
   DNS [RFC1035] implementation. This is used to retrieve all the
   IPv4 as well as IPv6 addresses of a host using a single query.

1. Introduction

   Currently there is no mechanism to get all the v4 and v6 addresses
   of a host with a single query. This proposal defines a new query type
   "ADDR" which can be used by a client while querying the DNS server.
   While processing this query type, the server should  return all the
   records of type T_A & T_AAAA for the QNAME in question, in the answer
   section of the response.


Sajitha               Expires Aug 28, 2004                     [Page 1]


Internet-Draft   DNS QTYPE to retrieve IPv4 and IPv6 address   Feb 2003

2. Rationale

   In DNS IPv4 address is identified by the RR type T_A and IPv6
   address by T_AAAA. As the IPv6 deployment is increasing, the dual
   stack implementations are becoming more common. In this case each
   hosts will have IPv4 as well as IPv6 address. This calls for the
   need of retrieving all the v4 as well as v6 address for a
   particular host. Currently this is achieved by using more than
   one queries.

   Most of the internet services need to know the addresses of a host
   inorder to communicate with it.  When DNS is used for address
   resolution, the queries and responses has to travel over the network
   and so the time taken to resolve the address of a host becomes very
   critical.

3. The ADDR qtype

   The ADDR query type is defined with mnemonic ADDR and type code [TBD].
   This is defined for the IN class. Using this query type, client can
   request for all the addresses of a host using a single query.

   While processing this query type, the server should  return all the
   records of type T_A & T_AAAA for the host in question. All these
   records should be provided in the answer section of the response.

   The server may order all the T_AAAA types first and followed by
   T_A types. A6 record type is not considered as it is deprecated.

4. Advantage over "ALL" QTYPE

   The query type denoted by "*" with a value of 255 [see RFC1035
   Section 3.2.3] will cause the server to return all types of records
   corresponding to the QNAME in question. This include A, NS, MX, SOA,
   CNAME, HINFO etc. For a client looking for the addresses of a host,
   it is inefficient to process all these records and choose the T_A
   and T_AAAA.

   For a DNS server, it has to provide all the RR types of the
   QNAME if queried with "ALL" QTYPE. This is an overhead to the server.
   Moreover the DNS packet size will be a limitation to provide all the
   types of records in a response.


Sajitha               Expires Aug 28, 2004                     [Page 2]


Internet-Draft   DNS QTYPE to retrieve IPv4 and IPv6 address   Feb 2003

5. Operational Consideration

   The existing clients can be easily modified to use this QTYPE and
   if does not get an answer, fall back to the two query sequence as
   they do now.

   The old servers which does not support this query type, will return
   a not implemented RCODE whereas the servers which supports this
   query type will return the T_A and T_AAAA RRs.

6. Security consideration

   The ADDR query type as such does not introduce any new security
   problems into the DNS.

7 - References

   [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
              Specification,'' RFC 1035, USC/Information Sciences
              Institute, November 1987.

8. IANA Considerations

   IANA is requested to allocate a QTYPE value for the ADDR query type.

Author's Address

   Sajitha T. T.
   Hewlett-Packard STSD-I
   29, Cunningham Road
   Bangalore - 560052
   India

   Phone: +91-80-2053091
   E-Mail: sajitha@india.hp.com


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.


Sajitha               Expires Aug 28, 2004                     [Page 3]

Internet-Draft   DNS QTYPE to retrieve IPv4 and IPv6 address   Feb 2003

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.