DNS as Code

DNS as code

Traditionally, modifying a zone requires a number of manual steps, such as sending emails to registrars or logging into DNS providers’ web interfaces to perform a record update.

While this process may be adequate for ad hoc change requests, these steps lack transparency and repeatability, and simply do not scale. For example, maintaining records across multiple providers can be a time-consuming and risky undertaking — with a primary implementation in place, a single change will require repetitive manual touchpoints in several unique UI interfaces.

Depending on the scale of the application’s DNS footprint, DNS as Code and agile workflows can significantly ease the burden of DNS management. With a “code once and deploy everywhere” approach, developers can maintain source records in a centralized repository and propagate DNS updates in a deliberate, programmatic fashion using APIs. Thus, if a zone modification needs to be replicated across multiple providers, an update can be implemented once in a source file and deployed to all the pertinent nameservers simultaneously using automation servers.

Secondary implementations 

While a centralized code repository may help operations teams maintain multi-platform primary DNS implementations via automation, secondary implementations can achieve similar efficiencies without any specific DNS as Code technologies. With a secondary setup, zone transfers replicate updates from a primary nameserver to a collection of authoritative secondary nameservers that are ultimately responsible for responding to live DNS queries. In this way, a similar “code once and deploy everywhere” workflow is achieved without any CI/CD automation tools.

However, even with a secondary implementation in place, DNS as Code offers a myriad of other agile advantages that may persuade admins to adopt this approach. For one, traditional DNS software and third-party providers often lack fully fledged administrative and version control capabilities. Specifically, code repository software supports granular permission credentials, as users can be assigned the appropriate read/write access on a file-by-file (i.e., zone-by-zone) basis. These tools offer more in-depth version control features as well, including built-in review steps to ensure mistakes are not accidentally pushed to production. In addition, multiple users can draft and propose changes simultaneously, while legacy versions are always available for admins seeking historical reference.

Using Akamai’s Terraform integration to generate multiple host instances

From a deployment perspective, automation servers can assist with DNS unit testing and subsequent confirmation notifications. Liveness validation mechanisms can be cohesively incorporated into the compiling process to ensure new IP addresses are valid and responsive before a production push. Once DNS changes are successfully (or unsuccessfully) tested and deployed, these same servers can send emails to pertinent stakeholders to avoid tedious manual status checks. 

Simply put, third-party DNS providers do not typically offer such event-driven functionality out of the box, and any on-premise BIND implementations will require significant custom development work to achieve advanced version control and automated testing capabilities. In short, the DevOps tools that help optimize traditional website development workflows can improve DNS management as well — regardless of whether the website relies on a secondary or primary DNS implementation.

Delegation records 

Along with standard zone record management, DevOps technologies can assist with domain delegation changes, as most modern registrars now offer API support. Traditionally, adding new authoritative nameservers into rotation can be an operational headache since both the hosted zone file and the registrar’s records need to be adjusted to reflect this change. Without the assistance of APIs, the complexity of multi-party involvement complicates any attempt to execute these steps quickly and efficiently, so particular attention needs to be paid to the order of operations. However, with a code repository and automation servers, these updates can be orchestrated in a consistent and reliable manner, relieving the zone admin of painful uncertainty and burdensome project management tasks.

DNS as Code can automate the removal of nameservers as well. If a particular provider is experiencing reliability or latency issues, emailing the registrar to remove them from rotation can be subject to offline pitfalls during emergency situations. However, with an API-driven workflow, these changes can be performed (or rolled back) via automation servers without any cumbersome offline communication. More advanced implementations may incorporate continuous checks to validate DNS performance and programmatically remove problematic nameserver records.

Edge DNS and DevOps

Akamai’s Edge DNS includes a comprehensive DevOps suite to support a DNS as Code approach. The platform offers an open API, a simplified command line interface, and a Terraform provider to perform common Edge DNS tasks. These commands can be incorporated into pertinent automation servers or server-side scripts to perform programmatic zone file updates across the platform.

Along with API support, all zone file requests are propagated in less than five minutes. From a reliability standpoint, Edge DNS offers a 100% uptime SLA and unrivaled DDoS resilience. Thus, application teams can architect DevOps workflows with confidence that record updates will be reflected seamlessly and without interruption. 

Conclusion

Similar to client- and server-side code management, DNS as Code involves a number of technical considerations, especially if multiple providers are involved. Each platform may support unique, proprietary record types — for example, Edge DNS includes a zone apex mapping record to directly resolve top-level domains to an optimal Akamai IP. In this case, the source text file will most likely incorporate variables to successfully execute the “code once and deploy everywhere” approach. Similarly, any deployment scripts will need to account for the varying capabilities and nuances of each provider’s API.

While the initial implementation may require investment, DNS as Code offers many tangible benefits for application owners. If you have any questions about how Edge DNS can fit into your DevOps workflows, your Akamai representative would be happy to assist.

Explore Akamai’s diverse portfolio of DNS solutions

If you find this blog useful, continue your exploration using the below references. Everything Akamai deploys depends on the DNS technology embedded in the Akamai Intelligent Edge Platform. Akamai built on this to enable a range of services for domain owners:

• New White Paper — Designing DNS for Availability and Resilience Against DDoS Attacks explains how Akamai deploys Edge DNS with multiple vectors of global resilience

• Achieve domain stability and resilience with Akamai’s Edge DNS service

• Load balance your data centers, cloud deployments, and CDNs with Akamai’s Cloud-Based Global Server Load Balancing (GSLB) solution, Global Traffic Management (GTM)

• Scale your application with layer 7 load balancing with Akamai’s Application Load Balancing (ALB) Cloudlet

• Ensure every device in your network checks a DNS security tool, ensuring the domain name resolved is not malware, phishing, or a botnet — Akamai’s Secure Internet Access Enterprise and DNSi/SPS solutions turn your DNS resolver into a security tool

• Sign Up and Search Akamai’s Community provides you with access to a range of Akamai resources 

• DevOps Professionals are welcome to join our developer hub — Akamai’s DNS solutions are API and DevOps aligned, enabling cloud-to-cloud innovation

• Consider signing up for a 60-day free trial of Edge DNS and/or a 90-day free trial of Global Traffic Management

• Contact Akamai for help with your DNS questions.