DNS Records Explained: A, AAAA, CNAME, MX, TXT and TTL With Real Lookups

A company moves its website to a new host, updates DNS, and half its visitors still see the old site the next day. Another adds a new email service and suddenly its invoices land in spam. Both stories come down to DNS records: what they contain, how long they are cached, and the rules each type must follow.

We looked up public test domains from a Windows machine using Python’s resolver and the nslookup tool. The results are from that run; IP addresses are summarised rather than listed, since they can change. Provider dashboards and command options vary, so some steps below are general guidance.

What is DNS?

The Domain Name System is the internet’s distributed directory. Computers connect using IP addresses, but people remember names. DNS answers the question “what is the address, or mail server, or verification text, for this name?” It is distributed: no single server knows everything, and each domain’s owner controls the records for their own names through their DNS hosting provider.

How a lookup works

1. Your app asks the operating system to resolve example.com.
2. The OS asks a recursive resolver, usually run by your network, ISP or a public DNS service.
3. If the resolver has no cached answer, it asks the root servers, then the .com servers, then the domain’s authoritative name servers.
4. The answer comes back with a TTL, and is cached along the way.

example.com:            3 address(es), v4=2, v6=1, 0.039s
repeat lookup:          0.007s
does-not-exist.invalid: gaierror 11001

The first lookup took 39 ms; the repeat took 7 ms because the answer was already cached. The .invalid name, reserved so that it never exists, failed with a “host not found” error, which is what an application sees when a domain is mistyped or has expired.

Record types at a glance

A and AAAA records

An A record maps a name to an IPv4 address, such as 203.0.113.10; an AAAA record maps it to an IPv6 address. A name can have several of each, and our lookup of example.com returned two IPv4 addresses and one IPv6 address. Clients usually pick among multiple addresses, which spreads load and provides some redundancy, though it is not a replacement for a proper load balancer or health checks.

CNAME records

www.example.com.    CNAME   example.com.
shop.example.com.   CNAME   stores.some-saas.example.

A CNAME says “this name is an alias; look up that other name instead.” It is ideal for pointing a subdomain at a service whose IP addresses may change, since the provider manages the target’s records. Two rules cause most CNAME problems:

• A name with a CNAME cannot have any other records, such as MX or TXT, at the same name.
• Therefore the bare root domain (example.com itself), which must have NS and SOA records, cannot be a CNAME.

Many DNS providers offer “ALIAS”, “ANAME” or “CNAME flattening” to point the root domain at another name; the provider resolves it behind the scenes and returns A records.

MX records

nslookup -type=MX example.com
example.com   MX preference = 0, mail exchanger = (root)

MX records name the servers that receive email for a domain, each with a preference number; lower numbers are tried first, and higher ones are backups. Our lookup shows a special case: example.com publishes a null MX, a single MX pointing to the root, “.”. It is a standard way of saying “this domain accepts no email”, so senders give up immediately instead of retrying. MX targets must be host names with A or AAAA records, not IP addresses and not CNAMEs.

TXT records

nslookup -type=TXT example.com
example.com   text = "v=spf1 -all"

TXT records hold text that other systems read. The most important uses are email authentication:

• SPF lists which servers may send mail for the domain. v=spf1 -all, which we found on example.com, means “no server may send mail for this domain”, the companion to its null MX.
• DKIM publishes public keys used to verify signatures on outgoing mail.
• DMARC tells receivers what to do when SPF or DKIM checks fail, and where to send reports.

TXT records are also used to prove domain ownership to services such as search consoles, email providers and certificate authorities. Delete old verification records only when you are sure nothing still relies on them.

NS and SOA records

NS records list the authoritative name servers for a domain, usually set at the registrar. If they point to the wrong provider, every other record you edit is ignored, because the world is asking a different set of servers. The SOA (start of authority) record holds administrative details for the zone, such as the primary server and timers. You rarely edit it directly.

Other useful records

CAA records restrict which certificate authorities may issue TLS certificates for your domain, reducing the risk of a mis-issued certificate. PTR records provide reverse lookups from IP to name, which mail servers check for sending IPs. SRV records point clients to the host and port of specific services. Most websites only need A/AAAA, CNAME, MX and TXT, but knowing the others helps when a service’s setup guide asks for them.

TTL and caching

Every record has a TTL, time to live, in seconds. Resolvers and devices cache the answer for that long. A TTL of 3600 means a change may take up to an hour to be seen everywhere; 86400 means up to a day. Our repeat lookup, 7 ms against 39 ms, shows why caching exists: it makes the internet faster and reduces load on DNS servers. The cost is that changes are not instant, which is why people talk about “DNS propagation”. There is no real propagation step; caches simply expire at different times.

Changing DNS safely

1. Lower the TTL on the records you will change, for example to 300 seconds, at least one old TTL period beforehand.
2. Prepare the new destination and test it directly, for example with a hosts file entry, before switching.
3. Make the change and verify it by querying the authoritative name servers directly.
4. Keep the old server running until the old TTL has expired everywhere.
5. Raise the TTL again once everything is stable.

Export or screenshot your current records before any change. A single deleted TXT record can break email authentication or a verification that no one remembers setting up. If your infrastructure is managed as code, as in our Terraform tutorial, DNS records can be reviewed and versioned like everything else.

Troubleshooting

• Check what the world sees: nslookup name on Windows, or dig name on Linux and macOS.
• Ask a specific resolver to compare answers, such as a public DNS service.
• Check the NS records first if your changes seem to be ignored.
• Separate DNS from the web server: if the name resolves correctly but the page fails, the problem is further along; the status code tells you where, as listed in our HTTP status codes cheat sheet.
• Flush local caches, such as ipconfig /flushdns on Windows, when testing a change.
• Remember HTTP caching too: a correct DNS answer can still show an old page cached by a browser or CDN, as covered in HTTP caching explained.

Final thoughts

DNS records are simple individually: A and AAAA for addresses, CNAME for aliases, MX and TXT for email and verification. Most problems come from the rules around them, such as no CNAME at the root, one SPF record per domain and caching controlled by TTL. Lower TTLs before changes, keep a copy of your records, and check what authoritative servers actually return before declaring a change done.

Frequently asked questions

Keep learning