5

Does the SOA record in a DNS zone file have any purpose whatsoever, apart from zone file transfers? If a DNS server does not rely on zone file transfer for replication (but instead relies on some distributed backend database), is there even any reason for having an SOA record? Looking thru DNS query logs, I've never even seen a client even request an SOA record.

I suppose the "primary nameserver" and "admin" fields could be of some use, but usually the primary nameserver is obtained via an NS record.

7

Yes, the SOA record serves a purpose regardless. While the SOA record is not typically queried directly by regular clients it is returned in negative responses!

If you were to analyze your nameserver's responses rather than the incoming queries I think you would see the SOA record a lot more.

However, some of the fields of the SOA record are no longer relevant if the zone transfer method that is part of the DNS spec is not used.


If we take a look of the fields of the SOA record:

MNAME: name of master nameserver. Used in the context of dynamic updates as well as in some cases as part of the zone transfer implementation.

RNAME: technical contact email. Not really used by the system itself but rather informational.

SERIAL: zone serial number, used for zone transfers.

REFRESH: refresh interval, used for zone transfers.

RETRY: retry interval, used for zone transfers.

EXPIRE: expire interval, used for zone transfers.

MINIMUM: used to be the minimum TTL but is nowadays used as TTL for negative responses.


So we can see that MNAME, RNAME and MINIMUM are not specific to the zone transfer spec.

Out of this, I would say that the way negative responses work in DNS and the SOA MINIMUM field in particular is the main reason why a SOA record is necessary regardless of how zone synchronization is implemented.
Because of this, you simply can't implement a properly working authoritative nameserver without having SOA record in each zone.

  • Yeah, as Håkan says it will probably help if you look at some responses in a packet capture. It's very common to see this record in the AUTHORITY section of replies. dig blah.example.com. will return an example of this in the NXDOMAIN response. – Andrew B Oct 27 '14 at 23:23
0

I found this question while asking a similar question: "What are all the ways an SOA record is used?"

To add answers to Håkan Lindqvist's answer here, I would say this:

  • SOA stands for "Start Of Authority". This is a sort of 'anchor' for knowing what server is authoritative for what zone. If you got rid of the SOA record, how would you have that? You might have many servers in the NS records, but they can be authoritative for many (and different) zones. If your DNS service is going to function, at a minimum, you should be able to know what 1 server is going to work - the one said to be authoritative for the zone on the SOA record.
  • My tool for DNS has a proprietary database that deploys to all servers (running BIND) every so often, and is an independent piece of machinery from the actual DNS servers. This provides a level of buffer from problems in the production service. (i.e. I can upgrade the proprietary server without impacting the DNS service.) If that machine were to go down for an extended period of time, there is still a set of DNS server behavior defined in the SOA record for the service to continue (negative cache, refresh, retry, etc.). If the SOA record is not there, that behavior is not defined. How else would you know the behavior? You would have to define it somewhere else, and that would either be in another record type (defined in some other RFC), or some hidden proprietary document. If you are going to that trouble, why re-invent the wheel? Why not use the SOA record?

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.