Skip to content

A record

Type dig example.com A and the single line that comes back in the answer section is, for most domains, the only DNS record most people ever consciously think about. It's also the oldest and simplest record type defined in RFC 1035, and everything more elaborate elsewhere in this module ultimately exists to point at, qualify, or supplement one of these.

What it stores

An A record ("Address record") maps a domain name to a single IPv4 address — the 32-bit dotted-decimal number that IP actually routes packets to. Nothing more: no port, no path, no protocol. example.com A 93.184.216.34 says exactly one thing — "if you want to reach example.com, this is the IPv4 address to send packets to" — and every other detail of how a connection actually proceeds from there belongs to layers above DNS entirely.

dig example.com A +short

93.184.216.34

The +short flag strips dig's usual verbose output down to just the answer data, which is often all you need when you're scripting a lookup rather than reading it interactively.

One name, several addresses

A domain isn't limited to a single A record. A zone file can list several addresses under the same name:

www     IN  A   203.0.113.10
www     IN  A   203.0.113.11
www     IN  A   203.0.113.12

A resolver handed multiple A records for the same name typically returns all of them, and the querying client (or its own resolving library) picks one — often by simply trying the first in the list, or by rotating the order the authoritative server returns them in each time it's asked, a crude form of load distribution usually called round-robin DNS. It spreads incoming connections across several servers with no additional infrastructure required, which is exactly why it's still common for smaller deployments even though it has no idea whether any of those servers is actually healthy at the moment a client picks it.

Practical scenario: half the internet can't reach a site that "works fine"

A team notices scattered reports that their site is unreachable, while their own monitoring — and everyone in the office — sees it load perfectly. dig from the office shows one answer; a teammate working from home reports a different one:

dig www.example.com A +short

203.0.113.10

# same command, run from a different network
203.0.113.11

Round-robin DNS is doing exactly what it's supposed to: different queries are getting different addresses from the same rotating list. The actual problem turns out to be that 203.0.113.11 is one of three servers behind that name, and it's down — a deploy earlier that morning left it in a bad state that its own health check didn't catch. DNS itself has no concept of "this address is currently unhealthy, skip it"; it hands out whatever's in the zone file and trusts something else to keep that list accurate. Anyone whose resolver happened to hand them the dead address gets a hard failure, while everyone else sees nothing wrong at all — which is exactly the confusing, inconsistent symptom the reports described.

The fix isn't a DNS change; it's removing the unhealthy address from rotation (or replacing bare round-robin DNS with a load balancer that actually health-checks its backends before recording a diagnosis), because DNS-level round robin was never a substitute for one — it distributes load, it doesn't detect failure.

Common mistakes

  • Treating round-robin DNS as a failover mechanism. It has no health awareness at all. A dead server stays in rotation until a human removes its record.
  • Forgetting that a lowered TTL takes time to take full effect. Changing the address behind a name doesn't instantly update every resolver worldwide — see Introduction to DNS for exactly how the TTL governs that delay.
  • Confusing an A record with a PTR record. An A record answers "what address does this name point to"; the reverse question — "what name is registered for this address" — is a different record type entirely, served from a different, address-indexed zone.

Practice exercises

  1. Run dig <a-domain-with-multiple-a-records> A against a large site you suspect uses round-robin DNS (many do), repeat it several times, and see whether the order of addresses changes between queries.
  2. Explain why round-robin DNS spreads load across servers but cannot, on its own, stop sending traffic to a server that has crashed.
  3. Using this article's scenario, explain why two people reporting completely different experiences of the same outage is itself a useful clue about where to look.

The record above only makes sense for IPv4. The parallel record for the newer, much larger address space — IPv6 — works almost identically, with one extra wrinkle worth understanding before you rely on it: AAAA record.

Sources