Solving DNS zone apex challenges with third-party DNS providers using AWS

Summary

Many customers ask us how they can point their zone apex to their web content if it uses a DNS name rather than an IP address. This blog covers three design patterns and approaches that solve zone apex challenges with third-party DNS providers for applications hosted in AWS—and the pros and cons of each approach.

This is a 400-level post on a specific aspect of DNS. If you are interested in a more general overview of DNS you might find the tech talk, DNS design using Amazon Route 53, helpful.

It is often desirable for a customer’s root domain (zone apex record, or ‘naked domain’) to point to, or be redirected to, their web content. A zone apex record is a DNS record at the root of a DNS zone, such as ‘example.com.’ RFC 1034 states that the zone apex must be an A Record, and not a CNAME record. This means that the zone apex record must point to one or more IP addresses.

With many AWS services, a DNS name is provided rather than IP addresses. This allows for changes to the underlying components of the service (scale up/down, upgrades, failure replacement, etc.) without having to change DNS or client configurations. If you are using Amazon Route 53 to manage your hosted zone, AWS provides alias record sets to redirect your zone apex requests to an AWS service DNS name. But, when using many third-party DNS providers, this isn’t possible.

Introduction

Web content is often made available through an Amazon CloudFront distribution, an Elastic Load Balancer, an AWS Elastic Beanstalk environment, or through an Amazon Simple Storage Service bucket hosting static web content. Each of these solutions provides a DNS name, such as webALB-1234567890.us-east-1.elb.amazonaws.com, that resolves to IP addresses used by those services at the time. This allows for graceful changes to the underlying service caused by normal processes, like automatically scaling a service up or down, and also infrequent changes, like a failure of an instance. These IP addresses are not static, and can change over time, so it is recommended that you always use the DNS name of the service to reach your web content.

Asking your consumers to reach your web content using a DNS name like webALB-1234567890.us-east-1.elb.amazonaws.com is not ideal. Instead, customers frequently use CNAME (Canonical Name) DNS records to alias one name to another. For example, a CNAME record for our example might look like:

www.example.com.    3600    IN    CNAME    webALB-1234567890.us-east-1.elb.amazonaws.com

This works great for the ‘www’ subdomain and allows consumers to reach web content using www.example.com. But, in addition to the ‘www’ subdomain, it is desirable for a customer’s root domain (zone apex record, or ‘naked domain’) to point to their web content. A zone apex record is a DNS record at the root of a DNS zone. For instance, the apex record for the DNS domain ‘example.com’ would have the fully qualified name of ‘example.com.’ The zone apex is where the SOA and NS records for a DNS zone are placed. While not explicitly prohibited, with many DNS service providers, it isn’t possible to create a CNAME record for the zone apex, as it effectively rewrites all other DNS records for that same domain. RFC 1034 states that, “If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.”

The solution is to create a zone apex DNS A record that resolves to an IP address. What do you do when you need your zone apex record to point to static IP addresses, but your web content is hosted behind an AWS service that doesn’t support static IP addresses? With Amazon Route 53, this is possible, because Amazon Route 53 supports the alias record set. Alias record sets let you map your zone apex DNS name to the DNS name of your alias targets. These targets can include Amazon CloudFront distributions, AWS Elastic Beanstalk environments, elastic load balancers, or an Amazon Simple Storage Service bucket hosting static web content. Amazon Route 53 monitors the IP addresses associated with the alias target’s DNS names and returns a response that contains an A record (for IPv4 addresses) or AAAA record (for IPv6 addresses) with the IP address of the alias target. However, many customers use other third-party DNS providers that don’t support alias Records.

Now we will explore 3 different design patterns that solve the zone apex challenge while using third-party DNS providers. Each solution provides >1 static IP addresses (for added resiliency) that can be used to create A/AAAA records.

Using EC2 instances with Elastic IPs

In this option, you create EC2 instances with Elastic IP address in multiple Availability Zones for high availability. Elastic IP addresses remain associated with your EC2 instances until you disassociate them (surviving reboots and restarts). The Elastic IP addresses can be moved to different EC2 instances in the event of a failure, or when replacing existing instances with new instances (patching/updates). This allows for changes in your application without having to update DNS. Further, this design pattern allows for special use cases of EC2, such as using EC2 as reverse proxies (for example, Nginix or alike) that can then be used to front-end other services that are only available via DNS name. After associating EIPs with the EC2 instances, the next step is to create A or AAAA records in your DNS provider for your zone apex example.com pointing to the Elastic IPs of the EC2 instances. This architecture is shown in the following diagram:

DNS Zone Apex to AWS Elastic IP

Pros:

• The simplest and the lowest cost option.
• Supports both IPv4 (A) and IPv6 (AAAA).

Cons:

• DNS provider must support round robin resolution for load balancing.
• DNS caching can make AZ fail over indeterministic and unreliable.
• Instances must be publicly reachable (that is, not private).

Using AWS Global Accelerator

Another approach is to create A Records for the zone apex pointing to Global Accelerator IPs. AWS Global Accelerator provides static IP addresses (either Amazon provided or BYOIP) to Regional AWS resources or endpoints, such as Network Load Balancers, Application Load Balancers (Public or Private), EC2 Instances (Public or Private), and Elastic IP addresses. The IP addresses are announced via Anycast from AWS edge locations so they provide a fixed entry point to your applications close to your end users. This means that the same pair of static IP addresses are advertised globally through AWS Global Accelerator Points of Presence (PoPs). Global Accelerator also directs traffic to optimal endpoints over the AWS global network, which improves overall performance of your application.

Any changes to your application are abstracted from the end users as they always connect to AWS Global Accelerator IP addresses. In case of an unhealthy endpoint, AWS Global Accelerator automatically shifts traffic to the next optimal AWS Region without requiring any IP or DNS changes on client side. This results in deterministic and predictable failover times. You can learn more about How AWS Global Accelerator works in AWS Global Accelerator developer guide.

There are two ways in which AWS Global Accelerator can be used to provide static IP addresses for your web content:

• Associate the static IP addresses provided by AWS Global Accelerator with an Application Load Balancer endpoint, which then distributes traffic to your web content Amazon EC2 or AWS Lambda target groups
• Associate the static IP addresses provided by AWS Global Accelerator with an Application Load Balancer endpoint, which then redirects your traffic to another URL (that is, Amazon S3 static website, Amazon CloudFront distribution, or an AWS Elastic Beanstalk environment)

For the first design pattern, we create an AWS Global Accelerator pointing to an Application Load Balancer (can be private or public facing) which then distributes traffic to your web content Amazon EC2 or AWS Lambda target groups. This approach allows you to combine Application Load Balancer’s layer 7 routing capabilities, such as AWS WAF, path-based routing, host header-based routing, redirects, and so on. AWS Global Accelerator provides you with static IP addresses and a DNS name mapped to these static IP addresses. The static IPs allow you to create an A Record for zone apex use (that is, example.com pointing to Global Accelerator static IP addresses).

DNS Zone Apex to AWS Global Accelerator – Distribute

The second design pattern using Global Accelerator is similar to the first. You associate the static IP address of Global Accelerator with an ALB, but instead of forwarding traffic from the ALB to your web content instances or functions, you redirect the traffic from the ALB to another host. ALB supports temporary (HTTP 302) or permanent (HTTP 301) redirects. For this use case, a permanent redirect to the hostname of the web content makes the most sense. ALB also allows for reuse of URI components from the original URL in the target URL, using reserved keywords like, #{protocol} (to retain the protocol from the original URL), or #{path} (to retain the path from the original URL). For more examples, please see the ALB documentation describing redirect actions. With this design pattern, you can redirect to an Amazon S3 static website, Amazon CloudFront distribution, an AWS Elastic Beanstalk environment, or any other URL.

DNS Zone Apex to AWS Global Accelerator – Redirect

Pros:

• AWS Global Accelerator manages the Anycast IP addresses for you, which are advertised globally. This also helps reduce client DNS caching issues.
• AWS Global Accelerator directs traffic to optimal endpoints over the AWS global network which improves availability and performance of your applications for local and global users.
• AWS Global Accelerator distributes incoming application traffic across multiple endpoint resources in multiple AWS Regions, improving availability of your application and simplifying failover between Regions.
• Because of Global Accelerator’s internal ALB support, this option allows customers to keep their VPCs private.
• ALB supports redirect actions, allowing for the redirect to any URL of any service, hosted in AWS or externally.

Cons:

• There is an additional charge for using AWS Global Accelerator (for more information, please visit the AWS Global Accelerator pricing page).
• ALB has a limit of 25 certificates per load balancer (this can limit scale of the solution when using HTTPS), and 100 rules per load balancer.
• AWS Global Accelerator doesn’t support Security Groups or AWS WAF, however, you can use these options on the endpoints (ALB and EC2 instances).
• Does not yet support IPv6 (AAAA).

Using AWS Network Load Balancer

The last approach is to leverage a Network Load Balancer to distribute incoming traffic across the target instances of your application. Network Load Balancers, in particular, support the use of static IP addresses, allowing you to create A records in your DNS system that point to the static IP addresses of the Network Load Balancer. Network Load Balancers operate at Layer 4 of the Open Systems Interconnection (OSI) model and can handle millions of requests per second. When you enable an AZ for the load balancer, ELB creates a load balancer node in that AZ. ELB creates an Elastic Network Interface (ENI) for each AZ you enable. Each load balancer node in the AZ uses this ENI to get a static IP address. When you create an Internet-facing Network Load Balancer, you can optionally associate one Elastic IP address (EIP) per subnet. These EIPs can be used to create A records in your DNS system for the zone apex example.com.

DNS Zone Apex to AWS Network Load Balancer

Pros:

• Network Load Balancer provides static IPs for use with A records in your DNS system.
• Supports both TCP and UDP (layer 4) load balancing, and supports long-running connections that are useful for WebSocket type applications.
• Highly available – Network Load Balancer nodes are created in each enabled AZ, and can distribute your traffic to your targets in Availability Zones.
• TLS termination – Network Load Balancer can terminate TLS connections, freeing your backend servers from the compute-intensive work of encrypting and decrypting all of your traffic, and reducing the need to distribute server certificates to each backend server.
• Supports both IPv4 (A) and IPv6 (AAAA).

Cons:

• There is an additional charge for using a Network Load Balancer (for more information, please visit the Elastic Load Balancing pricing page).
• DNS caching can make AZ fail over indeterministic and unreliable.

Conclusion

In this blog post, we looked at various different AWS architectures for solving DNS zone apex challenge with third-party DNS providers. We listed the pros and cons of each approach so that you can choose the best architecture to meet your requirements.