Nimbostratus
NimbostratusThe way we remedied this issue (GTM v10.2) is to make it a best practice of using the GTM listener address hostname in enterprise DNS as the GTM device name (during setup). This ensures that the GTM NS records created in zonerunner will point to the same A records you have created in enterprise DNS, used in your delegation NS records:
GTM setup configured device names:
gtm1.company.com
gtm2.company.com
GTM listener address A records:
gtm1.company.com. IN A 10.1.1.4
gtm2.company.com. IN A 10.2.2.4
Enterprise DNS delegation for zone "gtm.company.com":
gtm.company.com. 7200 IN NS gtm1.company.com.
gtm.company.com. 7200 IN NS gtm2.company.com.
We discovered that when a DNS query is made for a wideip which is down, the GTM responds from ZoneRunner (if return to DNS or nothing is selected as alt/fallback method) because the GTM configuration does not have a valid answer. ZoneRunner using BIND, will respond with all A records configured for that wideip. Additionally, the response will also include the NS record for the zone as configured inside of ZoneRunner (this NS record is automatically created when you configure a wideip, and it points to its own device name as the A record data). It is in this condition that the NS record from GTM could overwrite (corrupt) the NS records used in your DNS delegation, if they are different. This is why we have adopted the practice of ensuring all GTM device hostnames are configured with the same hostname that is tied to the listener address in enterprise DNS (which is what your delegation NS records will point to). So now, when the GTM responds with its own NS record, it will overwrite what is in enterprise DNS, but it will overwrite it with the same information, preventing a potential outage.