Skip to main content

1. Definitions

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.

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.

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)
Last updated on