NOTIFY and TSIG

[Mark Andrews]

You use TSIG when transferring a zone to ensure you are talking to a valid primary.
Spoofed NOTIFY messages where accounted for when NOTIFY was developed.  The server
will protect itself from spurious NOTIFY messages by rate limiting.  Now if you are
using views you can use TSIG to select the correct view and hence zone instance, to
deliver the NOTIFY to.

> On 9 Jan 2024, at 14:40, Nick Tait via bind-users <bind-users at lists.isc.org> wrote:
> 
> Hi list.
> I've been trying to understand whether it is necessary for the NOTIFY request (i.e. sent from primary to secondary server) to use TSIG, in the case where the secondary server specifies a key in its zone's "primaries" option?
> For example, assume the following set-up:
> The primary server (192.0.2.1) specifies the following configuration:
> key "secret-key.example.com" { ... };
> zone "example.com" {
> type primary;
> file "/etc/bind/db.example.com";
> notify yes;
> allow-transfer { key "secret-key.example.com"; };
> };
> 
> And the secondary server (192.0.2.2) specifies:
> key "secret-key.example.com" { ... };
> zone "example.com" {
> type secondary;
> file "db.example.com";
> primaries { 192.0.2.1 key "secret-key.example.com"; };
> notify no;
> };
> 
> And if the zone file db.example.com (on the primary server) contained:
> $TTL 3600
> @ IN SOA server1 root.server1 1 86400 7200 2419200 1800
> @ IN NS server1
> @ IN NS server2
> server1 IN A 192.0.2.1
> server2 IN A 192.0.2.2
> 
> In this case when the zone is changed on the primary server, it will send an unsigned NOTIFY to the secondary server. The question I was trying to answer was: With the configuration above, will the secondary server accept the unsigned notification?
> I was hoping to find an RFC that answered this question, but didn't have any luck Googling. However the BIND documentation for "allow-notify" (https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-allow-notify) contains the following text:
> allow-notify
> ...
> Defines an address_match_list that is allowed to send NOTIFY messages for the zone, in addition to addresses defined in the primaries option for the zone.
> ...
> If not specified, the default is to process NOTIFY messages only from the configured primaries for the zone. allow-notify can be used to expand the list of permitted hosts, not to reduce it.
> My interpretation of the above was that if a key is specified in the "primaries" option, then the secondary would require the NOTIFY to be signed by the same key? However when I tested this theory, I found the secondary did accept (and process) the unsigned NOTIFY.
> While I understand (and agree) that this behaviour makes the most sense, given my confusion based on the documentation, I wonder if the documentation could be made clearer? E.g. Add the sentence: "In the case where the primaries option specifies a TSIG key, it is not necessary for the received NOTIFY to be signed by the same key."
> Thanks,
> Nick.
> -- 
> 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