We are planning the integration between two F5 DNS in an Active/DR environment. The DNS of the active site is fully built, on the DR site there is no Primary DNS and no active DNS module in F5.
I understand that for domains/zones delegated to F5, IP resolutions for DNS query is not a problem because I can count on several balancing methods (Global Availability/Ratio/Virtual Server Score and etc...).
However, the vast majority of zones/domains are on a primary BIND nameserver, which will also be built into the DR datacenter to allow queries through its nameserver.
The DR datacenter should not receive any kind of DNS traffic while the active datacenter is available (including queries to the nameservers), and the reverse is also valid.
For this type of deploy, I would like to understand best practices to prevent the Primary DNS hosted in the DR datacenter from receiving DNS queries while the Active datacenter is operational.
I've considered conditional firewall rule creations for both sites, but I'm not sure it's the most elegant solution, and also know if when the nameserver query is rejected/dropped, the next available nameserver will be consulted (if the dns query goes to the Primary DNS DR and then got dropped will also go to the next nameserver available Primary DNS Active)
Why don't you use BIND as an authoritative stealth name server, and then xfer the DNS zones into the F5 GTMs using DNS Express. The F5s will respond to the queries and hide the master. If you have both GTMs part of the same sync group, the. both Prod and DR will have the same records and be ready for use.
Thanks for your reply, but transfer the zones to the F5 DNS is not at playrightnow so I have to use the same conditions that I already has at the active site..
Just to be clear, are you lord balancing DNS using LTM module, or using DNS module for GSLB and DNS screening or hosting? I will give some guidance for both scenarios:
- LTM: Just keep the respective VS or pool members disabled. Manually bring them up.
- GTM: Easiest way is upstream DNS records. Delegate to only Production GTM listener, and if you need to failover, the. modify this configuration to delegate to DR instead. Although, think you mention the DR F5 doesn't have the GTM/DNS module provisioned?
Finally, remember GTM uses a component of LTM under the hood. If you want to delegate to BOTH, but just receive responses from Production, then just manually down the LTM VIP used as the GTM/DNS listener. You can always enable it during DR recovery procedure.
My main question is about building the Primary DNS (which contains the authority for most zones and is not an F5) on the DR site. When the Primary DNS nameserver that will be positioned on the DR site is registered as a nameserver for zones not delegated to F5, it will receive queries that I would not like to happen because the prerequisite is not to send any traffic to the DR site while the active site is operational.
So in DR the F5 is not in play. The DNS server in question is external to the F5. You could block with firewall or switch level ACLs, you can put the DNS server behind the F5 and control access via up/down the associated Virtual Server you create, or just architect this more cleanly. Really sounds like Production and DR are configured way differently.
You may need to provide an architectural diagram if we are still not understanding your use case.
;; ANSWER SECTION: www.abc.com. 300 IN CNAME d2iwv1xxkqpmiz.cloudfront.net. d2iwv1xxkqpmiz.cloudfront.net. 21600 IN NS ns-1231.awsdns-25.org. d2iwv1xxkqpmiz.cloudfront.net. 21600 IN NS ns-1630.awsdns-11.co.uk. d2iwv1xxkqpmiz.cloudfront.net. 21600 IN NS ns-194.awsdns-24.com. d2iwv1xxkqpmiz.cloudfront.net. 21600 IN NS ns-760.awsdns-31.net.
So I got 4 nameservers that can answer as authoritative for www.abc.com
As far I understand, the OS will pick up an random nameserver (could be the DR primary DNS) and then try to get the IP for the requested domain, and I want to avoid it. So I want to disable or force the nameservers hosted at the DR site to no reply as authoritative while the Active site is up.
