The value of local and distributed DNS recursors.
Micron21 have a well-established network, built to support Australia's best data centre - the Micron21 Tier 4 Data Centre in Kilsyth, Victoria. With a 100% SLA guarantee for power and cooling, and a blended well protected network, your hosted application should be capable of remaining online indefinitely - shouldn't it?
Internet Service Providers (ISPs) tend to offer their own range of services to compliment IP transit - for Micron21 that means DDoS protection, ADS-m reporting tools, live netflows, and access to our DNS (Domain Name System) recursors. For the most part you don't ever need to consider these services - they passively improve the reliability of your business, and give you access to information to make informed decisions regarding your IP transit and network services.
In recent times, there has been a shift from using local DNS recursors - either the cluster you administer yourself, or the ones offered by your transit provider - to 3rd party DNS platforms such as Google Public DNS or Amazon's Route53. This thinking isn't necessarily correct. For many who are led down this false path, the decision is a simple thought process - from the need to downsize and dissolve the responsibility of maintaining a local cluster, to simply copying the default setting from an online guide. Micron21 would ask you :
Who is your DNS provider? What would happen to your application if your DNS stopped working?
If the answer contains "I don’t know” or “it shouldn’t”, then why? What measures has your DNS provider put in place to ensure that your application will always have access to their DNS recursors? Just because your application has internet connectivity through Micron21 and is online doesn't necessarily mean that a 3rd party DNS provider will be. If your application has access to the internet but the DNS resolvers aren't responding your application might be in for a world of discomfort.
Whilst everyone's applications are different, what's universally true for most businesses is that DNS recursors are a critical part of the infrastructure - and it is something that isn’t considered enough during fault redundancy planning. DNS has small moving parts, and it is a function that is easy to take for granted.
DNS is designed to be as redundant as possible by nature, with tertiary servers configured to respond if there are delays or problems contacting the primary - but failure scenarios start looking grim when the problem isn't a simple "available/unavailable" problem. For instance, we've seen issues where core networking problems closer to the 3rd party DNS provider have caused unusually long RTTs (Round Trip Times) due to a mistake with routing. This in turn led to improper responses from the Primary DNS server - not a failure the application was capable of handling. The result was a timeout for the application, and downtime for all the clients relying on that application. The routing problem at the upstream provider wasn't resolved for two hours, leading to brand damage and lost productivity during the period. Other possible uncontrollable events are fragmented UDP responses from the DNS provider, or zone information failure.
By comparison, Micron21's DNS farm exist as close to your network as you can possibly get without hosting your own cluster. We have a primary in the Kilsyth Data Centre, and tertiary name servers in Melbourne, Sydney and Los Angeles. We're also the host of a root DNS server for ICANN. With less in-between your application and the DNS recursors, there's less room for something to go wrong, and for any subsequent negative impact to your business.
Micron21's Recursive DNS Servers