🔍 DNS QUERY
echobash.com
↓ DNS RESOLUTION
→ 185.199.108.153
Resolved in ~28ms  ·  TTL 3600s  ·  GitHub Pages CDN
🗺️ FULL DNS RESOLUTION FLOW — echobash.com INFOGRAPHIC
1
🌐
YOUR BROWSER
STEP 1
Chrome / Firefox / Safari / Edge  ·  Actor: YOU (the user) + browser process
You typed echobash.com in the address bar and pressed Enter. The browser immediately checks its own internal DNS cache — a small, fast lookup table it keeps in memory from previous visits. Cache entries expire when their TTL runs out.
🗂️ BROWSER CACHE CHECK ✗ CACHE MISS
What browser does: Parses URL → strips path/port → takes just echobash.com → calls the OS's DNS resolver API (getaddrinfo()). The browser hands off the hostname and waits for an IP back.
"Cache is empty for echobash.com. I'm calling the OS: getaddrinfo("echobash.com") — please give me an IP address!"
⬇ API CALL Browser → OS: getaddrinfo("echobash.com") via system DNS API
2
💻
OS DNS CACHE
STEP 2
/etc/resolv.conf  ·  systemd-resolved  ·  Windows DNS Client  ·  Actor: your computer's OS
Your operating system receives the getaddrinfo() call from the browser. The OS first checks the /etc/hosts file (manual overrides), then its own DNS cache (responses it stored from recent lookups). Both miss — so it opens a UDP socket to the configured DNS resolver.
📄 /etc/hosts CHECK ✗ NOT FOUND 🗂️ OS CACHE CHECK ✗ CACHE MISS
Where does the OS look? /etc/resolv.conf on Linux/macOS lists the upstream DNS server IP — often set by your Wi-Fi router via DHCP. That IP (e.g. 8.8.8.8) is where the OS sends the UDP query. Flush cache: macOS: sudo dscacheutil -flushcache  /  Linux: systemd-resolve --flush-caches
"Not in /etc/hosts, not in my cache. My configured resolver is 8.8.8.8 (Google DNS). Sending UDP query to port 53: 'What is the A record for echobash.com?'"
⬇ UDP QUERY OS → Recursive Resolver (8.8.8.8:53): "echobash.com IN A?" over UDP port 53
3
🔄
RECURSIVE RESOLVER
RESOLVER — THE WORKHORSE
8.8.8.8 (Google DNS)  ·  1.1.1.1 (Cloudflare)  ·  9.9.9.9 (Quad9)  ·  Actor: your ISP or configured DNS provider
The recursive resolver is the true workhorse of DNS. Your OS sent it a single question: "what is the IP for echobash.com?". The resolver is responsible for finding the answer no matter how many servers it has to ask. It makes ALL the sub-queries below on your behalf and returns only the final answer to you.
💡 Cache hit shortcut: If the resolver already has echobash.com cached from a recent lookup (within the last TTL seconds), it returns the answer immediately — no root/TLD queries needed. Steps 4–6 are skipped entirely. For a cold start (first-ever lookup) it must do all 3 sub-queries below.
RESOLVER'S 3-STEP JOURNEY (all done by 8.8.8.8)
3a Resolver → Root NS (a.root-servers.net / 198.41.0.4): "Who handles .com?"
↳ Root NS replies: "Try a.gtld-servers.net at 192.5.6.30 — they manage .com"
3b Resolver → .com TLD NS (a.gtld-servers.net / 192.5.6.30): "Who handles echobash.com?"
↳ TLD NS replies: "Try ns1.cloudflare.com at 173.245.58.45 — Cloudflare is authoritative"
3c Resolver → Auth NS (ns1.cloudflare.com / 173.245.58.45): "What is the A record for echobash.com?"
↳ Auth NS replies: "185.199.108.153 (and 3 more GitHub Pages IPs). TTL=3600s. Done!"
"Got it! echobash.com = 185.199.108.153 — I'll cache that for 3600s and send it back to your OS right now."
⬇ SUB-QUERY 3a Resolver (8.8.8.8) → Root NS (a.root-servers.net / 198.41.0.4:53): "echobash.com IN A?"
4
🌍
ROOT NAMESERVERS
ROOT NS — TOP OF THE TREE
13 root server groups (a–m.root-servers.net)  ·  1,800+ physical instances globally via anycast  ·  Actor: operated by ICANN & partners
The recursive resolver (8.8.8.8) sends a UDP DNS query to one of the 13 root server groups. Root servers sit at the very top of the DNS tree. They do not store individual domain records — their only job is to know which TLD nameservers are responsible for each top-level domain (.com, .net, .org, .io, etc.).
What the Resolver asks: Query: echobash.com IN A
What Root NS answers: It sends back a referral — not an IP, just a pointer: "I don't know echobash.com, but .com is managed by these servers →"
LetterOperatorIPv4
aVerisign198.41.0.4
bUSC-ISI199.9.14.201
fInternet Systems Consortium192.5.5.241
kRIPE NCC193.0.14.129
mWIDE Project202.12.27.33
"Received: 'echobash.com IN A?'  →  I don't store individual domains. .com is delegated to Verisign's GTLD servers. Referral: a.gtld-servers.net at 192.5.6.30"
⬇ REFERRAL → SUB-QUERY 3b Root NS → Resolver: "Ask a.gtld-servers.net"  |  Resolver → TLD NS (192.5.6.30:53): "echobash.com IN A?"
5
📋
.COM TLD NAMESERVER
TLD NS — DELEGATION REGISTRY
Verisign  ·  a.gtld-servers.net (192.5.6.30)  ·  b.gtld-servers.net  ·  … (13 servers)  ·  Actor: Verisign (runs all .com TLD servers)
The recursive resolver now contacts a.gtld-servers.net at 192.5.6.30 with the same query. The .com TLD server's database is essentially a giant registry of every registered .com domain mapped to its authoritative nameservers. It does NOT store A records — only NS delegation records telling you WHO to ask next.
What Resolver asks: Query: echobash.com IN A → a.gtld-servers.net
What TLD NS answers: A referral with NS records + glue records (IPs of the NS servers, so the resolver doesn't need another lookup to reach them)
;; AUTHORITY SECTION (NS delegation from .com TLD):
echobash.com. 172800 IN NS ns1.cloudflare.com.
echobash.com. 172800 IN NS ns2.cloudflare.com.

;; ADDITIONAL SECTION (glue records — IPs of the NS servers):
ns1.cloudflare.com. 172800 IN A 173.245.58.45
ns2.cloudflare.com. 172800 IN A 173.245.59.45
"Received: 'echobash.com IN A?'  →  Domain registered and delegated to Cloudflare. Ask ns1.cloudflare.com at 173.245.58.45 — they have the actual A records."
⬇ REFERRAL → SUB-QUERY 3c TLD NS → Resolver: "Ask ns1.cloudflare.com"  |  Resolver → Auth NS (173.245.58.45:53): "echobash.com IN A?"
6
🔑
AUTHORITATIVE NAMESERVER
AUTHORITATIVE — FINAL ANSWER
ns1.cloudflare.com (173.245.58.45)  ·  Actor: Cloudflare, configured by the domain owner
The recursive resolver contacts ns1.cloudflare.com at 173.245.58.45 — this is the authoritative nameserver. This means Cloudflare has the actual DNS zone file for echobash.com. The domain owner logged into Cloudflare's dashboard and added A records pointing to GitHub Pages IPs. This is the only server that can give a final, authoritative "yes, here is the IP" answer.
What Resolver asks: Query: echobash.com IN A → ns1.cloudflare.com:53
What Auth NS answers: A real ANSWER section (not a referral!) with the AA flag set (Authoritative Answer). TTL=3600 tells the resolver how long to cache this.
"Received: 'echobash.com IN A?'  →  I AM the authority for this domain! No more referrals. Here are the A records (AA flag = authoritative):"
;; ANSWER SECTION (flags: qr aa rd; NOERROR):
echobash.com. 3600 IN A 185.199.108.153
echobash.com. 3600 IN A 185.199.109.153
echobash.com. 3600 IN A 185.199.110.153
echobash.com. 3600 IN A 185.199.111.153

; Query time: 12 msec (Cloudflare → Recursive Resolver)
; Status: NOERROR  ·  aa (Authoritative Answer) flag SET
⬆ ANSWER Auth NS → Resolver: "echobash.com A 185.199.108.153 TTL=3600" (AA flag set — authoritative answer!)
7
⬆
RESPONSE TRAVELS BACK
CACHED AT EACH HOP
Actor: every layer in the chain caches independently  ·  TTL = 3600 seconds (1 hour)
The authoritative answer from Cloudflare's nameserver travels back to you in reverse order. Every intermediary caches the result for the TTL duration — so the next person who looks up echobash.com gets a fast cached answer instead of going through this full chain again.
THE RETURN PATH — STEP BY STEP
Auth NS Cloudflare (ns1.cloudflare.com) sends the answer packet back to the Recursive Resolver (8.8.8.8). Packet includes: 4× A records, TTL=3600, AA flag set.
⬇
Resolver Google DNS (8.8.8.8) stores echobash.com → 185.199.108.153 in its cache with a 3600s timer. It then forwards the answer back to your OS's original UDP request.
⬇
OS Cache Your OS receives the UDP response, stores the record in its own DNS cache, then returns the IP to the browser via getaddrinfo().
⬇
Browser Chrome/Firefox receives the IP, stores it in its own browser DNS cache, and immediately begins a TCP connection to 185.199.108.153:443.
"Resolver here — I cached your answer for 3600s. Next lookup for echobash.com returns instantly from cache — no root/TLD queries needed for the next hour!"
⬇ DNS DONE → TCP Browser → GitHub Pages (185.199.108.153:443): TCP SYN — DNS is complete, starting connection
8
✅
CONNECTION ESTABLISHED!
SUCCESS
TCP Handshake → TLS 1.3 Negotiation → HTTP/2 Request → Response  ·  Actor: Browser + GitHub Pages server
DNS is complete. Your browser now has the IP address 185.199.108.153 — a GitHub Pages CDN edge node. The browser initiates a TCP 3-way handshake (SYN → SYN-ACK → ACK), negotiates TLS 1.3, then sends the HTTP/2 GET request for the page. The server responds with HTML, CSS, and other assets.
What browser does: TCP SYN → 185.199.108.153:443 → receives SYN-ACK → sends ACK → TLS ClientHello → … → HTTP/2 GET / → 200 OK → page loads!
echobash.com → 185.199.108.153 → 🎉 CONNECTED!
⏱ DNS: ~28ms ⏱ TCP: ~12ms ⏱ TLS: ~18ms ⏱ First Byte: ~85ms ⏱ Total: ~143ms
🔍 LIVE LOOKUP — Try Any Domain INTERACTIVE 
Loading echobash.com A record...
🏔️ THE DNS NAMESPACE HIERARCHY REFERENCE
🌍
. (ROOT Nameservers)
The 13 root server groups. Controls everything above TLDs.
a.root-servers.net  ·  b.root-servers.net  ·  … m.root-servers.net
▼
📂
TLD — TOP-LEVEL DOMAINS
Managed by registries (Verisign for .com/.net, ICANN delegates others)
.com  ·  .net  ·  .org  ·  .io  ·  .dev  ·  .co.uk  ·  .ai
▼
🏷️
SLD — SECOND-LEVEL DOMAINS
Domains you register through a registrar (Namecheap, GoDaddy, Cloudflare)
echobash  ·  github  ·  devdunia  ·  google  ·  amazon
▼
🔧
SUBDOMAINS — YOU CONTROL THESE
Configured in your authoritative nameserver. Unlimited, free to create.
www  ·  api  ·  mail  ·  app  ·  blog  ·  cdn  ·  staging  ·  dev
ANATOMY OF A FULLY QUALIFIED DOMAIN NAME
Subdomain
mail
separator
.
SLD
echobash
TLD
.com
Root
.
FQDN: mail.echobash.com.  (trailing dot = explicit root)
⏱️ TTL — TIME TO LIVE CACHING
📊 TTL DECAY ILLUSTRATION
echobash.com   A   TTL = 3600 seconds
Just cached (3600s remaining)
30 minutes later (1800s remaining)
55 minutes later (300s remaining)
60 minutes — TTL expired, re-query triggered!
Cache Location Duration On Expiry
Authoritative NS Permanent Never expires
Recursive Resolver TTL value (3600s) Re-queries auth NS
OS Cache TTL value Forwards to resolver
Browser Cache TTL (often shorter) New OS lookup
Negative Caching: NXDOMAIN (domain doesn't exist) responses are also cached — typically for 900 seconds. Deleting a typo domain and re-checking immediately may still return NXDOMAIN!
🎯 WHY TTL MATTERS
⚡ LOW TTL (60s)
Use when: Planning a migration, A/B testing, failover scenarios

✓ DNS changes propagate fast
✗ More DNS queries → higher latency
✗ More load on authoritative NS
🐢 HIGH TTL (86400s)
Use when: Stable production domains with no planned changes

✓ Less DNS traffic
✓ Faster for end users (cached)
✗ Changes take up to 24h to propagate
PRO MIGRATION STRATEGY:
24–48h before migration: Lower TTL to 60s
During migration: Update A record to new IP
After migration is stable: Raise TTL back to 3600–86400s
CHECK TTL IN TERMINAL:
$ dig echobash.com A +noall +answer

echobash.com. 3600 IN A 185.199.108.153 $ dig +short echobash.com
185.199.108.153
185.199.109.153
The number between the domain name and record type is the remaining TTL in seconds.
📋 DNS RECORD TYPES QUICK REFERENCE CHEAT SHEET
Type Purpose Example for echobash.com
A IPv4 Address Maps domain name to a 32-bit IPv4 address. The most common record type. echobash.com. 3600 IN A 185.199.108.153
AAAA IPv6 Address Maps domain to a 128-bit IPv6 address. The future-proof version of A records. echobash.com. 3600 IN AAAA 2606:50c0:8000::153
CNAME Canonical Name (Alias) Points one domain name to another. Resolvers follow the chain. Cannot be used at zone apex. www.echobash.com. 3600 IN CNAME echobash.github.io.
MX Mail Exchange Specifies mail servers for the domain. Priority value determines order (lower = higher priority). echobash.com. IN MX 1 aspmx.l.google.com.
echobash.com. IN MX 5 alt1.aspmx.l.google.com.
NS Nameserver Delegates a DNS zone to an authoritative nameserver. These are set at your domain registrar. echobash.com. 86400 IN NS ns1.cloudflare.com.
echobash.com. 86400 IN NS ns2.cloudflare.com.
TXT Arbitrary Text Data Used for SPF (email auth), DKIM keys, domain verification (Google, GitHub), DMARC policies. echobash.com. IN TXT "v=spf1 include:_spf.google.com ~all"
SOA Start of Authority Contains zone metadata: primary NS, admin email, serial number, refresh/retry/expire times. echobash.com. IN SOA ns1.cloudflare.com. dns.cloudflare.com. 2024010101 10800 3600 604800 3600
PTR Reverse DNS Pointer Maps an IP address back to a hostname. Used for spam filtering, network diagnostics. Set by your hosting provider. 153.108.199.185.in-addr.arpa. IN PTR cdn-185-199-108-153.github.com.
CAA Certificate Authority Authorization Restricts which Certificate Authorities (CAs) can issue SSL certs for your domain. Important security control. echobash.com. IN CAA 0 issue "letsencrypt.org"
echobash.com. IN CAA 0 issue "pki.goog"