Guide

DNS explained: how domain names resolve on the web

Humans remember solana.garden; browsers need an IP address. The Domain Name System (DNS) is the distributed directory that translates hostnames into routable numbers — and it runs before every HTTPS handshake, CDN edge selection, and API call. When a site is "down" but the server is fine, DNS is often the culprit. When you point a domain at a CDN or migrate hosting, you are editing DNS records. Understanding resolution, record types, and TTL caching saves hours of confused debugging.

What DNS does in one request

Type a URL and press Enter. Before your browser opens a TCP connection or negotiates TLS, it must answer: "What IP address owns this hostname?" That lookup chain typically looks like this:

Stub resolver — your operating system or browser asks a configured recursive resolver (often your ISP, Google Public DNS at 8.8.8.8, or Cloudflare at 1.1.1.1).
Recursive resolver — walks the DNS tree starting at root nameservers, then the .garden TLD servers, then the authoritative servers for solana.garden, caching each answer along the way.
Authoritative nameserver — the server of record for your zone. It returns the actual record (for example an A record pointing to 203.0.113.10).
Browser connects — with an IP in hand, TCP and TLS proceed. If DNS is slow, your Largest Contentful Paint suffers even when the origin is fast.

DNS is deliberately decentralized. No single company owns the whole tree; registrars, hosting providers, and CDNs each control slices. That flexibility is powerful — and why misconfigured NS glue or stale caches cause intermittent outages.

Record types you actually use

A zone file (or DNS panel) is a set of typed records. These are the ones web developers touch weekly:

Address records — A and AAAA

A maps a hostname to an IPv4 address (93.184.216.34). AAAA does the same for IPv6. Apex domains (example.com) and subdomains (www.example.com, api.example.com) each need their own record unless a CNAME handles the mapping.

Aliases — CNAME

A CNAME says "this name is really that other name." CDNs commonly ask you to CNAME www to something.cdn.net. Important constraint: you cannot put a CNAME at the zone apex on classic DNS — providers use ALIAS/ANAME flattening or static A records instead. Breaking this rule silently breaks email or apex HTTPS.

Mail — MX and TXT

MX records route email to mail servers with a priority number. TXT records hold arbitrary text — SPF (v=spf1 ...), DKIM public keys, domain verification tokens for Google Search Console, and ACME DNS-01 challenge proofs for certificates.

Delegation — NS and SOA

NS records tell the world which nameservers are authoritative for your zone. Changing NS at the registrar is how you move DNS from GoDaddy to Cloudflare. SOA (start of authority) holds zone metadata including the primary NS and default TTL — you rarely edit it manually.

Security and policy — CAA, SRV

CAA (Certification Authority Authorization) restricts which certificate authorities may issue TLS certs for your domain — a useful guardrail against mis-issuance. SRV records locate services by port and protocol (common in federated systems, rare on simple static sites).

TTL, caching, and "propagation"

Every DNS answer carries a TTL (time to live) in seconds. Resolvers cache the response until TTL expires. A TTL of 300 means five minutes of cached answers worldwide even after you change the authoritative record.

People say DNS "propagates" — technically, old caches expire and new lookups fetch fresh data. There is no global instant update. Before a risky migration:

Lower TTL on records you plan to change (for example from 86400 to 300) a day ahead.
Make the change during low traffic.
Verify from multiple resolvers, not just your laptop's cache.
Raise TTL again once stable to reduce query load and improve resilience.

Browser DNS caching, OS caches, and VPN DNS overrides add another layer. "It works on my phone but not yours" often means different resolvers see different TTL-aged answers.

DNS and performance

DNS lookup time is part of connection setup — it affects Core Web Vitals indirectly by delaying the first byte. Typical optimizations:

Reuse connections — HTTP/2 and HTTP/3 multiplexing amortize DNS+TLS cost across many assets on the same host.
Minimize distinct hostnames — each new origin may trigger another lookup. Consolidate static assets on one CDN hostname when possible.
Preconnect and dns-prefetch — <link rel="preconnect" href="https://cdn.example.com"> warms DNS+TLS for third-party origins you know you will hit.
AnyCast DNS — large providers answer from geographically nearby resolver clusters, shaving tens of milliseconds.

Pairing fast DNS with a CDN means visitors resolve a nearby edge IP quickly, then cache static responses per HTTP cache headers at that edge. DNS gets them to the right door; caching decides how often they knock again.

DNSSEC and trust

Plain DNS responses are unsigned — a compromised network path could theoretically return forged answers (DNS spoofing). DNSSEC adds cryptographic signatures so validating resolvers can detect tampering. Adoption is uneven: many zones support it, but not every resolver validates. Enable DNSSEC at your registrar if your DNS host supports it; it is defense in depth, not a substitute for HTTPS.

For website operators, the practical security wins are usually simpler: lock registrar accounts with MFA, use CAA records, monitor for unexpected NS or MX changes, and never share zone-edit access casually.

Common failure modes

Symptom	Likely cause	Fix direction
NXDOMAIN — domain not found	Typo, expired registration, or missing zone at nameserver	Check registrar status; confirm NS delegation matches active zone
Site loads for some users only	Stale TTL caches or split authoritative answers	Query multiple public resolvers; verify single consistent A/AAAA set
HTTPS cert error after DNS change	Cert still issued for old hostname or CAA blocks CA	Re-issue cert; review CAA; wait for CDN cert provisioning
Email stops after web migration	MX records overwritten or apex CNAME conflict	Restore MX/TXT; never replace entire zone without export
Wildcard surprises	`*.example.com` catches unintended subdomains	Remove wildcard or point explicitly; audit subdomain takeover risk

Debugging with dig and online tools

The dig command is the standard inspector. Examples worth memorizing:

dig solana.garden A +short — IPv4 answer from your default resolver.
dig solana.garden A @1.1.1.1 — same query via Cloudflare's resolver.
dig solana.garden NS +trace — full delegation chain from root.
dig solana.garden CAA — which CAs may issue certificates.

Online checkers (DNSviz, intoDNS, WhatsMyDNS) visualize global resolver answers — useful when you suspect geographic split-brain. Always compare authoritative answers directly: dig @ns1.yourprovider.com solana.garden ANY bypasses recursive cache.

For HTTPS specifically, remember DNS only supplies the IP. Certificate validation, redirect rules, and origin health are separate layers — do not stop troubleshooting after the A record looks correct.

DNS in modern hosting patterns

Static sites on object storage often use a CNAME to a bucket endpoint plus a CDN in front. Serverless APIs map api.example.com to a gateway URL. Multi-region apps may use latency-based or geolocation routing policies (Route 53, Cloudflare Load Balancing) to return different A records per visitor region.

Split-horizon DNS serves different answers inside a corporate network versus the public internet — rare for public publishers but common in enterprises. Private DNS (internal zones) never touches public resolvers; confusing the two causes "works in office VPN, fails at home" tickets.

Key takeaways

DNS maps hostnames to IPs through a hierarchy of recursive and authoritative resolvers.
A/AAAA point to servers; CNAME aliases; MX/TXT handle mail and verification; NS delegates the zone.
TTL controls cache lifetime — plan migrations by lowering TTL first.
Slow or wrong DNS hurts page load before your app code runs; pair good DNS with CDN and HTTP caching.
Debug with dig against multiple resolvers; authoritative answers beat guessing from one browser.