284 lines
8.4 KiB
Plaintext
284 lines
8.4 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group D. Lawrence
|
||
Request for Comments: 3425 Nominum
|
||
Updates: 1035 November 2002
|
||
Category: Standards Track
|
||
|
||
|
||
Obsoleting IQUERY
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
The IQUERY method of performing inverse DNS lookups, specified in RFC
|
||
1035, has not been generally implemented and has usually been
|
||
operationally disabled where it has been implemented. Both reflect a
|
||
general view in the community that the concept was unwise and that
|
||
the widely-used alternate approach of using pointer (PTR) queries and
|
||
reverse-mapping records is preferable. Consequently, this document
|
||
deprecates the IQUERY operation, declaring it entirely obsolete.
|
||
This document updates RFC 1035.
|
||
|
||
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 arduous 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.
|
||
|
||
|
||
|
||
|
||
|
||
Lawrence Standards Track [Page 1]
|
||
|
||
RFC 3425 Obsoleting IQUERY November 2002
|
||
|
||
|
||
Response packets 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
|
||
requester 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 is 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 pointer (PTR)
|
||
records in the in-addr.arpa tree and has served the community well
|
||
for many years.
|
||
|
||
Based on all of these factors, this document recommends that the
|
||
IQUERY operation for DNS servers be officially obsoleted.
|
||
|
||
2 - Requirements
|
||
|
||
The key word "SHOULD" in this document is to be interpreted as
|
||
described in BCP 14, RFC 2119, namely that there may exist valid
|
||
reasons to ignore a particular item, but the full implications must
|
||
be understood and carefully weighed before choosing a different
|
||
course.
|
||
|
||
3 - Effect on RFC 1035
|
||
|
||
The effect of this document is to change the definition of opcode 1
|
||
from that originally defined in section 4.1.1 of RFC 1035, and to
|
||
entirely supersede section 6.4 (including subsections) of RFC 1035.
|
||
|
||
The definition of opcode 1 is hereby changed to:
|
||
|
||
"1 an inverse query (IQUERY) (obsolete)"
|
||
|
||
|
||
|
||
|
||
|
||
Lawrence Standards Track [Page 2]
|
||
|
||
RFC 3425 Obsoleting IQUERY November 2002
|
||
|
||
|
||
The text in section 6.4 of RFC 1035 is now considered obsolete. The
|
||
following is an applicability statement regarding the IQUERY opcode:
|
||
|
||
Inverse queries using the IQUERY opcode were originally described as
|
||
the ability to look up the names that are associated with a
|
||
particular Resource Record (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 DNS
|
||
Security (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 instigated this action. Matt Crawford, John
|
||
Klensin, Erik Nordmark and Keith Moore contributed some improved
|
||
wording in how to handle obsoleting functionality described by an
|
||
Internet Standard.
|
||
|
||
7 - References
|
||
|
||
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
|
||
Specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
|
||
3", BCP 9, RFC 2026, October 1996.
|
||
|
||
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Lawrence Standards Track [Page 3]
|
||
|
||
RFC 3425 Obsoleting IQUERY November 2002
|
||
|
||
|
||
8 - Author's Address
|
||
|
||
David C Lawrence
|
||
Nominum, Inc.
|
||
2385 Bay Rd
|
||
Redwood City CA 94063
|
||
USA
|
||
|
||
Phone: +1.650.779.6042
|
||
EMail: tale@nominum.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Lawrence Standards Track [Page 4]
|
||
|
||
RFC 3425 Obsoleting IQUERY November 2002
|
||
|
||
|
||
9 - Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2002). 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.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Lawrence Standards Track [Page 5]
|
||
|