DNS-sone og sonefil – les, eksporter og flytt riktig

En DNS-sone er den administrative delen av DNS-navnerommet som en bestemt gruppe navnetjenere publiserer. En sonefil er en tekstlig representasjon av ressursoppføringene i sonen.

Begrepene brukes ofte som om de var samme ting, men skillet betyr noe. Hos en moderne DNS-leverandør kan databasen, API-et eller kontrollpanelet være den egentlige kilden. Sonefilen er da en eksport eller et importformat, ikke nødvendigvis filen som serveren leser direkte.

Domene og sone er ikke alltid det samme

Sonen bedrift.no kan inneholde poster for rotdomenet og mange underdomener:

bedrift.no
www.bedrift.no
butikk.bedrift.no
_dmarc.bedrift.no

Men en del av navnerommet kan delegeres til andre navnetjenere. Hvis butikk.bedrift.no delegeres som egen sone, ligger postene under denne sonegrensen ikke lenger i bedrift.no-sonen.

Det gir tre nyttige begreper:

Et registrert domene har vanligvis en sone med samme navn, men DNS-modellen tillater flere soner under samme domenehierarki.

Et komplett, forenklet sonefileksempel

Eksemplet bruker adresser og vertsnavn som er reservert for dokumentasjon. Ikke kopier verdiene til produksjon.

$ORIGIN bedrift.no.
$TTL 3600

@ IN SOA ns1.dnsleverandor.example. hostmaster.bedrift.no. (
  2026082201
  3600
  900
  1209600
  300
)

@ IN NS ns1.dnsleverandor.example.
@ IN NS ns2.dnsleverandor.example.

@ 300 IN A 192.0.2.40
@ 300 IN AAAA 2001:db8::40
www 300 IN CNAME bedrift.no.

@ 3600 IN MX 10 mx.epostleverandor.example.
@ 3600 IN TXT "v=spf1 include:spf.epostleverandor.example -all"
_dmarc 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@bedrift.no"
selector1._domainkey 3600 IN CNAME selector1.epostleverandor.example.

RFC 1035 definerer masterfilformatet som tekstlige ressursoppføringer, med linjer, felt, parenteser for videreføring og direktiver som $ORIGIN. Senere standarder har utvidet formatet, blant annet med $TTL.

En leverandør kan eksportere den samme informasjonen i annen rekkefølge, med eksplisitt TTL på hver linje eller med alle navn skrevet fullt ut.

Feltene i én ressursoppføring

Se på denne linjen:

www 300 IN CNAME bedrift.no.

RDATA-feltene avhenger av posttypen. En A-post har én IPv4-adresse. En MX-post har prioritet og mål. En SOA-post har flere strukturerte verdier. En TXT-post kan bestå av én eller flere tekststrenger.

Les oversikten over DNS-posttyper når du skal tolke en ukjent eksport.

$ORIGIN, @ og punktumet til slutt

$ORIGIN bedrift.no. setter grunnnavnet for relative eiernavn og mål. Tegnet @ representerer gjeldende origin, altså bedrift.no. i eksemplet.

Disse eiernavnene blir derfor:

Et navn med avsluttende punktum er absolutt. Et navn uten punktum til slutt er relativt og får gjeldende origin lagt til.

Dette er en av de vanligste importfeilene:

www IN CNAME target.plattform.example

I en sone med origin bedrift.no. kan målet tolkes som:

target.plattform.example.bedrift.no.

Hvis målet skal være et eksternt, fullt navn, må masterfilformatet normalt ha:

www IN CNAME target.plattform.example.

Kontrollpaneler varierer. Noen legger til punktum eller sonenavn automatisk, andre forventer bare etiketten. Følg grensesnittets eksempel i stedet for å anta at tekstfeltet bruker rått sonefilformat.

$TTL og eksplisitt TTL

$TTL 3600

Direktivet setter standard TTL for etterfølgende poster som ikke har en eksplisitt verdi. Linjen under bruker derimot 300 sekunder:

@ 300 IN A 192.0.2.40

$TTL ble lagt til masterfilformatet i RFC 2308 . Det skal ikke forveksles med SOA-postens siste felt. Dette feltet brukes i moderne DNS til TTL for negative svar, sammen med SOA-postens egen TTL etter reglene for negativ caching.

Ved eksport kan alle poster få eksplisitt TTL selv om kildeteksten brukte $TTL. Det er normalt; den effektive DNS-verdien er viktigere enn om eksporten beholder den opprinnelige skrivemåten.

Hva SOA-posten inneholder

SOA står for Start of Authority. Hver sone skal ha én SOA-post på soneapex. I eksemplet er feltene, i rekkefølge:

I RNAME er første punktum separatoren som tilsvarer @ i en e-postadresse. hostmaster.bedrift.no. representerer dermed normalt hostmaster@bedrift.no. Escape-regler trengs hvis den lokale delen selv inneholder punktum.

Mange administrerte DNS-plattformer genererer SOA automatisk. Ikke kopier leverandørens MNAME, serial og tidsverdier blindt til en ny plattform hvis den nye leverandøren eier disse feltene.

NS i sonen og NS hos forelderen

Sonefilen inneholder normalt NS-poster på apex. For et .no-domene finnes også en delegering i .no-sonen. De to settene bør beskrive det samme aktive oppsettet, men de lagres og endres på ulike steder:

• NS hos .no vedlikeholdes gjennom registraren
• NS på apex publiseres av DNS-leverandøren

En import av sonefilen endrer ikke automatisk delegeringen hos Norid. Det er bra: Den nye sonen kan bygges og testes før registrarens NS-endring gjør den synlig.

Les hvordan navnetjenere og delegering virker før du bytter leverandør.

Det som ofte ikke følger sonefilen

Standard ressursoppføringer kan eksporteres, men leverandørspesifikke tjenester kan ligge utenfor formatet:

• proxy- eller CDN-status for en post
• redirectregler og URL-videresending
• helsesjekker, failover og trafikkstyring
• geografiske eller vektede svar
• DNSSEC-signering og nøkkelhåndtering
• tilgangsroller, revisjonslogg og API-tokens
• automatiske poster laget av en integrasjon
• interne views eller split DNS
• leverandørens e-post- eller webkonfigurasjon

En Cloudflare-eksport kan for eksempel inneholde A- eller CNAME-verdien, mens orange-cloud/proxy-status må kontrolleres separat. En sonefil er derfor ikke en komplett sikkerhetskopi av DNS-kontoen eller alle tjenestene rundt den.

TXT-poster er ikke alle hemmeligheter, men eksporter bør beskyttes

SPF-policy, DMARC-policy og DKIM-offentlig nøkkel er laget for å publiseres i DNS. Andre TXT-poster kan være midlertidige verifiseringstokens eller avsløre hvilke tjenester bedriften bruker.

Behandle soneeksporten som driftsinformasjon:

• lagre den i et tilgangsstyrt område
• ikke legg den i et offentlig kodearkiv
• fjern gamle verifiseringsposter etter leverandørens prosedyre
• del bare med dem som skal planlegge eller utføre flyttingen

Private DNSSEC-nøkler, kontopassord og API-tokens hører aldri hjemme i en standard offentlig sonefil.

Slik flytter du en sone kontrollert

1. Hent både eksport og aktive svar

Eksporter fra kontrollpanelet hvis mulig, men sammenlign med de autoritative svarene som faktisk publiseres. Et gammelt kontrollpanel kan inneholde inaktive poster, og en ren serie dig-oppslag finner ikke automatisk alle navn i sonen.

Et ANY-oppslag er heller ikke en soneeksport. Servere kan begrense slike svar, og spørsmålet ber bare om tilgjengelige typer for ett navn.

2. Lag en tjenesteinventarliste

Knytt postene til nettsted, e-post, sertifikater, verifisering, underdomener og integrasjoner. Da ser du om en manglende post er foreldet eller forretningskritisk.

3. Avklar hva den nye leverandøren genererer

Kontroller SOA, apex-NS, DNSSEC, flattening og leverandørspesifikke funksjoner. Importer ikke genererte poster bare fordi de står i eksporten.

4. Valider formatet

Hvis sonen skal lastes i BIND og verktøyet er installert, kan syntaksen kontrolleres slik:

named-checkzone bedrift.no bedrift.no.zone

Bestått syntaks betyr ikke at IP-adresser, e-postmål eller verifiseringsverdier er forretningsmessig riktige. Bruk også leverandørens importvalidering.

5. Test den nye sonen før delegering

Spør hver ny autoritativ server direkte:

dig @ns1.nydns.example bedrift.no SOA +norecurse
dig @ns1.nydns.example bedrift.no A +norecurse
dig @ns1.nydns.example bedrift.no MX +norecurse
dig @ns1.nydns.example _dmarc.bedrift.no TXT +norecurse

Kontroller også www, kritiske subdomener, AAAA, CAA, DKIM-selectorer og tjenestespesifikke poster.

6. Bytt delegering og behold gammel sone

Endre NS gjennom registraren først når alle nye navnetjenere svarer likt og korrekt. Behold den gamle sonen aktiv gjennom overgangsperioden, fordi resolvere kan bruke cachet delegering.

7. Kontroller etter byttet

Følg delegasjon, SOA, DNSSEC og kritiske posttyper fra flere resolvere. Test nettsted og e-post ende til ende. En vellykket import er ikke det samme som en vellykket tjeneste.

Soneoverføring er noe annet enn filimport

AXFR er protokollen for full soneoverføring mellom DNS-servere. Den brukes blant annet mellom primær- og sekundærservere. Det er ikke nødvendig å åpne AXFR offentlig for å kunne laste ned en sone fra et kontrollpanel.

Begrens soneoverføring til autoriserte servere. En offentlig lesbar DNS-sone er ikke det samme som at alle navn bør kunne hentes samlet gjennom en åpen AXFR. Se hvordan sekundær DNS synkroniserer og beskytter sonen hvis eksporten skal bli en løpende overføringsmodell.

Før du anser flyttingen som ferdig

• alle nye autoritative servere gir samme SOA og postsett
• foreldredelegering og apex-NS stemmer
• A og AAAA viser riktig nettsted
• MX, SPF, DKIM og DMARC er bevart
• CAA tillater den sertifikatutstederen som faktisk brukes
• proxy, redirect og helsesjekker er gjenskapt der de trengs
• DNSSEC-kjeden validerer etter byttet
• gammel leverandør beholdes til cachet delegering er ute
• eksport, beslutninger og ansvar er dokumentert

Vymo kan hjelpe med å kartlegge DNS for domenet og koble det til den enkle bedriftsnettsiden vi leverer. Send domenenavn, dagens DNS-leverandør og planlagt endring via kontaktsiden . Ikke send passord, API-nøkler, flyttekoder eller private nøkler.

En sonefil er mest verdifull når den behandles som én del av en større tjenesteinventar. Kontroller både standardpostene og funksjonene som ikke kan uttrykkes i filen før navnetjenerne flyttes.