The DNS A Record

The record every other lookup ends at

An A record maps a hostname to a single IPv4 address. It is the record that tells a resolver, and through it a browser or mail server, the numeric address to connect to.

Everything else in DNS is indirection on the way to that answer. NS records say which servers hold the zone, a CNAME says that one name is really another, an MX record names a mail host. Follow any of those chains far enough and it ends at an A record or at its IPv6 counterpart, the AAAA record, because an address is the only thing a client can connect to. RFC 8499 groups the pair under one heading: address records are records whose type is A or AAAA.

That position at the end of every chain is why A records deserve more attention than their simplicity suggests. The record has one field and has been defined the same way since RFC 1035. Its failures come not from complexity but from what happens when the machine changes and the record does not.

What an A record can hold, and what it cannot

The value side of an A record is an IPv4 address and nothing else. RFC 1035 defines the record data as a 32 bit Internet address, written in a zone file as four decimal numbers separated by dots. IANA lists the type under value 1, described simply as a host address.

That one sentence rules out most of what people try to put in the field:

• A hostname. If the destination is a name rather than a number, you want a CNAME or an apex alias feature.
• A URL. There is no scheme and no path. Forwarding is a web server function, not a DNS one.
• A port. An A record carries none; the client has to know the port already.
• An IPv6 address. A 128-bit address does not fit a 32-bit field. That is what the AAAA record is for.

What the field accepts and what actually works are different questions. An A record holding 10.0.0.5 or 192.168.1.10 is valid; IANA's special-purpose registry lists those ranges as private use under RFC 1918, and publishing one sends every visitor to an address inside their own network. The documentation ranges reserved by RFC 5737 fail the same way. Nothing in DNS forbids either kind, which is why they survive in staging zones copied into production.

The record also carries a TTL, the seconds a resolver may reuse the answer before asking again. RFC 2181 requires every record sharing a name, class and type to share a TTL as well, so you cannot give one A record a short TTL and its sibling a long one. The set is cached and expires as a unit.

The apex, where A records go and CNAMEs cannot

The apex of a zone is its top point, the bare domain with nothing in front of it: example.com rather than www.example.com. RFC 8499 defines it as the point in the tree owning the SOA record and the authoritative NS set, and that definition is why the apex behaves unlike every other name in your zone.

Because the apex must carry SOA and NS records, it cannot carry a CNAME, which is not allowed to coexist with any other data at the same name. An A record has no such restriction. It is ordinary data, sits alongside SOA, NS, MX and TXT, and is therefore the standard way to give a bare domain an address.

This is the one place where the A record's plainness is an advantage, which is worth saying because the usual advice runs the other way. At a subdomain, a CNAME pointing at a platform hostname beats a hard-coded address, since the platform can change addresses without involving you. At the apex that option does not exist.

Several A records for one name, and what that does not buy you

A name can have as many A records as you want. RFC 1035 anticipated it in a line: hosts that have multiple Internet addresses will have multiple A records. Resolvers hand the whole set back, clients work through it, and queries end up spread across the listed addresses.

The gap between what that does and what people believe it does is the most common misconception about this record.

• It distributes queries, not load. DNS has no idea how busy any listed machine is. RFC 1794 described round-robin ordering of address records in 1995 as something done without regard to the particular loads on the target machines.
• It is not failover. An A record has no health state. When one address stops answering, the zone keeps handing it out at the same rate, and a share of your visitors get a timeout until somebody edits the zone.
• Caching flattens the distribution. A resolver serving a large network caches the set and answers from it for the life of the TTL, so the split happens between resolvers rather than between users.
• Order is not a control. A record set is a set. Nothing in the protocol makes the first address you typed the first one tried.

Health-checked answers do exist, but they belong to the DNS host, not to the record. A managed provider that offers them tests each address and withholds the ones failing its check, which turns a static list into something closer to failover. Providers describe that as a way to improve uptime and load sharing rather than a substitute for a load balancer. If traffic has to move off a broken host in seconds, the mechanism belongs in front of the servers, not in the zone.

Changing the address without dropping traffic

Editing an A record takes effect on your authoritative servers at once. What takes time is the expiry of answers resolvers already hold, and the clock is the TTL in force when each of them cached the old value, not the TTL you set afterward.

So a planned change runs backwards. Lower the TTL first, wait out the old TTL so every cache holding the record has picked up the short value, then move the service and change the record. Raise the TTL again once traffic has settled, remembering that a record set shares a single TTL, so the change covers every address on that name.

Two things go wrong more often than caching does. The first is retiring the old host too early: the edit is correct, but the old address has to keep answering until the last cached copy expires. The second is asymmetry, where a migration updates the apex and forgets www, and the reports arrive in the form of it works for me.

The stale A record, and how an address becomes someone else's

An A record pointing at an address you no longer control is the most dangerous leftover a zone can carry, and cloud hosting made it ordinary. Release a virtual machine, a load balancer or an elastic IP and the address returns to the provider's pool, to be issued to whoever asks next. If the record is still published, your name now resolves to a stranger's server.

OWASP calls these dangling records and lists A records among the vulnerable types: A records pointing to released IP addresses can be vulnerable if the IP is reassigned and the attacker obtains it, which it notes is common in cloud environments. Whoever holds that address controls content on a name your users trust. They can host a convincing phishing page on your domain, obtain a valid TLS certificate for the subdomain from a certificate authority, and collect session cookies scoped to the parent domain.

That last item is why this is not merely a subdomain problem. A cookie set for the whole domain is readable by any host beneath it, so a forgotten record on a retired microsite can expose sessions in the main application.

The remedy is order of operations, and it costs nothing. The sequence OWASP recommends for decommissioning is to redirect or serve a maintenance page, update or remove the DNS record, wait for cached answers to expire, and only then tear down the resource. Removing the record before the machine closes the window. Removing the machine first opens one that stays open until somebody notices.

An audit worth running on every zone you hold

Export the zone rather than reading the control panel screen by screen, then put two questions to every A record.

• Do you still control this address? Check it against the current inventory of servers, load balancers and reserved addresses. Anything you cannot account for is a candidate for deletion rather than for leaving alone.
• Is the name still in use? Staging, demo and vendor-trial hostnames outlive the projects that created them, and each is a name an attacker can search for.

Wildcards deserve a separate pass. A wildcard A record answers for every name in the zone that does not otherwise exist, so typos, guessed hostnames and dead subdomains all resolve to whatever it points at. RFC 4592 sets the boundary: a wildcard does not apply when the queried name, or a name between it and the wildcard, is known to exist. It is a poor way to cover a missing record, since it directs traffic for names you have never heard of at an address you may no longer own.

One consumer of these records is easy to forget because it reads them backward. A receiving mail server presented with a connection resolves the reverse DNS name for the connecting address and then resolves that name forward again, checking whether the address it started with is among the answers. The forward half of that round trip is an ordinary A lookup — and an AAAA lookup alongside it, which is why a sender that reaches the internet over IPv6 needs both halves published. If the hostname in the reverse entry has no address record, or has one that no longer matches, the round trip breaks on your side of the check even though the PTR record itself is present and correct.