Streamline hybrid DNS management using Amazon Route 53 Resolver endpoints delegation

Introduction

We recently announced that Amazon Route 53 Resolver Endpoint supports Domain Name System (DNS) delegation, allowing you to delegate authority for a subdomain from your on-premises infrastructure to Route 53 and vice versa. Previously, to implement DNS delegation and maintain a unified private DNS namespace across on-premises and in Amazon Web Services (AWS) environments, customers needed to run self-managed DNS infrastructure. This meant more operational overhead and undifferentiated heavy lifting for customers. This new feature allows you to implement DNS delegation and have a streamlined, structured, and unified hybrid connectivity across your network topology without the need to manage more DNS infrastructure.

In this post, we’ll show how you can leverage this new capability to simplify your hybrid DNS infrastructure at scale.

Many AWS customers allow multiple organizations within their same enterprise to individually manage their respective DNS subdomains, whereas parent domains and parent hosted zones are typically overseen by a central team. For example, a central team may be in charge of your example.com parent domain on-premises, while a cloud engineering team is responsible for your aws.example.com subdomain. Similarly, the parent domain (example.com) might be hosted on Route 53, while a Berlin-based on-premises regional IT team manages the berlin.example.com subdomain. Previously, for each of these use cases, you had to deploy self-managed DNS infrastructure to support DNS delegation from on-premises to AWS and from AWS to on-premises to facilitate such organizational ownership separations. This release adds DNS delegation support to Route 53 Resolver Endpoint’s existing forwarding capabilities, allowing you to significantly lower the operational burden of operating hybrid DNS.

Why DNS Zone delegation?

To understand DNS delegation and the value that this new feature brings, consider the scenario of a large organization (AnyCompany) composed of multiple independent entities around the world. The organization operates a decentralized DNS architecture, with a private, internal-only parent domain (example.com) managed by global teams, while subdomains are delegated to authoritative DNS servers hosted in different entities according to their industry segment. For example, the health tech business (Entity 1) is delegated to healthtech.example.com, the retail business (Entity 2) is delegated to the retail.example.com subdomain, and so on. Each entity operates in hybrid mode, with workloads running in both on-premises and AWS environments. When a client attempts to access one of the health tech applications (such as app1.aws.healthtech.example.corp) hosted in, say, the Entity 1 AWS organization, the request follows the DNS delegation chain, as shown in the following figure.

Figure 1: DNS architecture of AnyCompany

1. A client in the corporate network sends a recursive DNS request to the local resolver to resolve an A record for the health tech application “app1.aws.healthtech.example.com”.
2. The local DNS resolver checks its local cache for a resolution. If it does not have the answer in cache, then it starts an iterative request to the parent zone “example.com”.
3. The parent zone DNS server responds with a referral for “healthtech.example.com”.
4. The DNS resolver sends an iterative query to the “healthtech.example.com” authoritative DNS server.
5. The “healthtech.example.com” DNS server responds with a referral for the “aws.healthtech.example.com” zone.
6. The DNS Resolver sends an iterative query to the “aws.healthtech.example.com” authoritative DNS server.
7. The “aws.healthtech.example.com” DNS server that contains the requested A record (app1) returns an authoritative answer to the DNS Resolver.
8. The DNS resolver provides a Type A resolution of “app1.aws.healthtech.example.com” to the client.

Before this release, Route 53 Resolver endpoints did not support iterative DNS queries for private, non-publicly resolvable DNS domains split across Route 53 and on-premises name servers. This limitation meant you could not include Route 53 Resolver endpoints in a private, unified namespace DNS delegation chain such as the one described above for hybrid scenarios. As a result, customers who wanted a private, unified hybrid DNS namespace had to deploy more self-managed DNS infrastructure to act as authoritative DNS servers for subdomains containing records for their AWS resources in Amazon Virtual Private Cloud (Amazon VPC). For example, DNS records for aws.healthtech.example.com had to be hosted on a self-managed DNS infrastructure. This release allows you to create a Private Hosted Zone for the subdomain (aws.healthtech.example.com) and delegate authority for the subdomain directly to Route 53 Resolver endpoints.

Route 53 endpoint inbound delegation (on-premises to AWS)

Before we discuss Inbound delegation, let’s first cover Route 53 endpoints. When you have workloads that span both VPCs and on-premises, you might need to ensure that your on-premises resources can resolve names hosted on AWS, and vice versa. Route 53 Resolver inbound endpoints, combined with conditional forwarding rules, enables your on-premises DNS resolvers to easily resolve domain names for AWS resources such as Amazon EC2 instances or records in a Route 53 private hosted zone. For more information see How DNS resolvers on your network forward DNS queries to Route 53 Resolver endpoints.

With Route 53 endpoint inbound delegation, you can delegate the authority for a subdomain to Route 53 without deploying more infrastructure to host DNS records. Continuing with the example, to enable access from the corporate network to the health tech application running on Amazon VPC, the cloud engineering team implements the following DNS configurations.

1. In AWS, create a private hosted zone for aws.healthtech.example.com and associate it with the Amazon VPC where the health tech application running.
2. Create an A record for app1.aws.healthtech.example.com

Figure 2: Private hosted zone configuration for inbound delegation

3. Create an inbound resolver delegation endpoint in the VPC where the private hosted zone aws.healthtech.example.com is associated.

Figure 3: Create inbound delegation endpoint

3a. Make a note of the IP addresses of the Resolver endpoint.

Figure 4: IP addresses of the inbound delegation endpoint

4. The team responsible for the healthtech.example.com on-premises DNS infrastructure must update the healthtech.example.com zone with delegation (NS) records for aws.healthtech.example.com (e.g., ns1.healthtech.example.com). Here is an example configuration using Windows DNS but the steps are similar for other DNS servers.

dnscmd /recordadd healthtech.example.com aws NS ns1.aws.healthtech.example.com

5. Configure the DNS records for ns1. healthtech.example.com to resolve the IP addresses of your inbound resolver delegation endpoint noted in step 3.

dnscmd /recordadd healthtech.example.com ns1.aws A 10.10.0.7
dnscmd /recordadd healthtech.example.com ns1.aws A 10.10.12.70

The following figure describes the Route 53 Resolver inbound delegation flow.

Figure 5: Route 53 Resolver inbound delegation flow

Route 53 endpoint outbound delegation (AWS to on-premises)

When you have workloads that span both VPCs and on-premises, Route 53 Resolver outbound endpoints, combined with conditional forwarding rules, enables AWS resources such as Amazon EC2 instances to resolve domain names for on-premises resources. For more information see How DNS resolvers on your network forward DNS queries to Route 53 Resolver endpoints.
Route 53 Resolver also supports outbound DNS delegation from AWS to on-premises DNS servers. In the following sections we show two scenarios where the outbound endpoint delegation can streamline the management of your private, unified hybrid DNS namespace.

Parent domain in Route 53 private hosted zone

Route 53 DNS delegation allows you to have your parent domain as a private hosted zone while delegating subdomains to on-premises DNS servers.

Consider the opposite scenario, where your health tech application running in the apps VPC needs to access the company’s drugs database (drugs.healthtech.example.com). A year has passed, and your IT department has migrated the global parent DNS domain (example.com) to Route 53 as the organization’s authoritative DNS service provider. However, the DNS servers for the various subdomains are still on-premises across different datacenters, such as the healthtech.example.com DNS servers (ns.healthtech.example.com). To enable the health tech application on Amazon Elastic Compute Cloud (Amazon EC2) connect to the company’s drugs database (drugs.healthtech.example.com) on-premises, your AWS cloud engineering team must perform two key steps.

1. First, create a new outbound resolver endpoint for the apps VPC, if one doesn’t already exist.
2. Create an NS record for the subdomain healthtech.example.com that specifies the fully qualified domain name (FQDN) of the on-premises DNS servers as the authoritative name servers.

Figure 6: NS record for outbound delegation

3. Next, create a delegation rule for the domain healthtech.example.com and associate the delegation rule with the apps VPC.

Figure 7: Create outbound delegation rule

4. Next, do one of the following:
a. If the FQDN of the on-premises DNS server is in the same domain as the private hosted zone (in-zone), create a glue record by adding an A record in the private hosted zone that maps to the IP address of the on-premises DNS server.
b. Otherwise, if the FQDN is not in the same domain, create a forwarding rule for the FQDN that points to the IP address of the on-premises DNS server.

In my example, the FQDN of the on-premises DNS server is in-zone, so I created an A record in the private hosted zone that maps to the IP address of the on-premises DNS server. Figure 8 shows the configuration of the private hosted zone.

Figure 8: Private hosted zone configuration for outbound delegation

These configurations enable the Route 53 private hosted zone to delegate the healthtech.example.com subdomain to the on-premises DNS nameservers and allows the VPC Resolver to recursively resolve the drugs server by following the delegation.

Figure 9: Route 53 Resolver private hosted zone to outbound delegation flow

Outbound delegation removes the need for 1-1 provisioning of forwarding rules for each delegated subdomain. Suppose that the Health Tech subsidiary of AnyCompany had multiple other subdomains such as sales.healthtech.example.com, training.healthtech.example.com, hr.healthtech.example.com, and so on. To use conditional forwarding in that scenario, you needed to create forwarding rules for each of those subdomains with the target server of each of those subdomains. As more subdomains are added, the number of conditional forwarding rules likewise increases, and management becomes more challenging. However, outbound endpoint delegation allows you to have a single delegation rule for them all (healthtech.example.com).

Parent and subdomains on-premises

Route 53 Resolver also supports DNS resolution by following the delegation chain when both the parent domain and delegated domain(s) are hosted on the on-premises infrastructure.

Therefore, continuing with the last scenario, we can assume that you have not yet migrated your parent domain (example.com) to the private hosted zone. That is, all your DNS domains (parent and subdomains) are hosted on-premises, but the health tech application runs on Amazon EC2. Furthermore, like before, your health tech application running in the apps VPC needs to access the company’s drugs database (drugs.healthtech.example.com), which is on-premises. With both the parent (example.com) and subdomain (healthtech.example.com) DNS servers on-premises, your cloud engineering team creates two rules on the outbound Resolver: one Forwarding Rule for example.com targeting the IP address of the parent on-premises DNS servers, and one Delegation Rule for example.com. Moreover, as with the previous scenario, if any nameserver in the delegation chain is out-of-domain, the team must add a forwarding rule to allow Route 53 resolve the IP address of the specified authoritative DNS server.

Now when the health tech application in AWS needs to query records from the drugs database, it sends a DNS query for drugs.healthtech.example.com, which Route 53 Resolver forwards to the example.com on-premises DNS server based on the forward rule. When the on-premises DNS server responds with a referral, Route 53 follows the delegation chain until it contacts the correct on-premises DNS server with the requested record and returns the response to the health tech application on Amazon EC2.

Figure 10: Delegation flow when both parent and subdomains are on-premises

Using Route 53 endpoint outbound delegation in this way allows you to separate DNS authority for different application domains, make sure of proper DNS resolution across multiple data centers, and keep clear delegation boundaries for security and compliance.

Conclusion

Inbound and outbound delegation for Amazon Route 53 Resolver endpoints streamlines hybrid DNS management for your IT teams, enabling you to build a unified private DNS namespace across both on-premises and AWS environments. You can delegate authority for a private subdomain from your on-premises infrastructure directly to Route 53 Resolver or, if you have a private hosted zone on Route 53, delegate your subdomain to on-premises DNS servers. Whether you manage your own private root and top-level domains (TLDs), such as some of our largest users, or you implement a decentralized private DNS namespace architecture, you can integrate Route 53 Resolver into your corporate private DNS delegation chain. This significantly reduces the operational burden of operating hybrid DNS at scale. Inbound and outbound delegation for Resolver endpoints is included as part of Resolver endpoints hourly and query-based pricing. Therefore, there are no other costs to use this feature. Go to the inbound and outbound delegation for Resolver endpoints documentation to get started.

About the author