contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt

   1
   2
   3
   4 INTERNET-DRAFT                                      Andreas Gustafsson
   5 draft-ietf-dnsext-axfr-clarify-05.txt                     Nominum Inc.
   6                                                          November 2002
   7
   8
   9                DNS Zone Transfer Protocol Clarifications
  10
  11
  12 Status of this Memo
  13
  14    This document is an Internet-Draft and is in full conformance with
  15    all provisions of Section 10 of RFC2026.
  16
  17    Internet-Drafts are working documents of the Internet Engineering
  18    Task Force (IETF), its areas, and its working groups.  Note that
  19    other groups may also distribute working documents as Internet-
  20    Drafts.
  21
  22    Internet-Drafts are draft documents valid for a maximum of six months
  23    and may be updated, replaced, or obsoleted by other documents at any
  24    time.  It is inappropriate to use Internet-Drafts as reference
  25    material or to cite them other than as "work in progress."
  26
  27    The list of current Internet-Drafts can be accessed at
  28    http://www.ietf.org/ietf/1id-abstracts.txt
  29
  30    The list of Internet-Draft Shadow Directories can be accessed at
  31    http://www.ietf.org/shadow.html.
  32
  33 Abstract
  34
  35    In the Domain Name System, zone data is replicated among
  36    authoritative DNS servers by means of the "zone transfer" protocol,
  37    also known as the "AXFR" protocol.  This memo clarifies, updates, and
  38    adds missing detail to the original AXFR protocol specification in
  39    RFC1034.
  40
  41 1. Introduction
  42
  43    The original definition of the DNS zone transfer protocol consists of
  44    a single paragraph in [RFC1034] section 4.3.5 and some additional
  45    notes in [RFC1035] section 6.3.  It is not sufficiently detailed to
  46    serve as the sole basis for constructing interoperable
  47    implementations.  This document is an attempt to provide a more
  48    complete definition of the protocol.  Where the text in RFC1034
  49    conflicts with existing practice, the existing practice has been
  50    codified in the interest of interoperability.
  51
  52
  53
  54
  55 Expires May 2003                                                [Page 1]
  56 \f
  57 draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
  58
  59
  60    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  61    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  62    document are to be interpreted as described in [RFC 2119].
  63
  64 2. The zone transfer request
  65
  66    To initiate a zone transfer, the slave server sends a zone transfer
  67    request to the master server over a reliable transport such as TCP.
  68    The form of this request is specified in sufficient detail in RFC1034
  69    and needs no further clarification.
  70
  71    Implementers are advised that one server implementation in widespread
  72    use sends AXFR requests where the TCP message envelope size exceeds
  73    the DNS request message size by two octets.
  74
  75 3. The zone transfer response
  76
  77    If the master server is unable or unwilling to provide a zone
  78    transfer, it MUST respond with a single DNS message containing an
  79    appropriate RCODE other than NOERROR.  If the master is not
  80    authoritative for the requested zone, the RCODE SHOULD be 9
  81    (NOTAUTH).
  82
  83    Slave servers should note that some master server implementations
  84    will simply close the connection when denying the slave access to the
  85    zone.  Therefore, slaves MAY interpret an immediate graceful close of
  86    the TCP connection as equivalent to a "Refused" response (RCODE 5).
  87
  88    If a zone transfer can be provided, the master server sends one or
  89    more DNS messages containing the zone data as described below.
  90
  91 3.1. Multiple answers per message
  92
  93    The zone data in a zone transfer response is a sequence of answer
  94    RRs.  These RRs are transmitted in the answer section(s) of one or
  95    more DNS response messages.
  96
  97    The AXFR protocol definition in RFC1034 does not make a clear
  98    distinction between response messages and answer RRs.  Historically,
  99    DNS servers always transmitted a single answer RR per message.  This
 100    encoding is wasteful due to the overhead of repeatedly sending DNS
 101    message headers and the loss of domain name compression
 102    opportunities.  To improve efficiency, some newer servers support a
 103    mode where multiple RRs are transmitted in a single DNS response
 104    message.
 105
 106    A master MAY transmit multiple answer RRs per response message up to
 107    the largest number that will fit within the 65535 byte limit on TCP
 108
 109
 110
 111 Expires May 2003                                                [Page 2]
 112 \f
 113 draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
 114
 115
 116    DNS message size.  In the case of a small zone, this can cause the
 117    entire transfer to be transmitted in a single response message.
 118
 119    Slaves MUST accept messages containing any number of answer RRs.  For
 120    compatibility with old slaves, masters that support sending multiple
 121    answers per message SHOULD be configurable to revert to the
 122    historical mode of one answer per message, and the configuration
 123    SHOULD be settable on a per-slave basis.
 124
 125 3.2. DNS message header contents
 126
 127    RFC1034 does not specify the contents of the DNS message header of
 128    the zone transfer response messages.  The header of each message MUST
 129    be as follows:
 130
 131        ID      Copy from request
 132        QR      1
 133        OPCODE  QUERY
 134        AA      1, but MAY be 0 when RCODE is not NOERROR
 135        TC      0
 136        RD      Copy from request, or 0
 137        RA      Set according to availability of recursion, or 0
 138        Z       0
 139        AD      0
 140        CD      0
 141        RCODE   NOERROR on success, error code otherwise
 142
 143    The slave MUST check the RCODE in each message and abort the transfer
 144    if it is not NOERROR.  It SHOULD check the ID of the first message
 145    received and abort the transfer if it does not match the ID of the
 146    request.  The ID SHOULD be ignored in subsequent messages, and fields
 147    other than RCODE and ID SHOULD be ignored in all messages, to ensure
 148    interoperability with certain older implementations which transmit
 149    incorrect or arbitrary values in these fields.
 150
 151 3.3. Additional section and SIG processing
 152
 153    Zone transfer responses are not subject to any kind of additional
 154    section processing or automatic inclusion of SIG records.  SIG RRs in
 155    the zone data are treated exactly the same as any other RR type.
 156
 157 3.4. The question section
 158
 159    RFC1034 does not specify whether zone transfer response messages have
 160    a question section or not.  The initial message of a zone transfer
 161    response SHOULD have a question section identical to that in the
 162    request.  Subsequent messages SHOULD NOT have a question section,
 163    though the final message MAY.  The receiving slave server MUST accept
 164
 165
 166
 167 Expires May 2003                                                [Page 3]
 168 \f
 169 draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
 170
 171
 172    any combination of messages with and without a question section.
 173
 174 3.5. The authority section
 175
 176    The master server MUST transmit messages with an empty authority
 177    section.  Slaves MUST ignore any authority section contents they may
 178    receive from masters that do not comply with this requirement.
 179
 180 3.6. The additional section
 181
 182    The additional section MAY contain additional RRs such as transaction
 183    signatures.  The slave MUST ignore any unexpected RRs in the
 184    additional section.  It MUST NOT treat additional section RRs as zone
 185    data.
 186
 187 4. Zone data
 188
 189    The purpose of the zone transfer mechanism is to exactly replicate at
 190    each slave the set of RRs associated with a particular zone at its
 191    primary master.  An RR is associated with a zone by being loaded from
 192    the master file of that zone at the primary master server, or by some
 193    other, equivalent method for configuring zone data.
 194
 195    This replication shall be complete and unaltered, regardless of how
 196    many and which intermediate masters/slaves are involved, and
 197    regardless of what other zones those intermediate masters/slaves do
 198    or do not serve, and regardless of what data may be cached in
 199    resolvers associated with the intermediate masters/slaves.
 200
 201    Therefore, in a zone transfer the master MUST send exactly those
 202    records that are associated with the zone, whether or not their owner
 203    names would be considered to be "in" the zone for purposes of
 204    resolution, and whether or not they would be eligible for use as glue
 205    in responses.  The transfer MUST NOT include any RRs that are not
 206    associated with the zone, such as RRs associated with zones other
 207    than the one being transferred or present in the cache of the local
 208    resolver, even if their owner names are in the zone being transferred
 209    or are pointed to by NS records in the zone being transferred.
 210
 211    The slave MUST associate the RRs received in a zone transfer with the
 212    specific zone being transferred, and maintain that association for
 213    purposes of acting as a master in outgoing transfers.
 214
 215 5. Transmission order
 216
 217    RFC1034 states that "The first and last messages must contain the
 218    data for the top authoritative node of the zone".  This is not
 219    consistent with existing practice.  All known master implementations
 220
 221
 222
 223 Expires May 2003                                                [Page 4]
 224 \f
 225 draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
 226
 227
 228    send, and slave implementations expect to receive, the zone's SOA RR
 229    as the first and last record of the transfer.
 230
 231    Therefore, the quoted sentence is hereby superseded by the sentence
 232    "The first and last RR transmitted must be the SOA record of the
 233    zone".
 234
 235    The initial and final SOA record MUST be identical, with the possible
 236    exception of case and compression.  In particular, they MUST have the
 237    same serial number.  The slave MUST consider the transfer to be
 238    complete when, and only when, it has received the message containing
 239    the second SOA record.
 240
 241    The transmission order of all other RRs in the zone is undefined.
 242    Each of them SHOULD be transmitted only once, and slaves MUST ignore
 243    any duplicate RRs received.
 244
 245 6. Security Considerations
 246
 247    The zone transfer protocol as defined in [RFC1034] and clarified by
 248    this memo does not have any built-in mechanisms for the slave to
 249    securely verify the identity of the master server and the integrity
 250    of the transferred zone data.  The use of a cryptographic mechanism
 251    for ensuring authenticity and integrity, such as TSIG [RFC2845],
 252    IPSEC, or TLS, is RECOMMENDED.
 253
 254    The zone transfer protocol allows read-only public access to the
 255    complete zone data.  Since data in the DNS is public by definition,
 256    this is generally acceptable.  Sites that wish to avoid disclosing
 257    their full zone data MAY restrict zone transfer access to authorized
 258    slaves.
 259
 260    These clarifications are not believed to themselves introduce any new
 261    security problems, nor to solve any existing ones.
 262
 263 Acknowledgements
 264
 265    Many people have contributed input and commentary to earlier versions
 266    of this document, including but not limited to Bob Halley, Dan
 267    Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
 268    Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
 269    Trenholme, and Brian Wellington.
 270
 271 References
 272
 273    [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
 274    November 1987.
 275
 276
 277
 278
 279 Expires May 2003                                                [Page 5]
 280 \f
 281 draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
 282
 283
 284    [RFC1035] - Domain Names - Implementation and Specifications, P.
 285    Mockapetris, November 1987.
 286
 287    [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
 288    S. Bradner, BCP 14, March 1997.
 289
 290    [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG).  P.
 291    Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
 292
 293 Author's Address
 294
 295    Andreas Gustafsson
 296    Nominum Inc.
 297    2385 Bay Rd
 298    Redwood City, CA 94063
 299    USA
 300
 301    Phone: +1 650 381 6004
 302
 303    Email: gson@nominum.com
 304
 305
 306 Full Copyright Statement
 307
 308    Copyright (C) The Internet Society (2000 - 2002).  All Rights Reserved.
 309
 310    This document and translations of it may be copied and furnished to
 311    others, and derivative works that comment on or otherwise explain it
 312    or assist in its implmentation may be prepared, copied, published and
 313    distributed, in whole or in part, without restriction of any kind,
 314    provided that the above copyright notice and this paragraph are
 315    included on all such copies and derivative works.  However, this
 316    document itself may not be modified in any way, such as by removing
 317    the copyright notice or references to the Internet Society or other
 318    Internet organizations, except as needed for the purpose of
 319    developing Internet standards in which case the procedures for
 320    copyrights defined in the Internet Standards process must be
 321    followed, or as required to translate it into languages other than
 322    English.
 323
 324    The limited permissions granted above are perpetual and will not be
 325    revoked by the Internet Society or its successors or assigns.
 326
 327    This document and the information contained herein is provided on an
 328    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 329    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 330    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 331    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 332
 333
 334
 335 Expires May 2003                                                [Page 6]
 336 \f
 337 draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
 338
 339
 340    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391 Expires May 2003                                                [Page 7]
 392 \f
 393