https://salsa.debian.org/dsa-team/mirror/dsa-nagios/blob/master/dsa-nagios-checks/checks/dsa-check-soas seems to be doing what we want

example usage:

olasd@pergamon:~$ ./dsa-check-soas internal.softwareheritage.org -v -a ns0.euwest.azure.internal.softwareheritage.org
Getting A record for nameserver pergamon.internal.softwareheritage.org for internal.softwareheritage.org
Addresses for nameserver pergamon.internal.softwareheritage.org for internal.softwareheritage.org: 192.168.100.29
Getting A record for nameserver ns0.euwest.azure.internal.softwareheritage.org for internal.softwareheritage.org
Addresses for nameserver ns0.euwest.azure.internal.softwareheritage.org for internal.softwareheritage.org: 192.168.200.22
Testing nameserver pergamon.internal.softwareheritage.org for internal.softwareheritage.org
 Nameserver pergamon.internal.softwareheritage.org is at 192.168.100.29
 Nameserver pergamon.internal.softwareheritage.org returns serial 167 for internal.softwareheritage.org
Testing nameserver ns0.euwest.azure.internal.softwareheritage.org for internal.softwareheritage.org
 Nameserver ns0.euwest.azure.internal.softwareheritage.org is at 192.168.200.22
 Nameserver ns0.euwest.azure.internal.softwareheritage.org returns serial 167 for internal.softwareheritage.org
internal.softwareheritage.org is at 167

In T1201#22425, @ftigeot wrote:

Right now, the internal.softwareheritage.org zone contains only a single NS record. This is most likely also the case for the various reverse zones.
There is no explicit notification directive in the master server configuration either.

There is no warranty internal.softwareheritage.org zones served by pergamon and ns0.euwest.azure will always be the same in this situation.

Wow, yeah, that's a very bad oversight on my part!

I feel like adding the azure nameserver to the NS records is the most sensible option.

Currently NS records are handled by manually adding records to data/defaults.yml; That's been done so well that when I added the reverse zones for azure, I didn't add any NS records...

Considering this, the records should probably be automatically generated by the profile::bind_server::primary class, from a list of expected nameservers in data/defaults.yml

Correct me if I am wrong, but I do not believe the current Puppet code has the ability to handle more than one NS record per zone.
At the very least, I couldn't find an obvious way to add such a record.

DNS resource records as defined by the inkblot/bind module can contain lists of values. I've implemented the missing bits in rSPSITE8dc5ab46 and rSPSITEb550b4fa.