contrib/bind9/doc/rfc/rfc2671.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            P. Vixie
   8 Request for Comments: 2671                                            ISC
   9 Category: Standards Track                                     August 1999
  10
  11
  12                   Extension Mechanisms for DNS (EDNS0)
  13
  14 Status of this Memo
  15
  16    This document specifies an Internet standards track protocol for the
  17    Internet community, and requests discussion and suggestions for
  18    improvements.  Please refer to the current edition of the "Internet
  19    Official Protocol Standards" (STD 1) for the standardization state
  20    and status of this protocol.  Distribution of this memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  25
  26 Abstract
  27
  28    The Domain Name System's wire protocol includes a number of fixed
  29    fields whose range has been or soon will be exhausted and does not
  30    allow clients to advertise their capabilities to servers.  This
  31    document describes backward compatible mechanisms for allowing the
  32    protocol to grow.
  33
  34 1 - Rationale and Scope
  35
  36 1.1. DNS (see [RFC1035]) specifies a Message Format and within such
  37      messages there are standard formats for encoding options, errors,
  38      and name compression.  The maximum allowable size of a DNS Message
  39      is fixed.  Many of DNS's protocol limits are too small for uses
  40      which are or which are desired to become common.  There is no way
  41      for implementations to advertise their capabilities.
  42
  43 1.2. Existing clients will not know how to interpret the protocol
  44      extensions detailed here.  In practice, these clients will be
  45      upgraded when they have need of a new feature, and only new
  46      features will make use of the extensions.  We must however take
  47      account of client behaviour in the face of extra fields, and design
  48      a fallback scheme for interoperability with these clients.
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Vixie                       Standards Track                     [Page 1]
  59 \f
  60 RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
  61
  62
  63 2 - Affected Protocol Elements
  64
  65 2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
  66      word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
  67      1-bit flags.  The original reserved Z bits have been allocated to
  68      various purposes, and most of the RCODE values are now in use.
  69      More flags and more possible RCODEs are needed.
  70
  71 2.2. The first two bits of a wire format domain label are used to denote
  72      the type of the label.  [RFC1035 4.1.4] allocates two of the four
  73      possible types and reserves the other two.  Proposals for use of
  74      the remaining types far outnumber those available.  More label
  75      types are needed.
  76
  77 2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
  78      While the minimum maximum reassembly buffer size still allows a
  79      limit of 512 octets of UDP payload, most of the hosts now connected
  80      to the Internet are able to reassemble larger datagrams.  Some
  81      mechanism must be created to allow requestors to advertise larger
  82      buffer sizes to responders.
  83
  84 3 - Extended Label Types
  85
  86 3.1. The "0 1" label type will now indicate an extended label type,
  87      whose value is encoded in the lower six bits of the first octet of
  88      a label.  All subsequently developed label types should be encoded
  89      using an extended label type.
  90
  91 3.2. The "1 1 1 1 1 1" extended label type will be reserved for future
  92      expansion of the extended label type code space.
  93
  94 4 - OPT pseudo-RR
  95
  96 4.1. One OPT pseudo-RR can be added to the additional data section of
  97      either a request or a response.  An OPT is called a pseudo-RR
  98      because it pertains to a particular transport level message and not
  99      to any actual DNS data.  OPT RRs shall never be cached, forwarded,
 100      or stored in or loaded from master files.  The quantity of OPT
 101      pseudo-RRs per message shall be either zero or one, but not
 102      greater.
 103
 104 4.2. An OPT RR has a fixed part and a variable set of options expressed
 105      as {attribute, value} pairs.  The fixed part holds some DNS meta
 106      data and also a small collection of new protocol elements which we
 107      expect to be so popular that it would be a waste of wire space to
 108      encode them as {attribute, value} pairs.
 109
 110
 111
 112
 113
 114 Vixie                       Standards Track                     [Page 2]
 115 \f
 116 RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
 117
 118
 119 4.3. The fixed part of an OPT RR is structured as follows:
 120
 121      Field Name   Field Type     Description
 122      ------------------------------------------------------
 123      NAME         domain name    empty (root domain)
 124      TYPE         u_int16_t      OPT
 125      CLASS        u_int16_t      sender's UDP payload size
 126      TTL          u_int32_t      extended RCODE and flags
 127      RDLEN        u_int16_t      describes RDATA
 128      RDATA        octet stream   {attribute,value} pairs
 129
 130 4.4. The variable part of an OPT RR is encoded in its RDATA and is
 131      structured as zero or more of the following:
 132
 133                 +0 (MSB)                            +1 (LSB)
 134      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 135   0: |                          OPTION-CODE                          |
 136      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 137   2: |                         OPTION-LENGTH                         |
 138      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 139   4: |                                                               |
 140      /                          OPTION-DATA                          /
 141      /                                                               /
 142      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 143
 144    OPTION-CODE    (Assigned by IANA.)
 145
 146    OPTION-LENGTH  Size (in octets) of OPTION-DATA.
 147
 148    OPTION-DATA    Varies per OPTION-CODE.
 149
 150 4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
 151      field) is the number of octets of the largest UDP payload that can
 152      be reassembled and delivered in the sender's network stack.  Note
 153      that path MTU, with or without fragmentation, may be smaller than
 154      this.
 155
 156 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
 157        reassembly buffer.  Choosing 1280 on an Ethernet connected
 158        requestor would be reasonable.  The consequence of choosing too
 159        large a value may be an ICMP message from an intermediate
 160        gateway, or even a silent drop of the response message.
 161
 162 4.5.2. Both requestors and responders are advised to take account of the
 163        path's discovered MTU (if already known) when considering message
 164        sizes.
 165
 166
 167
 168
 169
 170 Vixie                       Standards Track                     [Page 3]
 171 \f
 172 RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
 173
 174
 175 4.5.3. The requestor's maximum payload size can change over time, and
 176        should therefore not be cached for use beyond the transaction in
 177        which it is advertised.
 178
 179 4.5.4. The responder's maximum payload size can change over time, but
 180        can be reasonably expected to remain constant between two
 181        sequential transactions; for example, a meaningless QUERY to
 182        discover a responder's maximum UDP payload size, followed
 183        immediately by an UPDATE which takes advantage of this size.
 184        (This is considered preferrable to the outright use of TCP for
 185        oversized requests, if there is any reason to suspect that the
 186        responder implements EDNS, and if a request will not fit in the
 187        default 512 payload size limit.)
 188
 189 4.5.5. Due to transaction overhead, it is unwise to advertise an
 190        architectural limit as a maximum UDP payload size.  Just because
 191        your stack can reassemble 64KB datagrams, don't assume that you
 192        want to spend more than about 4KB of state memory per ongoing
 193        transaction.
 194
 195 4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
 196      are structured as follows:
 197
 198                  +0 (MSB)                            +1 (LSB)
 199       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 200    0: |         EXTENDED-RCODE        |            VERSION            |
 201       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 202    2: |                               Z                               |
 203       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 204
 205    EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note
 206                    that EXTENDED-RCODE value "0" indicates that an
 207                    unextended RCODE is in use (values "0" through "15").
 208
 209    VERSION         Indicates the implementation level of whoever sets
 210                    it.  Full conformance with this specification is
 211                    indicated by version "0."  Requestors are encouraged
 212                    to set this to the lowest implemented level capable
 213                    of expressing a transaction, to minimize the
 214                    responder and network load of discovering the
 215                    greatest common implementation level between
 216                    requestor and responder.  A requestor's version
 217                    numbering strategy should ideally be a run time
 218                    configuration option.
 219
 220                    If a responder does not implement the VERSION level
 221                    of the request, then it answers with RCODE=BADVERS.
 222                    All responses will be limited in format to the
 223
 224
 225
 226 Vixie                       Standards Track                     [Page 4]
 227 \f
 228 RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
 229
 230
 231                    VERSION level of the request, but the VERSION of each
 232                    response will be the highest implementation level of
 233                    the responder.  In this way a requestor will learn
 234                    the implementation level of a responder as a side
 235                    effect of every response, including error responses,
 236                    including RCODE=BADVERS.
 237
 238    Z               Set to zero by senders and ignored by receivers,
 239                    unless modified in a subsequent specification.
 240
 241 5 - Transport Considerations
 242
 243 5.1. The presence of an OPT pseudo-RR in a request should be taken as an
 244      indication that the requestor fully implements the given version of
 245      EDNS, and can correctly understand any response that conforms to
 246      that feature's specification.
 247
 248 5.2. Lack of use of these features in a request must be taken as an
 249      indication that the requestor does not implement any part of this
 250      specification and that the responder may make no use of any
 251      protocol extension described here in its response.
 252
 253 5.3. Responders who do not understand these protocol extensions are
 254      expected to send a response with RCODE NOTIMPL, FORMERR, or
 255      SERVFAIL.  Therefore use of extensions should be "probed" such that
 256      a responder who isn't known to support them be allowed a retry with
 257      no extensions if it responds with such an RCODE.  If a responder's
 258      capability level is cached by a requestor, a new probe should be
 259      sent periodically to test for changes to responder capability.
 260
 261 6 - Security Considerations
 262
 263      Requestor-side specification of the maximum buffer size may open a
 264      new DNS denial of service attack if responders can be made to send
 265      messages which are too large for intermediate gateways to forward,
 266      thus leading to potential ICMP storms between gateways and
 267      responders.
 268
 269 7 - IANA Considerations
 270
 271      The IANA has assigned RR type code 41 for OPT.
 272
 273      It is the recommendation of this document and its working group
 274      that IANA create a registry for EDNS Extended Label Types, for EDNS
 275      Option Codes, and for EDNS Version Numbers.
 276
 277      This document assigns label type 0b01xxxxxx as "EDNS Extended Label
 278      Type."  We request that IANA record this assignment.
 279
 280
 281
 282 Vixie                       Standards Track                     [Page 5]
 283 \f
 284 RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
 285
 286
 287      This document assigns extended label type 0bxx111111 as "Reserved
 288      for future extended label types."  We request that IANA record this
 289      assignment.
 290
 291      This document assigns option code 65535 to "Reserved for future
 292      expansion."
 293
 294      This document expands the RCODE space from 4 bits to 12 bits.  This
 295      will allow IANA to assign more than the 16 distinct RCODE values
 296      allowed in [RFC1035].
 297
 298      This document assigns EDNS Extended RCODE "16" to "BADVERS".
 299
 300      IESG approval should be required to create new entries in the EDNS
 301      Extended Label Type or EDNS Version Number registries, while any
 302      published RFC (including Informational, Experimental, or BCP)
 303      should be grounds for allocation of an EDNS Option Code.
 304
 305 8 - Acknowledgements
 306
 307      Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
 308      Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
 309      Narten were each instrumental in creating and refining this
 310      specification.
 311
 312 9 - References
 313
 314     [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
 315                Specification", STD 13, RFC 1035, November 1987.
 316
 317 10 - Author's Address
 318
 319    Paul Vixie
 320    Internet Software Consortium
 321    950 Charter Street
 322    Redwood City, CA 94063
 323
 324    Phone: +1 650 779 7001
 325    EMail: vixie@isc.org
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Vixie                       Standards Track                     [Page 6]
 339 \f
 340 RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
 341
 342
 343 11 - Full Copyright Statement
 344
 345    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 346
 347    This document and translations of it may be copied and furnished to
 348    others, and derivative works that comment on or otherwise explain it
 349    or assist in its implementation may be prepared, copied, published
 350    and distributed, in whole or in part, without restriction of any
 351    kind, provided that the above copyright notice and this paragraph are
 352    included on all such copies and derivative works.  However, this
 353    document itself may not be modified in any way, such as by removing
 354    the copyright notice or references to the Internet Society or other
 355    Internet organizations, except as needed for the purpose of
 356    developing Internet standards in which case the procedures for
 357    copyrights defined in the Internet Standards process must be
 358    followed, or as required to translate it into languages other than
 359    English.
 360
 361    The limited permissions granted above are perpetual and will not be
 362    revoked by the Internet Society or its successors or assigns.
 363
 364    This document and the information contained herein is provided on an
 365    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 366    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 367    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 368    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 369    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 370
 371 Acknowledgement
 372
 373    Funding for the RFC Editor function is currently provided by the
 374    Internet Society.
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Vixie                       Standards Track                     [Page 7]
 395 \f