SOA-posten: sonens «fødselsattest»

Hver DNS-sone starter med én obligatorisk post: SOA-posten – Start of Authority. Den er sonens «fødselsattest»: den forteller hvem som er ansvarlig, når sonen sist ble oppdatert, og hvordan sekundære navnetjenere skal synkronisere seg. Uten en SOA-post er en DNS-sone ikke gyldig.

Hos de fleste DNS-leverandører vedlikeholdes SOA-posten automatisk. Men å forstå hva den inneholder gjør det lettere å feilsøke problemer og forstå hvordan DNS fungerer i sin helhet.

Hvordan ser en SOA-post ut?

En typisk SOA-post ser slik ut i tekst-format:

eksempel.no.  SOA  ns1.dnsleverandor.no. hostmaster.eksempel.no. (
    2025090101  ; Serienummer
    3600        ; Refresh (sekunder)
    900         ; Retry (sekunder)
    604800      ; Expire (sekunder)
    300         ; Minimum TTL (sekunder)
)

La oss gå gjennom hvert felt.

Feltene i SOA-posten

Primær navnetjener (MNAME)

Det første feltet etter SOA er vertsnavnet til den primære autoritative navnetjeneren. Dette er navnetjeneren som er «master» for sonen – den andre navnetjenere henter oppdateringer fra.

Ansvarlig kontaktadresse (RNAME)

Det andre feltet er en e-postadresse, men i et spesielt format: @-tegnet erstattes med et punktum. Så hostmaster.eksempel.no. betyr i virkeligheten hostmaster@eksempel.no. Dette er en teknisk kontaktadresse for sonen – ikke noe de fleste sluttbrukere trenger å forholde seg til.

Serienummer

Serienummeret er sonens versjonsnummer. Hver gang sonen endres, skal serienummeret økes. Sekundære navnetjenere bruker dette nummeret til å oppdage om de har den nyeste versjonen av sonen:

• Er sekundærens serienummer lavere enn primærens? Da henter sekundæren en oppdatert kopi.
• Er de like? Ingen oppdatering nødvendig.

Konvensjonelt brukes datoen som del av serienummeret: 2025090101 betyr 1. september 2025, revisjon 01. Slik er det enkelt å se når sonen sist ble endret.

Viktig: Serienummeret må alltid øke. Senkes det (noe som kan skje ved gjenoppretting av en gammel backup), kan sekundærer slutte å synkronisere.

Refresh

Hvor ofte sekundære navnetjenere skal sjekke om primæren har en nyere versjon av sonen, oppgitt i sekunder. Typisk verdi: 3600 (1 time) til 86400 (24 timer).

Retry

Dersom en sekundær navnetjener ikke klarer å kontakte primæren under en planlagt Refresh-sjekk, venter den Retry sekunder før den prøver igjen. Bør være lavere enn Refresh – typisk 900 (15 minutter).

Expire

Dersom sekundæren ikke har lykkes å kontakte primæren i Expire sekunder, anser den sin lokale kopi av sonen som utdatert og slutter å svare autoritativt. Typisk verdi: 604800 (7 dager). Dette er en sikkerhetsventil – ingen sekundær skal svare med potensielt gammel informasjon i all evighet.

Minimum TTL

Det siste feltet er historisk brukt som standard TTL for poster i sonen, men i dag (siden RFC 2308) brukes det som negativ TTL – hvor lenge resolver skal cache et «domenet finnes ikke»-svar (NXDOMAIN). Typisk verdi: 300 til 3600 sekunder.

En oversiktstabell

Hva betyr dette når du administrerer DNS?

Bruker du en administrert DNS-tjeneste, oppdateres SOA-posten normalt automatisk. Du trenger da ikke tenke på serienummeret – det økes når sonen endres.

Men det er nyttig å kjenne til SOA-timerne, særlig Refresh og Expire, fordi de påvirker hvor raskt endringer slår igjennom på sekundære navnetjenere og hvor lenge sekundærene kan operere selvstendig om primæren er nede. Les driftsguiden til sekundær DNS før timerne eller overføringsmodellen endres.

For mer om TTL-verdier generelt og hvordan de påvirker propagering, se Hva er TTL i DNS? .

Sjekke SOA-posten

Du kan se SOA-posten for et domene med dig:

dig SOA eksempel.no

Dette gir deg alle feltene i ANSWER SECTION. Er serienummeret lavt eller veldig gammelt, kan det indikere at sonen ikke har blitt oppdatert som forventet. Er Expire-verdien uvanlig lav, kan sekundærer miste sonekopien sin raskere enn ønsket.

Å forstå SOA-posten er et steg mot å forstå DNS-infrastrukturen helhetlig. Vil du dykke dypere, se Hva er DNS? eller oversikten over DNS-poster .