On 2012-11-28, at 22:21, Don Stokes
On 29/11/12 10:17, Martin D Kealey wrote:
AFAIK this is because the "primary nameserver" field in the SOA record doesn't one of the NS records in the delegation from the parent zone.
Absolutely not. The SOA primary name server not being one of the delegated name servers is not an error, in fact it's a common configuration.
The MNAME field has a single use these days, which is to identify the server responsible for accepting DNS UPDATE (RFC2136) requests. Zones that don't support dynamic updates can either not care about any junk update requests they receive at the nominated server, or set the MNAME to something that will cause such junk requests to be sent elsewhere. Don, you example of loopback.dns.net.nz is a good one. I tend to be more crude in my zones, e.g. see below. [I once tried to persuade the dnsop working group at the IETF that enshrining an empty field to mean "not applicable" in MNAME and also as an MX target was a good idea. Nobody agreed, really. I then attempted to reserve SINK.ARPA as a name that would definitively never exist, so that you could use that as an MNAME or an MX target for zones that don't want dynamic updates or mail, and that failed in the IESG. A procedural document requiring IAB review which defined and required the non-existence of something that already didn't exist made people curiously angry.] Fully agree that there's no requirement for the MNAME to be populated with anything that appears in the apex NS set RDATA. [krill:~]% dig hopcount.ca soa +noall +answer ; <<>> DiG 9.8.3-P1 <<>> hopcount.ca soa +noall +answer ;; global options: +cmd hopcount.ca. 86377 IN SOA . jabley.hopcount.ca. 1304604691 28800 3600 604800 3600 [krill:~]% Joe