notify explicit and also-notify

Matus UHLAR - fantomas uhlar at fantomas.sk
Fri May 4 10:58:23 UTC 2018


On 04.05.18 06:21, Bob McDonald 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

everything OK if I haven't missed something.

>notify=master-only - notifies are only sent to master servers. (still
>getting my head wrapped around this one)

no, this causes notifies to be sent only for master zones.
not very useful in zone definition, but quite useful in bind options.

>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.

correct, although I don't understand why slaves should crash when receiving
a notify (broken software should be fixed)

>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)

correct

-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
99 percent of lawyers give the rest a bad name. 


More information about the bind-users mailing list