What is a DNS AAAA record?

A DNS AAAA record maps a hostname to an IPv6 address. It performs the same basic role as an A record, but for IPv6 rather than IPv4. If a site publishes both record types, IPv4-capable clients can use the A answer and IPv6-capable clients can use the AAAA answer.

An AAAA record may look like this:

www.example.com. 300 IN AAAA 2001:db8:20::15

The value is an IPv6 address, written in colon-separated hexadecimal notation. IPv6 addresses are longer than IPv4 addresses and can be shortened using standard compression rules. For DNS operations, the important point is not the visual format but whether the address actually routes to the intended service and whether the service behaves correctly over IPv6.

Publishing an AAAA record is not only a DNS decision. It tells users, crawlers, monitoring systems, and automated clients that the service is reachable over IPv6. That promise should be tested with the same seriousness as the IPv4 path.

Dual-stack behavior in practice

Many public websites run in dual-stack mode, meaning the same hostname has both A and AAAA records. Modern operating systems and browsers usually try to avoid slow connections by racing or prioritizing IPv4 and IPv6 paths. This behavior is often called Happy Eyeballs. The user sees one page load, but the client may have evaluated more than one network path to get there.

This has two operational consequences. First, a partial IPv6 failure may affect only a subset of users, networks, geographies, or devices. Second, logs may show traffic arriving from IPv6 addresses even when a team thinks of the service as mostly IPv4. Monitoring that only checks IPv4 can miss real user failures.

IPv6 also changes address interpretation. A single user, household, mobile network, or enterprise may present many IPv6 addresses over time. Security systems that were built around a single IPv4 address per client can behave poorly if they apply the same assumptions to IPv6. Rate limits, allowlists, blocklists, abuse investigations, and analytics all need IPv6-aware grouping and review.

When to publish an AAAA record

Publish an AAAA record when the destination is genuinely ready for IPv6 traffic. Readiness means the route works, TLS certificates match, the application receives the expected host header, and all required controls are active. It also means support teams can troubleshoot an IPv6-only or IPv6-preferred user without guessing.

For a CDN, load balancer, or reverse proxy, the AAAA record may point at provider-managed edge infrastructure rather than directly at an origin. In that case, confirm the provider supports IPv6 on the relevant service and that the origin connection model is understood. Some architectures accept IPv6 from clients at the edge but still use IPv4 between the edge and origin. Others support IPv6 end to end.

For internal systems, be deliberate. Publishing internal IPv6 addresses in public DNS can reveal network structure or create confusing connection failures. Conversely, failing to publish internal AAAA records where IPv6 is required can cause workstations or services to fall back unexpectedly.

Testing the IPv6 path

A useful test starts with DNS and continues through the application. Query the authoritative nameserver for the AAAA record, then query one or more recursive resolvers. Confirm the TTL, the returned address, and whether the hostname also has an A record.

Then test the connection from a network with real IPv6 access. A local developer machine may not be enough because some networks provide IPv4 only, some tunnel IPv6, and some have broken IPv6 routing. Use monitoring locations that can report IPv4 and IPv6 separately.

Check these behaviors before rollout:

• The site or API answers over IPv6 without redirect loops.
• The TLS certificate covers the hostname.
• The same security controls apply on IPv4 and IPv6.
• Logs preserve the full IPv6 client address or a deliberate prefix-level representation.
• Rate limits and bot controls handle IPv6 prefixes sensibly.
• Error budgets and alerts distinguish IPv6 failures from total service failures.

These checks prevent a common pattern: DNS says the service is dual-stack, but only the IPv4 path has been operationally maintained.

Failure modes that look unusual

IPv6 failures can be intermittent and hard to reproduce. One user may fail while another succeeds because their networks choose different paths. Synthetic monitoring may pass if it only tests IPv4. A support agent may test from an office network with no IPv6 and conclude the site is fine.

Another failure mode is policy drift. A firewall, WAF, DDoS control, or access rule may be configured for IPv4 ranges but not equivalent IPv6 ranges. This can make the IPv6 path either too permissive or too restrictive. Both outcomes are operational risks: one exposes a bypass, the other blocks legitimate users.

Logging and storage systems can also cause problems. IPv6 strings are longer than IPv4 strings. Old schemas, dashboards, and parsers may truncate addresses, reject colons, or treat compressed and expanded forms as different identities. That affects abuse analysis, customer support, and incident timelines.

Security and rollout implications

Adding an AAAA record expands the reachable surface of a hostname. If the hostname is meant to be protected by an edge layer, confirm that direct IPv6 access to the origin is not open unless that is intentional. If access rules use IP allowlists, update them for IPv6 deliberately rather than copying IPv4 logic.

During rollout, start with low-risk hostnames or a controlled subset where possible. Monitor IPv6 request volume, connection errors, TLS failures, cache behavior, origin reachability, and security-rule decisions. Compare IPv4 and IPv6 response codes for the same routes. Large differences often indicate configuration drift rather than user behavior.

Keep the rollback simple: remove or change the AAAA record, then account for TTL and resolver caching. The safest deployments treat IPv6 enablement as a full production path, not as a minor DNS checkbox.

Related learning

• What is a DNS A record?
• What is a DNS CNAME record?
• Common DNS issues and how to diagnose them