Skip to content

A Record Lookup

An A record maps a hostname to a 32-bit IPv4 address. This lookup returns every A record a name publishes, with the exact response code behind an empty answer, so you can tell "this host has no IPv4 address" apart from "this name does not exist" — two problems with entirely different fixes.

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.154
Two A records at one name, both served, TTL 300 seconds.

How 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 ↓

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

  1. Chrome shows DNS_PROBE_FINISHED_NXDOMAIN. The name does not exist. Verify the exact hostname — a missing www record is the usual cause — and confirm the domain is registered and delegated with WHOIS and an NS lookup.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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:'
The last command is the fastest way to distinguish an empty answer from a nonexistent name.
Reverse the lookup with a reverse DNS (PTR) check to see what name an address claims for itself. Forward and reverse do not have to match, and for mail servers, mismatches cause deliverability problems.

Frequently asked questions

Why does one domain return several IP addresses?
Because the zone publishes several A records at that name. Resolvers return all of them, generally in rotating order, and the client picks one. It is used for basic load distribution and for CDNs that advertise multiple edge addresses. It is not failover in any real sense — DNS does not know whether an address is up.
How long does an A record change take to go live?
Up to the TTL of the record being replaced, measured from when each resolver last cached it. The authoritative change is instant; the wait is entirely about caches expiring. Lower the TTL to 300 seconds a day before a planned change, then raise it again once the new address is stable.
Can an A record point to a hostname instead of an IP?
No. An A record's value must be a literal IPv4 address. If you need to point at a name, use a CNAME — or, at a zone apex where CNAME is illegal, your provider's ALIAS/ANAME record, which resolves the target and serves the resulting addresses as A records.
Is it a problem that my A record has a very high TTL?
Only when you need to change it. A high TTL reduces query volume and improves resilience if your nameservers become unreachable. The cost is agility: with a 24-hour TTL, an emergency IP change takes a full day to reach everyone. Many operators keep 3600 as a compromise and drop to 300 before planned work.
Why do I see a private 192.168 address for a public domain?
Someone published an internal address in a public zone — often because an internal split-horizon view was copied into the external zone during a migration. It resolves everywhere but is routable nowhere outside that network, so external users see a connection timeout rather than a DNS error.
Does an A record affect email delivery?
Indirectly. If a domain publishes no MX records, RFC 5321 allows senders to fall back to the A record and deliver there, so a stray A record on a domain that should not receive mail can silently swallow messages. Check what mail routing you actually publish with the MX lookup.
What does it mean when different resolvers return different A records?
Either the record is mid-change and some caches still hold the old value, or the authoritative provider is deliberately answering differently by geography or load. The TTL tells you which is plausible; DNS Compare shows you the spread across four major resolvers at once.