SBN

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.

IMG_0126.jpeg

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.

 

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

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.

*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Sam Preston. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/cyS_xoEOJaY/edge-dns-secondary-implementation-order-of-operations-for-ns-zone-and-registrar-records.html