An A record (address record) is the DNS resource record that maps a host name to a single 32-bit IPv4 address, for example app.example.com to 203.0.113.25. Among DNS records it is the oldest and most frequently queried type, defined with record type code 1 in the original DNS specifications, and it is the record that most web, API and application traffic depends on before a connection can start.
A name may carry several A records at once, and the same address may appear under many names. The A record does not carry ports, protocols or paths: it answers only the question which IPv4 address belongs to this name.
Structure of an A record
Every A record consists of the same five fields that all DNS records share, with an RDATA field of exactly four octets holding the IPv4 address in network byte order. In zone file syntax a typical entry reads app.example.com. 3600 IN A 203.0.113.25.
The table below describes each field and the values that are valid for it.
| Field | Meaning | Example value |
|---|---|---|
| Owner name | Fully qualified host name the record describes | app.example.com. |
| TTL | Seconds a resolver may cache the answer | 3600 |
| Class | Protocol family, practically always Internet | IN |
| Type | Record type, code 1 for address records | A |
| RDATA | One IPv4 address, four octets long | 203.0.113.25 |
The owner name may be the zone apex (the bare domain, written as @ in many zone editors), an ordinary subdomain, or a wildcard such as *.example.com that matches names without their own records. A trailing dot marks a name as fully qualified; omitting it in a zone file appends the zone origin, a classic source of mistakes.
How resolvers use A records
When an application needs an IPv4 address, the operating system sends an A query to its recursive resolver, which returns either the cached record or the answer it obtains from the domain’s authoritative name servers. Modern dual-stack clients send A and AAAA queries in parallel and race connections with the Happy Eyeballs algorithm, preferring IPv6 when it works.
If the queried name is an alias, the authoritative server answers with a CNAME chain followed by the A record of the target name. If several A records exist for one name, they form an RRset, and the resolver returns all of them, often in rotated order.
The possible outcomes of an A query are summarized below.
| Response | Meaning | Client behavior |
|---|---|---|
| One or more A records | The name has IPv4 addresses | Connects to one of the addresses |
| CNAME plus A records | The name is an alias of another host | Uses the addresses of the target |
| NOERROR with no data | The name exists but has no A record | Falls back to AAAA or fails |
| NXDOMAIN | The name does not exist | Reports an unknown host |
| SERVFAIL | Resolution or DNSSEC validation failed | Retries, then reports an error |
A records compared with related record types
The A record answers only for IPv4, so it is usually deployed together with other types that cover IPv6, aliasing and reverse lookups. Choosing the right type depends on what the name should point to and who controls the target.
| Record type | Points to | Typical use |
|---|---|---|
| A | An IPv4 address | Servers, load balancers, apex domains |
| AAAA | An IPv6 address | The same hosts on IPv6 |
| CNAME | Another domain name | Aliases to hosted services and CDNs |
| PTR | A domain name, from an address | Reverse lookups, mail server checks |
| ALIAS or ANAME | A name, flattened to addresses | Provider feature for CNAME-like apex records |
A key rule is that a CNAME cannot coexist with other records at the same name, so the zone apex, which always carries SOA and NS records, must use A and AAAA records or a provider-specific flattening feature. A matching PTR record in the reverse zone is not created automatically; the owner of the address block controls it.
Configuring A records in practice
Good A record design starts with the question of how stable the target address is. A dedicated server with a fixed public address tolerates a long TTL, while an address behind failover or a migration plan needs a short one.
| Situation | Recommended setup | Reason |
|---|---|---|
| Single static server | One A record, TTL 3,600 seconds or more | Few queries, rare changes |
| Planned migration | Lower TTL to 300 seconds in advance | Old address expires from caches quickly |
| Several equal servers | Multiple A records in one RRset | Simple round-robin distribution |
| Managed load balancer or CDN | CNAME or provider alias record | Provider changes addresses without notice |
| Health-based failover | Managed DNS with health checks, TTL 30-60 seconds | Unhealthy addresses are withdrawn |
Publishing a private address such as 10.0.0.5 in a public zone works technically but reveals internal topology; such records belong in a split-horizon or internal zone. Every change should be verified against the authoritative servers directly, because a recursive resolver may still return the cached old value.
Common A record mistakes
Most A record incidents are not caused by DNS software but by stale or inconsistent data. The following errors appear repeatedly in production zones.
- Dangling A records that still point to a released cloud address, which another customer can later acquire and use to serve content under the domain.
- Round-robin mistaken for load balancing: DNS rotation does not detect failed servers, so clients keep receiving dead addresses until the record is removed.
- Missing apex record:
wwwworks but the bare domain does not resolve because only the subdomain received an A record. - Forgotten AAAA record pointing to an old IPv6 host, so dual-stack clients reach a different server than IPv4-only clients.
- Wildcard surprises: a wildcard A record answers for typos and unused names, which can hide configuration errors.
In everyday language
Every server on the Internet has a numeric address, much like a street address for a building. An A record is the entry that links a name to that numeric address, so people can type a memorable name instead of four groups of digits.
When the server moves to a new address, the owner simply updates the A record, and visitors keep using the same name. The essential point is that an A record answers one question only: where, in IPv4 terms, this name lives.
Seen in the real world
A small accounting firm hosts its client portal on a virtual server with the public address 198.51.100.40. Its DNS provider holds an A record for portal.example.com with a TTL of 3,600 seconds, and an identical record at the zone apex so that the bare domain also works.
When the firm moves the portal to a larger server at 198.51.100.77, the administrator first reduces the TTL to 300 seconds a day ahead. After the switch, the old address disappears from resolver caches within minutes, and a check against the authoritative server confirms the new value. The old server is shut down a week later, and the firm also deletes an unused A record for a retired test host, closing a potential takeover risk.