This gets much more involved the further downstream you go. For example, when a downstream slave (true or stealth) provides transfers to a further downstream slave (true or stealth), the notify options can get a bit messy.
Bottom line is it requires some detailed analysis and probably some pictures. Regards, Bob On Fri, May 4, 2018 at 6:21 AM, Bob McDonald <bmcdonal...@gmail.com> wrote: > This is my understanding of how Current (ver. 9.8 and above) ISC Bind > works. It may or may not apply to older versions of ISC Bind and/or DNS > resolver programs from other sources. This is only MY understanding. You > are welcome to disagree and point out the folly of my understanding. > > There are several types of zones: > > 1) True Master - Defined in the zone block in the named.conf as a master > AND appearing in the MNAME field in the SOA record of the zone. > > 2) Stealth Master - Defined in the zone block in the named.conf as a > master AND NOT appearing in the MNAME field in the SOA record of the zone. > NOT visible to clients. Requires update forwarding for DDNS updates. > > 3) Apparent Master - defined in the zone block in the named.conf as a > slave AND appearing in the MNAME field in the SOA record of the zone. > Although visible to clients, not really the master. Think of it as > masquerading as the True Master in place of a Stealth Master. > > 4) True Slaves - Defined in the zone block in the named.conf as a slave > AND appearing in the zone as part of the NS RRset.. > > 5) Stealth Slaves - Defined in the zone block in named.conf as a slave AND > NOT appearing in the zone as part of the NS RRset. (e.g. authoritative for > the zone yet not in the NS RRset) > > notify=no - Notifies are not sent. Updating is done via the zone refresh > timers. (now there's something to explain to management...) > > notify=yes - notifies are sent to all servers appearing in the NS RRset > (except the server identified in the MNAME field of the SOA record) and to > the also-notify list > > notify=master-only - notifies are only sent to master servers. (still > getting my head wrapped around this one) > > notify=explicit - notifies are ONLY sent to servers listed in the > also-notify list. > > To complicate things further... The notify option may also be specified > in the zone statement, in which case it overrides the options notify > statement. It would only be necessary to turn off this option if it caused > slaves to crash. > > There is also an option: > > notify-to-soa - If yes do not check the nameservers in the NS RRset > against the SOA MNAME. Normally a NOTIFY message is not sent to the SOA > MNAME (SOA ORIGIN) as it is supposed to contain the name of the ultimate > master. Sometimes, however, a slave is listed as the SOA MNAME in hidden > master configurations and in that case you would want the ultimate master > to still send NOTIFY messages to all the nameservers listed in the NS RRset. > > So, the bottom line is that there are SEVERAL ways to make notifies (and > therefore updates) flow through the environment. > > Once you get this figured out, add in allow-notify, allow-updates, and > update-forwarding (just say no...). There are also other use cases for > dial-up. etc. > > Also, authoritative means serving a valid copy of a specific zone. (e.g. > the server has a copy of the zone file and has a valid definition in it's > named.conf that matches one of the above defined types) > > Hope that helps. > > Regards, > > Bob >
_______________________________________________ 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
