Edge DNS Secondary Implementation: Order of Operatio ...

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 exclusivelydelegate zones to Edge DNS. This masks their primary nameservers from the public internet and implements transaction signatures (TSIGs) 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. 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, the nameserver responding to the query should be listed in its 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.

Zone File	Registrar
ns1.example.com ns2.example.com ns3.example.com	ns1.example.com ns2.example.com

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 Codeis becoming an increasingly popular means of executing these steps programmatically in order to reduce delays and manual touchpoints.

For the interim period when the Akamai nameservers are only listed in the zone file, and not yet listed with the registrar (example below), a percentage of DNS queries will 'leak' to Edge DNS even if the delegation records are not sending any DNS traffic to Akamai.

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 beforeadding 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.

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).

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 Enterprise Threat Protection (ETP) 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 developers.akamai.com

Questions about DNS?Contact usto 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.