|Migrated||gitlab-migration||T1178 Make Azure infrastructure independent from Rocquencourt|
|Migrated||gitlab-migration||T1179 Create an independent DNS resolver on Azure|
|Migrated||gitlab-migration||T1201 monitor DNS zones on primary/replica to ensure they stay in sync|
|Migrated||gitlab-migration||T1253 Generate correct SOA records for internal.softwareheritage.org.|
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
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
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.