AWS internal zone delegation to route 53 with inbound endpoint as resolver

Introduction

The migration of computing loads from private clouds to public clouds takes time. As a rule, this is a process of complex transformation of processes and architecture. When working with DNS, most projects use the least resistance principle. The migration to using DNS as a service occurs instantly and to public zones. This is because essentially all Amazon services are public, and the concept of a private hosted zone is somewhat different:

• Private DNS in Amazon does not allow you to resolve records from unattached VPC from private addresses;
• You can set additional DNS servers in VPC Option to AmazonProvidedDNS, but it just doesn’t work due to the nature of the DNS service.

More detailed information on how AWS DNS works you can find here:

Integrating your Directory Service's DNS resolution with Amazon Route 53 Resolvers | Amazon Web…

Formulation of the problem

Management of the DNS service is divided into two parts.

An external, highly reliable service manages the public zone and is not used internally for the company’s infrastructure.

The private zone is managed using the Windows domain name management service. We have replication between different data centers for the reliability of the company’s work.

While creating a hybrid infrastructure, the company created direct connections to Amazon using direct connect or VPN and connected these tunnels to the transit gateway service. Now we can create connected VPC with private infrastructure on demand. We use address management manually or through IPAM.

The problem we faced:

1) We can use only one DNS type to control records for private zone via DHCP Optin Set (AmazonProvidedDNS or on-prem DNS);

2) When the connection is interrupted, and the private zone is used, DNS resolving stops working;

3) It is necessary to solve DNS management in the private zone through support because it requires changes in the acts of the director;

4) Internal zone management for other VPCs, to work with peering or any custom project-related infrastructure require

Resolution

The solution to this problem will be if we summarize everything in one resolver, namely the highly reliable managed service route53, and force on-prem to resolve only our subdomain under certain conditions.

For the VPC with resources, let’s set internal DNS via DHCP Option as a first resolver and a second AmazonProvidedDNS to provide DNS resolving in a case of VPN fault.

Then create separated resolver VPC to deploy Route53 Inbound resolver, turn on DNS hostnames and DNS resolution in the DNS support attributes for the VPC.

Then, associate the applicable private hosted zone with that VPC.

If the private hosted zone and the VPC are in the same account, then complete the following steps:

1. Open the Route 53 console.
2. In the navigation pane, choose Hosted Zones.
3. Choose the private hosted zone containing the records you want to query.
4. In the search bar, search for your VPC. Then, choose Associate New VPC.

If the private hosted zone and VPC are in different accounts, use the AWS Command Line Interface (AWS CLI) to perform cross-account association.

Confirm that your on-premises DNS server sends only recursive queries. Route 53 inbound resolver doesn’t support iterative queries.

Confirm that the routing table associated with the subnets where you created the inbound endpoint resolver includes a route to the on-premises network.

You must allow specific traffic using custom network access control lists (network ACLs) with the subnet where you created the inbound endpoint. Make sure that the network ACLs allow traffic on the following ports:

• UDP and TCP traffic to(Outbound NACL rule) the on-premises DNS server on destination port range 1024–65535.
• UDP and TCP traffic from(Inbound NACL rule) the on-premises DNS server on port 53.
• Any security group associated with the inbound must allow traffic on TCP and UDP port 53 from your on-premises DNS server IP address.

If you have a firewall between the on-premises network and AWS, the firewall must permit specific traffic. Make sure that it allows traffic on TCP and UDP port 53 for your on-premises DNS server IP addresses.

You must also establish connectivity to the inbound resolver endpoint IP addresses over the AWS Direct Connect connection.

Configure an inbound endpoint.

1. Open the Route 53 console.

2. In the navigation pane, choose Inbound endpoints.

3. On the navigation bar, choose the AWS Region for the VPC where you want to create the inbound endpoint.

4. Choose to Create an inbound endpoint.

5. Complete the General settings for the inbound endpoint. Choose a Security group for this endpoint that allows inbound UDP and TCP traffic from the remote network on destination port 53.

6. Choose 2–6 IP addresses for DNS queries. You can let Resolver choose IP addresses from the available IP addresses in the subnet. Or, you can specify the IP addresses. It’s a best practice to choose IP addresses in at least two Availability Zones.

7. For the Subnet of each IP address, choose subnets that have the following values:

Corresponding route tables: These route tables must include routes to the IP addresses of the DNS resolvers on your remote network through AWS Direct Connect or a VPN.

Network ACLs must allow UDP and TCP traffic from the remote network on destination port 53. Also, they must allow both UDP and TCP traffic to the remote network on the destination port range of 1024–65535. You might use a different range for your network ACLs depending on your client type.

8. (Optional) Complete the Tags section.

9. Choose to Create an inbound endpoint.

Note: There’s no FQDN for inbound Resolver. Therefore, Route 53 creates elastic network interfaces in the selected subnet when you create an inbound endpoint — the IP addresses of these network interface forward the DNS queries.

Use an inbound endpoint to resolve records in a private hosted zone from a remote network

Test your configuration

Before testing, confirm that your configuration align for the following conditions:

• The remote network’s DNS server must conditionally forward DNS queries for the private hosted zone’s domain name to the inbound endpoint’s IP addresses.
• The remote DNS server must forward DNS queries for the domain name instead of delegating the authority of the domain name to the inbound endpoint.
• Iterative DNS queries that are sent to the inbound endpoints time out. Inbound endpoints must support only recursive DNS queries. If the on-premises DNS server sends a DNS query with Recursion Desired set to 0 (false), then the inbound endpoint doesn’t provide an answer. You can find this information in the packet capture.
• If you use AWS Transit Gateway, then verify that the subnets are associated with Transit Gateway attachments. This is necessary to resolve DNS queries.

To test your configuration, perform DNS resolution for one of the records in the private hosted zone from a client on the remote network. In the following commands, replace RECORD_NAME and RECORD_TYPE with your relevant values:

For Linux or MacOS, run dig RECORD_NAME RECORD_TYPE, such as in the following example:

dig example.com A

For Windows, run nslookup RECORD_NAME RECORD_TYPE, such as in the following example:

nslookup example.com

To setup Condition Forwarder on-prem and to avoid this error:

A problem occurred while trying to add the conditional forwarded. A zone configuration occurred.

Need to do the following steps:

• create DNS delegation and wait for sync;
• create conditional forwarding (for Replica with the parameter -ReplicationScope Forest);
• after sync, delete the DNS delegation

Workaround

1 Open the DNS Manager

2 Navigate to DNS -> Server-Name -> Forward Lookup Zones -> example.com

3 Right Click on example.com, Click on New Delegation -> Next

4 Enter the Delegated domain (The host part). We want to use conditional forwarder for then Click on the Next button

Here we use the test as an example, so the host/domain we want to conditionally forward is test.example.com

5 In the New Name Server Record window

For Server fully qualified domain (FQDN): We enter the FQDN of the current Windows Server we are working on (Itself)

For IP Addresses of this NS record: We enter the IP address of the current Windows Server we are working on (Itself)

Ignore the error or cross icon if any

Click on the OK button

6 Click on the Next button, Click on the Finish button

7 Navigate to DNS -> Server-Name -> Conditional Forwarders

8 Right Click on Conditional Forwarders, and Click on New Conditional Forwarder…

For DNS Domain: Fill in the domain we want to forward conditionally. In our case, for example, it is test.example.com

For IP addresses of the primary servers: We should enter the DNS server to which we want to forward the DNS query for this domain.

Click on the OK button

9 Now we have successfully created a Conditional Forwarder for a domain/zone which exist on the current Windows Server/Windows DNS server/Domain Controller

https://dannyda.com/2022/04/20/how-to-fix-a-problem-occurred-while-trying-to-add-the-conditional-forwarder-a-zone-configuration-problem-occurred-on-microsoft-windows-server/

Conclusion

Rebuilt the hybrid system in such a way as to use native Amazon resolvers, we get the opportunity to build all security around the principle of privacy and reliability with redundancy at all levels. Effectively eliminating the weakest link in hybrid configurations.