Redundant, Secure, and Open Short Domains: A Vision for Multi-Provider Apex Domain Aliases to Enable DNS Diversity
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., edgedns.zone). 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., edgedns.zone) 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 edgedns.zone. With Akamai zone apex mapping, these addresses are dynamic, set at query time, and DNSSEC-ready.
edgedns.zone. 20 IN A 198.51.100.146
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., ns1.akam.net). 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 www.edgedns.zone and, unlike apex domains, can have a CNAME.
www.edgedns.zone. 1800 IN CNAME www.edgedns.zone.edgesuite.net.
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, edgedns.zone might have a signature like this.
edgedns.zone. 300 IN RRSIG TYPE65 13 2 300 20201017071505
20201014061505 48845 edgedns.zone.
JJbJh54n7FvyM27n7Mex39mzCaeWCJmvuxyypLpe7KC/TU2I6Eh9/tx6
HVywpMCqgmwGbY6y5D8A4W0LZRKOjA==
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 www.edgedns.zone.
www.edgedns.zone. 300 IN CNAME www.edgedns.zone.edgekey.net.
www.edgedns.zone.edgekey.net. 21600 IN CNAME e5805.dscx.akamaiedge.net.
e5805.dscx.akamaiedge.net. 20 IN A 198.51.100.146
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 edgedns.zone to https://www.edgedns.zone). 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 "edgedns.zone" into a browser address bar. Most browsers start off by making an insecure "http scheme" request to http://edgedns.zone/ that then needs to return a redirect to https://edgedns.zone/ or https://www.edgedns.zone/. 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 edgedns.zone. Notice that the www CNAME and the apex HTTPS record point to the same pool.edgedns.zone service name.
www.edgedns.zone. 2H IN CNAME pool.edgedns.zone.
edgedns.zone. 2H IN HTTPS 0 pool.edgedns.zone.
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 pool.edgedns.zone 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., https://edgedns.zone/), 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.
- Achieve domain stability and resilience with Akamai's Edge DNS service.
- Load balance your data centers, cloud deployments, and CDNs with Akamai's Cloud-Based Global Server Load Balancing (GSLB) solution: Global Traffic Management.
- Scale layer 7 load balancing using Akamai's Application Load Balancing (ALB) Cloudlet.
- Use the Edge Redirector Cloudlet to redirect users from less to more preferred URLs.
- Ensure every device in your network checks a DNS security tool and that domain name resolution is not for malware, phishing, or a botnet. Akamai's Secure Internet Access and DNS Infrastructure (DNSi) and Secure Internet Access Services (SIA) transform your basic DNS resolver into a security tool.
- Sign Up and Search Akamai's Community, which provides access to a range of Akamai resources.
- DevOps teams are welcome to join akamai.com/developer. Akamai's DNS solutions are API-ready to enable cloud-to-cloud innovation. Look for APIs such as Edge DNS Zone Management API.
Contact us for help with your DNS questions.
