notify explicit and also-notify

[Bob McDonald]

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