idnits 2.17.1 draft-sajitha-dnsext-qtype-addr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC1035]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 46 has weird spacing: '... should retur...' == Line 72 has weird spacing: '... should retur...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (27 Feb 2003) is 7722 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1035' on line 110 looks like a reference -- Missing reference section? 'TBD' on line 68 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. T. Sajitha 2 Internet-Draft Hewlett-Packard 3 Expires: Aug 28, 2004 27 Feb 2003 5 DNS QTYPE to retrieve IPv4 and IPv6 address 6 draft-sajitha-dnsext-qtype-addr-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on Aug 28, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document proposes a new query type to be used in the 38 DNS [RFC1035] implementation. This is used to retrieve all the 39 IPv4 as well as IPv6 addresses of a host using a single query. 41 1. Introduction 43 Currently there is no mechanism to get all the v4 and v6 addresses 44 of a host with a single query. This proposal defines a new query type 45 "ADDR" which can be used by a client while querying the DNS server. 46 While processing this query type, the server should return all the 47 records of type T_A & T_AAAA for the QNAME in question, in the answer 48 section of the response. 50 2. Rationale 52 In DNS IPv4 address is identified by the RR type T_A and IPv6 53 address by T_AAAA. As the IPv6 deployment is increasing, the dual 54 stack implementations are becoming more common. In this case each 55 hosts will have IPv4 as well as IPv6 address. This calls for the 56 need of retrieving all the v4 as well as v6 address for a 57 particular host. Currently this is achieved by using more than 58 one queries. 60 Most of the internet services need to know the addresses of a host 61 inorder to communicate with it. When DNS is used for address 62 resolution, the queries and responses has to travel over the network 63 and so the time taken to resolve the address of a host becomes very 64 critical. 66 3. The ADDR qtype 68 The ADDR query type is defined with mnemonic ADDR and type code [TBD]. 69 This is defined for the IN class. Using this query type, client can 70 request for all the addresses of a host using a single query. 72 While processing this query type, the server should return all the 73 records of type T_A & T_AAAA for the host in question. All these 74 records should be provided in the answer section of the response. 76 The server may order all the T_AAAA types first and followed by 77 T_A types. A6 record type is not considered as it is deprecated. 79 4. Advantage over "ALL" QTYPE 81 The query type denoted by "*" with a value of 255 [see RFC1035 82 Section 3.2.3] will cause the server to return all types of records 83 corresponding to the QNAME in question. This include A, NS, MX, SOA, 84 CNAME, HINFO etc. For a client looking for the addresses of a host, 85 it is inefficient to process all these records and choose the T_A 86 and T_AAAA. 88 For a DNS server, it has to provide all the RR types of the 89 QNAME if queried with "ALL" QTYPE. This is an overhead to the server. 90 Moreover the DNS packet size will be a limitation to provide all the 91 types of records in a response. 93 5. Operational Consideration 95 The existing clients can be easily modified to use this QTYPE and 96 if does not get an answer, fall back to the two query sequence as 97 they do now. 99 The old servers which does not support this query type, will return 100 a not implemented RCODE whereas the servers which supports this 101 query type will return the T_A and T_AAAA RRs. 103 6. Security consideration 105 The ADDR query type as such does not introduce any new security 106 problems into the DNS. 108 7 - References 110 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 111 Specification,'' RFC 1035, USC/Information Sciences 112 Institute, November 1987. 114 8. IANA Considerations 116 IANA is requested to allocate a QTYPE value for the ADDR query type. 118 Author's Address 120 Sajitha T. T. 121 Hewlett-Packard STSD-I 122 29, Cunningham Road 123 Bangalore - 560052 124 India 126 Phone: +91-80-2053091 127 E-Mail: sajitha@india.hp.com 129 Full Copyright Statement 131 Copyright (C) The Internet Society (2003). All Rights Reserved. 133 This document and translations of it may be copied and furnished to 134 others, and derivative works that comment on or otherwise explain it 135 or assist in its implementation may be prepared, copied, published 136 and distributed, in whole or in part, without restriction of any 137 kind, provided that the above copyright notice and this paragraph are 138 included on all such copies and derivative works. However, this 139 document itself may not be modified in any way, such as by removing 140 the copyright notice or references to the Internet Society or other 141 Internet organizations, except as needed for the purpose of 142 developing Internet standards in which case the procedures for 143 copyrights defined in the Internet Standards process must be 144 followed, or as required to translate it into languages other than 145 English. 147 The limited permissions granted above are perpetual and will not be 148 revoked by the Internet Society or its successors or assigns. 150 This document and the information contained herein is provided on an 151 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 152 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 153 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 154 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 155 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 157 Acknowledgement 159 Funding for the RFC Editor function is currently provided by the 160 Internet Society.