kpfleming
commented
4 years ago I've just noticed this as well while considering upgrading my systems to use TSIG instead of hardcoded IP addresses. I think the current behavior makes sense, as it is completely symmetrical (it indicates explicit trust between the master, slaves, and any other clients who wish to AXFR/IXFR), but I could see the value in being able to control whether or not (or which) NOTIFY packets are signed.
in the meantime it appears that a suitable action would be to improve the docs to let the user know what the behavior is, and I'm happy to take a stab at that.
Use case: have a master sever that accepts AXFR request from a set of statically configured IP address and in addition also via a TSIG signed request.
This used to work with 3.x by setting a TSIG key in TSIG-ALLOW-AXFR. However, since 4.x any notifications for those domains are now signed with the TSIG key (as configured in TSIG-ALLOW-AXFR), but this results in the slaves that do not have the TSIG key configured in ignoring the notification. This seems undesirable (at least for this use case) and the documentation doesn't make it clear if TSIG-ALLOW-AXFR or AXFR-MASTER-TSIG is intended to be used for signing notifications.
Further discussion on the mailing list in:
possibly related to #3945 (which talks about the slave side)