How DNS Records Work

Every server on the internet is reached by an IP address, a string of numbers like 104.16.132.229. Nobody wants to remember that, so DNS (the Domain Name System) exists to translate a name you can remember, like example.com, into the address a computer needs. It is often described as the phone book of the internet, and that is a fair description as long as you remember it is a phone book with millions of local branches, each responsible for a small slice of the whole thing.

DNS is not one database sitting on one server. It is a distributed system of records, held by thousands of different name servers, each authoritative for a particular domain or set of domains. When you run a check on Frabs, our DNS Lookup tool is asking the internet's own resolvers the same question your browser asks, then showing you the raw answer.

A domain can hold many kinds of records, but in practice you only need to recognise a handful of them.

• A record: points a name to an IPv4 address. This is the one most sites depend on directly.
• AAAA record: the IPv6 equivalent of an A record, for addresses in the newer, longer format.
• CNAME record: points a name to another name rather than an address. Commonly used for things like www.example.com pointing at example.com.
• MX record: tells other mail servers which machine handles email for the domain, and in what priority order.
• TXT record: free text attached to a domain, used for anything from proving ownership to publishing SPF and DMARC rules.
• NS record: lists the name servers that are authoritative for the domain, meaning they hold the master copy of its records.

When your computer needs to resolve example.com, it usually does not go straight to the source. It asks a resolver, often run by your ISP or a public option like 1.1.1.1, and that resolver does the legwork on your behalf.

1. The resolver checks whether it already has a fresh answer cached from a previous lookup. If so, it replies immediately.
2. If not, it asks one of the root name servers, which does not know the answer but knows which servers handle the .com top level domain.
3. It then asks a .com name server, which does not know the final answer either, but knows which name servers are authoritative for example.com specifically.
4. Finally it asks that authoritative server, gets the actual record, and hands the answer back to your computer.

That whole chain usually happens in well under a second, and almost always ends with the answer being cached somewhere along the way so the next person asking does not have to repeat all four steps.

Every DNS record has a TTL, or time to live, measured in seconds. It tells any resolver caching that record how long it is allowed to keep serving the cached answer before it has to ask again. A TTL of 3600 means an hour. A TTL of 86400 means a full day.

This is why changing a record does not update instantly for everyone. Some resolvers around the world are still holding onto the old answer until their cached copy expires. This is often called propagation, though nothing is actually spreading anywhere, each individual resolver is simply working through its own cache on its own schedule. If you plan a change in advance, lowering the TTL a day or two beforehand means fewer resolvers will be holding a long lived cached answer when you make the switch. The DNS Propagation tool checks a domain against several major public resolvers at once, which is a faster way to see how far a change has actually spread than repeatedly checking from your own device.

When you run a domain through the DNS Lookup tool, an empty result for a record type is not automatically a problem. A domain with no MX records simply is not set up to receive email. A domain with no AAAA record is not reachable over IPv6, which is common and rarely urgent. What matters is whether the records present match what you expect for that domain: the right A record pointing at your current host, the right MX records pointing at your mail provider, and NS records that match the name servers your registrar or DNS provider actually gave you.

dig example.com A +short
dig example.com MX +short
nslookup -type=NS example.com

• No A or AAAA record at all: the domain has never been pointed anywhere, or the records were removed.
• A record present but the site does not load: the record may be correct while the server it points to is down, or a firewall is blocking the connection.
• MX records missing after a provider migration: a common cause of email suddenly bouncing, usually because the old records were deleted before the new ones were confirmed working.
• NS records that do not match your DNS provider: the domain is still delegated to a previous provider, so changes made in your current dashboard will not show up anywhere.