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
