How DNS works for someone who just bought a domain

A new domain does nothing until it is told where to go. Several different services can be involved in that, they use similar words, and the settings page that matters is often not at the place where you paid. Once the pieces are named, DNS is a short chain of lookups with a cache at each link, and every symptom you will meet falls out of that.

The lookups quoted below are real, made on 2026-10-17 against example.com and iana.org (domains that exist for documentation and reference), from one laptop with dig 9.10.6. They are illustrations of what the output looks like. Addresses, TTLs and servers change, and a different resolver would print different numbers.

Four roles, often confused

RFC 9499, the DNS terminology document, defines the registry and registrar roles in these terms. You can buy at one place, run DNS at a second and host the site at a third. The only link between registrar and DNS host is a set of NS records saying which nameservers answer for the domain. Everything else you configure lives in the zone at the DNS host.

What happens when someone visits your name

A visitor types example.com. Their device asks a recursive resolver, usually run by their network or a public service. RFC 9499 describes such a resolver as expected to cache the answers it receives. If it holds a fresh answer, it replies at once. If not, it works down the tree:

1. It asks a root server where the servers for .com are.
2. It asks a .com server which nameservers are in charge of example.com. That answer is the delegation, the NS records your registrar published at the registry.
3. It asks one of those authoritative nameservers for the record. This is the one place where your configuration is the source of truth.
4. It caches the answer for as long as the TTL allows and returns it.

The device then connects to the address it received. DNS only says where to go. The HTTP request, certificate and page all come afterwards from the web host.

The records you will actually touch

The addresses in the table are reserved for documentation (192.0.2.0/24 in RFC 5737 and 2001:db8::/32 in RFC 3849), so they never belong to a real server. Use the same convention when you write examples.

Two details are easy to get backwards. In an MX record, RFC 1035 says lower preference values are preferred, so 10 is tried before 20. And SPF, the sender policy, lives in an ordinary TXT record: RFC 7208 says SPF records must be published as TXT and that the old dedicated record type has been discontinued.

Real records show both. At the time of the lookup, iana.org published four MX records, all at preference 10 (equal numbers mean equal preference). example.com published MX 0 . and a TXT record v=spf1 -all. That odd-looking MX is a "null MX" from RFC 7505: preference 0 and a zero-length name, meaning there is no mail exchanger for the domain. The TXT record is the policy RFC 7208 gives for a domain that sends no mail.

The apex CNAME rule

The root of a domain, example.com itself, is the apex. RFC 9499 defines it as the owner of the zone's SOA record and its authoritative NS records. RFC 2181 section 10.1 says that for any name in the DNS exactly one of these is true: a CNAME exists (with only DNSSEC records alongside), or other records exist and none is a CNAME, or the name has no records, or it does not exist. RFC 1912 states the consequence for zone operators: a CNAME is not allowed to coexist with any other data, and its example of the mistake is a CNAME placed next to NS records at a domain's top. So a CNAME at the apex collides with the SOA and NS records that must be there.

Some DNS providers fake it with a flattened "ALIAS" or "ANAME" record that looks up the target on their side and returns plain A answers. That is a vendor feature outside the standard, and not every provider offers it. The practical rule: the apex gets A and AAAA records, www gets a CNAME to a hostname the host gives you, and the host's dashboard gives the exact values. If it asks for a CNAME at the apex, look for its alternative before assuming your DNS can do it.

The same rule explains a real chain from the lookups: www.iana.org was a CNAME to a CDN hostname, and each link carried its own TTL (3600 seconds for the CNAME, 300 for the A records it led to).

TTL: the number that explains most of the waiting

Every record carries a TTL, in seconds, that says how long a resolver may reuse the answer. 300 is five minutes and 86400 is a day. RFC 2181 specifies the TTL as an unsigned number with a maximum of 2147483647, and says it is a maximum time to live, not a mandatory one; implementations are free to place an upper bound on any TTL they receive.

When you change a record, nothing is pushed to anyone. Resolvers that cached the old value keep returning it until their copy expires; resolvers that never cached it see the new value immediately. That is all "propagation" is: many independent caches expiring at different moments. Two consequences:

• The old TTL decides the wait. A record cached with a day-long TTL can stay in caches for up to a day after you edit it, whatever TTL the edit sets. Lowering the TTL ahead of a planned change is the lever, and pointing a domain at a new host without downtime builds a full cutover plan on it.
• Failures are cached too. RFC 2308 describes negative caching: the authoritative server includes the zone's SOA record with a "no such name" answer, and its TTL is the smaller of the SOA's own TTL and the SOA minimum field, which RFC 2308 redefines as the negative-answer TTL. Look up a name before you create the record and a resolver may remember "not found" for that long.

A real example of the second point: asking iana.org's authoritative server for a name that does not exist returned NXDOMAIN with an SOA whose TTL was 3600 and whose minimum field was 3600, so a resolver may cache the miss for up to 3600 seconds. The same question put to Google's public resolver (8.8.8.8) came back with 1226 seconds left on one attempt and 1800 on the next: that resolver kept the miss for less than the authoritative cap, which RFC 2181 permits.

Diagnosing with dig

dig prints exactly what came back. Ask these questions in this order.

dig example.com NS +short
dig example.com A +noall +answer
dig www.example.com CNAME +noall +answer
dig example.com MX +short
dig example.com TXT +short

To compare what different parts of the system say, ask a specific server directly. The BIND manual documents @server for choosing the server, +norecurse to clear the recursion-desired bit, +short for terse answers, +noall +answer to print only the answer section, and +trace, which makes iterative queries from the root name servers and shows each referral:

dig @ns1.example.net example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig @a.gtld-servers.net example.com NS +norecurse
dig +trace example.com A

How to read the results:

• Asking the authoritative server (@ns1.example.net) shows the truth of your zone. The reply carries the aa flag, which marks an authoritative answer. Asking a public resolver shows what that resolver has cached. Differences between the two mean a cache has not expired.
• Asking the registry's server shows the delegation itself. The real query dig @a.gtld-servers.net example.com NS +norecurse returned no answer section, no aa flag, and two NS records in the authority section with a TTL of 172800 seconds (two days), which the registry sets and you cannot change. A plain dig example.com NS through a resolver shows the zone's own NS records instead. If the two sets differ, you have a delegation problem, which RFC 9499 calls a lame delegation when a listed server does not serve the zone.
• The TTL in the answer is what remains at that resolver. Repeating the query often shows it falling. Not always: three queries to 8.8.8.8, eight seconds apart, reported 3569, 3573 and 3547 seconds left for the same record, which fits a resolver that spreads queries across several caches. Do not treat a TTL that fails to count down as a fault.
• +trace walks from the root yourself and shows where the chain breaks. When you name a server with @, the manual says it affects only the first query, for the root servers.

What can go wrong, and what it looks like

When the records are right and nothing happens

In this fictional case you register example.org at one registrar and deploy a site to a platform that tells you to add an A record for the apex and a CNAME for www. The registrar offers its own DNS panel, so you add both there. Nothing happens. A query to the registry's server shows two nameservers belonging to a different company: a placeholder service attached at purchase, not the one behind the panel you edited. The records you wrote sit in a zone nobody is asking. Pointing the delegation at the panel's nameservers, or adding the records at the service the delegation actually names, fixes it. The answer to "what do I change" was in the first dig, and it took ten seconds to find.

Keep this

• Know which service holds the registration, which holds DNS, and which serves the site.
• Ask the registry's server for the delegation (dig @<tld-server> yourdomain NS +norecurse) before editing any record.
• Use A and AAAA at the apex, and a CNAME for www.
• Treat TTL as a ceiling: check both the authoritative server and a public resolver, and lower TTLs ahead of a planned change.
• Never recreate a zone without copying MX and TXT records first.