Hands-on Lab

What DNS Is and How It Works (hands-on, with dig)

October 19, 2026 2 min 1

0 / 9

Cheat sheet

Found it useful? Don't miss the next lab

The video has captions and a transcript. Everything it shows is written out, step by step, below. Cheat sheet with every command

0:00 / 0:00

Start with the most basic question: who does this machine ask when it needs to resolve a name? /etc/resolv.conf lists the 'nameserver' it sends every query to —here 1.1.1.1, Cloudflare's public resolver—. The machine doesn't walk the DNS tree itself: it delegates that work to that recursive resolver.

cat /etc/resolv.conf

I did it

The most common query: a name to an IPv4 address (an A record). dig +noall +answer strips everything but the clean answer. The second column is the TTL in seconds: how long this record may be cached before asking again. This is 'resolving a name' in a single line.

dig +noall +answer jacar.es A

I did it

This is where you see HOW DNS works under the hood. +trace doesn't trust the resolver: it starts at the root servers (.) and follows the delegations step by step —root → .es servers (h.nic.es) → jacar.es's authoritative servers (Cloudflare)— down to the final answer. Each block is a question to a different level of the hierarchy. This is how a name is genuinely resolved on the Internet.

dig +trace +nodnssec jacar.es

I did it

DNS maps far more than names to IPs. Every domain carries several record types: A (IPv4), AAAA (IPv6), MX (where its mail goes), NS (which servers are authoritative for the domain) and TXT (free-form text: SPF, verifications, DKIM…). A single DNS zone describes many facets of a domain at once.

for t in A AAAA MX NS TXT; do echo "== $t =="; dig +short "$t" jacar.es; done

I did it

We ask the domain's authoritative server directly with +norecurse (no recursion). That server is the 'source of truth' for the jacar.es zone: its answer comes from no intermediate cache, it's the original data. Contrasting this with the recursive query from the start makes the split of roles between resolver and authoritative server crystal clear.

NS=$(dig +short NS jacar.es | head -n1); echo "Authoritative NS: $NS"; dig +noall +answer +norecurse @"$NS" jacar.es A

I did it

DNS also works in reverse: from an IP back to a name (a PTR record), known as reverse DNS. dig -x does it for us by querying the special in-addr.arpa tree. It's what mail servers and diagnostic tools use to learn 'who' an address is.

dig +short -x 1.1.1.1

I did it

So far we've used someone else's resolver. Now we bring up our own: unbound, a recursive, validating resolver running locally (127.0.0.1). Instead of forwarding to a third party, it will itself walk the root → TLD → authoritative path we saw with +trace, and cache the answers. Running your own resolver buys privacy and control.

unbound-checkconf >/dev/null && unbound && echo 'unbound started: recursive + DNSSEC-validating resolver, listening on 127.0.0.1:53'

I did it

Verification: we query 127.0.0.1 (our unbound) for example.com and it returns the IP. Our own resolver works end to end: it resolved the name starting from the root, without leaning on any third party.

dig +noall +answer +time=5 @127.0.0.1 example.com A

unbound validates DNSSEC by default. Querying a signed domain (cloudflare.com), the flags line includes 'ad' (Authenticated Data): the resolver has cryptographically verified the answer wasn't tampered with, following the chain of RRSIG signatures from the root down. Without DNSSEC there'd be no way to tell if someone forged the record.

dig @127.0.0.1 +dnssec cloudflare.com A | grep -E 'flags:|RRSIG'

I did it

The final piece: caching. We ask our unbound for wikipedia.org twice in a row. On the second answer the TTL has dropped by ~2 seconds: it didn't ask the Internet again, it served the record from its cache and counted down the elapsed time. That cache is what makes DNS —billions of queries a day— fast without hammering the authoritative servers.

dig +noall +answer +time=10 @127.0.0.1 wikipedia.org A; echo '--- same query again (served from cache) ---'; sleep 2; dig +noall +answer +time=10 @127.0.0.1 wikipedia.org A

I did it

1 view Watch on YouTube

Was this lab useful? Rate it:

Click to rate this post!

[Total: 0 Average: 0]

Video transcript

0:00 This is how DNS works, with real queries.
0:04 We start with the basics:
0:05 this machine sends every query to the server listed in the resolv.conf file.
0:11 Here that is 1.1.1.1, Cloudflare's public resolver.
0:16 Understand what DNS is and how it works under the hood, by running real dig
0:20 queries.
0:22 DNS.
0:22 The Internet's phone book:
0:24 it translates domain names (jacar.es) into the IP addresses machines actually
0:30 use.
0:31 How a name gets resolved.
0:32 Root, TLD (.es), Authoritative, Answer.
0:36 In this lab.
0:37 Resolve names and inspect the record types.
0:40 Trace resolution from the root down.
0:42 Run your own resolver with unbound.
0:45 Validate with DNSSEC and watch caching work.
0:48 The most common query:
0:50 a name to an IPv4 address, the A record.
0:53 The second column is the TTL, how many seconds that answer may stay cached.
0:58 dig +trace.
0:59 It trusts no resolver:
1:01 it starts at the root servers and follows the delegations step by step down to the
1:05 authoritative one.
1:07 With the trace option, dig skips the resolver.
1:10 It starts at the root servers and follows each delegation:
1:13 the root, the .es servers and, last, the authoritative servers for jacar.es.
1:20 A domain holds several record types:
1:22 A and AAAA for addresses, MX for mail, NS for its authoritative servers and TXT for
1:28 free text.
1:30 Now we ask the authoritative server directly, with no recursion.
1:34 Its answer comes from no cache:
1:36 it is the zone's original data.
1:39 DNS also works in reverse.
1:41 With the x option, dig goes from an IP to a name:
1:45 the PTR record, the one mail servers check.
1:48 Recursive resolver.
1:50 Instead of forwarding to a third party, unbound walks the hierarchy itself (root
1:55 to TLD to authoritative), validates, and caches the answers.
1:59 So far we used someone else's resolver.
2:02 Now we start our own, unbound, on
2:05 127.0.0.1.
2:08 It walks the hierarchy itself and caches the answers.
2:12 We check that it works:
2:14 we ask 127.0.0.1 for example.com and
2:19 unbound returns the IP, resolved from the root with no third party.
2:25 DNSSEC.
2:26 A chain of cryptographic signatures from the root proving the answer wasn't
2:30 tampered with.
2:31 The ad flag confirms validation.
2:34 Unbound validates DNSSEC by default.
2:38 Querying cloudflare.com shows the ad flag:
2:41 the answer's signature was checked all the way from the root.
2:44 TTL and caching.
2:46 The TTL says how many seconds a record may be kept.
2:50 The resolver serves it from cache until it expires, avoiding a repeat lookup.
2:55 Last, the cache.
2:56 We ask for wikipedia.org twice in a row.
3:00 In the second answer the TTL has dropped:
3:03 unbound serves it from its cache without asking again.

DNS is one of those pieces of infrastructure you only notice when it breaks. In this lab we crack it open with dig: you’ll see a real name-to-IP resolution, the full trace from the root servers down to the authoritative one, the record types that describe a domain (A, AAAA, MX, NS, TXT) and, at the end, your own recursive resolver validating DNSSEC and serving from cache.

If you work with containers, DNS shows up constantly, which is why this pairs well with our Portainer on Docker Compose lab the guides in the Tools category, and the rest of our hands-on labs. To go deeper into the original specification, the canonical reference is RFC 1035, for a visual primer see Cloudflare’s learning center, and the official list of root servers at IANA.

FAQ

What is DNS?

DNS (the Domain Name System) is the Internet's phone book: it translates human-readable domain names like jacar.es into the IP addresses machines need to connect. Without it you'd have to memorize numeric addresses for every service.

What is the difference between a recursive resolver and an authoritative server?

The recursive resolver (your router's, your ISP's, or a public one like 1.1.1.1) walks the hierarchy for you and caches the answer. The authoritative server is a zone's source of truth: it publishes the domain's original records and relies on no cache.

What is DNSSEC for?

DNSSEC adds a chain of cryptographic signatures from the root that proves a DNS answer wasn't tampered with in transit. A validating resolver like unbound checks those signatures and marks the answer with the 'ad' (Authenticated Data) flag when they check out.

Cheat sheet

```
cat /etc/resolv.conf
```
```
dig +noall +answer jacar.es A
```
```
dig +trace +nodnssec jacar.es
```

for t in A AAAA MX NS TXT; do echo "== $t =="; dig +short "$t" jacar.es; done

NS=$(dig +short NS jacar.es | head -n1); echo "Authoritative NS: $NS"; dig +noall +answer +norecurse @"$NS" jacar.es A

```
dig +short -x 1.1.1.1
```

unbound-checkconf >/dev/null && unbound && echo 'unbound started: recursive + DNSSEC-validating resolver, listening on 127.0.0.1:53'

dig @127.0.0.1 +dnssec cloudflare.com A | grep -E 'flags:|RRSIG'

dig +noall +answer +time=10 @127.0.0.1 wikipedia.org A; echo '--- same query again (served from cache) ---'; sleep 2; dig +noall +answer +time=10 @127.0.0.1 wikipedia.org A

Found it useful? Don't miss the next lab

Subscribe to the newsletter

FAQ

What is DNS?

What is the difference between a recursive resolver and an authoritative server?

What is DNSSEC for?

Cheat sheet