Dynamic Updates in the Domain Name System (DNS UPDATE)
updated by
- rfc-3007 — Secure Domain Name System (DNS) Dynamic Update
- rfc-4033 — DNS Security Introduction and Requirements
- rfc-4034 — Resource Records for the DNS Security Extensions
- rfc-4035 — Protocol Modifications for the DNS Security Extensions
updates
- rfc-1035 — Domain names - implementation and specification
Extracted elements (28)
Creating a zone using DNS UPDATE is intentionally unsupported because there is no provision for telling a slave server who its master servers are. Addition and deletion of SOA RRs are therefore also unsupported at this time.
Idempotence and ordering are not built into the protocol but can be achieved by applications using a 'marker RR': delete the original marker and add a new one with different RDATA, specifying the original as a prerequisite. Only the first copy of a duplicated request will find the marker present.
Metavalues for CLASS are used in the Prerequisite and Update Sections 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. This is why the Zone Section is not optional.
No semantic checking (e.g., verifying that NS or CNAME targets exist) is required in the primary master when adding RRs. Servers that implement such checking should restrict it to the prescan phase and must avoid out-of-zone dependencies whose veracity cannot be authoritatively verified.
Requestors requiring accurate response codes must use TCP because a UDP response may be lost, causing a retry; the duplicate request may then fail (prerequisites no longer satisfied) even though the original update succeeded. Forwarders receiving via TCP must therefore also forward via TCP.
SOA SERIAL auto-increment deferral is permitted to conserve serial numbers and make 2**32 wraparound infrequent. Visible SOA SERIALs need only differ when zone content differs; the Authority Section SOA in a QUERY response counts as 'visible' for this purpose.
Wildcarding and aliasing are disabled in UPDATE processing: a wildcard matches only a wildcard in the zone, and a CNAME matches only a CNAME. All UPDATE operations are done on canonical names to avoid ambiguity.
A zone's SOA SERIAL should never be set to zero due to interoperability problems with widely deployed DNS implementations. If incrementing SERIAL would produce zero (wraparound at 2**32), it must be incremented again or set to one.
UPDATE dependency loops in the AXFR forwarding graph are prohibited because UPDATE forwarding has no loop detection analogous to the SOA SERIAL pretest used by AXFR. Historically, mutually dependent slaves were permitted for AXFR but this configuration is incompatible with UPDATE forwarding.
During Update Section prescan, RRs whose CLASS is not ANY must not have TYPE of ANY, AXFR, MAILA, MAILB, or any unrecognized type; violations signal FORMERR. CLASS=ANY or CLASS=NONE RRs must have TTL=0, else FORMERR.
If a zone slave receives an UPDATE request, it must forward the request toward the primary master, allocating a new ID for the forwarded message. If the original requestor used TCP, the forwarder must use TCP for forwarding.
If the zone's SOA SERIAL is not changed by an update, the server shall increment it automatically before the SOA or any changed RR is included in any response or transfer. The auto-increment deferral period must be no more than one-third of the zone refresh time, defaulting to the lesser of that maximum and 300 seconds.
SOA and NS RRs at the zone apex are protected: they cannot be deleted by 'delete all RRsets from a name' or 'delete an RRset' operations targeting the zone name, and the last NS RR in an NS RRset at the zone apex cannot be deleted individually.
SOA SERIAL changes from an update must be in a positive direction per RFC 1982 modulo 2**32 arithmetic. Attempts to replace an SOA with a lower or equal SERIAL are silently ignored by the primary master server.
The server must ensure atomicity with respect to concurrent UPDATE or QUERY transactions. No two transactions can be processed concurrently if either depends on the results of the other; UPDATE transactions that modify the same names or RRsets must be serialized.
The Zone Section must contain exactly one RR with ZTYPE=SOA; otherwise the server signals FORMERR. If the named zone is not one of the server's authority zones, the server signals NOTAUTH.
UPDATE is atomic: all prerequisites must be satisfied or no update operations take place. If any system failure occurs during Update Section processing, the server MUST signal SERVFAIL and undo all updates applied during the transaction.
When a zone is modified by an UPDATE, the server must commit the change to nonvolatile storage before sending a response or answering queries or transfers for the modified zone.
When adding an SOA RR, if an SOA already exists and the new SOA.SERIAL is lower than or equal to the current SOA.SERIAL per RFC 1982 arithmetic, the update RR is silently ignored. An attempt to add a new SOA where none exists is also treated as a no-op.
Five prerequisite semantics are defined, distinguished by CLASS and TYPE metavalues: (1) RRset exists value-independent (CLASS=ANY, TYPE=rrset, empty RDATA), (2) RRset exists value-dependent (CLASS=zone, full RDATA), (3) RRset does not exist (CLASS=NONE, TYPE=rrset), (4) name is in use (CLASS=ANY, TYPE=ANY), (5) name is not in use (CLASS=NONE, TYPE=ANY). All prerequisites use TTL=0.
Four update operations are defined by CLASS/TYPE metavalues: add to RRset (CLASS=zone), delete an RRset (CLASS=ANY, TYPE=rrset, empty RDATA), delete all RRsets from a name (CLASS=ANY, TYPE=ANY, empty RDATA), and delete a single RR from an RRset (CLASS=NONE, full RDATA). TTL must be zero for delete operations.
New assigned numbers introduced by this document: CLASS=NONE (254), Opcode=UPDATE (5), and new RCODE values YXDOMAIN (6), YXRRSET (7), NXRRSET (8), NOTAUTH (9), and NOTZONE (10).
The UPDATE message has five sections: Header, Zone (zone to be updated), Prerequisite (RRsets that must or must not preexist), Update (edits to apply), and Additional Data. The Zone Section must contain exactly one RR whose ZTYPE is SOA.
A denial-of-service attack can be launched by flooding an update forwarder with TCP sessions containing updates that the primary master will refuse. The synchronous TCP forwarding requirement means the forwarder holds connections open until the primary master responds, enabling resource exhaustion.
Without RFC 2137 (Secure DNS Update) or equivalent technology such as IPsec, anyone who can reach an authoritative name server can alter the contents of any zone on that server. It is very strongly recommended that DNS UPDATE not be deployed without such security measures.
Server processing follows a fixed pipeline: (1) validate Zone Section (FORMERR/NOTAUTH/forward), (2) check Prerequisites (NXDOMAIN/YXDOMAIN/NXRRSET/YXRRSET/NOTZONE/FORMERR), (3) check requestor permissions (REFUSED or continue), (4) prescan Update Section (FORMERR/NOTZONE), (5) apply updates (SERVFAIL on error), (6) return NOERROR.
The UPDATE message header reuses the DNS message header format but repurposes the four count fields as ZOCOUNT, PRCOUNT, UPCOUNT, and ADCOUNT. Only the QR flag bit is used; the Z field is reserved and must be zero.
The Zone Section encodes ZNAME (variable-length domain name), ZTYPE (16-bit, must be SOA), and ZCLASS (16-bit zone class). Exactly one record is permitted in this section.