A Record Explained: The DNS Record That Turns Names Into Addresses

The Record That Everything Else Points Toward

Strip DNS down to its essential job and it's this: turning names humans use into addresses machines route packets to. That job belongs to the A record. Every other record type in the DNS system either delegates authority toward eventually finding one (NS), aliases toward one indirectly (CNAME), or does something unrelated to hostname resolution entirely (TXT, MX). The A record is the one that actually terminates the chain with a usable IPv4 address a client can open a connection to.

This matters more than it might first appear, because it explains a lot of DNS behavior that otherwise seems arbitrary — why CNAMEs can't coexist with other records at the same name, why "the domain doesn't resolve" almost always traces back to a missing or broken A (or AAAA) record somewhere in the chain, and why this specific record type has stayed essentially unchanged since RFC 1035 defined it in 1987, even as dozens of other record types have been added around it.

Anatomy of an A Record

Structurally, an A record is about as simple as DNS gets: a name, a type (A), a TTL, and a value that must be a syntactically valid IPv4 address — four octets, each 0–255, separated by dots. There's no additional field, no priority, no weighting. Whatever complexity exists around A records lives entirely in how they're used and combined, not in the record format itself.

example.com.       3600  IN  A     93.184.216.34
www.example.com.   3600  IN  A     93.184.216.34
app.example.com.   300   IN  A     198.51.100.20

Notice that different names under the same domain can carry entirely different A records, with entirely different TTLs. There's no requirement that a subdomain share its parent's address or caching duration — each name's A record is an independent entry in the zone.

The Full Resolution Chain, Step by Step

Getting from a typed domain name to a returned A record answer involves more hops than most people picture. Here's the actual sequence for a query that isn't already cached anywhere along the path:

1. Local stub resolver check. Your device first checks its own local cache — has it resolved this name recently?
2. Recursive resolver query. If not cached locally, the query goes to a configured recursive resolver (your ISP's, or a public one like 8.8.8.8/1.1.1.1), which does the heavy lifting on your behalf.
3. Root server query. The recursive resolver, if it has nothing cached, asks one of the 13 root server clusters: "who's authoritative for .com?"
4. TLD server query. The root refers it to the .com TLD nameservers, which are asked: "who's authoritative for example.com?"
5. Authoritative server query. The TLD refers it to example.com's actual authoritative nameservers, which are finally asked directly for the A record.
6. Answer returned and cached. The authoritative server returns the IPv4 address and TTL. The recursive resolver caches it for that TTL and returns it to your device, which also caches it locally.

Every subsequent query for that name, from any client using that same recursive resolver, is answered from cache until the TTL expires — none of those root/TLD/authoritative hops repeat until then. This is why DNS, despite this apparently long chain, resolves in milliseconds for anything already warm in cache, and why a cold, uncached lookup can occasionally feel noticeably slower.

A Record vs the Record Types People Confuse It With

A recurring source of confusion is treating A records as interchangeable with a handful of other record types that solve related but distinct problems.

A Record vs AAAA: Two Protocol Versions, Same Job

An AAAA record does conceptually the same job as an A record — map a name directly to an address — but for IPv6 rather than IPv4. A domain can, and increasingly does, publish both simultaneously, letting a client choose based on its own network capability, a process called Happy Eyeballs in modern operating systems, where IPv6 is typically attempted with a slight preference and IPv4 used as fallback if IPv6 doesn't connect quickly.

Why A Records Point at IPs, Not Hostnames

This is a hard rule, not a stylistic convention: an A record's value must be a literal IPv4 address, never another hostname. If it were allowed to point at a hostname, resolving it would require yet another lookup — which is precisely what a CNAME already does. Keeping A records strictly address-only means a resolver can always be certain that reaching an A record answer terminates the chain immediately, with no further indirection needed, which keeps resolution predictable and avoids accidental resolution loops.

Deployment Contexts: Where A Records Actually Get Configured

The mechanics are identical everywhere, but the interface and surrounding tooling differ meaningfully by context:

• Traditional web hosting: a single A record pointing the domain and often the www subdomain at a shared or dedicated server's static IP.
• CDN-fronted sites: the apex domain's A record often points at the CDN provider's edge IP range rather than the origin server directly, with the CDN handling routing to the nearest edge node — sometimes via anycast, where the same published IP is actually announced from many physical locations.
• Cloud DNS platforms (Route 53, Cloud DNS, Azure DNS): A records are managed the same way conceptually, but often alongside provider-specific alias record types that behave like a CNAME at the zone apex, which plain DNS otherwise disallows.
• Home networking: a router's local DNS or hosts file may hold A-record-equivalent entries for devices on the local network, resolved entirely without touching the public DNS hierarchy at all.

Security Implications of A Record Configuration

Because an A record is the literal address a client connects to, its accuracy has direct security consequences. A stale A record pointing at a decommissioned IP that's since been reassigned to someone else by a cloud provider — a scenario known as subdomain takeover — can let an attacker claim that IP and serve content under a legitimate-looking hostname, including one that may still carry inherited trust from cookies, SSL pinning expectations, or brand reputation. Regularly auditing A records for hostnames pointing at infrastructure you no longer control is a real, underappreciated security practice, not a theoretical concern.

Performance: TTL as a Trade-off, Not Just a Setting

TTL on an A record is a direct trade-off between DNS query overhead and change-propagation speed. A very high TTL (86400s / 24 hours) minimizes repeated DNS queries and shaves a small amount of latency off subsequent connections, but means any change — including an emergency IP change — takes up to that long to reach everyone. A very low TTL (60–300s) makes changes propagate fast but increases the query volume hitting your authoritative nameservers and adds a marginal amount of recurring resolution overhead across the internet. Most production sites land somewhere in the 300–3600 second range as a practical middle ground, lowering it temporarily before a planned migration.

Common Mistakes and Best Practices

Related Tools

Check any hostname's live A record with A Record Lookup. For the full record picture — AAAA, MX, TXT, NS, CNAME — use DNS Lookup. To see how a DNS change is propagating across resolvers, use DNS Propagation Checker, and to check the reverse direction, Reverse DNS Lookup. Ready to set one up yourself? See Configure A Record.