DNS Deep Dive: How a Name Becomes an IP

Every networked thing you do starts with a name. You don’t type IP addresses into a browser; you type infotechninja.com, and somewhere between hitting Enter and the page loading, a small army of servers turns that name into a number. Most of the time it works in a few milliseconds and you never think about it. The few times it doesn’t, you’re probably staring at a “DNS_PROBE_FINISHED_NXDOMAIN” page wondering what’s broken.

This is lesson 8 of Networking from Scratch. We touched DNS briefly in lesson 1 as “step 1 of loading a webpage.” This article is the deep dive: the hierarchy, the query path, the records you’ll actually edit, encrypted DNS, and the troubleshooting tools that turn DNS from a black box into something you can debug confidently.

The DNS hierarchy in one mental picture

DNS is a tree. Read a domain name backwards to walk the tree from top to bottom:

infotechninja.com
                ^
                | top-level domain (TLD)

infotechninja
^
| second-level domain (the part you registered)

Three layers in that tree matter for resolution:

1. The root. Written as a single dot (.) and almost always invisible. Operated globally by 13 logical clusters of nameservers (named a.root-servers.net through m.root-servers.net) that hold the list of every TLD’s nameservers.
2. TLD servers. One set per top-level domain. The .com servers know which nameservers are authoritative for every domain registered under .com. The .io servers know the same for .io, and so on.
3. Authoritative servers. The actual servers that hold the records for a specific domain. infotechninja.com’s authoritative servers are whatever the registrar has on file (typically the DNS hosting provider).

That hierarchy is why a registrar can sell you a domain in seconds: they don’t actually publish the records themselves; they update the TLD’s entry to point at the nameservers you chose, and the rest of the world finds those nameservers from there.

The recursive resolver and the query path

Your laptop doesn’t walk the DNS tree itself. It uses a stub resolver — a tiny piece of the operating system that just sends a single query to one of the resolvers configured on your machine (via DHCP, manually, or by network policy). Common ones:

• Your home router’s built-in resolver, which usually forwards to your ISP’s.
• Your office network’s internal resolver.
• Public resolvers like Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, or Quad9’s 9.9.9.9.

That resolver is called recursive because it does the legwork on your laptop’s behalf. The full sequence for a cache-cold lookup of infotechninja.com:

laptop  --? infotechninja.com -->  recursive resolver
                                      |
                                      |  --? . (root)            --> "ask the .com servers, here they are"
                                      |  --? .com                --> "ask infotechninja.com's authoritative servers, here they are"
                                      |  --? infotechninja.com   --> "203.0.113.42"
                                      |
laptop  <-- 203.0.113.42 --             recursive resolver

The resolver caches each step’s answer for as long as that answer’s TTL says it can. The next thousand laptops on the network that ask for infotechninja.com get the cached answer instantly, with no walks up the tree.

TTL: the “how long can I cache this” field

Every DNS record carries a Time To Live in seconds — how long downstream resolvers should remember the answer before going back to the authoritative server to ask again.

One important rule: changes to a record only propagate as fast as the previous TTL allowed. If you publish a record with a 24-hour TTL and then change it, every cache that picked up the old version can hold onto it for the full 24 hours before re-checking. Drop the TTL low before a planned change, then raise it back afterwards.

The records you’ll actually edit

DNS supports dozens of record types. Most of them you will never touch. The handful you’ll edit on real domains:

The CNAME-at-the-apex rule

You can’t put a CNAME at the apex of a zone (the bare domain like infotechninja.com). The reason is technical — the apex needs an SOA and NS records, and CNAMEs are not allowed to coexist with other record types at the same name. In practice, this trips up people who want to point their root domain at a load balancer or CDN that gives them a CNAME-only hostname. Solutions:

• Use a static A/AAAA record instead, if your provider supports it.
• Use vendor-specific “ALIAS” or “ANAME” records (a flatten-on-resolve hack offered by some DNS hosts).
• Skip the apex entirely — redirect example.com to www.example.com at the HTTP layer and use a CNAME on www.

DNSSEC, briefly

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, so a recursive resolver can verify that the answer it received actually came from the rightful owner of the zone — not from someone poisoning the cache or a man-in-the-middle. The chain of trust runs from the root’s signing key down through the TLD to your zone, mirroring the resolution path.

DNSSEC adoption is widespread but not universal. Most TLDs sign their zones; many recursive resolvers validate; consumer-end-to-end uptake is mixed. If you’re running a production zone, enable DNSSEC if your DNS host makes it one click; if not, weigh whether the operational complexity is worth it. The biggest practical risk to not using it is cache poisoning, which is rare on well-run resolvers but not impossible.

DoH and DoT — encrypted DNS

Standard DNS queries travel in plaintext. Anyone on the wire between your laptop and your resolver can see every domain you look up — your ISP, the coffee-shop Wi-Fi operator, anyone with the right tap. Two protocols address this:

From a privacy standpoint they accomplish the same thing — the resolver still sees every query (it has to, to answer them) but the network in between can’t. The trade-off: when DoH is enabled in the browser, queries may bypass your network’s configured resolver entirely, which can break split-horizon DNS and lawful interception in enterprise environments. Many enterprises disable browser-level DoH and force queries through the corporate resolver, which can then do its own DoT/DoH upstream.

The tools that actually debug DNS

Three you should know cold.

dig (Linux, macOS, anywhere with bind-tools installed)

dig infotechninja.com
dig infotechninja.com AAAA
dig infotechninja.com MX
dig +short infotechninja.com           # just the answer
dig +trace infotechninja.com           # walk the tree yourself
dig @1.1.1.1 infotechninja.com         # ask a specific resolver
dig -x 203.0.113.42                    # reverse lookup

dig +trace is the killer move — it shows you each step of the recursive resolver’s walk: root, then TLD, then authoritative. If a domain is broken, +trace tells you which step is failing.

nslookup (Windows, also on Linux/macOS)

nslookup infotechninja.com
nslookup -type=mx infotechninja.com
nslookup -type=any infotechninja.com 1.1.1.1

Older tool, more verbose output, more limited than dig. On Windows, it’s the default DNS-debug option and works for the basics.

host (Linux, macOS)

host infotechninja.com
host -t MX infotechninja.com

Compact, fast, ideal for scripts.

Common DNS problems and how to recognise them

The single most useful debugging habit: specify the resolver you’re asking. dig @1.1.1.1 ... bypasses your local resolver and tells you what the public internet sees. If the answer is right when asked from outside but wrong from inside, the issue is local. If it’s wrong everywhere, the authoritative records are wrong.

The hosts file (it still exists)

Before doing any of the network DNS, every operating system checks a local file:

Anything in there overrides DNS. Useful for:

• Pointing a name at a test server before pushing the real DNS change.
• Forcing an internal name to resolve when DNS is broken.
• Diagnosing “is this a DNS problem or a routing problem?” — add the IP manually and see if connectivity works.

It’s also a popular foot-gun. If a domain is misbehaving on one specific machine, check the hosts file. A line someone added a year ago for a test environment is often the culprit.

What you can now answer

• Why is DNS a tree? — Each level (root, TLD, zone) only has to know about the level below it. That keeps any one component small enough to be reliable.
• Why does my DNS change take a day to propagate? — The TTL on the previous record. Drop the TTL before the change next time.
• Why can’t I CNAME my apex? — A CNAME can’t coexist with the SOA and NS records the apex requires. Use ALIAS / ANAME or a static A/AAAA.
• What does dig +trace do? — Walks the DNS tree yourself, one step at a time. Best tool for “which step is failing.”
• What’s the difference between DoH and DoT? — DoT runs over TLS on a dedicated port; DoH runs inside HTTPS. Same outcome, different visibility.

What’s next

You can now read DNS confidently — the hierarchy, the records, the propagation behaviour, the tools that debug it. Next we move to the layer above: the OSI and TCP/IP models, the two reference frameworks that organise everything we’ve built up so far. The article is short and clarifying — once it’s in your head, every other piece of networking maps onto it cleanly.