SOA resource recordYou'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:
SOA
resource records of Active-Directory-integrated "zones".
This behaviour is wrong.
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:
MNAME
RNAME
SERIAL,
REFRESH,
RETRY,
and
EXPIRE
MINIMUM
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:
There is a particular arrangement of "master/slaves" database
replication schemes that is known as "hidden master". In this arrangement, the
"master" content DNS server is not accessible to anything but the slave content
DNS servers. Only the slave content DNS servers are listed in the delegation
information, not the master. The master publishes to the slaves, and the slaves
publish to the rest of Internet. The master's intermediate domain name may be
given in the MNAME field, but may not exist in the DNS database.
A "zone" may simply not support Dynamic DNS update at all. In which
case the MNAME field has no purpose to serve and what it contains
is completely irrelevant.
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:
In multiple-master database replication schemes where
Dynamic DNS update is supported, all of the content DNS servers are peers
and are masters. Dynamic DNS update requests may be sent to any of the
content DNS servers. Where such database replication schemes are used,
therefore, one can find each content DNS server listing itself in the
MNAME field of the SOA resource record that it is
publishing. This is not a problem. It doesn't matter which SOA
resource record a Dynamic DNS update client happens to receive when it
performs its SOA lookup. And it doesn't matter that two different
update requests might be sent to two different content DNS servers because of
this. Every content DNS server is a "master", and capable of processing the
update request by updating the DNS database. So the fact that the field
content varies, from content DNS server to content DNS server, is insignificant.
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.
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.)
"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 serial number in the SERIAL field
is a counter that is increased whenever the DNS database administrator deems
the "zone" data to have changed. The first step in "zone transfer"
database replication is to look up the SOA resource record
for the "zone" apex, and determine whether its serial number has changed
with respect to the locally stored copy of the database.
With ISC's BIND, DNS database administrators are expected to increase the serial number manually, after making changes. Manually tweaking the serial number is thus an integral part of the procedure for updating a resource record.
With some other DNS server softwares, such as Dan Bernstein's djbdns, the server has the capability to automatically increment the serial number whenever the "zone" data have changed, without need for explicit administrator action, by the simple expedient of using the file timestamp of the database source file as the serial number. This mechanism is mentioned, in passing, in RFC 1034 § 4.3.5.
The refresh interval in the REFRESH field
is the length of time that a "slave" waits after successful replication
of the database before it attempts replication again.
The retry interval in the RETRY field
is the length of time that a "slave" waits after an unsuccessful
replication attempt before it attempts replication again.
The expiry interval in the EXPIRE field
is the length of time that a "slave" holds on to the old data that it
already has whilst its attempts at replication remain unsuccessful.
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.
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.
MINIMUM field
There's a lot of confusion surrounding the MINIMUM field of
SOA resource records. The problem is twofold:
SOA resource record
sent in a DNS datagram is subtly different to the meaning of the field in
a "zone" source file.
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:
The database schema used by the DNS protocol does not actually match the true schema of the distributed DNS database. The schema used by the DNS protocol involves individual resource records with individual "owner name", "class", "type", "TTL", and "data" fields, with duplicate keys ("owner name"+"class"+"type") being allowed. As shown by the "clarification" in RFC 2181, however, the true schema used by the distributed DNS database involves "resource record sets", each with an owner name, a class, a type, a TTL, and a set of zero or more data; where keys (owner name+class+type) are required to be unique. (Every domain name that exists possesses a resource record set of every possible class and type. It is simply that most such resource record sets, of the tens of thousands of as-yet-undefined types, are empty. The non-existence of every domain name that doesn't exist also has a TTL, moreover.)
The problem is that it is impossible to directly represent, using the schema of the DNS protocol, the answers to certain queries against the distributed DNS database, as per the latter's schema. It's impossible to convey an empty resource record set, as per the distributed DNS database schema, using the schema of the DNS protocol. There's simply nowhere, in the DNS protocol, to convey the TTL of that empty resource record set. Similarly, it's impossible to convey the TTL of the non-existence of a domain name. The DNS protocol has nowhere to convey its TTL, either.
The schema of "zone" source files does not actually match the true schema of the distributed DNS database. There's no way to represent, in the "zone" source file schema, the TTLs of empty resource record sets. Nor is there any way to represent the TTLs of the non-existences of domain names.
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.)