I’m sure it’s no surprise that Secondary DNS Implementations have been on the rise with the increasing amount of Distributed Denial of Service, or DDoS attacks happening across the internet. Why wouldn’t you want to have an additional layer of resiliency for your website, right?
While having Secondary DNS is a best practice that we highly recommend here at Dyn, it can pose some difficult decisions for companies that are also utilizing our Advanced Traffic Steering Features. Advanced Features such as Active Failover and Traffic Director allow you to optimize performance for your end users by monitoring your end point and steering traffic appropriately.
Within Dyn there are a few ways that you can configuring a Secondary DNS Provider alongside Advanced Features. So the question becomes, how can you take advantage of both the resiliency of Secondary DNS and the performance of Advanced Features? Have no fear, Active Failover is here!
The great thing about our Active Failover Service is that you will have a Primary IP address within the Zone, and when that zone is XFR’d or transferred to your Secondary Provider, the Primary Address, will simply transfer over as a vanilla A Record.
In the event that our Health Monitoring detects that this Primary Address endpoint as down, we will put the service into failover, and begin to serve the backup address. After this failover event occurs, it will trigger a ‘NOTIFY’ within the zone, to notify your Secondary DNS Provider, that there has been a change. This will then trigger an XFR to occur, which will update the A Record for your failover domain, to serve the backup address. Once the service returns to a Healthy State, the same process will occur to allow the Primary Address to be updated with the Secondary Provider again. This will ensure that all of your end users, regardless of which DNS Provider they are hitting, will be served an up to date DNS response.
If you are utilizing our Traffic Director Service, there are two plans of attack you can take. The first attack would be to utilize the benefit of Parent/Child Zones. Let’s say that you have a zone of ‘testing123.com’, and on the subdomain ‘child.testing123.com’ there is a Traffic Director Service geo-load balancing the incoming queries. With our Traffic Director Service there is a geo-mapping that happens behind the scenes. You can see when adding a Traffic Director Service that there are ‘nodes’ added below the domain name you are attaching to your Traffic Director Service. These additional nodes assist with the mapping of our geo-load balancing. You can see these additional nodes in the screenshot below:
When configuring a Secondary Provider these nodes are what cause difficulties with XFR transfer. They will not map over directly, and be able to be interpreted by the Secondary DNS Provider in the same manner that our Database uses them to geo-load balance. Therefore, you are unable to directly XFR a zone that has Traffic Director on it.
In order to work around this, we recommend that you create a ‘Child Zone’ for the node which currently is utilizing Traffic Director. If you are utilizing Traffic Director on the apex of your zone, we recommend placing the Traffic Director Service on a subdomain and redirect or utilize an ALIAS record to point the apex to a subdomain.
When you are going to create the Child Zone, I would recommend adding a ‘wildcard’ node, and adding your fallback record from your TD service to the wildcard as an A Record. This will allow all queries to still have a response, while you are configuring the Child Zone.
The first step in creating the Child Zone is to unlink the attached domain from your TD Service. This will leave the empty node or subdomain in the Parent Zone. During this time, any queries for the sub-domain that you removed Traffic Director from, will be answered by your wildcard node.
To create a ‘Child Zone’ you will need to take the subdomain you are working on and create it as a new zone within your account and do not publish the zone. If you need assistance with how to create zones, you can utilize this guide: https://help.dyn.com/how-to-create-your-first-zone-video/
In the screenshot below, you will see that I have create ‘child.testing123.com’ as my a new ‘Child Zone’:
This zone will function as its own DNS entity from the parent zone now. Next, you will want to go into the child zone and attach the desired Traffic Director Service. Once you have attached the Traffic Director Service, you will want to publish the Child Zone.
When creating the Child Zone, we will automatically put your four nameserver records into the subdomain within the Parent Zone. It will look like this:
One the Child Zone is created and the Traffic Director is attached, you will be able to configure Secondary DNS for the Parent Zone. This will allow the Parent Zone to transfer over, and the Child Zone will remain with the Traffic Director Service. The Child Zone will not be able to have Secondary DNS configured. Here is our help guide on how to configure Secondary DNS: https://help.dyn.com/using-external-nameservers/
The last option to utilize Secondary DNS and Advanced Features would be to find a provider that has Feature Parity to our Advanced Traffic Steering Features. If you are able to find a provider that has a similar geo-load balancing service to our Traffic Director Service, you can run a Primary-Primary configuration.
In a Primary-Primary configuration, you will have two Primary Zones, one with each provider. We recommend having one ‘source of truth’ where all of your changes are made. Then, you would need to integrate the backend API’s for each provider with your internal systems to allow any changes made within your one source of truth to be populated to the other provider as well. Here are a few getting started guides for our Managed DNS API: https://help.dyn.com/dns-api-guide/ https://help.dyn.com/rest-resources-by-topic/
Variety is the spice of life, and in an ever-changing internet world, we all need to optimize our back end infrastructure for resiliency and performance. Why not have the best of both worlds?