GTM Listener Hostname - Zonerunner NS Records

When you add a wide IP, you will most likely need an NS record delegating the wide-ip domain to the GTM so that all DNS queries for that domain will be handled by the GTM.

In the parent DNS server that delegates the new domain to the GTM, there should be a glue record (an A record) that points to the GTM, which the GTM uses as a floating self IP addr and a listener address for DNS queries.

You can then allocate this address or a different one (also a self IP addr) for your wide IP in you local DNS server on the GTM.

You need the NS record for the wide ip domain in the GTM's local DNS server as well.

"Wide IP" is a misleading name and should really be called "wide name", to my mind.

I think Josh is referring to the fact that when you create a wide ip in GTM configuration, it will automatically create a NS record for that domain using the hostname of the box. If you are not aware of this at the time you initially setup the GTM, you might end up using a hostname for that is tied to the management IP address in DNS. This of course results in an issue should anyone query your enterprise DNS servers for the NS records of that zone (the LDNS will cache the response from GTM and point the NS records at the management IP of the GTM which will timeout for all future requests if you are using CNAMEs for the wide ips).

Additionally, it seems in v10, the default behavior is to not synchronize the zone files between GTMs in the same sync group (whereas this was enabled by default in v9). As a result, if your LDNS queries GTM for type any or for the NS record, it will receive the single NS record that specific GTM had auto-created, reducing the high availability of GTM for that specific LDNS. To rectify, you must either enable synchronization of zone files in gtm configuration settings (under system), or manually create static NS entries to include the other GTM listener hostnames.

If your GTM deployment is using HA active/standby pairs (not best practice), this is further complicated by the fact that the floating listener address cannot be mapped to 2 separate A records, which means you must manually edit the NS records that were auto created in each GTM to point to the A record tied to that floating listener IP.

The 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.

I believe my situation is related. I am trying to figure out why the GTM keeps create an NS record for a zone with the Master Server being the local name of the GTM. We use our GTMs for external resolutions only, so having the local name resolvable when asking the zone for NS records is a security issue. I don't see a way to change it without deleting the Server records for each GTM in the pair. has anyone come across this before? Leaking DNS information??

Josh, did you manage to get this resolved? Looking at the same situation where we dont want to be authoritative for example.com: just vip.example.com which is delegated to the GTM.

One approach would be to edit the SOA and NS entries in Zone runner and point it to the authoritative NS/SOA. Have you tried that?