OK So wondering if I have master in cloud wanted to know which port should
I open for slave which is behind corporate firewall and if I set as below
then my slaves will start listening on port 2034? I am bit confused on port
numbers for NOTIFY messages and NOTIFY-UPDATED [i.e. AXFR/IXFR]
also-notify {10.0.1.2; "notify-them" port 2034;};
On Fri, May 4, 2018 at 5:00 PM, Bob McDonald <bmcdonal...@gmail.com> wrote:
> 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
>
>
_______________________________________________
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
