A record
Maps a hostname to a single IPv4 address.
Written and maintained by Ben Ennis
Last reviewed July 27, 2026 · How we verify this
Zone-file example
; type 1, defined in RFC 1035
www.example.com. 300 IN A 203.0.113.10
example.com. 300 IN A 203.0.113.10
example.com. 300 IN A 203.0.113.11 ; round-robin second answerTypical uses
- Pointing a hostname at a web server, load balancer, or VIP
- Publishing several addresses for crude round-robin distribution
- Zone apex records, where CNAME is not allowed
- Glue records that give a nameserver's own address
When it breaks, check
- A stale answer almost always means TTL, not a bad zone — check the remaining TTL in a dig answer
- Multiple A records are unordered; clients pick their own, so do not use them for failover
- A missing AAAA alongside A is fine, but a broken AAAA will make dual-stack clients appear to hang
- Confirm you are querying the authoritative server, not a resolver cache
What the A record does
The A record answers the only question most clients care about: what address do I connect to. The value is a single IPv4 address stored as four bytes, and a name can carry several A records at once. That plurality is where most misunderstandings start. A name with three A records is not a load balancer and is not failover; the resolver returns all three, usually in rotating order, and the client picks one by its own rules. If the address it picks is down, most clients retry another, but the timing is entirely up to the client, and browsers, curl, and Java runtimes each differ.
Zone-file and wire format
In a zone file an A record is name TTL class A address, and the
class is almost always IN. On the wire the RDATA is exactly four octets in
network byte order, which is why an A record can never hold an IPv6 address or a
hostname. A trailing dot makes the name fully qualified; without it the zone’s origin is
appended, which is the classic way to create
www.example.com.example.com.
; name TTL class type rdata
www.example.com. 300 IN A 203.0.113.10
api.example.com. 60 IN A 203.0.113.20
example.com. 300 IN A 203.0.113.10
; short TTLs are for records you expect to move; 300s is a common floor
; because many resolvers ignore anything lower in practice.Common uses
Most A records point at a load balancer or a CDN edge rather than a
single origin, because changing DNS is slow and changing a load balancer target is
instant. The one place you are forced to use an A record is the zone apex:
example.com itself cannot be a CNAME, so if your provider only gives you a
hostname you either need an A record with an address you control, or a provider-specific
ALIAS record. Glue records in a parent zone are also A records,
supplying the address of a nameserver so resolution can bootstrap.
Troubleshooting
When a change has not taken effect, measure rather than guess. Query the authoritative nameserver directly for the intended answer, then query a public resolver for what the world sees. A decreasing TTL on the resolver answer tells you exactly how many seconds are left before it refetches.
Dual-stack surprises are the other recurring problem. If a name has both A and AAAA records and the IPv6 path is broken, clients implementing Happy Eyeballs (RFC 8305) will still connect, but with added latency; clients that do not will appear to hang. Check both families, not just the one you expect to be used.
# what the authoritative server intends
dig +norecurse @ns1.example.com www.example.com A
# what a public resolver currently has cached, with the remaining TTL
dig @1.1.1.1 www.example.com A +noall +answer
# check both address families before blaming the application
dig www.example.com A +short
dig www.example.com AAAA +shortA single A record can still mean hundreds of physical servers
The multiple-A-records case above is not the only way one hostname maps to many
machines. Anycast does the opposite: a single A record, one IPv4 address, is announced
via BGP from many physical locations at once, and the network layer — not DNS — decides
which server actually answers a given connection based on routing distance.
Cloudflare’s explanation of anycast
describes this as one IP address applying to many servers simultaneously, with a
request typically reaching whichever data centre is closest to the sender. From the
resolver’s point of view nothing looks unusual: dig returns exactly one
address, the same address, from anywhere in the world.
This is why pinging or connecting to a major CDN or public resolver’s advertised IP from two different countries can produce completely different response times and even different TLS certificates or server identities, despite both queries returning the identical A record. It also explains a debugging trap specific to anycast services: “the server is broken” reports from one region and “everything is fine” reports from another can both be true simultaneously, because they are not talking to the same physical machine even though they resolved the same name to the same address. Public resolvers like 1.1.1.1 and 8.8.8.8, and most major CDN edges, work this way. If you operate infrastructure behind an anycast provider, do not assume a single A record implies a single point of failure or a single upstream to check when a customer reports an outage — you need to know which anycast site handled their specific request, which usually means asking the provider or checking a location-identifying response header rather than inspecting the DNS record itself.
The defining RFC
The A record is type 1 and is defined in RFC 1035 §3.4.1, part of the original DNS specification, which remains an Internet Standard. The rules for how names are composed and how a resolver follows them are in the companion document RFC 1034. RFC 1912 collects the common configuration errors and is still accurate three decades on. Query a live zone with the DNS lookup tool.
Reference and tooling
Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.
Related reading
- How to find every subdomain with CT logs
Certificate Transparency logs are the most complete public record of a company's hostnames — including the ones with records like this that nobody documented.