dns64 now default without nat64 rule

[mikesplain]

Description

We recently upgraded from v3.19.0 to v4.0.1 in our EKS clusters which is configured for dualstack (pod getting IPv6 addresses). We noticed some services in containers could not communicate with external routes. During the upgrade process, I noticed the following change to our subnets (here's 1 example):

  # module.aws_vpc.aws_subnet.private[2] will be updated in-place
  ~ resource "aws_subnet" "private" {
      ~ enable_dns64                                   = false -> true
      ~ enable_resource_name_dns_aaaa_record_on_launch = false -> true
        id                                             = "subnet-<redact>"

        # (15 unchanged attributes hidden)
    }

Specifically, our services were unable to communicate with api.github.com within a container.

We disabled dns64 on the subnet and the communication worked again.

After reading the docs on DNS64 we found when enabling dns64, there should be an accompanying route setup on the route for 64:ff9b::/96 to a NAT gateway.

After adding this route manually, this communication worked as planned.

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

Versions

• Module version [Required]:

• Terraform version:
  v1.4.3-dev

• Provider version(s):
  registry.terraform.io/hashicorp/aws v4.61.0

Reproduction Code [Required]

Here is our code from v3.19.0 and a commented out change that was documented in the upgrade guide for v4.0.1

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

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

  public_subnets  = [for k, v in local.azs : cidrsubnet(var.vpc_cidr, 2, k)]
  private_subnets = [for k, v in local.azs : cidrsubnet(var.vpc_cidr, 4, k + 12)]

  create_igw         = true
  enable_nat_gateway = true
  single_nat_gateway   = true
  enable_dns_hostnames = true

  enable_ipv6                                    = true
  # v3.19.0
  assign_ipv6_address_on_creation = true
  # v4.0.1
  # private_subnet_assign_ipv6_address_on_creation = true

  create_egress_only_igw = true

  public_subnet_ipv6_prefixes  = [0, 1, 2]
  private_subnet_ipv6_prefixes = [3, 4, 5]

}

Steps to reproduce the behavior:

1. Upgrade from module version 3.19.0 to 4.0.1
2. Comment out assign_ipv6_address_on_creation and uncomment private_subnet_assign_ipv6_address_on_creation
3. Spin up EKS cluster in dualstack,curl -6 api.github.com -> should hang.

Expected behavior

1. IPv6 routing should remain the same between major 3 and major 4 versions unless noted in the upgrade docs.
2. Enabling DNS64 should automatically add required routes for NAT64

Actual behavior

I could be wrong but it looks like previously enable_dns64 was not set via this module. Now that it is set by default to true for each type of subnet, IPv6 routing to non-ipv6 addresses are nat64'ed, without the correct route in place to route to the nat gateway.

Terminal Output Screenshot(s)

Additional context

Seems to me like adding that route when dns64 is enabled would be a good course of action and I imagine this was just a bug was a bit of an edge case, so most people wouldn't notice it.

Thanks for all the hard work on these modules, I just figured filing this might help someone else running into this issue in the future.

[bryantbiggs]

Thank you for the very detailed report - I agree, we should add a route for this synthesized address destination to the route table. Do you want to take a stab at this or should I?

[mikesplain]

I'm happy to, just wanted to confirm that you all agreed with the direction. I'll open a PR shortly.

[bryantbiggs]

yes 💯 - looking forward to the PR, thank you!

[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

[antonbabenko]

This issue has been resolved in version 4.0.2 🎉

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.