Wat is een DNS SOA-record?

DNS
Gepubliceerd door

Als je ooit de DNS-records van een domein hebt bekeken met dig of een online tool, ben je waarschijnlijk een SOA-record tegengekomen zonder precies te weten waarvoor het dient. Het is een van de belangrijkste records in elke DNS-zone: het bepaalt wie het gezag over die zone heeft, hoe secundaire DNS-servers moeten synchroniseren en hoe lang gegevens geldig blijven als de primaire server uitvalt.

Wat een SOA-record bevat

SOA staat voor Start of Authority. Elke DNS-zone moet precies één SOA-record bevatten. Het staat altijd bovenaan de zone en bevat zeven afzonderlijke velden. Zo ziet een typisch SOA-record eruit:

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                          2025052901  ; Serial
                          7200        ; Refresh
                          3600        ; Retry
                          1209600     ; Expire
                          86400 )     ; Minimum TTL

Elk veld uitgelegd:

  • MNAME (ns1.example.com.): de primaire autoritatieve DNS-server van de zone. Dit is de server die secundaire servers benaderen voor updates
  • RNAME (admin.example.com.): het e-mailadres van de zone-administrator, maar met een punt in plaats van @. Hier komt dat overeen met [email protected]. Als het lokale deel een punt bevat, moet die ge-escaped worden met een backslash (voornaam\.achternaam.example.com.)
  • Serial (2025052901): een versienummer van de zone. Elke wijziging moet dit nummer verhogen, anders detecteren secundaire servers de update niet. Het gangbare formaat is JJJJMMDDNN (datum plus dagelijkse teller)
  • Refresh (7200): het interval in seconden tussen controles door secundaire servers. Hier elke 2 uur
  • Retry (3600): de wachttijd voor een nieuwe poging als de Refresh-controle mislukt. Hier 1 uur
  • Expire (1209600): de tijd waarna een secundaire server stopt met antwoorden voor de zone als hij de primaire niet meer kan bereiken. Hier 14 dagen. Na die termijn beschouwt de secundaire zijn gegevens als verlopen en stopt hij volledig met het bedienen van de zone
  • Minimum TTL (86400): sinds RFC 2308 bepaalt dit veld hoe lang negatieve antwoorden (NXDOMAIN) in cache worden gehouden. Hier 24 uur. Als iemand een niet-bestaand subdomein opvraagt, houdt de resolver dat "bestaat niet"-antwoord 24 uur in cache

Waarom het serienummer zo belangrijk is

De serial veroorzaakt in de praktijk waarschijnlijk de meeste problemen. Wanneer een secundaire server contact opneemt met de primaire tijdens een Refresh-cyclus, vergelijkt hij zijn lokale serienummer met dat van de primaire. Is dat van de primaire hoger, dan start de secundaire een zonetransfer (AXFR of IXFR) om zichzelf bij te werken. Is het niet veranderd, dan doet hij niets.

De klassieke fout: een DNS-record op de primaire wijzigen zonder de serial te verhogen. Resultaat: de primaire heeft de juiste versie, maar de secundaire servers blijven uren of zelfs dagen de oude versie serveren. Gebruikers krijgen verschillende antwoorden afhankelijk van welke server ze raken, en het probleem is lastig te diagnosticeren als niemand eraan denkt het SOA te controleren.

Het formaat JJJJMMDDNN is een conventie, geen verplichting. De serial is een 32-bits integer, dus elke waarde van 0 tot 4.294.967.295 werkt. Het datumformaat is echter aan te raden omdat het fouten zichtbaar maakt: een serial van 2025052901 is duidelijk de eerste wijziging van 29 mei 2025.

Hoe Refresh, Retry en Expire samenwerken

Deze drie waarden vormen een veerkrachtsysteem voor DNS-zones. Refresh bepaalt het normale synchronisatieritme. Retry treedt in werking bij mislukking. Expire is het allerlaatste vangnet: als deze periode zonder contact met de primaire verstreken is, geeft de secundaire er de voorkeur aan helemaal niet meer te antwoorden in plaats van mogelijk verouderde data te serveren.

Voor een standaarddomein beveelt RFC 1912 aan:

  • Refresh: 3.600 tot 86.400 seconden (1 uur tot 24 uur)
  • Retry: 600 tot 3.600 seconden (10 minuten tot 1 uur)
  • Expire: 1.209.600 tot 2.419.200 seconden (2 tot 4 weken)
  • Minimum TTL: 3.600 tot 86.400 seconden (1 uur tot 24 uur)

Als je zone vaak verandert (bijvoorbeeld een CDN of infrastructuur met dynamische load balancing), verlaag de Refresh dan naar 300 of 600 seconden. Is de zone stabiel, dan volstaat 86.400 prima en vermindert het de belasting op de primaire server.

Hoe je het SOA-record van een domein bekijkt

Op Linux en macOS is dig het handigst:

dig SOA example.com

Op Windows gebruik je nslookup:

nslookup -type=SOA example.com

Het antwoord toont alle zeven SOA-velden. Let vooral op de serial: als die oud of bevroren lijkt, is dat vaak de reden waarom DNS-wijzigingen niet correct propageren.

Veelgemaakte SOA-fouten

Een paar problemen die regelmatig voorkomen in de praktijk:

  • Het RNAME-veld gebruikt een @ in plaats van een punt, wat de syntax breekt. [email protected] moet in het SOA geschreven worden als admin.example.com.
  • De serial wordt per ongeluk verlaagd na het terugzetten van een backup. Secundaire servers weigeren te synchroniseren totdat de serial van de primaire weer boven hun lokale waarde uitkomt
  • Expire is te kort ingesteld (een paar uur). Als de primaire in het weekend uitvalt, stoppen de secundaire servers met antwoorden voordat iemand kan ingrijpen
  • Minimum TTL staat op 0, wat betekent dat resolvers negatieve antwoorden niet cachen. Elke query naar een niet-bestaand subdomein veroorzaakt een volledige roundtrip, wat je DNS-servers kan overbelasten tijdens een scan of aanval
Het SOA-record is zelden het eerste dat je aanpast bij het inrichten van een domein, maar het is vaak degene die verklaart waarom "de DNS niet propageert". Voordat je complexe oorzaken gaat zoeken, controleer of de serial correct is verhoogd en of de Refresh- en Expire-waarden bij je gebruik passen.