The semantics of the fields of an SOA resource record

You've come to this page because you've asked a question similar to the following:
What are the semantics of the fields of an SOA resource record?
or because you've made a fallacious statement such as:

This is the Frequently Given Answer to that question and to such fallacious statements.

The fields in (the data portions of) SOA resource records fall into four groups:

The MNAME field

The MNAME field supposedly (according to RFC 1035) contains the name of the "primary" (a.k.a. "master") content DNS server for the "zone", holding the master copies of the DNS data for that "zone". However, that erroneously assumes that only database replication mechanisms that have a "single master, multiple (direct and indirect) slaves" paradigm exist. This is, of course, false. Other, multiple master, database replication mechanisms exist.

In fact, the main, if not sole, use of this field is by Dynamic DNS update. Dynamic DNS update clients attempt to automatically determine, in the absence of their having been explicitly told, what content DNS server to send their update requests to. They do this by looking up what is published in the DNS database. They perform a series of SOA resource record lookups, starting with the domain name whose DNS data they wish to update and proceeding to progressively shorter domain names until a non-empty SOA resource record set is found; and then perform a name-to-address lookup on the name, in the MNAME field of the SOA resource record thus located, to find the addresses on which the relevant content DNS servers are listening for Dynamic DNS update requests. They then send their Dynamic DNS update requests to those addresses.

So a better description of the MNAME field is that it is an intermediate domain name, forming the halfway point in a two-stage mapping from a domain name (the apex of a "zone") to the IP address(es) of the content DNS server(s) for that "zone", to which Dynamic DNS update requests are to be sent.

It is wrong to assume that the domain name in the MNAME field must always exist, or must match one of the intermediate domain names used in the delegation data for the "zone" (i.e. the domain names in the NS resource record set). This is for several reasons:

It is also wrong to assume that it is an error if the domain name in the MNAME is not identical across all content DNS servers for a given "zone". This is because:

The RNAME field

The RNAME field supposedly (according to RFC 1035) contains the mailbox name of the "person responsible" for the "zone". However, domain registries identify at least three distinct "responsible person" rôles ("administrative", "technical", and "billing") for which having a single mailbox name is simply insufficient.

In practice, this field is only used by humans who are reading the outputs of DNS diagnosis tools. No known software uses it for any purpose. This field is a vestigal part of the DNS database schema that has long since been superceded by other, superior, non-DNS mechanisms.

One content DNS server software, Dan Bernstein's djbdns, provides a convenience feature that will automatically set the RNAME in the SOA resource record for a domain example.com. to be the mailbox name hostmaster@example.com, without the DNS database administrator having to enter that datum by hand. This is a reasonable convention to adhere to, even where one is setting the RNAME field manually. Another reasonable convention is to simply set the RNAME field to ., to convey that this field is in desuetude.

The SERIAL, REFRESH, RETRY, and EXPIRE fields

The SERIAL, REFRESH, RETRY, and EXPIRE fields are private to each individual DNS database replication mechanism used by a particular set of peer content DNS servers for the relevant "zone". Not all DNS database replication mechanisms use all of these fields in the same way, or use them in ways that are compatible with one another, or even use them at all.

Beware humans wielding DNS diagnosis tools, and reading their output. The only entities to which the contents of these fields should properly matter are the peer content DNS servers involved in the replication of the DNS database content for the relevant "zone". One cannot know whether these fields have appropriate values and behaviour without knowing what DNS database replication mechanism in use amongst the content DNS servers actually is. Treat warnings about the contents of these fields, especially warnings given by entities who appear to only recognise one DNS database replication mechanism ("zone transfer") and no others, as suspect.

Beware humans playing mix-and-match with DNS database replication mechanisms. Some DNS database replication mechanisms rely quite heavily upon these fields. Since not all DNS database replication mechanisms use all of these fields in the same way, or use them in ways that are compatible with one another, or even use them at all, one should not mix and match different DNS database replication mechanisms across a set of peer content DNS servers, unless one is very careful and knows exactly what one is doing. (Note that this admonition applies across all DNS server softwares, and is not specific to any particular software. Beware humans who try to paint this as being a Microsoft-specific, or djbdns-specific, thing, too.)

The semantics of these fields with respect to the "zone transfer" DNS database replication mechanism

"Zone transfer" is the one database replication mechanism that makes heavy use of the SERIAL, REFRESH, RETRY, and EXPIRE fields. The semantics of these fields with respect to ths DNS database replication mechanism are spelled out in detail in RFC 1034. So here is merely a précis:

The semantics of these fields with respect to Active Directory Integrated DNS database replication

Active Directory database replication doesn't use the SERIAL, REFRESH, RETRY, and EXPIRE fields of SOA resource records at all. The replication schedule is controlled by Active Directory replication configuration parameters that are specified and stored elsewhere. The contents of the DNS database are irrelevant. The serial number could be a fixed constant, and the refresh, retry, and expire intervals nonsense values, and Active Directory database replication would still work.

Active Directory updates the serial number in SOA resource records, according to the rules described in Microsoft KnowledgeBase article #282826, but that's just a sop for the benefit of things (mostly human beings wielding DNS diagnosis tools, ironically) that expect serial numbers to actually change. Whilst a single, sequenced, incrementing, counter matches the paradigm of the "zone transfer" replication mechanism; it doesn't match a multi-master database replication paradigm at all. It's impossible to have an exact mapping between the two. Active Directory constructs the best simulacrum that it can, to make it look as if there is a single sequenced counter there. But it can only ever be an approximation of what is actually going on.

Therefore constructing anything based upon the notion of there being a single, sequenced, counter, such a "zone transfer" database replication setup with a "slave" querying more than one Active Directory Integrated content DNS server as its "master", will fail. But this is not a problem, because doing so is expecting two different DNS database replication mechanisms to use the fields of SOA resource records in ways that are compatible with each other, and violating the rule that one must not expect this.

The upshot of this is a very simple maxim that should apply unless you are very careful and know exactly what you are doing: If you are going to use "zone transfer" alongside Active Directory database replication, have all of the "slaves" use a single primary "master". For preference, don't even do that and simply use Active Directory database replication on all servers.

The semantics of these fields with respect to DNS database replication by simple source file copying

One can, of course, replicate DNS data by the simple expedient of copying the DNS database source file around, using tools such as rsync, ftp, cvs, rcp, scp, or even just plain cp. This mechanism is mentioned, in passing, in RFC 1034 § 4.3.5. Exactly as Active Directory database replication, this mechanism doesn't use the SERIAL, REFRESH, RETRY, and EXPIRE fields of SOA resource records at all. The replication schedule, and whether data are considered to be out of date, are both determined by how the file copying mechanism is configured. The contents of the DNS database are irrelevant.

With some DNS server softwares, such as Dan Bernstein's djbdns, the server's facility to tie the serial number to the file timestamp of the database source file acts as a sop for the benefit of things (mostly human beings wielding DNS diagnosis tools, ironically) that expect serial numbers to actually change.

However, with DNS server softwares that require the administrator to set the serial number explicitly, by hand, those human beings wielding diagnosis tools will see serial numbers that do not change. But this is not a problem, because trying to mix in a different database replication mechanism that relies upon serial numbers changing is expecting different DNS database replication mechanisms to use the fields of SOA resource records in ways that are compatible with each other, and violating the rule that one must not expect this.

The MINIMUM field

There's a lot of confusion surrounding the MINIMUM field of SOA resource records. The problem is twofold:

The meaning of the MINIMUM fields of SOA resource records in DNS datagrams relates to "negative caching", i.e. the caching of empty resource record sets (i.e. resource record sets with no members) and of "no such name" indications.

The fundamental issues with "negative caching" are these:

So what RFC 2308 gives, to solve these two problems, is a bodge. When sending an empty resource record set in a response, and when sending a response that comprises the non-existence of a domain name, the response can have an SOA resource record added to it, which carries in its MINIMUM field the missing TTL information that the DNS protocol schema does not natively support. Similarly, when representing empty resource record sets and the non-existences of domain names in "zone" source files, the MINIMUM field of the related SOA resource record carries the missing TTL information that the "zone" source file schema does not natively support for those things. (Of course, this has the consequence that all empty resource record sets and non-existences in a single "zone" have identical TTL values.)

There's irony here, notice. In order to provide the "resource record set" semantics of RFC 2181, the easiest way to implement a caching proxy DNS server is actually to use the true schema of the distributed DNS database as the schema of the cache, and not the schemata of "zone" source files or of the DNS protocol. Most caching proxy DNS server softwares do indeed work this way. (The back-end converts all received responses from the DNS protocol schema, and the front-end converts all sent responses into the DNS protocol schema.) Negative caching support is a relatively integral part of this design. (Empty resource record sets and non-existences of domain names are concrete entities in their own rights, not simply the mere absences of other entities.) This is why it would be so unlikely for any caching proxy DNS server software to not support negative caching. (Its design would have to not be the simplest one.)


© Copyright 2004–2004 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.