🔵 AAAA Record Lookup

🔍 What Is an AAAA Record?

An AAAA record, pronounced "quad-A," is the DNS record type that maps a hostname to an IPv6 address. It plays exactly the role an A record plays for IPv4 — nothing more abstract, nothing more complicated — it's simply the answer a resolver hands back when something asks "what IPv6 address does this name point to?" A single hostname can have zero, one, or several AAAA records, and it can carry AAAA records alongside A records without conflict, since the two record types query independently even for an identical name.

This tool exists because checking that answer by hand isn't something most people do daily, but it becomes suddenly relevant during an IPv6 rollout, a CDN migration, a "some users can't connect" ticket, or a routine infrastructure audit. Rather than reaching for a terminal and remembering the right dig or nslookup flag, this page runs the live query for you, against a public DNS-over-HTTPS resolver, and lays the result out clearly — including a direct comparison against the domain's A record so you can see its dual-stack status at a glance.

📜 Why "AAAA" and Not Something Simpler

The naming looks arbitrary until you know the reasoning: an IPv4 address is 32 bits, and an IPv6 address is 128 bits — exactly four times larger. When the IETF standardized the IPv6 DNS record in the mid-1990s, they picked a record type name that encoded that 4x jump directly into the label itself, quadrupling the letter A rather than simply moving to the next unused letter in the alphabet like B. It's a small, slightly unusual naming decision, but once you know the "four times the size" logic behind it, the name stops being a trivia question and starts being a mnemonic.

📋 Record Structure & Syntax

An AAAA record's structure mirrors an A record's, with the value field holding a 128-bit address instead of a 32-bit one. In zone-file syntax it looks like this:

example.com.    3600    IN    AAAA    2606:4700:3033::6815:1234

Reading left to right: the owner name, the TTL in seconds, the record class (almost always IN, for Internet), the record type, and finally the IPv6 address itself. IPv6 addresses are written as eight groups of four hexadecimal digits separated by colons, and DNS providers universally accept the shortened forms — a run of consecutive all-zero groups collapsed to a double colon (::), and leading zeros within a group dropped. A fully expanded address like 2606:4700:3033:0000:0000:0000:6815:1234 is functionally identical to the compressed 2606:4700:3033::6815:1234 shown above — the compression is purely notational, not a different address.

⚖️ AAAA vs A: What Actually Differs

Functionally, both record types do the same job — map a name to an address a network layer can route to. The differences are all in the details underneath: address size, notation, and increasingly, which network path traffic actually takes once it leaves the resolver. IPv6 also removes a few IPv4-era concepts entirely, most notably NAT as a routing necessity, since IPv6's address space is large enough that address exhaustion isn't the daily operational concern it became for IPv4.

⚙️ How This Tool Resolves an AAAA Record

When you click Lookup, this tool sends a live DNS-over-HTTPS query for the AAAA record type against a public resolver and returns exactly what comes back — the same answer any properly configured IPv6-aware resolver anywhere in the world would receive at that moment. It isn't reading from a cached database or a stored snapshot; a domain that changes its AAAA record five minutes before you check will show the new value immediately, subject only to the TTL of whatever answer a resolver you personally use might already have cached elsewhere.

🔌 Dual-Stack: Reading the Result Correctly

Most production domains that publish an AAAA record also keep their A record — this combination is called dual-stack, and it's the safest, most widely recommended configuration for a public-facing hostname today. Dual-stack means an IPv6-capable visitor connects over IPv6 natively, while a visitor on an IPv4-only connection still reaches the exact same hostname over IPv4 without any special handling — nobody is left behind, and nobody's browser needs to do anything unusual to get there.

A domain that returns AAAA records but no A record at all is IPv6-only, which is still comparatively rare for public-facing services precisely because it excludes any visitor whose network path lacks IPv6 connectivity, whether that's an older ISP, a corporate network still mid-rollout, or a mobile carrier with incomplete IPv6 support on a specific plan. IPv6-only is far more common on internal infrastructure — private data-center segments, service meshes, and internal APIs — where every client on the network is already guaranteed IPv6-capable.

👀 Happy Eyeballs: How Clients Choose IPv4 vs IPv6

When a hostname returns both an A and an AAAA record, the client doesn't just blindly pick one — modern browsers and operating systems use an algorithm called Happy Eyeballs (formally RFC 8305), which fires off connection attempts to both address families in quick succession and uses whichever one completes its handshake first, usually giving IPv6 a small head start since it's normally faster on networks where it's genuinely well-supported. This is precisely why a dual-stack domain with a broken or slow IPv6 path can still feel fine to most users — Happy Eyeballs quietly falls back to IPv4 within a few hundred milliseconds if the IPv6 attempt stalls, masking a real IPv6 problem that would otherwise be invisible until someone checks the AAAA record directly.

That masking effect is exactly why this tool matters for troubleshooting: a site "working fine" in a browser tells you almost nothing about whether its IPv6 path is healthy, because Happy Eyeballs is specifically designed to hide that kind of partial failure from the end user.

⏳ TTL & Caching Behavior

TTL works identically for AAAA records as it does for A records — it's the number of seconds a resolver is permitted to cache the answer before it's required to ask again. A freshly changed AAAA record won't be visible to every resolver worldwide instantly; each one continues serving its previously cached answer until that entry's TTL expires, which is why a change can appear "live" from one location and "not yet applied" from another for a window of time entirely explained by caching, not by anything broken.

📋 Comparison Tables

IPv4 vs IPv6

Dual-Stack vs IPv6-Only

Managed DNS vs Self-Hosted DNS for AAAA

🌐 Real-World Examples

🛡️ AAAA Records Across Major DNS Providers

Every major managed DNS provider — Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS, NS1, and standard registrar DNS panels — supports AAAA records as a first-class record type, with essentially the same add-record workflow used for an A record, just selecting AAAA from the type dropdown and pasting in the IPv6 address instead of an IPv4 one. Where providers meaningfully differ is in secondary features: some automatically flag a hostname that has an A record but no matching AAAA as an IPv6-readiness gap in their dashboard, and some (notably Cloudflare, when its proxy is enabled) synthesize an AAAA response automatically even for origins that are IPv4-only internally, terminating IPv6 at the edge and translating to IPv4 on the way to origin.

🖥️ Command-Line Reference: dig, nslookup, host, PowerShell

Beyond this tool, checking an AAAA record from a terminal is a one-line command on every major platform:

Every one of these commands hits the same DNS system this page queries — they'll return the same answer, just formatted differently and cached according to whichever resolver your operating system is configured to use, which may hold a different remaining TTL than the public resolver this tool queries directly.

☁️ CDN & Cloud Provider Behavior

Reverse-proxying CDNs — Cloudflare, Fastly, Akamai and similar — routinely publish AAAA (and A) records that point to their own edge network rather than to your actual origin server, meaning the address this tool returns for a CDN-fronted domain tells you about the CDN's edge, not your backend infrastructure directly. That's expected and correct behavior, not a misconfiguration; it's the entire point of a reverse proxy. Where this becomes genuinely useful is confirming the CDN's IPv6 edge is live and correctly configured after enabling IPv6 support in the CDN's dashboard, which many providers treat as an opt-in toggle rather than an automatic default.

🔒 Security Considerations

An exposed IPv6 address doesn't carry meaningfully different risk from an exposed IPv4 one on its own — the risk comes from what's listening on it, not the address family. That said, IPv6's larger address space does change one practical dynamic: brute-force scanning across an entire IPv6 subnet is computationally infeasible in a way IPv4 subnet scanning simply isn't, which is a genuine security benefit for services that rely partly on obscurity as a layer, though it should never be the only layer. The more relevant security habit here is making sure firewall rules are mirrored across both stacks — a common, easy-to-miss mistake is locking down a service tightly on IPv4 while leaving the IPv6 firewall rules at their permissive default, effectively leaving a second, unguarded front door open.

⏱️ Performance & Reliability

On networks where IPv6 is genuinely well-provisioned end to end, it frequently performs on par with or slightly faster than IPv4, partly because it skips the extra NAT translation step that adds a small amount of latency and complexity to nearly every IPv4 consumer connection today. The caveat is "genuinely well-provisioned end to end" — a poorly peered or lightly-tested IPv6 path can be slower or less reliable than a mature IPv4 one, which is exactly the scenario Happy Eyeballs was designed to paper over for end users, and exactly the scenario a direct AAAA check like this one is designed to surface for the people actually responsible for fixing it.

❌ Common Mistakes

✅ Best Practices

For most public-facing services, publish dual-stack rather than IPv6-only, keep TTLs reasonable (not so low they add unnecessary query load, not so high they slow down a genuine cutover), monitor both address families independently rather than assuming one implies the other is healthy, and mirror every security control across both stacks before considering an IPv6 rollout complete. Testing from a genuinely IPv6-connected network — not just checking that the DNS record exists — is the only way to confirm the whole path actually works end to end.

📊 Pros & Cons of Publishing AAAA

🔧 Troubleshooting

🎓 Expert Tips

🔗 More Ways to Investigate DNS

For the complete record picture beyond AAAA, use DNS Lookup. To check the IPv4 side of the same hostname, use A Record Lookup. For a deeper geolocation and metadata check on any IPv6 address itself, try IPv6 Lookup, or expand and subnet an IPv6 prefix with the IPv6 Calculator. To confirm whether a DNS change has propagated globally, use DNS Propagation Checker, and to go the other direction — from address back to hostname — try Reverse DNS Lookup.