A Record Lookup

An A record (address record) is the DNS resource record that holds a 32-bit IPv4 address for a name. RFC 1035 defined it in 1987 and it is still the most common record type on the internet. When you open a website, the resolver fetches this record and hands the address to your operating system, which connects to it.

example.com.      3600  IN  A  203.0.113.10
www.example.com.  3600  IN  A  203.0.113.10

The fields are the name, the TTL in seconds, the class (IN for internet), the type and the address. A name can hold any number of A records, each with its own TTL. An A record never holds a hostname or an IPv6 address. Hostnames go in CNAME records and IPv6 addresses go in AAAA records.

An A record lookup returns every IPv4 address published for the name and the TTL remaining on each one. Our DNS lookup tool sends the same question to Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) and OpenDNS at the same time and marks whether they agree. DNSX also looks up each address and shows its city, country and the autonomous system that announces it, so you can see whether a site is on Cloudflare, AWS or a shared host. Our IP address lookup gives the same detail for one address.

Open Command Prompt or PowerShell. nslookup ships with every version of Windows, and Resolve-DnsName is the PowerShell cmdlet. Add a resolver address, as in the last two lines, to ask a public resolver instead of your network's.

nslookup -type=A example.com
Resolve-DnsName -Type A example.com
nslookup -type=A example.com 8.8.8.8
Resolve-DnsName -Type A example.com -Server 1.1.1.1

macOS ships dig, so no install is needed. Open Terminal and run one of these. The +short form prints only the record values, and the @ form sends the query to a specific resolver.

dig A example.com
dig A example.com +short
dig @1.1.1.1 A example.com

dig and host come from the dnsutils package on Debian and Ubuntu and from bind-utils on Fedora and RHEL. The +noall +answer options print only the answer section, and +tcp forces the query over TCP when you suspect a truncated UDP answer.

dig A example.com +noall +answer
host -t A example.com

After you change a A record, the authoritative nameservers answer with the new value immediately, and every recursive resolver that cached the old record keeps serving it until the cached TTL runs out. Our DNS lookup tool above shows whether Google, Cloudflare, Quad9 and OpenDNS agree yet, and the Authoritative option reads the value straight from the zone's own nameservers. The DNS propagation checker asks resolvers in more locations and lays the results out side by side.

Publishing several A records for one name is the oldest form of load balancing, described in RFC 1794 as round robin DNS. The nameserver returns the whole set, most resolvers rotate the order on each answer, and a client that cannot reach the first address usually tries the next.

Round robin is not health aware. A dead server stays in rotation until someone removes the record. CDNs and cloud load balancers answer with a short TTL instead, often 60 to 300 seconds, and return different addresses depending on where the query came from (GeoDNS). So two resolvers can show different addresses for a CDN-fronted domain with no propagation problem at all.

No. The zone apex (the bare domain, example.com with no www) must carry SOA and NS records, and RFC 1034 section 3.6.2 forbids any other record at a name that holds a CNAME. So the apex can only have A and AAAA records, which is a problem when your host gives you a hostname rather than a fixed address.

DNS providers answer this with a synthetic record called ALIAS, ANAME or CNAME flattening. You point the apex at a hostname, and the provider's nameserver resolves that hostname at query time and returns the resulting A records. Route 53 alias records, Cloudflare CNAME flattening and the ALIAS type at DNSimple and NS1 all work this way. The IETF draft for a standard ANAME type was never finished.

Almost always because a cache has not expired yet. If the TTL was 86,400 seconds, a resolver that cached the record a minute before your change serves the old address for almost a day. Lowering the TTL to 300 seconds a day before a planned move keeps that window short.

Other caches sit between you and the nameserver: the browser, the operating system (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS) and often the home router. Pick the Authoritative option in the tool above to confirm the zone already has the new address, then compare the public resolvers to see which caches still hold the old one.

Every lookup on DNSX is also a JSON endpoint on api.dnsx.dev that you can call from curl or a script with no API key. The response has one result per resolver with its records and TTLs.

curl https://api.dnsx.dev/dns/a/github.com