Matt Larson recently wrote an article over at CircleID on LinkedIn’s use of managed DNS to direct traffic to a distributed service. Here at APNIC, we use both IP anycast and managed DNS, and this article will outline how we do it.
The reasons for distributing a service are usually based on scale: scale of demand, scale of reliability, or scale of performance. At APNIC, we have a reasonably large demand for our reverse DNS service, around 30,000 queries per second, so we distribute our DNS service to improve response time, to manage load, and to ensure responses can be delivered quickly.
Distribution of DNS service
We use two techniques for distributing our DNS service: multiple name servers in each zone, and IP anycast. Our IP anycast is again in two parts. We run a small deployment configuration in multiple locations, consisting of two service machines, one switch, and one router. All of the service machines across all of the locations offer their DNS service using the same IP address, and the magic of BGP ensures users of the service get their packets delivered to something which can answer.
This use of IP anycast is exceptionally robust. The service machines announce their routes to their local router, which only announces the route onwards to its upstream when it has at least one downstream active. If an outage occurs on a machine, traffic gets seamlessly and automatically directed to another node. If a router goes offline, BGP’s mechanisms for rerouting traffic direct local users to other sites.
We also use a partner provider of IP anycast DNS service as a backup to our own services, taking advantage of the economies of scale that can be applied when 30,000 queries per second is considered a small load.
Distribution of WHOIS service
Our WHOIS service is also distributed. The WHOIS service carries far less load than the DNS service (around 300 queries per second) but it’s often used by automated systems, and also needs to be highly available and responsive. When we designed the WHOIS distribution service, we considered another IP anycast deployment, but managed DNS has two main advantages that ultimately made it the better choice.
- Our distributed WHOIS system operates on virtual hardware in cloud data centres. For a small team of operators, avoiding the travel requirements that co-located equipment demands is a big win, and allows us to have service in more locations than we could otherwise. We don’t need to arrange for BGP connectivity in multiple locations, though we still need cloud providers with full IPv6 support.
- Managed DNS is an even simpler solution to deploy than IP anycast. IP anycast is robust, but requires careful and extensive monitoring to ensure all the parts are functioning appropriately. Managed DNS outsources that monitoring to the DNS provider and wraps the entire package up into a point-and-click web management system. The main work for us in this space was around ensuring that an individual service machine’s outage didn’t become a user-visible service outage, which is made a little harder for being the relatively uncommon WHOIS protocol.
Which is better?
This question comes down to scale. Managed DNS doesn’t require expertise in BGP and IP anycast and works well with other managed services such as cloud hosting. IP anycast is closer to the metal and, if you’re LinkedIn or of a similar scale, you probably need the greater control and flexibility that handling these services in-house offers.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.