Edge DNS Secondary Implementation: Order of Operations for NS Zone and Registrar Records
This article has been updated to include recent industry trends and information about primary implementations.
Akamai Edge DNS service delivers edge-based, authoritative domain services for thousands of organizations. These organizations trust Edge DNS to deliver reliable and performant responses, reflected by a 100% uptime service-level agreement. Along with unmatched reliability, Edge DNS boasts an impressive geographically diverse footprint and an intelligently deployed anycast network, ensuring client queries are consistently routed to a nearby nameserver in an efficient manner. From an operations perspective, Akamai offers administrators the flexibility to leverage Edge DNS as either a secondary or primary provider, as well as the option of implementing DNSSEC to protect against DNS forgery and manipulation.
Secondary DNS
In secondary mode, zone administrators establish zone transfers from their primary nameservers to Akamai.
This model allows domain owners to continue to rely on their existing provider for record management, while leveraging the Edge DNS network to reliably respond to end-user queries. For a heightened security posture, domain owners can mask their primary nameservers by exclusively delegating zones to Edge DNS. Transactional signatures (TSIGs) can also be implemented to authenticate zone transfers.
Secondary onboarding: updating nameserver and delegation records
One conundrum DNS administrators encounter is how to properly update their record sets when they're ready to onboard a zone to Edge DNS in a secondary model. Specifically, the order of operations for updating the zone's NS records and the domain registrar's delegation records can be a source of precarious uncertainty during the transition since the primary and secondary zones will advertise identical NS records via axfr calls. Although there are a number of valid implementation strategies involving these two steps, a few core principles should be incorporated into the deployment plan.
1. While the IETF DNS spec doesn't provide clarity on the order of operations, certain resolvers may reject a response if the queried nameserver is not listed as authoritative in the zone file's NS records. Consequently, any additions to the NS record set (e.g., adding Akamai nameservers) should be established in the zone file before the registrar's records are updated; conversely, any removals should be reflected first in the delegation records. Examples of an acceptable and an ill-advised zone file setup can be found below.
| Acceptable Zone File | Registrar |
| ns1.example.com ns2.example.com ns3.example.com |
ns1.example.com ns2.example.com |
| Problematic Zone File | Registrar |
| ns1.example.com ns2.example.com |
ns1.example.com ns2.example.com ns3.example.com |
2. While not recommended long term, the two record sets can temporarily advertise different values, and there is no IETF-defined technical requirement concerning the timeliness/delay to address such discrepancies. However, the two record sets should ultimately align in the steady state, per the DNS specification. As a result, DNS as Code is becoming an increasingly popular means of executing these steps programmatically in order to reduce delays and manual touchpoints.
During the interim period when the Akamai nameservers are only listed in the zone file, certain resolvers will cache the zone's NS records even if another record type is being retrieved. As a result, a percentage of DNS queries will "leak" to Edge DNS even before the delegation step is performed:
| Zone File | Registrar |
| ns1.example.com ns2.example.com a12-65.akam.net a13-65.akam.net a2-64.akam.net a3-64.akam.net a4-65.akam.net In this scenario, a certain percentage of DNS traffic will be directed to Edge DNS. |
ns1.example.com ns2.example.com |
Consequently, zone transfers need to be successfully established before adding the Akamai nameservers to the zone file. The amount of traffic sent to Akamai will be determined by the length of the NS records' time to live (TTL). The greater the TTL, the more traffic will be directed to Edge DNS. Similarly, domain owners should NOT deprovision any legacy nameservers until they're removed from both record sets and the pertinent TTLs have expired.
3. The domain owner can add as many or as few of the Akamai nameservers as they see fit for each record update. Thus, the domain owner has the option to execute a hard cutover (add all Edge DNS nameservers at once) or a phased approach (add one or several Edge DNS nameservers at a time).
Secondary implementation steps: order of operations
With these key principles in mind, the implementation steps will follow this high-level order of operations:
1. Update zone file and add one, several, or all Akamai Edge DNS nameservers (retain current nameservers; i.e., additive change).
| Zone File | Registrar |
ns1.example.com ns2.example.com a12-65.akam.net a13-65.akam.net a2-64.akam.net a3-64.akam.net a4-65.akam.net To reiterate: Some DNS traffic will be directed to Edge DNS after this step is executed. |
ns1.example.com ns2.example.com |
2a. Update registrar to add the same Akamai nameservers referenced in step 1a.
| Zone File | Registrar |
| ns1.example.com ns2.example.com a12-65.akam.net a13-65.akam.net a2-64.akam.net a3-64.akam.net a4-65.akam.net |
ns1.example.com ns2.example.com a12-65.akam.net a13-65.akam.net a2-64.akam.net a3-64.akam.net a4-65.akam.net |
2b. Remove legacy nameservers from registrar's NS records (if necessary / a mixed delegation model is also supported).
| Zone File | Registrar |
| ns1.example.com ns2.example.com a12-65.akam.net a13-65.akam.net a2-64.akam.net a3-64.akam.net a4-65.akam.net Some DNS traffic will be directed to the legacy DNS infrastructure even after this step is executed since the legacy nameservers are still listed in the zone file. |
a12-65.akam.net a13-65.akam.net a2-64.akam.net a3-64.akam.net a4-65.akam.net |
3. Remove legacy nameservers from the zone file (if necessary).
| Zone File | Registrar |
| a12-65.akam.net a13-65.akam.net a2-64.akam.net a3-64.akam.net a4-65.akam.net |
a12-65.akam.net a13-65.akam.net a2-64.akam.net a3-64.akam.net a4-65.akam.net |
There are a number of different iterations, but the overall execution will follow this basic template. In addition, it's always best practice to reduce the TTLs for the zone file's authoritative NS records during the implementation in case a rollback is needed.
Primary implementations
While the above principles also hold true for a primary implementation, the Edge DNS zone records can be edited independently in a primary model, which alleviates the underlying order of operations concern. Each provider simply needs to list themselves as authoritative in the zone's NS records during the transition period.
| Edge DNS Zone File | Legacy Zone File |
| a12-65.akam.net a13-65.akam.net a2-64.akam.net a3-64.akam.net a4-65.akam.net |
ns1.example.com ns2.example.com |
Just like with a secondary implementation, the delegation records should ultimately match the NS records of the zone once the onboarding process is complete; therefore, all providers' zones in a mixed delegation model should advertise the same NS records in the eventual steady state. And, as with any implementation, Akamai's professional services team should be consulted to assist with any additional nuances involved with your Edge DNS implementation.
Summary
- When Akamai is implemented as a secondary DNS provider, zone transfers are established from their primary nameservers to Edge DNS, which allows domain owners to continue relying on their existing provider for record management, while leveraging the Edge DNS network to reliably respond to end-user queries
- The zone administrator needs to consider the order of operations of updating the zone's NS records and the registrar's delegation records during the initial deployment onto Edge DNS as a secondary provider
- A nameserver responding to a query should always be listed as authoritative in its zone file's NS records; therefore, during the initial implementation, any additions to the NS record set should be reflected in the zone file before the registrar's delegation records are updated -- conversely, any removals should be reflected first in the delegation records
- DNS as code has become a popular approach to programmatically execute these updates to reduce delays and manual touchpoints
- Primary implementations share the same onboarding principles, but the transition phase is simplified since each provider zone can be edited independently
Explore diverse DNS-oriented solutions
Everything Akamai deploys depends on our intelligent edge DNS platform, which expands to enable a range of services for domain owners. If you find this blog useful, continue your exploration with these references.
- Learn how Akamai deploys Edge DNS with multiple vectors of global resilience in the "Designing DNS for Availability and Resilience Against DDoS Attacks" white paper
- Achieve domain stability and resilience with Akamai 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)
- Massively scale your application with layer 7 load balancing with Akamai's Application Load Balancer (ALB) Cloudlet
- Turn your DNS resolver into a security tool with Akamai's Secure Internet Access Enterprise and DNSi/SPS solutions
- Sign up for and search the Akamai community to access a range of Akamai resources
- Akamai's DNS solutions are API- and DevOps-aligned to enable cloud-to-cloud innovation, and DevOps professionals are always welcome to join our developer community.
Questions about DNS? Contact us to receive help from Akamai Technical Support.
Copyright 2021by Akamai Technologies, Inc. All Rights Reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system or translated into any language in any form by any means without the written permission of Akamai Technologies, Inc. While every precaution has been taken in the preparation of this document, Akamai Technologies, Inc. assumes no responsibility for errors, omissions, or for damages resulting from the use of the information herein. The information in these documents is subject to change without notice.
