Designing DNS for IPv6

The core concept of DNS is unchanged from IPv4. From a Layer 3 perspective, DNS is just another application, and therefore, by virtue of the OSI/ISO model provided abstraction, agnostic to the chosen network layer protocol.

Regardless of the IP version, there is a deep link between DNS and the IP layer. The DNS specification has adapted and introduced an additional type to accommodate IPv6 addresses. In IPv6 the equivalent of the IPv4 “A” records are AAAA records. This means that it is possible to use IPv4 as the network protocol to connect to a DNS server and resolve an IPv6 (AAAA) record.

PTR records

A pointer (PTR) record translates an IP address to its domain name. IPv6 addresses are reverse mapped under the domain IP6.ARPA. IPv6 reverse maps use a sequence of nibbles separated by dots with the suffix “.IP6.ARPA” as defined in RFC 3596. For example, the reverse lookup domain name corresponding to the address 2001:db8:1234:1a00:1:2:3:4 would be 4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.a.1.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa.

Alias records

Amazon Route 53 supports alias records. Route 53 alias records are mapped internally to the DNS name of alias targets such as AWS resources. Route 53 monitors the IP address associated with an alias target's DNS name for scaling actions and software updates. The authoritative response from Route 53 name servers contains an A record (for IPv4 addresses) or AAAA record (for IPv6 addresses) with the IP address of the alias target.

DNS resolution within a host

External configuration aside it is up to a host’s networking stack at runtime to resolve DNS records. When configured as dual-stack, most modern operating systems default to preferring IPv6. In other words, when a query for a FQDN returns both an A and AAAA record the OS prefers to use the AAAA record and establishes IPv6 connectivity to the target.

Note

It is up to an IPv6 enabled host’s operating system and network stack whether it will attempt to map a given FQDN to an IPv4 or IPv6 address. Ensure that IPv6-enabled hosts are able to resolve AAAA records, and that the network between it and its destination is routable to IPv6. A commonly observed misconfiguration in dual-stack setups is hosts resolving FQDNs to IPv6 addresses, but no end-to-end IPv6 routable path existing between source and destination. Happy Eyeballs (Fast Fallback) is an algorithm published by the IETF which can make dual-stack applications (those that understand both IPv4 and IPv6) more responsive to users by attempting to connect using both IPv4 and IPv6 at the same time (preferring IPv6). This avoids the usual problems faced by users with imperfect IPv6 connections or setups.

Amazon Route 53 DNS records

In AWS, Amazon Route 53 provides DNS capabilities. Route 53 provides features for two use cases:

• Public DNS for externally hosted content

• DNS capability within a VPC both from a resolver and authoritative name server standpoint

Public IPv6 DNS resolution

For externally queryable DNS, you can use Route 53 public hosted zones, with both A and AAAA records. Route 53 health checks support health checking IPv6 services. The name servers exist both for IPv4 and IPv6, meaning clients wanting to resolve a FQDN hosted on Route 53 public hosted zone can do so natively.

DNS resolution within a VPC

Amazon VPC comes with Route 53 Resolver, which provides a built-in capability for resolving DNS names. This resolver is reachable either on 169.254.169.253 or VPC_CIDR_NETWORK + 2 for IPv4 and fd00:ec2::253 for Nitro-based IPv6 hosts. Requests sent to this resolver are resolved against the combination of private hosted zones associated with the VPC, and any (shared) resolver rules. For more information, refer to Resolving DNS queries between VPCs and your network.

Note: By default, a VPC’s DHCP option set will specify these VPC Route 53 DNS resolvers to DHCP clients. However, if you don’t want to use AWS provided DNS resolvers, you can change the DHCP options to point clients at self-hosted or third-party DNS resolvers.

Private DNS resolution

Amazon Route 53 can be configured to act as an authoritative name server for one or more zones. You can configure this by creating Private Hosted Zones (PHZs) and associating it with one or more VPCs. Route 53 supports the creation of AAAA records so that it can be used to resolve FQDNs to IPv6 addresses.

For more information, refer to Working with private hosted zones.

DNS64 and NAT64

DNS64

Your IPv6-only workloads running in VPCs can only send and receive IPv6 network packets. Without DNS64, a DNS query for an IPv4-only service will yield an IPv4 destination address in response and your IPv6-only client cannot communicate with it. To bridge this communication gap, you can enable DNS64 for a subnet and it applies to all the AWS resources within that subnet. With DNS64, the Amazon Route 53 Resolver looks up the DNS record for the service you queried for and does one of the following:

• If the record contains an IPv6 address, it returns the original record and the connection is established without any translation over IPv6.

• If there is no IPv6 address associated with the destination in the DNS record, the Route 53 Resolver synthesizes one by prepending the well-known /96 prefix, defined in RFC 6052 (64:ff9b::/96), to the IPv4 address in the record. Your IPv6-only client sends network packets to the synthesized IPv6 address. You will then need to route this traffic to the NAT gateway, which performs the necessary translation on the traffic to allow IPv6 clients in your subnet to access IPv4 services outside that subnet.

DNS64 is a subnet-level setting, which you can enable or disable on IPv6-only subnets using the modify-subnet-attribute using the AWS CLI or with the VPC console. DNS64 works in conjunction with NAT64, which comes built into the Amazon VPC NAT Gateway service.

NAT64

NAT64 enables your IPv6-only clients in Amazon VPCs to communicate with IPv4-only services in the same VPC (in different subnets), or connected VPCs, in your on-premises networks, or the internet. NAT64 is automatically available on your existing NAT gateways or on any new NAT gateways you create. It's not a feature you enable or disable. Once you have enabled DNS64 and your IPv6-only service sends network packets to the synthesized IPv6 address through the NAT gateway, the following happens:

• From the 64:ff9b::/96 prefix, the NAT gateway recognizes that the original destination is IPv4 and translates the IPv6 packets to IPv4 by replacing:

  • Source IPv6 with its own private IPv4, which is translated to the Elastic IP address by the internet gateway.

  • Destination IPv6 to IPv4 by truncating the 64:ff9b::/96 prefix.

• The NAT gateway sends the translated IPv4 packets to the destination through the internet gateway, VPC peering, virtual private gateway, or transit gateway, and initiates a connection.

• The IPv4-only host sends back IPv4 response packets. Once a connection is established, NAT gateway accepts the response IPv4 packets from the external hosts.

• The response IPv4 packets are destined for NAT gateway, which receives the packets and de-NATs them by replacing its IP (destination IP) with the host’s IPv6 address and prepending back 64:ff9b::/96 to the source IPv4 address. The packet then flows to the host following the local route.

The NAT gateway enables your IPv6-only workloads in an Amazon VPC subnet to communicate with IPv4-only services anywhere outside the subnet.

DNS64 and NAT64