Sjekk navnetjener-propagering steg for steg

Etter et navnetjenerbytte er «nettsiden virker hos meg» en dårlig fasit. Nettleseren tester én enhet, én resolver og én tjeneste. E-post kan fortsatt gå til gammel leverandør, en av navnetjenerne kan svare feil, eller en DNSSEC-feil kan være skjult av lokal cache.

Denne sjekklisten gir deg en bedre avgjørelse: Skal du vente på cache, eller må DNS-oppsettet rettes? Du trenger et terminalverktøy som dig, domenenavnet og navnene på de gamle og nye navnetjenerne.

Før du starter: noter forventet resultat

Skriv ned dette før du tolker oppslagene:

Uten en forventet verdi kan du se at to svar er forskjellige, men ikke hvilket som er riktig.

1. Sjekk delegeringen fra .no

Kontrollpanelet hos domeneforhandleren viser hva du ba om å få endret. DNS-hierarkiet viser hva internett faktisk blir henvist til. Følg henvisningene fra roten:

dig +trace eksempel.no NS +noall +authority +nodnssec

Se etter linjene der .no henviser domenet til navnetjenerne. De skal inneholde de nye navnene. Hvis resultatet fortsatt viser de gamle navnetjenerne, er ikke den nye delegeringen publisert i overordnet sone ennå.

Et vanlig oppslag er også nyttig, men kan vise et cachet svar:

dig eksempel.no NS

For norske domener publiserer Norid NS-poster i .no-sonen og nødvendige limposter. Norid krever blant annet minst to navnetjenere, at alle svarer autoritativt, og at NS-dataene hos navnetjenerne samsvarer med registreringen. Se Norids tekniske krav til navnetjenere .

Tolkning:

• Nye navnetjenere vises fra .no: gå videre til autoritativ test.
• Gamle navnetjenere vises: kontroller at endringen er lagret hos domeneforhandleren.
• Blanding av gamle og nye svar bare fra rekursive resolvere: det kan være cache.
• Navnetjenernavn under domenet selv mangler IP-adresse: undersøk limposter.

2. Spør alle nye navnetjenere direkte

Et navnetjenerbytte er ikke ferdig bare fordi delegeringen peker riktig. Hver oppført server må være konfigurert for domenet og gi et autoritativt svar.

dig @ns1.leverandor.no eksempel.no SOA +norecurse
dig @ns2.leverandor.no eksempel.no SOA +norecurse

Kontroller tre ting i hvert svar:

1. Status er NOERROR.
2. aa står blant flaggene. Det betyr authoritative answer.
3. Begge svarene viser samme SOA-serienummer.

Spør deretter etter NS-settet direkte:

dig @ns1.leverandor.no eksempel.no NS +norecurse
dig @ns2.leverandor.no eksempel.no NS +norecurse

NS-settet i sonen skal samsvare med navnetjenerne som er delegert fra .no. Hvis én server ikke svarer, mangler aa, eller viser et annet serienummer, har du en autoritativ feil. Resolvere kan da få ulike resultater også etter at all gammel cache er borte.

Dette omtales ofte som en svak eller lame delegering: overordnet sone henviser til en server som ikke utfører den forventede autoritative tjenesten. RFC 9499 beskriver blant annet manglende svar, utilgjengelige adresser og svar uten autoritativt flagg som slike delegeringsproblemer.

3. Sammenlign viktige poster i gammel og ny sone

Før du flytter, bør den nye sonen inneholde alle postene tjenestene faktisk trenger. Test minst nettsted og e-post mot hver nye navnetjener:

dig @ns1.leverandor.no eksempel.no A +short
dig @ns1.leverandor.no eksempel.no AAAA +short
dig @ns1.leverandor.no www.eksempel.no CNAME +short
dig @ns1.leverandor.no eksempel.no MX +short
dig @ns1.leverandor.no eksempel.no TXT +short
dig @ns1.leverandor.no _dmarc.eksempel.no TXT +short

Gjenta med ns2. For DKIM må du også teste selektoren e-postleverandøren har gitt deg, for eksempel:

dig @ns1.leverandor.no selector1._domainkey.eksempel.no TXT +short

Ikke anta at en manglende AAAA-post er feil hvis tjenesten ikke bruker IPv6, eller at www må være CNAME hvis leverandøren bruker A-post. Sammenlign med det avtalte oppsettet.

Hvis du fortsatt har tilgang til de gamle navnetjenerne, spør dem på samme måte. Gammel og ny sone bør gi kompatible svar gjennom overgangsperioden. Da fortsetter nettside og e-post å virke uansett hvilken delegering en resolver har i cache.

4. Kontroller DNSSEC før du skylder på propagering

DNSSEC knytter data i domenets sone til en DS-post i .no. Ved flytting kan domenet slutte å validere hvis gammel DS-post står igjen mens de nye navnetjenerne bruker en annen nøkkel eller ikke signerer sonen.

Se hvilke DS-poster som publiseres:

dig +trace eksempel.no DS

Test via en validerende resolver:

dig @1.1.1.1 eksempel.no A +dnssec
dig @8.8.8.8 eksempel.no A +dnssec

SERVFAIL hos validerende resolvere, samtidig som et direkte oppslag mot navnetjeneren gir data, er et sterkt tegn på DNSSEC-feil. Det er ikke noe som blir riktig av vanlig TTL-venting. Kontroller DS, DNSKEY og signaturkjeden etter planen i guiden til DNSSEC ved leverandørbytte .

Norid krever at registrerte DS-poster peker til DNSKEY-poster i den delegerte sonen, og at SOA- og NS-data kan valideres. Det er derfor viktig at DNSSEC-endringen koordineres med navnetjenerbyttet.

5. Sammenlign rekursive resolvere

Når delegeringen er riktig og alle autoritative servere svarer likt, kan du undersøke restene av gammel cache:

dig @1.1.1.1 eksempel.no NS
dig @8.8.8.8 eksempel.no NS
dig @9.9.9.9 eksempel.no NS

Sammenlign deretter A- og MX-postene:

dig @1.1.1.1 eksempel.no A
dig @8.8.8.8 eksempel.no A
dig @1.1.1.1 eksempel.no MX
dig @8.8.8.8 eksempel.no MX

Hvis autoritative svar er riktige, men noen rekursive resolvere fortsatt viser gammel verdi, er venting normalt. Se TTL-en i det gamle svaret. Den viser hvor lenge akkurat den resolveren kan beholde kopien.

Hvis alle rekursive resolvere gir SERVFAIL, tomt svar eller samme feil etter at de autoritative serverne er kontrollert, må du gå tilbake til delegering og DNSSEC. En prikkete verdenskart-test er mindre presis enn å finne hvilket lag som faktisk avviker.

For en grundig forklaring på TTL, negativ cache og hvorfor resolverne kan være uenige, se DNS-propagering forklart .

6. Test nettside og e-post som tjenester

DNS-oppslag er nødvendige, men de beviser ikke at tjenesten bak svaret fungerer.

For nettstedet bør du kontrollere:

• domenet med og uten www
• HTTP-videresending til riktig HTTPS-adresse
• gyldig TLS-sertifikat for begge vertsnavn
• riktig nettsted når webserveren har flere domener
• skjemaer, innlogging og andre viktige funksjoner

For e-post bør du kontrollere:

• at MX-postene har forventet navn og prioritet
• at leverandøren har aktivert domenet på sin side
• at SPF, DKIM og DMARC er bevart
• sending både til og fra en ekstern adresse
• at gammel leverandør ikke mottar meldinger som blir oversett

En webserver som viser feil side, eller en e-postleverandør som ikke kjenner domenet, er ikke propageringsfeil selv om det oppstår samtidig med DNS-bytte.

Resultat: vent eller rett?

En navnetjenerendring er ferdig når hele kjeden er riktig

Ikke mål et navnetjenerbytte med antall timer siden du trykket lagre. Mål det med konkrete svar:

• .no delegerer til de nye navnetjenerne
• alle nye navnetjenere svarer autoritativt og likt
• sonen inneholder riktige poster for nettsted og e-post
• DNSSEC validerer
• rekursive resolvere går fra gammelt til nytt svar uten tjenestebrudd

Når disse punktene stemmer, er eventuell ulikhet normalt bare cache. Hvis ett punkt feiler, vet du nøyaktig hvem som må rette hva. Den metoden er både raskere og tryggere enn å vente 48 timer uten å kontrollere kilden.