DNS in IPv6 Environments

IPv6 adoption has been "imminent" since roughly 2000. It's now 2026 and the world runs on dual-stack — IPv4 and IPv6 coexisting everywhere, which means DNS operators are managing both. If you thought adding a second address family was just a matter of adding some AAAA records, you're in for a surprise.

IPv6 DNS works, but it has rough edges that bite in production. Understanding them saves you hours of debugging.

AAAA records: the basics

The AAAA record maps a hostname to an IPv6 address. The name comes from the fact that an IPv6 address is four times the size of an IPv4 address (128 bits vs 32 bits).

example.com.  300  IN  AAAA  2001:db8:85a3::8a2e:370:7334

Nothing complicated there. The record type, TTL, and the address follow the same zone file conventions as an A record.

Querying AAAA records with dig:

# Basic AAAA query
dig AAAA example.com

# Both A and AAAA in one query
dig example.com A example.com AAAA

# At a specific resolver
dig @8.8.8.8 AAAA ipv6.google.com

# Short output
dig +short AAAA google.com

One thing that trips people up: if you query for AAAA and get NOERROR with an empty answer section, that means the record doesn't exist but the domain does. NXDOMAIN means the domain itself doesn't exist. These are different failures with different debugging paths.

Reverse DNS in IPv6: ip6.arpa

IPv4 reverse DNS lives in in-addr.arpa. IPv6 reverse DNS lives in ip6.arpa, and it's considerably more painful to work with.

An IPv4 PTR for 192.0.2.1 is 1.2.0.192.in-addr.arpa. Simple octets in reverse order.

An IPv6 PTR for 2001:db8:85a3::8a2e:370:7334 is:

4.3.3.7.0.7.3.e.2.a.8.0.0.0.0.0.0.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.

That's the full 32-hex-digit address, each digit reversed, separated by dots. No aggregation like in IPv4 — every single nibble gets its own label.

A few things this means in practice:

Delegation is difficult. With IPv4 you can delegate on octet boundaries (e.g., delegate a /24). With IPv6 you can technically delegate on nibble boundaries, but most ISPs and hosting providers give you a /48 or /64, which doesn't align cleanly. The result: most IPv6 PTR records are managed by whoever controls the /32 or /48 block, not by the end operator.

Zone size. A fully populated /64 would have 2^64 PTR records. Nobody does that. In practice, PTR records are created for specific hosts, servers, or load balancer IPs.

Many deployments skip PTR entirely. For end-user traffic, PTR records on IPv6 addresses are often absent. This breaks certain spam filters and logging tools that rely on rDNS. It's a real operational gap.

Dual-stack resolution: the dance

In a dual-stack environment, a client querying for example.com might get both an A and a AAAA record. The question is which address it uses.

Before RFC 8305, this was up to the OS and application, and behavior was inconsistent. Some clients tried IPv6 first. Some tried in order. Some picked randomly. The result: flaky connections when IPv6 paths worked in routing tables but had problems at the application layer.

RFC 8305 (Happy Eyeballs version 2) standardized the approach:

Query for A and AAAA in parallel (or near-parallel)
Begin a connection attempt to the first address received
After a short delay (250ms by default), start a parallel connection attempt to the other address family
Use whichever connection succeeds first
Cancel the other

The 250ms delay matters. It means IPv6 gets a head start since AAAA queries typically return alongside or slightly before A queries. But if IPv6 connectivity is broken, the fallback to IPv4 happens automatically within 250-500ms rather than waiting for a full connection timeout.

Modern browsers implement this. curl has --happy-eyeballs-timeout-ms. Most languages' HTTP clients have some version of it.

Where Happy Eyeballs doesn't help: server-side software connecting outbound (database connections, API calls, etc.) where developers have rolled their own connection code. That's where you still see hard failures when IPv6 breaks.

Common misconfiguration patterns

Publishing AAAA without testing reachability. This one is surprisingly common. An operator adds AAAA records because "IPv6 support" is on the checklist, but the host is not actually reachable over IPv6 in production. For clients implementing Happy Eyeballs correctly, this degrades to a 250ms penalty on every connection. For clients that don't, it causes outright failures.

Always verify:

# Check that the IPv6 address is actually reachable
ping6 2001:db8::1
curl -6 https://example.com

Missing or broken PTR records. Mail servers in particular rely on PTR records matching the forward A/AAAA records for basic deliverability checks. If your mail server sends from an IPv6 address with no PTR, expect rejections from major providers.

Mismatched DNSSEC for AAAA. If you're running DNSSEC, AAAA records need to be signed too. An unsigned AAAA when DNSSEC is enabled will fail validation for resolvers that enforce it.

Forgetting the IPv6 interface on the nameserver itself. If your authoritative nameserver has an IPv6 address but that address isn't configured in the NS records or isn't actually listening, you'll see query failures from IPv6-only resolvers.

What full IPv6 deployment actually looks like

"Full IPv6 deployment" in practice means:

Every public-facing service has AAAA records pointing to reachable addresses
PTR records exist for all server and infrastructure IPs
Internal infrastructure (resolvers, monitoring, backup systems) is IPv6-capable
IPv6 firewall rules match IPv4 policy — not "allow all IPv6" because someone forgot
Your monitoring checks IPv6 reachability separately from IPv4

The last point matters. It's easy to have a monitoring setup that checks http://example.com and considers it healthy as long as something responds. If your IPv6 path is broken, Happy Eyeballs will silently fall back to IPv4 and your monitoring won't notice.

Run separate checks:

# IPv4 only
curl -4 https://example.com
# IPv6 only
curl -6 https://example.com

Key takeaways

AAAA records are straightforward; IPv6 reverse DNS in ip6.arpa is not
PTR records are harder to manage in IPv6 and are frequently missing
Happy Eyeballs (RFC 8305) handles dual-stack gracefully, but not all clients implement it
Publishing AAAA records without verified IPv6 reachability creates silent performance problems
Monitor IPv4 and IPv6 paths independently

Up next

Lesson 02: DNS and IoT — mDNS, DNS-SD, and what happens when you put 50 devices on a network that weren't designed with security in mind.