Confusing DNS64 behaviour with public subnets

[rvem]

Description

public_subnet_enable_dns64 is true by default and with enable_ipv6 = true; this enables DNS64 for created public subnets.

However, if a given domain doesn't have an IPv6 record, it's resolved to 64:ff9b::/96 which in turn needs an additional route setup
to work correctly.

• ✋ I have searched the open/closed issues and my issue is not listed.

Somewhat similar to #923, but for public subnets.

Versions

• Module version [Required]: 5.1.1

• Terraform version: 1.5.4

• Provider version(s): AWS - 5.10.0

Reproduction Code [Required]

module "aws_vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.1.1"

  name = local.vpc_name
  cidr = var.vpc_cidr
  azs  = local.azs

  public_subnets  = ["10.0.11.0/24", "10.0.12.0/24", "10.0.13.0/24"]

  enable_ipv6 = true
  assign_ipv6_address_on_creation = true
  enable_dns_hostnames = true
  enable_dns_support = true
  map_public_ip_on_launch = true
  public_subnet_assign_ipv6_address_on_creation = true

  enable_dhcp_options = true
  dhcp_options_domain_name = var.domain_name
  dhcp_options_domain_name_servers = ["AmazonProvidedDNS"]

  public_subnet_ipv6_prefixes  = [0, 1, 2]
}

Steps to reproduce the behavior:

curl -6 api.github.com from the EC2 instance within one of the public subnets above hangs.

Expected behavior

DNS64 enabled along with the corresponding route for resolving 64:ff9b::/96

Actual behavior

An IP from 64:ff9b::/96 is not routed correctly:(

[github-actions]

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

[rvem]

Still relevant

[JeffreyVdb]

I'm having this issue as well.
Use case is creating a publicly reachable machine with only an IPv6 IP.

There are 2 solutions:

• adding an IPv4 public IP
• adding the route to 64:ff9b::/96

In my case however, I don't need a public IPv4 IP, I do need NAT64.

[github-actions]

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

[rvem]

Still relevant

[github-actions]

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

[rvem]

Still relevant

[dylan-shipwell]

this bug just bit me.

should all named subnets have an equivalent: block?

terraform-aws-vpc/main.tf

Lines 1116 to 1126 in 9ffd9c6

	resource "aws_route" "private_dns64_nat_gateway" {
	count = local.create_vpc && var.enable_nat_gateway && var.enable_ipv6 && var.private_subnet_enable_dns64 ? local.nat_gateway_count : 0
	route_table_id = element(aws_route_table.private[*].id, count.index)
	destination_ipv6_cidr_block = "64:ff9b::/96"
	nat_gateway_id = element(aws_nat_gateway.this[*].id, count.index)
	timeouts {
	create = "5m"
	}
	}

I dont see why private and database subnets are special for getting DNS64 routes, especially given aws api clients rely on this routing to work (since so few aws api's support ipv6)

[dylan-shipwell]

I'm looking to understand or open an issue regarding NAT64. I was almost convinced AWS doesn't support dualstack deployments where generated DNS64 making [64:ff9b::0:0/96] addresses, are routable for private subnet workloads.

Default Behavior

Src\Dst	Inet4	Inet6	Pub4	Pub6	Priv4	Priv6
Inet4	N/A	N/A	OK via IP4	N/A	No Route	N/A
Inet6	N/A	N/A	N/A	OK via IP6	N/A	No Route
Pub4	OK via IP4	N/A	OK via local	N/A	No Route	N/A
Pub6	DNS64 OK via PubNATGW	OK via IGW	DNS64 OK via PubNATGW	OK via local	N/A	No Route
Priv4	OK via PubNATGW	N/A	OK via PubNATGW	N/A	OK via local	N/A
Priv6	Timeout Via PubNATGW	OK via eIGW	DNS64 OK via PubNATGW	OK via eIGW or local	BROKEN missing via PrivNATGW	OK via local

---

What i found out yesterday is that AWS VPC NAT Gateways can be deployed in a "private" mode, and the private subnet's route table entry [64:ff9b::0:0/96] can direct to the Private NAT GW, which will enable DNS64 addresses to work in the private subnet.

Adding a VPC NatGW with a private deployment option, and enrolling a route for (for example)
64:ff9b::a00:0/112 to the private-natgw (equivalent to 10.0.0.0/16) enabled Private IPV6 clients to connect to Private IPV4 hosts, an extremely important detail on linux systems that will prefer to only resolve and advertise ipv6 dns records for hostnames- inside a vpc that will generate and advertise ipv6 dns names for all names by generating DNS64 virtual dns records. if ipv6->dns64->nat64->(private) ipv4 doesn't work, this causes hairy issues.

I would strongly suggest that if DNS64 is enabled and the module user doesn't specifical request disabling private NAT GW's that a compliment of private gateway's to match the public ones are created and routed to for the private subnets.