On Jan 16, 2013, at 1:42 PM, Barry Margolin wrote: > In article <mailman.1077.1358370123.11945.bind-us...@lists.isc.org>, > Chuck Swiger <cswi...@mac.com> 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. >>> 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. >> >> Okay...so 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. > 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. Regards, -- -Chuck _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users