Home » Security Bloggers Network » Fast DNS Secondary Implementation: Order or Operations for NS Zone & Registrar Records

Fast DNS Secondary Implementation: Order or Operations for NS Zone & Registrar Records

by Sam Preston on May 6, 2019

Akamai’s Fast DNS service provides cloud-based, authoritative domain services to thousands of organizations. Fast DNS is the most widely deployed cloud DNS service pushed to the edge of the Internet. Every organization must protect their domain name. Akamai’s built Fast DNS to focus on domain name availability, security, resiliency, and performance. The domain name must be 100% available at all times. These domain names must be secured with DNSSEC to minimize spoofing. DoS attacks cannot be allowed to knock down the domain names. Clients who are trying to get to the domain must be able to get that information as fast as possible. DNSSEC, DoS resiliency, and global performance are all provided by Akamai’s Fast DNS Service.

Benefits of a Secondary DNS Server

Using Fast DNS as a secondary DNS service is one of the quickest ways for organization ease into the benefits of a globally robust cloud DNS solution. Secondary DNS servers are a layer before the DNS Primary. The DNS Primary servers control the domain’s zone records. These can be configured to push the zone information out to secondary DNS servers. The whole architecture can be configured where the Internet only communicates with the DNS secondary servers. This protects the critical Primary DNS server and zone information from attack.

Pushing Secondary DNS to the Edge of the Internet

Akamai’s Fast DNS streamlines the Secondary DNS’s benefits. Organizations can plug into Akamai’s global DNS deployment and push their DNS Secondary to a global edge deployed throughout the world. The Secondary DNS’s benefits are then enhanced, with DNS servers closer to the edge, spread throughout the world, and resiliently deployed. Closer to the edge means better application response. Global deployment means it is more resilient to DoS attacks. Resiliently deployed means that Akamai shifts the organization’s domain to work around Internet faults.

Updating DNS Records to Begin Leveraging Fast DNS

One conundrum domain owners face is how to properly update their DNS records when they are ready to leverage Fast DNS as a secondary service. There are two steps that need to be executed:

Sponsorships Available

Update the domain’s zone NS records to include Akamai Fast DNS nameservers / remove any legacy nameservers

Update domain’s registrar’s delegation & ‘glue’ records to include Akamai Fast DNS nameservers / remove any legacy nameservers

There are a number of valid implementation strategies involving these two steps, but a few core principles should be incorporated into the go-live deployment plan:

A. While the IETF DNS spec does not provide clarity on the order of operations, it is recommended to list all authoritative name servers in your zone file at all times*. Consequently:

Any additions to the NS record set (e.g. adding Akamai nameservers) should be implemented in the zone file before the registrar’s records are updated
Conversely, any removals (e.g. removing legacy nameservers) should be implemented in the registrar’s records before the zone file reflects this change
Example of an acceptable and ill-advised zone file setup below:

B. While not recommended long term, the two recordsets can be different

There is no technical requirement concerning the timeliness/delay between addressing discrepancies, although ultimately the two recordsets should align, per the DNS specification
- Even if the domain owner wants to align the record steps ‘as fast as possible’, the registrar’s propagation timetable for updating their record sets is out of the domain owner’s control
For the time period (long or short) when the Akamai nameservers are only listed in the zone file (and not yet listed with the Registrar / visual example below), a percentage of DNS queries will ‘leak’ to Fast DNS even if the delegation records are not sending any DNS traffic to Akamai*

Consequently, the zone transfers need to be successfully setup before adding the Akamai nameservers to the zone file
The amount of traffic sent to Akamai will be determined by the length of the TTL associated with the authority records; the greater the TTL, the more traffic will go to Fast DNS
- There are other factors as well, such as whether the recursive resolvers are caching delegation records
Similarly, domain owners should NOT deprovision any legacy nameservers until they are removed from both record sets

Per RFC 1912: In order to prevent lame delegations while the cache is being aged, continue to provide nameservice on the old nameserver for the length of the maximum of the minimum plus refresh times for the zone and the parent zone.

C. 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 (i.e. add all Fast DNS nameservers at once) or a phased approach (add one or several Fast DNS nameservers at a time)

With these key principles in mind, the implementation steps will follow this high-level order of operations:

1.) Update zone file, add one, several, or all Akamai Fast DNS name servers (retain current name servers; i.e. additive change)

2a.) Update Registrar to add the same Akamai name servers referenced in Step 1

2b.) Remove legacy nameservers from Registrar’s NS records (if necessary***)

3.) Remove legacy nameservers from zone file (if necessary***)

Steps 1-2b will be repeated until the steady state is achieved with the Registrar.***

There are a number of different iterations, but the overall execution will follow this basic template. In addition, it is always best practice to reduce the TTLs for the zone file’s authoritative NS records during the implementation in case a rollback is needed.

*Recursive resolvers exhibit inconsistent behavior when there is a mismatch between the record sets between parent (Registrar) and zone. As a result, we want to avoid a situation where a resolver does not accept a response from a nameserver because it is not listed as authoritative in the zone file

**This is due to recursive resolvers caching practices: resolvers will cache NS records listed in a zone even if the resolver is only querying for an A record. Thus, future A record queries may be sent to a Fast DNS server.

***Domain owners may want to use another authoritative DNS provider alongside Akamai

Explore Akamai’s Diverse DNS Oriented Solutions

If you find this blog useful, continue your exploration with these references. Everything Akamai deploys depends on our Intelligent Edge DNS platform. Akamai expands our platform to enable a range of services for domain owners:

New White Paper – Designing DNS for Availability and Resilience against DDoS Attacks is a white paper that explains how Akamai deploys Fast DNS with multiple vectors of global resilience.
Achieve domain stability and resilience with Akamai Fast DNS service.
Load balance your data centers, cloud deployments, and CDNs with Akamai’s Cloud Based Global Server Load Balancing (GSLB) solution – GTM.
Massively 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 NOT malware, phishing, or a botnet. Akamai’s Enterprise Threat Protection (ETP) and DNSi/SPS solutions turn your DNS resolver into a security tool.
Sign-up and Search Akamai’s Community. This provides you access to a range of Akamai resources.
DevOps Professionals are welcomed to join developers.akamai.com. Akamai’s DNS solutions are API and DevOps aligned … enabling cloud to cloud innovation.