notify explicit and also-notify

[Bob McDonald]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180504/1c22c1f4/attachment.html>