contrib/bind9/doc/rfc/rfc2136.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                  P. Vixie, Editor
   8 Request for Comments: 2136                                          ISC
   9 Updates: 1035                                                S. Thomson
  10 Category: Standards Track                                      Bellcore
  11                                                              Y. Rekhter
  12                                                                   Cisco
  13                                                                J. Bound
  14                                                                     DEC
  15                                                              April 1997
  16
  17          Dynamic Updates in the Domain Name System (DNS UPDATE)
  18
  19 Status of this Memo
  20
  21    This document specifies an Internet standards track protocol for the
  22    Internet community, and requests discussion and suggestions for
  23    improvements.  Please refer to the current edition of the "Internet
  24    Official Protocol Standards" (STD 1) for the standardization state
  25    and status of this protocol.  Distribution of this memo is unlimited.
  26
  27 Abstract
  28
  29    The Domain Name System was originally designed to support queries of
  30    a statically configured database.  While the data was expected to
  31    change, the frequency of those changes was expected to be fairly low,
  32    and all updates were made as external edits to a zone's Master File.
  33
  34    Using this specification of the UPDATE opcode, it is possible to add
  35    or delete RRs or RRsets from a specified zone.  Prerequisites are
  36    specified separately from update operations, and can specify a
  37    dependency upon either the previous existence or nonexistence of an
  38    RRset, or the existence of a single RR.
  39
  40    UPDATE is atomic, i.e., all prerequisites must be satisfied or else
  41    no update operations will take place.  There are no data dependent
  42    error conditions defined after the prerequisites have been met.
  43
  44 1 - Definitions
  45
  46    This document intentionally gives more definition to the roles of
  47    "Master," "Slave," and "Primary Master" servers, and their
  48    enumeration in NS RRs, and the SOA MNAME field.  In that sense, the
  49    following server type definitions can be considered an addendum to
  50    [RFC1035], and are intended to be consistent with [RFC1996]:
  51
  52       Slave           an authoritative server that uses AXFR or IXFR to
  53                       retrieve the zone and is named in the zone's NS
  54                       RRset.
  55
  56
  57
  58 Vixie, et. al.              Standards Track                     [Page 1]
  59 \f
  60 RFC 2136                       DNS Update                     April 1997
  61
  62
  63       Master          an authoritative server configured to be the
  64                       source of AXFR or IXFR data for one or more slave
  65                       servers.
  66
  67       Primary Master  master server at the root of the AXFR/IXFR
  68                       dependency graph.  The primary master is named in
  69                       the zone's SOA MNAME field and optionally by an NS
  70                       RR.  There is by definition only one primary master
  71                       server per zone.
  72
  73    A domain name identifies a node within the domain name space tree
  74    structure.  Each node has a set (possibly empty) of Resource Records
  75    (RRs).  All RRs having the same NAME, CLASS and TYPE are called a
  76    Resource Record Set (RRset).
  77
  78    The pseudocode used in this document is for example purposes only.
  79    If it is found to disagree with the text, the text shall be
  80    considered authoritative.  If the text is found to be ambiguous, the
  81    pseudocode can be used to help resolve the ambiguity.
  82
  83    1.1 - Comparison Rules
  84
  85    1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
  86    RDLENGTH and RDATA fields are equal.  Note that the time-to-live
  87    (TTL) field is explicitly excluded from the comparison.
  88
  89    1.1.2. The rules for comparison of character strings in names are
  90    specified in [RFC1035 2.3.3].
  91
  92    1.1.3. Wildcarding is disabled.  That is, a wildcard ("*") in an
  93    update only matches a wildcard ("*") in the zone, and vice versa.
  94
  95    1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
  96    the update, and will not otherwise be followed.  All UPDATE
  97    operations are done on the basis of canonical names.
  98
  99    1.1.5. The following RR types cannot be appended to an RRset.  If the
 100    following comparison rules are met, then an attempt to add the new RR
 101    will result in the replacement of the previous RR:
 102
 103       SOA    compare only NAME, CLASS and TYPE -- it is not possible to
 104              have more than one SOA per zone, even if any of the data
 105              fields differ.
 106
 107       WKS    compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
 108              -- only one WKS RR is possible for this tuple, even if the
 109              services masks differ.
 110
 111
 112
 113
 114 Vixie, et. al.              Standards Track                     [Page 2]
 115 \f
 116 RFC 2136                       DNS Update                     April 1997
 117
 118
 119       CNAME  compare only NAME, CLASS, and TYPE -- it is not possible
 120              to have more than one CNAME RR, even if their data fields
 121              differ.
 122
 123    1.2 - Glue RRs
 124
 125    For the purpose of determining whether a domain name used in the
 126    UPDATE protocol is contained within a specified zone, a domain name
 127    is "in" a zone if it is owned by that zone's domain name.  See
 128    section 7.18 for details.
 129
 130    1.3 - New Assigned Numbers
 131
 132       CLASS = NONE (254)
 133       RCODE = YXDOMAIN (6)
 134       RCODE = YXRRSET (7)
 135       RCODE = NXRRSET (8)
 136       RCODE = NOTAUTH (9)
 137       RCODE = NOTZONE (10)
 138       Opcode = UPDATE (5)
 139
 140 2 - Update Message Format
 141
 142    The DNS Message Format is defined by [RFC1035 4.1].  Some extensions
 143    are necessary (for example, more error codes are possible under
 144    UPDATE than under QUERY) and some fields must be overloaded (see
 145    description of CLASS fields below).
 146
 147    The overall format of an UPDATE message is, following [ibid]:
 148
 149       +---------------------+
 150       |        Header       |
 151       +---------------------+
 152       |         Zone        | specifies the zone to be updated
 153       +---------------------+
 154       |     Prerequisite    | RRs or RRsets which must (not) preexist
 155       +---------------------+
 156       |        Update       | RRs or RRsets to be added or deleted
 157       +---------------------+
 158       |   Additional Data   | additional data
 159       +---------------------+
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170 Vixie, et. al.              Standards Track                     [Page 3]
 171 \f
 172 RFC 2136                       DNS Update                     April 1997
 173
 174
 175    The Header Section specifies that this message is an UPDATE, and
 176    describes the size of the other sections.  The Zone Section names the
 177    zone that is to be updated by this message.  The Prerequisite Section
 178    specifies the starting invariants (in terms of zone content) required
 179    for this update.  The Update Section contains the edits to be made,
 180    and the Additional Data Section contains data which may be necessary
 181    to complete, but is not part of, this update.
 182
 183    2.1 - Transport Issues
 184
 185    An update transaction may be carried in a UDP datagram, if the
 186    request fits, or in a TCP connection (at the discretion of the
 187    requestor).  When TCP is used, the message is in the format described
 188    in [RFC1035 4.2.2].
 189
 190    2.2 - Message Header
 191
 192    The header of the DNS Message Format is defined by [RFC 1035 4.1].
 193    Not all opcodes define the same set of flag bits, though as a
 194    practical matter most of the bits defined for QUERY (in [ibid]) are
 195    identically defined by the other opcodes.  UPDATE uses only one flag
 196    bit (QR).
 197
 198    The DNS Message Format specifies record counts for its four sections
 199    (Question, Answer, Authority, and Additional).  UPDATE uses the same
 200    fields, and the same section formats, but the naming and use of these
 201    sections differs as shown in the following modified header, after
 202    [RFC1035 4.1.1]:
 203
 204                                       1  1  1  1  1  1
 205         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
 206       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 207       |                      ID                       |
 208       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 209       |QR|   Opcode  |          Z         |   RCODE   |
 210       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 211       |                    ZOCOUNT                    |
 212       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 213       |                    PRCOUNT                    |
 214       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 215       |                    UPCOUNT                    |
 216       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 217       |                    ADCOUNT                    |
 218       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 219
 220
 221
 222
 223
 224
 225
 226 Vixie, et. al.              Standards Track                     [Page 4]
 227 \f
 228 RFC 2136                       DNS Update                     April 1997
 229
 230
 231    These fields are used as follows:
 232
 233    ID      A 16-bit identifier assigned by the entity that generates any
 234            kind of request.  This identifier is copied in the
 235            corresponding reply and can be used by the requestor to match
 236            replies to outstanding requests, or by the server to detect
 237            duplicated requests from some requestor.
 238
 239    QR      A one bit field that specifies whether this message is a
 240            request (0), or a response (1).
 241
 242    Opcode  A four bit field that specifies the kind of request in this
 243            message.  This value is set by the originator of a request
 244            and copied into the response.  The Opcode value that
 245            identifies an UPDATE message is five (5).
 246
 247    Z       Reserved for future use.  Should be zero (0) in all requests
 248            and responses.  A non-zero Z field should be ignored by
 249            implementations of this specification.
 250
 251    RCODE   Response code - this four bit field is undefined in requests
 252            and set in responses.  The values and meanings of this field
 253            within responses are as follows:
 254
 255               Mneumonic   Value   Description
 256               ------------------------------------------------------------
 257               NOERROR     0       No error condition.
 258               FORMERR     1       The name server was unable to interpret
 259                                   the request due to a format error.
 260               SERVFAIL    2       The name server encountered an internal
 261                                   failure while processing this request,
 262                                   for example an operating system error
 263                                   or a forwarding timeout.
 264               NXDOMAIN    3       Some name that ought to exist,
 265                                   does not exist.
 266               NOTIMP      4       The name server does not support
 267                                   the specified Opcode.
 268               REFUSED     5       The name server refuses to perform the
 269                                   specified operation for policy or
 270                                   security reasons.
 271               YXDOMAIN    6       Some name that ought not to exist,
 272                                   does exist.
 273               YXRRSET     7       Some RRset that ought not to exist,
 274                                   does exist.
 275               NXRRSET     8       Some RRset that ought to exist,
 276                                   does not exist.
 277
 278
 279
 280
 281
 282 Vixie, et. al.              Standards Track                     [Page 5]
 283 \f
 284 RFC 2136                       DNS Update                     April 1997
 285
 286
 287               NOTAUTH     9       The server is not authoritative for
 288                                   the zone named in the Zone Section.
 289               NOTZONE     10      A name used in the Prerequisite or
 290                                   Update Section is not within the
 291                                   zone denoted by the Zone Section.
 292
 293    ZOCOUNT The number of RRs in the Zone Section.
 294
 295    PRCOUNT The number of RRs in the Prerequisite Section.
 296
 297    UPCOUNT The number of RRs in the Update Section.
 298
 299    ADCOUNT The number of RRs in the Additional Data Section.
 300
 301    2.3 - Zone Section
 302
 303    The Zone Section has the same format as that specified in [RFC1035
 304    4.1.2], with the fields redefined as follows:
 305
 306                                       1  1  1  1  1  1
 307         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
 308       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 309       |                                               |
 310       /                     ZNAME                     /
 311       /                                               /
 312       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 313       |                     ZTYPE                     |
 314       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 315       |                     ZCLASS                    |
 316       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 317
 318    UPDATE uses this section to denote the zone of the records being
 319    updated.  All records to be updated must be in the same zone, and
 320    therefore the Zone Section is allowed to contain exactly one record.
 321    The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
 322    the zone's class.
 323
 324    2.4 - Prerequisite Section
 325
 326    This section contains a set of RRset prerequisites which must be
 327    satisfied at the time the UPDATE packet is received by the primary
 328    master server.  The format of this section is as specified by
 329    [RFC1035 4.1.3].  There are five possible sets of semantics that can
 330    be expressed here, summarized as follows and then explained below.
 331
 332       (1)  RRset exists (value independent).  At least one RR with a
 333            specified NAME and TYPE (in the zone and class specified by
 334            the Zone Section) must exist.
 335
 336
 337
 338 Vixie, et. al.              Standards Track                     [Page 6]
 339 \f
 340 RFC 2136                       DNS Update                     April 1997
 341
 342
 343       (2)  RRset exists (value dependent).  A set of RRs with a
 344            specified NAME and TYPE exists and has the same members
 345            with the same RDATAs as the RRset specified here in this
 346            Section.
 347
 348       (3)  RRset does not exist.  No RRs with a specified NAME and TYPE
 349           (in the zone and class denoted by the Zone Section) can exist.
 350
 351       (4)  Name is in use.  At least one RR with a specified NAME (in
 352            the zone and class specified by the Zone Section) must exist.
 353            Note that this prerequisite is NOT satisfied by empty
 354            nonterminals.
 355
 356       (5)  Name is not in use.  No RR of any type is owned by a
 357            specified NAME.  Note that this prerequisite IS satisfied by
 358            empty nonterminals.
 359
 360    The syntax of these is as follows:
 361
 362    2.4.1 - RRset Exists (Value Independent)
 363
 364    At least one RR with a specified NAME and TYPE (in the zone and class
 365    specified in the Zone Section) must exist.
 366
 367    For this prerequisite, a requestor adds to the section a single RR
 368    whose NAME and TYPE are equal to that of the zone RRset whose
 369    existence is required.  RDLENGTH is zero and RDATA is therefore
 370    empty.  CLASS must be specified as ANY to differentiate this
 371    condition from that of an actual RR whose RDLENGTH is naturally zero
 372    (0) (e.g., NULL).  TTL is specified as zero (0).
 373
 374    2.4.2 - RRset Exists (Value Dependent)
 375
 376    A set of RRs with a specified NAME and TYPE exists and has the same
 377    members with the same RDATAs as the RRset specified here in this
 378    section.  While RRset ordering is undefined and therefore not
 379    significant to this comparison, the sets be identical in their
 380    extent.
 381
 382    For this prerequisite, a requestor adds to the section an entire
 383    RRset whose preexistence is required.  NAME and TYPE are that of the
 384    RRset being denoted.  CLASS is that of the zone.  TTL must be
 385    specified as zero (0) and is ignored when comparing RRsets for
 386    identity.
 387
 388
 389
 390
 391
 392
 393
 394 Vixie, et. al.              Standards Track                     [Page 7]
 395 \f
 396 RFC 2136                       DNS Update                     April 1997
 397
 398
 399    2.4.3 - RRset Does Not Exist
 400
 401    No RRs with a specified NAME and TYPE (in the zone and class denoted
 402    by the Zone Section) can exist.
 403
 404    For this prerequisite, a requestor adds to the section a single RR
 405    whose NAME and TYPE are equal to that of the RRset whose nonexistence
 406    is required.  The RDLENGTH of this record is zero (0), and RDATA
 407    field is therefore empty.  CLASS must be specified as NONE in order
 408    to distinguish this condition from a valid RR whose RDLENGTH is
 409    naturally zero (0) (for example, the NULL RR).  TTL must be specified
 410    as zero (0).
 411
 412    2.4.4 - Name Is In Use
 413
 414    Name is in use.  At least one RR with a specified NAME (in the zone
 415    and class specified by the Zone Section) must exist.  Note that this
 416    prerequisite is NOT satisfied by empty nonterminals.
 417
 418    For this prerequisite, a requestor adds to the section a single RR
 419    whose NAME is equal to that of the name whose ownership of an RR is
 420    required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS must
 421    be specified as ANY to differentiate this condition from that of an
 422    actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL).  TYPE
 423    must be specified as ANY to differentiate this case from that of an
 424    RRset existence test.  TTL is specified as zero (0).
 425
 426    2.4.5 - Name Is Not In Use
 427
 428    Name is not in use.  No RR of any type is owned by a specified NAME.
 429    Note that this prerequisite IS satisfied by empty nonterminals.
 430
 431    For this prerequisite, a requestor adds to the section a single RR
 432    whose NAME is equal to that of the name whose nonownership of any RRs
 433    is required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS
 434    must be specified as NONE.  TYPE must be specified as ANY.  TTL must
 435    be specified as zero (0).
 436
 437    2.5 - Update Section
 438
 439    This section contains RRs to be added to or deleted from the zone.
 440    The format of this section is as specified by [RFC1035 4.1.3].  There
 441    are four possible sets of semantics, summarized below and with
 442    details to follow.
 443
 444
 445
 446
 447
 448
 449
 450 Vixie, et. al.              Standards Track                     [Page 8]
 451 \f
 452 RFC 2136                       DNS Update                     April 1997
 453
 454
 455       (1) Add RRs to an RRset.
 456       (2) Delete an RRset.
 457       (3) Delete all RRsets from a name.
 458       (4) Delete an RR from an RRset.
 459
 460    The syntax of these is as follows:
 461
 462    2.5.1 - Add To An RRset
 463
 464    RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
 465    and RDATA are those being added, and CLASS is the same as the zone
 466    class.  Any duplicate RRs will be silently ignored by the primary
 467    master.
 468
 469    2.5.2 - Delete An RRset
 470
 471    One RR is added to the Update Section whose NAME and TYPE are those
 472    of the RRset to be deleted.  TTL must be specified as zero (0) and is
 473    otherwise not used by the primary master.  CLASS must be specified as
 474    ANY.  RDLENGTH must be zero (0) and RDATA must therefore be empty.
 475    If no such RRset exists, then this Update RR will be silently ignored
 476    by the primary master.
 477
 478    2.5.3 - Delete All RRsets From A Name
 479
 480    One RR is added to the Update Section whose NAME is that of the name
 481    to be cleansed of RRsets.  TYPE must be specified as ANY.  TTL must
 482    be specified as zero (0) and is otherwise not used by the primary
 483    master.  CLASS must be specified as ANY.  RDLENGTH must be zero (0)
 484    and RDATA must therefore be empty.  If no such RRsets exist, then
 485    this Update RR will be silently ignored by the primary master.
 486
 487    2.5.4 - Delete An RR From An RRset
 488
 489    RRs to be deleted are added to the Update Section.  The NAME, TYPE,
 490    RDLENGTH and RDATA must match the RR being deleted.  TTL must be
 491    specified as zero (0) and will otherwise be ignored by the primary
 492    master.  CLASS must be specified as NONE to distinguish this from an
 493    RR addition.  If no such RRs exist, then this Update RR will be
 494    silently ignored by the primary master.
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Vixie, et. al.              Standards Track                     [Page 9]
 507 \f
 508 RFC 2136                       DNS Update                     April 1997
 509
 510
 511    2.6 - Additional Data Section
 512
 513    This section contains RRs which are related to the update itself, or
 514    to new RRs being added by the update.  For example, out of zone glue
 515    (A RRs referred to by new NS RRs) should be presented here.  The
 516    server can use or ignore out of zone glue, at the discretion of the
 517    server implementor.  The format of this section is as specified by
 518    [RFC1035 4.1.3].
 519
 520 3 - Server Behavior
 521
 522    A server, upon receiving an UPDATE request, will signal NOTIMP to the
 523    requestor if the UPDATE opcode is not recognized or if it is
 524    recognized but has not been implemented.  Otherwise, processing
 525    continues as follows.
 526
 527    3.1 - Process Zone Section
 528
 529    3.1.1. The Zone Section is checked to see that there is exactly one
 530    RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
 531    requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
 532    so named is one of this server's authority zones, else signal NOTAUTH
 533    to the requestor.  If the server is a zone slave, the request will be
 534    forwarded toward the primary master.
 535
 536    3.1.2 - Pseudocode For Zone Section Processing
 537
 538       if (zcount != 1 || ztype != SOA)
 539            return (FORMERR)
 540       if (zone_type(zname, zclass) == SLAVE)
 541            return forward()
 542       if (zone_type(zname, zclass) == MASTER)
 543            return update()
 544       return (NOTAUTH)
 545
 546    Sections 3.2 through 3.8 describe the primary master's behaviour,
 547    whereas Section 6 describes a forwarder's behaviour.
 548
 549    3.2 - Process Prerequisite Section
 550
 551    Next, the Prerequisite Section is checked to see that all
 552    prerequisites are satisfied by the current state of the zone.  Using
 553    the definitions expressed in Section 1.2, if any RR's NAME is not
 554    within the zone specified in the Zone Section, signal NOTZONE to the
 555    requestor.
 556
 557
 558
 559
 560
 561
 562 Vixie, et. al.              Standards Track                    [Page 10]
 563 \f
 564 RFC 2136                       DNS Update                     April 1997
 565
 566
 567    3.2.1. For RRs in this section whose CLASS is ANY, test to see that
 568    TTL and RDLENGTH are both zero (0), else signal FORMERR to the
 569    requestor.  If TYPE is ANY, test to see that there is at least one RR
 570    in the zone whose NAME is the same as that of the Prerequisite RR,
 571    else signal NXDOMAIN to the requestor.  If TYPE is not ANY, test to
 572    see that there is at least one RR in the zone whose NAME and TYPE are
 573    the same as that of the Prerequisite RR, else signal NXRRSET to the
 574    requestor.
 575
 576    3.2.2. For RRs in this section whose CLASS is NONE, test to see that
 577    the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
 578    requestor.  If the TYPE is ANY, test to see that there are no RRs in
 579    the zone whose NAME is the same as that of the Prerequisite RR, else
 580    signal YXDOMAIN to the requestor.  If the TYPE is not ANY, test to
 581    see that there are no RRs in the zone whose NAME and TYPE are the
 582    same as that of the Prerequisite RR, else signal YXRRSET to the
 583    requestor.
 584
 585    3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
 586    test to see that the TTL is zero (0), else signal FORMERR to the
 587    requestor.  Then, build an RRset for each unique <NAME,TYPE> and
 588    compare each resulting RRset for set equality (same members, no more,
 589    no less) with RRsets in the zone.  If any Prerequisite RRset is not
 590    entirely and exactly matched by a zone RRset, signal NXRRSET to the
 591    requestor.  If any RR in this section has a CLASS other than ZCLASS
 592    or NONE or ANY, signal FORMERR to the requestor.
 593
 594    3.2.4 - Table Of Metavalues Used In Prerequisite Section
 595
 596    CLASS    TYPE     RDATA    Meaning
 597    ------------------------------------------------------------
 598    ANY      ANY      empty    Name is in use
 599    ANY      rrset    empty    RRset exists (value independent)
 600    NONE     ANY      empty    Name is not in use
 601    NONE     rrset    empty    RRset does not exist
 602    zone     rrset    rr       RRset exists (value dependent)
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Vixie, et. al.              Standards Track                    [Page 11]
 619 \f
 620 RFC 2136                       DNS Update                     April 1997
 621
 622
 623    3.2.5 - Pseudocode for Prerequisite Section Processing
 624
 625       for rr in prerequisites
 626            if (rr.ttl != 0)
 627                 return (FORMERR)
 628            if (zone_of(rr.name) != ZNAME)
 629                 return (NOTZONE);
 630            if (rr.class == ANY)
 631                 if (rr.rdlength != 0)
 632                      return (FORMERR)
 633                 if (rr.type == ANY)
 634                      if (!zone_name<rr.name>)
 635                           return (NXDOMAIN)
 636                 else
 637                      if (!zone_rrset<rr.name, rr.type>)
 638                           return (NXRRSET)
 639            if (rr.class == NONE)
 640                 if (rr.rdlength != 0)
 641                      return (FORMERR)
 642                 if (rr.type == ANY)
 643                      if (zone_name<rr.name>)
 644                           return (YXDOMAIN)
 645                 else
 646                      if (zone_rrset<rr.name, rr.type>)
 647                           return (YXRRSET)
 648            if (rr.class == zclass)
 649                 temp<rr.name, rr.type> += rr
 650            else
 651                 return (FORMERR)
 652
 653       for rrset in temp
 654            if (zone_rrset<rrset.name, rrset.type> != rrset)
 655                 return (NXRRSET)
 656
 657    3.3 - Check Requestor's Permissions
 658
 659    3.3.1. Next, the requestor's permission to update the RRs named in
 660    the Update Section may be tested in an implementation dependent
 661    fashion or using mechanisms specified in a subsequent Secure DNS
 662    Update protocol.  If the requestor does not have permission to
 663    perform these updates, the server may write a warning message in its
 664    operations log, and may either signal REFUSED to the requestor, or
 665    ignore the permission problem and proceed with the update.
 666
 667
 668
 669
 670
 671
 672
 673
 674 Vixie, et. al.              Standards Track                    [Page 12]
 675 \f
 676 RFC 2136                       DNS Update                     April 1997
 677
 678
 679    3.3.2. While the exact processing is implementation defined, if these
 680    verification activities are to be performed, this is the point in the
 681    server's processing where such performance should take place, since
 682    if a REFUSED condition is encountered after an update has been
 683    partially applied, it will be necessary to undo the partial update
 684    and restore the zone to its original state before answering the
 685    requestor.
 686
 687    3.3.3 - Pseudocode for Permission Checking
 688
 689       if (security policy exists)
 690            if (this update is not permitted)
 691                 if (local option)
 692                      log a message about permission problem
 693                 if (local option)
 694                      return (REFUSED)
 695
 696    3.4 - Process Update Section
 697
 698    Next, the Update Section is processed as follows.
 699
 700    3.4.1 - Prescan
 701
 702    The Update Section is parsed into RRs and each RR's CLASS is checked
 703    to see if it is ANY, NONE, or the same as the Zone Class, else signal
 704    a FORMERR to the requestor.  Using the definitions in Section 1.2,
 705    each RR's NAME must be in the zone specified by the Zone Section,
 706    else signal NOTZONE to the requestor.
 707
 708    3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
 709    ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
 710    unrecognized type, then signal FORMERR to the requestor.  For RRs
 711    whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
 712    else signal a FORMERR to the requestor.  For any RR whose CLASS is
 713    ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
 714    the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
 715    MAILB, or any other QUERY metatype besides ANY, or any unrecognized
 716    type, else signal FORMERR to the requestor.
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Vixie, et. al.              Standards Track                    [Page 13]
 731 \f
 732 RFC 2136                       DNS Update                     April 1997
 733
 734
 735    3.4.1.3 - Pseudocode For Update Section Prescan
 736
 737       [rr] for rr in updates
 738            if (zone_of(rr.name) != ZNAME)
 739                 return (NOTZONE);
 740            if (rr.class == zclass)
 741                 if (rr.type & ANY|AXFR|MAILA|MAILB)
 742                      return (FORMERR)
 743            elsif (rr.class == ANY)
 744                 if (rr.ttl != 0 || rr.rdlength != 0
 745                     || rr.type & AXFR|MAILA|MAILB)
 746                      return (FORMERR)
 747            elsif (rr.class == NONE)
 748                 if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
 749                      return (FORMERR)
 750            else
 751                 return (FORMERR)
 752
 753    3.4.2 - Update
 754
 755    The Update Section is parsed into RRs and these RRs are processed in
 756    order.
 757
 758    3.4.2.1. If any system failure (such as an out of memory condition,
 759    or a hardware error in persistent storage) occurs during the
 760    processing of this section, signal SERVFAIL to the requestor and undo
 761    all updates applied to the zone during this transaction.
 762
 763    3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
 764    the zone.  In case of duplicate RDATAs (which for SOA RRs is always
 765    the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
 766    fields both match), the Zone RR is replaced by Update RR.  If the
 767    TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
 768    lower (according to [RFC1982]) than or equal to the current Zone SOA
 769    RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
 770    Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
 771    Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
 772    RR.
 773
 774    3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
 775    all Zone RRs with the same NAME are deleted, unless the NAME is the
 776    same as ZNAME in which case only those RRs whose TYPE is other than
 777    SOA or NS are deleted.  For any Update RR whose CLASS is ANY and
 778    whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
 779    deleted, unless the NAME is the same as ZNAME in which case neither
 780    SOA or NS RRs will be deleted.
 781
 782
 783
 784
 785
 786 Vixie, et. al.              Standards Track                    [Page 14]
 787 \f
 788 RFC 2136                       DNS Update                     April 1997
 789
 790
 791    3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
 792    NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
 793    unless the NAME is the same as ZNAME and either the TYPE is SOA or
 794    the TYPE is NS and the matching Zone RR is the only NS remaining in
 795    the RRset, in which case this Update RR is ignored.
 796
 797    3.4.2.5. Signal NOERROR to the requestor.
 798
 799    3.4.2.6 - Table Of Metavalues Used In Update Section
 800
 801    CLASS    TYPE     RDATA    Meaning
 802    ---------------------------------------------------------
 803    ANY      ANY      empty    Delete all RRsets from a name
 804    ANY      rrset    empty    Delete an RRset
 805    NONE     rrset    rr       Delete an RR from an RRset
 806    zone     rrset    rr       Add to an RRset
 807
 808    3.4.2.7 - Pseudocode For Update Section Processing
 809
 810       [rr] for rr in updates
 811            if (rr.class == zclass)
 812                 if (rr.type == CNAME)
 813                      if (zone_rrset<rr.name, ~CNAME>)
 814                           next [rr]
 815                 elsif (zone_rrset<rr.name, CNAME>)
 816                      next [rr]
 817                 if (rr.type == SOA)
 818                      if (!zone_rrset<rr.name, SOA> ||
 819                          zone_rr<rr.name, SOA>.serial > rr.soa.serial)
 820                           next [rr]
 821                 for zrr in zone_rrset<rr.name, rr.type>
 822                      if (rr.type == CNAME || rr.type == SOA ||
 823                          (rr.type == WKS && rr.proto == zrr.proto &&
 824                           rr.address == zrr.address) ||
 825                          rr.rdata == zrr.rdata)
 826                           zrr = rr
 827                           next [rr]
 828                 zone_rrset<rr.name, rr.type> += rr
 829            elsif (rr.class == ANY)
 830                 if (rr.type == ANY)
 831                      if (rr.name == zname)
 832                           zone_rrset<rr.name, ~(SOA|NS)> = Nil
 833                      else
 834                           zone_rrset<rr.name, *> = Nil
 835                 elsif (rr.name == zname &&
 836                        (rr.type == SOA || rr.type == NS))
 837                      next [rr]
 838                 else
 839
 840
 841
 842 Vixie, et. al.              Standards Track                    [Page 15]
 843 \f
 844 RFC 2136                       DNS Update                     April 1997
 845
 846
 847                      zone_rrset<rr.name, rr.type> = Nil
 848            elsif (rr.class == NONE)
 849                 if (rr.type == SOA)
 850                      next [rr]
 851                 if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
 852                      next [rr]
 853                 zone_rr<rr.name, rr.type, rr.data> = Nil
 854       return (NOERROR)
 855
 856    3.5 - Stability
 857
 858    When a zone is modified by an UPDATE operation, the server must
 859    commit the change to nonvolatile storage before sending a response to
 860    the requestor or answering any queries or transfers for the modified
 861    zone.  It is reasonable for a server to store only the update records
 862    as long as a system reboot or power failure will cause these update
 863    records to be incorporated into the zone the next time the server is
 864    started.  It is also reasonable for the server to copy the entire
 865    modified zone to nonvolatile storage after each update operation,
 866    though this would have suboptimal performance for large zones.
 867
 868    3.6 - Zone Identity
 869
 870    If the zone's SOA SERIAL is changed by an update operation, that
 871    change must be in a positive direction (using modulo 2**32 arithmetic
 872    as specified by [RFC1982]).  Attempts to replace an SOA with one
 873    whose SERIAL is less than the current one will be silently ignored by
 874    the primary master server.
 875
 876    If the zone's SOA's SERIAL is not changed as a result of an update
 877    operation, then the server shall increment it automatically before
 878    the SOA or any changed name or RR or RRset is included in any
 879    response or transfer.  The primary master server's implementor might
 880    choose to autoincrement the SOA SERIAL if any of the following events
 881    occurs:
 882
 883    (1)  Each update operation.
 884
 885    (2)  A name, RR or RRset in the zone has changed and has subsequently
 886         been visible to a DNS client since the unincremented SOA was
 887         visible to a DNS client, and the SOA is about to become visible
 888         to a DNS client.
 889
 890    (3)  A configurable period of time has elapsed since the last update
 891         operation.  This period shall be less than or equal to one third
 892         of the zone refresh time, and the default shall be the lesser of
 893         that maximum and 300 seconds.
 894
 895
 896
 897
 898 Vixie, et. al.              Standards Track                    [Page 16]
 899 \f
 900 RFC 2136                       DNS Update                     April 1997
 901
 902
 903    (4)  A configurable number of updates has been applied since the last
 904         SOA change.  The default value for this configuration parameter
 905         shall be one hundred (100).
 906
 907    It is imperative that the zone's contents and the SOA's SERIAL be
 908    tightly synchronized.  If the zone appears to change, the SOA must
 909    appear to change as well.
 910
 911    3.7 - Atomicity
 912
 913    During the processing of an UPDATE transaction, the server must
 914    ensure atomicity with respect to other (concurrent) UPDATE or QUERY
 915    transactions.  No two transactions can be processed concurrently if
 916    either depends on the final results of the other; in particular, a
 917    QUERY should not be able to retrieve RRsets which have been partially
 918    modified by a concurrent UPDATE, and an UPDATE should not be able to
 919    start from prerequisites that might not still hold at the completion
 920    of some other concurrent UPDATE.  Finally, if two UPDATE transactions
 921    would modify the same names, RRs or RRsets, then such UPDATE
 922    transactions must be serialized.
 923
 924    3.8 - Response
 925
 926    At the end of UPDATE processing, a response code will be known.  A
 927    response message is generated by copying the ID and Opcode fields
 928    from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
 929    and ADCOUNT fields and associated sections, or placing zeros (0) in
 930    the these "count" fields and not including any part of the original
 931    update.  The QR bit is set to one (1), and the response is sent back
 932    to the requestor.  If the requestor used UDP, then the response will
 933    be sent to the requestor's source UDP port.  If the requestor used
 934    TCP, then the response will be sent back on the requestor's open TCP
 935    connection.
 936
 937 4 - Requestor Behaviour
 938
 939    4.1. From a requestor's point of view, any authoritative server for
 940    the zone can appear to be able to process update requests, even
 941    though only the primary master server is actually able to modify the
 942    zone's master file.  Requestors are expected to know the name of the
 943    zone they intend to update and to know or be able to determine the
 944    name servers for that zone.
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954 Vixie, et. al.              Standards Track                    [Page 17]
 955 \f
 956 RFC 2136                       DNS Update                     April 1997
 957
 958
 959    4.2. If update ordering is desired, the requestor will need to know
 960    the value of the existing SOA RR.  Requestors who update the SOA RR
 961    must update the SOA SERIAL field in a positive direction (as defined
 962    by [RFC1982]) and also preserve the other SOA fields unless the
 963    requestor's explicit intent is to change them.  The SOA SERIAL field
 964    must never be set to zero (0).
 965
 966    4.3. If the requestor has reasonable cause to believe that all of a
 967    zone's servers will be equally reachable, then it should arrange to
 968    try the primary master server (as given by the SOA MNAME field if
 969    matched by some NS NSDNAME) first to avoid unnecessary forwarding
 970    inside the slave servers.  (Note that the primary master will in some
 971    cases not be reachable by all requestors, due to firewalls or network
 972    partitioning.)
 973
 974    4.4. Once the zone's name servers been found and possibly sorted so
 975    that the ones more likely to be reachable and/or support the UPDATE
 976    opcode are listed first, the requestor composes an UPDATE message of
 977    the following form and sends it to the first name server on its list:
 978
 979       ID:                        (new)
 980       Opcode:                    UPDATE
 981       Zone zcount:               1
 982       Zone zname:                (zone name)
 983       Zone zclass:               (zone class)
 984       Zone ztype:                T_SOA
 985       Prerequisite Section:      (see previous text)
 986       Update Section:            (see previous text)
 987       Additional Data Section:   (empty)
 988
 989    4.5. If the requestor receives a response, and the response has an
 990    RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
 991    appropriate response to its caller.
 992
 993    4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
 994    if no response is received within an implementation dependent timeout
 995    period, or if an ICMP error is received indicating that the server's
 996    port is unreachable, then the requestor will delete the unusable
 997    server from its internal name server list and try the next one,
 998    repeating until the name server list is empty.  If the requestor runs
 999    out of servers to try, an appropriate error will be returned to the
1000    requestor's caller.
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010 Vixie, et. al.              Standards Track                    [Page 18]
1011 \f
1012 RFC 2136                       DNS Update                     April 1997
1013
1014
1015 5 - Duplicate Detection, Ordering and Mutual Exclusion
1016
1017    5.1. For correct operation, mechanisms may be needed to ensure
1018    idempotence, order UPDATE requests and provide mutual exclusion.  An
1019    UPDATE message or response might be delivered zero times, one time,
1020    or multiple times.  Datagram duplication is of particular interest
1021    since it covers the case of the so-called "replay attack" where a
1022    correct request is duplicated maliciously by an intruder.
1023
1024    5.2. Multiple UPDATE requests or responses in transit might be
1025    delivered in any order, due to network topology changes or load
1026    balancing, or to multipath forwarding graphs wherein several slave
1027    servers all forward to the primary master.  In some cases, it might
1028    be required that the earlier update not be applied after the later
1029    update, where "earlier" and "later" are defined by an external time
1030    base visible to some set of requestors, rather than by the order of
1031    request receipt at the primary master.
1032
1033    5.3. A requestor can ensure transaction idempotence by explicitly
1034    deleting some "marker RR" (rather than deleting the RRset of which it
1035    is a part) and then adding a new "marker RR" with a different RDATA
1036    field.  The Prerequisite Section should specify that the original
1037    "marker RR" must be present in order for this UPDATE message to be
1038    accepted by the server.
1039
1040    5.4. If the request is duplicated by a network error, all duplicate
1041    requests will fail since only the first will find the original
1042    "marker RR" present and having its known previous value.  The
1043    decisions of whether to use such a "marker RR" and what RR to use are
1044    left up to the application programmer, though one obvious choice is
1045    the zone's SOA RR as described below.
1046
1047    5.5. Requestors can ensure update ordering by externally
1048    synchronizing their use of successive values of the "marker RR."
1049    Mutual exclusion can be addressed as a degenerate case, in that a
1050    single succession of the "marker RR" is all that is needed.
1051
1052    5.6. A special case where update ordering and datagram duplication
1053    intersect is when an RR validly changes to some new value and then
1054    back to its previous value.  Without a "marker RR" as described
1055    above, this sequence of updates can leave the zone in an undefined
1056    state if datagrams are duplicated.
1057
1058    5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
1059    a requestor could first retrieve the SOA RR, and build an UPDATE
1060    message one of whose prerequisites was the old SOA RR.  It would then
1061    specify updates that would delete this SOA RR and add a new one with
1062    an incremented SOA SERIAL, along with whatever actual prerequisites
1063
1064
1065
1066 Vixie, et. al.              Standards Track                    [Page 19]
1067 \f
1068 RFC 2136                       DNS Update                     April 1997
1069
1070
1071    and updates were the object of the transaction.  If the transaction
1072    succeeds, the requestor knows that the RRs being changed were not
1073    otherwise altered by any other requestor.
1074
1075 6 - Forwarding
1076
1077    When a zone slave forwards an UPDATE message upward toward the zone's
1078    primary master server, it must allocate a new ID and prepare to enter
1079    the role of "forwarding server," which is a requestor with respect to
1080    the forward server.
1081
1082    6.1. The set of forward servers will be same as the set of servers
1083    this zone slave would use as the source of AXFR or IXFR data.  So,
1084    while the original requestor might have used the zone's NS RRset to
1085    locate its update server, a forwarder always forwards toward its
1086    designated zone master servers.
1087
1088    6.2. If the original requestor used TCP, then the TCP connection from
1089    the requestor is still open and the forwarder must use TCP to forward
1090    the message.  If the original requestor used UDP, the forwarder may
1091    use either UDP or TCP to forward the message, at the whim of the
1092    implementor.
1093
1094    6.3. It is reasonable for forward servers to be forwarders
1095    themselves, if the AXFR dependency graph being followed is a deep one
1096    involving firewalls and multiple connectivity realms.  In most cases
1097    the AXFR dependency graph will be shallow and the forward server will
1098    be the primary master server.
1099
1100    6.4. The forwarder will not respond to its requestor until it
1101    receives a response from its forward server.  UPDATE transactions
1102    involving forwarders are therefore time synchronized with respect to
1103    the original requestor and the primary master server.
1104
1105    6.5. When there are multiple possible sources of AXFR data and
1106    therefore multiple possible forward servers, a forwarder will use the
1107    same fallback strategy with respect to connectivity or timeout errors
1108    that it would use when performing an AXFR.  This is implementation
1109    dependent.
1110
1111    6.6. When a forwarder receives a response from a forward server, it
1112    copies this response into a new response message, assigns its
1113    requestor's ID to that message, and sends the response back to the
1114    requestor.
1115
1116
1117
1118
1119
1120
1121
1122 Vixie, et. al.              Standards Track                    [Page 20]
1123 \f
1124 RFC 2136                       DNS Update                     April 1997
1125
1126
1127 7 - Design, Implementation, Operation, and Protocol Notes
1128
1129    Some of the principles which guided the design of this UPDATE
1130    specification are as follows.  Note that these are not part of the
1131    formal specification and any disagreement between this section and
1132    any other section of this document should be resolved in favour of
1133    the other section.
1134
1135    7.1. Using metavalues for CLASS is possible only because all RRs in
1136    the packet are assumed to be in the same zone, and CLASS is an
1137    attribute of a zone rather than of an RRset.  (It is for this reason
1138    that the Zone Section is not optional.)
1139
1140    7.2. Since there are no data-present or data-absent errors possible
1141    from processing the Update Section, any necessary data-present and
1142    data- absent dependencies should be specified in the Prerequisite
1143    Section.
1144
1145    7.3. The Additional Data Section can be used to supply a server with
1146    out of zone glue that will be needed in referrals.  For example, if
1147    adding a new NS RR to HOME.VIX.COM specifying a nameserver called
1148    NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional
1149    Data Section.  Servers can use this information or ignore it, at the
1150    discretion of the implementor.  We discourage caching this
1151    information for use in subsequent DNS responses.
1152
1153    7.4. The Additional Data Section might be used if some of the RRs
1154    later needed for Secure DNS Update are not actually zone updates, but
1155    rather ancillary keys or signatures not intended to be stored in the
1156    zone (as an update would be), yet necessary for validating the update
1157    operation.
1158
1159    7.5. It is expected that in the absence of Secure DNS Update, a
1160    server will only accept updates if they come from a source address
1161    that has been statically configured in the server's description of a
1162    primary master zone.  DHCP servers would be likely candidates for
1163    inclusion in this statically configured list.
1164
1165    7.6. It is not possible to create a zone using this protocol, since
1166    there is no provision for a slave server to be told who its master
1167    servers are.  It is expected that this protocol will be extended in
1168    the future to cover this case.  Therefore, at this time, the addition
1169    of SOA RRs is unsupported.  For similar reasons, deletion of SOA RRs
1170    is also unsupported.
1171
1172
1173
1174
1175
1176
1177
1178 Vixie, et. al.              Standards Track                    [Page 21]
1179 \f
1180 RFC 2136                       DNS Update                     April 1997
1181
1182
1183    7.7. The prerequisite for specifying that a name own at least one RR
1184    differs semantically from QUERY, in that QUERY would return
1185    <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at
1186    this name, while UPDATE's prerequisite condition [Section 2.4.4]
1187    would NOT be satisfied.
1188
1189    7.8. It is possible for a UDP response to be lost in transit and for
1190    a request to be retried due to a timeout condition.  In this case an
1191    UPDATE that was successful the first time it was received by the
1192    primary master might ultimately appear to have failed when the
1193    response to a duplicate request is finally received by the requestor.
1194    (This is because the original prerequisites may no longer be
1195    satisfied after the update has been applied.)  For this reason,
1196    requestors who require an accurate response code must use TCP.
1197
1198    7.9. Because a requestor who requires an accurate response code will
1199    initiate their UPDATE transaction using TCP, a forwarder who receives
1200    a request via TCP must forward it using TCP.
1201
1202    7.10. Deferral of SOA SERIAL autoincrements is made possible so that
1203    serial numbers can be conserved and wraparound at 2**32 can be made
1204    an infrequent occurance.  Visible (to DNS clients) SOA SERIALs need
1205    to differ if the zone differs.  Note that the Authority Section SOA
1206    in a QUERY response is a form of visibility, for the purposes of this
1207    prerequisite.
1208
1209    7.11. A zone's SOA SERIAL should never be set to zero (0) due to
1210    interoperability problems with some older but widely installed
1211    implementations of DNS.  When incrementing an SOA SERIAL, if the
1212    result of the increment is zero (0) (as will be true when wrapping
1213    around 2**32), it is necessary to increment it again or set it to one
1214    (1).  See [RFC1982] for more detail on this subject.
1215
1216    7.12. Due to the TTL minimalization necessary when caching an RRset,
1217    it is recommended that all TTLs in an RRset be set to the same value.
1218    While the DNS Message Format permits variant TTLs to exist in the
1219    same RRset, and this variance can exist inside a zone, such variance
1220    will have counterintuitive results and its use is discouraged.
1221
1222    7.13. Zone cut management presents some obscure corner cases to the
1223    add and delete operations in the Update Section.  It is possible to
1224    delete an NS RR as long as it is not the last NS RR at the root of a
1225    zone.  If deleting all RRs from a name, SOA and NS RRs at the root of
1226    a zone are unaffected.  If deleting RRsets, it is not possible to
1227    delete either SOA or NS RRsets at the top of a zone.  An attempt to
1228    add an SOA will be treated as a replace operation if an SOA already
1229    exists, or as a no-op if the SOA would be new.
1230
1231
1232
1233
1234 Vixie, et. al.              Standards Track                    [Page 22]
1235 \f
1236 RFC 2136                       DNS Update                     April 1997
1237
1238
1239    7.14. No semantic checking is required in the primary master server
1240    when adding new RRs.  Therefore a requestor can cause CNAME or NS or
1241    any other kind of RR to be added even if their target name does not
1242    exist or does not have the proper RRsets to make the original RR
1243    useful.  Primary master servers that DO implement this kind of
1244    checking should take great care to avoid out-of-zone dependencies
1245    (whose veracity cannot be authoritatively checked) and should
1246    implement all such checking during the prescan phase.
1247
1248    7.15. Nonterminal or wildcard CNAMEs are not well specified by
1249    [RFC1035] and their use will probably lead to unpredictable results.
1250    Their use is discouraged.
1251
1252    7.16. Empty nonterminals (nodes with children but no RRs of their
1253    own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response
1254    to a query of any type for that name.  There is no provision for
1255    empty terminal nodes -- so if all RRs of a terminal node are deleted,
1256    the name is no longer in use, and queries of any type for that name
1257    will result in an NXDOMAIN response.
1258
1259    7.17. In a deep AXFR dependency graph, it has not historically been
1260    an error for slaves to depend mutually upon each other.  This
1261    configuration has been used to enable a zone to flow from the primary
1262    master to all slaves even though not all slaves have continuous
1263    connectivity to the primary master.  UPDATE's use of the AXFR
1264    dependency graph for forwarding prohibits this kind of dependency
1265    loop, since UPDATE forwarding has no loop detection analagous to the
1266    SOA SERIAL pretest used by AXFR.
1267
1268    7.18. Previously existing names which are occluded by a new zone cut
1269    are still considered part of the parent zone, for the purposes of
1270    zone transfers, even though queries for such names will be referred
1271    to the new subzone's servers.  If a zone cut is removed, all parent
1272    zone names that were occluded by it will again become visible to
1273    queries.  (This is a clarification of [RFC1034].)
1274
1275    7.19. If a server is authoritative for both a zone and its child,
1276    then queries for names at the zone cut between them will be answered
1277    authoritatively using only data from the child zone.  (This is a
1278    clarification of [RFC1034].)
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290 Vixie, et. al.              Standards Track                    [Page 23]
1291 \f
1292 RFC 2136                       DNS Update                     April 1997
1293
1294
1295    7.20. Update ordering using the SOA RR is problematic since there is
1296    no way to know which of a zone's NS RRs represents the primary
1297    master, and the zone slaves can be out of date if their SOA.REFRESH
1298    timers have not elapsed since the last time the zone was changed on
1299    the primary master.  We recommend that a zone needing ordered updates
1300    use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see
1301    [RFC1995]), and that a client receiving a prerequisite error while
1302    attempting an ordered update simply retry after a random delay period
1303    to allow the zone to settle.
1304
1305 8 - Security Considerations
1306
1307    8.1. In the absence of [RFC2137] or equivilent technology, the
1308    protocol described by this document makes it possible for anyone who
1309    can reach an authoritative name server to alter the contents of any
1310    zones on that server.  This is a serious increase in vulnerability
1311    from the current technology.  Therefore it is very strongly
1312    recommended that the protocols described in this document not be used
1313    without [RFC2137] or other equivalently strong security measures,
1314    e.g. IPsec.
1315
1316    8.2. A denial of service attack can be launched by flooding an update
1317    forwarder with TCP sessions containing updates that the primary
1318    master server will ultimately refuse due to permission problems.
1319    This arises due to the requirement that an update forwarder receiving
1320    a request via TCP use a synchronous TCP session for its forwarding
1321    operation.  The connection management mechanisms of [RFC1035 4.2.2]
1322    are sufficient to prevent large scale damage from such an attack, but
1323    not to prevent some queries from going unanswered during the attack.
1324
1325 Acknowledgements
1326
1327    We would like to thank the IETF DNSIND working group for their input
1328    and assistance, in particular, Rob Austein, Randy Bush, Donald
1329    Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz.  Special
1330    thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this
1331    document.
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346 Vixie, et. al.              Standards Track                    [Page 24]
1347 \f
1348 RFC 2136                       DNS Update                     April 1997
1349
1350
1351 References
1352
1353    [RFC1035]
1354       Mockapetris, P., "Domain Names - Implementation and
1355       Specification", STD 13, RFC 1035, USC/Information Sciences
1356       Institute, November 1987.
1357
1358    [RFC1982]
1359       Elz, R., "Serial Number Arithmetic", RFC 1982, University of
1360       Melbourne, August 1996.
1361
1362    [RFC1995]
1363       Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute
1364       of Technology, August 1996.
1365
1366    [RFC1996]
1367       Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
1368       RFC 1996, Internet Software Consortium, August 1996.
1369
1370    [RFC2065]
1371       Eastlake, D., and C. Kaufman, "Domain Name System Protocol
1372       Security Extensions", RFC 2065, January 1997.
1373
1374    [RFC2137]
1375       Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
1376       2137, April 1997.
1377
1378 Authors' Addresses
1379
1380    Yakov Rekhter
1381    Cisco Systems
1382    170 West Tasman Drive
1383    San Jose, CA 95134-1706
1384
1385    Phone: +1 914 528 0090
1386    EMail: yakov@cisco.com
1387
1388
1389    Susan Thomson
1390    Bellcore
1391    445 South Street
1392    Morristown, NJ 07960
1393
1394    Phone: +1 201 829 4514
1395    EMail: set@thumper.bellcore.com
1396
1397
1398
1399
1400
1401
1402 Vixie, et. al.              Standards Track                    [Page 25]
1403 \f
1404 RFC 2136                       DNS Update                     April 1997
1405
1406
1407    Jim Bound
1408    Digital Equipment Corp.
1409    110 Spitbrook Rd ZK3-3/U14
1410    Nashua, NH 03062-2698
1411
1412    Phone: +1 603 881 0400
1413    EMail: bound@zk3.dec.com
1414
1415
1416    Paul Vixie
1417    Internet Software Consortium
1418    Star Route Box 159A
1419    Woodside, CA 94062
1420
1421    Phone: +1 415 747 0204
1422    EMail: paul@vix.com
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458 Vixie, et. al.              Standards Track                    [Page 26]
1459 \f
1460