Owning a domain and understanding how DNS works are two different things. Most site owners know they need to “point” their domain somewhere and that changes take time to spread. This post closes the gap: what DNS is, what the records mean, what goes wrong, and why TTL is the number worth caring about before any launch or migration.
What DNS is and why it exists
DNS stands for Domain Name System. When you type a domain into a browser, DNS converts that human-readable name into the IP address of the server hosting the site. Without it, you’d need to memorise 192.0.2.44 or whatever numeric address your host assigns, and update it everywhere each time you switched providers.
The system is distributed. Rather than one central directory, DNS is a hierarchy of nameservers spread across the world. At the top are root servers that know which servers are authoritative for each top-level domain (.com, .co.uk, .io). Those TLD servers point to the nameservers for your specific domain. Your nameservers hold the actual records.
How a lookup works
When someone visits your site, here is the chain of events:
- The browser checks its own cache. If it asked recently and the answer hasn’t expired, it reuses it.
- If not cached, the operating system asks a recursive resolver, usually provided by an ISP or a public DNS service like Cloudflare’s
1.1.1.1or Google’s8.8.8.8. - The resolver queries a root server, then the TLD server for your domain’s extension, then your authoritative nameserver.
- The authoritative nameserver returns the IP address mapped to your domain.
- The browser connects to that IP and loads your site.
Under normal conditions this takes 20–100 milliseconds. Resolvers cache answers, so repeat visitors skip most of the chain.
The authoritative nameserver is the one you control. Every other server in the chain is reading from it. When you change a DNS record, you change it there.
The records you’ll actually encounter
DNS records are entries in your nameserver’s zone file. There are dozens of record types, but these are the ones site owners touch.
A record: Maps a domain or subdomain to an IPv4 address. The most fundamental record. If your domain points to a hosting server, an A record is doing it.
CNAME record: Points a subdomain to another hostname rather than an IP address. Used when a host or CDN gives you a domain instead of a fixed IP. One constraint: you cannot put a CNAME on the root domain (the apex), because it conflicts with other records at the same label. Hosts like Vercel and Netlify offer workarounds for this, often called ALIAS or ANAME records.
MX record: Directs inbound email. Every mail provider asks you to set or update MX records. Priority order is set by numeric values on each entry; lower numbers win. Get these wrong and inbound mail bounces or routes to the wrong service.
TXT record: Stores arbitrary text strings. Used for domain ownership verification (Google Search Console, third-party integrations) and email authentication (SPF, DKIM, DMARC). Misconfigured SPF and DKIM records cause legitimate outbound email to land in spam folders. If you’re setting up a new domain, TXT records are where the most common configuration mistakes happen.
NS record: Lists the nameservers responsible for your domain. Changing NS records is how you move DNS management from one provider to another. These propagate slowly because they carry a long TTL by default.
TTL: the number to care about before any change
Every DNS record carries a TTL (Time to Live), measured in seconds. TTL tells resolvers how long to cache the answer before checking again. A record with a TTL of 3600 is cached for one hour by every resolver that fetches it. Change the record, and any resolver that already cached the old answer won’t pick up the new one until its timer expires.
This is why DNS changes don’t take effect instantly. “Propagation” is the global process of cached copies expiring and resolvers re-fetching from your authoritative nameserver. The longest possible wait equals the TTL that was set at the moment of the change.
The practical rule: lower your TTLs before any planned cutover. Set them to 60 or 300 seconds a day or two in advance. Make the switch, and most visitors see the new records within minutes instead of hours. Once the new configuration is confirmed working, raise TTLs back to a sensible default (3600 is fine for most records). A very low TTL increases DNS query volume slightly, but that load is negligible for any normal site.
TTL preparation is one of the steps that separates a clean migration from a chaotic one. If you’re planning a host change, moving a site without losing traffic covers the full sequencing from DNS through redirects.
What goes wrong
DNS problems tend to cluster around a handful of patterns.
Stale records after a host change. An A record still pointing at an old server IP that now serves a parking page. After any migration, read through every record in your zone file before assuming you’re done.
CNAME conflicts. A CNAME on the root domain alongside MX or TXT records breaks both mail delivery and domain verification at once. Most DNS managers will warn you; some don’t.
Email authentication gaps. Missing or incorrect SPF, DKIM, or DMARC records cause outbound email to fail spam filters silently. These are TXT records and are easy to overlook when provisioning a new domain or adding a third-party sending service. The website security basics guide covers what each of those records does and why they matter together.
Nameserver mismatch. You updated records in your registrar’s panel, but the domain still delegates to an old nameserver. Your changes exist but are never served.
Confusing DNS with HTTPS. DNS gets visitors to the right server. It does nothing to encrypt the connection. If that part is still unclear, HTTPS, SSL, and TLS explained picks up from here.
When diagnosing, run a lookup using dig on the command line, or an online tool like dnschecker.org. Compare what your authoritative nameserver returns against what a global resolver returns. The gap between those two answers tells you whether you’re looking at a propagation delay or a configuration error.
How Strynal approaches DNS
DNS lives at the bottom of every launch and every migration. The decisions made there (TTLs, record sequencing, email authentication) determine whether a cutover takes ten minutes or ten hours, and whether email keeps working throughout.
Our process starts with an audit: what’s in the zone file, what TTLs are set to, whether SPF and DKIM are in place. We lower TTLs well ahead of any cutover, sequence record changes so email is never in a broken state, and verify from multiple geographic vantage points before calling it done.
For clients on an ongoing plan, DNS health is a standing check. Misconfigured records, new third-party services needing authentication entries, and changes that quietly broke something are the kinds of things that surface between launches. We cover this under website care and maintenance, which is part of the broader websites and apps practice at Strynal.
If your domain has inherited records from a previous developer and nobody’s documented what points where, that’s a tangle we work through regularly. It’s usually fixable in an afternoon once someone reads the zone file clearly and traces what each record is actually doing.