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