MNAME not a listed NS record

Barry Margolin barmar at
Thu Jan 17 00:30:07 UTC 2013

In article <mailman.1080.1358373225.11945.bind-users at>,
 Chuck Swiger <cswiger at> wrote:

> On Jan 16, 2013, at 1:42 PM, Barry Margolin wrote:
> > In article <mailman.1077.1358370123.11945.bind-users at>,
> > Chuck Swiger <cswiger at> wrote:
> > 
> >> On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
> >>> Is there anything technically wrong with having a SOA MNAME field that 
> >>> isn't listed as a NS record?
> >> 
> >> Sure.  The SOA MNAME is expected to be the "primary master" nameserver for 
> >> the zone; it's where things like dhcpd and such send dynamic updates for 
> >> the 
> >> zone to.
> > 
> > But that doesn't mean it should be the server for resolver queries.
> True, but I don't see much utility from a nameserver which can be dynamically
> updated but not queried.

Who says you're using dynamic update? The MNAME field has been part of 
the DNS standard since long before DHCP and dynamic update.  In many 
instances it's just an FYI field.

> >>> The server listed as MNAME will host the zone and is authoritative for 
> >>> the 
> >>> zone, but out of latency concerns it isn't ideal to have other resolvers 
> >>> querying this server.
> >> 
> >> why would you use that nameserver at all, then?
> >> 
> >> Choose a nameserver which is suitable for other resolvers to query for 
> >> your 
> >> master.
> > 
> > The master could be behind a firewall that only allows the published 
> > nameservers to connect to it.
> Sure.  In which case, why publish an internal-only machine into the public
> DNS via your SOA record?  Someone else made mention of a "stealth master",
> but my definition of that is an internal machine which is not visible in
> any publicly published records.

You have to put something in the MNAME. You could lie and put one of the 
public nameservers, but why do that when you could put the true master?

> > The performance requirements of a nameserver that serves public queries 
> > are different from a server that only has to respond to zone transfer 
> > requests from the published nameservers.
> True.  Handling AFXRs isn't much work, and you can always revert to other 
> methods
> of replicating zone data if need be, so my primary concern is making 
> nameservers
> work well enough to handle the query load, and not to make nameservers just 
> handle
> zone transfers.

Do that on the public nameservers.  The hidden master doesn't need to be 
dedicated to nameserving, since it's not handling all the load that the 
public servers do.

Barry Margolin
Arlington, MA

More information about the bind-users mailing list