Comparison of 3 DNS Configuration Methods When Joining EC2 to On-Premises Active Directory

Hello, I'm Soojae Lee from Classmethod.

In this article, we'll look at the DNS role required when joining a Windows Server EC2 to an existing on-premises Active Directory domain, and compare the behavior, configuration, and operational differences of three DNS configurations.

What Role Does DNS Play in Domain Joining

Domain joining is the process of registering a Windows server as a computer managed by AD, connecting it so that domain accounts and group policies can be used. EC2 instances can also join an existing AD if they can communicate with the on-premises Domain Controller (DC) as needed.
AWS explanation of existing AD integration

In this process, the EC2 instance first needs to know which DC to communicate with. Just because an administrator enters a domain name like ad.example.com doesn't mean Windows already knows the DC's IP address. This is where DNS is used to find the server providing AD services.

Simplified, the flow looks like this:

1. DC Discovery      EC2 → DNS lookup → Confirm name and address of DC candidates
2. Joining/Auth      EC2 → Direct communication with selected DC
3. Post-join Ops     EC2 → Uses DNS and DC for authentication and policy processing

Even after joining, you need to be able to continuously find the DC and related services for authentication and policy processing. This is why a DNS configuration that can resolve AD names is required even after domain joining.
Microsoft DC Discovery Process

Therefore, the three methods compared in this article are not differences in the ability to join an AD domain, but differences in how to create a path for EC2 to resolve AD names.

Why Doesn't the Default Configuration Work

For example, to join an EC2 instance to the ad.example.com domain, you first need to find the DC for this domain.
At this point, Windows queries DNS for an SRV record named _ldap._tcp.dc._msdcs.ad.example.com.

Simply put, this query is the process of asking "Which server acts as the DC in ad.example.com?" The response includes the hostname of the DC providing the LDAP service and the service port.

While an A record tells you the IPv4 address corresponding to a hostname, an SRV record tells you the hostname and port of the server providing a specific service.

Therefore, you need to verify both whether the SRV record can be queried, and whether the DC hostname received in the response can be resolved to an IP address.

The internal AD DNS server manages the records needed for DC discovery. If an EC2 instance uses the default DNS, AmazonProvidedDNS, and there is no configuration to forward DNS requests to the internal AD DNS, these records cannot be queried.

Looking at the item that specifies the DNS server in the VPC's default DHCP options:

domain-name-servers : AmazonProvidedDNS

If the EC2 instance is configured to send DNS requests directly to the internal AD DNS, or to forward requests through AmazonProvidedDNS, it can query the records needed for DC discovery. The three methods introduced below are ways to create this query path.
AWS AD and Route 53 integration example

What Do the Three Methods Change

First, it's easier to understand if you separate the server that EC2 sends DNS requests to first and where queries for the internal AD domain and AWS internal domains are each handled.

Methods A and B change the server that EC2 sends DNS requests to, to the internal DNS. The difference is that A changes it directly on the server, while B distributes the address through AWS DHCP settings.

Method C keeps the DNS used by EC2 as AWS DNS, and adds a path on the AWS side to forward DNS requests for the AD domain.

For example, if you only want to join app-server-01, you can use A to specify the DNS for that server. If you want to apply the internal DNS as a common setting for servers created in the same VPC going forward, you can consider B.
If you want to continue using AWS Private Hosted Zones while sending only AD domain DNS requests to the internal network, C becomes a candidate.

The configuration examples below assume that the VPC and on-premises are connected via Site-to-Site VPN. The AD domain is ad.example.com, and the internal DNS addresses are 192.168.1.10 and 192.168.1.11.

Before applying in practice, confirm the domain FQDN, and the addresses of DNS and DC with the AD administrator. The DNS and DC may be on the same server, but they are not necessarily the same.

Replace the addresses and resource IDs in the commands with values appropriate for your environment, and run the AWS CLI examples in Bash.

Method A: Statically Assign AD DNS to the Target EC2's NIC

This is the simplest method. You directly specify the internal DNS server address in the network adapter of the target server.

You can change only the selected servers while maintaining the existing default DNS settings of the VPC, making it good for applying to some servers first to verify. However, you need to manage that the same settings are applied when replacing or adding servers afterward.

How It Works

When you statically specify "Use the following DNS server addresses" on the NIC, the DNS server address distributed by DHCP is ignored on that adapter. This is because DHCP options are only used when the state is "Obtain DNS server address automatically."

This means there is no conflict even if the VPC's DHCP option set remains as AmazonProvidedDNS. Since the form is to continue receiving the IP address via DHCP and only specify DNS statically, the IP management method of the EC2 instance does not change either.

VPC DHCP options: Maintain AmazonProvidedDNS
    ├─ EC2 with manually specified DNS → VPN → Internal DNS
    └─ EC2 obtaining DNS automatically → AWS-provided DNS

The AWS Managed Microsoft AD manual join procedure in AWS Directory Service also guides you to specify DNS addresses on the NIC. When connecting to on-premises AD, specify the reachable internal AD DNS address.

Configuration Method

DNS addresses can be changed with PowerShell commands. Run with administrator privileges, and first check and record the actual adapter name and existing DNS settings. The IPs and domain names below are examples, and Ethernet must also be changed to the actual adapter name.

# Check current settings
Get-DnsClientServerAddress -AddressFamily IPv4

# Change to AD DNS server
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("192.168.1.10","192.168.1.11")

# Verify
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.example.com
nltest /dsgetdc:ad.example.com

For Resolve-DnsName, verify that the SRV response contains the expected DC hostname. nltest /dsgetdc is a command to verify that Windows can find the DC. Verification items for post-join behavior and existing services are covered in the final verification section.

For GUI: ncpa.cpl → Right-click adapter → Properties → IPv4 → "Use the following DNS server addresses".

If the server was originally receiving DNS automatically, change it back to "Obtain DNS server address automatically" or run the following command to revert. If DNS was manually specified before, restore to the original address you recorded.

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses

Precautions

Unless there is a separate DNS policy, general DNS queries from Windows using the changed adapter will go through the internal DNS. Therefore, you also need to check what names the internal DNS can resolve beyond the AD domain.

AWS Internal Name Resolution

If you are using Private Hosted Zones or private DNS for interface-type VPC endpoints, verify that those names can also be queried from the internal DNS. If there is no query path in the internal DNS, name resolution may fail after the DNS change.

In this case, you can configure conditional forwarding in the internal DNS to send DNS requests for specified domains only to the Route 53 Resolver inbound endpoint. The inbound endpoint is the entry point that receives requests sent from the internal DNS and forwards them to the VPC Resolver. AWS Hybrid DNS documentation

EC2 → Internal DNS
        ├─ AD domain → Self-response
        └─ AWS internal domain → Inbound endpoint → VPC Resolver

You need to configure so that Private Hosted Zone and interface-type VPC endpoint private DNS names required in the VPC using the inbound endpoint can be resolved.

Creating a new inbound endpoint incurs additional costs. Also, since EC2's DNS requests first go to the internal DNS, the dependency on the internal DNS and VPN remains even after adding this configuration.

Internet Name Resolution

A DNS server can answer queries for zones it manages, or resolve external names using forwarders or root hints. External name resolution does not fail simply because there are no forwarders. However, some environments restrict recursive queries or external communication so that only internal names can be queried.
Microsoft DNS forwarding explanation

Verify from the target EC2 whether external domain queries are possible by specifying each internal DNS. Success from an internal PC alone cannot verify firewalls or DNS access policies at the EC2 source.

nslookup www.google.com 192.168.1.10
nslookup www.google.com 192.168.1.11

This is a simple verification example for external queries. You also need to separately verify the AWS service addresses you actually use, AD SRV records, DC hostnames, and AWS internal domains.

Method B: Attach a Custom DHCP Option Set to the VPC

This is a method to specify the DNS server address to distribute to instances at the VPC level. If an instance obtains DNS automatically, there is no need to specify the address individually on the OS. Servers with DNS manually configured on their NIC need to be checked separately.

The Actual DNS Path Is the Same as Method A

Custom DHCP options are a bundle of network settings that AWS DHCP delivers to instances. It is not a function to change EC2 to receive IP addresses from an internal DHCP server, or to have DHCP handle DNS requests on its behalf.
AWS DHCP Options concepts

Setting distribution: AWS DHCP → Delivers internal DNS address to EC2
Name resolution: EC2 → VPN → Internal DNS

If the same internal DNS address is specified, the server to which A and B send DNS requests is the same. The difference is whether to manage settings per server or distribute them as VPC defaults. Therefore, the same precautions apply: the internal DNS must be able to resolve external names or AWS internal names.

For example, if you want to join only some Windows instances to AD but there are also Linux batch servers in the same VPC, Method B may also affect the DNS settings of those servers. Rather than only counting AD join targets, you need to also check the servers that automatically receive DNS in that VPC and the names those servers query.

Configuration Method

Create a new DHCP option set and attach it to the VPC. Only one option set can be attached per VPC, and different sets cannot be applied per subnet.

# 1. Create DHCP option set
aws ec2 create-dhcp-options \
  --dhcp-configurations \
    "Key=domain-name-servers,Values=192.168.1.10,192.168.1.11" \
    "Key=domain-name,Values=ad.example.com"

# 2. Attach to VPC
aws ec2 associate-dhcp-options \
  --dhcp-options-id dopt-xxxxxxxxxxxxxxxxx \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx

The domain-name in the example is the DNS search suffix. Setting this value does not automatically join AD. Also check existing suffixes and other DHCP options such as NTP, and reflect the necessary values in the new set.

Confirm the new DhcpOptionsId from the first command's result and use it in the second command. Also record the existing option set ID for reverting. Creating a new option set alone does not change the instance settings; you need to attach it to the VPC with the second command.

Constraints to Be Aware Of

1. Cannot be modified after creation

Important: You can't modify the DHCP options set after you create the set. To modify your DHCP options set, create a new DHCP options set with the correct parameters and associate it with your VPC.

— Why aren't the configuration parameters of my DHCP options set passed to instances in the VPC?

To change the DNS server, you need to create a new one and re-attach it to the VPC. If you leave the existing option set without deleting it, you can re-attach it when reverting. However, reverting also takes time as it depends on the DHCP renewal timing of each instance.

2. Mixing AmazonProvidedDNS and internal DNS is not recommended

You can enter either the AmazonProvidedDNS or custom domain name servers. Using both might cause unexpected behavior. Therefore, it's a best practice to use either AmazonProvidedDNS, or a custom domain name server.

You cannot implement branching like "internal DNS for AD domain only, AWS DNS for the rest" using only the DNS server list in DHCP options. If you need per-name forwarding, use the conditional forwarding in the internal DNS described in Method A. AWS DHCP options configuration guide

3. Timing of application

Reboot is not required. It takes effect when the DHCP lease is automatically renewed. If quick application is needed, manually renew on the OS.

ipconfig /renew
ipconfig /all

In ipconfig /all, verify that the DNS server list for the target adapter has changed. Immediately after changing the VPC association, servers using the old DNS and servers using the new DNS may be mixed due to differences in lease renewal timing. It is best not to conclude that the full rollout is complete based on success on a single representative server.

Also, even if two DNS servers are specified, if both servers depend on the same VPN path, a line failure affects them together. The number of DNS servers and the availability of communication paths should be examined separately.

Method C: Route 53 Resolver Outbound Endpoint + Forwarding Rule

This is a method of keeping the AWS-provided DNS as-is, and forwarding DNS requests for specific domains from the VPC Resolver only to the internal DNS.

For example, if there is a rule for ad.example.com, the name used for DC discovery, _ldap._tcp.dc._msdcs.ad.example.com, is also included in the forwarding targets. Results received from AD DNS are returned to the EC2 instance through the Resolver.

Queries for general external domains without other rules, or queries for Private Hosted Zones attached to the VPC, use the existing AWS DNS configuration. AWS outbound forwarding explanation

EC2 → AWS-provided DNS (VPC+2 Resolver)
        ├─ ad.example.com query → Outbound endpoint → VPN → Internal DNS
        └─ Other domain queries → Processed by AWS-provided DNS as-is

Components

1. Outbound endpoint — Creates ENIs in 2 or more subnets in different AZs. A dedicated security group is required, and outbound TCP/UDP 53 toward the internal DNS must be allowed
2. Forwarding Rule — Specifies the target domain name and the IP of the DNS server to forward to
3. Associating the rule with a VPC

Separating the role of each component: the endpoint is the network path through which DNS requests exit to the internal DNS; the rule is the condition that determines which domain requests to forward; and the VPC association is the setting that determines to which VPCs the rule applies. If you only create an endpoint or only create a rule, DNS requests from the desired VPC will not be automatically forwarded.

DNS requests forwarded in Method C originate from the IP address of the outbound endpoint. Therefore, verify that DNS communication originating from the outbound endpoint's IP is also permitted in the on-premises firewall. Also check the routing and NACL of the subnet where the endpoint is located, and the path for the internal DNS response to return.

Configuration Method

In the console: Route 53 → Outbound endpoints → Create → Create rule. With the CLI, it's as follows.

1. Create Outbound Endpoint

Specify 2 or more subnets in different AZs.

aws route53resolver create-resolver-endpoint \
  --name ad-outbound \
  --direction OUTBOUND \
  --creator-request-id ad-outbound-001 \
  --security-group-ids sg-xxxxxxxxxxxxxxxxx \
  --ip-addresses SubnetId=subnet-aaaaaaaaaaaaaaaaa SubnetId=subnet-bbbbbbbbbbbbbbbbb

Put the endpoint ID received in the response into --resolver-endpoint-id in the next step.

2. Verify Endpoint Status

aws route53resolver get-resolver-endpoint \
  --resolver-endpoint-id rslvr-out-xxxxxxxxxxxxxxxxx \
  --query 'ResolverEndpoint.Status' \
  --output text

Endpoint creation proceeds asynchronously. If the status is CREATING, wait and check again; when it becomes OPERATIONAL, proceed to the next step. AWS Endpoint status query

3. Create Forwarding Rule

Specify the endpoint ID received in Step 1 and the IP addresses of the internal DNS.

aws route53resolver create-resolver-rule \
  --name forward-ad-domain \
  --creator-request-id ad-rule-001 \
  --rule-type FORWARD \
  --domain-name ad.example.com \
  --resolver-endpoint-id rslvr-out-xxxxxxxxxxxxxxxxx \
  --target-ips "Ip=192.168.1.10" "Ip=192.168.1.11"

Put the rule ID received in the response into --resolver-rule-id in the next step.

4. Associate the Rule with a VPC

Specify the ID of the VPC to apply the forwarding rule to.

aws route53resolver associate-resolver-rule \
  --resolver-rule-id rslvr-rr-xxxxxxxxxxxxxxxxx \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx \
  --name assoc-ad-rule

The EC2 instance verifying Method C must use AmazonProvidedDNS distributed via the VPC's DHCP options. If the internal DNS is manually specified on the NIC, DNS requests will not go through the VPC Resolver, so first check the DNS server address used by the EC2 instance.

When integrating with AD, also consider reverse lookups (in-addr.arpa) used by applications and operations tools along with the forward lookup zone. A reverse forwarding rule is not mandatory for all domain joins.

When adding a reverse forwarding rule, also check the priority between the required address ranges and the VPC's automatically defined reverse rules. The AWS blog's AD and Route 53 integration example has specific configurations summarized.

Cost

Charges are incurred for the outbound endpoint based on usage time and the number of DNS queries processed.

A minimum of 2 IPs (ENIs) is required for an endpoint. Using 2 ENIs for 730 hours per month is 2 × $0.125 × 730 = $182.50. This varies depending on actual usage hours and the number of ENIs, and DNS query charges passing through the endpoint are separate. AWS official pricing

Reverting

When reverting forwarding settings applied to a specific VPC, disassociate that VPC from the rule or restore the previous rule association. Deleting a shared endpoint or rule may affect other VPCs, so first work based on the association of the target VPC. AWS rule disassociation guide

If you only disassociate the rule, endpoint costs will continue to be incurred. To also clean up costs, verify that it is not being used by other rules and VPCs, then delete unnecessary rules and endpoints. If there are servers already joined to AD, also verify that necessary AD name resolution is possible after reverting.

Comparing the 3 Methods

The failure impact for A and B refers to the case where all internal DNS servers used by the applicable scope are unreachable. The NIC settings of A and the DHCP options of B do not have per-domain branching functionality; conditional forwarding must be added to the internal DNS.

"No additional cost" for A and B refers to the DNS address configuration. Creating a new inbound endpoint incurs separate costs. The monthly cost example for C is based on 2 ENIs used for 730 hours.

When reverting B, re-attach the original DHCP option set and confirm the DHCP renewal of the instances. For C, disassociate the rule from the target VPC or restore the previous association; there is no need to delete shared endpoints.

What Criteria to Use When Choosing

If the target is only a small number of servers, you can first consider Method A. If all necessary names can be resolved through the existing internal DNS, it can be applied with only the NIC settings of the target servers. Since the servers to be changed can be limited, it is also convenient for applying to some servers first.

If many instances in the VPC need to commonly use the internal DNS, Method B is convenient for management. Since it also applies to new instances that receive DNS automatically, it becomes more advantageous as the number of instances increases. However, if all specified internal DNS servers become unreachable, it may affect general name resolution for instances using that configuration.

Consider Method C if the following apply:

• You use Private Hosted Zones or VPC endpoints and want to maintain AWS internal name resolution without relying on the internal DNS
• You want to limit the DNS impact of an internal DNS failure to the forwarded target domains
• The same AD name resolution is needed across multiple VPCs (cost distribution through endpoint sharing)

If there is already a path to query AWS internal names from the internal DNS, it can be used with A and B. If you need to configure it from scratch, compare the cost of adding an inbound endpoint with the cost of the outbound endpoint for C, and decide together whether to also route AWS internal name queries through the VPN and internal DNS.

What to Verify After Applying

Regardless of which of the three methods you choose, it is easier to find problems if you separate queries sent directly to the internal DNS from queries using the DNS configured on the EC2 instance.

Below are read-only examples to run on the target EC2.

# Check if the internal DNS itself responds to AD records
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.ad.example.com -Type SRV -Server 192.168.1.10
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.ad.example.com -Type SRV -Server 192.168.1.11

# Verify the same name using the current EC2's DNS settings
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.ad.example.com -Type SRV

Specifying -Server queries the record from the specified DNS server. Omitting it uses the DNS configured on the interface, which can be used to verify internal DNS settings in A and B, or the forwarding configuration through VPC Resolver in C. Microsoft Resolve-DnsName explanation

However, in Method C, checking by querying the internal DNS directly is meaningful only when TCP/UDP 53 communication from EC2 to the internal DNS is permitted. Since the actual forwarding path originates from the outbound endpoint, do not conclude about C's behavior based solely on the success or failure of a direct query.

Verification targets are not limited to AD names. Also compare the connection targets of applications that were working normally before the change and AWS internal names under the same conditions.

This table is not a diagnostic table for confirming causes, but a starting point for narrowing down the next verification scope. When domain joining fails, you can also check Windows' C:\Windows\Debug\NetSetup.log. Microsoft domain join troubleshooting guide

For operational tasks, it is better to decide the timing for a rollback decision in advance. After a DNS change, verify name resolution not only for AD but also for existing services, and after proceeding with joining and rebooting, verify login and business service operation again. Since reverting DNS settings and leaving the AD domain are separate tasks, the recovery scope for already-joined servers must be determined separately.

Conclusion

When choosing a DNS configuration, it helps to first consider "where to manage the branching of name resolution" and "how far to allow the scope of impact from changes and failures". You should also compare whether existing DNS configurations can be leveraged and any additional costs.

You can check AWS-side configurations such as Private Hosted Zones and endpoints in the console, and confirm the internal DNS's recursive query and conditional forwarding settings together with the person in charge.

Preparing a checklist of preliminary confirmation items before the work reduces surprises on the day. I hope this article helps with that decision.

Thank you for reading. If you have any questions or other opinions, please feel free to contact me at must01940 gmail.