DHCP and DNS¶

Exercise dhcp-and-dns-annex.pdf · PDF

In Configuring TCP/IP on hosts you typed four settings by hand into two machines. In this building there are hundreds of phones and laptops, and nobody typed anything. Who did? And who knows the IP address of Instagram, or of your bank, by heart? Nobody. Yet your phone finds them in milliseconds.

Two quiet protocols do this work for you every single day. When either one breaks, people say "the Internet is down", even when it is not. On this page you learn to tell them apart, and to fix the right one.

DHCP: who types the four settings?¶

DHCP, the Dynamic Host Configuration Protocol (RFC 2131, March 1997), is a service in which a server lends each newcomer an IP address and tells it the other three settings: mask, gateway and DNS server.

In the postal analogy: you arrive in a new town and go to the town hall desk. They assign you a letterbox for a limited time, and give you a leaflet with the address of the post office and of the address book.

DORA: four messages¶

The newcomer has a problem: it has no address, and it does not know where the server is. So it shouts.

sequenceDiagram
    participant C as Client (no address yet)
    participant S as DHCP server 10.G.0.2
    C->>S: Discover (broadcast): is there a server?
    S->>C: Offer: you can have 10.G.0.185
    C->>S: Request (broadcast): I take 10.G.0.185
    S->>C: Acknowledge: yours for 600 s, plus gateway and DNS

DHCP travels inside UDP, a transport protocol: the server listens on port 67, the client on port 68.

The lease¶

A lease is the time for which the address is lent.

At half of the lease, the client asks the same server to renew it. If it gets no answer, it keeps trying; when the lease ends, it must stop using the address. That is how the addresses of phones that left yesterday go back to the pool (the range of addresses the server may lend).

A reservation tells the server "this MAC always gets this address". It is the comfortable way to give a printer a fixed address without typing it on the printer.

Lab: watch a lease being born¶

This lab is svc.clab.yml (on Google Classroom). The node srv (10.G.0.2) runs a DHCP and DNS server; pc1 and pc2 start with no address.

G=3 containerlab deploy -t svc.clab.yml       # host
docker exec -it clab-svc-pc1 bash             # terminal 1
docker exec -it clab-svc-srv bash             # terminal 2
ip -br addr show eth1                         # pc1: does it have an address?
tcpdump -n -i eth1 -c 4 port 67 or port 68    # srv: waits for 4 messages
dhclient -v eth1                              # pc1: ask for an address

dhclient is a DHCP client: it asks for an address and shows the conversation. On pc1 (group 1):

root@pc1:/# dhclient -v eth1
Listening on LPF/eth1/46:62:c0:ea:cd:fc
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
DHCPOFFER of 10.1.0.185 from 10.1.0.2
DHCPREQUEST for 10.1.0.185 on eth1 to 255.255.255.255 port 67
DHCPACK of 10.1.0.185 from 10.1.0.2
bound to 10.1.0.185 -- renewal in 265 seconds.

And what srv captured:

IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 46:62:c0:ea:cd:fc, length 300
IP 10.1.0.2.67 > 10.1.0.185.68: BOOTP/DHCP, Reply, length 313
IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 46:62:c0:ea:cd:fc, length 300
IP 10.1.0.2.67 > 10.1.0.185.68: BOOTP/DHCP, Reply, length 319

Four lines: D, O, R, A. The client's source address is 0.0.0.0 ("I have none yet") and its destination 255.255.255.255, the IPv4 broadcast. Ports 68 and 67. Your address will be somewhere in 10.G.0.100 to 10.G.0.199, the server's pool.

What came with the address?¶

ip -br addr show eth1 ; ip route                                               # pc1
grep -E "routers|name-servers|lease-time" /var/lib/dhcp/dhclient.leases        # pc1
cat /var/lib/misc/dnsmasq.leases ; ss -uln                                     # srv

root@pc1:/# ip -br addr show eth1
eth1@if3         UP             10.1.0.185/24
root@pc1:/# ip route
default via 10.1.0.1 dev eth1
10.1.0.0/24 dev eth1 proto kernel scope link src 10.1.0.185
root@pc1:/# grep -E "routers|name-servers|lease-time|renewal" /var/lib/dhcp/dhclient.leases
  option routers 10.1.0.1;
  option dhcp-lease-time 600;
  option domain-name-servers 10.1.0.2;
  option dhcp-renewal-time 300;

All four settings arrived in one exchange, and you typed none of them. Lease 600 s = 10 minutes; renewal at 300 s = half. On srv, the lease file has one line per client (expiry time, MAC, address), and ss -uln shows which UDP ports are listening:

root@srv:/# ss -uln
State  Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0      0           10.1.0.2:53        0.0.0.0:*
UNCONN 0      0       0.0.0.0%eth1:67        0.0.0.0:*

Port 67 is DHCP. Port 53 is DNS, coming next. Now run dhclient -v eth1 on pc2: it gets a different address, and the lease file has two lines.

If you run dhclient twice on the same node, release first with dhclient -r eth1.

DNS: the address book of the Internet¶

Machines need addresses; people need names. DNS, the Domain Name System, translates.

From one file to a tree¶

Until the early 1980s, every computer on the ARPANET had one file, HOSTS.TXT, with all names and addresses. It was kept by hand at the Stanford Research Institute and copied by everybody. It could not grow. In November 1983 Paul Mockapetris published the design of the DNS (RFC 882 and 883; today's base is RFC 1034 and 1035, November 1987). No central list any more, but a tree in which each branch is looked after by its owner.

Read www.debian.org. right to left:

Who walks the tree¶

Your PC does not walk the tree itself. It asks its configured DNS server, a resolver, which does the walk and keeps each answer in its cache for as many seconds as the record says. That number is the record's TTL (time to live).

flowchart LR
    PC["<b>Your PC</b><br>asks one question"] -->|"www.debian.org?"| RES["<b>Resolver</b><br>does the walk,<br>keeps a cache"]
    RES -->|"1"| ROOT["<b>Root</b><br>ask org"]
    RES -->|"2"| TLD["<b>org</b><br>ask debian.org"]
    RES -->|"3"| AUTH["<b>debian.org</b><br>authoritative:<br>here is the A record"]
    RES -->|"answer"| PC

Records¶

What a zone contains:

Our lab domain is tramuntana.internal. The ending .internal was reserved by ICANN in July 2024 for private networks: it will never exist on the Internet, so it can never clash with a real name.

Lab: ask with dig¶

dig asks a DNS server a question and prints the answer.

The real DNS, from the Ubuntu host¶

dig +short debian.org        ;  dig +short debian.org MX
dig +short www.wikipedia.org ;  dig +short -x 1.1.1.1
dig debian.org               #  the full answer; run it twice

$ dig +short debian.org               $ dig +short debian.org MX
151.101.2.132                         0 mailly.debian.org.
151.101.66.132                        0 muffat.debian.org.
151.101.130.132                       0 mitropoulos.debian.org.
151.101.194.132                       $ dig +short www.wikipedia.org
$ dig +short -x 1.1.1.1               dyna.wikimedia.org.
one.one.one.one.                      185.15.58.224

(Addresses and TTLs change with time and place.) One name can have several A records: debian.org had four, so the load is shared. www.wikipedia.org is a CNAME: one name pointing to another, then the address. -x asks the reverse question, a PTR record.

The full answer:

$ dig debian.org
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11304
;; QUESTION SECTION:
;debian.org.                    IN      A
;; ANSWER SECTION:
debian.org.             300     IN      A       151.101.2.132
;; Query time: 23 msec
;; SERVER: 169.254.1.1#53(169.254.1.1) (UDP)

Run it twice within a few seconds: the TTL has gone down. The second answer came from the cache.

With dig +trace +nodnssec debian.org you can watch the walk itself (school filters may block it):

.                       515150  IN      NS      a.root-servers.net.     (… up to m)
org.                    172800  IN      NS      a0.org.afilias-nst.info.
debian.org.             3600    IN      NS      nsp.dnsnode.net.
debian.org.             300     IN      A       151.101.194.132

Root, then org, then debian.org, then the answer: exactly the table above.

The lab's DNS, from pc1¶

@10.G.0.2 means "ask this server": the one DHCP announced.

dig @10.G.0.2 srv.tramuntana.internal +short
dig @10.G.0.2 git.tramuntana.internal +short
dig @10.G.0.2 tramuntana.internal MX +short
dig @10.G.0.2 -x 10.G.0.2 +short
dig @10.G.0.2 nope.tramuntana.internal | grep status

root@pc1:/# dig @10.1.0.2 srv.tramuntana.internal +short
10.1.0.2
root@pc1:/# dig @10.1.0.2 git.tramuntana.internal +short
srv.tramuntana.internal.
10.1.0.2
root@pc1:/# dig @10.1.0.2 tramuntana.internal MX +short
10 srv.tramuntana.internal.
root@pc1:/# dig @10.1.0.2 -x 10.1.0.2 +short
srv.tramuntana.internal.
root@pc1:/# dig @10.1.0.2 nope.tramuntana.internal | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21914

Five commands, five kinds of answer: an A record, a CNAME (git is an alias of srv), an MX, a PTR, and NXDOMAIN. On srv, tail -3 /var/log/dnsmasq.log shows your own questions arriving.

Clean up: exit everywhere, then containerlab destroy -t svc.clab.yml --cleanup.

Which one failed: DHCP or DNS?¶

Key takeaways¶

• DHCP lends an address and gives the other three settings in four messages: Discover, Offer, Request, Acknowledge (DORA). UDP ports 67 (server) and 68 (client).
• The address is lent for a lease; the client renews at half of it. A reservation ties a MAC to a fixed address.
• DNS is a tree: root → TLD → the domain's authoritative servers. Your resolver walks it and keeps answers in its cache for the record's TTL.
• Record types: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), NS (name servers), PTR (reverse).
• dig asks DNS questions; @server chooses who to ask; NXDOMAIN = the name does not exist.
• 169.254.x.x or no address → DHCP. Addresses work but names do not → DNS.

Quick check¶

Next: so far a small Linux container was the DHCP and DNS server. Now open the box that does this job in real offices, in Meet RouterOS.