No SOA record -- what are the implications?

Solution 1:

There is in fact a SOA record, it's just not where you're expecting it. Let's take a look at the AUTHORITY section...keep in mind that ns1.nservers.co.uk. is not in any way affiliated with the nic.uk. nameservers, which are authoritative for co.uk..

$ dig @ns1.nservers.co.uk. +norecurse +noall +authority vancemillerkitchensuk.co.uk SOA
co.uk.                  3600    IN      SOA     win-k7rk0hedad1. hostmaster. 6 900 600 86400 3600
$ dig @ns1.nservers.co.uk. +norecurse +short co.uk SOA
win-k7rk0hedad1. hostmaster. 6 900 600 86400 3600

This betrays their actual configuration: they have a single co.uk zone defined. This simplifies their configuration as they only have to maintain one file. The reason you don't get an answer section for the SOA request is because that isn't the true top of the zone. Keep in mind that this is a terrible configuration: you should never pretend to be authoritative for domains that you're not. Don't emulate this.

SOA records are mandatory. You have to stuff something in that AUTHORITY section where it is required by RFC if you expect the rest of the internet to play nicely with you. Obviously they aren't really authoritative for co.uk, but this at least tells other nameservers what the negative TTL should be.

Solution 2:

SOA record at apex of every zone on the child nameservers is mandatory per DNS specification, see §6.1 of RFC 2181:

The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone. Such a server is authoritative for all resource records in a zone that are not in another zone.

A zone not having a SOA is then not DNS-conforming. Nameservers will reject it at load time:

$ cat example.com 
example.com. 1 NS a.example.
example.com. 1 NS b.example. 

$ named-checkzone example.com example.com 
zone example.com/IN: has 0 SOA records
zone example.com/IN: not loaded due to errors.

Maybe you can find a setup where it works, but why risking it?

Besides being mandatory per specification, there are at least 3 items in the SOA record that are needed by clients (all the other items are mostly useful only to the nameservers administrator if its set of nameservers use AXFR/IXFR/DNS Updates to update themselves):

• the RNAME is normally the email address of the person responsible for the zone, that you can contact in case of problems; unfortunately nowadays you may not get an answer there or it may not even be a valid existing mailbox anyway, so theoretically useful, in practice not sure

• the MNAME, per §4.3 of RFC 2616 is needed for DNS Updates:

4.3. If the requestor has reasonable cause to believe that all of a zone's servers will be equally reachable, then it should arrange to try the primary master server (as given by the SOA MNAME field if matched by some NS NSDNAME) first to avoid unnecessary forwarding inside the slave servers. (Note that the primary master will in some cases not be reachable by all requestors, due to firewalls or network partitioning.)

• the SOA MINIMUM has been redefined over the year to now be the "negative TTL", the amount of time a cache can keep the NXDOMAIN reply it got (since an NXDOMAIN reply would return no records in the answer section per definition, there won't be there any TTL to find). See §5 of RFC 2308:

Like normal answers negative answers have a time to live (TTL). As there is no record in the answer section to which this TTL can be applied, the TTL must be carried by another method. This is done by including the SOA record from the zone in the authority section of the reply. When the authoritative server creates this record its TTL is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. This TTL decrements in a similar manner to a normal cached answer and upon reaching zero (0) indicates the cached negative answer MUST NOT be used again.

Proper caching of NXDOMAIN replies is important for performances, as outlined in RFC 8020 "NXDOMAIN: There Really Is Nothing Underneath": if a name triggers an NXDOMAIN reply then the recursive nameserver can, during the time the entry is cached, reply immediately for all names "below" the one queried, as it knows that no name can exist below, per the DNS design of having all names in a tree.

Also, multiple registries test the configuration before allowing to do the delegation. It is not the case for UK, but it is the case for DENIC (.DE) for example. See §2.1.4 in https://www.denic.de/fileadmin/public/documentation/DENIC-23p_EN.pdf that outlines the test on SOA.

Various tools check for it also. See Zonemaster at https://zonemaster.net/ and the explanation of its test on SOA at https://github.com/zonemaster/zonemaster/blob/master/docs/specifications/tests/Delegation-TP/delegation06.md

---

Solution 3:

SOA records pretty much regulate the identity and the update frequency of your DNS servers. If your DNS server is the only authorative DNS server for a domain (Or you control all the authoraties and have a fancy for manual actions), you can omit the SOA record with little to no impact. The only impact might be that some response caching will not happen.

In summary: DNS can work just fine without SOA, SOA just regulates updates to secondary servers, and caching. So it's a really bad idea to not have a SOA record.