An A record points at an address you do not own
An A record maps a name to an IPv4 address. It is the simplest thing in DNS and there is very little to say about the syntax.
What makes it worth an article is that the address is not yours. It was lent to you by a hosting provider, and it goes back into a pool when you stop paying for the machine behind it. The record keeps pointing at it either way, because a DNS record has no idea what is at the other end.
Three ways the address changes without anyone telling you
The host migrates the account. Shared hosting providers move accounts between nodes for capacity, for hardware replacement, for consolidation after an acquisition. Good providers update the DNS if they also run it. If DNS is elsewhere, which it usually is when an agency is involved, the record now points at a machine that no longer serves the site.
A rebuild reassigns the address. Destroy a virtual machine and create another, and unless the address was explicitly reserved it is a different one. This is the standard way a staging environment stops resolving after somebody tidied up the account.
The service in front changed. A load balancer, a proxy or a CDN swaps the address it publishes. If you copied the address into an A record instead of using the name the provider gave you, you are now pinned to an endpoint they no longer consider yours.
That third one is worth stating as a rule: if a provider gave you a hostname, use it in a CNAME rather than resolving it once and writing down the answer. The whole point of the hostname is that they can change what it resolves to. The awkward case is the apex, which cannot hold a CNAME, and which is exactly the situation flattening exists to work around.
The dangling record, which is the one that matters
All three cases above produce a record pointing at an address you no longer control. The visible symptom is the site not loading, which is annoying and gets fixed.
The invisible one is what happens next. That address goes back into the provider's pool and is allocated to somebody else, often within hours. Their machine now answers on it. Your client's name still resolves to it.
Depending on what the new occupant is running, old.example.com or staging.example.com is now serving somebody else's content under your client's domain. On a provider where customers can claim a hostname without proving they own it, that somebody can also obtain a valid certificate for the name, because domain validation checks whether the name points at them, and it does.
The consequences are the ones you would expect from a hostname under a trusted domain being controlled by a stranger: content the client did not publish, cookies scoped to the parent domain in some configurations, and a name the client's own users have been trained to trust.
Nothing about this is exotic and nothing in normal operations detects it, because the record works. It resolves, it connects, it may well answer 200.
Finding them
The check is a reconciliation, not a lookup. For every name in the zone, resolve it and ask whether the address belongs to infrastructure you recognise.
while read -r name; do
ip=$(dig +short "$name" A | tail -1)
[ -z "$ip" ] && continue
org=$(whois "$ip" 2>/dev/null | grep -iE '^(orgname|org-name|descr|netname)' | head -1)
printf '%-40s %-16s %s\n' "$name" "$ip" "$org"
done < names.txtRead the output and look for organisations that are not the client's host. A row naming a provider you stopped using two years ago is the finding.
The input list is the difficult part, because a zone file contains names nobody remembers creating. Export it from the DNS provider rather than writing it by hand, and do this whenever a client leaves a host, not only on a schedule. The window between releasing an address and somebody else taking it is short.
Several A records is not failover
A name can carry more than one A record, and the resolver returns them in a rotating order. This gets called round-robin load balancing, and it is neither of those things reliably.
It is not load balancing because the distribution depends on caching resolvers, not on load. A large ISP resolver caches one ordering and hands it to a million users.
It is not failover because nothing removes a dead address from the set. Browsers do retry the next address after a failed connection, quickly enough that users rarely notice. Many other clients do not: a scripted HTTP call, an older library, a payment provider's callback may take the first address, fail, and give up. So a two-address setup with one dead machine produces a site that works in browsers and fails intermittently for integrations, which is a genuinely miserable ticket to receive.
If you want failover, it has to be something that checks health and withdraws the address. DNS on its own has no such mechanism.
The second address family
AAAA records are the same idea for IPv6 and they participate in the same failure. A name with both an A and an AAAA record has two ways to be reached, and clients differ on which they try first.
The specific failure worth knowing is an AAAA record left behind pointing at an address that no longer serves anything. Browsers hide it by trying both families in parallel. A terminal, a probe or a server-to-server call frequently does not, so it fails while everyone in the office sees a working site. Force the family to prove it:
curl -4 -sSI https://example.com/
curl -6 -sSI https://example.com/What to watch
Most monitoring records whether a name resolved. The more useful assertion is what it resolved to.
Store the address per hostname and alert on it changing. A change you performed is one line to acknowledge. A change you did not perform is either a migration nobody told you about, a provider action, or a compromise, and all three want attention the same day.
It is the same reasoning that makes a nameserver set worth watching rather than merely a domain's expiry date, and it costs one comparison per check. What it removes is the class of incident where the site has been serving from the wrong machine for a fortnight and the first evidence is a client noticing that their content reverted.
