Module 01 — Names, Resolvers & Your First Query

Updated 20 August 2026

Module 01 · Names, Resolvers & Your First Query

This module assumes zero DNS knowledge. It takes you from "what is a name" to reading a dig response line by line and telling four different kinds of failure apart — which is most of what DNS troubleshooting actually is.

🧠 concept → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (answers hidden)

Prerequisite: none. A Linux shell and an internet connection.

Part A · What a name actually is

A1 · The problem DNS solves

The analogy. Think of the contacts app on your phone. You never memorise phone numbers — you save a name and tap it. Now imagine nobody had a shared contacts app, and instead everyone kept a paper address book they copied by hand. The moment one person changes their number, every book in the country is wrong, and nobody knows it.

That paper book is /etc/hosts. DNS is the shared, always-current contacts app that replaced it.

Official docs: RFC 1034 — Domain Names: Concepts and Facilities · RFC 9499 — DNS Terminology (BCP 219) · hosts(5)

A network moves packets between IP addresses. Nothing in the network layer understands the word example.com — a router has never heard of it. So something has to turn the name a human types into the address a packet needs. That something is DNS.

The first solution was not DNS. It was one text file, HOSTS.TXT, maintained by hand at the Stanford Research Institute, which every machine on the ARPANET downloaded periodically. Your /etc/hosts file is the direct descendant of it, and it still works exactly the same way.

That design died of three separate diseases, and each one explains a feature of DNS:

Problem with one fileWhat went wrongWhat DNS does instead
LoadEvery host on the network fetching the same file from one machineDistributed — the data lives on thousands of independent servers
Name collisionsOne flat list, so two organisations could not both have a machine called mailHierarchical — mail.a.com and mail.b.com are different names
StalenessYour copy was wrong from the moment someone else changed theirsDelegated + cached with a TTL — the owner changes it, caches expire on a timer
The one-line definition worth memorising: DNS is a distributed, hierarchical, delegated, cached database, whose most common use is mapping names to IP addresses. Every word in that sentence is a separate interview answer, and the rest of this module unpacks them in order.
DNS is a database, not a routing protocol. It hands you data and then gets out of the way. It does not connect you to anything, it does not check that the address it gave you is alive, and it has no idea whether the server behind that address is healthy. "DNS is broken" is a diagnosis people reach for far too early — very often DNS answered correctly and quickly, and the thing at the other end was down.
🧪 Exercise A1.1 — Look at the file DNS replaced
bash
cat /etc/hosts
✅ Expected result — click to reveal
plain text
127.0.0.1	localhost
127.0.1.1	dev-box

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

What to read out of it. Each line is address then name then optional aliases. That is the entire data model of the pre-DNS internet, and it is still consulted on every lookup your machine makes.

Notice what is missing, because the missing things are precisely what DNS adds:

  • No expiry. Nothing tells the machine when this information goes stale. It is right until a human edits it.
  • No authority. Nothing records who is entitled to say what dev-box means. Whoever can write the file wins.
  • No sharing. This file is true on this machine only. The machine next to it can disagree, and neither will ever know.

Now imagine this at 500 hosts. One IP change means pushing a file to 500 machines. Any host that misses the push is silently, confidently wrong — and "silently wrong" is far more expensive to debug than "loudly broken". That single sentence is the reason DNS exists.

🎯 Interview questions — What DNS is

Q. What is DNS and what problem does it solve?

DNS is a distributed, hierarchical, delegated and cached database. Its best-known job is translating human-readable names into IP addresses, but it is a general-purpose lookup system — the same machinery carries mail routing, service discovery, certificate issuance policy and text-based ownership proofs.

The problem it solves is not just "names are nicer than numbers". It is decentralised administration at scale: it lets the owner of a name change what that name points to, without coordinating with anyone else, and without any central authority holding the data.

The detail that separates a strong candidate: pointing out that DNS is a database, not a connection. It returns data and stops. It performs no health checking of the address it returns, so a correct DNS answer and a dead service are entirely compatible states. Candidates who understand this stop blaming DNS first.

Q. Why was a single hosts file not good enough?

Three independent failures, and it is worth naming all three because each maps to a DNS feature.

Load — one server distributing one file to every host on the network does not scale, which is why DNS data is spread over many independent servers.

Collisions — a flat namespace means one global mail. Hierarchy fixes this: mail.a.com and mail.b.com coexist because the name includes the administrative path to its owner.

Consistency — with copies everywhere and no expiry, every copy is wrong between edits. DNS replaces "copy the file" with "ask the owner, then cache the answer for a stated TTL", which bounds how wrong you can be.

Worth adding: /etc/hosts did not disappear. It is still consulted first on most Linux systems, which is why it is a standard debugging and incident tool — and a standard cause of "it works on my machine".

A2 · The namespace is an inverted tree

The analogy. Think of a postal address, written backwards. On an envelope you write name, then street, then city, then country — smallest thing first, biggest last.

A domain name is exactly that: www.example.com means "the machine called www, inside example, inside com". And just like the post office, each level only has to know about the level below it — the country's sorting office doesn't need to know your house number.

Official docs: RFC 1034 §3 — The Domain Name Space · IANA Root Zone Database — every TLD and its operator · IANA Root Servers

The namespace is a tree, drawn upside down: the root at the top, branching downwards. Every node in the tree has a short text label. A domain name is simply the list of labels on the path from a node back up to the root, written left to right, separated by dots.

Diagram source
flowchart TD
    ROOT["root<br>label is empty<br>written as a bare dot"]
    ROOT --> COM["com"]
    ROOT --> ORG["org"]
    ROOT --> UK["uk"]
    COM --> EX["example<br>= example.com"]
    COM --> OTHER["acme"]
    UK --> CO["co"]
    CO --> BBC["bbc<br>= bbc.co.uk"]
    EX --> WWW["www<br>= www.example.com"]
    EX --> ENG["eng"]
    ENG --> API["api<br>= api.eng.example.com"]
    style ROOT fill:#8b5cf6,color:#fff
    style EX fill:#22c55e,color:#fff
    style API fill:#22c55e,color:#fff

Read the diagram from the bottom up, not the top down. api.eng.example.com is api inside eng inside example inside com inside the root. The name is a path, and it is written in the opposite order to a filesystem path — which is the first thing that trips people up.

TermWhat it means, precisely
LabelOne node's name. www, example, com. The root's label is the empty string
Domain nameThe full path of labels from a node to the root, dot-separated
RootThe top of the tree. Written as a single dot . and served by 13 named root server identities
TLDTop-level domain — a label directly under the root. com, org, uk, dev
SubdomainA relative term, not an absolute one. eng.example.com is a subdomain of example.com, which is itself a subdomain of com
Why hierarchy is the whole trick. Because example sits under com, the operator of com can say "anything ending in example.com — ask these servers, not me". That single sentence is delegation, and it is what makes the system scale: nobody has to hold the whole database, and nobody has to be asked permission to change their own slice of it.
"There are only 13 root servers" is a trap. There are 13 root server identities — a.root-servers.net through m.root-servers.net — because 13 addresses was what fitted in an early response size limit. Behind those 13 names sit well over a thousand physical servers in hundreds of locations, all answering on the same addresses. The mechanism that makes that possible has a name and appears in Module 09.
🧪 Exercise A2.1 — Walk three names of different depths, one of which does not exist
bash
ping -c 1 example.com
ping -c 1 www.example.com
ping -c 1 definitely-not-real.example.com
✅ Expected result — click to reveal
plain text
PING example.com (23.215.0.136) 56(84) bytes of data.
64 bytes from 23.215.0.136: icmp_seq=1 ttl=54 time=11.9 ms

--- example.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

PING www.example.com (23.215.0.138) 56(84) bytes of data.
64 bytes from 23.215.0.138: icmp_seq=1 ttl=54 time=12.1 ms

--- www.example.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

ping: definitely-not-real.example.com: Name or service not known

Your addresses will differ from these — example.com is served from many locations and the addresses change. That is normal and is itself the point: the name is stable, the address behind it is not.

Three things to read out of this.

1. example.com and www.example.com are different names, and here they resolve to different addresses. They are two separate nodes in the tree. There is no rule anywhere in DNS that makes www.x behave like x — that is a convention people set up by hand, and forgetting to set it up is a common outage.

2. The third failure is a different kind of failure. Look at the wording: Name or service not known. Not Destination Host Unreachable, not Request timed out. ping never sent a packet, because it never got an address to send it to. Resolution failed before the network was involved at all.

3. That distinction is the single most useful reflex in this whole subject. "Name or service not known" means take the network off the suspect list and look at DNS. "Destination Host Unreachable" means DNS did its job and something downstream is wrong. Engineers who cannot tell these apart spend hours on the wrong half of the stack.

What ping will not tell you is why resolution failed — whether the name genuinely does not exist, whether your resolver was unreachable, or whether the name was malformed. Those look identical here. Getting that detail is exactly what dig is for, and that is Part C.

🎯 Interview questions — The namespace

Q. Describe the structure of the DNS namespace.

An inverted tree with an unnamed root at the top. Each node carries a label; a domain name is the path of labels from a node up to the root, written left to right and separated by dots — so it reads most-specific-first, the opposite of a filesystem path.

Directly under the root are the top-level domains, then registrable domains beneath those, then whatever structure the owner chooses.

The point worth making explicitly: the hierarchy is not cosmetic, it is the administrative boundary. Because the tree is nested, authority can be handed downwards one branch at a time, which is what lets the database be maintained by millions of unrelated parties with no central coordination.

Q. How many root servers are there?

Thirteen root server identities, a through m under root-servers.net, operated by twelve independent organisations. Thirteen because that many addresses fitted inside the original 512-byte UDP response limit.

But thirteen identities is not thirteen machines. Each identity is served by many physical instances in many countries, all announcing the same address, so the practical count is over a thousand servers.

The trap in this question is answering "13" and stopping. The interviewer is usually checking whether you know the difference between a name, an address, and a server — three things this question deliberately blurs.

A3 · Absolute names, relative names, and the trailing dot

The analogy. Think of giving someone directions. If you say "the bakery on Jalan Ampang", that works fine if you are both standing in Kuala Lumpur. Say it to someone in another country and they have no idea where you mean — unless you add "… in Kuala Lumpur, Malaysia".

A name without a trailing dot is the short version, and something may quietly fill in the rest for you. The trailing dot is the "… Malaysia" — it says "this is the complete address, do not add anything".

Official docs: RFC 1034 §3.1 — Name space specifications · RFC 9499 — definitions of FQDN and relative name

Because the root's label is empty, the truly complete form of a name ends in a dot:

plain text
www.example.com.
│   │       │  └── the root, whose label is empty
│   │       └───── com
│   └───────────── example
└───────────────── www

A name written with that final dot is absolute — it is anchored at the root and means exactly one thing everywhere in the world. The formal term is FQDN, fully qualified domain name.

A name written without the final dot is relative, and something is entitled to add labels to it before looking it up.

This is genuinely counter-intuitive, so state it plainly: www.example.com and www.example.com. are not guaranteed to be the same query. The version without the dot may be expanded into www.example.com.corp.internal. before it is ever sent. On a laptop at home the two behave identically and you will never notice. Inside a corporate network or a Kubernetes pod they behave differently, and the difference is a well-known source of five-second delays and bewildering resolution failures.

The rules that govern that expansion — the search list and ndots — are the subject of Module 06. What matters now is only this: the trailing dot means "do not touch this name, send it as written".

🧪 Exercise A3.1 — Prove the trailing dot is legal, then break the name deliberately
bash
ping -c 1 example.com.
ping -c 1 example.com..
✅ Expected result — click to reveal
plain text
PING example.com (23.215.0.136) 56(84) bytes of data.
64 bytes from 23.215.0.136: icmp_seq=1 ttl=54 time=12.0 ms

--- example.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

ping: example.com..: Name or service not known

The first command works and most people are surprised by that. The trailing dot is not a typo and not decoration — it is the root label, and it is the more correct way to write a name. ping strips or ignores it and resolves normally.

The second fails because it contains an empty label in the middle. example.com.. asks for a label between the two final dots, and that label is the empty string — which is reserved for the root and cannot appear anywhere else. This one is not a network failure; the name itself is invalid.

Where you will actually meet the trailing dot. In zone files, where a name without a trailing dot silently gets the zone name appended — so writing www.example.com inside the example.com zone produces www.example.com.example.com.. That is one of the most common zone-file mistakes there is, it produces a valid file that loads without complaint, and Module 02 makes you commit it on purpose so you recognise it.

🎯 Interview questions — FQDNs

Q. What is an FQDN, and what does the trailing dot mean?

A fully qualified domain name specifies the complete path to the root, so it is unambiguous globally. The trailing dot is the root — the root's label is the empty string, so example.com. has labels example, com, and empty.

A name without the trailing dot is relative and may have a search domain appended before it is queried.

Where this earns you credit: naming the two places it bites. In zone files, an unqualified name silently gets the origin appended, producing www.example.com.example.com. from a file that loads cleanly. In resolver configuration, the trailing dot is how you force a single absolute query and skip search-list expansion — which is the standard trick for proving that a slow or failing lookup is a search-domain problem rather than a server problem.

A4 · What is legal in a name

The analogy. Think of filling in an official form. The "phone number" box will not accept letters. The "name" box has a maximum number of characters. The rules feel arbitrary until you realise the boxes are a fixed size on the paper.

Same here — and the twist worth remembering: "valid DNS name" and "valid host name" are two different forms with two different rule sets. Something can pass one and fail the other.

Official docs: RFC 1035 §2.3.1 and §2.3.4 — preferred syntax and size limits · RFC 1123 §2.1 — host names may begin with a digit · RFC 4343 — DNS case insensitivity
RuleDetail, and why it exists
A label is at most 63 octetsThe length is encoded on the wire in a byte whose top two bits are reserved, leaving six bits — and six bits counts to 63
A whole name is at most 255 octetsCounting the length byte in front of every label plus the final zero byte. In practice this caps you at roughly 253 printable characters
Host names: letters, digits, hyphenThe "LDH" rule from RFC 1035, relaxed by RFC 1123 to allow a leading digit. A hyphen may not start or end a label
Comparison is case-insensitiveExample.COM and example.com are the same name. Case is preserved on output but never affects matching
The wire is 8-bit cleanDNS itself can carry arbitrary bytes in a label. The LDH restriction is a host name rule, not a DNS rule — which is why _dmarc and _sip._tcp are perfectly valid DNS labels
The distinction nearly everyone misses. "Valid DNS name" and "valid host name" are two different rule sets. DNS will happily store and serve a label starting with an underscore; it is host name syntax that forbids it. This is why service-discovery names like _sip._tcp.example.com exist and are legal — they are deliberately outside host-name syntax so they cannot collide with a real machine name.
🧪 Exercise A4.1 — Prove case does not matter, then build an illegal label
bash
ping -c 1 ExAmPlE.cOm

# a 64-character label - one octet over the limit
ping -c 1 $(printf 'a%.0s' {1..64}).example.com
✅ Expected result — click to reveal
plain text
PING ExAmPlE.cOm (23.215.0.136) 56(84) bytes of data.
64 bytes from 23.215.0.136: icmp_seq=1 ttl=54 time=11.8 ms

--- ExAmPlE.cOm ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

ping: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.example.com: Name or service not known

The mixed-case lookup succeeds and the tool echoes back your capitalisation. Case is preserved for display and ignored for matching — those are two different behaviours and both are in RFC 4343.

Now the important part, and it is about what you cannot see. The 64-character label failed with Name or service not known — the exact same message you got in Exercise A2.1 for a name that simply did not exist. But these are completely different events:

  • In A2.1 a query was sent and the network answered "no such name"
  • Here no query was ever sent — the resolver library rejected the name locally, because 64 does not fit in six bits

ping collapses both into one message, and that is its fatal weakness as a DNS tool. It tells you that resolution failed and never why. Every incident where the answer is "we spent two hours on the wrong thing" starts here.

You will repeat this exact command with dig in Exercise C6.2 and watch it name the real cause in one line.

🎯 Interview questions — Name syntax

Q. What are the length limits on a