DNS A record
AThe A record maps a hostname to an IPv4 address. It is the record most domains cannot work without.
What an A record does
An A record answers one question: which IPv4 address serves this name? A resolver asked for example.com returns the address in the A record, and the client connects to it.
The record type is defined in RFC 1035, and the value is always a bare IPv4 address — never a hostname, and never a URL.
What an A record looks like
An A record pairs a name with one IPv4 address: example.com. 3600 IN A 192.0.2.1. The 3600 is the TTL in seconds, IN is the class, and A is the type.
The address is written in the ordinary dotted form and nothing else belongs in the field. A hostname there is a CNAME, and an IPv6 address is an AAAA record.
Multiple A records
A name can publish several A records. Resolvers may return them in any order, and clients generally try the first one they receive, so publishing several is a common way to spread traffic across servers.
This is not load balancing in any strict sense. Nothing measures server health, and a client that caches one address will keep using it until the TTL expires.
The apex is different
The apex of a domain — example.com with no subdomain — must carry NS and SOA records. Because a CNAME cannot coexist with other records at the same name, the apex cannot be a CNAME, which is why an A record is usually the only option there.
Some DNS providers offer a flattening feature that resolves a target name and publishes the result as A records at the apex. That is a provider behaviour rather than a DNS feature, so it varies.
Checking an A record
dig A example.com +short prints the addresses and nothing else. Adding +noall +answer instead shows the full answer section with the TTL counting down, which is the quickest way to tell how long a resolver will keep serving what it already has.
A change that appears live in one place and stale in another is usually neither broken nor propagating slowly. It is two resolvers holding different cached copies, each until its own copy expires.
TTL and change propagation
Every A record carries a TTL: the number of seconds a resolver may cache the answer. Changing the address does not push anything to resolvers — they keep serving the cached value until it expires.
The practical wait after a change is bounded by the TTL that was in effect before the change, not the one set afterwards. Lowering the TTL a day ahead of a migration is what makes the cutover quick.