DNS: Name Resolution

The scenario

Three devices share one switch on 10.0.1.0/24: a Laptop (10.0.1.10), a DNS Server (10.0.1.2) and a Web Server (10.0.1.20, listening on TCP ports 80 and 443). The Laptop's DNS server setting is 10.0.1.2, the same setting a PC gets from DHCP or from the nameserver line in /etc/resolv.conf. When you trace to a name instead of an address, the Laptop first sends a DNS question over UDP port 53 to 10.0.1.2, and only then connects to the address in the answer. The DNS Server holds two A records: web.lab points to 10.0.1.20, and api.lab points to 10.0.1.30, an address no device in this lab uses.

What you will work out

Understand how a device turns a name into an address by asking its own DNS server, and why a successful lookup does not guarantee a working connection.

Why this matters

Almost every connection starts with a lookup, so a missing record, a record pointing at the wrong address, and a device asking no server or the wrong one all look like 'the site is down' to a user. Splitting the problem into its two steps finds the broken one quickly: dig or nslookup shows whether the name resolves, and a connection by address shows whether the server answers.

Running it

DNS: Name Resolution opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.