Boneyard Tools

How DNS records work, from the root zone to your browser

A tour of how DNS records are organized into zones, how a lookup resolves step by step, and how TTLs and record types fit together.

Records, zones and the domain name tree

Every DNS record is a small entry that maps a name to some data, such as an A record mapping example.com to an IPv4 address. Records are grouped into zones, and a zone is the slice of the domain tree that one set of name servers is responsible for. The tree starts at the root, branches into top-level domains like com and org, and continues down through your registered domain and any subdomains. NS records at each level delegate authority downward, which is how the system stays distributed rather than living in one giant file.

What happens during a lookup

When your browser needs an address it asks a resolver, which walks the tree on your behalf. The resolver queries a root server to learn the name servers for the top-level domain, queries those to learn the name servers for the domain, and finally asks the authoritative server for the exact record, for example the A or AAAA record. Each answer can be cached along the way, so popular names resolve almost instantly on repeat visits. The SOA record at the top of each zone holds the timers and serial number that govern how this caching and zone transfer behaves.

TTL, caching and why changes take time

Every record carries a time to live, a number of seconds that tells resolvers how long they may cache the answer before asking again. A low TTL means changes propagate quickly but generates more queries, while a high TTL is efficient but makes edits slow to appear worldwide. This is why a freshly changed A record can still resolve to the old address for some visitors until the previous TTL expires. Lowering the TTL a day before a planned migration is a common way to make cutover feel instant.

Picking the right record for the job

Matching the task to the record type avoids most DNS mistakes. Use A and AAAA to point a name at a server, CNAME to alias a subdomain to another name, and ALIAS at the apex where CNAME is forbidden. Reach for MX plus SPF, DKIM and DMARC TXT records to run and secure email, and add CAA to control which certificate authorities may issue for the domain. The explainer above lets you search any of these to confirm its purpose and see a valid example before you save it.

Frequently asked questions

Why can I not put a CNAME at the root domain?

A CNAME must be the only record for a name, but the apex already needs SOA and NS records, so a CNAME there would conflict. Providers solve this with ALIAS or ANAME records that behave like a CNAME but resolve on the server side.

How long do DNS changes take to appear?

It depends on the TTL of the old record and on caches along the path. Changes are often visible within minutes with a low TTL, but can take up to a day or more if the previous TTL was long.