Edge DNS: Zone Apex Mapping & DNSSEC

Introduction

Along with its DDoS resilience and impressive global footprint, Akamai Edge DNS offers zone administrators additional technical flexibility and implementation options to improve performance and simplify DNS operations. One example is zone apex mapping (ZAM), a feature that enables top level hostnames (e.g., akamai.com) to resolve directly to an Akamai edge IP. The popularity and appeal of ZAM do, however, prompt a number of questions about the technical specifics, such as: Is ZAM interoperable with DNSSEC? The short answer is yes: Outside of a few caveats that we will explore later in this article, Edge DNS zones can be authenticated with DNSSEC and retain the performance benefits of ZAM. We'll explore the details of each feature and the interoperability limitations in the sections below. 

Zone apex mapping

The Internet Engineering Task Force (IETF) specification requires a domain name's zone apex to resolve to either an A or AAAA record in public DNS. This stipulation can prove burdensome, however, as CDNs and other proxy services often require a hostname to be CNAMEd to an alias belonging to the third party; in Akamai's case, this alias is called an edgehostname. For Akamai CDN customers, DNS lookups for apex hostnames typically resolve to an endpoint responsible for redirecting the request to a subdomain, which can then be CNAMEd to an edgehostname without violating the aforementioned DNS spec. While this is a common setup, this layer 7 redirect and subsequent CNAME lookup can add latency to a user's web experience. In addition, this request flow potentially exposes the origin endpoint to additional attack vectors, as the request for the apex domain will not enjoy the protections of Akamai's security products, such as Web Application Firewall, Bot Manager, or Site Shield.

However, if a zone is hosted by Akamai Edge DNS with ZAM enabled, Akamai nameservers can directly return an A or AAAA record for an optimal Akamai edge IP when an apex domain is queried by a resolver. Consequently, top level domains can be served through Akamai without violating any DNS standards. Even if the redirect to the subdomain is still preferred for SEO reasons (or otherwise), ZAM can facilitate a more performant architecture by enabling the possibility of issuing the layer 7 redirects on our edge network, which is typically closer to the end user than the origin endpoint. This approach also protects the customer's application from any nefarious activities against the apex domain, since the TLD redirect will be fulfilled independently by the Akamai platform.  

Cname optimization 

ZAM can be leveraged for subdomains as well, eliminating any latency associated with the "CNAME chain." Without ZAM, subdomain lookups might traverse multiple CNAMEs to eventually retrieve an A record associated with an Akamai edge server IP (see column 2 in the figure below). With ZAM in place, however, Edge DNS nameservers can return this Akamai IP directly without any background queries or additional lookup, eliminating the CNAME chain. This optimization is possible because Edge DNS nameservers possess all the necessary mapping information in a consolidated table, and are thus able to return an A or AAAA record associated with the optimal edge server.

DNSSEC and apex domain workflow

For a majority of use cases, ZAM is compatible with DNSSEC, the protocol extension responsible for authenticating responses and preventing DNS poisoning attacks. When DNSSEC is enabled for an Edge DNS zone, every record is digitally signed by a public/private keypair and successful decryption by a resolver indicates the zone's data was not forged or manipulated by a malicious third party. While DNSSEC increases the amount of data transferred "over the wire," Edge DNS's global anycast network is designed to ensure responses remain performant and available for all end users. 

However, there are a few interoperability limitations for these two features. DNSSEC and ZAM are currently not supported if the registrar delegates the protected zone to multiple DNS providers. In this scenario, each provider would be required to sign the zone with their own private key since the ZAM / alias record output is dynamic. This is an untenable implementation, however, since a recursive resolver is required to perform two unique lookups when a zone is protected by DNSSEC: one to retrieve the desired record and another to obtain the public key to validate the response. Unfortunately, there is no guarantee the same DNS provider will be chosen for both lookups in a mixed delegation model, and as a result, the resolver could receive the public key for provider A but the resource record set from provider B, an outcome that will result in a verification failure.  And while ZAM can be enabled in a mixed delegation model without DNSSEC, the other DNS provider(s) may not support an equivalent top level CNAME option -- even if this offering exists, performance or mapping inconsistencies may arise based on the provider's specific CNAME flattening capabilities and limitations. 

In addition, if Edge DNS is implemented as a secondary provider with zone transfers in place, ZAM is not supported if the primary provider signs the zone. In this scenario, Akamai will simply "serve" the DNSSEC-protected zone without any record optimizations, as any such modifications would result in a resolver verification failure. Finally, as with any implementation, Akamai's professional services team should be consulted to assist with any additional nuances involved with ZAM, DNSSEC, and Edge DNS. 

Future protocols may help

Protocol improvements are currently being drafted to address these multi-provider challenges. For example, the proposed HTTPS record type outlines a standard approach to bind a service definition at the apex:

www.example.com. 2H IN CNAME gtm.example.net.

example.com. 2H IN HTTPS 0 0 gtm.example.net.

gtm.example.net  2H IN CNAME example.com.edgekey.net.

As a result, zone administrators would be able to bind an apex entry to an Akamai edgehostname (or any alias) in a consistent manner across all authoritative providers, eliminating reliance on proprietary solutions that handout dynamic outputs for apex record queries. Since the proposed HTTPS record is a static entry, this standardization would allow one keypair to sign the zone so every provider could serve the same signed artifact, an approach that ensures multi-provider DNSSEC can be achieved. Similarly, in a secondary/axfr model, this new record type would offer primary providers a standard method to sign a zone with the top level domain binded to an alias hostname, assuming the primary supported DNSSEC. 

Along with standardizing apex domain alias capabilities, the proposed Service Binding standard may offer additional server details when a DNS response is returned with the goal of facilitating additional security and performance benefits. For example, the IETF draft outlines the opportunity to advertise whether the server supports TLS; with this information in hand, the client could automatically send the initial layer 7 request over HTTPs to avoid any latent protocol-upgrade redirects, while simultaneously eliminating potential attack vectors. 

Conclusion

ZAM and DNSSEC are two primary examples of how Akamai Edge DNS enables responses that are as performant and secure as possible. The interoperability of these features affords zone owners additional functionality and flexibility when it comes to managing records. If you are interested in learning more, please contact your Akamai representative today.

Explore Akamai's diverse DNS-oriented solutions

If you find this blog useful, continue your exploration using the references below. Everything we deploy depends on the DNS technology embedded in our Akamai Intelligent Edge Platform. Akamai built on this to enable a range of services for domain owners:

• New white paper: Designing DNS for Availability and Resilience against DDoS Attacks explains how Akamai deploys Edge DNS with multiple vectors of global resilience

• Achieve domain stability and resilience with Akamai Edge DNS

• Load balance your data centers, cloud deployments, and CDNs with Akamai's cloud-based global server load balancing solution, Global Traffic Management

• Massively scale your application with layer 7 load balancing with Akamai Application Load Balancer Cloudlet

• Ensure every device in your network checks a DNS security tool -- ensuring the domain name resolved is NOT malware, phishing, or a botnet; Akamai Enterprise Threat Protection and DNSi/SPS solutions turn your DNS resolver into a security tool

• Sign-up for and search the Akamai Community, which provides you access to a range of Akamai resources 

• DevOps professionals are welcome to join our developer hub – Akamai's DNS solutions are API and DevOps aligned, enabling cloud-to-cloud innovation

Use this form to ask Akamai for help. We will have someone contact you to answer your DNS questions.