Dynamic Updates in the Domain Name System (DNS UPDATE)
RFC 2136
Document | Type |
RFC - Proposed Standard
(April 1997; Errata)
Updates RFC 1035
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text pdf html bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2136 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 possibleShow full document text