Hvad er DNS, og hvordan fungerer det?

IPAddress-Lookup.com · June 28, 2025

Hver gang du indtaster et webstedsnavn i din browser, træder et usynligt system i aktion for at finde ud af, hvor det pågældende websted rent faktisk befinder sig. Dette system kaldes Domain Name System, eller DNS, og det er en af de vigtigste dele af infrastrukturen på internettet. Uden det ville du være nødt til at huske lange talrækker for hver eneste hjemmeside, du besøger, i stedet for brugervenlige navne som example.com. I denne guide vil vi forklare præcis, hvad DNS er, gennemgå en reel opslagsproces fra start til slut, beskrive alle de vigtigste rekordtyper og vise dig, hvordan du selv kan kontrollere og fejlfinde DNS.

Hvad er DNS?

DNS er internettets telefonbog. Computere kommunikerer ikke ved hjælp af navne, der kan læses af mennesker; de kommunikerer ved hjælp af numeriske adresser. Når du vil ringe til en ven, ringer du ikke op til vedkommendes navn, men til vedkommendes nummer, men du husker sandsynligvis navnet og lader din kontaktliste oversætte det til cifre. DNS gør det samme for internettet: det oversætter et domænenavn, som mennesker kan huske, f.eks. www.example.com, til den numeriske IP-adresse, som maskiner faktisk bruger til at dirigere trafikken, f.eks. 93.184.216.34 for IPv4 eller en længere hexadecimal streng for IPv6.

Denne oversættelse er vigtig, fordi IP-adresser ændrer sig. En hjemmeside kan flytte til en ny server, skifte hostingudbyder eller sprede sit indhold på snesevis af datacentre rundt om i verden. Navne giver os en stabil, letgenkendelig betegnelse, der forbliver den samme, selv når den underliggende adresse flytter. DNS er det lag, der indfrier dette løfte ved at omdanne navne til adresser milliarder af gange i sekundet over hele kloden. Det er også et distribueret system, hvilket betyder, at ingen enkelt computer rummer hele telefonbogen. I stedet er ansvaret fordelt på et omfattende hierarki af servere, hvilket netop er det, der gør DNS hurtigt, robust og i stand til at skalere til hele kloden.

De aktører, der er involveret i en DNS-opslag

Før vi sporer en forespørgsel, er det en god idé at stifte bekendtskab med aktørerne. Hver har en specifik opgave, og en enkelt opslagsforespørgsel kan berøre dem alle:

• Stub-resolver — det lille stykke software, der er indbygget i dit operativsystem. Når et program har brug for en adresse, videresender stub-resolveren anmodningen. Den tænker stort set ikke selv.
• Rekursiv resolver — arbejdshesten, som normalt drives af din internetudbyder eller en offentlig udbyder, såsom en velkendt 8.8.8.8- eller 1.1.1.1-tjeneste. Den modtager din forespørgsel og udfører alt det nødvendige benarbejde for at finde det endelige svar, hvorefter den sender det tilbage til dig.
• Root-navneservere — toppen af hierarkiet. De kender ikke adressen på nogen hjemmesider, men de ved, hvor de kan finde de servere, der er ansvarlige for hvert topniveaudomæne.
• TLD-navneservere — ansvarlige for et topniveaudomæne som .com, .org eller .net. De ved, hvilke autoritative servere der håndterer hvert domæne, der er registreret under dem.
• Autoritative navneservere — den endelige kilde til sandheden. Disse servere indeholder de faktiske poster for et bestemt domæne og giver det endelige svar.

Sporing af en reel forespørgsel: opløsning af www.example.com

Lad os følge en enkelt forespørgsel trin for trin. Forestil dig, at du skriver www.example.com i din browser og trykker på Enter. Her er, hvad der sker bag kulisserne, forudsat at der endnu ikke er noget i cachen:

1. Browseren spørger stub-resolveren. Dit operativsystems stub-resolver modtager forespørgslen om www.example.com. Den tjekker først sin egen lokale cache. Hvis den for nylig har slået dette navn op, returnerer den svaret med det samme, og rejsen slutter her.
2. Stub-resolveren kontakter den rekursive resolver. Da der ikke er noget svar i cachen, videresender stub-resolveren forespørgslen til din konfigurerede rekursive resolver.
3. Den rekursive resolver forespørger en rodserver. Den rekursive resolver ved endnu ikke, hvor .com befinder sig, så den spørger en af rodserverne. Rodserveren kender ikke www.example.com, men svarer med en henvisning: »Jeg har ikke det svar, men her er de servere, der er ansvarlige for .com.«
4. Den rekursive resolver forespørger .com-TLD-serveren. Efter denne henvisning spørger resolveren en .com-TLD-server om www.example.com. TLD-serveren svarer med endnu en henvisning: »Jeg kender ikke adressen, men her er de autoritative navneservere for example.com.«
5. Den rekursive resolver forespørger den autoritative server. Til sidst spørger resolveren den autoritative navneserver for example.com. Denne server har de egentlige poster og svarer endeligt: »www.example.com findes på 93.184.216.34.«
6. Svaret sendes tilbage til dig. Den rekursive resolver gemmer dette svar i cachen, videregiver det til din stub-resolver, og din browser opretter en forbindelse til den pågældende IP-adresse. Hele processen afsluttes typisk på få tiendedele af et millisekund.

Rekursive kontra iterative forespørgsler

Gennemgangen ovenfor illustrerer to forskellige forespørgselsmetoder, og at forstå forskellen fjerner en masse forvirring. Når din enhed stiller et spørgsmål til den rekursive resolver, forventer den et komplet, endeligt svar. Det er en rekursiv forespørgsel: resolveren påtager sig ansvaret for at gøre, hvad der skal til for at returnere et fuldstændigt resultat. Din enhed læner sig tilbage og venter.

De samtaler, som den rekursive resolver har med rod-, TLD- og autoritative servere, er iterative forespørgsler. Ingen af disse servere søger svaret på dine vegne. I stedet svarer de med de bedste oplysninger, de har, hvilket normalt er en henvisning, der peger et skridt tættere på destinationen. Den rekursive resolver gentager derefter processen og går iterativt ned gennem hierarkiet, indtil den når frem til et autoritativt svar. Kort sagt: din enhed spørger rekursivt, og resolveren arbejder iterativt.

Caching og TTL på hvert lag

Hvis hver eneste forespørgsel skulle rejse hele vejen til en autoritativ server, ville internettet være smerteligt langsomt, og rodserverne ville bryde sammen under belastningen. Caching forhindrer det. På næsten hvert lag gemmes svarene midlertidigt, så de kan genbruges. Din browser cacher, dit operativsystem cacher, og den rekursive resolver cacher i stor stil.

Hvor længe en post må caches, styres af dens TTL (time to live), der måles i sekunder og indstilles af domæneejeren. En post med en TTL på 3600 kan caches i en time, før en resolver skal hente en ny kopi. Korte TTL’er giver dig mulighed for hurtigt at ændre poster, hvilket er praktisk under en servermigrering, men de øger forespørgselsmængden. Lange TTL’er forbedrer ydeevnen og reducerer belastningen, men betyder, at ændringer tager længere tid at sprede sig over hele verden. Derfor sænker administratorer ofte en posts TTL en dag før en planlagt ændring og hæver den igen bagefter.

DNS-hierarkiet og rodserverne

DNS er organiseret som et omvendt træ. Helt øverst sidder roden, der skrives som en enkelt prik, som normalt er usynlig. Under roden findes topniveaudomænerne, såsom .com, .org og landekoder som .uk eller .de. Under hvert TLD findes andenniveaudomænerne, som enkeltpersoner og organisationer registrerer, f.eks. example.com. Under disse findes underdomæner som f.eks. www eller mail. Når man læser et domænenavn fra højre mod venstre, bevæger man sig ned gennem hierarkiet fra det generelle til det specifikke.

Roden betjenes af et system, der er kendt som de »13 rodservere«. I virkeligheden er der tale om 13 navngivne klynger, mærket A til M, som hver især drives af en anden organisation. Bag hver af disse 13 adresser står der hundredvis af fysiske servere fordelt over hele verden ved hjælp af en teknik kaldet anycast, som dirigerer din anmodning til den nærmeste tilgængelige instans. Det er sådan, at en håndfuld navngivne indgangspunkter pålideligt kan besvare hele klodens forespørgsler med lav ventetid og høj modstandsdygtighed over for nedbrud og angreb.

Forklaring af DNS-posttyper

Et domænes DNS-zone er en samling af poster, og hver posttype tjener et bestemt formål. Det er afgørende at forstå dem for alle, der driver en hjemmeside eller administrerer e-mail. Tabellen nedenfor opsummerer de vigtigste typer med et eksempel på hver.

A- og AAAA-poster

Disse er de vigtigste elementer, der forbinder navne med adresser. En A-post peger på en IPv4-adresse, mens en AAAA-post peger på en IPv6-adresse. Et domæne kan have begge dele, så klienter på begge protokoller kan nå det. Når din browser spørger "hvor er example.com", er det som regel en af disse to poster, der giver det endelige svar.

CNAME-poster

En CNAME opretter et alias, der videresender et navn til et andet kanonisk navn. Den bruges ofte til at pege www på det rene domæne eller til at pege et brugerdefineret underdomæne på en hostingudbyders adresse. En vigtig regel er, at en CNAME ikke kan eksistere sammen med andre poster under det samme navn, hvilket er grunden til, at roden af et domæne normalt bruger A- eller AAAA-poster i stedet for en CNAME.

MX- og e-mail-poster

MX-poster fortæller omverdenen, hvilke servere der modtager e-mail til dit domæne, med et prioritetsnummer, der bestemmer rækkefølgen, hvori de afprøves. Lavere tal foretrækkes, så en server med prioritet 10 afprøves før en med prioritet 20. Men MX-poster er kun en del af e-mailens DNS-historie.

TXT-poster: SPF, DKIM og DMARC

TXT-poster gemmer tekst i fri form, og e-mailverdenen er stærkt afhængig af dem til tre indbyrdes forbundne autentificeringsmekanismer. SPF angiver de servere, der har tilladelse til at sende e-mail på vegne af dit domæne, hvilket hjælper modtagerne med at afvise forfalskninger. DKIM offentliggør en kryptografisk offentlig nøgle, så modtagerne kan verificere, at en besked er signeret af dit domæne og ikke er blevet ændret undervejs. DMARC binder de to sammen og fortæller modtagerne, hvad de skal gøre med beskeder, der ikke består SPF- eller DKIM-kontrollen, og hvor de skal sende rapporter. Tilsammen udgør de rygraden i moderne e-mail-leverbarhed.

NS- og SOA-poster

NS-poster delegerer autoritet og angiver de servere, der er ansvarlige for en zone. SOA-posten befinder sig øverst i hver zone og indeholder administrative oplysninger såsom den primære navneserver, den ansvarlige kontaktperson, et serienummer, der ændres, når zonen redigeres, samt timere, der styrer, hvordan sekundære servere opdaterer deres kopier af zonen.

CAA- og PTR-poster

En CAA-post begrænser, hvilke certifikatmyndigheder der har tilladelse til at udstede certifikater til dit domæne, hvilket tilføjer et ekstra beskyttelseslag mod uautoriserede certifikater. Hvis du vil forstå, hvordan disse certifikater sikrer din trafik, kan du læse vores guide til SSL-certifikater. En PTR-post håndterer omvendt DNS og knytter en IP-adresse til et værtsnavn, hvilket ofte kontrolleres af mailservere for at vurdere afsenderens legitimitet.

DNS og e-mail-leverbarhed

DNS er uden tvivl lige så vigtigt for e-mail som for internettet. Når en mailserver skal levere en besked til dit domæne, slår den dine MX-poster op for at finde den rigtige destination. Når en modtagende server skal afgøre, om en indgående besked er troværdig, tjekker den dine SPF-, DKIM- og DMARC-poster og verificerer ofte også afsenderserverens PTR-post. Hvis nogen af disse mangler eller er forkert konfigureret, kan legitime e-mails ende i spam-mapper eller blive afvist direkte. At sikre, at dine DNS-e-mail-poster er korrekte, er en af de mest effektive foranstaltninger, du kan træffe for at sikre, at dine meddelelser havner i indbakken i stedet for at forsvinde i en spam-mappe.

DNS-sikkerhed

Da DNS er så grundlæggende, er det blevet et mål for angreb, og der findes flere teknologier til at styrke det:

• DNSSEC tilføjer kryptografiske signaturer til DNS-poster, så resolverne kan verificere, at et svar virkelig stammer fra den autoritative kilde og ikke er blevet manipuleret. Det beskytter dataintegriteten, men krypterer ikke dataene.
• DNS over HTTPS (DoH) og DNS over TLS (DoT) krypterer kommunikationen mellem din enhed og den rekursive resolver. Traditionelt blev DNS-forespørgsler sendt i klartekst, hvilket gjorde det muligt for enhver på netværksstien at se og endda ændre dem. DoH og DoT lukker dette hul ved at indkapsle forespørgslerne i kryptering.
• Cache-forgiftning er et klassisk angreb, hvor en ondsindet aktør narrer en resolver til at gemme et falsk svar i cachen og dermed omdirigere ofrene til en svigagtig server. DNSSEC og moderne beskyttelsesmekanismer for resolvere, såsom tilfældige kildeporte, gør dette angreb langt sværere at gennemføre.

Almindelige DNS-problemer og fejlfinding

Når en hjemmeside ikke vil indlæses, er DNS ofte synderen. Nogle af de hyppigste problemer omfatter:

• Propageringsforsinkelser. Når du ændrer en post, kan gamle cachelagrede værdier forblive, indtil deres TTL udløber. Derfor kan en ændring være synlig for dig, men endnu ikke for andre.
• Stavefejl og manglende poster. Et forkert stavet værtsnavn eller en glemt A-post fører til fejl, der er lette at overse.
• Uoverensstemmende navneservere. Hvis din registrator peger domænet mod de forkerte navneservere, vil ingen af dine omhyggeligt udarbejdede poster nogensinde blive konsulteret.
• Konflikter mellem CNAME-poster. Hvis du placerer en CNAME-post sammen med andre poster under det samme navn, forstyrrer det navneopløsningen.
• Cache i resolveren. Nogle gange er problemet en forældet post i din egen enhed eller router, hvilket løses ved at tømme cachen.

Sådan tjekker du selv DNS-poster

Du behøver ikke at være netværksingeniør for at slå DNS-poster op. Kommandolinjeværktøjer som dig og nslookup, der findes på de fleste systemer, giver dig mulighed for at forespørge på enhver posttype direkte. Hvis du f.eks. forespørger på A-posten for et domæne, får du dets IPv4-adresse, mens en forespørgsel på MX-posterne afslører dets mailservere. Hvis du ikke foretrækker kommandolinjen, kan du med et online DNS-opslagsværktøj søge på ethvert domænes poster fra din browser uden at skulle installere software, hvilket gør det nemt at bekræfte, om en nylig ændring er blevet videreformidlet, eller at diagnosticere en forkert konfiguration.

Når du vænner dig til at tjekke DNS-poster, bliver hele systemet meget mere overskueligt. Så snart du kan se A-, MX- og TXT-posterne for dit eget domæne, bliver den abstrakte telefonbog til et konkret og forståeligt sæt poster, som du selv har kontrol over. Derfra bliver det at diagnosticere en langsom hjemmeside, en returneret e-mail eller en certifikatadvarsel blot et spørgsmål om at læse oplysningerne i stedet for at gætte.

Ofte stillede spørgsmål

Hvad står DNS for?

DNS står for Domain Name System. Det er det distribuerede system, der oversætter menneskeligt læselige domænenavne til de numeriske IP-adresser, som computere bruger til at kommunikere med hinanden.

Hvorfor kaldes DNS for internettets telefonbog?

Ligesom en telefonbog lader dig slå en persons telefonnummer op ud fra vedkommendes navn, lader DNS din computer slå en hjemmesides IP-adresse op ud fra dens domænenavn. Du husker det nemme navn, og DNS klarer oversættelsen til det tal, maskinerne rent faktisk har brug for.

Hvor lang tid tager det, før ændringer i DNS træder i kraft?

Det afhænger af postens TTL og af, hvor aggressivt resolverne langs ruten har cachelagret den. Ændringer kan vises inden for få minutter, hvis TTL'en er kort, men det kan tage op til 24 til 48 timer, før de er fuldt ud spredt over hele verden, når ældre cachelagrede værdier stadig er i brug.

Hvad er forskellen mellem en rekursiv resolver og en autoritativ server?

En rekursiv resolver udfører det praktiske arbejde med at finde et svar ved at forespørge andre servere på dine vegne og gemme resultatet i cachen. En autoritativ server er den endegyldige kilde, der rent faktisk indeholder et domænes poster og giver det endelige svar.

Er DNS krypteret?

Traditionelt DNS er ikke krypteret, hvilket betyder, at forespørgsler sendes i klartekst. Nyere standarder såsom DNS over HTTPS og DNS over TLS krypterer trafikken mellem din enhed og resolveren, mens DNSSEC tilføjer signaturer, der verificerer svarens ægthed.

Hvordan kan jeg tjekke DNS-posterne for et domæne?

Du kan bruge kommandolinjeværktøjer som dig eller nslookup eller en browserbaseret DNS-opslagstjeneste. Disse giver dig mulighed for at anmode om specifikke posttyper såsom A, AAAA, MX og TXT, så du kan kontrollere konfigurationen eller fejlfinde problemer.