What Is DNS? The Domain Name System Explained

Quick answer
DNS turns names into IP addresses. It is a distributed, heavily cached directory — which is why changes take time to appear.
You need four record types: A/AAAA (name → IP), CNAME (name → name), TXT (verification and SPF), MX (email).
A registrar sells the name; DNS hosting serves the records. They are frequently different, and separating them is how you put a CDN in front.
Debug with dig, not a browser. A browser adds its own DNS cache and hides the real answer.

What is DNS?

DNS (Domain Name System) is the naming system that maps human-readable hostnames like example.com to the IP addresses computers use to route traffic, like 203.0.113.10. Without it you would have to type a numeric address for every site you visited, and any change of hosting provider would break every link to you.

It is worth being precise about one thing: DNS does not route traffic and does not know anything about your application. It only answers the question “which IP address does this name refer to?” Everything after that — the TLS handshake, the HTTP request, which server responds — happens over a connection that was opened using that address.

That distinction explains most DNS confusion. When people say “DNS is down,” they usually mean name resolution is failing, and every request to that host fails before a single byte reaches their server.

Where this bites vibecoders
The specific way this bites vibecoders is localhost becoming a production hostname. An assistant hardcodes http://localhost:3000 in a frontend config, or a webhook URL, or a CORS allowlist, because that is what worked during development. The app runs perfectly until a second machine is involved — a CI job, a container, a colleague’s laptop — and then the reference points at that machine’s localhost. The value that worked everywhere is the one that was never checked anywhere but your own.

How does a DNS lookup work?

A lookup is a chain of delegations, and each step is a caching opportunity.

1. You ask a resolver. Your browser or operating system does not usually query authoritative servers directly. It asks a recursive resolver — usually run by your ISP, or a public one like Cloudflare or Google — and caches the answer.

2. The resolver asks a root server. Root servers know which server is authoritative for every top-level domain. They do not know your IP address; they answer with “ask the .com server”.

3. The resolver asks the TLD server. The .com server knows which nameserver is authoritative for example.com and returns its address.

4. The resolver asks the authoritative nameserver. This is your DNS host, and it holds your actual records. It answers with the IP address and the TTL.

5. Everyone caches the answer. The resolver caches it for the TTL, and your browser caches it separately. This is why the lookup is fast, and why your change is not instant.

Because steps 2 and 3 are cached too, propagation is not a single event. In practice, after a change, most people see it within a minute and the slowest caches may hold the old value until their TTL expires.

Which DNS records do you actually need?

Four types cover almost every small project.

Record	Points to	Use it for
A	An IPv4 address	Your domain and subdomains pointing at a server
AAAA	An IPv6 address	The same, for IPv6 — usually added alongside A
CNAME	Another hostname	Aliases, and pointing a subdomain at a platform or CDN
TXT	Arbitrary text	Domain verification, SPF/DKIM for email
MX	A mail server	Receiving email at your domain

A versus CNAME is the distinction beginners get wrong most often. An A record is a destination; a CNAME is a signpost to another signpost. A CNAME cannot exist at the apex — you cannot make example.com a CNAME, because it would be circular. So the bare domain gets an A (or AAAA) record, and www is typically a CNAME pointing at it.

You will also meet two records that are not really about where your site lives:

TXT records are used by dozens of services to prove you own the domain — domain verification for hosting, analytics, and search consoles. They change no traffic.
MX records route email. If your provider documents MX records for sending, that is a separate concern from your website, and getting it wrong means mail to your domain bounces.

Why do DNS changes take time to propagate?

Because every party in the chain is allowed to cache your answer for the TTL you specified, and most do exactly that. Until those caches expire, they keep returning the old value — correctly, from their point of view.

The practical consequence is that a change made moments before a launch is a gamble. The reliable procedure is:

Lower the TTL on the record to something short (300 seconds) and wait for that change to propagate — often a day, sometimes longer.
Make the actual change.
Verify with dig against several public resolvers, not just your own machine.
Raise the TTL back once you are confident, so resolvers can cache efficiently again.

Most hosting panels have a propagation checker, but they check a minority of resolvers and can be optimistic. Verifying yourself is faster and more reliable.

How do I check what DNS actually says?

Use dig, which queries a resolver directly and shows the answer and its TTL, bypassing your browser’s cache.

# What does this name resolve to?
dig example.com

# Ask a specific public resolver, bypassing your ISP entirely
dig @1.1.1.1 example.com

# Check the record type specifically
dig example.com A
dig www.example.com CNAME

# Check which nameservers are authoritative for the domain
dig NS example.com

# Trace the delegation from the root
dig +trace example.com

Two habits make this much more effective. Query a public resolver explicitly (@1.1.1.1 or @8.8.8.8), because your ISP resolver may be caching a stale answer and you will waste an hour debugging a change that already worked. And read the ANSWER SECTION and the TTL, not the header — the header is boilerplate.

The other trap is testing from a browser. Browsers cache DNS aggressively and a normal reload does not clear it, so a change that has already propagated everywhere still looks broken to you. dig against a public resolver settles the question in under a second.

Where AI coding assistants get this wrong

Hardcoding localhost or 127.0.0.1 in a frontend config, webhook URL, or CORS allowlist, which works on exactly one machine.
Creating a CNAME at the apex, which is invalid and is rejected or silently ignored by most DNS providers.
Confusing the registrar with DNS hosting, so changing nameservers where the records live is never attempted.
Missing the www vs apex distinction, so one of the two forms of the URL 404s and the fix looks like a server problem.
Forgetting IPv6. Adding only an A record means users on IPv6-only networks cannot reach you — a failure that is invisible to the developer testing on IPv4.
Testing in a browser after a DNS change, inheriting the browser’s cache and concluding the change failed.
No TXT record for domain verification, so a platform onboarding step mysteriously never completes.
Setting MX records by copying an example, which silently breaks email authentication for the whole domain.

Checklist

Separate the registrar (where you renew the name) from DNS hosting (where the records live).
Put an A or AAAA record on the apex; use CNAME for subdomains.
Add both A and AAAA so IPv6-only users can reach you.
Keep a TXT record available for domain verification challenges.
Set www as a CNAME to the apex, and redirect one to the other so both URLs work.
Lower the TTL before a planned change, wait, change, verify, then raise it again.
Verify with dig @1.1.1.1 <name> rather than a browser.
Check dig NS <domain> to confirm which nameservers are actually authoritative.
Set an auto-renew on the domain itself — expiry is not a DNS problem but it is the same admin surface, and it takes a site offline.
Keep DNS records under version control as a documented export, so a registrar lockout is recoverable.

FAQ

What is DNS in simple terms?

DNS (Domain Name System) is the internet’s directory that turns human-readable names like example.com into IP addresses like 203.0.113.10, which is what computers actually connect to. It is a distributed, cached system, which is why a change you make today can take minutes or hours to appear everywhere.

What is the difference between a domain registrar and DNS hosting?

The registrar is where you buy and renew the domain name — it is the shop. DNS hosting is where the records that say where the name points actually live — it is the signpost. They are often the same company by default, and separating them is the usual fix when you want Cloudflare or a CDN in front of a domain bought elsewhere.

What is the difference between an A record and a CNAME?

An A record maps a name directly to an IPv4 address. A CNAME maps one name to another name, and cannot be used at the apex (the bare domain with no subdomain). So example.com can have an A record to an IP, while www can be a CNAME pointing at example.com.

Why does my DNS change take time to appear?

Because resolvers and browsers cache results for the TTL you set on the record. Until that cache expires, they keep returning the old answer. Lowering the TTL before a planned change, and waiting for it to expire first, makes the switch predictable instead of a gamble.

Does DNS affect my SEO or site speed?

Indirectly, and only through consequences. DNS itself is not a ranking factor, but slow propagation means downtime during a migration, and a bad DNS configuration can send traffic to the wrong server. Once the record is correct and cached, DNS has no ongoing effect on how fast your pages load.

Do I need a DNS record for email?

You need MX records for receiving mail at your domain, and usually SPF and DKIM TXT records to prove your outgoing mail is legitimate. These are separate from the A and CNAME records that point at your website, and many providers configure them for you if you use their mail service.