DNS and DHCP concepts

DNS and DHCP are the two services every Linux host depends on without thinking. When they break, everything looks like a network problem but no network tool works.

DNS hierarchy

DNS is a hierarchical, distributed database. Names are read right to left:

host.example.com.
.        - the root
com      - top-level domain (TLD)
example  - second-level domain
host     - the host name

The root is served by 13 logical name servers (a.root-servers.net through m.root-servers.net), each with many physical instances.

How a name is resolved

When a client asks its resolver for www.example.com:

1. The resolver checks its cache. If fresh, done.
2. If stale, the resolver queries a root server. The root refers to the .com TLD servers.
3. The resolver queries a .com server. It refers to the example.com authoritative servers.
4. The resolver queries the example.com server. It returns the A (IPv4) or AAAA (IPv6) record for www.example.com.

The resolver does the recursion (hence “recursive resolver”). The authoritative server returns the answer without recursing.

dig www.example.com
dig +short www.example.com
dig @8.8.8.8 www.example.com       # use a specific resolver
dig +trace www.example.com         # show the full chain
dig -x 10.0.0.5                    # reverse lookup

dig is the sysadmin’s primary DNS tool. The +trace option shows every step of the resolution; this is how you diagnose “the resolver is wrong”.

Resource records

TTL (time to live) tells resolvers how long to cache. A low TTL allows faster changes at the cost of more queries.

Recursive vs authoritative resolvers

A recursive resolver accepts queries from clients and performs the full lookup. Examples: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), your ISP’s resolver, systemd-resolved on your Linux host.

An authoritative resolver (or authoritative server) holds the zone’s records and returns answers without recursing.

A host’s /etc/resolv.conf (or systemd-resolved configuration) typically points to a recursive resolver. Authoritative servers do not appear here.

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Plain DNS queries are sent over UDP/TCP port 53 in cleartext. DoH (RFC 8484) and DoT wrap the queries in TLS. systemd-resolved supports both, as do Firefox and most modern browsers.

For a sysadmin, the operational impact is small - the DNS results are the same - but the privacy properties differ. In production, plain DNS is still the default.

DHCP

DHCP dynamically assigns IP addresses, default gateway, and DNS servers. The flow:

Client -> Server:  DISCOVER (broadcast)
Server -> Client: OFFER  (your address would be X)
Client -> Server: REQUEST (I would like X)
Server -> Client: ACK    (X is yours, valid for N seconds)

The lease has a lifetime. When 50% of the lifetime is up, the client tries to renew with the same server. If that fails, it tries again at 87.5%. If renewal fails entirely, the address is given up.

DHCP failure modes

A host that cannot get a DHCP lease will often fall back to link-local addressing (169.254.0.0/16 for IPv4). This is the “APIPA” range in Windows terminology.

ip -4 addr show                    # look for 169.254.x.x
journalctl -u systemd-networkd     # DHCP logs
systemctl restart systemd-networkd

If a host has 169.254.x.x, it has no usable IPv4 address. The DHCP server is unreachable, the lease is exhausted, or the link is broken.

Recognising DNS vs DHCP failures

The diagnostic discipline: always test by IP first, then by hostname. If IP works and hostname does not, the problem is DNS. If neither works, the problem is lower in the stack.

Knowledge check