DNS Resolution: From URL to IP, Packet by Packet [Under the Hood]

By /
hafeez@unixshadow: ~/dig.trace
hafeez@unixshadow:~$ dig +trace unixshadow.com # from URL to IP, packet by packet

DNS Resolution
From URL to IP, Packet by Packet

you typed a name. before a single TCP SYN can fly, four servers have to agree on the number.

# the chain — who asks whom // right to left, dot by dot
your appSTUB
A? unixshadow.com
/etc/resolv.conf
recursive resolver1.1.1.1

recursive resolverASKING
NS? .com
“who handles .com?”
root servers“.”

recursive resolverASKING
NS? unixshadow.com
“who’s authoritative?”
.com TLD serversTLD

recursive resolverASKING
A? unixshadow.com
final question
authoritative NSAUTH

answer walks back up the chain — 203.0.113.7, cached at every level for TTL seconds.

# on the wire // what dig +trace actually shows
;; A? unixshadow.com. @198.41.0.4 (root)
;; A? unixshadow.com. @192.12.94.30 (.com TLD)
;; unixshadow.com. 300 IN A 203.0.113.7 @authoritative
;; received 61 bytes in 42 ms
# each ;; line is one server consulted — the dots resolve right to left.
# field guide // the records you’ll actually meet
A / AAAA
name → IPv4 / IPv6 address. The answer you’re usually after.
CNAME
alias — “www is really @”. Costs an extra lookup.
MX
where mail goes, with priority numbers. Lower wins.
TXT
freeform text: SPF, DKIM, domain verification.
NS / SOA
who’s authoritative / the zone’s birth certificate (serial, refresh).
TTL
seconds a record may be cached. Lower = faster changes, more queries.
# see it live
# interrogate DNS yourself:
dig unixshadow.com — the full answer section
dig +trace unixshadow.com — watch the whole chain
dig @1.1.1.1 unixshadow.com — ask a specific resolver
dig -x 203.0.113.7 — reverse: IP back to name
# slow first load?
Check the TTLs — a 300s TTL means every resolver on earth re-asks every 5 minutes. Raise TTLs on stable records and the chain short-circuits from cache.
unixshadow.com  ·  VPS & hosting from the shadowshafeez@unixshadow:~$

Scroll to Top