DEV Community

Cover image for Website to IP Address: How Domain Name Resolution Works
toolbox-poster
toolbox-poster

Posted on • Originally published at toolbox.starnomina.tn

Website to IP Address: How Domain Name Resolution Works

#dns #networking #webdev #devops

TL;DR
Every time you visit a website, your device performs a DNS resolution to translate the human-readable domain name into an IP address. This seemingly simple process involves a multi-layer caching hierarchy, recursive resolvers, root servers, and authoritative nameservers — all completing in milliseconds. This guide traces the full resolution chain, covers modern protocols like DNS-over-HTTPS, and explains how CDNs, anycast, and dual-stack networking influence what IP you actually connect to.

📑 Table of Contents

  • What Is DNS Resolution?
  • The Full Resolution Chain
  • DNS-over-HTTPS & DNS-over-TLS
  • Multiple IPs & Load Balancing
  • CDN Behavior: Cloudflare, AWS & More
  • IPv4 vs. IPv6 Dual-Stack
  • Happy Eyeballs Algorithm
  • Anycast Routing
  • Verification: dig & nslookup Examples
  • Best Practices
  • Common Mistakes
  • Tools
  • References

What Is DNS Resolution?

📖 Definition — DNS resolution is the process of translating a domain name (e.g., example.com) into an IP address (e.g., 93.184.216.34) that network devices can use to route traffic to the correct server.

DNS is often called "the phonebook of the internet." It's a globally distributed, hierarchical database designed for high availability and fast lookups. Without DNS, you'd need to memorize IP addresses for every website you visit.

The Full Resolution Chain

When you type www.example.com into your browser, the resolution passes through multiple layers before a network connection is made:

1. Browser Cache — The browser checks its own DNS cache first. Chrome caches entries for up to 60 seconds. View it at chrome://net-internals/#dns.

2. OS Cache — If not in the browser cache, the OS resolver is queried. On Windows, the DNS Client service caches entries; on Linux, systemd-resolved or nscd handles caching.

3. Router/Local DNS — Your home router or corporate DNS forwarder may have the answer cached from a previous query by any device on the network.

4. Recursive Resolver — Your ISP's or configured public resolver (e.g., 8.8.8.8, 1.1.1.1) accepts the query and performs recursive resolution if the answer isn't cached.

5. Root Nameservers — The resolver queries one of the 13 root server clusters (e.g., a.root-servers.net). The root responds with a referral to the TLD nameservers for .com.

6. TLD Nameservers — The .com TLD servers (operated by Verisign) respond with a referral to example.com's authoritative nameservers.

7. Authoritative Nameserver — The domain's nameserver (e.g., ns1.example.com) returns the final A or AAAA record with the actual IP address.

ℹī¸ In practice, most queries are answered from cache at step 2–4. A full recursive resolution through all 7 steps typically only happens for the first query to an uncached domain and takes 50–200ms.

DNS-over-HTTPS & DNS-over-TLS

Traditional DNS queries are sent in plaintext over UDP port 53, making them visible to anyone monitoring the network. Modern encrypted DNS protocols solve this privacy problem:

Protocol Port Transport RFC Adoption
DNS-over-HTTPS (DoH) 443 HTTPS (HTTP/2) RFC 8484 Firefox, Chrome, Edge, iOS, Android
DNS-over-TLS (DoT) 853 TLS RFC 7858 Android 9+, systemd-resolved, Unbound
DNS-over-QUIC (DoQ) 853 QUIC RFC 9250 AdGuard, NextDNS (emerging)

DoH is the most widely deployed because it uses standard HTTPS on port 443, making it indistinguishable from regular web traffic and difficult to block. Major public resolvers support it:

# DoH query using curl
curl -s "https://dns.google/resolve?name=example.com&type=A" | jq .

# DoH query using dog (modern dig alternative)
dog example.com --https @https://cloudflare-dns.com/dns-query
Enter fullscreen mode Exit fullscreen mode

Multiple IPs & Load Balancing

A domain can have multiple A and AAAA records, each pointing to a different server. This is the simplest form of DNS-based load balancing, known as DNS round-robin.

$ dig example.com A +short
93.184.216.34
93.184.216.35
93.184.216.36
Enter fullscreen mode Exit fullscreen mode

The DNS resolver or client rotates through the list. However, DNS round-robin has limitations:

  • No health checking — DNS continues returning a dead server's IP until the record is manually removed or the TTL expires

  • Uneven distribution — Caching resolvers may pin clients to one IP for the duration of the TTL

  • No geography awareness — All clients get the same set of IPs regardless of location (unless using GeoDNS)

More sophisticated solutions use GeoDNS (returning different IPs based on the client's location) or weighted records (AWS Route 53, Cloudflare Load Balancing) to distribute traffic intelligently.

CDN Behavior: Cloudflare, AWS & More

When a website uses a CDN, the IP you resolve is the CDN's edge server — not the origin server. The CDN selects the nearest edge node using anycast or GeoDNS.

CDN / Provider Resolution Method What You See
Cloudflare Anycast on shared IPs Same IPs globally; routed to nearest PoP via BGP
AWS CloudFront GeoDNS (Route 53) Different IPs per region; ALIAS/CNAME to d123.cloudfront.net
Fastly Anycast Shared anycast IPs across PoPs
Akamai Sophisticated GeoDNS + real-time mapping Highly variable IPs based on location and load

💡 To find the true origin IP behind a CDN, check historical DNS records, certificate transparency logs, or look for subdomains (like direct.example.com) that bypass the CDN.

IPv4 vs. IPv6 Dual-Stack

Modern domains typically publish both A records (IPv4) and AAAA records (IPv6). A dual-stack configuration allows clients to connect using whichever protocol is available and preferred.

$ dig example.com A +short
93.184.216.34

$ dig example.com AAAA +short
2606:2800:220:1:248:1893:25c8:1946
Enter fullscreen mode Exit fullscreen mode

IPv6 adoption is growing steadily — Google reports over 45% of its users connect via IPv6. Having AAAA records ensures your site is reachable as networks increasingly default to IPv6.

Happy Eyeballs Algorithm

📖 Definition — Happy Eyeballs (RFC 8305) is an algorithm used by modern clients to race IPv6 and IPv4 connection attempts, preferring IPv6 but falling back to IPv4 quickly if the v6 connection is slow or fails.

The algorithm works as follows:

  1. The client initiates DNS queries for both A and AAAA records simultaneously

  2. Once the AAAA response arrives, it starts a TCP connection to the IPv6 address immediately

  3. After a short delay (typically 250ms), if the IPv6 connection hasn't completed, it starts a parallel IPv4 connection attempt

  4. Whichever connection completes first wins, and the other is cancelled

This ensures users get the best possible connection time without being penalized by broken IPv6 paths — a problem that plagued early dual-stack deployments.

Anycast Routing

Anycast allows multiple servers worldwide to share the same IP address. BGP routing directs each client to the nearest (in network hops) instance. This is how DNS root servers, major CDNs, and public resolvers achieve global low-latency responses.

  • The 13 root server letters (a-m) are actually 1,700+ instances deployed globally via anycast

  • Cloudflare's 1.1.1.1 resolver uses anycast across 300+ cities

  • Google's 8.8.8.8 uses anycast with clusters on every continent

ℹī¸ Because of anycast, the IP you resolve for a domain might route to a completely different physical server than the same IP queried from another continent. The IP is the same; the destination differs.

Verification: dig & nslookup Examples

Use our Website to IP tool for instant resolution, or run queries from the command line:

# Basic A record lookup
dig example.com A +short

# Full answer with TTL and authority
dig example.com A +noall +answer +authority

# Query a specific resolver
dig example.com @1.1.1.1

# Trace the full resolution chain
dig example.com +trace

# Windows nslookup
nslookup example.com
nslookup -type=AAAA example.com

# Query all record types
dig example.com ANY +noall +answer

# Check TTL remaining
dig example.com A +noall +answer | awk '{print "TTL:", $2, "seconds"}'
Enter fullscreen mode Exit fullscreen mode

The DNS Lookup tool provides a comprehensive multi-record-type query with global resolver comparison.

Best Practices

⚡ Pro Tip: 💡 Set your DNS TTL based on your operational needs: 300 seconds (5 min) for records that may need fast failover, 3600 seconds (1 hour) for stable records. Lower TTLs increase resolver load but give you faster recovery during incidents.

  • Publish both A and AAAA records to support dual-stack clients and future-proof your infrastructure

  • Use low TTLs before migrations (60–300s), then raise them once stable

  • Configure at least two authoritative nameservers on different networks for redundancy

  • Enable DNSSEC to protect against cache poisoning and response tampering

  • Use encrypted DNS (DoH/DoT) on your devices to prevent eavesdropping and manipulation

  • Pre-resolve critical domains with dns-prefetch in your HTML: ``

  • Monitor DNS resolution times and availability with external monitoring from multiple locations

Common Mistakes

Mistake Impact Fix
Setting TTL too high before migration Old IP served for hours/days after cutover Lower TTL to 60s at least 48h before migration
Only publishing A records (no AAAA) IPv6-only clients can't reach you Add AAAA records for all public services
Using a single nameserver Complete DNS outage if it goes down Use 2+ nameservers on different networks
Assuming resolved IP = origin server Misidentifying CDN edge IPs as the origin Understand CDN/anycast before drawing conclusions
Not enabling DNSSEC Vulnerable to cache poisoning attacks Sign your zones and publish DS records at registrar
Ignoring DNS propagation delay Confusion when changes don't take effect instantly Wait for old TTL to expire; verify from multiple resolvers

Tools

🌐 Website to IP — Resolve any domain to its IPv4 and IPv6 addresses instantly with response time and geolocation.

🔍 DNS Lookup — Query A, AAAA, CNAME, MX, NS, TXT, SOA, and any DNS record type from multiple global resolvers.

References

  • 📄 RFC 1035 — Domain Names: Implementation and Specification

  • 📄 RFC 8484 — DNS Queries over HTTPS (DoH)

  • 📄 RFC 7858 — DNS over Transport Layer Security (DoT)

  • 📄 RFC 8305 — Happy Eyeballs Version 2

  • 📄 Root Server Technical Operations — root-servers.org

  • 📄 Cloudflare — What Is DNS? (Learning Center)

đŸŽ¯ Key Takeaway: đŸŽ¯ Key Takeaway — DNS resolution is a multi-layer caching hierarchy that translates domain names into IP addresses in milliseconds. The IP you connect to may be a CDN edge node, an anycast endpoint, or one of many load-balanced servers — not necessarily the origin. Publish both A and AAAA records, enable DNSSEC, use encrypted DNS, and understand TTL behavior to maintain fast, reliable, and secure name resolution.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

Top comments (0)