BRev A record — name to IPv4 address
An A record holds exactly one IPv4 address for a name. It is the oldest and most common record type, and the one nearly every connection ends at: the browser resolves the name, gets four bytes, and opens a socket. Everything else in DNS is, in one way or another, machinery for getting to an A or AAAA record.
A name can carry several A records, and that is round-robin DNS: the resolver returns all of them, typically in rotating order, and the client picks one — usually the first. It distributes load crudely and is not failover, because DNS has no idea whether an address is healthy and will keep handing out a dead one until you edit the zone. Real failover needs a load balancer or a health-checked DNS service.
The apex — example.com with no subdomain — is where A records matter most, because it is the one name that cannot hold a CNAME. Pointing the apex at a platform that only gives you a hostname is the single most common DNS design problem there is, and the answers are provider-specific ALIAS/ANAME records or a redirect from a name that can be a CNAME.
What a A record looks like
Type 1 · IPv4 address. Zone-file form below — owner name, TTL, then the record and its RDATA.
| Name | TTL | Record | What it means |
|---|---|---|---|
| example.com. | 3600 | A 93.184.215.14 | The apex, pointing directly at an IPv4 address — the only shape the apex accepts. |
| www.example.com. | 3600 | A 93.184.215.14 | A subdomain pointing at the same address. It could equally be a CNAME to the apex. |
| api.example.com. | 300 | A 203.0.113.10 | A short TTL kept deliberately low ahead of a planned move. |
| api.example.com. | 300 | A 203.0.113.11 | A second A record on the same name — round-robin across two addresses, not failover. |
The mistakes that break production
Lowering the TTL on the day of the migration
Too late. Resolvers cached the record with the OLD TTL, so a change from 86400 to 300 only takes effect after the old value expires — up to a day later. Lower the TTL at least one old-TTL period before you plan to move, let it propagate, then make the change and raise it again afterwards.
Expecting round-robin to be failover
DNS does not know an address is down. Multiple A records are handed out regardless, so a dead server keeps receiving roughly its share of visitors. Browsers do retry the next address after a connection failure, which masks it — but slowly, and not for every client.
Query a A record now
The box below is seeded with example.com. Choose A as the type and press Look up — the query goes from your browser straight to Cloudflare or Google over DNS-over-HTTPS, with no server of ours in the path.
DNS is the internet's address book: it turns a name like example.com into the addresses and service endpoints machines actually connect to. Every record has a type (what kind of fact it states) and a TTL (how long resolvers may cache it).
Record types
| Type | What it stores |
|---|---|
| A | IPv4 address |
| AAAA | IPv6 address |
| CNAME | Canonical name (alias) |
| MX | Mail exchanger (priority target) |
| TXT | Text — SPF, verifications, DKIM, arbitrary data |
| NS | Authoritative nameservers |
| SOA | Start of authority (serial, refresh, retry, expire, minimum) |
| SRV | Service locator (priority weight port target) |
| CAA | Which CAs may issue certificates |
| PTR | Reverse DNS (IP → name) |
| DNSKEY | DNSSEC public key |
| DS | Delegation signer (DNSSEC chain of trust) |
| HTTPS | HTTPS service binding (ALPN, ECH, hints) |
| SVCB | General service binding |
| TLSA | DANE — pin certificates in DNS |
| NAPTR | Name authority pointer (SIP/ENUM) |
TTL & “propagation”
DNS changes don't “push” anywhere — resolvers simply keep the old answer until its TTL runs out, then fetch the new one. So a change “propagates” in at most the old record's TTL. Planning a change? Lower the TTL (e.g. to 300s) a day in advance, make the change, then raise it back. The compare card above shows whether major public caches have picked your change up yet.
FAQ
What is the difference between an A record and a CNAME?
An A record holds an address. A CNAME holds another name, and the resolver then has to look that name up. A CNAME cannot coexist with other records on the same name, which is why the apex takes an A record and not a CNAME.
How long does an A record change take to apply?
Up to the TTL that was in effect before you made the change, since that is how long resolvers cache the old answer. Some resolvers hold longer than they should, so allow a margin — and lower the TTL well in advance of a planned change.
Can one name have several A records?
Yes, and resolvers return all of them. Clients generally use the first, so the practical effect is coarse load distribution. It is not health-checked, so it does not survive a server failure cleanly.