What is DNS? Meaning, Records, and Lookup Flow

DNS, or Domain Name System, is the internet service that turns a readable domain such as example.com into the network address a browser needs. It works through recursive resolvers, root servers, TLD servers, and authoritative nameservers, while caching keeps repeat lookups quick.

Why DNS matters

The risk is simple: your server can be healthy while visitors still cannot reach it. DNS is the control plane for domains, hosting, CDN routing, email delivery, certificate validation, and security checks. If that control plane points to the wrong place, the rest of the stack looks broken.

A domain move can fail without touching a single website file. One wrong nameserver, one missing mail record, one stale cache, or one confident TTL change can send traffic into the weeds. Boring infrastructure earns that name only after you test it.

For HostScout readers, the useful question is not whether DNS is technical. It is who controls the authoritative DNS zone, and whether you can change records safely when you move a registrar, hosting provider, CDN, or email service.

How a DNS lookup works

When you type a domain into a browser, your device usually does not ask the final DNS server directly. It asks a recursive resolver first. That resolver may belong to your ISP, operating system, company network, or a public DNS service.

If the resolver has a fresh answer, it returns the cached result. If not, it walks the hierarchy. The lookup starts at the root layer, moves to the TLD layer for endings such as .com or .net, and then reaches the authoritative nameserver for the domain.

The authoritative nameserver is the practical source of truth. It holds the zone records for that domain. The resolver returns the answer to your device, and your browser can connect to the web server, CDN edge, mail server, or other service named in the record.

That hierarchy matters during buying and migration. A registrar controls registration and nameserver delegation. The DNS host controls the zone. A hosting provider may offer DNS, but that does not prove your active zone lives there.

The DNS records most buyers touch

Most domain owners deal with a short list of record types. The trap is that those records often belong to different products: a website, a CDN, transactional email, workspace email, SSL validation, or anti-spam policy.

A and AAAA records usually matter when a site points directly to a server. CNAME records are common with CDNs, managed hosting, landing page tools, and SaaS products. MX and TXT records protect email, so they are the records people forget during web-only moves.

Registrar, DNS host, web host, and CDN are different jobs

One provider can sell all of these services, but DNS still separates the jobs. Cloudflare, GoDaddy, Namecheap, and Spaceship appear in HostScout provider data around domains, CDN, email, or cloud services. A convenient bundle is not proof that every DNS role is active there.

Registrar means the company where the domain is registered. DNS host means the service whose nameservers answer for the zone. Web host means the server or platform serving the site. CDN means the edge network in front of the origin.

Before moving anything, check the active nameservers. If they point to a CDN or external DNS host, editing records at the registrar may do nothing. If they point to the registrar, moving the domain without copying the zone can drop the site and email together.

TTL is the delay you feel after a change

TTL means time to live. It tells recursive resolvers how long they may cache a DNS answer before asking again. Lower TTL values make planned changes easier to observe. Higher TTL values reduce repeated lookups, but they also make mistakes linger.

For a serious migration, do not change nameservers and records blindly in the same pass. Lower the relevant TTL before the move, wait for caches to age out, copy the zone, test the new target, and only then switch delegation.

The practical risk is split-brain behavior. Some visitors may reach the new destination while others still see the old answer. That is normal during propagation, but it becomes a problem when the old server, old mailbox, or old CDN setup is removed too early.

When to change DNS, and when to avoid it

Change DNS when you are pointing a domain to a new hosting provider, adding a CDN, verifying a service, moving email, or tightening security records. In those cases, DNS is the correct lever.

Avoid DNS changes when the real problem is application routing, web server configuration, certificate issuance, or account ownership. DNS can point users to the right place; it cannot fix a broken site on that server.

Use this decision rule:

• Change A, AAAA, or CNAME when the website destination is changing.
• Change MX and mail TXT records when the mail provider is changing.
• Change NS records only when the authoritative DNS host is changing.
• Leave registrar settings alone when the active nameservers already point elsewhere.

Common failure modes

The safest DNS plan assumes the old setup contains hidden dependencies. Website builders, CDNs, spam filters, SSL validation, and workspace products often leave verification records in the zone.

Watch for these problems:

• Incomplete zone copy: the new DNS host has the website record, but not the mail, verification, or security records.
• Wrong apex setup: the root domain and the www hostname point to different places.
• Email drift: MX records move, but SPF, DKIM, or DMARC TXT records do not.
• Premature cleanup: the old server or email service is removed before cached DNS answers expire.
• Registrar confusion: records are edited at a provider that is not authoritative for the domain.

HostScout method note

HostScout treats DNS as part of the hosting purchase, not as a separate academic topic. Our provider data flags companies that sell domains, CDN, email, cloud, or hosting products, then editorial review checks how those roles affect real migration risk.

That method is deliberately conservative. A provider page can show a domain or CDN product, but the DNS zone that matters is still the one delegated by the domain’s nameservers. We avoid hard pricing or uptime claims here because DNS behavior depends on the active zone and provider configuration.

Practical takeaway

DNS stays simple only while nothing moves. The moment you change registrar, hosting, CDN, or email, DNS becomes the map that decides which provider receives traffic. Treat the zone as production infrastructure, not as a setup screen you click through once.

For buying decisions, inspect the domain and hosting surface together. A cheap domain deal is less useful if DNS controls are weak, email records are hard to audit, or the provider hides nameserver behavior inside a bundled website product.