Egendefinerte navnetjenere – private nameservere uten falsk trygghet

Egendefinerte navnetjenere, også kalt private nameservere, bruker virksomhetens eget domene i stedet for DNS-leverandørens navn. Kundene delegerer for eksempel til ns1.dnsfirma.no og ns2.dnsfirma.no.

Dette kan gi et ryddig, hvitmerket uttrykk for et webhotell eller byrå. Det gir ikke automatisk bedre oppetid, sikkerhet eller ytelse. De egendefinerte navnene må fortsatt ende hos autoritative DNS-tjenere som svarer riktig og tåler feil.

Tre oppsett som ofte blandes sammen

Leverandørens vanlige navnetjenere

Kunden bruker navn som leverandøren har tildelt, for eksempel:

ns1.dnsleverandor.example
ns2.dnsleverandor.example

Leverandøren drifter DNS-plattformen og navneinfrastrukturen. Dette er som regel enklest for en vanlig bedrift.

Hvitmerkede navnetjenere hos en DNS-leverandør

Virksomheten viser egne navn, mens en ekstern DNS-plattform svarer bak dem. Det krever at plattformen uttrykkelig støtter egendefinerte navnetjenere. Dere kan ikke anta at et vanlig CNAME-oppsett er tilstrekkelig.

Tilgjengelighet og pris varierer. Cloudflares dokumentasjon for egendefinerte kontonavnetjenere oppgir for eksempel at funksjonen krever Business-avtale etter kontakt med support eller Enterprise. Dette er et produktvilkår kontrollert 22. august 2026, ikke en egenskap ved DNS-protokollen.

Egen autoritativ DNS-drift

Virksomheten drifter selv tjenere eller programvare som er autoritativ for kundesonene. Da eier dere kapasitet, oppdateringer, sonedistribusjon, overvåking, DDoS-beredskap, DNSSEC og hendelser. To navn på samme maskin er ikke reell redundans.

Velg modell før dere lager vertsnavnene. Et hvitmerket leverandøroppsett og egen DNS-drift har svært ulik risiko.

Hva er den faktiske verdien?

Egendefinerte navnetjenere kan være nyttige når dere:

• selger DNS eller webhotell under eget merkenavn
• administrerer mange kundedomener med samme prosess
• vil kunne bytte underliggende plattform uten å be alle kunder endre NS-navn
• har en DNS-leverandør som støtter oppsettet kontraktuelt og teknisk
• kan overvåke og dokumentere hele delegeringskjeden

Den mulige flyttefordelen er ikke automatisk. IP-adresser, glue, soner, DNSSEC og leverandøravtale må kunne endres uten at de egendefinerte navnene blir et nytt låsepunkt.

For én vanlig bedriftsnettside gir oppsettet sjelden verdi. Kunden får ikke høyere rangering eller mer sikker DNS fordi navnetjeneren inneholder bedriftens navn.

Glue: adressen som løser sirkelen

Anta at dittfirma.no delegeres til:

dittfirma.no. NS ns1.dittfirma.no.
dittfirma.no. NS ns2.dittfirma.no.

En resolver må kjenne IP-adressene til navnetjenerne for å spørre dem. Men IP-adressene ligger under domenet den prøver å nå. Uten ekstra adresseinformasjon oppstår en sirkel.

Derfor legges A- og eventuelle AAAA-adresser inn som glue i foreldresonen sammen med delegeringen. Registrar håndterer denne registreringen mot .no-registeret. IETF beskriver i RFC 9471 at glue for navnetjenere under delegeringspunktet gjør det mulig for resolveren å finne tjeneradressen.

Glue er ikke en egen posttype i virksomhetens vanlige soneeditor. Det er adresseinformasjon som følger delegeringen hos forelderen. Adressen må også være korrekt publisert i den autoritative sonen. Hvis parent og child viser ulike adresser, kan forskjellige resolvere få ulikt resultat.

Bruker kundedomenet kunde.no navnetjeneren ns1.dnsfirma.no, ligger navnetjeneren utenfor kunde.no. kunde.no trenger da ikke egen in-domain-glue for navnet. Den nødvendige kjeden må i stedet fungere gjennom delegeringen av dnsfirma.no.

Les hele forklaringen av glue records før dere endrer adresser.

Krav for .no-domener

Norids regelverk krever minst to navnetjenere for registrering av et .no-domene. De skal være korrekt satt opp for domenet og fungere når søknaden sendes. Det er ikke noe krav om at domeneabonnenten driver navnetjenerne selv.

Norids basistester mot navnetjenere kontrollerer blant annet at:

• navnetjeneren svarer autoritativt for domenet
• NS-settet er konsistent
• en navnetjener med glue har minst én registrert IPv4-adresse
• registrerte IPv4- og IPv6-adresser stemmer med A- og AAAA-svarene
• navnetjenerne svarer over både UDP og TCP på port 53

«Minst to» er et minimum for navn og svar, ikke bevis på uavhengighet. To tjenere kan fortsatt dele maskin, nettverk, programvare, kontrollkonto og feilmodus.

Arkitekturen bør tåle mer enn én feil

Vurder hvilke felles avhengigheter navnetjenerne har:

Anycast kan la flere noder svare fra samme tjenesteadresser, men navnet «Anycast» er heller ingen garanti. Undersøk regioner, ruting, kapasitet, kontrollplan og hendelseshistorikk. Se hvordan Anycast-DNS fungerer for å skille nettverksmodellen fra navnetjenernavnet.

DNSSEC må følge sonen, ikke merkenavnet

Egendefinerte navnetjenernavn signerer ikke DNS-svar. DNSSEC krever at sonen signeres, at riktige DNSKEY-poster publiseres, og at en samsvarende DS-post finnes i foreldresonen.

Avklar:

• hvem som genererer og beskytter signeringsnøkler
• hvem som oppdaterer DS gjennom registraren
• hvordan nøkkelbytte gjennomføres
• hva som skjer med DNSSEC ved leverandørbytte
• hvem som overvåker valideringsfeil

Et plattformbytte kan gjøre hele domenet utilgjengelig for validerende resolvere hvis gammel DS blir stående uten samsvarende nøkkel. Bruk guiden til trygg DNSSEC-drift i migreringsplanen.

Sikker administrasjon

Det mest synlige angrepspunktet er ofte ikke DNS-tjeneren, men kontoen som styrer soner, glue og delegering.

Bruk:

• navngitte brukere fremfor en delt hovedkonto
• flerfaktorautentisering der registrar og DNS-plattform tilbyr det
• roller med minst mulig tilgang
• avgrensede API-nøkler per system og miljø
• sikker lagring og planlagt rotasjon av hemmeligheter
• endringslogg og varsling for NS-, DS- og glue-endringer
• en dokumentert nødprosedyre som ikke avhenger av én person

Merkenavndomenet for navnetjenerne er kritisk infrastruktur. Fornyelse, registrar, kontaktopplysninger og tilgang bør behandles strengere enn et vanlig kampanjedomene.

Overvåk svarene resolverne faktisk får

En overvåking som bare spør én rekursiv resolver fra ett nettverk kan overse delvise feil. Test fra flere uavhengige steder og spør hver autoritativ navnetjener direkte.

Kontroller minst:

• at alle tjenere svarer autoritativt på SOA og NS
• at sonens serienummer eller data er konsistent
• at A- og AAAA-svar for navnetjenerne stemmer med registrert glue
• at UDP og TCP virker
• at DNSSEC validerer når det er aktivert
• at vanlige A-, MX- og TXT-svar er riktige
• at negative svar har forventet resultat
• responstid, tidsavbrudd og feilrate over tid

Varslet må gå til noen som kan rette delegering eller DNS-plattform. Et grønt dashbord uten vakt eller prosedyre er bare historikk.

Endre glue uten å skape et mellomrom

Ved IP-bytte må adresseinformasjonen hos forelderen og i den autoritative sonen holdes konsistent. En trygg plan er normalt å:

1. legge den nye adressen til på navnetjeneren og få tjenesten til å svare der
2. publisere samsvarende A- eller AAAA-data
3. oppdatere registrert navnetjeneradresse gjennom registraren
4. kontrollere parent, child og direkte svar fra flere nett
5. vente gjennom relevante cacheperioder
6. fjerne gammel adresse først når den ikke lenger brukes

Den nøyaktige rekkefølgen må tilpasses leverandør og registrar. Ikke flytt både navnetjenerdomene, DNS-plattform, IP-adresser og DNSSEC i ett udokumentert steg.

Utflytting og leverandørbytte

Egendefinerte navn kan gjøre et underleverandørbytte mindre synlig for kundene, men bare hvis den nye plattformen støtter samme modell. Før bytte bør dere ha:

• full soneeksport eller reproduserbar konfigurasjon
• oversikt over alle kundedomener som bruker NS-settet
• nye autoritative tjenere som er lastet og testet
• plan for glue og DNSSEC
• kontroll av skjulte leverandørfunksjoner som flattening og failover
• avtalt overlapp mellom gammel og ny tjeneste
• tilbakeføringskriterier

Standard soneformat dekker ikke nødvendigvis leverandørspesifikke regler, API-er, helsechecks eller trafikkstyring. Dokumenter dem separat.

Vanlige feil

• To navn, én IP: Ser redundant ut, men én tjenerfeil rammer begge.
• Glue bare i lokal sone: Resolveren trenger adressen fra forelderen for å bryte sirkelen.
• Ulike adresser hos parent og child: Gir uforutsigbar cache og delvise feil.
• Vanlig CNAME som hvitmerking: Navnetjeneroppsett må støttes av DNS-plattformen og delegeringen.
• Glemt merkenavndomene: Utløp kan ramme alle kundedomener som bruker navnene.
• DNSSEC flyttes uten DS-plan: Kan gjøre korrekte DNS-svar ugyldige.
• Ingen utflyttingstest: Hvitmerking kan skjule en sterk leverandørlåsing.

Sjekkliste før oppsett

1. Har vi et reelt forretningsbehov utover utseendet?
2. Støtter DNS-leverandøren egendefinerte navnetjenere i avtalen vår?
3. Hvem registrerer og oppdaterer glue?
4. Oppfyller alle tjenere Norids tester for hvert .no-domene?
5. Hvilke felles feil kan stoppe hele NS-settet?
6. Hvem eier sonedistribusjon, DNSSEC og hendelser?
7. Overvåker vi parent, child og autoritative svar fra flere nett?
8. Kan alle soner og leverandørfunksjoner flyttes ut?
9. Hvordan sikres kontrollkontoer og API-nøkler?
10. Hvem kan handle når DNS feiler utenfor arbeidstid?

Hva tilbyr Vymo?

Vymos publiserte standardtilbud omfatter .no-domene, én enkel bedriftsside og e-post. Det lover ikke hvitmerkede navnetjenere, kundestyrt DNS-forhandlerpanel, egen autoritativ DNS-infrastruktur eller drift av private nameservere.

For en vanlig virksomhet er leverandørens stabile standardnavnetjenere normalt riktig. Trenger dere egendefinerte navn for mange kundedomener, må plattform, soneantall, DNSSEC, API, overvåking og utflytting vurderes som en egen DNS-leveranse.

Skal virksomheten bare registrere et .no-domene, kan dere søke etter et ledig navn . Vymo tar foreløpig bare imot domenebestillinger fra virksomheter i Brønnøysundregistrene og behandler bestillingen manuelt.

Egendefinerte navnetjenere er et merkevarelag over kritisk infrastruktur. Bruk dem når dere kan drifte hele kjeden bedre — ikke bare fordi ns1.dittfirma.no ser ryddig ut.