Do you have the need for Active Failover or another DynECT Managed DNS advanced feature but can’t delegate your entire zone to Dyn? Have no fear, cut nodes are here!
Cut nodes allow you to keep the DNS for your zone with your current DNS provider, but point or cut a specific node over to Dyn’s nameservers, allowing you to use one of our advanced features.
How Does It Work?
With a standard zone configuration, the entire zone is hosted with one DNS provider. This means that any type of request (A, MX, CName, TXT, etc.) for the domain name is going to be resolved by the authoritative nameservers for the zone. For example, if you look up which nameservers that dyn.com is pointed to, you will see that it is using ns1.p01.dynect.net, ns2.p01.dynect.net, ns3.p01.dynect.net, and ns4.p01.dynect.net.
However, what if you have one specific node that you want hosted on other nameservers? That’s where cut zones come into play.
Let’s say your domain name example.com is hosted with another DNS provider and you are under contract or are required to have your DNS with that provider, but you need Active Failover on a specific node like vpn.example.com. What you could do is setup Active Failover with Dyn for vpn.example.com and then cut vpn.example.com over to Dyn’s nameservers.
More specifically, you would need to contact your current DNS provider and setup ns records on the node that you want to cut over. Continuing with the example of vpn.example.com, you would setup these ns records on that node with the DynECT nameservers designated for your account.
Do All DNS Providers Support This?
Not all DNS providers support the cutting of a node to other nameservers. However, this practice is becoming more and more common, so most do. Please contact your current DNS provider to find out if this is something they will allow. Some providers refer to this as delegating a node or sub domain, so it is always good to make sure you and your provider are always on the page in terms of the terminology being used.
Are there any negative affects or downsides to this method?
Using this method is not exactly the same as having your entire zone hosted on Dyn’s nameservers. A cut node does have increased latency. This is a result of the extra hops that are required to resolve the node. When a request is made for the cut node, it is still initially resolved by the authoritative nameservers for the zone.
However, the authoritative nameservers for the zone will then relay the request onto Dyn’s nameservers to provide the response for the request. The added hops will increase latency, although they are very rarely noticeable to the end user. With that being said, if minimizing latency is important to you, hosting the entirety on Dyn’s Anycast nameserver-based DynECT platform would be your best option.
It is also worth noting that in the cut node scenario, you are relying on the authoritative nameservers the zone is hosted on to be resolving properly. If those nameservers were to become unavailable and stopped responding to requests for your zone, your cut node would not resolve either. The last thing to mention is that a cut node is still cached by resolvers, as long as those ns records haven’t timed out.
Are there any alternatives that will work in a use case like this?
To generate optimal response times, delegating your entire zone to a provider like Dyn is best. This eliminates the need for a second round of nameservers to be used to resolve the request and also minimizes latency. However, if this isn’t an option, the using of a CName is another option. With this method, you can setup failover or an advanced feature on a node that you have hosted on DynECT and then CName the node you want to have that advanced feature on to the node the advanced feature is setup on.