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

2019-05-06T16:00:00
ID AKAMAIBLOG:2CF37A62AA830284F49F29A2E4BFC243
Type akamaiblog
Reporter Sam Preston
Modified 2019-05-07T15:19:18

Description

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.

Fast DNS Image One.jpg

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.
Fast DNS Image Two.jpg

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:

  1. Update the domain's zone NS records to include Akamai Fast DNS nameservers / remove any legacy nameservers
  2. 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:

Fast DNS Image Three.PNG

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*

Fast DNS Image Four.PNG

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

Fast DNS Image Five.PNG

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

Fast DNS Image Six.PNG

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

Fast DNS Image Seven.PNG

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

Fast DNS Image Eight.PNG

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:

Use this form to ask for Akamai help. We can have someone contact you to help with your DNS questions.****