external/bsd/bind/dist/doc/rfc/rfc3425.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        D. Lawrence
   8 Request for Comments: 3425                                       Nominum
   9 Updates: 1035                                              November 2002
  10 Category: Standards Track
  11
  12
  13                            Obsoleting IQUERY
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (2002).  All Rights Reserved.
  26
  27 Abstract
  28
  29    The IQUERY method of performing inverse DNS lookups, specified in RFC
  30    1035, has not been generally implemented and has usually been
  31    operationally disabled where it has been implemented.  Both reflect a
  32    general view in the community that the concept was unwise and that
  33    the widely-used alternate approach of using pointer (PTR) queries and
  34    reverse-mapping records is preferable.  Consequently, this document
  35    deprecates the IQUERY operation, declaring it entirely obsolete.
  36    This document updates RFC 1035.
  37
  38 1 - Introduction
  39
  40    As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS
  41    queries is used to look up the name(s) which are associated with the
  42    given value.  The value being sought is provided in the query's
  43    answer section and the response fills in the question section with
  44    one or more 3-tuples of type, name and class.
  45
  46    As noted in [RFC1035], section 6.4.3, inverse query processing can
  47    put quite an arduous burden on a server.  A server would need to
  48    perform either an exhaustive search of its database or maintain a
  49    separate database that is keyed by the values of the primary
  50    database.  Both of these approaches could strain system resource use,
  51    particularly for servers that are authoritative for millions of
  52    names.
  53
  54
  55
  56
  57
  58 Lawrence                    Standards Track                     [Page 1]
  59 \f
  60 RFC 3425                   Obsoleting IQUERY               November 2002
  61
  62
  63    Response packets from these megaservers could be exceptionally large,
  64    and easily run into megabyte sizes.  For example, using IQUERY to
  65    find every domain that is delegated to one of the nameservers of a
  66    large ISP could return tens of thousands of 3-tuples in the question
  67    section.  This could easily be used to launch denial of service
  68    attacks.
  69
  70    Operators of servers that do support IQUERY in some form (such as
  71    very old BIND 4 servers) generally opt to disable it.  This is
  72    largely due to bugs in insufficiently-exercised code, or concerns
  73    about exposure of large blocks of names in their zones by probes such
  74    as inverse MX queries.
  75
  76    IQUERY is also somewhat inherently crippled by being unable to tell a
  77    requester where it needs to go to get the information that was
  78    requested.  The answer is very specific to the single server that was
  79    queried.  This is sometimes a handy diagnostic tool, but apparently
  80    not enough so that server operators like to enable it, or request
  81    implementation where it is lacking.
  82
  83    No known clients use IQUERY to provide any meaningful service.  The
  84    only common reverse mapping support on the Internet, mapping address
  85    records to names, is provided through the use of pointer (PTR)
  86    records in the in-addr.arpa tree and has served the community well
  87    for many years.
  88
  89    Based on all of these factors, this document recommends that the
  90    IQUERY operation for DNS servers be officially obsoleted.
  91
  92 2 - Requirements
  93
  94    The key word "SHOULD" in this document is to be interpreted as
  95    described in BCP 14, RFC 2119, namely that there may exist valid
  96    reasons to ignore a particular item, but the full implications must
  97    be understood and carefully weighed before choosing a different
  98    course.
  99
 100 3 - Effect on RFC 1035
 101
 102    The effect of this document is to change the definition of opcode 1
 103    from that originally defined in section 4.1.1 of RFC 1035, and to
 104    entirely supersede section 6.4 (including subsections) of RFC 1035.
 105
 106    The definition of opcode 1 is hereby changed to:
 107
 108       "1               an inverse query (IQUERY) (obsolete)"
 109
 110
 111
 112
 113
 114 Lawrence                    Standards Track                     [Page 2]
 115 \f
 116 RFC 3425                   Obsoleting IQUERY               November 2002
 117
 118
 119    The text in section 6.4 of RFC 1035 is now considered obsolete.  The
 120    following is an applicability statement regarding the IQUERY opcode:
 121
 122    Inverse queries using the IQUERY opcode were originally described as
 123    the ability to look up the names that are associated with a
 124    particular Resource Record (RR).  Their implementation was optional
 125    and never achieved widespread use.  Therefore IQUERY is now obsolete,
 126    and name servers SHOULD return a "Not Implemented" error when an
 127    IQUERY request is received.
 128
 129 4 - Security Considerations
 130
 131    Since this document obsoletes an operation that was once available,
 132    it is conceivable that someone was using it as the basis of a
 133    security policy.  However, since the most logical course for such a
 134    policy to take in the face of a lack of positive response from a
 135    server is to deny authentication/authorization, it is highly unlikely
 136    that removing support for IQUERY will open any new security holes.
 137
 138    Note that if IQUERY is not obsoleted, securing the responses with DNS
 139    Security (DNSSEC) is extremely difficult without out-on-the-fly
 140    digital signing.
 141
 142 5 - IANA Considerations
 143
 144    The IQUERY opcode of 1 should be permanently retired, not to be
 145    assigned to any future opcode.
 146
 147 6 - Acknowledgments
 148
 149    Olafur Gudmundsson instigated this action.  Matt Crawford, John
 150    Klensin, Erik Nordmark and Keith Moore contributed some improved
 151    wording in how to handle obsoleting functionality described by an
 152    Internet Standard.
 153
 154 7 - References
 155
 156    [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
 157               Specification", STD 13, RFC 1035, November 1987.
 158
 159    [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
 160               3", BCP 9, RFC 2026, October 1996.
 161
 162    [RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
 163               Requirement Levels", BCP 14, RFC 2119, March 1997.
 164
 165
 166
 167
 168
 169
 170 Lawrence                    Standards Track                     [Page 3]
 171 \f
 172 RFC 3425                   Obsoleting IQUERY               November 2002
 173
 174
 175 8 - Author's Address
 176
 177    David C Lawrence
 178    Nominum, Inc.
 179    2385 Bay Rd
 180    Redwood City CA 94063
 181    USA
 182
 183    Phone: +1.650.779.6042
 184    EMail: tale@nominum.com
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Lawrence                    Standards Track                     [Page 4]
 227 \f
 228 RFC 3425                   Obsoleting IQUERY               November 2002
 229
 230
 231 9 - Full Copyright Statement
 232
 233    Copyright (C) The Internet Society (2002).  All Rights Reserved.
 234
 235    This document and translations of it may be copied and furnished to
 236    others, and derivative works that comment on or otherwise explain it
 237    or assist in its implementation may be prepared, copied, published
 238    and distributed, in whole or in part, without restriction of any
 239    kind, provided that the above copyright notice and this paragraph are
 240    included on all such copies and derivative works.  However, this
 241    document itself may not be modified in any way, such as by removing
 242    the copyright notice or references to the Internet Society or other
 243    Internet organizations, except as needed for the purpose of
 244    developing Internet standards in which case the procedures for
 245    copyrights defined in the Internet Standards process must be
 246    followed, or as required to translate it into languages other than
 247    English.
 248
 249    The limited permissions granted above are perpetual and will not be
 250    revoked by the Internet Society or its successors or assigns.
 251
 252    This document and the information contained herein is provided on an
 253    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 254    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 255    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 256    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 257    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 258
 259 Acknowledgement
 260
 261    Funding for the RFC Editor function is currently provided by the
 262    Internet Society.
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Lawrence                    Standards Track                     [Page 5]
 283 \f