DNS A record

A name, a type, a time to live, and a 32-bit IPv4 address written in the familiar dotted form. Nothing else — there is no port, no protocol, and no path.

Because it holds an address rather than another name, an A record is a terminal answer. A resolver that finds one has finished, and no further lookup is needed.

The IPv6 equivalent is the AAAA record, which holds a 128-bit address. The two coexist: a hostname with both is reachable over either protocol, and the client chooses.

An A record can be published at the apex of a domain, which is the practical reason it is still used where a CNAME would otherwise be more convenient.

A hostname may carry multiple A records. The resolver returns all of them, usually in a rotating order, and the client tries one.

This distributes traffic, but it is not load balancing in any meaningful sense: there is no health information, and a client that receives the address of a dead server simply fails or retries.

Modern clients implement connection racing — trying several addresses in parallel and keeping the first that answers — which softens the failure but does not remove it.

Real availability comes from something that knows whether a server is up: a load balancer, an anycast network, or a DNS provider that removes failing addresses from its answers.

An A record points at an address. If the address changes, you must change the record.

A CNAME points at another name, so the target owner controls the address. That is the right shape for a CDN or a hosted service, and it is forbidden at the apex of a domain.

Many DNS providers offer a non-standard apex flattening record — marketed as ALIAS or ANAME — which resolves a name on the server side and serves the result as an A record. It behaves like a CNAME at the apex and is a provider feature rather than a protocol one.

The choice matters for change management more than for performance: a hard-coded address is a thing someone must remember to update.

`dig example.com A +short` prints the addresses. `dig example.com A` prints the full answer including the time to live remaining on the cached copy.

`nslookup example.com` is the equivalent on systems without dig, though its output is harder to read precisely.

Query your authoritative nameserver directly with `dig @ns1.example.net example.com A` to see the published record rather than a cached one, which is how you distinguish a change that has not propagated from a change that was never made.

Compare the resolved address against the address actually serving the site. A mismatch usually means a CDN or a proxy in between, and it is worth knowing which.