MNAME not a listed NS record

Tim Maestas t.maestas at
Fri Jan 18 17:39:16 UTC 2013

nsupdate will use the MNAME regardless of whether it is matched by a
NS record.  ISC dhcpd, as you indicated, does not unless overridden
manually via a zone statement.

On Fri, Jan 18, 2013 at 9:35 AM, Chris Buxton <clists at> wrote:
> On Jan 16, 2013, at 1:01 PM, Chuck Swiger 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.
> No, not necessarily, not if there's no NS record for it.
> RFC 2136 says says that the server "as given by the SOA MNAME field if matched by some NS NSDNAME" should be the preferred target of a dynamic update. That is, if the master server (as indicated by the SOA record) is not listed in an NS record as an authoritative name server, it need not be considered. However, the RFC is a bit vague on how a requestor determines (and orders) the list of authoritative name servers for a zone, and so...
> - ISC DHCP sends DDNS updates to the SOA MNAME server if and only if that server is also listed in an NS record. Otherwise, it picks a name from the available NS records and sends the update there. This behavior can be overridden by a zone statement in dhcpd.conf.
> - Microsoft clients send DDNS updates to various places, and will typically try multiple targets if the update is denied. I believe the order is the first configured caching resolver, the zone's MNAME field, and then any one of the servers listed in the NS RRSet. I believe the client will try three times, assuming these three cases are all different. (I'm not counting potential retries to the same target to attempt use of GSS-TSIG.)
> I believe nsupdate behaves the same as dhcpd, but it's been a while since I last tested this.
> Chris Buxton
> BlueCat Networks
> _______________________________________________
> Please visit to unsubscribe from this list
> bind-users mailing list
> bind-users at

More information about the bind-users mailing list