--- /dev/null
+DNSEXT Working Group David C Lawrence
+INTERNET-DRAFT Nominum
+<draft-ietf-dnsext-obsolete-iquery-02.txt> December 2001
+Updates: RFC 1035
+
+
+ Obsoleting IQUERY
+
+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
+
+ Comments should be sent to the authors or the DNSEXT WG mailing list
+ namedroppers@ops.ietf.org.
+
+ This draft expires on 14 June 2002.
+
+ Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All rights reserved.
+
+Abstract
+
+ Based on a lack of working implementations of the IQUERY method
+ of performing inverse DNS lookups, and because an alternative
+ mechanism for doing inverse queries of address records has been
+ successfully used operationally for well over a decade, this
+ draft proposes that the IQUERY operation be entirely obsoleted.
+
+
+
+Expires Jun 2002 [Page 1]
+\f
+INTERNET-DRAFT Obsoleting IQUERY June 2001
+
+
+1 - Introduction
+
+ As specified in RFC 1035 (section 6.4), the IQUERY operation for
+ DNS queries is used to look up the name(s) which are associated
+ with the given value. The value being sought is provided in the
+ query's answer section and the response fills in the question
+ section with one or more 3-tuples of type, name and class.
+
+ As noted in [RFC1035], section 6.4.3, inverse query processing can
+ put quite an onerous burden on a server. A server would need to
+ perform either an exhaustive search of its database or maintain a
+ separate database that is keyed by the values of the primary
+ database. Both of these approaches could strain system resource
+ use, particularly for servers that are authoritative for millions
+ of names.
+
+ Response packet from these megaservers could be exceptionally
+ large, and easily run into megabyte sizes. For example, using
+ IQUERY to find every domain that is delegated to one of the
+ nameservers of a large ISP could return tens of thousands of
+ 3-tuples in the question section. This could easily be used to
+ launch denial of service attacks.
+
+ Operators of servers that do support IQUERY in some form (such as
+ very old BIND 4 servers) generally opt to disable it. This is
+ largely due to bugs in insufficiently-exercised code, or concerns
+ about exposure of large blocks of names in their zones by probes
+ such as inverse MX queries.
+
+ IQUERY is also somewhat inherently crippled by being unable to tell
+ a requestor where it needs to go to get the information that was
+ requested. The answer is very specific to the single server that
+ was queried. This is sometimes a handy diagnostic tool, but
+ apparently not enough so that server operators like to enable it,
+ or request implementation where it's lacking.
+
+ No known clients use IQUERY to provide any meaningful service. The
+ only common reverse mapping support on the Internet, mapping
+ address records to names, is provided through the use of PTR
+ records in the in-addr.arpa tree and has served the community well
+ for many years.
+
+ Based on all of these factors, this draft proposes that the IQUERY
+ operation for DNS servers be officially obsoleted.
+
+1.1 - Requirements
+
+ The key words "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
+ document are to be interpreted as described in RFC2119.
+
+
+Expires Jun 2002 [Page 2]
+\f
+INTERNET-DRAFT Obsoleting IQUERY June 2001
+
+1.2 - Updated documents and sections
+
+ In RFC 1035, sections 4.1.1 is updated in part and section 6.4 is
+ entirely superseded.
+
+2 - New text for RFC 1035.
+
+ Section 4.1.1 has the following text to describe opcode 1:
+
+ "1 an inverse query (IQUERY)"
+
+ It is now considered to read as follows:
+
+ "1 an inverse query (IQUERY) (obsolete)"
+
+ Section 6.4, including all subsections, of RFC 1035 should be
+ considered obsolete and not to be implemented. The section
+ effectively now reads as follows:
+
+ "Inverse queries using the IQUERY opcode were originally described
+ as the ability to look up the names that are associated with a
+ particular RR. Their implementation was optional and never
+ achieved widespread use. Therefore IQUERY is now obsolete, and
+ name servers SHOULD return a "Not Implemented" error when an IQUERY
+ request is received."
+
+4 - Security Considerations:
+
+ Since this document obsoletes an operation that was once available,
+ it is conceivable that someone was using it as the basis of a
+ security policy. However, since the most logical course for such a
+ policy to take in the face of a lack of positive response from a
+ server is to deny authentication/authorization, it is highly
+ unlikely that removing support for IQUERY will open any new
+ security holes.
+
+ Note that if IQUERY is not obsoleted, securing the responses with
+ DNSSEC is extremely difficult without out-on-the-fly digital signing.
+
+5 - IANA Considerations:
+
+ The IQUERY opcode of 1 should be permanently retired, not to be
+ assigned to any future opcode.
+
+6 - Acknowledgments:
+
+ Olafur Gudmundsson was the instigator for this action.
+ Matt Crawford contributed some improved wording.
+
+
+
+
+Expires Jun 2002 [Page 3]
+\f
+INTERNET-DRAFT Obsoleting IQUERY June 2001
+
+References:
+
+[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
+ Specification'', STD 13, RFC 1035, November 1987.
+
+7 - Author's Address
+
+ David Lawrence
+ Nominum, Inc.
+ 950 Charter St
+ Redwood City CA 94063
+ USA
+
+ Phone: +1.650.779.6042
+ EMail: tale@nominum.com
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). 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.
+
+ 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."
+
+
+
+
+
+
+
+
+
+Expires Jun 2002 [Page 4]
projects / thirdparty / bind9.git / commitdiff
