ping6.net

IPv6 DNS: AAAA Records, Dual-Stack Resolution, and Best Practices

Learn how DNS works with IPv6, including AAAA records, dual-stack resolution order, DNS64, and common configuration mistakes.

ping6.netDecember 14, 202414 min read
IPv6DNSAAAA recordsDNS64dual-stackname resolution

DNS is where IPv6 deployment lives or dies. Publish an AAAA record before your IPv6 connectivity works, and users wait through timeouts. Skip reverse DNS, and mail servers reject your traffic. Misconfigure dual-stack resolution, and you make the network slower instead of faster.

This guide covers how DNS works with IPv6, what breaks, and how to fix it before it becomes a problem.

TL;DR - Quick Summary

Key Points:

  • AAAA records are the IPv6 equivalent of A records (quad-A = 4 A's for 128-bit addresses)
  • Happy Eyeballs (RFC 8305) tries IPv6 first but falls back to IPv4 within 50-250ms
  • DNS64 synthesizes AAAA records from A records for IPv6-only networks but breaks DNSSEC

Skip to: AAAA Records for basics, Dual-Stack Resolution for performance, or Common Mistakes for troubleshooting.

AAAA Records: IPv6's Answer to A Records#

An AAAA record (pronounced "quad-A") maps a hostname to an IPv6 address. It's the IPv6 equivalent of an A record, but it holds a 128-bit address instead of 32 bits.

Format and Structure#

example.com.    3600    IN    AAAA    2001:db8::1

The structure matches A records: name, TTL, class, type, and address. The address uses standard IPv6 notation with colons and hexadecimal digits.

Leading zeros in each group can be omitted, and consecutive zero groups collapse to ::. Both of these are valid and identical:

example.com.    IN    AAAA    2001:0db8:0000:0000:0000:0000:0000:0001
example.com.    IN    AAAA    2001:db8::1

Use the compressed format. It's easier to read and less error-prone to type.

Querying AAAA Records#

Query AAAA records the same way you query A records, just specify the type.

Using dig:

dig AAAA example.com

This queries for the AAAA record using your default DNS server.

dig AAAA @2001:4860:4860::8888 example.com

This queries Google Public DNS over IPv6.

Using nslookup:

nslookup -type=AAAA example.com
nslookup -type=AAAA example.com 2001:4860:4860::8888

Using host:

host -t AAAA example.com

You can also use our DNS Lookup tool to query both A and AAAA records simultaneously and compare results.

AAAA vs A Records#

Both serve the same purpose—translating names to addresses—but they differ in key ways:

FeatureA RecordAAAA Record
Address Length32 bits128 bits
Address FormatDotted decimal (192.0.2.1)Colon-hex (2001:db8::1)
Record Type128
Query SizeSmallerLarger (affects UDP fragmentation)
Cache BehaviorIndependent TTLIndependent TTL

A and AAAA records are completely independent. They can have different TTLs, point to different servers, or exist without the other. This flexibility is useful but creates opportunities for misconfiguration.

Test Before Publishing

Only publish an AAAA record if your service is actually reachable over IPv6. Publishing broken AAAA records causes connection delays when clients attempt IPv6 first and wait for timeouts before falling back to IPv4.


Dual-Stack DNS Resolution#

Most networks run dual-stack: both IPv4 and IPv6 work simultaneously. When a client looks up a hostname, it receives both A and AAAA records. The operating system then decides which to use.

Happy Eyeballs (RFC 8305)#

Modern operating systems implement Happy Eyeballs, an algorithm that tries both IPv4 and IPv6 but prefers IPv6 when it works. The algorithm:

  1. Queries DNS for both A and AAAA records
  2. Starts connecting to the IPv6 address first
  3. Waits 50-250ms (implementation dependent)
  4. If IPv6 hasn't connected yet, starts an IPv4 connection in parallel
  5. Uses whichever connection completes first

This approach balances performance with reliability. IPv6 gets preference, but broken IPv6 doesn't stall connections for long.

Resolution Order#

The order clients query records and attempt connections varies by OS and configuration.

Most Unix/Linux systems:

  • Query A and AAAA simultaneously or AAAA first
  • Prefer IPv6 addresses if they exist
  • Controlled by /etc/gai.conf (getaddrinfo configuration)

macOS:

  • Queries both record types in parallel
  • Implements Happy Eyeballs strictly
  • Strongly prefers IPv6 when available

Windows:

  • Queries both record types
  • Prefers IPv6 by default (configurable via registry)
  • Implements Happy Eyeballs starting with Windows 8

Browsers:

  • Chrome and Firefox implement their own Happy Eyeballs
  • Don't rely solely on OS behavior
  • May cache resolution results aggressively

When IPv6 Wins (or Loses)#

IPv6 typically wins the race when:

  • IPv6 connectivity is native (not tunneled)
  • IPv6 routing is direct without extra hops
  • The destination is well-connected over IPv6

IPv6 loses when:

  • It's tunneled (6to4, Teredo) with added latency
  • Routing takes longer paths than IPv4
  • The server is poorly connected over IPv6
  • Firewall or middlebox issues slow connections

Facebook's IPv6 Performance

Facebook found that users on native IPv6 connections experienced 10-15% faster page loads compared to IPv4. The performance gain came from fewer network hops, no carrier-grade NAT, and more direct routing.

Testing Dual-Stack Behavior#

Force IPv4 or IPv6 to test behavior:

# Force IPv4
curl -4 https://example.com
# Force IPv6
curl -6 https://example.com
# Let the OS choose
curl https://example.com

Compare response times. If IPv6 is significantly slower, investigate routing or connectivity issues before publishing AAAA records widely.


DNS64 and NAT64#

DNS64 synthesizes AAAA records from A records, enabling IPv6-only networks to access IPv4-only services. It pairs with NAT64, which translates packets between IPv6 and IPv4.

How DNS64 Works#

When an IPv6-only client queries a hostname:

  1. DNS64 server receives the query
  2. Checks for an AAAA record
  3. If AAAA exists, returns it normally
  4. If only an A record exists, synthesizes an AAAA record using a special prefix
  5. Client connects to the synthesized IPv6 address
  6. NAT64 gateway translates the connection to IPv4

The Well-Known Prefix: 64:ff9b::/96#

The most common DNS64 prefix is 64:ff9b::/96, defined in RFC 6052. The last 32 bits of the address embed the IPv4 address.

Example synthesis:

A record:    192.0.2.1
Prefix:      64:ff9b::/96
AAAA record: 64:ff9b::192.0.2.1
             or 64:ff9b::c000:201 (in hex)

Some networks use other prefixes like 2001:db8::/96 or custom ranges. The prefix must be configured consistently on both DNS64 and NAT64.

When You Need DNS64/NAT64#

DNS64 is essential for:

  • IPv6-only mobile networks (common with T-Mobile, AT&T)
  • IPv6-only datacenters accessing legacy IPv4 services
  • Testing IPv6-only client behavior

You don't need DNS64 if:

  • Your network is dual-stack
  • All services you access have native IPv6
  • You can mandate IPv6 on all backend services

Limitations and Gotchas#

DNS64 breaks several things:

DNSSEC validation fails - The synthesized AAAA record doesn't match the signed zone. DNS64 servers must strip DNSSEC signatures, reducing security.

Applications that embed IP addresses break - If an application receives an IPv4 address in JSON, XML, or other data formats, DNS64 won't translate it. The app tries to connect to an IPv4 address from an IPv6-only stack and fails.

Load balancers and CDNs get confused - DNS64 makes all clients appear to come from the NAT64 gateway's address. Geolocation, rate limiting, and client identification break.

Referrals and redirects fail - If a DNS response includes IPv4 addresses in additional sections (like NS glue records), clients can't reach them.

Test Without DNS64

Design services to work natively on IPv6. DNS64/NAT64 is a transition tool, not a permanent solution. It adds latency, complexity, and breaks edge cases.


Reverse DNS (PTR Records)#

Reverse DNS maps an IPv6 address back to a hostname. It's not mandatory for connectivity but is required for mail servers and useful for logging and security tools.

The ip6.arpa Zone#

IPv6 reverse DNS uses the ip6.arpa domain. Each nibble (4 bits, or one hexadecimal digit) of the address becomes a label in the domain name, written in reverse order.

Converting Addresses to PTR Format#

Take the full, uncompressed IPv6 address, reverse it nibble by nibble, and append ip6.arpa.

Example: 2001:db8::1

Step 1: Expand to full form:

2001:0db8:0000:0000:0000:0000:0000:0001

Step 2: Write out all nibbles:

2 0 0 1 0 d b 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

Step 3: Reverse the order:

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 b d 0 1 0 0 2

Step 4: Separate with dots and append ip6.arpa:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

That's the PTR record name. It points to your hostname.

Querying Reverse DNS#

Using dig with automatic conversion:

dig -x 2001:db8::1

This automatically constructs the ip6.arpa name and queries for the PTR record.

Querying the PTR record directly:

dig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Using host:

host 2001:db8::1

Delegating Reverse DNS#

Reverse DNS zones are delegated by your ISP or RIR. If you have a /48, you control a /48 worth of reverse DNS space. Most providers let you manage it through a web interface or allow you to run your own DNS servers for the reverse zone.

For smaller allocations (like a /64), some ISPs handle individual PTR records for you. Contact them with the address and hostname.

Reverse DNS for Mail Servers

Mail servers check reverse DNS to reduce spam. If your mail server's IPv6 address doesn't have a PTR record, or if it doesn't match the forward lookup, many mail systems will reject your messages or score them as spam.


Common DNS Mistakes with IPv6#

Publishing AAAA Without Working IPv6#

This is the number one mistake. You enable IPv6 on a server, create the AAAA record, and assume it works. But if the firewall blocks IPv6, routing is broken, or the server isn't actually listening on IPv6, clients time out.

Symptom: Slow website loads, especially on mobile networks that prefer IPv6.

Fix: Test connectivity from multiple external IPv6 networks before publishing the AAAA record. Use our Ping tool to verify reachability.

Forgetting Reverse DNS#

Forward DNS works fine, but you skip reverse DNS. This breaks mail delivery, confuses log analysis, and looks unprofessional.

Symptom: Mail rejection, "Reverse DNS lookup failed" errors.

Fix: Set up PTR records for all server addresses. Verify with dig -x from multiple locations.

TTL Mismatches Between A and AAAA#

Your A record has a 3600 second TTL, but AAAA has 300. When you update DNS, clients get inconsistent results for hours.

Symptom: Some clients resolve to old addresses, others to new ones. Difficult to troubleshoot.

Fix: Match TTLs for A and AAAA records. They should be identical. Lower both before making changes, then raise them again afterward.

Firewall Blocking DNS Over IPv6#

Your DNS server has an IPv6 address and AAAA record, but the firewall blocks UDP and TCP port 53 over IPv6. Clients can't query it.

Symptom: DNS queries fail from IPv6-only clients or networks.

Fix: Allow UDP and TCP port 53 for both IPv4 and IPv6. Test from an IPv6-only host. Remember that DNS over TCP is mandatory, not optional.

Incomplete Dual-Stack Configuration#

You configure AAAA records for your website but not for your CDN, mail servers, or API endpoints. Users get mixed results.

Symptom: Main site works over IPv6, but embedded content, API calls, or mail fail back to IPv4, losing performance benefits.

Fix: Enable IPv6 for all services in the chain, not just the front end. Test complete workflows from IPv6-only clients.

Hardcoded IPv4 Addresses in Configuration#

Your DNS resolves fine, but application configuration files contain hardcoded IPv4 addresses. Services break when IPv6-only clients try to connect.

Symptom: Application fails with connection errors on IPv6-only networks.

Fix: Use hostnames, not IP addresses, in configuration files. Let DNS resolve to the appropriate address family.


Best Practices#

Test Thoroughly Before Publishing#

Before adding AAAA records to production DNS:

  1. Verify the service listens on IPv6: netstat -an | grep :80 (or your port)
  2. Test from an external IPv6 address: curl -6 https://[2001:db8::1]/
  3. Check firewall rules allow IPv6 traffic
  4. Verify routing is correct with traceroute6
  5. Test from multiple IPv6 networks (mobile, broadband, datacenter)

Don't assume it works because the OS has an IPv6 address.

Match TTLs for A and AAAA Records#

Set identical TTLs. This keeps cache behavior consistent and simplifies DNS updates.

example.com.    3600    IN    A       192.0.2.1
example.com.    3600    IN    AAAA    2001:db8::1

If you need to change addresses, lower the TTL 24-48 hours before the change, make the update, then raise it back.

Configure Reverse DNS#

Set up PTR records for all publicly routable IPv6 addresses. It's required for mail servers and helpful for everything else.

Work with your ISP or RIR to delegate the reverse zone. Keep PTR records synchronized with forward DNS—they should match.

Monitor Both Protocols#

Track DNS query volume, response times, and error rates separately for A and AAAA records. Monitor resolution over both IPv4 and IPv6 transport.

Set up alerts for:

  • AAAA queries failing when A queries succeed
  • Response time differences between IPv4 and IPv6
  • Sudden drops in IPv6 query volume

Separate monitoring catches problems before users complain.

Use IPv6-Capable DNS Servers#

Your DNS servers must answer queries over both IPv4 and IPv6. Configure both address families even if your network isn't fully dual-stack yet.

Test from IPv6-only clients. A surprising number of DNS servers have AAAA records but don't actually accept queries over IPv6.

Implement DNSSEC Carefully#

DNSSEC works with IPv6, but DNS64 breaks it. If you use DNS64 in your network, you can't validate DNSSEC on synthesized records.

For production deployments, design for native dual-stack and avoid DNS64 where possible.


Test Your DNS Configuration

Use our DNS Lookup tool to query A, AAAA, and PTR records. Verify that your dual-stack configuration is correct before making it live.

Frequently Asked Questions#

Do I need both A and AAAA records for dual-stack services?

Yes. Publish both record types for dual-stack services. Clients that support IPv6 will use AAAA, while IPv4-only clients use A. Don't publish AAAA unless your service actually works over IPv6—broken AAAA records cause timeout delays.

Can I use different servers for IPv4 and IPv6?

Yes. A and AAAA records are independent and can point to different servers. This is useful for gradual IPv6 deployment or when you want to route traffic differently by protocol. Just ensure both servers provide identical content and functionality.

Why is my website slow on mobile but fast on WiFi?

Mobile networks often prefer or require IPv6. If your AAAA record exists but your IPv6 connectivity is broken or slow, mobile users wait through timeouts or experience high latency. Test your site over IPv6 from multiple mobile carriers. Remove the AAAA record if IPv6 doesn't work properly.

Do I need reverse DNS for everything?

Reverse DNS is mandatory for mail servers and strongly recommended for all public-facing servers. It's not required for client addresses or internal servers, but having it helps with troubleshooting, logging, and security analysis.

How do I test if DNS64 is working?

Query an IPv4-only hostname from an IPv6-only client. If DNS64 is working, you'll receive a synthesized AAAA record with the configured prefix (usually 64:ff9b::/96). Use dig AAAA ipv4only.arpa as a test—it's an IPv4-only domain designed for DNS64 testing.