Direct naar de inhoud

SOA-record uitgelegd: serial en negatieve TTL

Dennis Postma22 oktober 2026
Leestijd4 minuten
DNS-basis

Het SOA-record staat bovenaan elke DNS-zone. Wat de zeven velden betekenen, hoe serienummers werken en waarom het laatste veld negatieve caching bepaalt.

DNSense handleiding-cover: een SOA-record voor example.com met serial 2026102201 en refresh 7200

Elke DNS-zone begint met één SOA-record, de Start of Authority. Het noemt de primaire server van de zone, geeft een contactadres en bevat de timers waarmee nameservers synchroon blijven. Je past het zelden aan, maar het verklaart een paar vreemde verschijnselen.

De zeven velden

Bekijk er een met dig:

dig SOA example.com +short
ns1.example.net. hostmaster.example.com. 2026102201 7200 3600 1209600 3600
VeldVoorbeeldBetekenis
MNAMEns1.example.net.De primaire nameserver van de zone
RNAMEhostmaster.example.com.Het contactadres, geschreven met een punt in plaats van @
Serial2026102201Versienummer van de zone
Refresh7200Hoe vaak een secundaire server op een nieuwe versie controleert, in seconden
Retry3600Hoe lang een secundaire server wacht voor hij na een mislukte controle opnieuw probeert
Expire1209600Hoe lang een secundaire server blijft antwoorden als hij de primaire niet bereikt
Minimum3600Hoe lang resolvers een antwoord "deze naam bestaat niet" cachen

Het serienummer

Een secundaire nameserver vergelijkt zijn serial met die van de primaire. Is die van de primaire hoger, dan haalt hij de zone op. Wijzig je records zonder de serial te verhogen, dan blijven secundaire servers de oude data serveren.

Veel hosts gebruiken de datum plus een teller, JJJJMMDDnn, dus 2026102201 is de eerste wijziging op 22 oktober 2026. Andere gebruiken een gewone teller of een Unix-tijdstempel. Elk systeem werkt, zolang het getal alleen stijgt.

Beheerde DNS-providers verhogen de serial bij elke wijziging zelf. Alleen als je zelf zonebestanden beheert, moet je het met de hand doen.

Het laatste veld telt het zwaarst

Het laatste veld is de negatieve cachetijd. Vraagt een resolver naar een naam die niet bestaat, dan onthoudt hij dat antwoord zo lang als de laagste van deze waarde en de eigen TTL van het SOA-record.

Dat geeft een klassieke verrassing. Je vraagt een nieuwe hostnaam op voor je hem aanmaakt, krijgt "niet gevonden" en voegt daarna het record toe. Je resolver blijft "niet gevonden" zeggen tot het negatieve antwoord verloopt. Maak records dus eerst aan en test daarna, en houd deze waarde bescheiden, een uur of minder, als je vaak namen toevoegt.

Opvraag van new.example.com om 10:00 geeft niet gevonden, om 10:05 wordt het record toegevoegd en de resolver blijft niet gevonden zeggen tot 11:00

Refresh, retry en expire

Deze doen er alleen toe als je secundaire nameservers draait die de zone van een primaire kopiëren. Providers die je zone vanaf hun eigen platform serveren, negeren ze. Draai je wel secundaire servers, dan is een gebruikelijke set: refresh om de paar uur, retry elk uur en expire na twee weken. Expire moet ruim boven refresh liggen, anders verandert een korte storing in een storing van de hele zone.

SOA-records en DNSense

Het SOA-record hoort bij je DNS-host. Het wordt met de zone aangemaakt en automatisch bijgewerkt, en DNSense beheert het niet, net zoals het NS-records op de apex met rust laat. Jij werkt met de records in de zone en de host regelt de serial.

Gerelateerde handleidingen