MultiDNS Architecture with OctoDns
Infrastructure as Code(IAC) has found widespread appeal because of the introduction of powerful new tools like Terraform and CloudFormation, but did you know that the same concepts used to programmatically deploy servers can be used to manage DNS records?
What is a DNS record?
DNS stands for Domain Name System, and it allows the internet to function by routing requests to names like Google or Facebook to a corresponding IP(Internet Protocol) address. When you make a request through a web browser for a website like Amazon, a server called a DNS resolver makes a series of queries through other increasingly privileged DNS servers until it receives the correct IP number for the requested address. Through a DNS service, like Route53 or CloudFlare, you can request to effectively own addresses to use for hosting your own services.
BIND Format
Unfortunately, while different DNS services are very similar in how they handle and store DNS records, they are not the same. The central language used to store and transfer these DNS records is called BIND(Berkeley Internet Name Daemon) Format in the form of zone files. By exporting your records into BIND zone files, you are able to move between different DNS providers as your needs change or you move the rest of your stack. Once you have exported your records, most providers will usually have an import tool that will guide you into converting it into their own provider specific format.
DNS Uptime
DNS providers are extremely proficient in keeping your DNS records resolving so that their servers and your corresponding business transactions are not limited. The most proficient uptime currently reported according to the absolutely amazing DNS analytics site dnsperf is 99.98%, which sounds exceptional in most contexts! The problem is that in the world of computing and ecommerce, 99.98% uptime over the course of a corresponding year still results in almost two hours of downtime. SLA’s(Service Level Agreements) for especially important software might require different “nines” of uptime such as 99.999% or even 99.9999% uptime! This is even including the fact that there are many more sources of disruption than just DNS records, which then begs the question of how to meet increasingly high uptime standards.
MultiDNS Architecture
The core premise of MultiDNS Architecture is very simple: use multiple providers so that in the case that one organization fails to provide service that another may be signaled to take its place. There are multiple different configurations for how the DNS providers reference one another in this format. By the most common is called Primary/Secondary, where the Primary DNS provider with control of your domain record copies its changes to the secondary provider. This solves the issue inherent in a single provider by almost eliminating downtime completely with as little as two different providers, but also introduces new issues. The first is paying for multiple providers in the first place, which luckily becomes a relative nonfactor because DNS providers cost so little compared to the costs of running servers or data storage. Another, harder to solve problem is that altering DNS records, which was once a very simple process, now has to account for increased complexity. Record drift, different formats, domain ownership, and deploying changes simultaneously across multiple different providers now all become major concerns. Luckily, there is a single powerful tool that manages to a great extent solve these problems.
OctoDNS
OctoDNS allows you to mimic powerful Infrastructure as Code practices and apply them in the exact same way to DNS records across a MultiDNS architecture. OctoDNS uses yaml files to indicate the zone files you wish to export, the target providers you push new changes towards, and configurations for credential files unique to each provider. From these yaml files, which can be stored and version controlled like all other types of code, you can push your changes across any number of different providers with small effort. Much in the same way that Terraform is agnostic of cloud providers like Amazon Web Services, octoDNS allows you to become agnostic of DNS providers like Route53. This entails huge benefits even outside of a multiDNS architecture, as now the zone file you use becomes the de facto source of truth for future configurations, encouraging developers to be more familiar with the BIND format that underpins all DND records.
Even better, you can use octoDNS to dry run your DNS record changes before they are live to catch errors before they have critical impact on business operation. Perhaps the only major drawback is that all of these features depend on using supported providers, which can be found here. This is of minimal concern, however, as you will find that practically all major DNS providers are already supported and will require no effort to onboard.
Should your company use MultiDNS architecture? Should you use octoDNS?
In most situations if your company does not adhere to strict uptime requirements and would not be significantly impacted by a few hours of downtime per year, I would honestly suggest against MultiDNS architecture. It is a system that inherently introduces complexity and cost to reduce downtime. On the other hand, in the case that downtime absolutely needs to be reduced, then there is no better alternative! OctoDNS, on the other hand, is a wonderful tool that I recommend to everyone managing DNS records for themselves or on behalf of others. In my own practice I have used octoDNS to route requests through multiple cloud providers in this programmatic fashion with spectacular results, reaching previously impossible levels of DNS uptime with far superior visibility of our record state. DNS is just as crucial as the servers it connects to, and being able to programmatically manage your records inherently leads to a far more robust and documented DNS strategy. I am still amazed that no other tools have come close to fulfilling the same niche as octoDNS, and even now the project is frequently updated. If you have any questions or concerns, please feel free to reach out to me on Linkedin, or contact me at hello@rogueethic.com!