Networking

DNS and DHCP¶

Almost everything you do on a network depends on two background services: DNS translates human-friendly names into IP addresses, and DHCP hands devices a working IP configuration the moment they connect. This page explains how each one works, the message exchanges behind them, and the tools you use to inspect and troubleshoot them.

Applies to

These are protocol-level services, so the concepts are OS-agnostic. DNS lookups use dig/nslookup; DHCP behaviour is identical whether the client is Linux, Windows, a phone, or a printer. Examples show Linux and Windows commands where they differ.

Both services build on the addressing and ports covered in TCP, UDP, and ports and IP addressing and subnetting.

DNS: turning names into IP addresses¶

You type example.com; the computer needs 203.0.113.10. DNS (the Domain Name System) is the distributed database that does the translation. It is hierarchical: no single server knows everything, so a lookup is answered by walking down the tree until you reach the server that holds the real record.

The resolution path¶

When nothing is cached, a name is resolved by handing the question off down a chain:

Application (browser)
   |
   v
Stub resolver       (the thin client in your OS - knows almost nothing,
   |                 just forwards the question to a configured resolver)
   v
Recursive resolver  (does the actual legwork and caches results;
   |                 e.g. your ISP's, or 1.1.1.1 / 8.8.8.8)
   |---> ROOT server:        "where is .com?"        -> "ask the .com TLD servers"
   |---> TLD server (.com):  "where is example.com?" -> "ask its authoritative NS"
   |---> AUTHORITATIVE NS:   "what is example.com?"  -> "A 203.0.113.10"
   v
answer cached for its TTL, then returned back up the chain

Role	What it does
Stub resolver	The lightweight resolver built into your OS. It does not walk the tree itself; it asks a configured recursive resolver and waits for the final answer.
Recursive resolver	Does the legwork (root -> TLD -> authoritative) on your behalf and caches what it learns. Run by ISPs or public services like `1.1.1.1` and `8.8.8.8`.
Root servers	The top of the tree; they point to the right TLD servers.
TLD servers	Know which nameservers are authoritative for each domain under a TLD (`.com`, `.org`, `.in`).
Authoritative nameservers	Hold the real records for a domain. This is where the zone actually lives.

Recursive vs iterative

From the stub resolver's point of view the query is recursive - it asks once and gets a final answer. The recursive resolver then does iterative queries (root, then TLD, then authoritative), following referrals until it has the answer.

Record types in brief¶

A DNS zone is made of resource records. The ones you meet most often:

Type	Purpose
A	Name -> IPv4 address
AAAA	Name -> IPv6 address
CNAME	Alias: this name is really another name
MX	Mail servers for the domain (with priorities)
NS	Which nameservers are authoritative for the zone (delegation)
PTR	Reverse lookup: IP address -> name
TXT	Arbitrary text; used for SPF, DKIM, DMARC, domain verification

Going deeper on records

For full examples of every record type, SPF/DKIM/DMARC, apex CNAME limits, and how to point a domain at a server, see Domains and DNS for Hosting.

Caching and TTL¶

Every record carries a TTL (time-to-live, in seconds) that tells resolvers how long they may cache the answer. A 3600 TTL means an answer can be reused for an hour before the resolver asks again. Caching is what keeps DNS fast and keeps load off the authoritative servers.

There is no "push" in DNS. When you change a record, old cached copies simply expire across the world's resolvers as their TTLs run out - this is what people call propagation. Lower a record's TTL a day before a planned change so the new value is picked up in minutes, then raise it back afterwards.

Tools¶

# Linux / macOS - dig (from bind-utils / dnsutils)
dig example.com +short            # just the answer
dig A    example.com +short       # explicit A record
dig MX   example.com +short       # mail servers
dig +trace example.com            # walk root -> TLD -> authoritative
dig @1.1.1.1 example.com +short   # query a specific resolver (bypass local cache)
dig -x 203.0.113.10               # reverse lookup (PTR)

:: Windows - nslookup
nslookup example.com
nslookup -type=MX example.com
nslookup example.com 1.1.1.1      :: query a specific resolver

nslookup exists on Linux too, but dig gives clearer, more scriptable output and is the troubleshooting tool of choice.

DHCP: automatic IP assignment¶

Without DHCP you would type an IP address, subnet mask, gateway, and DNS server into every device by hand. DHCP (Dynamic Host Configuration Protocol) does it automatically: a device connects, asks the network for a configuration, and gets a working setup within a second.

The DORA process¶

A client and DHCP server exchange four messages. The mnemonic is DORA:

CLIENT                                                  DHCP SERVER
  |  1. DISCOVER  (broadcast: "is there a DHCP server?")     |
  |-------------------------------------------------------->|
  |  2. OFFER     (server: "you can have 192.168.1.50")     |
  |<--------------------------------------------------------|
  |  3. REQUEST   (broadcast: "I'll take 192.168.1.50")     |
  |-------------------------------------------------------->|
  |  4. ACK       (server: "confirmed - here's your lease") |
  |<--------------------------------------------------------|

Step	Message	Meaning
D	Discover	Client broadcasts looking for any DHCP server (it has no IP yet).
O	Offer	One or more servers reply offering an address and settings.
R	Request	Client broadcasts which offer it accepts (so other servers know to release theirs).
A	Acknowledge	The chosen server confirms and finalises the lease.

The early messages are broadcasts because the client does not yet have an IP address to be reached at.

What a lease includes¶

A DHCP lease is more than an address - it is a full set of network settings, valid for a limited time (the lease duration). A typical lease hands the client:

IP address - e.g. 192.168.1.50
Subnet mask - e.g. 255.255.255.0, defining the local network (see IP addressing and subnetting)
Default gateway - the router used to reach other networks
DNS servers - the resolvers the client should use for name lookups

Before the lease expires the client tries to renew it (usually at half the lease time) so its address stays stable.

# Linux - inspect / renew a lease
ip address show                 # current addresses
sudo dhclient -r && sudo dhclient eth0   # release then request a new lease

:: Windows
ipconfig /all          :: show lease, gateway, DNS, lease times
ipconfig /release      :: drop the current lease
ipconfig /renew        :: request a fresh lease

Reservations¶

A reservation ties a specific IP to a device's MAC address in the DHCP server's config. The device still uses DHCP (so its DNS/gateway stay centrally managed), but it always receives the same address - ideal for printers, servers, and network gear that other systems must reach at a fixed IP.

Relay across subnets¶

DHCP relies on broadcasts, and routers do not forward broadcasts between subnets. So a single DHCP server cannot directly hear clients on other subnets. The fix is a DHCP relay agent (also called an IP helper) running on the router or a local host: it catches the broadcast Discover, forwards it as a unicast to the central DHCP server, and relays the replies back.

[ Client subnet A ] --broadcast--> [ Router / relay agent ] --unicast--> [ Central DHCP server ]

This lets one DHCP server serve many subnets instead of running a server on each.

Static vs dynamic addressing¶

	Static	Dynamic (DHCP)
Set by	Configured by hand on the device	Assigned by a DHCP server
Stability	Never changes	May change unless reserved
Best for	Servers, routers, infrastructure	Laptops, phones, general clients
Effort at scale	High - manual per device	Low - centrally managed

A common middle ground is DHCP reservations: dynamic management with a stable, predictable address.

Verify your work¶

# DNS works and resolution is sane
dig example.com +short          # returns an IP
dig +trace example.com          # ends at the authoritative nameservers
dig @1.1.1.1 example.com +short # a public resolver agrees

# DHCP gave you a complete config
ip address show                 # an address on the right subnet
ip route show                   # a default route via the gateway
cat /etc/resolv.conf            # DNS servers were handed to you

On Windows, ipconfig /all should show an IP, mask, gateway, DNS servers, and lease times. You are done when names resolve to addresses and your client has a full lease (IP, mask, gateway, DNS) without anything configured by hand.

Summary¶

DNS maps names to IPs by walking stub resolver -> recursive resolver -> root -> TLD -> authoritative, then caching the answer for its TTL.
Key records: A/AAAA (addresses), CNAME (alias), MX (mail), NS (delegation), PTR (reverse), TXT (verification/SPF/DKIM/DMARC). See the hosting DNS page for depth.
Inspect DNS with dig (+trace, @resolver, -x) and nslookup.
DHCP auto-assigns addresses through the DORA exchange (Discover, Offer, Request, Acknowledge).
A lease delivers IP, mask, gateway, and DNS; reservations pin a fixed IP to a MAC; a relay agent lets one server cover multiple subnets.
Use static addressing for infrastructure, dynamic for clients, and reservations when you want both.