Can one A record hold two IP addresses?

No. Each A record contains exactly one IPv4 address. To publish several addresses for a name you create several A records with the same owner name, which together form an RRset. Resolvers return the whole set, usually in rotating order.

Does the order of A records in a response mean anything?

Not in any guaranteed sense. Most authoritative servers and many recursives rotate the order per response, and clients differ in how they use it — some take the first, some race several in parallel. Never rely on ordering for priority; DNS has no priority field for A records. If you need weighted or ordered selection, use an [SRV record](/records/srv) or a real load balancer.

Why does my site still resolve to the old IP after I changed the A record?

Because the previous answer is still cached somewhere for up to its old TTL. Recursive resolvers, your OS, and your browser each hold copies. Query the authoritative nameserver directly with `dig @ns1.example.com example.com A` — if that shows the new value, the zone is correct and you are just waiting out caches.

Should I use an A record or a CNAME for www?

A CNAME is usually better for `www` if it points at a platform-managed hostname, because the vendor can change addresses without you touching your zone. Use an A record when you own and control the IP. The apex has no choice — it needs A/AAAA records or a provider-specific ALIAS/flattening feature.

What TTL is safe for a production A record?

An hour (3600) is a reasonable default for a stable host: it keeps query volume low and gives you a buffer if your DNS provider has a partial outage. Drop it to 300 a day or two before a planned migration, then raise it again once the cutover is verified.

Do A records affect email delivery?

Indirectly. [MX records](/records/mx) point at hostnames, and those hostnames need A (or AAAA) records for a sending server to connect. An MX target with no address record means mail cannot be delivered at all, even though the MX lookup itself succeeds.

A Record: Syntax, Examples & Troubleshooting

An A record maps a hostname to a single 32-bit IPv4 address. It is the terminal record of most name resolutions: whatever chain of CNAMEs or delegations a resolver follows, the answer a browser actually connects to is an A record (or its IPv6 sibling, AAAA).

What does an A record actually do?

The A record is defined in RFC 1035 as record type 1, and its RDATA is exactly four bytes — a raw IPv4 address. There is no port, no protocol, no weighting, and no notion of health. DNS hands the client an address; everything after that is the client's problem.

In a resolution, the A record is where the walk stops. A stub resolver asks a recursive resolver for www.example.com; the recursive resolver walks the root, the TLD servers, and the zone's authoritative nameservers (see the NS record reference), possibly following a CNAME or two along the way, and returns an address record. The answer section may contain the CNAME chain plus the final A record — that is normal, not a misconfiguration.

Because the A record is the endpoint, it is also the record most often wrong when a site is down but DNS "resolves fine". A stale A record pointing at a decommissioned server produces a connection timeout, not an NXDOMAIN — a distinction worth internalizing before you start debugging. If you are seeing NXDOMAIN instead, read SERVFAIL vs NXDOMAIN.

A record syntax and fields

Field	Example	Meaning
Name (owner)	`google.com.`	The hostname being defined. In a zone file, `@` means the zone apex and a bare label like `www` is relative to the zone origin.
TTL	`221`	Seconds a resolver may cache this answer. Inherited from `$TTL` if omitted in the zone file.
Class	`IN`	Internet class. Effectively always `IN`; CH and HS exist but you will never publish them.
Type	`A`	Record type 1 — IPv4 host address.
RDATA	`192.178.211.139`	One dotted-quad IPv4 address. Exactly one address per record.

One A record holds exactly one address. Multiple addresses means multiple records at the same name — an RRset — never a comma-separated list in a single record. Provider UIs that accept commas are splitting them for you behind the scenes.

Multiple A records and round-robin

When a name has several A records, the authoritative server returns all of them in one RRset. Most nameservers rotate the order on each response — DNS round-robin — and most clients try the first address returned. The practical effect is coarse load spreading across servers, which is why the google.com answer above carries six addresses.

Round-robin is not load balancing, and treating it as such causes outages. Understand its limits:

No health awareness. DNS does not know a server is down. If one of five A records points at a dead host, roughly one in five new connections stalls until the client's happy-eyeballs or retry logic kicks in — and some clients have none.
Caching defeats the rotation. A resolver caches the whole RRset for the TTL and serves the same ordering it cached to everyone behind it. Distribution is per-resolver, not per-user.
Client behaviour varies. Browsers implementing Happy Eyeballs (RFC 8305) race several addresses in parallel; curl and most command-line tools try them strictly in order with a connect timeout in between.
Removal is not instant. Pulling a bad address out still leaves it cached for up to the TTL. Plan for that window before you rely on record removal as a failover mechanism.

A records at the zone apex

The apex (example.com with no subdomain label) can hold A records but cannot hold a CNAME, because the apex must also carry SOA and NS records and a CNAME may not coexist with other data. That restriction is why apex hosting on a platform that only gives you a hostname is awkward, and why providers invented ALIAS, ANAME, and Cloudflare's CNAME flattening — all of which resolve the target server-side and hand out synthesized A records at query time.

If you are choosing between pointing at an IP and pointing at a name, CNAME vs A record walks the tradeoff. The short version: use an A record when you control the address and it is stable; use a CNAME on subdomains when a vendor owns the address and may change it.

A Record Lookup

IPv4 addresses a hostname resolves to

What TTL should an A record use?

Situation	Suggested TTL	Why
Stable production host	3600–86400	Fewer queries, better cache hit rate, resilience if your DNS provider has a bad day.
Before a planned migration	300 (set 24–48h ahead)	Short TTL lets the cutover complete in minutes instead of a day.
Actively failing over	60–300	The floor on how fast a change can take effect. Below 60 many resolvers clamp anyway.
After a migration settles	Raise back to 3600+	Leaving everything at 300 permanently multiplies your query volume for no benefit.

The critical detail is that lowering a TTL only helps if you do it before the change — the old, long TTL is what is already cached. The full timeline is in Lower your TTL before a DNS migration.

Mistakes engineers actually make with A records

Trailing-dot confusion in the host field. Provider forms want the label (www or @), not the FQDN. Entering www.example.com in a Namecheap or cPanel host field usually yields www.example.com.example.com.
Leaving an old A record alongside a new one. Adding the new IP without deleting the old one gives you round-robin between working and broken — an intermittent outage that looks like "it works for some people".
Publishing an RFC 1918 address publicly. 10.x, 172.16–31.x, and 192.168.x in a public zone means external clients connect to their own LAN. Split-horizon DNS exists for this; a public A record does not.
Confusing the browser cache with the resolver cache. Chrome and Firefox keep their own short DNS caches, and the OS keeps another. A dig from the shell can be correct while the browser is still wrong. See DNS_PROBE_FINISHED_NXDOMAIN.
Assuming the CDN's A record is yours to hardcode. CDN edge addresses rotate. If a vendor gave you a hostname, use a CNAME on a subdomain rather than pinning today's IP into an A record.
Forgetting the AAAA record. A dual-stack client with a working IPv6 path prefers the AAAA record. A stale AAAA alongside a fresh A produces failures only for IPv6 users.

Check it with dig

# Just the addresses
dig +short google.com A

# Full answer with TTLs, so you can see caching in action
dig +noall +answer google.com A

# Ask the authoritative server directly, bypassing every cache
dig +noall +answer @ns1.google.com google.com A

# Follow the whole delegation path from the root
dig +trace google.com A

# Compare two public resolvers
dig +short @8.8.8.8 google.com A
dig +short @1.1.1.1 google.com A

Running the same query twice against a recursive resolver shows a decreasing TTL — that is the cache counting down.

If two resolvers disagree, the record changed recently and one of them is still serving a cached copy. Confirm with DNS Compare or check all 85 resolvers on the propagation checker. For a whole-zone view, DNS Lookup returns every record type at once.

A Record: syntax, examples, and troubleshooting

Example A record