How DNS Records Work: A, AAAA, MX, CNAME, and TXT

This guide is the mental model for A, AAAA, CNAME, MX, NS, and TXT, plus how to read them on a public domain you are allowed to inspect. For a one-box view, use DNS Record Lookup. For addresses only, use Domain to IP.

The path a query actually takes

Your stub resolver (the OS, or a browser tool’s backend) asks a recursive resolver. That resolver walks from the root to the TLD to the zone’s nameservers, unless it already has a cached answer. The records you see are whatever those nameservers published, filtered by type.

Two consequences matter for debugging:

• TTL is a permission to be stale. After you change an A record, some clients will keep the old address until their cache expires. A lookup that still shows the old IP is not always a failed deploy.
• The view depends on the resolver. Some CDNs return different A records by geography. Comparing your laptop’s dig to a web lookup can disagree without either being “wrong.”

Do not send internal names (vpn.internal, dc1.corp) to a public lookup. Those zones are not meant to be queried from the open internet, and you should only probe systems you administer.

A and AAAA: where a client connects

An A record is IPv4. An AAAA record is IPv6. Browsers that have IPv6 will often try AAAA first or in parallel (Happy Eyeballs). If you “fixed the site” by updating A and left a stale AAAA pointing at a decommissioned VIP, a slice of users will still fail.

A name can have several A or AAAA values. That is normal for DNS load balancing and for anycast edges. Domain to IP is the fast way to list those addresses. DNS Record Lookup is better when you also need to see whether the name is a CNAME onto something else.

Neither record is a guarantee that a process is listening. DNS answers “where might I send packets.” A timeout after a correct A record is a routing, firewall, or service problem - next stop is often Ping Test or HTTP Header Viewer, still only against hosts you own or have permission to test.

CNAME: an alias, not a second address

A CNAME says “this name is an alias of that name.” The resolver then looks up the target. You should not place other record types next to a CNAME on the same name (the RFC rule people still break). The common pattern is www → something.cdn.cloud, while the apex holds A/AAAA or a provider-specific flattening record.

Loops (a CNAME b, b CNAME a) and CNAMEs that point at a name with no A/AAAA are the usual outages after a marketing-site migration. The lookup will show the chain; you still have to decide which end is the mistake.

MX and NS names are sometimes written as hostnames that themselves have A records. If mail or delegation looks broken, resolve those hostnames too - a dangling MX hostname is a silent mail black hole.

MX, NS, and who is authoritative

NS records name the servers that answer for the zone. If you just moved registrars and the parent zone still delegates to the old NS set, public lookups will keep hitting the old zone no matter what you typed in the new dashboard.

MX records name mail exchangers and a priority. Lower number is tried first. MX values are hostnames, not IP addresses; those hostnames need A/AAAA of their own. Checking MX without checking the target addresses is how “we updated DNS” still leaves mail on the previous ESP.

SOA is the zone’s serial and timing metadata. You rarely debug a homepage with SOA, but a serial that never increments is a hint that the nameserver you are querying did not receive the edit you thought you published.

TXT: policy strings, not secrets

TXT is a bag of strings. SPF (v=spf1 …), DKIM selectors (v=DKIM1; k=rsa; p=…), domain verification tokens, and BIMI hints all live here. They are public by design. Anyone can read them; that is not a leak of the private DKIM key if you published only the public half.

A lookup can show you the current SPF string. It cannot tell you whether a particular message passed. For that you need the receiving mail server’s authentication results.

If a vendor asked you to “add this TXT to prove you own the domain,” look the name up after the TTL and confirm the exact token. Typos in TXT are invisible until the vendor’s checker fails.

How to read a public domain without guessing

1. Confirm you are allowed to query the name. Public marketing sites and your own zones: fine. Someone else’s internal hostname: stop.
2. Open DNS Record Lookup and enter the hostname (usually the apex or www, not a full URL with https:// and a path).
3. Read A/AAAA and CNAME first if the problem is “the website.” Read MX and TXT if the problem is mail. Read NS if the problem is “I changed hosts and nothing moved.”
4. If you only need addresses, Domain to IP is enough - it still sends the hostname.
5. Compare with dig from a second network if the answer looks geographically sticky.

The tool page is the lookup. This article is the types. If you already know you want the box, skip here and open it.

What a lookup cannot prove

A clean set of records does not mean TLS is valid - that is a different query, via SSL Certificate Checker. It does not mean the HTTP response is the one you shipped - that is HTTP Header Viewer. It does not mean reverse DNS matches; PTR lives in a different tree, covered in What Reverse DNS (PTR) Records Tell You.

It also cannot prove a change is “fully propagated worldwide.” That phrase is marketing. Caches expire on their own clocks.

Look up the published records, not a guess

If the question is “what is published for this public name,” run DNS Record Lookup. If the question is only “which IPs,” use Domain to IP. For a map of the other diagnostic tools, see Best Free Networking Diagnostic Tools. Send the hostname on purpose; do not pretend the query stayed on the machine.