Recent IPv6 and DNS Software Updates in 2026

Since February 2024, AWS has charged 0.005 dollars per hour for every public IPv4 address used across its services. This amounts to roughly 3.65 dollars per month for each address. In a typical three-availability-zone EKS deployment, costs accumulate from NAT gateway elastic IP addresses, load balancer addresses, and occasional bastion hosts. The new pricing shifted attention toward IPv6-first designs that reduce reliance on public IPv4 resources.

One organization operating as a RIPE NCC member LIR chose to run its order-management platform on IPv6-first EKS. Each environment's VPC receives a /56 prefix from its own provider-aggregatable allocation using BYOIPv6. The setup retains IPv4 support in a limited capacity, similar to maintaining legacy equipment. Initial IPv4 subnets were sized at /28, the smallest option AWS permits, to ensure connectivity with systems that still require IPv4.

In the IPv6-first EKS configuration, the ipFamily parameter is set to ipv6. This results in pods and services receiving only IPv6 addresses through VPC CNI prefix delegation, assigning a /80 per node and a /128 per pod. Each pod obtains a globally unique address from the organization's RIPE allocation. Concepts such as IP exhaustion management, secondary CIDRs, and custom networking become unnecessary under this model.

Egress traffic defaults to an egress-only Internet gateway, which operates without per-gigabyte charges and preserves the pod's original IPv6 address without source network address translation. A single NAT gateway serves as the fallback for IPv4-only destinations, reducing the previous requirement for three gateways. Dual-stack interface endpoints handle required AWS APIs including ECR, STS, KMS, Secrets Manager, and SSM. Security groups restrict access to IPv6 on port 443. Dual-stack application load balancers manage edge traffic while CloudFront distributes static content. The primary database path avoids RDS and instead uses a managed service over PrivateLink.

No option exists for a fully IPv6-only EKS cluster. Even with ipFamily set to ipv6, the underlying nodes remain dual-stack. Every subnet provided to EKS must include an IPv4 CIDR block. This selection cannot be changed after cluster creation. Additional restrictions apply to Nitro instances only, with no support for Windows pods, Outposts, or FSx for Lustre. These constraints illustrate that overall IPv6 capability depends on the weakest link in the dependency chain.

Dependencies that accept only IPv4 connections force continued use of NAT gateways, IPv4 routes, addresses, and associated costs. Failures do not produce obvious errors but instead maintain IPv4 requirements quietly. Analysis of each dependency, including database engines, payment APIs, and container registries, determines the ongoing IPv4 overhead. Several limitations were resolved during the deployment period, indicating gradual improvement. The approach treats IPv4 support as a shrinking legacy component rather than a core requirement.

The first alpha of PowerDNS Recursor 5.5.0 introduces several enhancements over version 5.4. A new capability maintains an up-to-date list of selected names in the record cache regardless of query frequency. Named interfaces allow explicit specification of source addresses for outgoing queries. Response Policy Zone updates now automatically clear related entries from the packet cache. Protobuf logging supports a four-byte framing format and configurable strategies for multiple remote targets. The embedded web server can load TLS keys and certificates from encrypted PKCS12 files.

Outgoing DNS over TLS connections gain optional client certificate support for authenticating to authoritative servers or forwarders. An Extended DNS Error option can be returned when a name falls under a negative trust anchor, based on a contribution from a Quad9 developer. Numerous smaller bug fixes and performance improvements accompany these changes. Users should consult the upgrade guide before installation. Feedback on the new DNS cookie handling is particularly welcome. The release includes updated packages for multiple distributions and maintains support for prior versions according to the established end-of-life policy.

Separately, PowerDNS DNSdist version 2.0.10 addresses a regression introduced in 2.0.9. The issue prevented dynamic blocking of suffixes through the FFI interface, which is used by components such as DNSdist Defender. The update restores correct functionality in this area. Operators should review the full changelog and upgrade guide for complete details. As with other PowerDNS releases, the tarball, signature, and distribution packages are available through official channels. Feedback can be submitted via the mailing list or GitHub for any observed problems.