There are times when your client systems must resolve a Microsoft Active Directory’s Fully Qualified Domain Name (FQDN) before they can join a domain. Each VPC in your AWS environment is provisioned with a DNS resolver powered by Amazon Route 53. We call this an AmazonProvidedDNS. This resolver runs on the second IPv4 address from the start of your VPC’s address space, the VPC+2 address. However, the AmazonProvidedDNS is not aware of your directory’s FQDN. This blog post discusses some approaches to help address this challenge.

I explain how to provide DNS resolution for your AWS Directory Service for Microsoft Active Directory, AWS Directory Service Simple Active Directory, or a Microsoft Active Directory running on an EC2 instance. This is done by implementing a Route 53 Resolver Endpoint to complement the AmazonProvidedDNS (Amazon Route 53 Resolver server) in an Amazon Virtual Private Cloud (VPC)

An AmazonProvidedDNS resolver is created as part of your VPC and resolves a number of other AWS services (such as AWS PrivateLink and VPC endpoints, Route 53 Private Hosted Zones or Amazon Elastic File System EFS). For more information about AmazonProvidedDNS, the DHCP options sets for your VPC entry in the Amazon VPC User Guide may be helpful.

Before your EC2 client instances and managed services are able to authenticate and join the AWS Managed Microsoft AD, they must resolve the directory’s fully qualified domain name (FQDN). On the flip side, the DNS service running on the Directory Service is NOT aware of any other AWS Services that exist in the VPC such as PrivateLink Endpoints, Private Hosted Zones, Amazon EFS, etc.

The Directory Service domain controllers act as an authoritative DNS server for its own FQDN (example.aws) and forward all other queries using forwarders and conditional forwarders.

Note: in December 20th 2022 we introduced a change in the default behavior of the DNS resolver in AWS Managed AD. Starting this date, all new directories are created with a forwarder for all non-authoritative queries to the +2 IP address of the VPC. This means, the same steps suggested on Method 1 below are already applied by default for new directories you create. Preexisting directories are not updated as part of this change.

Prerequisites:

To follow the steps in this blog, you will need:

1. An AWS account with console access.
2. A VPC and two private subnets. For detailed steps see the Work with VPCs and subnets entry in the VPC User Guide.
3. An AWS Managed Active Directory Service created by following the steps in our Directory Service Administration Guide. My Managed AD domain name is: example.aws. The IP addresses assigned to the two Domain Controllers of my directory are: 10.24.34.213 and 10.24.35.137.
4. A VPC interface endpoint for the EC2 service (ec2.region_name.amazonaws.com) following the AWS PrivateLink documentation.
5. A Route 53 Private Hosted Zone that you created following the steps in the Amazon Route 53 Developer Guide. My zone’s FQDN is example.myprivatehostedzone.net.

Section 1: Understanding the flow of DNS queries within the VPC

If we launch an EC2 instance in our VPC and test the DNS resolution for the same service that we created VPC Endpoint for, we get a local IPv4 address as an answer. The default configuration of the DHCP Option set includes the VPC’s AmazonProvidedDNS as DNS server.

If we make the same query to an internet DNS service from the same instance, the response is the internet IP address corresponding to the endpoint’s public DNS name. This is shown in the following screenshot (figure 1).

Figure 1: A DNS query showing a response containing a local VPC IP address.

Similarly, if we test the DNS resolution for our Private Hosted Zone we get an authoritative answer from AmazonProvidedDNS. But, if we try to get the same resolution from an internet DNS service, it is not aware of our Private Hosted Zone (figure 2).

Figure 2: A DNS query showing a ‘non-existent domain’ response.

In the following diagram (figure 3) I illustrate the flow of DNS resolution in the VPC as it happens by default.

Figure 3: flow of DNS resolution in the VPC when there is no Directory present.

Section 2: Resolving your Directory Service using Route 53 Resolver Endpoints

The first approach to tackling the Microsoft Active Directory FQDN challenge is by taking advantage of AWS Route 53 Resolver Endpoints. A Route 53 Resolver Endpoint is a customer-managed resolver consisting of one or more Elastic Network Interfaces (ENIs) deployed on your VPC.

Resolver Endpoints are classified into two types:

• Inbound Endpoint: provides DNS resolution of AWS resources, such as EC2 instances, for your corporate network.
• Outbound Endpoint: provides resolution of specific DNS names that you configure using forwarding rules to your VPC.

A Resolver Endpoint has a limit of 10,000 queries per second per ENI and can consist of up to six ENIs.

Outbound Resolver Endpoints host Forwarding Rules that forward queries for specified domain names to specific IP addresses.

Solution Overview:

The following diagram (figure 4) shows the flow of DNS resolution using Route 53 Resolver Endpoints to integrate your Directory Service’s DNS name into your VPC’s resolver.

Figure 4: Showing the proposed solution where DNS resolution goes through the AmzonProvidedDNS and is complimented by R53 Resolver Endpoints.

In this example, we created an Outbound Endpoint that handles DNS queries regarding my AWS Managed Microsoft AD’s FQDN coming from my VPC. To achieve this goal, we created a Forwarding Rule inside my Endpoint that forwards any queries for example.aws originating from the VPC to the AWS Managed Microsoft AD IP addresses.

Step 1: Create Outbound Resolver

We start by Configuring outbound forwarding. Follow the steps provided in Amazon Route 53 Developer Guide to:

1. Create an Outbound Endpoint and associate it to our VPC.
2. Select at least one Security Group containing rules that allow DNS traffic to and from our Endpoint. (figure 5).
   

   Figure 5: First portion of the New Outbound Endpoint wizard showing the endpoint’s name, VPC ID and associated security group.

3. Deploy at least two IP addresses on different Availability Zones (each will be hosted on a dedicated ENI) to ensure high availability (figure 6).

Figure 6: Second portion of the New Outbound Endpoint wizard showing two IP addresses deployed in two different subnets.

Step 2: Create Forwarding Rule

We will now create Forwarding Rules for the DNS domains that I want to provide name resolution for. A Forwarding Rule contains the information necessary to handle queries for a given DNS domain. These queries are handled by forwarding the requests to the IP address or addresses, that can resolve them.

In this case, we create a Forwarding Rule that points the FQDN of the AWS Managed Microsoft AD to the IP addresses of the domain controllers. Following the steps provided in the Amazon Route 53 Developer Guide we:

1. Create a Forwarding Rule for my AWS Managed AD domain name: example.aws and associate this Rule to the Endpoint, and to any VPC hosting resources that need to resolve this DNS domain (figure 7).
2. Point the forwarding rule to the IP addresses of my AWS Managed Microsoft AD: 10.24.34.213 and 10.24.35.137 (figure 8).

Figure 7: first portion of the New Rule wizard showing the rule’s name, type, target domain, VPCs and associated endpoint.

Figure 8: second portion of the New Rule wizard showing the IP addresses we are forwarding to for resolution.

Step 3: Testing Active Directory FQDN resolution

Now that the Outbound Endpoint and Forwarding Rule are created, any resource in the VPC that queries the AmazonProvidedDNS as its DNS resolver is able seamlessly resolve for my AWS Managed Microsoft AD domain’s FQDN, as well as any AWS resources on the VPC such as (interface) VPC Endpoints, R53 Private Hosted Zones, EFS etc. (figure 9).

Figure 9: a screenshot of a DNS query showing a response from the Route 53 Resolver Endpoint.

Section 3: Concentrating DNS Resolution through your Active Directory

If you are working with a smaller environment, such as where there is a single VPC, a simpler DNS design might better serve your needs. This design concentrates DNS resolution for all resources in a VPC on your AWS Managed Microsoft AD service. It then forwards all queries where that AWS Managed Microsoft AD is not authoritative to the AmazonProvidedDNS (figure 10).

Different from the Outbound Endpoint, resources in other VPCs need a Peering Connection in order to reach the EC2 instances hosting your Microsoft Active Directory or AWS Managed AD instances acting as DNS servers. In addition, the AmazonProvidedDNS in the VPC has a limit of 1024 requests per second per source ENI. For these reasons, you should consider this alternative only for single VPC use cases or small workloads.

Method 1. (recommended). Update the Global Forwarder on each Active Directory or AWS Managed AD Domain Controller instance to the corresponding IP address of the AmazonProvidedDNS on the VPC, the VPC+2 address.

Method 2. Create an AD integrated DNS Conditional Forwarder for region_name.amazonaws.com in the AWS Managed AD DNS Server service properties.

Start by creating a new DHCP Option Set for the VPC and populate the domain-name-servers with the IP addresses of your Microsoft Active Directory or AWS Managed Microsoft AD domain controllers instead of the AmazonProvidedDNS of the VPC.

Figure 10: Showing DNS resolution concentrated on the AWS Managed AD

Note: If you prefer to setup your EC2 instances client DNS settings manually, the following documentation may help:

• Manually join a Windows instance
• My private Amazon EC2 instance is running Amazon Linux, Ubuntu, or RHEL. How do I assign a static DNS server to the EC2 instance that persists during reboot?

To create a DHCP options set for your directory and change the DHCP option set associated with a VPC you can follow the steps in the AWS Directory Service Administration Guide.

In order to complete the steps in any of these methods, you need to log into a domain-joined Windows instance with an account with administrative permissions on the domain. To do this, first, install the management tools for DNS server, open an administrator PowerShell prompt, and run:

Install-WindowsFeature RSAT-DNS-Server

Method 1: Update the Global Forwarder on each Microsoft Active Directory or AWS Managed Microsoft AD Domain Controller instance to the AmazonProvidedDNS of the VPC.

1. Open the DNS management console. Under Connect to DNS Server chose The following computer and enter the IP address of one of your Microsoft Active Directory or Managed AD domain controllers.

2. Right click on the server node and select Properties. Go to the Forwarders Tab and Click Edit

3. Type the IP address of the VPC’s AmazonProvidedDNS (in my case 10.24.34.2) and press Enter

4. (AWS Managed Microsoft AD only) Select 169.254.169.253 and click Delete

5. Click OK. Then Click on Apply and OK to close.

NOTE: this is a local server configuration. You must repeat the steps on each AWS Managed Microsoft AD domain controller or Microsoft Active Directory domain controller that will act as DNS resolver for the VPC.

Method 2: Create an AD integrated Conditional Forwarder for region_name.amazonaws.com

1. Open the DNS management console. Under Connect to DNS Server chose The following computer and enter the name of your Managed AD domain, in my case example.aws
   
   
2. Expand the domain name’s node. Right click on Conditional Forwarders and chose New Conditional Forwarder
   
   
3. Enter the region + amazonaws.com, in my case eu-west-1.amazonaws.com

• • Enter the IP address of the AmazonProvidedDNS on the VPC, in my case 10.24.34.2 (ignore the red cross since the resolvers’ FQDN will not be resolved)
    

    Make sure to check the option Store this conditional forwarder in Active Directory, and replicate as followsSelect the option All DNS servers in the forest from the drop down menu.Not doing so will result in uneven DNS responses from the domain controllers

  • Leave the rest of the options as default and click OK

Repeat the steps for any other domain you need to conditionally forward such as any Private Hosted Zones associated to the VPC.

Cleaning Up

Disassociate the Forwarding Rule from all VPC, and then delete the Rule. Do this for all rules you have created. Once all rules are deleted, disassociate the Resolver Endpoint from all VPCs, and then delete the Resolver Endpoint. Delete the PrivateLink (VPC Endpoint) for EC2 service. Lastly, delete your Directory.

Summary

In this blog post, I walked through the process of customizing the DNS architecture of an Amazon VPC. By taking advantage of Route 53 Resolver Endpoints, you can build a highly available DNS solution that seamlessly provides resolution for Microsoft Active Directory services running in your VPC, as well as other AWS Services. You can use the full capabilities of Route53 DNS to connect your Microsoft Active Directory with AWS Applications and Services. We explored how to use Route 53 Resolver Endpoint to complement your DNS solution design and achieve seamless DNS resolution for your directory services, such as AWS Managed Microsoft Active Directory, Simple Active Directory or Self-Managed Active Directory on EC2 running on the same VPC.
With Microsoft Active Directory DNS integration, you can now launch additional AWS Services that are clients to the Directory Service. These can be domain joined EC2 Instances, Amazon Relational Database Service and Amazon FSx for Windows File Server. You will be certain that all necessary DNS resolution will already be in place. At the same time, you can accommodate new custom DNS providers in your VPC by easily creating or editing new Forwarder Rules.

Additional Resources

For more information about DNS support for your VPC visit the Amazon Virtual Private Cloud User Guide. To learn more about Route 53 Resolver Endpoints, visit the Amazon Route 53 Developer Guide.