How DNS and domain name resolution work

Why DNS exists

IPv4 addresses like 203.0.113.42 are hard to remember and change when you migrate hosts. DNS gives stable, human-meaningful names mapped to current infrastructure. The mapping is not magical consensus like a blockchain ledger — it is a hierarchy of delegated zones, each operated by whoever controls the parent domain.

When you type a URL, your device does not query one global database. It asks a recursive resolver (often your ISP, router, or a public service like Cloudflare 1.1.1.1 or Google 8.8.8.8) to walk the tree and return an answer. The resolver caches results so the next lookup is fast — which is why caching semantics matter at the network layer too, not only in HTTP headers.

The lookup path: root to zone

Resolving api.example.com typically follows these steps:

1. Stub resolver — Your phone or laptop asks the configured recursive resolver for an A or AAAA record.
2. Root hints — If uncached, the recursive resolver starts at a root nameserver (the trailing dot in DNS notation) and learns which servers handle .com.
3. TLD delegation — The .com servers point to the authoritative nameservers for example.com.
4. Authoritative answer — The zone operator's servers return the record — or a referral if the name is a subdomain delegated elsewhere.
5. Cache and return — The recursive resolver stores the answer for its TTL and hands the IP to your application.

Authoritative servers are the source of truth for a zone. Recursive resolvers do the legwork and absorb load. Misconfiguration at the authoritative layer — wrong A record, stale NS delegation — propagates to every user whose resolver has not yet expired the old cache.

Record types you actually encounter

DNS stores many record types. These appear daily when operating web apps, email, and wallet infrastructure:

• A / AAAA — IPv4 and IPv6 addresses for a hostname. Browsers need one of these before opening a TCP connection.
• CNAME — Alias pointing to another name. CDNs often use CNAMEs so you can change the backend without clients relearning IPs. CNAME chains add latency; flattening at the edge is common.
• NS — Nameserver delegation. Changing NS records moves control of the entire zone to a new provider — a high-impact operation.
• MX — Mail routing. Unrelated to HTTPS but shares the same zone file; typos here do not break your site but do break receipts.
• TXT — Arbitrary text. Used for SPF/DKIM email auth, domain verification tokens, and ACME DNS-01 challenges when automating TLS certificates.
• SRV — Service location with port hints. Less common on the public web but used by some game and VoIP stacks; see NAT traversal and relays for why port discovery matters in real-time apps.

Wallet apps resolve RPC hostnames the same way — a malicious resolver could return a phishing IP long before your wallet checks the TLS certificate. That is why some teams publish expected IPs out-of-band or pin resolvers on critical infrastructure.

TTL: time-to-live and propagation delay

Every DNS answer carries a TTL (seconds). Resolvers must not serve stale data beyond that window. Low TTL (60–300 s) speeds failover when you move servers; high TTL (hours) reduces query load and improves cold-start latency worldwide.

Operators learn TTL the hard way during incidents. You fix the A record at 14:00, but users with cached answers from a 3600 s TTL keep hitting the old IP until 15:00. Planning a migration means lowering TTL days ahead, making the change, verifying, then raising TTL again. The same patience applies when rotating CDN origins behind WebSocket backends — clients holding old IPs see mysterious connection failures.

DNSSEC: signed answers, not encrypted queries

Plain DNS responses can be forged on untrusted networks — a classic café Wi-Fi attack redirects banking sites. DNSSEC adds cryptographic signatures along the chain of trust from root to zone. Validating resolvers reject tampered answers.

DNSSEC does not encrypt queries — observers still see which domains you look up. Protocols like DNS over HTTPS (DoH) and DNS over TLS (DoT) wrap transport confidentiality; DNSSEC handles authenticity. Together they reduce spoofing risk but do not replace checking the TLS certificate hostname after connect — see our TLS explainer for that layer.

Adoption is uneven: many zones are signed, but some resolvers skip validation. As an operator, enabling DNSSEC on your zone protects downstream validators; as a user, picking a validating recursive resolver (1.1.1.1 with DNSSEC, Quad9) closes part of the gap.

Common failures and what users see

• NXDOMAIN — Name does not exist. Typos, expired domains, or deleted subdomains. Browsers show "server not found."
• SERVFAIL — Resolver could not get a valid answer — often authoritative outage, lame delegation, or DNSSEC validation failure.
• Stale cache — You fixed DNS; half the internet still sees the old IP until TTL expires. Flush local cache (ipconfig /flushdns, sudo dscacheutil -flushcache) only helps your machine, not global resolvers.
• Split-horizon DNS — Internal corp DNS returns private IPs; public DNS returns public IPs. Debugging "works on my VPN" often means two different answers for the same name.
• CNAME at apex — DNS spec forbids CNAME on bare example.com alongside other records. Providers use ALIAS/ANAME hacks; misconfig breaks email or apex HTTPS.

For Solana operators, RPC outages sometimes masquerade as DNS issues — always dig +trace api.mainnet-beta.solana.com (or your provider hostname) before blaming validators. Our RPC endpoints guide covers health checks once you know the IP resolves.

DNS hijacking vs phishing vs wallet risk

Attackers target DNS because it sits upstream of everything:

• Registrar compromise — Attacker changes NS records to point the whole domain at malicious infrastructure. TLS may still "work" for the attacker's cert on their server.
• Resolver poisoning — Forged answers on unsecured networks; mitigated by DNSSEC + encrypted DNS transports.
• Typosquatting — Register solana-garden.com (hyphen swap) and hope users mistype. DNS faithfully resolves the wrong name; user education and bookmarks matter.

Crypto users should treat unexpected DNS changes like unexpected on-chain program upgrades: verify through multiple channels before sending funds. DNS integrity is transport plumbing; wallet seed security remains separate — see Solana wallet security.

What operators should monitor

If you run a production hostname in 2026:

• Alert on NS, SOA, and apex A/AAAA changes — unexpected edits are incident-grade.
• Monitor authoritative query errors and SERVFAIL rates from multiple vantage points.
• Keep TTL low before migrations; document rollback records before cutover.
• Enable DNSSEC if your registrar supports it; test with dig +dnssec.
• Separate marketing subdomains from wallet-critical API hosts so a CMS mistake cannot repoint payments.

Related on Solana Garden: TLS and HTTPS certificate chains, HTTP caching explained, Solana RPC endpoints, WebSockets and SSE, Explainers hub.