DNS

Why it matters

People remember names; networks route by IP address. The Domain Name System (DNS) translates one to the other. It is so central that "it's always DNS" is a running joke among engineers: a wrong record, an expired domain or a slow resolver can take down a service whose servers are perfectly healthy. Cloud and security engineers edit DNS records, and attackers abuse DNS for phishing and data theft, so you need to know how a lookup works.

Names are a tree

A name such as www.example.com. is read right to left:

• . the root (usually hidden)
• com a top-level domain (TLD)
• example a domain registered under .com
• www a name inside that domain

Each level is run by different name servers. The root servers know who runs .com; the .com servers know who runs example.com; the example.com name servers are authoritative and hold the actual records.

Who does the work

• Your computer has a stub resolver: it just asks one server and waits.
• A recursive resolver (your ISP's, your router's, or a public one such as 1.1.1.1 or 8.8.8.8) does the legwork and caches answers.
• Authoritative servers give the final answer for their zone.

Worked example: tracing a lookup

You visit www.example.com with empty caches:

1. Your laptop checks its own cache and the hosts file. Nothing.
2. It asks the recursive resolver configured by DHCP, say 192.168.1.1, over UDP port 53.
3. The resolver asks a root server: "where is www.example.com?" The root replies: "I don't know, but here are the .com servers."
4. The resolver asks a .com server, which replies with the name servers for example.com.
5. The resolver asks an example.com name server, which answers: www.example.com A 93.184.215.14, with a TTL.
6. The resolver caches the answer for the TTL and returns it to your laptop, which caches it too.

(The real address you see for example.com may differ; addresses in these lessons are illustrations.) The next visitor using that resolver gets the answer from cache in a millisecond or two.

Record types you will meet

Querying DNS yourself

nslookup example.com              # works on Windows, macOS, Linux
dig example.com                   # macOS / Linux, more detail
dig gmail.com MX                  # a specific record type
dig @1.1.1.1 example.com          # ask a specific resolver
dig +trace example.com            # follow the delegation from the root

In dig output, the ANSWER section shows the records, with the TTL in seconds:

;; ANSWER SECTION:
example.com.   3600   IN   A   93.184.215.14

TTL and caching

The time to live (TTL) tells resolvers how long to cache a record. Long TTLs (hours) reduce load and speed up lookups; short TTLs (60 to 300 seconds) let you move a service quickly. Before a planned migration, engineers lower the TTL a day ahead so the change spreads fast. "DNS propagation" is mostly old cached answers expiring.

Security notes

Classic DNS is unencrypted, so anyone on the path can see and potentially tamper with lookups. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the query to the resolver, and DNSSEC lets resolvers verify that answers are signed by the zone owner.

Common mistakes

• Editing a record and expecting instant change while the old TTL is still cached.
• Putting a CNAME at the zone apex (example.com itself). Standard DNS does not allow it; providers offer ALIAS or flattening records instead.
• Blaming the server when the problem is a resolver: test with a second resolver (dig @1.1.1.1).
• Forgetting the hosts file, which overrides DNS on that one machine.

Quick recap

• DNS turns names into addresses through a tree: root, TLD, authoritative.
• A recursive resolver does the lookups and caches by TTL.
• Know A, AAAA, CNAME, MX, TXT and NS records.
• Use nslookup and dig to check what DNS really returns.

Try it

Open the Do tab and trace a few lookups from your own computer.