NOTIFY and TSIG

[Nick Tait]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240109/c4b8fafb/attachment.htm>