Nameserver

En nameserver er en server i DNS, som kan svare på spørgsmål om et domænes poster. Når nogen vil besøge en hjemmeside eller sende en e-mail, hjælper DNS med at finde den IP-adresse eller tjeneste, som domænet skal føre til.

Et domæne har normalt to eller flere autoritative nameservere registreret hos domæneregistratoren. De kan eksempelvis hedde ns1.udbyder.dk og ns2.udbyder.dk. De fortæller andre DNS-servere, hvor den gældende zone for domænet findes.

Nameserveren er ikke nødvendigvis det samme som webserveren. Webserveren leverer hjemmesiden. Nameserveren leverer oplysninger om, hvor hjemmesiden, mailen og andre tjenester findes. Derfor kan et website ligge hos én udbyder, e-mail hos en anden og DNS hos en tredje.

Begrebet bliver ofte blandet sammen med hosting og selve domænet. Domænet er navnet, hosting er pladsen eller tjenesten, og nameserverne er en del af vejvisningen. De kan være samlet hos samme firma, men funktionerne er stadig forskellige.

Et nameserverskift er en stor ændring, fordi hele DNS-zonen normalt flyttes til en ny autoritativ udbyder. Det er ikke blot en ændring af hjemmesidens IP. Hvis poster mangler i den nye zone, kan mail, underdomæner, verifikationer og eksterne systemer holde op med at virke.

Før et skift skal den eksisterende DNS-zone kortlægges. Gem A- og AAAA-poster, CNAME, MX-records, TXT-poster, SRV-poster og eventuelle underdomæner. Tag ikke kun et screenshot af de første fem linjer. Eksportér zonen eller skriv alle værdier ned.

Opret posterne hos den nye DNS-udbyder, før registratoren ændres, hvis udbyderen tillader det. Kontrollér især mailrelaterede poster som MX, SPF, DKIM og DMARC. En ny zone, der kun indeholder websitets A-record, er ikke en komplet kopi.

Sænk eventuelt TTL på vigtige poster i god tid før flytningen. TTL angiver, hvor længe svar kan gemmes i cache. En lavere værdi kan gøre et planlagt skift hurtigere, men ændringen skal selv nå at slå igennem, før den hjælper.

Foretag skiftet på et tidspunkt, hvor ansvarlige personer kan teste både hjemmeside, formularer og e-mail. Send mails ind og ud, test flere underdomæner, og kontrollér certifikatet på HTTPS. Et grønt flueben i domænepanelet er ikke en fuld funktionsprøve.

Brug offentlige DNS-opslag til at se, hvilke nameservere og poster forskellige resolvere får. Propagation er ikke en mystisk proces, der altid tager 48 timer. Det afhænger af caches, TTL og registreringsniveau, men forskellige brugere kan i en periode få forskellige svar.

Dokumentér, hvem der ejer DNS-adgangen. Når bureau, it-leverandør og kunde hver tror, at en anden har login, bliver en akut ændring unødigt vanskelig. Domænet og DNS bør stå i virksomhedens navn med kontrolleret adgang.

En virksomhed får bygget en ny hjemmeside. Den gamle leverandør har både webhosting, DNS og mail. Den nye webudbyder beder om at få nameserverne ændret til sine egne. Kunden gør det straks, og den nye hjemmeside virker efter en time.

Næste morgen opdager medarbejderne, at ingen e-mails er kommet ind. Den nye DNS-zone indeholder en A-record til hjemmesiden, men ikke de gamle MX-poster til Microsoft 365. Desuden mangler SPF og DKIM. Webdelen virker, fordi den ene nødvendige post blev oprettet; maildelen har mistet sin vejviser.

Fejlen rettes ved at tilføje de korrekte mailposter. Nogle afsenderes DNS-cache bruger dog stadig den tidligere mangelfulde zone, så levering er ustabil i flere timer. En kontrolleret kopi før skiftet ville have undgået hele problemet.

En bedre løsning kunne også have været at beholde de eksisterende nameservere og blot ændre A-recorden til den nye hjemmeside. Det afhænger af ejerskab og fremtidig drift. Et komplet nameserverskift er kun nødvendigt, hvis DNS faktisk skal flyttes.

På en international løsning kan en CDN eller sikkerhedstjeneste kræve, at nameserverne peger til tjenesten, fordi den skal styre hele DNS-laget. Her er skiftet legitimt, men den samme grundige kopiering og test er stadig nødvendig.

Den største faldgrube er at tro, at nameserverne kun vedrører hjemmesiden. De styrer hele domænets autoritative DNS. En “hurtig webflytning” kan derfor ramme mail, VPN, kundelogin, nyhedsbrev, betalingsverifikation og andre systemer, ingen tænkte på.

En anden fejl er at oprette en skjult afhængighed til bureauets konto. Hvis nameserverne ligger i en konto, kunden ikke ejer eller kan tilgå, bliver et fremtidigt leverandørskifte vanskeligt. Kunden bør have dokumenteret ejerskab og mulighed for at flytte løsningen.

Pas også på stavefejl og afsluttende punktummer i DNS-paneler. Nogle systemer tilføjer domænet automatisk, andre forventer et fuldt navn. En forkert CNAME kan ende som mail.firma.dk.firma.dk. Læs udbyderens format og kontrollér det offentlige svar.

Endelig kan man forveksle ændring af nameserver med ændring af en enkelt post. Det første flytter ansvaret for hele zonen. Det andet justerer én destination. Vælg den mindst omfattende ændring, der løser opgaven.

DNS er distribueret. Autoritative nameservere leverer det officielle svar for zonen, mens rekursive resolvere hos internetudbydere og offentlige tjenester finder og cacher svarene for brugeren. Derfor kan ændringer opleves forskelligt i en overgang.

To nameservere giver redundans, men de skal levere samme zone. Det er ikke en backup, hvis den ene har gamle poster. Professionelle DNS-udbydere synkroniserer normalt dette automatisk.

En nameserver kan være “skjult master” eller del af avancerede opsætninger, men almindelige virksomheder møder oftest blot de autoritative NS-navne i domænepanelet. Det vigtigste er at vide, hvem der administrerer dem, og hvad zonen indeholder.

DNSSEC kan beskytte mod manipulation af DNS-svar, men kræver korrekt samspil mellem registrator og DNS-udbyder. Ved flytning skal DNSSEC håndteres i rigtig rækkefølge, ellers kan domænet blive utilgængeligt, selv om posterne ser korrekte ud.

Vores forklaring af HTTP og HTTPS handler om forbindelsen til webserveren. Nameserveren kommer tidligere i kæden: først skal navnet oversættes til den rigtige destination, derefter kan den sikre webforbindelse oprettes.

Før et bureau overtager DNS, bør det aftales, hvad der sker ved samarbejdets ophør. En eksport af zonen, dokumenteret adgang og en navngiven kontaktperson gør et skifte kontrollerbart. Teknisk drift bør ikke bruges som en skjult binding af kunden.

Underdomæner er lette at overse. Support, webshop, kundeportal, tracking og staging kan have egne poster. En zonekopi bør derfor ikke kun kontrollere det nøgne domæne og www. Test de navne, som medarbejdere og kunder faktisk bruger.

Nogle tjenester verificerer ejerskab med TXT- eller CNAME-poster. Hvis de forsvinder ved et nameserverskift, stopper tjenesten måske ikke med det samme, men en senere kontrol kan fejle. Bevar posterne, indtil det er dokumenteret, at de ikke længere er nødvendige.

Når en DNS-udbyder har proxyfunktioner, kan en orange sky eller lignende ændre mere end selve DNS-svaret. Trafikken kan gå gennem udbyderens netværk, hvilket påvirker certifikater, cache og fejlsøgning. Dokumentér derfor også proxy-status, ikke kun postens værdi.

Ved fejl bør man skelne mellem registratorens delegation og selve zoneindholdet. Hvis registratoren peger på forkerte nameservere, bliver den korrekte zone aldrig spurgt. Hvis delegationen er korrekt, men A- eller MX-posten er forkert, ligger fejlen i zonen. De to niveauer kræver forskellige rettelser.

Et såkaldt glue record kan være nødvendigt, når en nameserver ligger under det domæne, den selv skal svare for, eksempelvis ns1.firma.dk for firma.dk. Almindelige kunder møder sjældent opsætningen, men den forklarer, hvorfor nameserverændringer nogle gange også indeholder IP-adresser hos registratoren.

Lav en sidste kontrol nogle dage efter flytningen. Midlertidige caches kan skjule fejl under den første test, og enkelte systemer bruges måske kun ugentligt. Gennemgå formularer, mail, underdomæner og verifikationer igen, når den gamle DNS ikke længere forventes at være i omløb.

Ved flytning af en webshop skal betalingswebhooks, ordre-mails og eventuelle separate checkout-domæner med i kontrollen. DNS-fejl kan derfor ramme mere end den synlige forside.