diff options
Diffstat (limited to 'doc/rfc/rfc2136.txt')
| -rw-r--r-- | doc/rfc/rfc2136.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc2136.txt b/doc/rfc/rfc2136.txt new file mode 100644 index 0000000..c0ed36b --- /dev/null +++ b/doc/rfc/rfc2136.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group P. Vixie, Editor +Request for Comments: 2136 ISC +Updates: 1035 S. Thomson +Category: Standards Track Bellcore + Y. Rekhter + Cisco + J. Bound + DEC + April 1997 + + Dynamic Updates in the Domain Name System (DNS UPDATE) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Domain Name System was originally designed to support queries of + a statically configured database. While the data was expected to + change, the frequency of those changes was expected to be fairly low, + and all updates were made as external edits to a zone's Master File. + + Using this specification of the UPDATE opcode, it is possible to add + or delete RRs or RRsets from a specified zone. Prerequisites are + specified separately from update operations, and can specify a + dependency upon either the previous existence or nonexistence of an + RRset, or the existence of a single RR. + + UPDATE is atomic, i.e., all prerequisites must be satisfied or else + no update operations will take place. There are no data dependent + error conditions defined after the prerequisites have been met. + +1 - Definitions + + This document intentionally gives more definition to the roles of + "Master," "Slave," and "Primary Master" servers, and their + enumeration in NS RRs, and the SOA MNAME field. In that sense, the + following server type definitions can be considered an addendum to + [RFC1035], and are intended to be consistent with [RFC1996]: + + Slave an authoritative server that uses AXFR or IXFR to + retrieve the zone and is named in the zone's NS + RRset. + + + +Vixie, et. al. Standards Track [Page 1] + +RFC 2136 DNS Update April 1997 + + + Master an authoritative server configured to be the + source of AXFR or IXFR data for one or more slave + servers. + + Primary Master master server at the root of the AXFR/IXFR + dependency graph. The primary master is named in + the zone's SOA MNAME field and optionally by an NS + RR. There is by definition only one primary master + server per zone. + + A domain name identifies a node within the domain name space tree + structure. Each node has a set (possibly empty) of Resource Records + (RRs). All RRs having the same NAME, CLASS and TYPE are called a + Resource Record Set (RRset). + + The pseudocode used in this document is for example purposes only. + If it is found to disagree with the text, the text shall be + considered authoritative. If the text is found to be ambiguous, the + pseudocode can be used to help resolve the ambiguity. + + 1.1 - Comparison Rules + + 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.2. The rules for comparison of character strings in names are + specified in [RFC1035 2.3.3]. + + 1.1.3. Wildcarding is disabled. That is, a wildcard ("*") in an + update only matches a wildcard ("*") in the zone, and vice versa. + + 1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in + the update, and will not otherwise be followed. All UPDATE + operations are done on the basis of canonical names. + + 1.1.5. The following RR types cannot be appended to an RRset. If the + following comparison rules are met, then an attempt to add the new RR + will result in the replacement of the previous RR: + + SOA compare only NAME, CLASS and TYPE -- it is not possible to + have more than one SOA per zone, even if any of the data + fields differ. + + WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL + -- only one WKS RR is possible for this tuple, even if the + services masks differ. + + + + +Vixie, et. al. Standards Track [Page 2] + +RFC 2136 DNS Update April 1997 + + + CNAME compare only NAME, CLASS, and TYPE -- it is not possible + to have more than one CNAME RR, even if their data fields + differ. + + 1.2 - Glue RRs + + For the purpose of determining whether a domain name used in the + UPDATE protocol is contained within a specified zone, a domain name + is "in" a zone if it is owned by that zone's domain name. See + section 7.18 for details. + + 1.3 - New Assigned Numbers + + CLASS = NONE (254) + RCODE = YXDOMAIN (6) + RCODE = YXRRSET (7) + RCODE = NXRRSET (8) + RCODE = NOTAUTH (9) + RCODE = NOTZONE (10) + Opcode = UPDATE (5) + +2 - Update Message Format + + The DNS Message Format is defined by [RFC1035 4.1]. Some extensions + are necessary (for example, more error codes are possible under + UPDATE than under QUERY) and some fields must be overloaded (see + description of CLASS fields below). + + The overall format of an UPDATE message is, following [ibid]: + + +---------------------+ + | Header | + +---------------------+ + | Zone | specifies the zone to be updated + +---------------------+ + | Prerequisite | RRs or RRsets which must (not) preexist + +---------------------+ + | Update | RRs or RRsets to be added or deleted + +---------------------+ + | Additional Data | additional data + +---------------------+ + + + + + + + + + + +Vixie, et. al. Standards Track [Page 3] + +RFC 2136 DNS Update April 1997 + + + The Header Section specifies that this message is an UPDATE, and + describes the size of the other sections. The Zone Section names the + zone that is to be updated by this message. The Prerequisite Section + specifies the starting invariants (in terms of zone content) required + for this update. The Update Section contains the edits to be made, + and the Additional Data Section contains data which may be necessary + to complete, but is not part of, this update. + + 2.1 - Transport Issues + + An update transaction may be carried in a UDP datagram, if the + request fits, or in a TCP connection (at the discretion of the + requestor). When TCP is used, the message is in the format described + in [RFC1035 4.2.2]. + + 2.2 - Message Header + + The header of the DNS Message Format is defined by [RFC 1035 4.1]. + Not all opcodes define the same set of flag bits, though as a + practical matter most of the bits defined for QUERY (in [ibid]) are + identically defined by the other opcodes. UPDATE uses only one flag + bit (QR). + + The DNS Message Format specifies record counts for its four sections + (Question, Answer, Authority, and Additional). UPDATE uses the same + fields, and the same section formats, but the naming and use of these + sections differs as shown in the following modified header, after + [RFC1035 4.1.1]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode | Z | RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ZOCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | PRCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | UPCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ADCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + + + + + + +Vixie, et. al. Standards Track [Page 4] + +RFC 2136 DNS Update April 1997 + + + These fields are used as follows: + + ID A 16-bit identifier assigned by the entity that generates any + kind of request. This identifier is copied in the + corresponding reply and can be used by the requestor to match + replies to outstanding requests, or by the server to detect + duplicated requests from some requestor. + + QR A one bit field that specifies whether this message is a + request (0), or a response (1). + + Opcode A four bit field that specifies the kind of request in this + message. This value is set by the originator of a request + and copied into the response. The Opcode value that + identifies an UPDATE message is five (5). + + Z Reserved for future use. Should be zero (0) in all requests + and responses. A non-zero Z field should be ignored by + implementations of this specification. + + RCODE Response code - this four bit field is undefined in requests + and set in responses. The values and meanings of this field + within responses are as follows: + + Mneumonic Value Description + ------------------------------------------------------------ + NOERROR 0 No error condition. + FORMERR 1 The name server was unable to interpret + the request due to a format error. + SERVFAIL 2 The name server encountered an internal + failure while processing this request, + for example an operating system error + or a forwarding timeout. + NXDOMAIN 3 Some name that ought to exist, + does not exist. + NOTIMP 4 The name server does not support + the specified Opcode. + REFUSED 5 The name server refuses to perform the + specified operation for policy or + security reasons. + YXDOMAIN 6 Some name that ought not to exist, + does exist. + YXRRSET 7 Some RRset that ought not to exist, + does exist. + NXRRSET 8 Some RRset that ought to exist, + does not exist. + + + + + +Vixie, et. al. Standards Track [Page 5] + +RFC 2136 DNS Update April 1997 + + + NOTAUTH 9 The server is not authoritative for + the zone named in the Zone Section. + NOTZONE 10 A name used in the Prerequisite or + Update Section is not within the + zone denoted by the Zone Section. + + ZOCOUNT The number of RRs in the Zone Section. + + PRCOUNT The number of RRs in the Prerequisite Section. + + UPCOUNT The number of RRs in the Update Section. + + ADCOUNT The number of RRs in the Additional Data Section. + + 2.3 - Zone Section + + The Zone Section has the same format as that specified in [RFC1035 + 4.1.2], with the fields redefined as follows: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / ZNAME / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ZTYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ZCLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + UPDATE uses this section to denote the zone of the records being + updated. All records to be updated must be in the same zone, and + therefore the Zone Section is allowed to contain exactly one record. + The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is + the zone's class. + + 2.4 - Prerequisite Section + + This section contains a set of RRset prerequisites which must be + satisfied at the time the UPDATE packet is received by the primary + master server. The format of this section is as specified by + [RFC1035 4.1.3]. There are five possible sets of semantics that can + be expressed here, summarized as follows and then explained below. + + (1) RRset exists (value independent). At least one RR with a + specified NAME and TYPE (in the zone and class specified by + the Zone Section) must exist. + + + +Vixie, et. al. Standards Track [Page 6] + +RFC 2136 DNS Update April 1997 + + + (2) RRset exists (value dependent). A set of RRs with a + specified NAME and TYPE exists and has the same members + with the same RDATAs as the RRset specified here in this + Section. + + (3) RRset does not exist. No RRs with a specified NAME and TYPE + (in the zone and class denoted by the Zone Section) can exist. + + (4) Name is in use. At least one RR with a specified NAME (in + the zone and class specified by the Zone Section) must exist. + Note that this prerequisite is NOT satisfied by empty + nonterminals. + + (5) Name is not in use. No RR of any type is owned by a + specified NAME. Note that this prerequisite IS satisfied by + empty nonterminals. + + The syntax of these is as follows: + + 2.4.1 - RRset Exists (Value Independent) + + At least one RR with a specified NAME and TYPE (in the zone and class + specified in the Zone Section) must exist. + + For this prerequisite, a requestor adds to the section a single RR + whose NAME and TYPE are equal to that of the zone RRset whose + existence is required. RDLENGTH is zero and RDATA is therefore + empty. CLASS must be specified as ANY to differentiate this + condition from that of an actual RR whose RDLENGTH is naturally zero + (0) (e.g., NULL). TTL is specified as zero (0). + + 2.4.2 - RRset Exists (Value Dependent) + + A set of RRs with a specified NAME and TYPE exists and has the same + members with the same RDATAs as the RRset specified here in this + section. While RRset ordering is undefined and therefore not + significant to this comparison, the sets be identical in their + extent. + + For this prerequisite, a requestor adds to the section an entire + RRset whose preexistence is required. NAME and TYPE are that of the + RRset being denoted. CLASS is that of the zone. TTL must be + specified as zero (0) and is ignored when comparing RRsets for + identity. + + + + + + + +Vixie, et. al. Standards Track [Page 7] + +RFC 2136 DNS Update April 1997 + + + 2.4.3 - RRset Does Not Exist + + No RRs with a specified NAME and TYPE (in the zone and class denoted + by the Zone Section) can exist. + + For this prerequisite, a requestor adds to the section a single RR + whose NAME and TYPE are equal to that of the RRset whose nonexistence + is required. The RDLENGTH of this record is zero (0), and RDATA + field is therefore empty. CLASS must be specified as NONE in order + to distinguish this condition from a valid RR whose RDLENGTH is + naturally zero (0) (for example, the NULL RR). TTL must be specified + as zero (0). + + 2.4.4 - Name Is In Use + + Name is in use. At least one RR with a specified NAME (in the zone + and class specified by the Zone Section) must exist. Note that this + prerequisite is NOT satisfied by empty nonterminals. + + For this prerequisite, a requestor adds to the section a single RR + whose NAME is equal to that of the name whose ownership of an RR is + required. RDLENGTH is zero and RDATA is therefore empty. CLASS must + be specified as ANY to differentiate this condition from that of an + actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TYPE + must be specified as ANY to differentiate this case from that of an + RRset existence test. TTL is specified as zero (0). + + 2.4.5 - Name Is Not In Use + + Name is not in use. No RR of any type is owned by a specified NAME. + Note that this prerequisite IS satisfied by empty nonterminals. + + For this prerequisite, a requestor adds to the section a single RR + whose NAME is equal to that of the name whose nonownership of any RRs + is required. RDLENGTH is zero and RDATA is therefore empty. CLASS + must be specified as NONE. TYPE must be specified as ANY. TTL must + be specified as zero (0). + + 2.5 - Update Section + + This section contains RRs to be added to or deleted from the zone. + The format of this section is as specified by [RFC1035 4.1.3]. There + are four possible sets of semantics, summarized below and with + details to follow. + + + + + + + +Vixie, et. al. Standards Track [Page 8] + +RFC 2136 DNS Update April 1997 + + + (1) Add RRs to an RRset. + (2) Delete an RRset. + (3) Delete all RRsets from a name. + (4) Delete an RR from an RRset. + + The syntax of these is as follows: + + 2.5.1 - Add To An RRset + + RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH + and RDATA are those being added, and CLASS is the same as the zone + class. Any duplicate RRs will be silently ignored by the primary + master. + + 2.5.2 - Delete An RRset + + One RR is added to the Update Section whose NAME and TYPE are those + of the RRset to be deleted. TTL must be specified as zero (0) and is + otherwise not used by the primary master. CLASS must be specified as + ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty. + If no such RRset exists, then this Update RR will be silently ignored + by the primary master. + + 2.5.3 - Delete All RRsets From A Name + + One RR is added to the Update Section whose NAME is that of the name + to be cleansed of RRsets. TYPE must be specified as ANY. TTL must + be specified as zero (0) and is otherwise not used by the primary + master. CLASS must be specified as ANY. RDLENGTH must be zero (0) + and RDATA must therefore be empty. If no such RRsets exist, then + this Update RR will be silently ignored by the primary master. + + 2.5.4 - Delete An RR From An RRset + + RRs to be deleted are added to the Update Section. The NAME, TYPE, + RDLENGTH and RDATA must match the RR being deleted. TTL must be + specified as zero (0) and will otherwise be ignored by the primary + master. CLASS must be specified as NONE to distinguish this from an + RR addition. If no such RRs exist, then this Update RR will be + silently ignored by the primary master. + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 9] + +RFC 2136 DNS Update April 1997 + + + 2.6 - Additional Data Section + + This section contains RRs which are related to the update itself, or + to new RRs being added by the update. For example, out of zone glue + (A RRs referred to by new NS RRs) should be presented here. The + server can use or ignore out of zone glue, at the discretion of the + server implementor. The format of this section is as specified by + [RFC1035 4.1.3]. + +3 - Server Behavior + + A server, upon receiving an UPDATE request, will signal NOTIMP to the + requestor if the UPDATE opcode is not recognized or if it is + recognized but has not been implemented. Otherwise, processing + continues as follows. + + 3.1 - Process Zone Section + + 3.1.1. The Zone Section is checked to see that there is exactly one + RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the + requestor. Next, the ZNAME and ZCLASS are checked to see if the zone + so named is one of this server's authority zones, else signal NOTAUTH + to the requestor. If the server is a zone slave, the request will be + forwarded toward the primary master. + + 3.1.2 - Pseudocode For Zone Section Processing + + if (zcount != 1 || ztype != SOA) + return (FORMERR) + if (zone_type(zname, zclass) == SLAVE) + return forward() + if (zone_type(zname, zclass) == MASTER) + return update() + return (NOTAUTH) + + Sections 3.2 through 3.8 describe the primary master's behaviour, + whereas Section 6 describes a forwarder's behaviour. + + 3.2 - Process Prerequisite Section + + Next, the Prerequisite Section is checked to see that all + prerequisites are satisfied by the current state of the zone. Using + the definitions expressed in Section 1.2, if any RR's NAME is not + within the zone specified in the Zone Section, signal NOTZONE to the + requestor. + + + + + + +Vixie, et. al. Standards Track [Page 10] + +RFC 2136 DNS Update April 1997 + + + 3.2.1. For RRs in this section whose CLASS is ANY, test to see that + TTL and RDLENGTH are both zero (0), else signal FORMERR to the + requestor. If TYPE is ANY, test to see that there is at least one RR + in the zone whose NAME is the same as that of the Prerequisite RR, + else signal NXDOMAIN to the requestor. If TYPE is not ANY, test to + see that there is at least one RR in the zone whose NAME and TYPE are + the same as that of the Prerequisite RR, else signal NXRRSET to the + requestor. + + 3.2.2. For RRs in this section whose CLASS is NONE, test to see that + the TTL and RDLENGTH are both zero (0), else signal FORMERR to the + requestor. If the TYPE is ANY, test to see that there are no RRs in + the zone whose NAME is the same as that of the Prerequisite RR, else + signal YXDOMAIN to the requestor. If the TYPE is not ANY, test to + see that there are no RRs in the zone whose NAME and TYPE are the + same as that of the Prerequisite RR, else signal YXRRSET to the + requestor. + + 3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS, + test to see that the TTL is zero (0), else signal FORMERR to the + requestor. Then, build an RRset for each unique <NAME,TYPE> and + compare each resulting RRset for set equality (same members, no more, + no less) with RRsets in the zone. If any Prerequisite RRset is not + entirely and exactly matched by a zone RRset, signal NXRRSET to the + requestor. If any RR in this section has a CLASS other than ZCLASS + or NONE or ANY, signal FORMERR to the requestor. + + 3.2.4 - Table Of Metavalues Used In Prerequisite Section + + CLASS TYPE RDATA Meaning + ------------------------------------------------------------ + ANY ANY empty Name is in use + ANY rrset empty RRset exists (value independent) + NONE ANY empty Name is not in use + NONE rrset empty RRset does not exist + zone rrset rr RRset exists (value dependent) + + + + + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 11] + +RFC 2136 DNS Update April 1997 + + + 3.2.5 - Pseudocode for Prerequisite Section Processing + + for rr in prerequisites + if (rr.ttl != 0) + return (FORMERR) + if (zone_of(rr.name) != ZNAME) + return (NOTZONE); + if (rr.class == ANY) + if (rr.rdlength != 0) + return (FORMERR) + if (rr.type == ANY) + if (!zone_name<rr.name>) + return (NXDOMAIN) + else + if (!zone_rrset<rr.name, rr.type>) + return (NXRRSET) + if (rr.class == NONE) + if (rr.rdlength != 0) + return (FORMERR) + if (rr.type == ANY) + if (zone_name<rr.name>) + return (YXDOMAIN) + else + if (zone_rrset<rr.name, rr.type>) + return (YXRRSET) + if (rr.class == zclass) + temp<rr.name, rr.type> += rr + else + return (FORMERR) + + for rrset in temp + if (zone_rrset<rrset.name, rrset.type> != rrset) + return (NXRRSET) + + 3.3 - Check Requestor's Permissions + + 3.3.1. Next, the requestor's permission to update the RRs named in + the Update Section may be tested in an implementation dependent + fashion or using mechanisms specified in a subsequent Secure DNS + Update protocol. If the requestor does not have permission to + perform these updates, the server may write a warning message in its + operations log, and may either signal REFUSED to the requestor, or + ignore the permission problem and proceed with the update. + + + + + + + + +Vixie, et. al. Standards Track [Page 12] + +RFC 2136 DNS Update April 1997 + + + 3.3.2. While the exact processing is implementation defined, if these + verification activities are to be performed, this is the point in the + server's processing where such performance should take place, since + if a REFUSED condition is encountered after an update has been + partially applied, it will be necessary to undo the partial update + and restore the zone to its original state before answering the + requestor. + + 3.3.3 - Pseudocode for Permission Checking + + if (security policy exists) + if (this update is not permitted) + if (local option) + log a message about permission problem + if (local option) + return (REFUSED) + + 3.4 - Process Update Section + + Next, the Update Section is processed as follows. + + 3.4.1 - Prescan + + The Update Section is parsed into RRs and each RR's CLASS is checked + to see if it is ANY, NONE, or the same as the Zone Class, else signal + a FORMERR to the requestor. Using the definitions in Section 1.2, + each RR's NAME must be in the zone specified by the Zone Section, + else signal NOTZONE to the requestor. + + 3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is + ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any + unrecognized type, then signal FORMERR to the requestor. For RRs + whose CLASS is ANY or NONE, check the TTL to see that it is zero (0), + else signal a FORMERR to the requestor. For any RR whose CLASS is + ANY, check the RDLENGTH to make sure that it is zero (0) (that is, + the RDATA field is empty), and that the TYPE is not AXFR, MAILA, + MAILB, or any other QUERY metatype besides ANY, or any unrecognized + type, else signal FORMERR to the requestor. + + + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 13] + +RFC 2136 DNS Update April 1997 + + + 3.4.1.3 - Pseudocode For Update Section Prescan + + [rr] for rr in updates + if (zone_of(rr.name) != ZNAME) + return (NOTZONE); + if (rr.class == zclass) + if (rr.type & ANY|AXFR|MAILA|MAILB) + return (FORMERR) + elsif (rr.class == ANY) + if (rr.ttl != 0 || rr.rdlength != 0 + || rr.type & AXFR|MAILA|MAILB) + return (FORMERR) + elsif (rr.class == NONE) + if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB) + return (FORMERR) + else + return (FORMERR) + + 3.4.2 - Update + + The Update Section is parsed into RRs and these RRs are processed in + order. + + 3.4.2.1. If any system failure (such as an out of memory condition, + or a hardware error in persistent storage) occurs during the + processing of this section, signal SERVFAIL to the requestor and undo + all updates applied to the zone during this transaction. + + 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.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY, + all Zone RRs with the same NAME are deleted, unless the NAME is the + same as ZNAME in which case only those RRs whose TYPE is other than + SOA or NS are deleted. For any Update RR whose CLASS is ANY and + whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are + deleted, unless the NAME is the same as ZNAME in which case neither + SOA or NS RRs will be deleted. + + + + + +Vixie, et. al. Standards Track [Page 14] + +RFC 2136 DNS Update April 1997 + + + 3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose + NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted, + unless the NAME is the same as ZNAME and either the TYPE is SOA or + the TYPE is NS and the matching Zone RR is the only NS remaining in + the RRset, in which case this Update RR is ignored. + + 3.4.2.5. Signal NOERROR to the requestor. + + 3.4.2.6 - Table Of Metavalues Used In Update Section + + CLASS TYPE RDATA Meaning + --------------------------------------------------------- + ANY ANY empty Delete all RRsets from a name + ANY rrset empty Delete an RRset + NONE rrset rr Delete an RR from an RRset + zone rrset rr Add to an RRset + + 3.4.2.7 - Pseudocode For Update Section Processing + + [rr] for rr in updates + if (rr.class == zclass) + if (rr.type == CNAME) + if (zone_rrset<rr.name, ~CNAME>) + next [rr] + elsif (zone_rrset<rr.name, CNAME>) + next [rr] + if (rr.type == SOA) + if (!zone_rrset<rr.name, SOA> || + zone_rr<rr.name, SOA>.serial > rr.soa.serial) + next [rr] + for zrr in zone_rrset<rr.name, rr.type> + if (rr.type == CNAME || rr.type == SOA || + (rr.type == WKS && rr.proto == zrr.proto && + rr.address == zrr.address) || + rr.rdata == zrr.rdata) + zrr = rr + next [rr] + zone_rrset<rr.name, rr.type> += rr + elsif (rr.class == ANY) + if (rr.type == ANY) + if (rr.name == zname) + zone_rrset<rr.name, ~(SOA|NS)> = Nil + else + zone_rrset<rr.name, *> = Nil + elsif (rr.name == zname && + (rr.type == SOA || rr.type == NS)) + next [rr] + else + + + +Vixie, et. al. Standards Track [Page 15] + +RFC 2136 DNS Update April 1997 + + + zone_rrset<rr.name, rr.type> = Nil + elsif (rr.class == NONE) + if (rr.type == SOA) + next [rr] + if (rr.type == NS && zone_rrset<rr.name, NS> == rr) + next [rr] + zone_rr<rr.name, rr.type, rr.data> = Nil + return (NOERROR) + + 3.5 - Stability + + When a zone is modified by an UPDATE operation, the server must + commit the change to nonvolatile storage before sending a response to + the requestor or answering any queries or transfers for the modified + zone. It is reasonable for a server to store only the update records + as long as a system reboot or power failure will cause these update + records to be incorporated into the zone the next time the server is + started. It is also reasonable for the server to copy the entire + modified zone to nonvolatile storage after each update operation, + though this would have suboptimal performance for large zones. + + 3.6 - Zone Identity + + If the zone's SOA SERIAL is changed by an update operation, that + change must be in a positive direction (using modulo 2**32 arithmetic + as specified by [RFC1982]). Attempts to replace an SOA with one + whose SERIAL is less than the current one will be silently ignored by + the primary master server. + + If the zone's SOA's SERIAL is not changed as a result of an update + operation, then the server shall increment it automatically before + the SOA or any changed name or RR or RRset is included in any + response or transfer. The primary master server's implementor might + choose to autoincrement the SOA SERIAL if any of the following events + occurs: + + (1) Each update operation. + + (2) A name, RR or RRset in the zone has changed and has subsequently + been visible to a DNS client since the unincremented SOA was + visible to a DNS client, and the SOA is about to become visible + to a DNS client. + + (3) A configurable period of time has elapsed since the last update + operation. This period shall be less than or equal to one third + of the zone refresh time, and the default shall be the lesser of + that maximum and 300 seconds. + + + + +Vixie, et. al. Standards Track [Page 16] + +RFC 2136 DNS Update April 1997 + + + (4) A configurable number of updates has been applied since the last + SOA change. The default value for this configuration parameter + shall be one hundred (100). + + It is imperative that the zone's contents and the SOA's SERIAL be + tightly synchronized. If the zone appears to change, the SOA must + appear to change as well. + + 3.7 - Atomicity + + During the processing of an UPDATE transaction, the server must + ensure atomicity with respect to other (concurrent) UPDATE or QUERY + transactions. No two transactions can be processed concurrently if + either depends on the final results of the other; in particular, a + QUERY should not be able to retrieve RRsets which have been partially + modified by a concurrent UPDATE, and an UPDATE should not be able to + start from prerequisites that might not still hold at the completion + of some other concurrent UPDATE. Finally, if two UPDATE transactions + would modify the same names, RRs or RRsets, then such UPDATE + transactions must be serialized. + + 3.8 - Response + + At the end of UPDATE processing, a response code will be known. A + response message is generated by copying the ID and Opcode fields + from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT, + and ADCOUNT fields and associated sections, or placing zeros (0) in + the these "count" fields and not including any part of the original + update. The QR bit is set to one (1), and the response is sent back + to the requestor. If the requestor used UDP, then the response will + be sent to the requestor's source UDP port. If the requestor used + TCP, then the response will be sent back on the requestor's open TCP + connection. + +4 - Requestor Behaviour + + 4.1. From a requestor's point of view, any authoritative server for + the zone can appear to be able to process update requests, even + though only the primary master server is actually able to modify the + zone's master file. Requestors are expected to know the name of the + zone they intend to update and to know or be able to determine the + name servers for that zone. + + + + + + + + + +Vixie, et. al. Standards Track [Page 17] + +RFC 2136 DNS Update April 1997 + + + 4.2. If update ordering is desired, the requestor will need to know + the value of the existing SOA RR. Requestors who update the SOA RR + must update the SOA SERIAL field in a positive direction (as defined + by [RFC1982]) and also preserve the other SOA fields unless the + requestor's explicit intent is to change them. The SOA SERIAL field + must never be set to zero (0). + + 4.3. If the requestor has reasonable cause to believe that all of a + zone's servers will be equally reachable, then it should arrange to + try the primary master server (as given by the SOA MNAME field if + matched by some NS NSDNAME) first to avoid unnecessary forwarding + inside the slave servers. (Note that the primary master will in some + cases not be reachable by all requestors, due to firewalls or network + partitioning.) + + 4.4. Once the zone's name servers been found and possibly sorted so + that the ones more likely to be reachable and/or support the UPDATE + opcode are listed first, the requestor composes an UPDATE message of + the following form and sends it to the first name server on its list: + + ID: (new) + Opcode: UPDATE + Zone zcount: 1 + Zone zname: (zone name) + Zone zclass: (zone class) + Zone ztype: T_SOA + Prerequisite Section: (see previous text) + Update Section: (see previous text) + Additional Data Section: (empty) + + 4.5. If the requestor receives a response, and the response has an + RCODE other than SERVFAIL or NOTIMP, then the requestor returns an + appropriate response to its caller. + + 4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or + if no response is received within an implementation dependent timeout + period, or if an ICMP error is received indicating that the server's + port is unreachable, then the requestor will delete the unusable + server from its internal name server list and try the next one, + repeating until the name server list is empty. If the requestor runs + out of servers to try, an appropriate error will be returned to the + requestor's caller. + + + + + + + + + +Vixie, et. al. Standards Track [Page 18] + +RFC 2136 DNS Update April 1997 + + +5 - Duplicate Detection, Ordering and Mutual Exclusion + + 5.1. For correct operation, mechanisms may be needed to ensure + idempotence, order UPDATE requests and provide mutual exclusion. An + UPDATE message or response might be delivered zero times, one time, + or multiple times. Datagram duplication is of particular interest + since it covers the case of the so-called "replay attack" where a + correct request is duplicated maliciously by an intruder. + + 5.2. Multiple UPDATE requests or responses in transit might be + delivered in any order, due to network topology changes or load + balancing, or to multipath forwarding graphs wherein several slave + servers all forward to the primary master. In some cases, it might + be required that the earlier update not be applied after the later + update, where "earlier" and "later" are defined by an external time + base visible to some set of requestors, rather than by the order of + request receipt at the primary master. + + 5.3. A requestor can ensure transaction idempotence by explicitly + deleting some "marker RR" (rather than deleting the RRset of which it + is a part) and then adding a new "marker RR" with a different RDATA + field. The Prerequisite Section should specify that the original + "marker RR" must be present in order for this UPDATE message to be + accepted by the server. + + 5.4. If the request is duplicated by a network error, all duplicate + requests will fail since only the first will find the original + "marker RR" present and having its known previous value. The + decisions of whether to use such a "marker RR" and what RR to use are + left up to the application programmer, though one obvious choice is + the zone's SOA RR as described below. + + 5.5. Requestors can ensure update ordering by externally + synchronizing their use of successive values of the "marker RR." + Mutual exclusion can be addressed as a degenerate case, in that a + single succession of the "marker RR" is all that is needed. + + 5.6. A special case where update ordering and datagram duplication + intersect is when an RR validly changes to some new value and then + back to its previous value. Without a "marker RR" as described + above, this sequence of updates can leave the zone in an undefined + state if datagrams are duplicated. + + 5.7. To achieve an atomic multitransaction "read-modify-write" cycle, + a requestor could first retrieve the SOA RR, and build an UPDATE + message one of whose prerequisites was the old SOA RR. It would then + specify updates that would delete this SOA RR and add a new one with + an incremented SOA SERIAL, along with whatever actual prerequisites + + + +Vixie, et. al. Standards Track [Page 19] + +RFC 2136 DNS Update April 1997 + + + and updates were the object of the transaction. If the transaction + succeeds, the requestor knows that the RRs being changed were not + otherwise altered by any other requestor. + +6 - Forwarding + + When a zone slave forwards an UPDATE message upward toward the zone's + primary master server, it must allocate a new ID and prepare to enter + the role of "forwarding server," which is a requestor with respect to + the forward server. + + 6.1. The set of forward servers will be same as the set of servers + this zone slave would use as the source of AXFR or IXFR data. So, + while the original requestor might have used the zone's NS RRset to + locate its update server, a forwarder always forwards toward its + designated zone master servers. + + 6.2. If the original requestor used TCP, then the TCP connection from + the requestor is still open and the forwarder must use TCP to forward + the message. If the original requestor used UDP, the forwarder may + use either UDP or TCP to forward the message, at the whim of the + implementor. + + 6.3. It is reasonable for forward servers to be forwarders + themselves, if the AXFR dependency graph being followed is a deep one + involving firewalls and multiple connectivity realms. In most cases + the AXFR dependency graph will be shallow and the forward server will + be the primary master server. + + 6.4. The forwarder will not respond to its requestor until it + receives a response from its forward server. UPDATE transactions + involving forwarders are therefore time synchronized with respect to + the original requestor and the primary master server. + + 6.5. When there are multiple possible sources of AXFR data and + therefore multiple possible forward servers, a forwarder will use the + same fallback strategy with respect to connectivity or timeout errors + that it would use when performing an AXFR. This is implementation + dependent. + + 6.6. When a forwarder receives a response from a forward server, it + copies this response into a new response message, assigns its + requestor's ID to that message, and sends the response back to the + requestor. + + + + + + + +Vixie, et. al. Standards Track [Page 20] + +RFC 2136 DNS Update April 1997 + + +7 - Design, Implementation, Operation, and Protocol Notes + + Some of the principles which guided the design of this UPDATE + specification are as follows. Note that these are not part of the + formal specification and any disagreement between this section and + any other section of this document should be resolved in favour of + the other section. + + 7.1. Using metavalues for CLASS is possible only because all RRs in + the packet are assumed to be in the same zone, and CLASS is an + attribute of a zone rather than of an RRset. (It is for this reason + that the Zone Section is not optional.) + + 7.2. Since there are no data-present or data-absent errors possible + from processing the Update Section, any necessary data-present and + data- absent dependencies should be specified in the Prerequisite + Section. + + 7.3. The Additional Data Section can be used to supply a server with + out of zone glue that will be needed in referrals. For example, if + adding a new NS RR to HOME.VIX.COM specifying a nameserver called + NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional + Data Section. Servers can use this information or ignore it, at the + discretion of the implementor. We discourage caching this + information for use in subsequent DNS responses. + + 7.4. The Additional Data Section might be used if some of the RRs + later needed for Secure DNS Update are not actually zone updates, but + rather ancillary keys or signatures not intended to be stored in the + zone (as an update would be), yet necessary for validating the update + operation. + + 7.5. It is expected that in the absence of Secure DNS Update, a + server will only accept updates if they come from a source address + that has been statically configured in the server's description of a + primary master zone. DHCP servers would be likely candidates for + inclusion in this statically configured list. + + 7.6. It is not possible to create a zone using this protocol, since + there is no provision for a slave server to be told who its master + servers are. It is expected that this protocol will be extended in + the future to cover this case. Therefore, at this time, the addition + of SOA RRs is unsupported. For similar reasons, deletion of SOA RRs + is also unsupported. + + + + + + + +Vixie, et. al. Standards Track [Page 21] + +RFC 2136 DNS Update April 1997 + + + 7.7. The prerequisite for specifying that a name own at least one RR + differs semantically from QUERY, in that QUERY would return + <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at + this name, while UPDATE's prerequisite condition [Section 2.4.4] + would NOT be satisfied. + + 7.8. It is possible for a UDP response to be lost in transit and for + a request to be retried due to a timeout condition. In this case an + UPDATE that was successful the first time it was received by the + primary master might ultimately appear to have failed when the + response to a duplicate request is finally received by the requestor. + (This is because the original prerequisites may no longer be + satisfied after the update has been applied.) For this reason, + requestors who require an accurate response code must use TCP. + + 7.9. Because a requestor who requires an accurate response code will + initiate their UPDATE transaction using TCP, a forwarder who receives + a request via TCP must forward it using TCP. + + 7.10. Deferral of SOA SERIAL autoincrements is made possible so that + serial numbers can be conserved and wraparound at 2**32 can be made + an infrequent occurance. Visible (to DNS clients) SOA SERIALs need + to differ if the zone differs. Note that the Authority Section SOA + in a QUERY response is a form of visibility, for the purposes of this + prerequisite. + + 7.11. A zone's SOA SERIAL should never be set to zero (0) due to + interoperability problems with some older but widely installed + implementations of DNS. When incrementing an SOA SERIAL, if the + result of the increment is zero (0) (as will be true when wrapping + around 2**32), it is necessary to increment it again or set it to one + (1). See [RFC1982] for more detail on this subject. + + 7.12. Due to the TTL minimalization necessary when caching an RRset, + it is recommended that all TTLs in an RRset be set to the same value. + While the DNS Message Format permits variant TTLs to exist in the + same RRset, and this variance can exist inside a zone, such variance + will have counterintuitive results and its use is discouraged. + + 7.13. Zone cut management presents some obscure corner cases to the + add and delete operations in the Update Section. It is possible to + delete an NS RR as long as it is not the last NS RR at the root of a + zone. If deleting all RRs from a name, SOA and NS RRs at the root of + a zone are unaffected. If deleting RRsets, it is not possible to + delete either SOA or NS RRsets at the top of a zone. An attempt to + add an SOA will be treated as a replace operation if an SOA already + exists, or as a no-op if the SOA would be new. + + + + +Vixie, et. al. Standards Track [Page 22] + +RFC 2136 DNS Update April 1997 + + + 7.14. No semantic checking is required in the primary master server + when adding new RRs. Therefore a requestor can cause CNAME or NS or + any other kind of RR to be added even if their target name does not + exist or does not have the proper RRsets to make the original RR + useful. Primary master servers that DO implement this kind of + checking should take great care to avoid out-of-zone dependencies + (whose veracity cannot be authoritatively checked) and should + implement all such checking during the prescan phase. + + 7.15. Nonterminal or wildcard CNAMEs are not well specified by + [RFC1035] and their use will probably lead to unpredictable results. + Their use is discouraged. + + 7.16. Empty nonterminals (nodes with children but no RRs of their + own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response + to a query of any type for that name. There is no provision for + empty terminal nodes -- so if all RRs of a terminal node are deleted, + the name is no longer in use, and queries of any type for that name + will result in an NXDOMAIN response. + + 7.17. In a deep AXFR dependency graph, it has not historically been + an error for slaves to depend mutually upon each other. This + configuration has been used to enable a zone to flow from the primary + master to all slaves even though not all slaves have continuous + connectivity to the primary master. UPDATE's use of the AXFR + dependency graph for forwarding prohibits this kind of dependency + loop, since UPDATE forwarding has no loop detection analagous to the + SOA SERIAL pretest used by AXFR. + + 7.18. Previously existing names which are occluded by a new zone cut + are still considered part of the parent zone, for the purposes of + zone transfers, even though queries for such names will be referred + to the new subzone's servers. If a zone cut is removed, all parent + zone names that were occluded by it will again become visible to + queries. (This is a clarification of [RFC1034].) + + 7.19. If a server is authoritative for both a zone and its child, + then queries for names at the zone cut between them will be answered + authoritatively using only data from the child zone. (This is a + clarification of [RFC1034].) + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 23] + +RFC 2136 DNS Update April 1997 + + + 7.20. Update ordering using the SOA RR is problematic since there is + no way to know which of a zone's NS RRs represents the primary + master, and the zone slaves can be out of date if their SOA.REFRESH + timers have not elapsed since the last time the zone was changed on + the primary master. We recommend that a zone needing ordered updates + use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see + [RFC1995]), and that a client receiving a prerequisite error while + attempting an ordered update simply retry after a random delay period + to allow the zone to settle. + +8 - Security Considerations + + 8.1. In the absence of [RFC2137] or equivilent technology, the + protocol described by this document makes it possible for anyone who + can reach an authoritative name server to alter the contents of any + zones on that server. This is a serious increase in vulnerability + from the current technology. Therefore it is very strongly + recommended that the protocols described in this document not be used + without [RFC2137] or other equivalently strong security measures, + e.g. IPsec. + + 8.2. A denial of service attack can be launched by flooding an update + forwarder with TCP sessions containing updates that the primary + master server will ultimately refuse due to permission problems. + This arises due to the requirement that an update forwarder receiving + a request via TCP use a synchronous TCP session for its forwarding + operation. The connection management mechanisms of [RFC1035 4.2.2] + are sufficient to prevent large scale damage from such an attack, but + not to prevent some queries from going unanswered during the attack. + +Acknowledgements + + We would like to thank the IETF DNSIND working group for their input + and assistance, in particular, Rob Austein, Randy Bush, Donald + Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz. Special + thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this + document. + + + + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 24] + +RFC 2136 DNS Update April 1997 + + +References + + [RFC1035] + Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + + [RFC1982] + Elz, R., "Serial Number Arithmetic", RFC 1982, University of + Melbourne, August 1996. + + [RFC1995] + Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute + of Technology, August 1996. + + [RFC1996] + Vixie, P., "A Mechanism for Prompt Notification of Zone Changes", + RFC 1996, Internet Software Consortium, August 1996. + + [RFC2065] + Eastlake, D., and C. Kaufman, "Domain Name System Protocol + Security Extensions", RFC 2065, January 1997. + + [RFC2137] + Eastlake, D., "Secure Domain Name System Dynamic Update", RFC + 2137, April 1997. + +Authors' Addresses + + Yakov Rekhter + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134-1706 + + Phone: +1 914 528 0090 + EMail: yakov@cisco.com + + + Susan Thomson + Bellcore + 445 South Street + Morristown, NJ 07960 + + Phone: +1 201 829 4514 + EMail: set@thumper.bellcore.com + + + + + + +Vixie, et. al. Standards Track [Page 25] + +RFC 2136 DNS Update April 1997 + + + Jim Bound + Digital Equipment Corp. + 110 Spitbrook Rd ZK3-3/U14 + Nashua, NH 03062-2698 + + Phone: +1 603 881 0400 + EMail: bound@zk3.dec.com + + + Paul Vixie + Internet Software Consortium + Star Route Box 159A + Woodside, CA 94062 + + Phone: +1 415 747 0204 + EMail: paul@vix.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vixie, et. al. Standards Track [Page 26] + |