Dynamic Updates in the DNS System

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.

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), however this document only addresses UDP.

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
      +---------------------+

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.

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                    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

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.
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.

Updates can be done in any of the following manners:

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.
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.
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.
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.

One significant area in which the protocol specification for UPDATE is especially vague is the area of security authentication. Any methods of authenticating the identify of the host sending the UPDATE command are completely up to the DNS server implementation. Failure to provide a security mechanism would allow any outside party to arbitrarily modify the DNS records of the master or primary servers at will.

Additional References

The UPDATE protocol is documented in RFC 2136 - Dynamic Updates in the Domain Name System (DNS UPDATE) and is the authoritive document on the subject.

Recent versions of BIND 8 optionally support on demand updating of secondary DNS servers from the primary DNS server when an update to the domain file occurs. All servers to be involved in the update need to be compiled with an option to allow the updating commands to be processed.

Jeffrey Lawson

Last modified: Sun May 3 11:48:59 PDT 1998