Flere navnetjenere – krav og redundans for .no

Et .no-domene må ha minst to autoritative navnetjenere. Kravet gir en grunnleggende mulighet for redundans: hvis én server ikke svarer, kan en resolver prøve en annen. Men antallet navn alene sier lite om hvor robust løsningen er.

To navnetjenere kan ligge på samme maskin og feile samtidig. Ett navnetjenernavn kan på sin side bruke anycast og besvares av mange fysiske noder over hele verden. Det riktige spørsmålet er derfor ikke bare «hvor mange?», men hvilke feil tåler tjenesten uten at domenet forsvinner?

Kravet for .no

Norids regelverk for norske domenenavn krever minst to navnetjenere. Alle navnetjenerne som oppgis, skal:

• være riktig konfigurert for domenet
• svare autoritativt
• fungere når søknaden eller endringen behandles
• oppfylle de tekniske testene Norid bruker

Norid registrerer bare fullt delegerte domener. Det er ikke et krav at abonnenten driver navnetjenerne selv; de fleste virksomheter bruker en DNS-, domene- eller hostingleverandør.

Kravet kontrollerer grunnleggende teknisk funksjon ved registrering og enkelte endringer. Det er ikke en garanti for at leverandørens arkitektur, overvåking eller beredskap passer risikoen i virksomheten.

Hva to navnetjenere faktisk beskytter mot

Tenk at domenet er delegert til ns1.leverandor.no og ns2.leverandor.no. En rekursiv resolver kan velge mellom dem. Hvis den første ikke svarer, prøver den normalt en annen autoritativ server.

Det kan beskytte mot:

• feil på én server eller prosess
• bortfall av én IP-adresse
• vedlikehold på én node
• enkelte nettverks- og rutingfeil

Brukeren kan likevel oppleve forsinkelse mens resolveren venter på tidsavbrudd og prøver neste server. Oppførselen varierer mellom resolvere, og en navnetjener som svarer raskt med feil data er ofte verre enn en som ikke svarer.

Når alle autoritative navnetjenere er utilgjengelige, kan domenet fortsette å virke midlertidig for brukere som har gyldige svar i cache. Etter hvert som TTL-verdiene utløper, vil nye oppslag feile. Det kan ramme nettside, e-post og alle andre tjenester under domenet.

To navn er ikke nødvendigvis to uavhengige systemer

Navnetjenernavn viser et logisk endepunkt. De forteller ikke alene:

• hvor mange fysiske servere som svarer
• om serverne ligger i samme datasenter
• om de bruker samme nettverk, programvare og kontrollplan
• om én feilkonfigurasjon publiseres til alle samtidig
• om leverandøren har uavhengige driftsmiljøer

En moden DNS-leverandør kan levere flere navnetjenernavn fra en distribuert anycast-plattform. Hvert navn kan svare fra mange steder, og plattformen kan tåle bortfall av enkeltlokasjoner. Les hvordan anycast DNS fordeler trafikken før dere teller servernavn som om de var fysiske maskiner.

Motsatt kan ns1 og ns2 peke til to IP-adresser på samme vert, samme nettverk og samme strømforsyning. Det oppfyller kanskje formatet «to navn», men gir svak reell redundans.

Alle autoritative servere må være enige

Resolveren kan spørre hvilken som helst av navnetjenerne i delegeringen. Hvis de gir forskjellige svar, blir feilen tilfeldig fra brukerens perspektiv.

Eksempler:

• én server har gammel A-post og sender trafikk til forrige webhotell
• én mangler en MX-post og gjør e-postlevering ustabil
• bare noen servere har den nye DKIM-posten
• én server svarer med NXDOMAIN for et navn de andre kjenner
• SOA-versjonen ble ikke overført til sekundærserveren

Ved planlagte endringer kan det være et kort vindu mens en sone distribueres. Vedvarende forskjeller tyder på en synkroniserings-, publiserings- eller delegeringsfeil.

Sammenlign samme spørsmål mot hver autoritative server:

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

dig @ns1.leverandor.no www.eksempel.no A +norecurse
dig @ns2.leverandor.no www.eksempel.no A +norecurse

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

Kontroller statuskoden, at svaret er autoritativt, og at postsettene er de forventede. En SOA-serial er nyttig for tradisjonell primær/sekundær-synkronisering, men riktig serienummer alene beviser ikke at alle postene eller DNSSEC-signaturene er korrekte.

Delegeringen og sonen er to ulike steder

Navnetjenerne finnes i to sammenhenger:

1. Norid publiserer en delegering i .no-sonen.
2. Domenets egne autoritative navnetjenere publiserer NS-poster i domenesonen.

Settene bør være konsistente. Hvis Norid peker til en gammel server som sonen ikke lenger anser som autoritativ, eller sonen annonserer en server som ikke finnes i delegeringen, kan oppslag og diagnostikk bli uforutsigbar.

Se delegeringen fra .no og følg hele kjeden:

dig eksempel.no NS +trace

Se deretter NS-postene en autoritativ server publiserer i selve sonen:

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

Et vanlig oppslag via en rekursiv resolver kan skjule forskjellen på grunn av cache. Spør derfor både foreldresonen og de autoritative serverne når et navnetjenerbytte ser tilfeldig ut.

Når navnetjeneren ligger under domenet selv

Hvis eksempel.no bruker ns1.eksempel.no som navnetjener, oppstår et avhengighetsproblem: For å finne IP-adressen til ns1.eksempel.no må resolveren allerede kunne slå opp informasjon under eksempel.no.

Dette løses med en limpost, ofte kalt glue record, i foreldresonen. Norid krever minst én registrert IPv4-adresse for en slik navnetjener når den trenger limpost, og kontrollerer at registrerte IPv4- og IPv6-adresser stemmer med svarene fra serveren.

Limposten er ikke en vanlig A-post som bare kan endres i domenets DNS-panel. Registraren må oppdatere navnetjenerobjektet hos Norid. Etter endringen bør både limdata i delegeringen og A-/AAAA-svarene fra sonen kontrolleres.

Les Norids beskrivelse av basistestene før dere setter opp egne navnetjenere under samme domene.

Én leverandør eller flere?

For de fleste små og mellomstore bedrifter er én moden DNS-leverandør med distribuert infrastruktur et tryggere valg enn to paneler som må holdes like manuelt.

Én leverandør passer ofte når

• leverandøren har dokumentert redundant eller anycast-basert drift
• DNS-endringer er sjeldne
• én publiseringsmekanisme reduserer konfigurasjonsfeil
• virksomheten ikke har et krav om leverandøruavhengighet

Flere leverandører kan være riktig når

• DNS er en kritisk avhengighet med egne tilgjengelighetskrav
• leverandørfeil er en eksplisitt del av trusselmodellen
• virksomheten kan overvåke svar fra hver leverandør
• sonen replikeres gjennom en kontrollert mekanisme
• DNSSEC og hendelseshåndtering er utformet for flerleverandørdrift

To separate kontrollpaneler der noen må kopiere hver post manuelt, er ikke en robust arkitektur. Det er to muligheter for menneskelig feil.

En vanlig modell er én skjult eller synlig primær som overfører sonen til sekundære servere med AXFR/IXFR og TSIG, eller en leverandørstøttet multi-primary-løsning. Guiden til sekundær DNS går gjennom valg av modell, overføring, katalogsoner, varsling og failover.

DNSSEC gjør flerleverandørdrift vanskeligere

Med DNSSEC må de autoritative serverne publisere en konsistent, validerbar sone, og DS-data i .no må passe signeringsoppsettet. To leverandører kan ikke bare signere hver sin tilfeldige variant av sonen.

En flerleverandørløsning trenger en avtalt modell for:

• hvem som signerer sonen
• hvilke DNSKEY-er som publiseres
• hvilke DS-poster registraren sender til Norid
• hvordan nøkkelbytte koordineres
• hvordan en leverandør fjernes uten valideringsbrudd
• hvordan signaturutløp overvåkes

Ikke aktiver eller flytt DNSSEC midt i et navnetjenerbytte uten en konkret overgangsplan. Et usignert domene kan fortsatt svare, mens et signert domene med brutt tillitskjede kan bli avvist av validerende resolvere.

Hvor mange bør dere bruke?

For .no er svaret minst to. Mange leverandører bruker to til fire navnetjenernavn. Flere navn er ikke automatisk bedre, fordi hvert ekstra endepunkt må:

• være riktig registrert i delegeringen
• svare autoritativt på UDP og TCP
• ha oppdaterte og konsistente sonedata
• inngå riktig i DNSSEC-modellen
• overvåkes og kunne håndteres under en hendelse

Velg antallet som følger leverandørens støttede arkitektur. Ikke legg til en tilfeldig ekstra server bare for å få et høyere tall.

Kontroller oppsettet uten å stole på kontrollpanelet

Bruk denne rekkefølgen:

1. Slå opp NS-delegeringen fra .no.
2. Finn IP-adressene til hvert navnetjenernavn.
3. Spør hver server direkte om SOA, NS og kritiske posttyper.
4. Test både UDP og TCP der verktøyet støtter det.
5. Sammenlign A, AAAA, MX og viktige TXT-poster.
6. Valider DNSSEC fra en ekstern resolver hvis domenet er signert.
7. Test fra mer enn ett nettverk eller en ekstern måletjeneste.
8. Kontroller igjen etter TTL-vinduet og etter større endringer.

En navnetjener kan svare på ping og likevel ikke levere autoritative DNS-svar. Et grønt kontrollpanel kan også vise ønsket konfigurasjon før den er publisert. Test den offentlige tjenesten som brukerne faktisk møter.

Før dere endrer navnetjenere

Et navnetjenerbytte flytter ansvaret for hele DNS-sonen. Eksporter eller dokumenter alle postene først, bygg sonen hos ny leverandør, og kontroller svarene før registraren endrer delegeringen.

Behold gammel DNS aktiv gjennom overgangsperioden. Da kan resolvere som fortsatt har gammel delegering i cache, få de samme svarene som dem som allerede bruker den nye.

Følg den trinnvise guiden til å endre navnetjenere uten å miste e-post . Har dere domenet hos Vymo, håndteres registerendringen manuelt gjennom kontakt med oss; Vymo har ikke et selvbetjent DNS-panel.