Introducing dual-stack and IPv6-only support for Amazon Route 53 Resolver Endpoints

Organizations are adopting IPv6 because of public IPv4 address and private IPv4 address (RFC1918) space exhaustion caused by the ongoing growth of the internet, particularly in the fields of mobile applications, Internet of Things (IoT), and application modernization. This is motivating many AWS customers to transition from IPv4-only to dual-stack (IPv4 and IPv6) and IPv6-only environments. AWS has supported IPv6 since 2011, and we are continuously expanding IPv6 support to more AWS services. In this post, we discuss how you can use dual-stack and IPv6-only Amazon Route 53 Resolver Endpoints to forward traffic to and resolve traffic from on-premises DNS servers with IPv6 addresses. We explore how you can centralize Route 53 Resolver Inbound Endpoints using private hosted zone to Amazon Virtual Private Cloud (Amazon VPC) association spread across multiple VPCs and multiple accounts. We also discuss deployment patterns for centralizing Route 53 Resolver Outbound Endpoints and sharing forwarding rules with multiple VPCs in multiple accounts using AWS Resource Access Manager (AWS RAM).

AWS introduced Amazon Route 53 Resolver Endpoints in late 2018 to enable seamless Domain Name System (DNS) query resolution across your entire hybrid network. Each VPC has a Route 53 Resolver at a VPC+2 IP address and resources within the VPC connect to it. Amazon Route 53 Resolver responds recursively to DNS queries from AWS resources for public records, Amazon VPC-specific DNS names, and Route 53 private hosted zones, and is available by default in all VPCs. Since Route 53 Resolver is not available outside of your VPC, you can use Route 53 Resolver Inbound and Outbound Endpoints for resolving DNS queries between VPCs and your on-premises network.

Inbound Resolver Endpoints allow DNS queries to your VPC from your on-premises network or another VPC. Outbound Resolver Endpoints allow DNS queries from your VPC to your on-premises network or another VPC. Check out the getting started page in our documentation for instructions on how to set up Route 53 Resolver Inbound and Outbound Endpoints.

With the recent announcement of IPv6 support for Route 53 Resolver Endpoints, you can now forward traffic to and resolve traffic from on-premises DNS servers with IPv6 addresses. You can select from IPv4-only, IPv6-only, or dual-stack IP addresses for Inbound and Outbound Endpoints.

Here are few things to keep in mind before we get started:

• Dual-stack VPC: Today, each VPC has a primary IPv4 CIDR and can have secondary CIDRs that can include IPv4 and IPv6. Configuring both IPv4 and IPv6 addresses makes it a dual-stack VPC. Amazon VPC features a built-in DNS resolver (Route 53 Resolver) that lives at VPC_CIDR_BASE + 2 and 169.254.169.253. IPv6 enabled Nitro instances can access the service through fd00:ec2::253.
• Resolver Endpoints: If you have deployed Inbound and Outbound Resolver Endpoints in IPv4-only, you can modify your configuration to be dual-stack.
• IPv6-only Resolver Endpoints: You can create a new IPv6-only Resolver Endpoint in an existing IPv6-only subnet. However, you cannot migrate an existing IPv4-only Resolver Endpoint to IPv6-only Resolver Endpoint directly.
• DNS64 and NAT64: Helps facilitate network communication and DNS lookup between IPv6-only network to an IPv4-only network.

Solution overview

In our solution, we use the new IPv6 capabilities of Route 53 Resolver Endpoints. The primary use cases that we cover are:

• Centralized Route 53 Resolver Inbound Endpoint (dual-stack and IPv6-only subnets) deployment using Private Hosted Zone to VPC association
• Centralized Route 53 Resolver Outbound Endpoint (dual-stack and IPv6-only subnets) to on-premises resources (IPv6) using AWS RAM for cross account resolver rule sharing.
• Centralized Route 53 Resolver Outbound Endpoint (IPv6-only subnets) to on-premises resources (IPv4) using AWS RAM for resolver rule sharing.

Prerequisites

Before we get started, there are several things we need to have in place which includes AWS Direct Connect or AWS Site-to-Site VPN connection for DNS traffic to flow between on-premises and AWS. If you have an existing IPv4 environment in AWS, then you may already have one or both of these connections. In our example, we have the items necessary to support IPv6 and IPv4. However, the same setup can also exist for an IPv6-only environment where you have only IPv6-only subnets in your VPC and the network connectivity is also supporting IPv6-only traffic.

If you have an existing IPv4-only VPC, and you have configured resources in your subnet to use IPv4 only, then you can enable IPv6 support for your VPC and resources. Your VPC can operate in dual-stack mode and your resources can communicate over IPv4, IPv6, or both. IPv4 and IPv6 communication are independent of each other. For example, if you have Route 53 Resolver Endpoints deployed on an IPv4-only subnet, then you can take the following steps to move to a dual-stack environment.

1. Associate an IPv6 CIDR block with your VPC and subnets.
2. Edit your existing IPv4 Route 53 Resolver (Inbound / Outbound) Endpoints type to be dual-stack.

Note that once you have moved an existing IPv4 Route 53 Resolver Endpoint to be dual-stack, you continue to have the existing IPv4 address, which can simplify the migration process.

The following are some of the key components we list that are necessary to enable IPv6 connectivity.

• Amazon VPC
  • Create a VPC with IPv4 and IPv6 CIDR blocks. If you have an existing VPC with only IPv4, then you can edit the CIDRs and add IPv6 to your existing VPC.
  • Create a VPC Subnet as dual-stack or IPv6-only.
• AWS Transit Gateway (TGW)
  • Create a TGW and attach VPCs to it, and choose dual-stack subnets for VPC attachments.
• AWS Direct Connect
  • Create a Transit Virtual Interface (VIF) with a IPv6 BGP peering session. A single transit VIF can have two peering sessions, one for IPv4 and one for IPv6.
• AWS Site-to-Site VPN
  • Create a VPN connection with Tunnel inside IP version set to IPv6. If you have an existing VPN with Tunnel inside IP version as IPv4, then you must create a new VPN connection with IPv6 option selected. The result is that you have two VPN Connections, one for IPv4 and one for IPv6 traffic.  Please note AWS Site-to-Site VPN with IPv6 support can only be terminated on TGW.

The following diagram (figure 1) shows that Application VPC A, Application VPC B, and Shared Services VPC are connected to Transit Gateway using VPC attachments where the Transit Gateway is shared across other accounts using AWS RAM. As a networking best practice, we recommend that you create Route 53 Resolver Endpoints (Inbound and Outbound) in a Shared Services VPC in the networking account.

Figure 1: Multi-account VPCs connected through Transit Gateway and then to on-premises network through Direct Connect and AWS Site-to Site VPN

Depending on your use case, you can choose to deploy Route 53 Resolver Endpoints (Inbound and Outbound) either dual-stack or IPv6-only. However, it isn’t necessary to deploy both if you have on-premises resources running dual-stack, as you can opt to use endpoints that are dual-stack. We recommend you deploy Route 53 Resolver Endpoints in multiple Availability Zones (AZ) for high availability. For example, when you deploy Route 53 Resolver Endpoints, AWS places an Elastic Network Interface (ENI) in the subnet you select. Each ENI can process up to 10,000 DNS queries per second (QPS). If you are using a dual-stack setup for your Route 53 Resolver Endpoints, then you share this quota between IPv4 and IPv6 queries.

Centralized Route 53 Resolver Inbound Endpoint (dual-stack and IPv6-only subnets) deployment using Private Hosted Zone to VPC association

For this scenario, we have deployed a dual-stack Route 53 Resolver Inbound Endpoint in a Shared Services VPC within Shared Services Account. Application VPC A and Application VPC B contain workloads that the on-premises application must reach. An Amazon Elastic Compute Cloud (Amazon EC2) instance inside Application VPC A has both IPv4 and IPv6 addresses, while an instance inside Application VPC B has IPv6-only addresses. Each application owner creates a private hosted zone and manages records within it. Since Application VPC A and Application VPC B are in different accounts, you create cross-account associations of private hosted zones. For more information, refer to the associating a private hosted zone with a VPC on a different AWS account entry in our documentation.

Figure 2: Route 53 Resolver Inbound Endpoint – Multiple VPCs (dual-stack and IPv6-only subnets) using Private Hosted Zone to VPC association

Let’s understand the DNS query flow originating from your on-premises application destined to an EC2 instance inside Application VPC A and Application VPC B, as shown in the preceding diagram (figure 2).

1. The on-premises application server makes an AAAA DNS query for www.aws.example100.internal and www.aws.example200.internal and sends it to on-premises DNS resolver.
2. The on-premises DNS resolver has a conditional forwarder and forwards all DNS queries for “aws.example100.internal” and “aws.example200.internal” including their subdomains to the IPv6 addresses of the Route 53 Resolver Inbound Endpoint inside the Shared Services VPC over a Direct Connect connection or Site-to-Site VPN connection.
3. The Route 53 Resolver Inbound Endpoint service receives the query and processes it.
4. (4a) The Inbound Endpoint checks if the private hosted zone www.aws.example100.internal is associated with it. (4b) The VPC DNS resolver checks if the private hosted zone www.aws.example200.internal is associated with it.
5. Private Hosted Zone (aws.example100.internal) returns the IPv6 address 2001:db8:1234:1a00::abc associated with the EC2 instance from Application VPC A to the Route 53 Resolver Inbound Endpoint or Private Hosted Zone (aws.example200.internal), which then returns the IPv6 address 2001:db8:1234:2a00::abc associated with the EC2 instance from Application VPC B.
6. The Route 53 Resolver Inbound Endpoint sends the AAAA response back to the on-premises DNS resolver.
7. The on-premises DNS resolver returns the answer to the on-premises application.

If the Route 53 Resolver Inbound Endpoint is IPv6-only the preceding request response flow remains the same for the IPv4 DNS query originating from on-premises resources as long as the on-premises DNS resolver is using IPv6-only or dual-stack. If your on-premises DNS resolver only uses IPv4, and you make a DNS query to a Route 53 Resolver Inbound Endpoint in an IPv6-only subnet, this fails because the network is unreachable. To overcome this, deploy a Route 53 Resolver Inbound Endpoint in a dual-stack subnet.

Centralized Route 53 Resolver Outbound Endpoint (dual-stack and IPv6-only subnets) to on-premises resources (IPv6) using AWS RAM for cross account resolver rule sharing

For this scenario, we have deployed a dual-stack Route 53 Resolver Outbound Endpoint in a Shared Services VPC. The EC2 instance inside Application VPC A is deployed in a dual-stack subnet, while the EC2 instance inside Application VPC B is deployed in an IPv6-only subnet. To provide Application VPC A and Application VPC B access to the Route 53 Resolver Outbound Endpoint, we must share the resolver rules using AWS RAM from the Shared Services Account,  as shown in the following diagram (figure 3).

Figure 3: Route 53 Resolver Outbound Endpoint – Multiple VPCs (dual-stack and IPv6-only subnets) to on-premises resources (IPv6) using AWS RAM for cross account resolver rule sharing

1. (1a) The EC2 instance in the dual-stack subnet makes an AAAA DNS query for app.corp.internal and sends it to the Route 53 resolver within its own VPC. (1b) The EC2 instance in the IPv6-only subnet makes an AAAA DNS query for app.corp.internal and sends it to the Route 53 resolver within its own VPC.
2. When the DNS query reaches the Route 53 Resolver within the VPC of the EC2 instance, it is evaluated against the associated resolver rules. The DNS query is matched against any of the resolver rules associated with the VPC. Then, depending on the type of rule, the DNS query follows a different path. A Route 53 Resolver rule is configured to forward queries to app.corp.internal in the on-premises corporate data center.
3. (3a or 3b) If it matches a Forward Rule, then the DNS query is sent to the IPv6 addresses of the Outbound Endpoint in the Shared Services VPC. Note that network connectivity between the EC2 instance to Outbound Endpoint is not needed.
4. The Route 53 Resolver Outbound Endpoint forwards the query to the on-premises DNS resolver over the Direct Connect connection or Site-to-site VPN connection.
5. The on-premises DNS resolver returns the DNS query of app.corp.internal with the IPv6 address of 2001:db8:5678::abc to the Outbound Endpoint.
6. (6a) The Outbound Endpoint sends the DNS query response to the Route 53 resolver of Application VPC A. (6b) The Outbound Endpoint sends the DNS query response to the Route 53 resolver of Application VPC B.
7. (7a) and (7b) Route 53 Resolver provides the DNS query of app.corp.internal with IPv6 address of 2001:db8:5678::abc.

Centralized Route 53 Resolver Outbound Endpoint (IPv6-only subnets) to on-premises resources (IPv4) using AWS RAM for resolver rule sharing

For this scenario, we have deployed a dual-stack Route 53 Resolver Outbound Endpoint in a Shared Services VPC. The EC2 instance inside Application VPC A is deployed in an IPv6-only subnet and must connect with on-premises application using the IPv4 address. For this to function, you must enable DNS64 on the IPv6-only subnet within the Application VPC A and create a Private NAT Gateway to perform NAT64 translation. You add a route 64:ff9b::/96 pointing to the Private NAT Gateway in the route table used by Application VPC A. As for the Route 53 Resolver Outbound Endpoint resolver rules that are created in the Shared Services VPC, they are then shared using AWS RAM with Application VPC A, as shown in the following diagram (figure 4).

Figure 4: Route 53 Resolver Outbound Endpoint – Multiple VPCs (IPv6-only subnets) to on-premises resources (IPv4) using AWS RAM for resolver rule sharing

1. The EC2 instance in the IPv6-only subnet makes a DNS query for app.corp.internal and sends it to the Route 53 Resolver.
2. When the DNS query reaches the Route 53 Resolver within the VPC of the EC2 instance, it is evaluated against the associated resolver rules. The DNS query is matched against any of the resolver rules associated with the VPC. Depending on the type of rule, the DNS query follows a different path. A Route 53 Resolver rule is configured to forward queries to app.corp.internal in the on-premises corporate data center.
3. If it matches a Forward Rule, then the DNS query is sent to the IPv6 addresses of the Outbound Endpoint in the Shared Services VPC.
4. The Route 53 Resolver Outbound Endpoint forwards the query to the on-premises DNS resolver over the Direct Connect connection or Site-to-site VPN connection.
5. The on-premises DNS resolver returns the DNS query of app.corp.internal with the IPv4 address of 172.16.0.10 to the Outbound Endpoint.
6. The Outbound Endpoint sends the DNS query response to the Route 53 resolver of the Application VPC A.
7. With DNS64 enabled on the IPv6-only subnet, the Route 53 Resolver looks up the DNS response and does one of the following:
   a. If the record contains an IPv6 address, it returns the original record, and the connection is established without any translation over IPv6.
   b. If there is no IPv6 address associated with the destination in the DNS record, then the Route 53 resolver synthesizes an IPv6 record by prepending 64:ff9b::/96 to the IPv4 address in the record.
8. The Route 53 Resolver provides the DNS query response of app.corp.internal with an IPv6 address of 64:ff9b::ac10:a.
9. Now the EC2 instance in the IPv6-only subnet of Application VPC A has a synthesized IPv6 address. Network traffic is now routed through the Private NAT Gateway and NAT64 is performed before the packet reaches the on-premises Application Server.

Conclusion

In this post, we showed three network design architecture patterns that use Route 53 Resolver Inbound and Outbound Endpoint with support for dual-stack and IPv6-only. With this support, you can forward traffic to and resolve traffic from on-premises DNS servers with IPv6 addresses. As companies continue to expand the use of IPv6 it is important to have IPv6 support in a hybrid DNS environment. Get started today by implementing Route 53 Resolver Endpoints with IPv6 support for your hybrid cloud environments.