RFC 3425 (rfc3425) - Page 2 of 5


Obsoleting IQUERY



Alternative Format: Original Text Document



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