Tech & AI, Explained

domains-and-dns

12 min read

Domains and DNS

Status: đźź© COMPLETE Last updated: 2026-06-19 Plain-English tagline: A domain is the human-readable name people type into a browser; DNS is the global phonebook that turns that name into the numeric address of an actual computer.

In plain English

Every computer on the internet is reachable at a numeric address called an IP address — something like 76.76.21.21 (IPv4) or 2606:4700:3032::ac43:bb01 (IPv6). Those numbers are perfectly fine for computers but useless for humans. Nobody memorizes 76.76.21.21; everyone memorizes vercel.com.

A domain name is the human-friendly name. stmarkbible.com, google.com, claude.ai are all domain names. They get registered by paying a yearly fee to a domain registrar (Namecheap, Vercel Domains, Cloudflare Registrar, Google Domains, etc.).

But registering the name doesn’t connect anything. The next step is DNS — the Domain Name System — the worldwide directory that maps domain names to IP addresses (and to other useful metadata).

When you type stmarkbible.com into a browser:

  1. Your computer asks “what’s the IP for stmarkbible.com?”
  2. A chain of DNS servers eventually answers “it’s 76.76.21.21”
  3. Your browser connects to that IP and asks for the page

DNS is the most important piece of internet plumbing that almost nobody thinks about — until it breaks. Then it’s the only thing anyone thinks about.

Why it matters

You can’t ship a real product on my-cool-app-git-feature-x.vercel.app. People won’t trust it, won’t share it, won’t remember it. A custom domain is what makes the project feel real.

Beyond branding, DNS is also how you:

  • Send and receive email at your domain (hello@stmarkbible.com)
  • Move hosting providers without changing the URL (the domain stays; the IP it points at changes)
  • Run multiple services under one brand (blog.stmarkbible.com, api.stmarkbible.com)
  • Verify ownership of a domain to services like Google, Apple, mail providers
  • Implement security policies (SPF, DKIM, DMARC for email; CAA for TLS)

If you understand DNS, you can debug 80% of the “why is my site broken?” emergencies that have nothing to do with your code. If you don’t, those emergencies feel like black magic.

Anatomy of a domain name

Take www.stmarkbible.com:

www  .  stmarkbible  .  com
 ↑          ↑            ↑
 |          |            └─ TLD (top-level domain)
 |          └─ second-level domain (the brand)
 └─ subdomain
  • TLD — top-level domain. The very last part. .com, .org, .io, .ai, .au. Managed by ICANN-accredited registries.
  • Second-level domain — the part you actually register and pay for. stmarkbible in this example.
  • Subdomain — anything to the left of the second-level domain. www, blog, api, mail, app. You create these for free once you own the parent. There’s no technical limit on how many you can have.
  • Apex / root domain — the domain without any subdomain. stmarkbible.com itself. Sometimes called “the apex,” “the naked domain,” or “the zone apex.” It behaves slightly differently from subdomains (see CNAME limitations below).
  • Fully qualified domain name (FQDN) — www.stmarkbible.com. with a trailing dot. That trailing dot represents “the root of all DNS” and is implicit in everyday use.

How a DNS lookup actually works

The first time your computer needs to resolve a domain, it walks through a hierarchy:

1. Browser checks its own cache    →   miss
2. Operating system cache           →   miss
3. Your home router cache           →   miss
4. Your ISP's resolver (recursive DNS server) — usually 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) if you've configured it
                                    →   miss
5. The resolver asks a root nameserver: "who handles .com?"
6. The .com TLD nameserver answers: "the nameservers for stmarkbible.com are at Vercel"
7. Vercel's nameservers answer: "stmarkbible.com → 76.76.21.21"
8. The answer travels back up the chain, getting cached at each step
9. Your browser connects to 76.76.21.21

This whole walk happens in tens of milliseconds. Once any layer has the answer cached, subsequent lookups skip the walk and return instantly — until the cache TTL (time to live) expires.

Most of the time you don’t see this. You only see it when:

  • A cache is stale (you changed a record, but somewhere along the chain still has the old answer)
  • Your nameservers are configured wrong (a typo in a record, missing record, wrong TTL)
  • The TLD’s registry is having a bad day (rare but it has happened to .com, .org, country-code TLDs)

The records you actually use

A domain’s DNS records are stored in a zone file at your domain’s authoritative nameservers. The most important record types:

RecordWhat it doesExample
AMaps a name → IPv4 addressstmarkbible.com A 76.76.21.21
AAAAMaps a name → IPv6 addressstmarkbible.com AAAA 2606:4700:3032::ac43:bb01
CNAME”This name is an alias for that name.” Resolves to the target, then follows ITS recordswww.stmarkbible.com CNAME cname.vercel-dns.com
MXMail exchanger — where email for this domain should gostmarkbible.com MX 10 mail.example.com
TXTFree-form text. Used heavily for verification & email auth (SPF, DKIM, DMARC)stmarkbible.com TXT "v=spf1 include:_spf.google.com ~all"
NSNameserver — which servers are authoritative for this zonestmarkbible.com NS ns1.vercel-dns.com
CAAWhich certificate authorities can issue SSL certs for this domainstmarkbible.com CAA 0 issue "letsencrypt.org"
SRVService location (port + host for a specific service)rare in webapp work
PTRReverse DNS — IP → namemanaged by your hosting provider

The two you’ll touch most: A records (for the apex domain) and CNAME records (for www and other subdomains).

A concrete example: connecting stmarkbible.com to Vercel

When George registered stmarkbible.com through Vercel Domains, this happened:

  1. Registrar action. Vercel paid the registry fee for stmarkbible.com and set the domain’s nameservers to Vercel’s own (ns1.vercel-dns.com, ns2.vercel-dns.com). The nameservers are where the authoritative records live.

  2. Zone records were auto-created in Vercel’s DNS:

    • stmarkbible.com A 76.76.21.21 — apex points to Vercel’s edge
    • www.stmarkbible.com CNAME cname.vercel-dns.com — www aliases to Vercel
    • Plus various verification records

  3. Vercel issued an SSL certificate via Let’s Encrypt (see HTTPS).

  4. The site went live at both stmarkbible.com and www.stmarkbible.com. Vercel is configured to redirect the apex to www.

If George had bought the domain at Namecheap instead, the flow would be:

  • Set Namecheap’s nameservers to point at Vercel (delegate the zone)
  • Or keep Namecheap’s nameservers and manually add the A and CNAME records there
  • Wait for DNS propagation
  • Verify in Vercel

The “easy mode” is letting the host manage DNS for you. The “more control” mode is keeping DNS at a third party (Cloudflare is popular) and using A/CNAME records to point at the host.

Apex vs www — a subtle but important distinction

Historically, websites used www.example.com because of how DNS evolved. Modern sites usually use the apex (example.com) and redirect www to it — or vice versa. Both work; you just need to pick one as the canonical version.

The technical wrinkle: DNS rules say a CNAME record cannot exist at the apex of a domain. (More accurately: a CNAME can’t coexist with other required records like SOA and NS, which must exist at the apex.) That means:

  • For www.example.com → easy: just create a CNAME pointing at your host.
  • For example.com (apex) → you can’t use CNAME. You need an A record pointing at a specific IP.

Hosts solve this differently:

  • Vercel: Provides specific IPs for A records at the apex (e.g. 76.76.21.21).
  • Cloudflare / some others: Implement “CNAME flattening” or “ALIAS” / “ANAME” records that act like CNAMEs at the apex by resolving the target IP at query time.
  • GitHub Pages, Netlify: Also provide apex IPs.

Bottom line: when a host says “add a CNAME for www and an A record for the apex,” that’s why.

TTL — Time To Live

Every DNS record has a TTL: how long resolvers should cache the answer before asking again. A TTL of 3600 means “cache for 1 hour.” A TTL of 300 means “cache for 5 minutes.”

Why this matters:

  • High TTLs (24+ hours) = fast, less load on nameservers, but slow to change. If you update a record, the old value might be cached around the world for a day.
  • Low TTLs (60–300 seconds) = fast to change, but more DNS queries.

Standard practice: Before doing a migration (changing IPs, switching hosts), drop the TTL on the affected records to 300s a day or two ahead. Make the change. Once everything’s stable, raise the TTL back to something normal (3600+).

Caches don’t always honor TTLs perfectly. Some ISPs lie about TTLs and cache longer. Some browsers cache even harder. Expect 48 hours for full propagation in worst-case scenarios.

Email DNS — the four records every domain needs

If you want to send email from george@stmarkbible.com without it landing in spam folders, you need:

RecordPurpose
MX”Mail for this domain should be delivered to these servers.”
SPF (TXT)“These are the IP addresses authorized to send email AS this domain.”
DKIM (TXT)A public key that lets recipients verify outgoing emails were signed by an authorized server.
DMARC (TXT)“Reject (or report) emails claiming to be from us that fail SPF/DKIM.”

Even if you don’t send email from your domain, set a strict DMARC record (v=DMARC1; p=reject) so attackers can’t spoof your domain in phishing attacks. This is free, takes 30 seconds, and prevents real damage.

DNS as configuration — not just for websites

DNS gets used for far more than “which IP serves this site.” Services use DNS records for:

  • Verifying ownership. Google, Apple, mail providers, SSL issuers ask you to add a TXT record to prove you control the domain.
  • Service discovery. SRV records tell apps where to find a specific service.
  • Email authentication. SPF, DKIM, DMARC are all DNS records.
  • Geographic routing. Some DNS providers return different IPs based on where the user is.
  • Load balancing. A single DNS name can return multiple IPs; clients pick one (round-robin DNS).

The same .com domain that serves your website also encodes a dozen other policies. The DNS panel is a quiet but powerful configuration surface.

Common gotchas

  • Propagation isn’t instant. Even with low TTLs, DNS changes can take 10 minutes to 48 hours to be visible everywhere. The most common newcomer mistake is “I changed the record, refreshed, it didn’t update, so I changed it again, now I’ve broken it twice.” Wait. Use dnschecker.org to see propagation worldwide.

  • A CNAME cannot exist at the apex. If your host insists on a CNAME and your domain registrar refuses to create one at the root, that’s why. Use A records (with your host’s IPs) or a registrar that supports CNAME flattening (Cloudflare).

  • Setting nameservers vs setting records are two different things. If you set your domain’s nameservers to point at a new provider, ALL your old records become invisible. You’re starting fresh at the new provider.

  • Mixing nameservers between providers is a disaster. Pick ONE place to manage DNS — your registrar OR your host OR Cloudflare. Splitting causes “but I added that record!” confusion forever.

  • www and the apex are different names. Setting example.com doesn’t set www.example.com. You have to handle both, and typically redirect one to the other for canonical URL hygiene.

  • TTL is “cache duration,” not “how long the record is valid.” A record is valid until you change it. The TTL just says how aggressively to cache.

  • Email DNS records (SPF/DKIM/DMARC) are subtle and easy to misconfigure. Use a checker like mxtoolbox.com to verify them. A bad SPF record can silently make all your email land in spam.

  • DNSSEC is great in theory and a foot-gun in practice. If you enable DNSSEC and then transfer the domain to a registrar that doesn’t support it, your site goes dark. Most solo projects skip DNSSEC.

  • WHOIS privacy. When you register a domain, your name, address, email, and phone get published in the WHOIS directory unless you enable privacy. Most modern registrars enable privacy by default; older ones don’t. Check.

  • Expired domains are gone fast. Registrars usually give a 30–45 day grace period after expiry, then auctions kick in. A valuable domain that expires can be lost to a squatter within hours. Auto-renew + an active credit card on file is non-negotiable.

  • Wildcard records (*.example.com) match anything not explicitly configured. Useful for multi-tenant apps where every customer gets a subdomain. Confusing if you forget you set one — every undefined subdomain “works.”

  • The trailing dot. In some DNS interfaces, example.com. (with the dot) means “absolute”; example.com (no dot) means “relative to the current zone.” Misunderstanding this can produce records like example.com.example.com. Most modern DNS UIs hide this complexity, but raw zone files don’t.

  • Cloudflare’s “proxied” mode hides your IP but also wraps the request. When a Cloudflare DNS record shows the orange cloud (proxied), the IP returned is Cloudflare’s, not your origin. Your origin’s real IP is hidden, but Cloudflare is now in the request path — useful for DDoS protection, sometimes incompatible with services that don’t expect it.

  • DNS caching at the OS level. On Windows, ipconfig /flushdns. On macOS, sudo dscacheutil -flushcache. On Linux, varies. When debugging local DNS oddities, flush the cache before assuming the problem is upstream.

  • The same name, looked up in two places, can return different IPs. GeoDNS (geographic routing) intentionally does this. Don’t be alarmed when the IP you see locally is different from what a friend sees overseas.

A debugging cheat sheet

When DNS isn’t working as expected:

# Resolve a name normally
nslookup stmarkbible.com
 
# Resolve via a specific resolver (bypass your ISP)
nslookup stmarkbible.com 1.1.1.1
 
# Detailed lookup with all records
dig stmarkbible.com ANY
 
# Trace the lookup all the way from root nameservers
dig +trace stmarkbible.com
 
# Check propagation worldwide
# (Web tool: https://dnschecker.org)

These four commands solve 90% of DNS debugging. The fifth thing to check: did you actually save the change? It’s astonishingly common to edit a record, get distracted, and forget to click Save.

See also

Sources

Graph View

Backlinks