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