idnits 2.17.00 (12 Aug 2021) /tmp/idnits40967/draft-ietf-dnsind-dynDNS-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnsind-dynDNS-10', contains other characters than digits, lowercase letters and dash. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 269 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 60 has weird spacing: '... Master maste...' == Line 481 has weird spacing: '... rrset emp...' == Line 483 has weird spacing: '... rrset emp...' == Line 484 has weird spacing: '... rrset rr ...' == Line 626 has weird spacing: '... rrset emp...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1996) is 9311 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1035' on line 1063 looks like a reference -- Missing reference section? 'RFC1996' on line 1075 looks like a reference -- Missing reference section? 'RFC1982' on line 1067 looks like a reference -- Missing reference section? 'RFC1034' on line 1025 looks like a reference -- Missing reference section? 'RFC1995' on line 1071 looks like a reference -- Missing reference section? 'SECUPD' on line 1084 looks like a reference -- Missing reference section? 'DNSSEC' on line 1079 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSIND Working Group Paul Vixie (Ed.) (ISC) 3 INTERNET-DRAFT Susan Thomson (Bellcore) 4 Yakov Rekhter (Cisco) 5 Jim Bound (DEC) 6 Amends: RFC 1035 November 1996 8 Dynamic Updates in the Domain Name System (DNS UPDATE) 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 The Domain Name System was originally designed to support queries of 31 a statically configured database. While the data was expected to 32 change, the frequency of those changes was expected to be fairly low, 33 and all updates were made as external edits to a zone's Master File. 35 Using this specification of the UPDATE opcode, it is possible to add 36 or delete RRs or RRsets from a specified zone. Prerequisites are 37 specified separately from update operations, and can specify a 38 dependency upon either the previous existence or nonexistence of an 39 RRset, or the existence of a single RR. 41 UPDATE is atomic, i.e., all prerequisites must be satisfied or else 42 no update operations will take place. There are no data dependent 43 error conditions defined after the prerequisites have been met. 45 1 - Definitions 47 This document intentionally gives more definition to the roles of 48 ``Master,'' ``Slave,'' and ``Primary Master'' servers, and their 49 enumeration in NS RRs, and the SOA MNAME field. In that sense, the 50 following server type definitions can be considered an addendum to 51 [RFC1035], and are intended to be consistent with [RFC1996]: 53 Slave an authoritative server that uses AXFR or IXFR to 54 retrieve the zone and is named in the zone's NS 55 RRset. 57 Master an authoritative server configured to be the source 58 of AXFR or IXFR data for one or more slave servers. 60 Primary Master master server at the root of the AXFR/IXFR dependency 61 graph. The primary master is named in the zone's SOA 62 MNAME field and optionally by an NS RR. There is by 63 definition only one primary master server per zone. 65 A domain name identifies a node within the domain name space tree 66 structure. Each node has a set (possibly empty) of Resource Records 67 (RRs). All RRs having the same NAME, CLASS and TYPE are called a 68 Resource Record Set (RRset). 70 The pseudocode used in this document is for example purposes only. If 71 it is found to disagree with the text, the text shall be considered 72 authoritative. If the text is found to be ambiguous, the pseudocode can 73 be used to help resolve the ambiguity. 75 1.1 - Comparison Rules 77 1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE, RDLENGTH 78 and RDATA fields are equal. Note that the time-to-live (TTL) field is 79 explicitly excluded from the comparison. 81 1.1.2. The rules for comparison of character strings in names are 82 specified in [RFC1035 2.3.3]. 84 1.1.3. Wildcarding is disabled. That is, a wildcard (``*'') in an 85 update only matches a wildcard (``*'') in the zone, and vice versa. 87 1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in the 88 update, and will not otherwise be followed. All UPDATE operations are 89 done on the basis of canonical names. 91 1.1.5. The following RR types cannot be appended to an RRset. If the 92 following comparison rules are met, then an attempt to add the new RR 93 will result in the replacement of the previous RR: 95 SOA compare only NAME, CLASS and TYPE -- it is not possible to 96 have more than one SOA per zone, even if any of the data 97 fields differ. 99 WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL -- only 100 one WKS RR is possible for this tuple, even if the services 101 masks differ. 103 CNAME compare only NAME, CLASS, and TYPE -- it is not possible to 104 have more than one CNAME RR, even if their data fields differ. 106 1.2 - Glue RRs 108 For the purpose of determining whether a domain name used in the UPDATE 109 protocol is contained within a specified zone, a domain name is ``in'' a 110 zone if it is owned by that zone's domain name. See section 7.18 for 111 details. 113 1.3 - New Assigned Numbers 115 CLASS = NONE (TBD: 254) 116 RCODE = YXDOMAIN (TBD: 6) 117 RCODE = YXRRSET (TBD: 7) 118 RCODE = NXRRSET (TBD: 8) 119 RCODE = NOTAUTH (TBD: 9) 120 RCODE = NOTZONE (TBD: 10?) 121 Opcode = UPDATE (5) 123 2 - Update Message Format 125 The DNS Message Format is defined by [RFC1035 4.1]. Some extensions are 126 necessary (for example, more error codes are possible under UPDATE than 127 under QUERY) and some fields must be overloaded (see description of 128 CLASS fields below). 130 The overall format of an UPDATE message is, following [ibid]: 132 +---------------------+ 133 | Header | 134 +---------------------+ 135 | Zone | specifies the zone to be updated 136 +---------------------+ 137 | Prerequisite | RRs or RRsets which must (not) preexist 138 +---------------------+ 139 | Update | RRs or RRsets to be added or deleted 140 +---------------------+ 141 | Additional Data | additional data 142 +---------------------+ 144 The Header Section specifies that this message is an UPDATE, and 145 describes the size of the other sections. The Zone Section names the 146 zone that is to be updated by this message. The Prerequisite Section 147 specifies the starting invariants (in terms of zone content) required 148 for this update. The Update Section contains the edits to be made, and 149 the Additional Data Section contains data which may be necessary to 150 complete, but is not part of, this update. 152 2.1 - Transport Issues 154 An update transaction may be carried in a UDP datagram, if the request 155 fits, or in a TCP connection (at the discretion of the requestor). When 156 TCP is used, the message is in the format described in [RFC1035 4.2.2]. 158 2.2 - Message Header 160 The header of the DNS Message Format is defined by [RFC 1035 4.1]. Not 161 all opcodes define the same set of flag bits, though as a practical 162 matter most of the bits defined for QUERY (in [ibid]) are identically 163 defined by the other opcodes. UPDATE uses only one flag bit (QR). 165 The DNS Message Format specifies record counts for its four sections 166 (Question, Answer, Authority, and Additional). UPDATE uses the same 167 fields, and the same section formats, but the naming and use of these 168 sections differs as shown in the following modified header, after 169 [RFC1035 4.1.1]: 171 1 1 1 1 1 1 172 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 173 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 174 | ID | 175 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 176 |QR| Opcode | Z | RCODE | 177 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 178 | ZOCOUNT | 179 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 180 | PRCOUNT | 181 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 182 | UPCOUNT | 183 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 184 | ADCOUNT | 185 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 187 These fields are used as follows: 189 ID A 16-bit identifier assigned by the entity that generates any 190 kind of request. This identifier is copied in the 191 corresponding reply and can be used by the requestor to match 192 replies to outstanding requests, or by the server to detect 193 duplicated requests from some requestor. 195 QR A one bit field that specifies whether this message is a 196 request (0), or a response (1). 198 Opcode A four bit field that specifies the kind of request in this 199 message. This value is set by the originator of a request 200 and copied into the response. The Opcode value that 201 identifies an UPDATE message is five (5). 203 Z Reserved for future use. Should be zero (0) in all requests 204 and responses. A non-zero Z field should be ignored by 205 implementations of this specification. 207 RCODE Response code - this four bit field is undefined in requests 208 and set in responses. The values and meanings of this field 209 within responses are as follows: 211 Mneumonic Value Description 212 ------------------------------------------------------------ 213 NOERROR 0 No error condition. 214 FORMERR 1 The name server was unable to interpret 215 the request due to a format error. 216 SERVFAIL 2 The name server encountered an internal 217 failure while processing this request, 218 for example an operating system error 219 or a forwarding timeout. 220 NXDOMAIN 3 Some name that ought to exist, 221 does not exist. 222 NOTIMP 4 The name server does not support 223 the specified Opcode. 224 REFUSED 5 The name server refuses to perform the 225 specified operation for policy or 226 security reasons. 227 YXDOMAIN 6? Some name that ought not to exist, 228 does exist. 229 YXRRSET 7? Some RRset that ought not to exist, 230 does exist. 231 NXRRSET 8? Some RRset that ought to exist, 232 does not exist. 233 NOTAUTH 9? The server is not authoritative for 234 the zone named in the Zone Section. 235 NOTZONE 10? A name used in the Prerequisite or 236 Update Section is not within the 237 zone denoted by the Zone Section. 239 ZOCOUNT The number of RRs in the Zone Section. 241 PRCOUNT The number of RRs in the Prerequisite Section. 243 UPCOUNT The number of RRs in the Update Section. 245 ADCOUNT The number of RRs in the Additional Data Section. 247 2.3 - Zone Section 249 The Zone Section has the same format as that specified in [RFC1035 250 4.1.2], with the fields redefined as follows: 252 1 1 1 1 1 1 253 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 254 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 255 | | 256 / ZNAME / 257 / / 258 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 259 | ZTYPE | 260 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 261 | ZCLASS | 262 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 264 UPDATE uses this section to denote the zone of the records being 265 updated. All records to be updated must be in the same zone, and 266 therefore the Zone Section is allowed to contain exactly one record. 267 The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is the 268 zone's class. 270 2.4 - Prerequisite Section 272 This section contains a set of RRset prerequisites which must be 273 satisfied at the time the UPDATE packet is received by the primary 274 master server. The format of this section is as specified by [RFC1035 275 4.1.3]. There are five possible sets of semantics that can be expressed 276 here, summarized as follows and then explained below. 278 (1) RRset exists (value independent). At least one RR with a 279 specified NAME and TYPE (in the zone and class specified by the 280 Zone Section) must exist. 282 (2) RRset exists (value dependent). A set of RRs with a specified 283 NAME and TYPE exists and has the same members with the same 284 RDATAs as the RRset specified here in this Section. 286 (3) RRset does not exist. No RRs with a specified NAME and TYPE (in 287 the zone and class denoted by the Zone Section) can exist. 289 (4) Name is in use. At least one RR with a specified NAME (in the 290 zone and class specified by the Zone Section) must exist. Note 291 that this prerequisite is NOT satisfied by empty nonterminals. 293 (5) Name is not in use. No RR of any type is owned by a specified 294 NAME. Note that this prerequisite IS satisfied by empty 295 nonterminals. 297 The syntax of these is as follows: 299 2.4.1 - RRset Exists (Value Independent) 301 At least one RR with a specified NAME and TYPE (in the zone and class 302 specified in the Zone Section) must exist. 304 For this prerequisite, a requestor adds to the section a single RR whose 305 NAME and TYPE are equal to that of the zone RRset whose existence is 306 required. RDLENGTH is zero and RDATA is therefore empty. CLASS must be 307 specified as ANY to differentiate this condition from that of an actual 308 RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TTL is specified 309 as zero (0). 311 2.4.2 - RRset Exists (Value Dependent) 313 A set of RRs with a specified NAME and TYPE exists and has the same 314 members with the same RDATAs as the RRset specified here in this 315 section. While RRset ordering is undefined and therefore not 316 significant to this comparison, the sets be identical in their extent. 318 For this prerequisite, a requestor adds to the section an entire RRset 319 whose preexistence is required. NAME and TYPE are that of the RRset 320 being denoted. CLASS is that of the zone. TTL must be specified as 321 zero (0) and is ignored when comparing RRsets for identity. 323 2.4.3 - RRset Does Not Exist 325 No RRs with a specified NAME and TYPE (in the zone and class denoted by 326 the Zone Section) can exist. 328 For this prerequisite, a requestor adds to the section a single RR whose 329 NAME and TYPE are equal to that of the RRset whose nonexistence is 330 required. The RDLENGTH of this record is zero (0), and RDATA field is 331 therefore empty. CLASS must be specified as NONE in order to 332 distinguish this condition from a valid RR whose RDLENGTH is naturally 333 zero (0) (for example, the NULL RR). TTL must be specified as zero (0). 335 2.4.4 - Name Is In Use 337 Name is in use. At least one RR with a specified NAME (in the zone and 338 class specified by the Zone Section) must exist. Note that this 339 prerequisite is NOT satisfied by empty nonterminals. 341 For this prerequisite, a requestor adds to the section a single RR whose 342 NAME is equal to that of the name whose ownership of an RR is required. 343 RDLENGTH is zero and RDATA is therefore empty. CLASS must be specified 344 as ANY to differentiate this condition from that of an actual RR whose 345 RDLENGTH is naturally zero (0) (e.g., NULL). TYPE must be specified as 346 ANY to differentiate this case from that of an RRset existence test. 347 TTL is specified as zero (0). 349 2.4.5 - Name Is Not In Use 351 Name is not in use. No RR of any type is owned by a specified NAME. 352 Note that this prerequisite IS satisfied by empty nonterminals. 354 For this prerequisite, a requestor adds to the section a single RR whose 355 NAME is equal to that of the name whose nonownership of any RRs is 356 required. RDLENGTH is zero and RDATA is therefore empty. CLASS must be 357 specified as NONE. TYPE must be specified as ANY. TTL must be 358 specified as zero (0). 360 2.5 - Update Section 362 This section contains RRs to be added to or deleted from the zone. The 363 format of this section is as specified by [RFC1035 4.1.3]. There are 364 four possible sets of semantics, summarized below and with details to 365 follow. 367 (1) Add RRs to an RRset. 368 (2) Delete an RRset. 369 (3) Delete all RRsets from a name. 370 (4) Delete an RR from an RRset. 372 The syntax of these is as follows: 374 2.5.1 - Add To An RRset 376 RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH and 377 RDATA are those being added, and CLASS is the same as the zone class. 378 Any duplicate RRs will be silently ignored by the primary master. 380 2.5.2 - Delete An RRset 382 One RR is added to the Update Section whose NAME and TYPE are those of 383 the RRset to be deleted. TTL must be specified as zero (0) and is 384 otherwise not used by the primary master. CLASS must be specified as 385 ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty. If 386 no such RRset exists, then this Update RR will be silently ignored by 387 the primary master. 389 2.5.3 - Delete All RRsets From A Name 391 One RR is added to the Update Section whose NAME is that of the name to 392 be cleansed of RRsets. TYPE must be specified as ANY. TTL must be 393 specified as zero (0) and is otherwise not used by the primary master. 394 CLASS must be specified as ANY. RDLENGTH must be zero (0) and RDATA 395 must therefore be empty. If no such RRsets exist, then this Update RR 396 will be silently ignored by the primary master. 398 2.5.4 - Delete An RR From An RRset 400 RRs to be deleted are added to the Update Section. The NAME, TYPE, 401 RDLENGTH and RDATA must match the RR being deleted. TTL must be 402 specified as zero (0) and will otherwise be ignored by the primary 403 master. CLASS must be specified as NONE to distinguish this from an RR 404 addition. If no such RRs exist, then this Update RR will be silently 405 ignored by the primary master. 407 2.6 - Additional Data Section 409 This section contains RRs which are related to the update itself, or to 410 new RRs being added by the update. For example, out of zone glue (A RRs 411 referred to by new NS RRs) should be presented here. The server can use 412 or ignore out of zone glue, at the discretion of the server implementor. 413 The format of this section is as specified by [RFC1035 4.1.3]. 415 3 - Server Behavior 417 A server, upon receiving an UPDATE request, will signal NOTIMP to the 418 requestor if the UPDATE opcode is not recognized or if it is recognized 419 but has not been implemented. Otherwise, processing continues as 420 follows. 422 3.1 - Process Zone Section 424 3.1.1. The Zone Section is checked to see that there is exactly one RR 425 therein and that the RR's ZTYPE is SOA, else signal FORMERR to the 426 requestor. Next, the ZNAME and ZCLASS are checked to see if the zone so 427 named is one of this server's authority zones, else signal NOTAUTH to 428 the requestor. If the server is a zone slave, the request will be 429 forwarded toward the primary master. 431 3.1.2 - Pseudocode For Zone Section Processing 433 if (zcount != 1 || ztype != SOA) 434 return (FORMERR) 435 if (zone_type(zname, zclass) == SLAVE) 436 return forward() 437 if (zone_type(zname, zclass) == MASTER) 438 return update() 439 return (NOTAUTH) 441 Sections 3.2 through 3.8 describe the primary master's behaviour, 442 whereas Section 6 describes a forwarder's behaviour. 444 3.2 - Process Prerequisite Section 446 Next, the Prerequisite Section is checked to see that all prerequisites 447 are satisfied by the current state of the zone. Using the definitions 448 expressed in Section 1.2, if any RR's NAME is not within the zone 449 specified in the Zone Section, signal NOTZONE to the requestor. 451 3.2.1. For RRs in this section whose CLASS is ANY, test to see that TTL 452 and RDLENGTH are both zero (0), else signal FORMERR to the requestor. 453 If TYPE is ANY, test to see that there is at least one RR in the zone 454 whose NAME is the same as that of the Prerequisite RR, else signal 455 NXDOMAIN to the requestor. If TYPE is not ANY, test to see that there 456 is at least one RR in the zone whose NAME and TYPE are the same as that 457 of the Prerequisite RR, else signal NXRRSET to the requestor. 459 3.2.2. For RRs in this section whose CLASS is NONE, test to see that the 460 TTL and RDLENGTH are both zero (0), else signal FORMERR to the 461 requestor. If the TYPE is ANY, test to see that there are no RRs in the 462 zone whose NAME is the same as that of the Prerequisite RR, else signal 463 YXDOMAIN to the requestor. If the TYPE is not ANY, test to see that 464 there are no RRs in the zone whose NAME and TYPE are the same as that of 465 the Prerequisite RR, else signal YXRRSET to the requestor. 467 3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS, 468 test to see that the TTL is zero (0), else signal FORMERR to the 469 requestor. Then, build an RRset for each unique and compare 470 each resulting RRset for set equality (same members, no more, no less) 471 with RRsets in the zone. If any Prerequisite RRset is not entirely and 472 exactly matched by a zone RRset, signal NXRRSET to the requestor. If 473 any RR in this section has a CLASS other than ZCLASS or NONE or ANY, 474 signal FORMERR to the requestor. 476 3.2.4 - Table Of Metavalues Used In Prerequisite Section 478 CLASS TYPE RDATA Meaning 479 ------------------------------------------------------------ 480 ANY ANY empty Name is in use 481 ANY rrset empty RRset exists (value independent) 482 NONE ANY empty Name is not in use 483 NONE rrset empty RRset does not exist 484 zone rrset rr RRset exists (value dependent) 485 3.2.5 - Pseudocode for Prerequisite Section Processing 487 for rr in prerequisites 488 if (rr.ttl != 0) 489 return (FORMERR) 490 if (zone_of(rr.name) != ZNAME) 491 return (NOTZONE); 492 if (rr.class == ANY) 493 if (rr.rdlength != 0) 494 return (FORMERR) 495 if (rr.type == ANY) 496 if (!zone_name) 497 return (NXDOMAIN) 498 else 499 if (!zone_rrset) 500 return (NXRRSET) 501 if (rr.class == NONE) 502 if (rr.rdlength != 0) 503 return (FORMERR) 504 if (rr.type == ANY) 505 if (zone_name) 506 return (YXDOMAIN) 507 else 508 if (zone_rrset) 509 return (YXRRSET) 510 if (rr.class == zclass) 511 temp += rr 512 else 513 return (FORMERR) 515 for rrset in temp 516 if (zone_rrset != rrset) 517 return (NXRRSET) 519 3.3 - Check Requestor's Permissions 521 3.3.1. Next, the requestor's permission to update the RRs named in the 522 Update Section may be tested in an implementation dependent fashion or 523 using mechanisms specified in a subsequent Secure DNS Update protocol. 524 If the requestor does not have permission to perform these updates, the 525 server may write a warning message in its operations log, and may either 526 signal REFUSED to the requestor, or ignore the permission problem and 527 proceed with the update. 529 3.3.2. While the exact processing is implementation defined, if these 530 verification activities are to be performed, this is the point in the 531 server's processing where such performance should take place, since if a 532 REFUSED condition is encountered after an update has been partially 533 applied, it will be necessary to undo the partial update and restore the 534 zone to its original state before answering the requestor. 536 3.3.3 - Pseudocode for Permission Checking 538 if (security policy exists) 539 if (this update is not permitted) 540 if (local option) 541 log a message about permission problem 542 if (local option) 543 return (REFUSED) 545 3.4 - Process Update Section 547 Next, the Update Section is processed as follows. 549 3.4.1 - Prescan 551 The Update Section is parsed into RRs and each RR's CLASS is checked to 552 see if it is ANY, NONE, or the same as the Zone Class, else signal a 553 FORMERR to the requestor. Using the definitions in Section 1.2, each 554 RR's NAME must be in the zone specified by the Zone Section, else signal 555 NOTZONE to the requestor. 557 3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is 558 ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any 559 unrecognized type, then signal FORMERR to the requestor. For RRs whose 560 CLASS is ANY or NONE, check the TTL to see that it is zero (0), else 561 signal a FORMERR to the requestor. For any RR whose CLASS is ANY, check 562 the RDLENGTH to make sure that it is zero (0) (that is, the RDATA field 563 is empty), and that the TYPE is not AXFR, MAILA, MAILB, or any other 564 QUERY metatype besides ANY, or any unrecognized type, else signal 565 FORMERR to the requestor. 567 3.4.1.3 - Pseudocode For Update Section Prescan 569 [rr] for rr in updates 570 if (zone_of(rr.name) != ZNAME) 571 return (NOTZONE); 572 if (rr.class == zclass) 573 if (rr.type & ANY|AXFR|MAILA|MAILB) 574 return (FORMERR) 575 elsif (rr.class == ANY) 576 if (rr.ttl != 0 || rr.rdlength != 0 577 || rr.type & AXFR|MAILA|MAILB) 578 return (FORMERR) 579 elsif (rr.class == NONE) 580 if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB) 581 return (FORMERR) 582 else 583 return (FORMERR) 585 3.4.2 - Update 587 The Update Section is parsed into RRs and these RRs are processed in 588 order. 590 3.4.2.1. If any system failure (such as an out of memory condition, or a 591 hardware error in persistent storage) occurs during the processing of 592 this section, signal SERVFAIL to the requestor and undo all updates 593 applied to the zone during this transaction. 595 3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to the 596 zone. In case of duplicate RDATAs (which for SOA RRs is always the 597 case, and for WKS RRs is the case if the ADDRESS and PROTOCOL fields 598 both match), the Zone RR is replaced by Update RR. If the TYPE is SOA 599 and there is no Zone SOA RR, or the new SOA.SERIAL is lower (according 600 to [RFC1982]) than or equal to the current Zone SOA RR's SOA.SERIAL, the 601 Update RR is ignored. In the case of a CNAME Update RR and a non-CNAME 602 Zone RRset or vice versa, ignore the CNAME Update RR, otherwise replace 603 the CNAME Zone RR with the CNAME Update RR. 605 3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY, all 606 Zone RRs with the same NAME are deleted, unless the NAME is the same as 607 ZNAME in which case only those RRs whose TYPE is other than SOA or NS 608 are deleted. For any Update RR whose CLASS is ANY and whose TYPE is not 609 ANY all Zone RRs with the same NAME and TYPE are deleted, unless the 610 NAME is the same as ZNAME in which case neither SOA or NS RRs will be 611 deleted. 613 3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose NAME, 614 TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted, unless 615 the NAME is the same as ZNAME and either the TYPE is SOA or the TYPE is 616 NS and the matching Zone RR is the only NS remaining in the RRset, in 617 which case this Update RR is ignored. 619 3.4.2.5. Signal NOERROR to the requestor. 621 3.4.2.6 - Table Of Metavalues Used In Update Section 623 CLASS TYPE RDATA Meaning 624 --------------------------------------------------------- 625 ANY ANY empty Delete all RRsets from a name 626 ANY rrset empty Delete an RRset 627 NONE rrset rr Delete an RR from an RRset 628 zone rrset rr Add to an RRset 629 3.4.2.7 - Pseudocode For Update Section Processing 631 [rr] for rr in updates 632 if (rr.class == zclass) 633 if (rr.type == CNAME) 634 if (zone_rrset) 635 next [rr] 636 elsif (zone_rrset) 637 next [rr] 638 if (rr.type == SOA) 639 if (!zone_rrset || 640 zone_rr.serial > rr.soa.serial) 641 next [rr] 642 for zrr in zone_rrset 643 if (rr.type == CNAME || rr.type == SOA || 644 (rr.type == WKS && rr.proto == zrr.proto && 645 rr.address == zrr.address) || 646 rr.rdata == zrr.rdata) 647 zrr = rr 648 next [rr] 649 zone_rrset += rr 650 elsif (rr.class == ANY) 651 if (rr.type == ANY) 652 if (rr.name == zname) 653 zone_rrset = Nil 654 else 655 zone_rrset = Nil 656 elsif (rr.name == zname && 657 (rr.type == SOA || rr.type == NS)) 658 next [rr] 659 else 660 zone_rrset = Nil 661 elsif (rr.class == NONE) 662 if (rr.type == SOA) 663 next [rr] 664 if (rr.type == NS && zone_rrset == rr) 665 next [rr] 666 zone_rr = Nil 667 return (NOERROR) 669 3.5 - Stability 671 When a zone is modified by an UPDATE operation, the server must commit 672 the change to nonvolatile storage before sending a response to the 673 requestor or answering any queries or transfers for the modified zone. 674 It is reasonable for a server to store only the update records as long 675 as a system reboot or power failure will cause these update records to 676 be incorporated into the zone the next time the server is started. It 677 is also reasonable for the server to copy the entire modified zone to 678 nonvolatile storage after each update operation, though this would have 679 suboptimal performance for large zones. 681 3.6 - Zone Identity 683 If the zone's SOA SERIAL is changed by an update operation, that change 684 must be in a positive direction (using modulo 2**32 arithmetic as 685 specified by [RFC1982]). Attempts to replace an SOA with one whose 686 SERIAL is less than the current one will be silently ignored by the 687 primary master server. 689 If the zone's SOA's SERIAL is not changed as a result of an update 690 operation, then the server shall increment it automatically before the 691 SOA or any changed name or RR or RRset is included in any response or 692 transfer. The primary master server's implementor might choose to 693 autoincrement the SOA SERIAL if any of the following events occurs: 695 (1) Each update operation. 697 (2) A name, RR or RRset in the zone has changed and has subsequently 698 been visible to a DNS client since the unincremented SOA was 699 visible to a DNS client, and the SOA is about to become visible to 700 a DNS client. 702 (3) A configurable period of time has elapsed since the last update 703 operation. This period shall be less than or equal to one third of 704 the zone refresh time, and the default shall be the lesser of that 705 maximum and 300 seconds. 707 (4) A configurable number of updates has been applied since the last 708 SOA change. The default value for this configuration parameter 709 shall be one hundred (100). 711 It is imperative that the zone's contents and the SOA's SERIAL be 712 tightly synchronized. If the zone appears to change, the SOA must 713 appear to change as well. 715 3.7 - Atomicity 717 During the processing of an UPDATE transaction, the server must ensure 718 atomicity with respect to other (concurrent) UPDATE or QUERY 719 transactions. No two transactions can be processed concurrently if 720 either depends on the final results of the other; in particular, a QUERY 721 should not be able to retrieve RRsets which have been partially modified 722 by a concurrent UPDATE, and an UPDATE should not be able to start from 723 prerequisites that might not still hold at the completion of some other 724 concurrent UPDATE. Finally, if two UPDATE transactions would modify the 725 same names, RRs or RRsets, then such UPDATE transactions must be 726 serialized. 728 3.8 - Response 730 At the end of UPDATE processing, a response code will be known. A 731 response message is generated by copying the ID and Opcode fields from 732 the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT, and 733 ADCOUNT fields and associated sections, or placing zeros (0) in the 734 these ``count'' fields and not including any part of the original 735 update. The QR bit is set to one (1), and the response is sent back to 736 the requestor. If the requestor used UDP, then the response will be 737 sent to the requestor's source UDP port. If the requestor used TCP, 738 then the response will be sent back on the requestor's open TCP 739 connection. 741 4 - Requestor Behaviour 743 4.1. From a requestor's point of view, any authoritative server for the 744 zone can appear to be able to process update requests, even though only 745 the primary master server is actually able to modify the zone's master 746 file. Requestors are expected to know the name of the zone they intend 747 to update and to know or be able to determine the name servers for that 748 zone. 750 4.2. If update ordering is desired, the requestor will need to know the 751 value of the existing SOA RR. Requestors who update the SOA RR must 752 update the SOA SERIAL field in a positive direction (as defined by 753 [RFC1982]) and also preserve the other SOA fields unless the requestor's 754 explicit intent is to change them. The SOA SERIAL field must never be 755 set to zero (0). 757 4.3. If the requestor has reasonable cause to believe that all of a 758 zone's servers will be equally reachable, then it should arrange to try 759 the primary master server (as given by the SOA MNAME field if matched by 760 some NS NSDNAME) first to avoid unnecessary forwarding inside the slave 761 servers. (Note that the primary master will in some cases not be 762 reachable by all requestors, due to firewalls or network partitioning.) 764 4.4. Once the zone's name servers been found and possibly sorted so that 765 the ones more likely to be reachable and/or support the UPDATE opcode 766 are listed first, the requestor composes an UPDATE message of the 767 following form and sends it to the first name server on its list: 769 ID: (new) 770 Opcode: UPDATE 771 Zone zcount: 1 772 Zone zname: (zone name) 773 Zone zclass: (zone class) 774 Zone ztype: T_SOA 775 Prerequisite Section: (see previous text) 776 Update Section: (see previous text) 777 Additional Data Section: (empty) 779 4.5. If the requestor receives a response, and the response has an RCODE 780 other than SERVFAIL or NOTIMP, then the requestor returns an appropriate 781 response to its caller. 783 4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or if 784 no response is received within an implementation dependent timeout 785 period, or if an ICMP error is received indicating that the server's 786 port is unreachable, then the requestor will delete the unusable server 787 from its internal name server list and try the next one, repeating until 788 the name server list is empty. If the requestor runs out of servers to 789 try, an appropriate error will be returned to the requestor's caller. 791 5 - Duplicate Detection, Ordering and Mutual Exclusion 793 5.1. For correct operation, mechanisms may be needed to ensure 794 idempotence, order UPDATE requests and provide mutual exclusion. An 795 UPDATE message or response might be delivered zero times, one time, or 796 multiple times. Datagram duplication is of particular interest since it 797 covers the case of the so-called ``replay attack'' where a correct 798 request is duplicated maliciously by an intruder. 800 5.2. Multiple UPDATE requests or responses in transit might be delivered 801 in any order, due to network topology changes or load balancing, or to 802 multipath forwarding graphs wherein several slave servers all forward to 803 the primary master. In some cases, it might be required that the 804 earlier update not be applied after the later update, where ``earlier'' 805 and ``later'' are defined by an external time base visible to some set 806 of requestors, rather than by the order of request receipt at the 807 primary master. 809 5.3. A requestor can ensure transaction idempotence by explicitly 810 deleting some ``marker RR'' (rather than deleting the RRset of which it 811 is a part) and then adding a new ``marker RR'' with a different RDATA 812 field. The Prerequisite Section should specify that the original 813 ``marker RR'' must be present in order for this UPDATE message to be 814 accepted by the server. 816 5.4. If the request is duplicated by a network error, all duplicate 817 requests will fail since only the first will find the original ``marker 818 RR'' present and having its known previous value. The decisions of 819 whether to use such a ``marker RR'' and what RR to use are left up to 820 the application programmer, though one obvious choice is the zone's SOA 821 RR as described below. 823 5.5. Requestors can ensure update ordering by externally synchronizing 824 their use of successive values of the ``marker RR.'' Mutual exclusion 825 can be addressed as a degenerate case, in that a single succession of 826 the ``marker RR'' is all that is needed. 828 5.6. A special case where update ordering and datagram duplication 829 intersect is when an RR validly changes to some new value and then back 830 to its previous value. Without a ``marker RR'' as described above, this 831 sequence of updates can leave the zone in an undefined state if 832 datagrams are duplicated. 834 5.7. To achieve an atomic multitransaction ``read-modify-write'' cycle, 835 a requestor could first retrieve the SOA RR, and build an UPDATE message 836 one of whose prerequisites was the old SOA RR. It would then specify 837 updates that would delete this SOA RR and add a new one with an 838 incremented SOA SERIAL, along with whatever actual prerequisites and 839 updates were the object of the transaction. If the transaction 840 succeeds, the requestor knows that the RRs being changed were not 841 otherwise altered by any other requestor. 843 6 - Forwarding 845 When a zone slave forwards an UPDATE message upward toward the zone's 846 primary master server, it must allocate a new ID and prepare to enter 847 the role of ``forwarding server,'' which is a requestor with respect to 848 the forward server. 850 6.1. The set of forward servers will be same as the set of servers this 851 zone slave would use as the source of AXFR or IXFR data. So, while the 852 original requestor might have used the zone's NS RRset to locate its 853 update server, a forwarder always forwards toward its designated zone 854 master servers. 856 6.2. If the original requestor used TCP, then the TCP connection from 857 the requestor is still open and the forwarder must use TCP to forward 858 the message. If the original requestor used UDP, the forwarder may use 859 either UDP or TCP to forward the message, at the whim of the 860 implementor. 862 6.3. It is reasonable for forward servers to be forwarders themselves, 863 if the AXFR dependency graph being followed is a deep one involving 864 firewalls and multiple connectivity realms. In most cases the AXFR 865 dependency graph will be shallow and the forward server will be the 866 primary master server. 868 6.4. The forwarder will not respond to its requestor until it receives a 869 response from its forward server. UPDATE transactions involving 870 forwarders are therefore time synchronized with respect to the original 871 requestor and the primary master server. 873 6.5. When there are multiple possible sources of AXFR data and therefore 874 multiple possible forward servers, a forwarder will use the same 875 fallback strategy with respect to connectivity or timeout errors that it 876 would use when performing an AXFR. This is implementation dependent. 878 6.6. When a forwarder receives a response from a forward server, it 879 copies this response into a new response message, assigns its 880 requestor's ID to that message, and sends the response back to the 881 requestor. 883 7 - Design, Implementation, Operation, and Protocol Notes 885 Some of the principles which guided the design of this UPDATE 886 specification are as follows. Note that these are not part of the 887 formal specification and any disagreement between this section and any 888 other section of this document should be resolved in favour of the other 889 section. 891 7.1. Using metavalues for CLASS is possible only because all RRs in the 892 packet are assumed to be in the same zone, and CLASS is an attribute of 893 a zone rather than of an RRset. (It is for this reason that the Zone 894 Section is not optional.) 896 7.2. Since there are no data-present or data-absent errors possible from 897 processing the Update Section, any necessary data-present and data- 898 absent dependencies should be specified in the Prerequisite Section. 900 7.3. The Additional Data Section can be used to supply a server with out 901 of zone glue that will be needed in referrals. For example, if adding a 902 new NS RR to HOME.VIX.COM specifying a nameserver called NS.AU.OZ, the A 903 RR for NS.AU.OZ can be included in the Additional Data Section. Servers 904 can use this information or ignore it, at the discretion of the 905 implementor. We discourage caching this information for use in 906 subsequent DNS responses. 908 7.4. The Additional Data Section might be used if some of the RRs later 909 needed for Secure DNS Update are not actually zone updates, but rather 910 ancillary keys or signatures not intended to be stored in the zone (as 911 an update would be), yet necessary for validating the update operation. 913 7.5. It is expected that in the absence of Secure DNS Update, a server 914 will only accept updates if they come from a source address that has 915 been statically configured in the server's description of a primary 916 master zone. DHCP servers would be likely candidates for inclusion in 917 this statically configured list. 919 7.6. It is not possible to create a zone using this protocol, since 920 there is no provision for a slave server to be told who its master 921 servers are. It is expected that this protocol will be extended in the 922 future to cover this case. Therefore, at this time, the addition of SOA 923 RRs is unsupported. For similar reasons, deletion of SOA RRs is also 924 unsupported. 926 7.7. The prerequisite for specifying that a name own at least one RR 927 differs semantically from QUERY, in that QUERY would return 928 rather than NXDOMAIN if queried for an RRset at this 929 name, while UPDATE's prerequisite condition [Section 2.4.4] would NOT be 930 satisfied. 932 7.8. It is possible for a UDP response to be lost in transit and for a 933 request to be retried due to a timeout condition. In this case an 934 UPDATE that was successful the first time it was received by the primary 935 master might ultimately appear to have failed when the response to a 936 duplicate request is finally received by the requestor. (This is 937 because the original prerequisites may no longer be satisfied after the 938 update has been applied.) For this reason, requestors who require an 939 accurate response code must use TCP. 941 7.9. Because a requestor who requires an accurate response code will 942 initiate their UPDATE transaction using TCP, a forwarder who receives a 943 request via TCP must forward it using TCP. 945 7.10. Deferral of SOA SERIAL autoincrements is made possible so that 946 serial numbers can be conserved and wraparound at 2**32 can be made an 947 infrequent occurance. Visible (to DNS clients) SOA SERIALs need to 948 differ if the zone differs. Note that the Authority Section SOA in a 949 QUERY response is a form of visibility, for the purposes of this 950 prerequisite. 952 7.11. A zone's SOA SERIAL should never be set to zero (0) due to 953 interoperability problems with some older but widely installed 954 implementations of DNS. When incrementing an SOA SERIAL, if the result 955 of the increment is zero (0) (as will be true when wrapping around 956 2**32), it is necessary to increment it again or set it to one (1). See 957 [RFC1982] for more detail on this subject. 959 7.12. Due to the TTL minimalization necessary when caching an RRset, it 960 is recommended that all TTLs in an RRset be set to the same value. 961 While the DNS Message Format permits variant TTLs to exist in the same 962 RRset, and this variance can exist inside a zone, such variance will 963 have counterintuitive results and its use is discouraged. 965 7.13. Zone cut management presents some obscure corner cases to the add 966 and delete operations in the Update Section. It is possible to delete 967 an NS RR as long as it is not the last NS RR at the root of a zone. If 968 deleting all RRs from a name, SOA and NS RRs at the root of a zone are 969 unaffected. If deleting RRsets, it is not possible to delete either SOA 970 or NS RRsets at the top of a zone. An attempt to add an SOA will be 971 treated as a replace operation. 973 7.14. No semantic checking is required in the primary master server when 974 adding new RRs. Therefore a requestor can cause CNAME or NS or any 975 other kind of RR to be added even if their target name does not exist or 976 does not have the proper RRsets to make the original RR useful. Primary 977 master servers that DO implement this kind of checking should take great 978 care to avoid out-of-zone dependencies (whose veracity cannot be 979 authoritatively checked) and should implement all such checking during 980 the prescan phase. 982 7.15. Nonterminal or wildcard CNAMEs are not well specified by [RFC1035] 983 and their use will probably lead to unpredictable results. Their use is 984 discouraged. 986 7.16. Empty nonterminals (nodes with children but no RRs of their own) 987 will cause responses to be sent in response to a 988 query of any type for that name. There is no provision for empty 989 terminal nodes -- so if all RRs of a terminal node are deleted, the name 990 is no longer in use, and queries of any type for that name will result 991 in an NXDOMAIN response. 993 7.17. In a deep AXFR dependency graph, it has not historically been an 994 error for slaves to depend mutually upon each other. This configuration 995 has been used to enable a zone to flow from the primary master to all 996 slaves even though not all slaves have continuous connectivity to the 997 primary master. UPDATE's use of the AXFR dependency graph for 998 forwarding prohibits this kind of dependency loop, since UPDATE 999 forwarding has no loop detection analagous to the SOA SERIAL pretest 1000 used by AXFR. 1002 7.18. For UPDATE's purposes, a zone is said to own all names at or below 1003 the zone's root. This allows an UPDATE message to add or delete names 1004 below a zone cut so as to create and maintain ``glue'' records needed 1005 for delegation when a name server is within the zone being delegated, 1006 even though a query for this data would result in a referral response. 1008 7.19. Previously existing names which are occluded by a new zone cut are 1009 still considered part of the parent zone, for the purposes of zone 1010 transfers, even though queries for such names will be referred to the 1011 new subzone's servers. If a zone cut is removed, all parent zone names 1012 that were occluded by it will again become visible to queries. (This is 1013 a clarification of [RFC1034].) 1015 7.20. If a node contains any name server delegations (NS RRs), this node 1016 is said to be owned by the child zone, and the parent will answer only 1017 with a referral to the child zone's servers if queried for a name at or 1018 below the child zone's root, except in the case of a QTYPE=NS query at 1019 the zone cut itself, for which the parent zone's servers would answer 1020 authoritatively. (This is a clarification of [RFC1034].) 1022 7.21. If a server is authoritative for both a zone and its child, then 1023 queries for names at the zone cut between them will be answered 1024 authoritatively using only data from the child zone. (This is a 1025 clarification of [RFC1034].) 1027 7.22. Update ordering using the SOA RR is problematic since there is no 1028 way to know which of a zone's NS RRs represents the primary master, and 1029 the zone slaves can be out of date if their SOA.REFRESH timers have not 1030 elapsed since the last time the zone was changed on the primary master. 1031 We recommend that a zone needing ordered updates use only servers which 1032 implement NOTIFY (see [RFC1996]) and IXFR (see [RFC1995]), and that a 1033 client receiving a prerequisite error while attempting an ordered update 1034 simply retry after a random delay period to allow the zone to settle. 1036 8 - Security Considerations 8.1. In the absence of [SECUPD] or 1037 equivilent technology, the protocol described by this document makes it 1038 possible for anyone who can reach an authoritative name server to alter 1039 the contents of any zones on that server. This is a serious increase in 1040 vulnerability from the current technology. Therefore it is very 1041 strongly recommended that the protocols described in this document not 1042 be used without [SECUPD] or other equivalently strong security measures, 1043 e.g. IPsec. 1045 8.2. A denial of service attack can be launched by flooding an update 1046 forwarder with TCP sessions containing updates that the primary master 1047 server will ultimately refuse due to permission problems. This arises 1048 due to the requirement that an update forwarder receiving a request via 1049 TCP use a synchronous TCP session for its forwarding operation. The 1050 connection management mechanisms of [RFC1035 4.2.2] are sufficient to 1051 prevent large scale damage from such an attack, but not to prevent some 1052 queries from going unanswered during the attack. 1054 Acknowledgements 1056 We would like to thank the IETF DNSIND working group for their input and 1057 assistance, in particular, Rob Austein, Randy Bush, Donald Eastlake, 1058 Masataka Ohta, Mark Andrews, and Robert Elz. Special thanks to Bill 1059 Simpson, Ken Wallich and Bob Halley for reviewing this document. 1061 References 1063 [RFC1035] 1064 P. Mockapetris, ``Domain Names - Implementation and Specification,'' 1065 RFC 1035, USC/Information Sciences Institute, November 1987. 1067 [RFC1982] 1068 R. Elz, ``Serial Number Arithmetic,'' RFC 1982, University of 1069 Melbourne, August 1996. 1071 [RFC1995] 1072 M. Ohta, ``Incremental Zone Transfer,'' RFC 1995, Tokyo Institute of 1073 Technology, August 1996. 1075 [RFC1996] 1076 P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes,'' 1077 RFC 1996, Internet Software Consortium, August 1996. 1079 [DNSSEC] 1080 Donald E. Eastlake and Charles W. Kaufman, ``Domain Name System 1081 Protocol Security Extensions,'' Internet Draft, August 1996, . 1084 [SECUPD] 1085 Donald E. Eastlake, ``Secure Domain Name System Dynamic Update,'' 1086 Internet Draft, March 1997, 1088 Authors' Addresses 1090 Yakov Rekhter Susan Thomson 1091 Cisco Systems Bellcore 1092 170 West Tasman Drive 445 South Street 1093 San Jose, CA 95134-1706 Morristown, NJ 07960 1094 +1 914 528 0090 +1 201 829 4514 1095 1097 Jim Bound Paul Vixie 1098 Digital Equipment Corp. Internet Software Consortium 1099 110 Spitbrook Rd ZK3-3/U14 Star Route Box 159A 1100 Nashua, NH 03062-2698 Woodside, CA 94062 1101 +1 603 881 0400 +1 415 747 0204 1102