How to *require* TSIG for NOTIFY

[Mark Andrews]

> On 15 Nov 2022, at 12:41, Jesus Cea <jcea at jcea.es> wrote:
> 
> Hi everybody,
> 
> I can configure my bind master to send TSIG in the NOTIFY messages, but I am not able to configure secondaries to *ONLY* allow NOTIFY with a valid TSIG.
> 
> In the slave zone config I have something like:
> 
> """
> zone "XXX" {
>  type slave;
> ...
>  allow-notify { key "KEY_TSIG"; };
>  masters {
>    IP;
>  };
> };
> """
> 
> The slave accepts the NOTIFY coming from "IP" (the master IP address), in both cases, with TSIG and with no TSIG. That is, it seems like ips listed in "masters" are not required to TSIG at all.
> 
> The log shows this fact:
> 
> Master configured with TSIG:
> 
> """
> 15-Nov-2022 01:48:50.961 notify: info: client @268b268 IP#57901/key_tsig: received notify for zone 'XXX.local': TSIG 'key_tsig'
> """
> 
> Master configured with no TSIG:
> 
> """
> 15-Nov-2022 02:15:30.701 notify: info: client @4074268 IP#32138: received notify for zone 'XXX.local'
> """
> 
> So, I can control whenever the master send notifies with and without TSIG,  but slaves just don't care to verify it (if the notify comes from a "masters" source).
> 
> Checking documentation around, I read this:
> 
> """
> allow-notify applies to slave zones only and defines a match list, for example, IP address(es) that are allowed to NOTIFY this server and implicitly update the zone in addition to those hosts defined in the masters option for the zone. The default behaviour is to allow zone updates only from the masters IP(s). This statement may be used in a zone, view or global options clause.
> """
> 
> It seems that whatever I specify in "allow-notify", "masters" are always allowed to notify without TSIG.
> 
> Given that NOTIFY is UDP and source spoofing is so easy, I would like to be able to *REQUIRE* TSIG even for "masters".
> 
> Is this something I can configure in bind? Is this something unrealistic/too paranoid for my own good?

NOTIFY is a hint for the secondary to perform a SOA refresh query sooner than the SOA query triggered by REFRESH and RETRY.  Those queries are rate limited.  Additionally multiple notify messages often coalesce
into one action as the server is waiting to send or is waiting for responses when they arrive.

While I don’t see the need, adding an 'allow-notify-explicit <bool>;’ could be added to ignore the primaries
list and only use the allow-notify acl.

Mark

> Thanks.
> 
> -- 
> Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
> jcea at jcea.es - https://www.jcea.es/    _/_/    _/_/  _/_/    _/_/  _/_/
> Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
> jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org