Sekundær DNS – synkroniser sonen uten en ny feilkilde

Sekundær DNS betyr at én eller flere autoritative servere henter sonedata fra en definert kilde og publiserer kopien til resolvere. Alle offentlige navnetjenere svarer autoritativt; «sekundær» beskriver hvordan serveren får data, ikke at svaret er mindre gyldig.

Modellen kan redusere risikoen for at én server eller DNS-leverandør gjør hele domenet usynlig. Den kan også introdusere en ny feilkilde hvis soner, DNSSEC og leverandørspesifikke funksjoner ikke synkroniseres.

Primær, sekundær og hidden primary

En hidden primary er en intern eller avgrenset kilde som mater offentlige sekundærer. Den kan redusere angrepsflaten mot endringskilden og gjøre det mulig å bruke flere publiseringsnettverk.

Den må fortsatt sikres, overvåkes og ha redundans. Hvis alle sekundærer mister muligheten til å hente oppdateringer lenge nok, kan sonen stoppe etter SOA expire selv om de fortsatt har en lokal kopi.

Slik flyter en endring

En standardbasert kjede ser forenklet slik ut:

1. Sonen endres hos primærkilden.
2. SOA-serial økes.
3. Primæren kan sende DNS NOTIFY til sekundærene.
4. Sekundæren spør etter SOA og ser om serial er nyere.
5. Sekundæren ber om IXFR eller AXFR.
6. Den validerer og laster den nye sonen.
7. Offentlige oppslag får den nye versjonen fra alle serverne.

RFC 5936 beskriver AXFR, mens RFC 1995 beskriver IXFR og RFC 1996 beskriver rask varsling om endringer.

NOTIFY er et signal om at sekundæren bør sjekke. Det er ikke selve soneinnholdet, og en mistet NOTIFY skal ikke gjøre synkronisering permanent avhengig av varselet. SOA refresh gir en periodisk kontrollvei.

AXFR, IXFR og leverandør-API er ulike modeller

AXFR overfører hele sonen

AXFR returnerer den komplette sonen for et bestemt serial. Det brukes ved første synkronisering, når inkrementell historikk ikke finnes, eller når IXFR faller tilbake til full overføring.

IXFR overfører endringene

IXFR kan sende forskjellen mellom sekundærens serial og ny versjon. Det reduserer data og arbeid for store eller hyppig endrede soner, men krever at primæren har nødvendig endringshistorikk.

API-synkronisering kan bevare andre funksjoner

To administrerte leverandører kan bruke API eller et eksternt source-of-truth-system i stedet for DNS-soneoverføring. Det kan være nødvendig når begge plattformer skal konfigurere:

• proxy-status og CDN
• flattening eller proprietære aliasposter
• helsesjekker og failover
• geografisk eller vektet ruting
• individuelle DNSSEC-signaturer

Dette er ikke automatisk bedre. API-feil, forskjellig datamodell og delvis gjennomførte endringer må håndteres. Én deklarativ kilde og idempotent publisering er tryggere enn at mennesker redigerer samme sone manuelt i to paneler.

SOA-serial avgjør om sonen er nyere

Sekundæren bruker SOA-serial til å oppdage en ny versjon. En vanlig menneskelesbar konvensjon er dato og revisjon:

2026082201

Serienummeret er et 32-bits felt med egne regler for serial-aritmetikk. Ikke bygg en migrering som antar at et vilkårlig høyere desimaltall alltid kan gjenopprettes eller sammenlignes som vanlig heltall gjennom wraparound.

Ved restore av gammel sone må serial fortsatt bli nyere etter DNS-reglene. Ellers kan sekundærene beholde den feilaktige versjonen fordi de ikke ser en oppdatering.

Refresh, retry og expire er en beredskapskjede

SOA-timerne har ulike oppgaver:

For kort expire kan gjøre et problem hos primæren til en autoritativ DNS-hendelse raskt. For lang expire kan gjøre at gamle data publiseres lenge. Verdiene må passe endringsfrekvens, overvåking og tiden dere realistisk trenger for å reparere overføringsveien.

Se SOA-posten felt for felt og DNS-sone og sonefil før timerne endres.

En åpen AXFR er ikke nødvendig redundans

Sekundæren må få tilgang til soneoverføring. Det betyr ikke at enhver klient på internett skal kunne hente hele sonen.

Begrens overføring med:

• eksplisitte sekundæradresser
• TSIG eller annen støttet transaksjonsautentisering
• egne nøkler per leverandør eller relasjon
• avgrenset nøkkeltilgang og planlagt rotasjon
• logging og varsling på avviste og vellykkede overføringer

TSIG autentiserer DNS-transaksjoner med delt hemmelighet, men en vanlig soneoverføring over TCP blir ikke dermed kryptert. Dersom konfidensialitet er et krav, beskriver RFC 9103 soneoverføring over TLS. Hele transfergruppen må bruke en konsekvent sikkerhetsmodell; én ukryptert eller svakt autentisert vei er fortsatt en svak lenke.

Ikke send TSIG-hemmeligheten i e-post eller et vanlig kontaktskjema. Bruk en avtalt hemmelighetskanal og roter nøkkelen etter eksponering.

Sekundær DNS er ikke en sikkerhetskopi

En sekundær gir en tilgjengelig kopi av det primæren publiserer. Den kopierer også:

• slettede poster
• feil IP-adresse
• ødelagt MX eller SPF
• ugyldig CAA-policy
• et for høyt eller feil serial

Soneoverføring er synkronisering, ikke versjonshistorikk. Behold separate, testede eksporter eller en deklarativ historikk som kan gjenopprettes med et nytt serial. Beskytt også konfigurasjon utenfor standardsonen, som proxyregler, DNSSEC-nøkler og tilgangsroller.

Uavhengig sekundær må redusere en reell felles feil

To NS-navn hos én anycast-leverandør kan allerede svare fra mange steder og nettverk. En annen leverandør kan redusere leverandøravhengighet, men bare hvis den ikke deler de kritiske feilene.

Kartlegg:

• autoritativ plattform og nettverk
• registrar og parent-delegering
• source of truth for sonedata
• identitetssystem og administratorer
• DNSSEC-signer og nøkkellager
• API-klient og deploypipeline
• overvåking og hendelseskanal

Hvis én feilaktig pipeline publiserer samme ødelagte sone til begge leverandører, har dere nettverksredundans, men ikke beskyttelse mot konfigurasjonsfeil.

DNSSEC: én signer eller flere signere

Én signert sone overføres

Én signer kan produsere komplett signert sone, og sekundærene publiserer samme DNSKEY-, RRSIG-, NSEC- eller NSEC3-data. Dette ligner vanlig primary/secondary, men alle leverandører må støtte overføring og servering av det signerte innholdet korrekt.

Hver leverandør signerer selv

Ved multi-signer har leverandørene egne signeringsnøkler. Da må DNSKEY-sett, DS-poster, algoritmer, signaturfornyelse og nøkkelrotasjon koordineres.

RFC 8901 beskriver flere modeller og hvorfor nøkkelendringer må rekke alle leverandører før gammel nøkkel fases ut. Dette er ikke et oppsett som bør improviseres i to kontrollpaneler.

En blanding der én navnetjener returnerer signerte data og en annen mangler nødvendige signaturer kan gi valideringsfeil som fremstår tilfeldige for brukerne.

Leverandørfunksjoner kan hindre standard soneoverføring

Sammenlign støtte for:

• apex-alias eller CNAME-flattening
• ANAME og andre ikke-standardtyper
• dynamisk eller geografisk ruting
• DNS-failover og helsesjekker
• proxied poster
• automatiske ACME- eller verifiseringsposter
• DNSSEC-signering og CDS/CDNSKEY
• store TXT-, HTTPS- og SVCB-postsett

En sekundær som bare mottar standard A-, AAAA-, CNAME-, MX- og TXT-data kan gi et annet produksjonssvar enn primærleverandøren. Det er et arkitekturproblem, ikke bare et importproblem.

Test før NS-settet utvides

Ikke legg sekundærens navn i parent-delegeringen før den er lastet og svarer riktig.

dig @ns1.primary.example bedrift.no SOA +norecurse
dig @ns2.secondary.example bedrift.no SOA +norecurse
dig @ns1.primary.example bedrift.no A +norecurse
dig @ns2.secondary.example bedrift.no A +norecurse

Kontroller minst:

• samme SOA-serial og apex-NS
• identiske ordinære postsett der modellen krever det
• autoritativt svar fra alle servere
• UDP og TCP på port 53
• A og AAAA for navnetjenerne
• negative svar og DNSSEC-bevis
• nye posttyper og store svar
• refresh etter en kontrollert endring

Ved multi-signer kan RRSIG og DNSKEY variere etter den valgte modellen. Test da DNSSEC-validering, ikke bare tekstlikhet.

Overvåk både tilgjengelighet og konsistens

En grønn porttest oppdager ikke en gammel sone. Overvåk:

Varslet må gå til noen som kan rette sonekilden, transferregler eller DNSSEC. Ikke vent til expire før en stoppet IXFR undersøkes.

Test de feilene sekundæren skal tåle

En kontrollert øvelse bør bekrefte at:

1. Offentlige sekundærer fortsetter å svare når primary/hidden primary stoppes.
2. Sonen forblir tilgjengelig gjennom planlagt primærbrudd.
3. Varsling utløses når refresh feiler.
4. Ny oppdatering synkroniseres etter at primæren kommer tilbake.
5. En sekundærleverandør kan feile uten at hele NS-settet blir utilgjengelig.
6. DNSSEC validerer i begge situasjoner.
7. Restore av en tidligere sone får et gyldig, nyere serial.

Øvelsen skal ha avgrensning, rollback og forventet observasjon. Det er ikke nødvendig å gjøre domenet utilgjengelig for å teste at en bestemt navnetjener kan tas ut.

Når sekundær DNS er verdt kompleksiteten

Uavhengig sekundær er mest relevant når:

• DNS-bortfall stopper kritiske tjenester
• virksomheten har et dokumentert tilgjengelighetskrav
• dagens leverandør er en uakseptabel felles feil
• sonen kan representeres konsistent hos begge
• DNSSEC-modellen er støttet og øvd
• teamet kan overvåke og håndtere avvik

For et vanlig .no-domene hos en moden anycast-leverandør kan flere uavhengige leverandører gi mer operasjonell risiko enn nytte. Guiden til flere navnetjenere forklarer grunnkravet uten å anta at to leverandører er nødvendig.

Vymos standardleveranse inkluderer ikke en selvbetjent hidden-primary-, AXFR- eller multi-signer-tjeneste. Hvis virksomheten har dokumenterte krav om leverandøruavhengig autoritativ DNS, send soneomfang, DNSSEC-status, nødvendige postfunksjoner og tilgjengelighetsmål via kontaktsiden . Ikke send TSIG-hemmeligheter, API-nøkler eller private DNSSEC-nøkler.

Sekundær DNS gir verdi når alle offentlige svar er koherente og den sekundære veien faktisk overlever feilen dere har designet for. Flere NS-navn alene er ikke bevis på noen av delene.