What an A record is and is not
The A record is the oldest and simplest record type in DNS: a name on the left, one IPv4 address on the right. It carries no port, no protocol, and no path. example.com having an A record says nothing about whether a web server is listening on port 443, only about where packets addressed to that name should go.
A name can hold several A records at once. All of them are valid answers, and the resolver hands the client the full set — usually rotated, which is where the term round-robin comes from. Clients then pick one, and modern browsers will fall back to the next address if the first refuses a connection. Multiple A records therefore give you crude load spreading and crude failover, but no health checking: DNS has no idea whether an address is alive.
dig +noall +answer example.com A
example.com. 300 IN A 172.66.147.243
example.com. 300 IN A 104.20.23.154How to read the results
- Several addresses in unrelated network ranges usually means a CDN or a multi-provider setup. Confirm with an ASN lookup — it names the network that owns each address.
- A single address that changes between checks is geo-steering or weighted routing at the DNS layer. Different resolvers get different answers on purpose. DNS Compare makes this visible instantly.
- No A records but the name exists is normal for a name that only publishes MX or TXT records, and normal for an IPv6-only host. Check AAAA before concluding anything is broken.
- NXDOMAIN means the name itself is absent. No A record can be added until the name exists — check the zone, the delegation, and the spelling.
- An RFC 1918 address (10.x, 172.16–31.x, 192.168.x) in a public zone resolves fine but is unreachable from the internet. This is a real and common misconfiguration after a migration from an internal DNS view.
Read the full explanation of a record lookup results ↓Show less ↑
The TTL is as informative as the address. A TTL of 30–60 seconds signals an actively managed, failover-capable setup. A TTL of 86400 signals a record nobody expects to change — and warns you that any change you make today will still be cached somewhere tomorrow.
A record or CNAME?
Use an A record when you control the IP address and it is stable. Use a CNAME when you are pointing at a service whose address the provider changes without telling you — a load balancer, a SaaS host, an object-storage endpoint. Hard-coding a provider's current IP into an A record is the most common cause of a site that mysteriously dies months later, when the provider retires that address.
The exception is the zone apex. example.com cannot be a CNAME, so apex records must be A (or AAAA), or the provider's ALIAS/ANAME/flattening equivalent — which resolves to A records on the wire and will appear here as A records.
Common failures and fixes
- Chrome shows DNS_PROBE_FINISHED_NXDOMAIN. The name does not exist. Verify the exact hostname — a missing
wwwrecord is the usual cause — and confirm the domain is registered and delegated with WHOIS and an NS lookup. - The A record is right but the site does not load. DNS is doing its job; the problem is further along. Check that the host accepts connections on 80/443 with the port checker and that the certificate matches the hostname with the SSL checker.
- You updated the IP and still reach the old server. Your resolver is serving a cached copy until the old TTL expires. Verify what the authoritative servers hold with
dig @ns1.yourprovider.com example.com A, then wait out the TTL. Flushing your own OS cache does not flush your ISP's. - The record points at your Cloudflare-style proxy, not your origin. When a record is proxied, the published A record is the proxy's anycast address by design. The origin address is intentionally hidden; nothing is broken.
- Two A records, one of them dead. Half of your users see a hang before the browser retries. DNS does no health checking — remove the dead address rather than relying on client fallback.
- www works, apex does not (or vice versa). They are separate names needing separate records. Add the missing one, or a redirect at the web layer.
The same check from the command line
# Just the addresses
dig +short example.com A
# With TTL and full answer section
dig +noall +answer example.com A
# Ask a specific public resolver instead of your own
dig @9.9.9.9 +short example.com A
# Ask the authoritative nameserver, bypassing every cache
dig +short @$(dig +short example.com NS | head -1) example.com A
# See the response code (NOERROR / NXDOMAIN / SERVFAIL)
dig example.com A | grep -E 'status:|ANSWER:'