Skip to main content
Dark background with blue code overlay

Redundant, Secure, and Open Short Domains: A Vision for Multi-Provider Apex Domain Aliases to Enable DNS Diversity

Jim Gilbert

Written by

Jim Gilbert

November 11, 2020

Jim Gilbert is a director of product management at Akamai. He has over ten years of DNS service and technology experience and more than twenty years of related experience working on various Internet fields such as email infrastructure for ISPs. Jim focuses on authoritative and recursive edge DNS services for the carrier and enterprise markets.

One small step for DNS, one giant leap for the internet

Human nature is to seek simpler and convenient ways to do things. One example is the sometimes onerous task of typing a URL into a web browser's address bar. Since users prefer short, easy-to-remember URLs, an internet trend is to use short domains for websites (e.g., With short website names, users benefit from the convenience of fewer characters to remember and type.

Making this work has been a challenge, however, due to an obscure corner-case in the DNS standard itself, and has led the industry to provider-specific, incompatible solutions that prevent organizations from using multiple DNS providers for redundancy. As an example, Akamai's zone apex mapping can dynamically resolve DNS requests for short domain names on the fly to an IP address of an optimal edge server. However, this solution is Akamai-specific. The impact is that multiple DNS providers cannot deliver answers for these configurations. Organizations are better with DNS redundancy at all possible levels with multiple DNS authoritative providers, even for short domain names.

A solution is on the way! An upcoming IETF proposed standard authored by people from Akamai and Google, known as service binding, provides an open solution that solves this problem and others such as open access to protocol configuration data (e.g., HTTP/3 support available) and keying material for encrypting TLS Server Name Indication.

For DNS technologists, this post describes a vision for providing DNS for short domain names from multiple providers and next steps to get ready for service binding-aware clients.

Important knowledge to better understand the gaps

Authoritative DNS and address records

Authoritative DNS commonly refers to a server or service that knows the content of a DNS zone and can respond to queries from a caching resolver without querying other servers. Unlike caching resolvers that work for users to find addresses for domain names, authoritative DNS servers hold the source of truth about data such as address records. The following diagram shows the typical workflow for a domain name lookup. A user starts this workflow with an action such as typing a name (e.g., into a browser address bar.

This process completes with edge addresses to get the content for the domain name. Example address records might look like the following for the short name With Akamai zone apex mapping, these addresses are dynamic, set at query time, and DNSSEC-ready.         20   IN  A

                                             AAAA 2001:db8::99:146

Note that short names are also DNS zones; they have NS (nameserver) records as well, which provide the names for the authorities (e.g., While longer names may use a CNAME record to point over to a CDN, short names are unable to do this because the same name can't have both a CNAME record and an NS record (as then the NS record would try to follow the CNAME, which isn't allowed).

Short apex domains

In the example above, the domain name is an apex domain, meaning that only a single label exists (i.e., edgedns) with a top-level domain (TLD, i.e., zone). A longer name might use a www subdomain. In this way, the full domain is then and, unlike apex domains, can have a CNAME. 1800 IN CNAME

Looking more closely, this record is read like this:

Secure DNS data

DNS Security Extensions (DNSSEC) provide standards for zone owners to sign zone data so that a client can validate and ensure the data to be genuine. As an example, might have a signature like this. 300 IN RRSIG TYPE65 13 2 300 20201017071505

20201014061505 48845



A DNSSEC validating resolver can use this record to validate the record data by calculating and comparing a matching signature. With a signature mismatch, the process can block the invalid record from use.

To learn more, the DNSSEC: How It Works & Key Considerations blog has a simple walkthrough.

DNS records often dynamic

Advanced DNS systems provide clever ways to respond with answers that are intelligent and specific to the client asking the question and the state of the internet. For example, Akamai DNS routes users to optimal edge servers that can deliver a good user experience and balances traffic across multiple data centers. The following resource records provide a good example for the name 300 IN CNAME 21600 IN CNAME 20 IN A

                                                     AAAA 2001:db8::99:146

Notice that the answer is a dynamic CNAME chain that concludes with A and AAAA records.

Deployment diversity matters

As the Deployment Diversity for DNS Resiliency blog describes, fast, reliable, and secure edge services kick-starts with DNS. Often, too much attention is spent on other areas of edge service deployments, leaving DNS as an afterthought. Many organizations overlook the DNS critical dependency for edge performance and security. To remain available through incidents such as DDoS attacks, utilize a segmented, diverse DNS architecture to always connect with users. This diversity often includes a multi-provider configuration, meaning more than one DNS service provides authoritative DNS.

Apex domains addressing redirection services can be a security risk

To work around the limitation that a DNS zone with a short name cannot use a CNAME, a redirection service is common. This mitigation uses a static address for a redirection service that navigates an application to a subdomain that has security (e.g., HTTP(S) redirect from to The risk with this technique is that an attacker can take down the redirection source and interrupt service for users addressing content with the short domain name (zone apex mapping solves this problem)! As a result, website performance can often not meet expectations, and edge deployments can be vulnerable to DDoS attacks, all because of this DNS constraint.

Browsers default to insecure schemes

A common use case for short domains is to type them in as "" into a browser address bar. Most browsers start off by making an insecure "http scheme" request to that then needs to return a redirect to or Not only does this take a bunch of network round trips (impacting load time), but it means that the request is exposed to active network attackers.

Wait ... multi-provider might not work for short names

That's correct. Short domains require unique solutions. Akamai's solution is known as zone apex mapping. Other DNS providers have similar proprietary solutions. These solutions can only work with a single DNS provider, as the zone owner can't sign and transfer a dynamically changing zone to multiple providers, and multiple DNS providers cannot each sign a dynamically changing zone with their own keys. A zone owner then has a choice: Don't sign and distribute the zone to multiple providers, or sign the zone and utilize one provider.

Service binding alias records to the rescue

With service binding's apex domain workflow, a zone owner can use multiple DNS providers for redundancy and sign zones for data integrity. To make this happen, the service binding standard has an HTTPS record, in alias mode, that can reside at the domain apex and act like a CNAME that a zone owner can sign and distribute to multiple providers!

The following example shows how to do so using Notice that the www CNAME and the apex HTTPS record point to the same service name. 2H IN CNAME          2H IN HTTPS 0

With these static records, a zone owner can sign the zone, transfer the zone with its signatures to multiple providers, and publish the corresponding delegation signature (DS) to the parent .zone TLD.

For the HTTPS-aware clients, the service name then expands to A+AAAA records and/or an HTTPS service mode record for that includes parameters such as available protocols (e.g., HTTP/3) and Encrypted Client Hello keys. With these parameters, clients can connect with the right edge server at the right time with the right protocols. In this way, a service eliminates extra transactions to bootstrap connections and better encrypts data for privacy.

The HTTPS record also signals that the site is available over HTTPS so HTTPS-aware clients will default to the "https scheme" (e.g.,, which improves both performance and security.

What to do

At this time, a good next step is to follow the service binding draft's IETF workflow. Akamai is testing an early implementation and expects the standard to continue progressing through the IETF's standards track.

Another good step is to plan a proof of concept (PoC) with HTTPS records in an Edge DNS test zone. Akamai expects compatible versions of tools such as dig and early HTTPS-aware clients (e.g., browsers) to come to market shortly. Each PoC configuration can evolve into a production configuration. Service binding-aware clients coming online will find the new records and use the new service definitions.

Explore Akamai's diverse DNS-oriented solutions

If you find this blog useful, continue your exploration with the below references. Everything Akamai deploys leverages a common intelligent edge platform.

Contact us for help with your DNS questions.

Jim Gilbert

Written by

Jim Gilbert

November 11, 2020

Jim Gilbert is a director of product management at Akamai. He has over ten years of DNS service and technology experience and more than twenty years of related experience working on various Internet fields such as email infrastructure for ISPs. Jim focuses on authoritative and recursive edge DNS services for the carrier and enterprise markets.