bind dns zone notify with multiple view

I experienced some difficulties with zones from what should have been an internal view (with RFC1918 addresses plus public IPv6) leaked to the external view (public IPv4 plus public IPv6). I think I pinned it down to where I had notify explicit on the master, but not on the slave. I think that resulted in the slave somehow notifying itself (as I could see a notify coming from it's own IPv6 address resulting in internal zones somehow transferred to the external. I left some test records over night with a dummy host name and a different nonsense IP on the internal view and external view. I verified today that clients are seeing the correct response so far.

However, the zone logs show that it is always the external view reported being updated, even though both zones are returning appropriate data. The result below is the log after changing the internal view zone on the master and running systemctl reload named:

master showing zone notify from internal (looks good)

28-Jan-2023 10:24:59.831 general: info: reloading configuration succeeded
28-Jan-2023 10:24:59.833 general: info: reloading zones succeeded
28-Jan-2023 10:24:59.835 zoneload: info: zone host.example.org/IN/internal: loaded serial 2023012851
28-Jan-2023 10:24:59.839 notify: info: zone host.example.org/IN/internal: sending notifies (serial 2023012851)

and here is the corresponding log on the slave (shows notify for external zone)

28-Jan-2023 10:24:59.841 notify: info: client @0xabcdef 192.168.240.12#35167: view external: received notify for zone 'host.example.org'
28-Jan-2023 10:24:59.841 general: info: zone host.example.org/IN/external: notify from 192.168.240.12#35167: serial 2023012851

clearly the internal zone notify was sent from the master, but the external zone on the slave received the notification.

I seem to have very similar issues to this:

BIND Zone Transfer with two views

I have reviewed this question, which is somewhat related as it deals with notifies and multiple views:

Bind notifies on DNS views

I have reviewed this question, and it might be relevant:

Zone transfers on a split-view Bind DNS system

and this:

BIND zone also-notify syntax

Here is my zone notify on the master:

also-notify { 192.168.240.11; };
allow-transfer { key keytransfer; };

and on the slave:

masters { 192.168.240.12 key keytransfer; };

I've seen other posts using a tsig key unique to the internal zone and one for the external zone (again...this guy BIND Zone Transfer with two views), but I still had issues and thus eliminated that part of the configuration. I'm in the process of trying it again with the help of this:

https://kb.isc.org/docs/aa-00296

update 1 Okay, so I implemented the following for my views and it seems to be working as intended and I'm seeing appropriate notifies in the logs:

view "internal" {
    match-clients   { !key keyexternal; key keyinternal; private_nets; };

and

view "external" {
    match-clients   { !key keyinternal; key keyexternal; any; };

do I need other changes before I attempt to load my full internal zone again?

When using views in BIND9, any given incoming DNS message (query, notify, update, zone transfer, whatever) will simply hit the first view that matches based on the match-clients, match-destinations and match-recursive-only settings of the views that you have defined. There is no inherent concept of "same view".

Your TSIG-based solution with one key created to represent each view and matching based on a !key otherview1; !key otherview2; key thisview; ...-style setup should do the trick as long as you make sure that all "maintenance" operations use TSIG-signed messages using the key corresponding to the relevant view. (Signed notify, signed zone transfer, etc.)