DNS is the service most business IT problems eventually trace back to, and the one least understood by the people troubleshooting them. This article covers the operational concepts — not the full protocol specification — that actually matter when a domain stops resolving, mail stops delivering, or a website intermittently fails to load.
Authoritative vs. recursive: two different jobs
DNS has two fundamentally different roles that get conflated constantly.
Authoritative DNS is the source of truth for a specific domain's records. When you configure an MX record, an SPF record, or an A record at your DNS host (Cloudflare, GoDaddy, Route 53, your registrar), you're writing to the authoritative server for that domain. It answers one question: "what does the owner of this domain say this record is?"
Recursive DNS (also called a resolver) is the service your computer, phone, or company network actually queries when it needs to look something up. It doesn't know the answer itself — it asks around, starting at the root, working down through the correct top-level domain server, and finally the domain's own authoritative server, then caches the answer for a while so it doesn't have to repeat the whole walk next time.
The distinction matters operationally because most DNS troubleshooting confusion comes from mixing these two up. If you change a record at your authoritative DNS host and it doesn't "take effect" immediately everywhere, that's not a authoritative-side problem — it's recursive resolvers around the world still serving their cached (now stale) copy of the old answer. That's propagation, and it's governed by TTL, not by how fast your DNS host applies changes.
Record types that actually come up in business IT
| Record | What it does | Common business-IT relevance |
|---|---|---|
| A | Maps a hostname to an IPv4 address | The most basic record; a website or service being unreachable usually starts here |
| AAAA | Maps a hostname to an IPv6 address | Increasingly relevant — see IT KORR's IPv6 Readiness Checker |
| CNAME | Aliases one hostname to another | Common for third-party services (mail.company.com → a hosted email provider) |
| MX | Specifies which mail servers accept email for the domain, with priority | Misconfigured MX is one of the most common causes of "email just stopped working" |
| TXT | Free-form text record | Where SPF, DMARC, and domain-verification records live — see the Email Authentication Architecture article |
| NS | Delegates authority for a (sub)domain to specific nameservers | Wrong NS records mean you're editing records that don't actually control the live domain |
| SOA | Start of Authority — administrative metadata for the zone, including the refresh/retry/expire timers secondary nameservers use | Rarely edited directly, but its serial number not incrementing is a real, if rare, cause of changes silently not propagating to secondaries |
| CAA | Specifies which Certificate Authorities are allowed to issue TLS certificates for the domain | A real security control, not just informational — see the DNS Troubleshooting and Security Signals article |
Delegation: who actually controls a domain's answers
A domain's NS records at the registrar point to the nameservers that are authoritative for it. This is delegation, and it's a real, frequent source of "I changed the record but nothing happened" confusion: if you're editing DNS records in a control panel that isn't actually the one your domain's NS records point to, your changes are invisible to the live domain — you're editing a zone nobody is asking.
This happens most often after a provider migration (moving from one DNS host to another, or from a registrar's default DNS to a third-party host like Cloudflare) where the NS records at the registrar were never updated to point at the new host, or were updated but the old host's zone still has stale, live-looking records that make the mistake hard to notice.
TTL: why "it should be instant" is wrong
Time To Live (TTL) is a value on every DNS record telling recursive resolvers how long they're allowed to cache the answer before asking again. A 3600-second TTL means a resolver that cached the old value 10 minutes ago will keep serving that stale answer for up to 50 more minutes, regardless of how fast the authoritative record was actually changed.
This is why "propagation" isn't really a single global event — it's every individual resolver's cache expiring on its own schedule. Two operational implications that matter in practice:
- Before a planned migration (changing mail providers, moving a website, changing DNS hosts), lower the TTL on the records you're about to change well in advance — often 24-48 hours before the cutover — so that when you do make the change, stale caches expire quickly instead of persisting at the old TTL's full duration.
- After an unplanned incident (a record was wrong and you just fixed it), understand that some visitors/systems will still see the old, broken answer until their resolver's cache naturally expires — there is no way to force this globally.
Common operational failures
- Wrong NS records after a provider migration — editing DNS at a host that isn't actually authoritative for the domain (see Delegation, above).
- MX record pointing at a decommissioned mail server — often left behind after a mail provider migration where every other record was updated.
- A TXT record silently overwritten — many DNS control panels don't clearly show that a domain can have multiple TXT records; adding a new one (for a new SaaS tool's domain verification, for example) without realizing it can accidentally replace rather than add to existing SPF or other TXT records.
- TTL left too high before a migration, causing a much longer-than-expected cutover window.
- A missing or incorrect SOA/NS setup after adding a subdomain delegation, where the subdomain resolves inconsistently depending on which resolver is asked.
Practical next steps
Run IT KORR's DNS Health Checker against your domain to see its actual current MX, NS, and record configuration rather than what you assume is configured. If the findings point toward email authentication specifically, continue to Email Authentication Architecture. For DNSSEC and CAA — the security-adjacent side of DNS — see DNS Troubleshooting and Security Signals.
This article covers DNS itself; for how DNS, DHCP, and IP address management work together as a complete network-services layer, see DNS, DHCP, and IPAM in the Infrastructure & Networking cluster.