Linux concept: DHCP

Je steekt een netwerkkabel in, of gaat op een wifinetwerk, en een paar seconden later werkt alles. Je hebt geen IP-adres gekozen, geen gateway opgezocht en geen DNS-server ingetypt. Iets heeft dat allemaal aan je machine gegeven terwijl jij de laptop nog aan het openklappen was. Dat iets is DHCP, en op de meeste netwerken is het de dienst met de grootste gevolgen waar niemand aan denkt tot de dag dat hij stopt.

2. Waar komt de naam vandaan?

DHCP staat voor Dynamic Host Configuration Protocol, en elk woord erin is gekozen tegen iets specifieks.

DHCP  =  Dynamic Host Configuration Protocol

• Dynamic, omdat de voorgaande systemen statisch waren. Configuratie werd met de hand opgeschreven, per machine, en een netwerk wijzigen betekende elk apparaat langsgaan.
• Host, het oude woord voor elke machine aan een netwerk, uit een tijd waarin dat meestal iets groots in een ruimte met een verhoogde vloer betekende.
• Configuration, bewust breder dan "adres". Zelfs in 1993 was de bedoeling een heel pakket instellingen af te leveren.
• Protocol, omdat het een vastgelegd gesprek is en geen product. Elke client kan met elke server praten.

Het woord dat het meeste werk doet is dynamic. Dat is de hele bedoeling: een machine die nog nooit op dit netwerk geweest is, en waar de beheerder nog nooit van gehoord heeft, kan aankomen en binnen een seconde correct ingesteld zijn zonder dat er een mens aan te pas komt.

4. DORA en het leven van een lease

Een lease krijgen is een gesprek van vier pakketten, en het heeft een naam die mensen al decennia door certificeringsexamens heen sleept: DORA.

4.1 De vier pakketten

CLIENT                                          SERVER
  |                                                |
  |  1. DISCOVER   broadcast: "is anyone there?"   |
  |  ──────────────────────────────────────────────>  |
  |                                                |
  |  2. OFFER      "you may have 192.168.1.198"    |
  |  <──────────────────────────────────────────────  |
  |                                                |
  |  3. REQUEST    broadcast: "I accept, from you" |
  |  ──────────────────────────────────────────────>  |
  |                                                |
  |  4. ACK        "confirmed, here is everything" |
  |  <──────────────────────────────────────────────  |

Het detail dat het onthouden waard is, is waarom REQUEST uitgezonden wordt in plaats van rechtstreeks verstuurd. Het lijkt verspilling, want de client weet al welke server hij wil. Maar als twee servers allebei aangeboden hebben, vertelt alleen een uitzending aan de verliezer dat zijn aanbod afgewezen is, zodat die het adres terug in de voorraad kan zetten in plaats van vast te houden.

4.2 De lijn, en de berichten die DORA weglaat

Alle vier de pakketten reizen over UDP, op twee poorten die niet veranderd zijn sinds voor DHCP bestond:

$ grep -E '^(bootps|bootpc|dhcpv6)' /etc/services
bootps          67/udp
bootpc          68/udp
dhcpv6-client   546/udp
dhcpv6-server   547/udp

Poort 67 is de server, poort 68 is de client. Kijk trouwens naar de namen: het zijn nog steeds bootps en bootpc, voor BOOTP-server en BOOTP-client. Veertig jaar later staan de poorten geregistreerd onder de naam van het protocol dat DHCP verving, en dat is dezelfde erfenis die next_server in het pakket achterliet.

UDP is hier de juiste keuze om een reden die je makkelijk over het hoofd ziet: TCP heeft een werkende IP-configuratie nodig om een handshake af te maken, en op het moment van DISCOVER heeft de client die niet. Het protocol moet werken voordat het netwerk werkt.

Omdat het gewoon UDP op bekende poorten is, kun je het hele gesprek meekijken:

$ sudo tcpdump -ni any 'udp port 67 or udp port 68'

Dit is het laatste redmiddel en het gereedschap dat discussies beslecht. Het laat zien of een DISCOVER de machine daadwerkelijk verlaten heeft, of er iets geantwoord heeft, en vooral hoeveel dingen er geantwoord hebben.

DORA is alleen het gelukkige pad. Het protocol legt nog vier berichten vast, en elk daarvan benoemt een specifieke situatie:

DECLINE is degene die je in een capture wilt herkennen. Een client die een adres afwijst betekent dat iets anders op het netwerk het al gebruikt, en daar is een korte lijst oorzaken voor: een machine die statisch ingesteld is binnen het leasebereik, een tweede DHCP-server, een verouderde reservering, of een gekloonde virtuele machine die zijn oorspronkelijke adres meedraagt. Alle vier zijn configuratiefouten en geen DHCP-storingen.

4.3 Verlengen: het deel dat eeuwig doorloopt

DORA gebeurt een keer. Daarna besteedt de client de rest van zijn leven aan verlengen, en de timers zijn vastgelegd als breuken van de lease:

Die breuken verklaren het gedrag dat mensen het meest verwart: een DHCP-server kan lang plat liggen voordat iemand het merkt. Elke machine heeft al een geldige lease, en geen van alle heeft iets nodig tot hij 50% van zijn eigen termijn bereikt. Met een lease van 24 uur levert een server die om negen uur 's ochtends uitvalt zijn eerste slachtoffer rond negen uur 's avonds op, en daarna druppelen de storingen een machine tegelijk binnen in plaats van allemaal tegelijk.

Het verklaart ook waarom de leaseduur een echte beslissing is. Korte leases betekenen sneller terughalen en sneller doorwerken van gewijzigde instellingen, ten koste van meer verkeer en een kleiner storingsvenster. Lange leases betekenen het omgekeerde. Een kantoor met vaste werkplekken kan prima dagen gebruiken; een conferentiewifinetwerk dat honderden telefoons per uur van adressen voorziet heeft minuten nodig.

6. Je eigen lease lezen op Linux

Alles hierboven is zichtbaar op de machine voor je neus, en naar een echte lease kijken is de snelste manier om het protocol concreet te maken.

6.1 Welke client draai je eigenlijk?

Linux heeft meerdere DHCP-clients en die van jou heb je meestal niet zelf gekozen. Hij kwam mee met de manier waarop je machine netwerken beheert:

Zoek uit welke het bij jou is voordat je naar leasebestanden gaat zoeken, want de meeste handleidingen die je online vindt gaan uit van dhclient en een bestand dat jouw systeem misschien niet heeft.

$ systemctl is-active NetworkManager systemd-networkd dhcpcd
active
inactive
inactive

6.2 De lease, in zijn geheel

Op een systeem met NetworkManager drukt dit precies af wat de server overhandigd heeft:

$ nmcli -f DHCP4 device show wlp0s20f3
DHCP4.OPTION[1]:    dhcp_client_identifier = 01:2c:6d:c1:13:67:3a
DHCP4.OPTION[2]:    dhcp_lease_time = 1800
DHCP4.OPTION[3]:    dhcp_server_identifier = 192.168.1.1
DHCP4.OPTION[4]:    domain_name_servers = 192.168.1.1
DHCP4.OPTION[5]:    expiry = 1787411669
DHCP4.OPTION[6]:    ip_address = 192.168.1.198
DHCP4.OPTION[7]:    next_server = 192.168.1.1
DHCP4.OPTION[8]:    ntp_servers = 10.12.0.20
DHCP4.OPTION[9]:    requested_broadcast_address = 1
DHCP4.OPTION[10]:   requested_domain_name = 1
DHCP4.OPTION[11]:   requested_domain_name_servers = 1
DHCP4.OPTION[12]:   requested_domain_search = 1
DHCP4.OPTION[13]:   requested_host_name = 1
DHCP4.OPTION[14]:   requested_interface_mtu = 1
DHCP4.OPTION[15]:   requested_ms_classless_static_routes = 1
DHCP4.OPTION[19]:   requested_rfc3442_classless_static_routes = 1

Er staat meer in die uitvoer dan het op het eerste gezicht lijkt, en het is de moeite waard hem in twee helften te lezen.

De regels die met requested_ beginnen zijn wat de client gevraagd heeft. Die lijst reist mee in het DISCOVER-pakket als de parameter request list, en het is de client die zegt "als je hier toevallig iets van weet, stuur het dan mee". Al het andere is wat de server daadwerkelijk teruggestuurd heeft.

Vergelijk de twee helften en de scheefheid springt eruit. Deze client vroeg om een domeinnaam, een zoekdomein, een MTU en classless static routes. Hij kreeg er niets van. Hij kreeg wel een NTP-server waar hij nooit om gevraagd heeft. Geen van beide kanten doet iets fout: de client vraagt om alles wat hij kan gebruiken, de server stuurt waarmee hij ingesteld is, en de overlap is wat hij is.

De andere velden vertellen ook een verhaal:

• dhcp_lease_time = 1800 is dertig minuten, en dat is kort. Deze router heeft besloten adressen agressief te hergebruiken, dus verlengen gebeurt elke vijftien minuten.
• dhcp_server_identifier en domain_name_servers zijn hetzelfde adres. De router is de DHCP-server en de DNS-resolver, wat normaal is op een klein netwerk en betekent dat een uitvallend apparaat allebei meeneemt.
• expiry is een Unix-tijdstempel. Decodeer hem om precies te weten wanneer deze lease sterft:

  $ date -d @1787411669
  Sat Aug 22 05:14:29 PM CEST 2026

• next_server is een erfenis van BOOTP, het adres waarvandaan een machine over het netwerk zou opstarten. Niets hier gebruikt het.

6.3 Dynamisch of statisch, in een oogopslag

Je hebt de lease niet altijd nodig. De kernel houdt bij waar een route vandaan komt, en ip route laat het zien:

$ ip route
default via 192.168.88.1 dev eth0 proto static metric 100
default via 192.168.1.1 dev wlp0s20f3 proto dhcp src 192.168.1.198 metric 600

Twee default routes op een machine, uit twee verschillende bronnen. De bekabelde interface is met de hand ingesteld, dus zijn route is proto static. De wifi-interface kreeg zijn route uit een lease, dus die is proto dhcp. De adressen zijn het daarmee eens:

$ ip -4 addr show wlp0s20f3
    inet 192.168.1.198/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp0s20f3

Dat woord dynamic is dezelfde uitspraak vanaf de adreskant: achter dit adres zit een lease met een lopende klok. Een statisch ingestelde interface draagt het niet.

Dit is de snelste eerste controle bij elk onderzoek naar "het netwerk doet raar". Verwachtte je dat een interface statisch was en zegt ip route proto dhcp, dan heb je het probleem gevonden voordat je een configuratiebestand geopend hebt.

8. De opties: wat er nog meer met je adres meekomt

De instellingen die DHCP draagt zijn genummerd, en een handvol van die nummers verklaart gedrag waar je waarschijnlijk al tegenaan gelopen bent.

8.1 Optie 6: waar je DNS vandaan komt

Dit is het verband dat mensen het vaakst missen. Je machine heeft zijn DNS-server niet gekozen, en jij ook niet. Hij kwam binnen in de lease, en op een Linux-systeem reist hij automatisch van de DHCP-client naar de resolverconfiguratie:

$ nmcli -f DHCP4 device show wlp0s20f3 | grep domain_name_servers
DHCP4.OPTION[4]:    domain_name_servers = 192.168.1.1

$ resolvectl status | grep -A1 'Current DNS Server'
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

Hetzelfde adres op beide plekken, want het tweede is door het eerste gezet. Dit is waarom het DNS-artikel zegt dat /etc/resolv.conf gegenereerd wordt en niet bewerkt: een DHCP-client is een van de dingen die het genereren, en hij overschrijft je aanpassingen bij de volgende verlenging. Wil je andere DNS-servers, wijzig ze dan bij de DHCP-server, of zeg je netwerkbeheerder dat hij de servers uit de lease moet negeren.

8.2 Optie 121: degene die stilletjes niets doet

Optie 3 geeft een client een default gateway. Optie 121 geeft hem een volledige routeringstabel, en zo deelt een netwerk "voor het bereik 10.20.0.0/16 ga je via die andere router" uit zonder iets op de client in te stellen.

Het addertje is dat ondersteuning niet universeel is, en een client die optie 121 niet begrijpt meldt geen fout. Hij negeert de routes eenvoudigweg en gebruikt de default gateway voor alles. Het symptoom is dat een bepaald subnet vanaf sommige machines onbereikbaar is en vanaf andere prima, zonder een foutmelding ergens. Duw je routes via DHCP, controleer dan op elk besturingssysteem of ze daadwerkelijk aangekomen zijn.

8.3 Optie 42 en de klok

De lease in sectie 6.2 bevatte ntp_servers = 10.12.0.20, waar de client nooit om gevraagd heeft en die hij toch kreeg. Tijd is het hebben waard: een machine met een flink verkeerde klok kan geen TLS-certificaat valideren, kan niet tegen Kerberos authenticeren, en produceert logs die met niets te correleren zijn.

Of die optie gebruikt wordt hangt af van de tijddaemon, en verschillende negeren DHCP-servers ten gunste van hun eigen ingestelde pool. Net als bij optie 121 is de storing stil, dus controleer in plaats van aan te nemen.

10. Best practices

• Draai een DHCP-server per netwerksegment. Het protocol kan niet bemiddelen tussen twee, dus twee servers met overlappende bereiken geven vroeg of laat hetzelfde adres aan twee machines. Heb je redundantie nodig, gebruik dan een paar dat van elkaar weet, of splits het bereik.
• Reserveer een deel van het subnet en deel dat nooit uit. Servers, printers, switches en accesspoints hebben adressen nodig die niet verspringen. Bepaal de grens een keer en schrijf hem op.
• Kies reserveringen boven statische instelling op het apparaat. De instelling staat op een plek die jij beheert, en het apparaat kan vervangen of teruggezet worden en komt toch goed terug.
• Stem de leaseduur af op hoe snel apparaten komen en gaan. Dagen voor vaste werkplekken, minuten voor gastenwifi. Bedenk dat de verlengingscyclus op 50% begint, dus een korte lease verkort ook hoe lang een uitgevallen server onzichtbaar blijft.
• Verlaag de leaseduur voordat je DHCP-opties wijzigt, niet terwijl je ze wijzigt. Elke machine houdt zijn huidige instellingen tot hij verlengt, dus een kortere lease een dag van tevoren betekent dat het hele netwerk de nieuwe gateway of DNS-server binnen minuten oppikt in plaats van over een dag.
• Zet DHCP snooping aan op beheerde switches. Het is de enige echte verdediging tegen een valse server, en het protocol biedt zelf niets.
• Weet welke server hoort te antwoorden. Als er iets vreemds is, lees dan dhcp_server_identifier uit de lease van een client. Noemt die iets onverwachts, dan heb je het probleem in een commando gevonden.
• Repareer DNS uit DHCP niet door /etc/resolv.conf aan te passen. De volgende verlenging overschrijft het. Wijzig het bij de DHCP-server, of stel de client in om die optie te negeren.
• Controleer of doorgegeven routes en NTP-servers echt aangekomen zijn. Opties 121 en 42 falen stil op clients die ze negeren, en het symptoom is een onbereikbaar subnet of een afdrijvende klok, geen foutmelding.
• Behandel een 169.254-adres als een diagnose, niet als een fout om omheen te werken. Het betekent dat geen enkele server geantwoord heeft.
• Bouw niets nieuws op ISC DHCP. Het is end-of-life sinds oktober 2022. Gebruik dnsmasq voor kleine netwerken en Kea voor de rest.

12. Samenvatting

DHCP is de dienst die alles instelt en waar niemand krediet voor krijgt. Hij loopt een keer als een machine aankomt, verlengt stilletjes zolang die blijft, en is onzichtbaar tot de dag dat hij dat niet is.

• DHCP lost een kip-en-eiprobleem op met broadcast: een machine zonder adres roept, en wie het hoort antwoordt. Daarom gaat het geen routers over zonder relay.
• Het deelt veel meer uit dan een adres: gateway, DNS-servers, zoekdomein, NTP-servers en de leaseduur. De DNS-regel veroorzaakt de meest verkeerd gediagnosticeerde storingen.
• Een adres is een lease, geen bezit. Er zit een klok op en het keert vanzelf terug in de voorraad.
• DHCP is de derde poging: RARP gaf alleen een adres, BOOTP (RFC 951, 1985) voegde doorsturen en opties toe maar gebruikte een handgeschreven tabel, en DHCP voegde voorraden en leases toe. RFC 2131 uit maart 1997 is nog steeds de specificatie.
• DORA is de uitwisseling van vier pakketten: Discover, Offer, Request, Acknowledge. REQUEST wordt bewust uitgezonden, zodat servers wier aanbod afgewezen is dat kunnen vrijgeven.
• Het loopt allemaal over UDP op poorten 67 (server) en 68 (client), nog steeds geregistreerd als bootps en bootpc. Bekijk de hele uitwisseling met tcpdump -ni any 'udp port 67 or udp port 68'.
• DORA is het gelukkige pad. DECLINE betekent dat het adres al in gebruik is, NAK dat de client om een adres vroeg dat niet bij dit subnet hoort, RELEASE geeft een lease vroegtijdig terug, en INFORM vraagt om instellingen zonder adres.
• Uitzendingen gaan geen routers over, dus een relay agent stuurt ze door en stempelt zijn eigen adres in giaddr. De server kiest de voorraad op basis van dat veld, en daarom krijgt een VLAN zonder passend subnet stilte in plaats van een foutmelding.
• Verlengen begint op 50% van de lease en herbinden op 87,5%. Daarom levert een uitgevallen DHCP-server urenlang geen symptomen op en druppelen de storingen daarna een machine tegelijk binnen.
• Lees je eigen lease met nmcli -f DHCP4 device show, of networkctl status onder systemd-networkd. De requested_-regels zijn wat de client vroeg; al het andere is wat de server werkelijk stuurde.
• ip route labelt elke route met zijn herkomst. proto dhcp tegenover proto static beantwoordt "is deze interface met de hand ingesteld?" in een commando.
• Draai een server per segment, reserveer een deel van het subnet, en kies reserveringen boven adressen op apparaten instellen.
• ISC DHCP is end-of-life sinds oktober 2022. Gebruik dnsmasq voor kleine netwerken en Kea voor grotere.
• DHCP heeft geen authenticatie. Wie het eerst antwoordt wint, dus een valse server is triviaal eenvoudig en DHCP snooping op de switch is de enige echte verdediging.
• Een 169.254-adres betekent dat geen enkele server geantwoord heeft. Het is een diagnose, geen instelling.
• IPv6 gebruikt vooral SLAAC: machines bouwen adressen uit een router advertisement, zonder server en zonder lease. DHCPv6 (RFC 8415) bestaat voor wat SLAAC niet kan.
• DHCP is waar je machine leert welke DNS-server hij moet vragen. Wat daarna gebeurt staat in het bijbehorende artikel over DNS.

Dit is de checklist die het bewaren waard is als een netwerk zich vreemd gedraagt:

DID DHCP WORK AT ALL
  ip -4 addr                     an address, or 169.254 (nothing answered)
  ip route                       proto dhcp or proto static?

WHAT DID IT ACTUALLY SAY
  nmcli -f DHCP4 device show IF  the whole lease, both halves
  networkctl status IF           the same under systemd-networkd
  dhcp_server_identifier         WHICH server answered: check this first
  dhcp_lease_time                renewal happens at half of it
  date -d @<expiry>          when this lease dies

WHERE DID THE SETTINGS GO
  resolvectl status              DNS servers, should match option 6
  ip route                       gateway, plus any option 121 routes

IF NOTHING ANSWERS AT ALL
  tcpdump -ni any 'udp port 67 or udp port 68'
                                 did the DISCOVER leave? did anything reply?
  relay configured on this VLAN?  broadcasts do not cross routers
  server has a subnet for giaddr? no match means silence, not an error
  host firewall                  broadcast UDP 67/68 is easy to drop

WHEN IT IS INTERMITTENT
  same interval every time       renewal failing at 50% of the lease
  only some machines             a second DHCP server on the segment
  one subnet unreachable         option 121 routes ignored by that client

Een netwerk waarop machines verschijnen, zichzelf correct instellen en blijven werken is geen geluk: het is een server die op elk segment antwoordt, een bereik dat niet botst met iets vasts, een leaseduur die past bij hoe het netwerk gebruikt wordt, en een switch die weigert iets anders te laten antwoorden.

Is een netwerk uitgegroeid tot grillige storingen die van machine naar machine verspringen, of weet niemand meer precies welk apparaat de adressen uitdeelt, dan is dat een middag aandacht van iemand waard voordat het de ochtend wordt waarop iedereen aankomt en niets werkt.