Vad är DNS och hur fungerar det?

IPAddress-Lookup.com · June 28, 2025

Varje gång du skriver in ett webbplatsnamn i din webbläsare sätts ett osynligt system i gång för att ta reda på var webbplatsen faktiskt finns. Det systemet kallas Domain Name System, eller DNS, och är en av de viktigaste delarna av infrastrukturen på internet. Utan det skulle du behöva memorera långa sifferserier för varje webbplats du besöker istället för lättminnesbara namn som example.com. I den här guiden kommer vi att förklara exakt vad DNS är, följa en verklig sökning från början till slut, gå igenom alla viktiga posttyper och visa dig hur du själv kan kontrollera och felsöka DNS.

Vad är DNS?

DNS är internetets telefonkatalog. Datorer kommunicerar inte med hjälp av namn som människor kan läsa; de kommunicerar med hjälp av numeriska adresser. När du vill nå en vän via telefon slår du inte upp deras namn, utan deras nummer, men du kommer förmodligen ihåg namnet och låter din kontaktlista översätta det till siffror. DNS gör samma sak för internet: det översätter ett domännamn som människor kan komma ihåg, till exempel www.example.com, till den numeriska IP-adress som maskinerna faktiskt använder för att dirigera trafiken, till exempel 93.184.216.34 för IPv4 eller en längre hexadecimal sträng för IPv6.

Denna omvandling är viktig eftersom IP-adresser ändras. En webbplats kan flytta till en ny server, byta webbhotell eller sprida sitt innehåll över dussintals datacenter runt om i världen. Namn ger oss en stabil, lättminnad etikett som förblir densamma även när den underliggande adressen flyttas. DNS är det lager som uppfyller det löftet genom att omvandla namn till adresser miljarder gånger per sekund över hela världen. Det är också ett distribuerat system, vilket innebär att ingen enskild dator innehar hela telefonkatalogen. Istället fördelas ansvaret över en omfattande hierarki av servrar, vilket är precis vad som gör DNS snabbt, motståndskraftigt och kapabelt att skala upp till att täcka hela planeten.

Aktörerna som är inblandade i en DNS-sökning

Innan vi spårar en förfrågan är det bra att lära känna aktörerna. Var och en har en specifik uppgift, och en enda sökning kan beröra dem alla:

• Stub-resolver – den lilla programvaran som är inbyggd i ditt operativsystem. När ett program behöver en adress vidarebefordrar stub-resolvern förfrågan. Den tänker knappt själv.
• Rekursiv resolver – arbetshästen, som vanligtvis drivs av din internetleverantör eller en offentlig leverantör, till exempel de välkända tjänsterna 8.8.8.8 eller 1.1.1.1. Den tar emot din fråga och utför allt nödvändigt arbete för att hitta det slutgiltiga svaret, för att sedan skicka tillbaka det till dig.
• Rotnamnservrar – toppen av hierarkin. De känner inte till adressen till någon webbplats, men de vet var de kan hitta de servrar som ansvarar för varje toppdomän.
• TLD-namnservrar – ansvarar för en toppdomän som .com, .org eller .net. De vet vilka auktoritativa servrar som hanterar varje domän som är registrerad under dem.
• Auktoritativa namnservrar – den slutgiltiga källan till sanningen. Dessa servrar innehar de faktiska posterna för en specifik domän och ger det definitiva svaret.

Spåra en verklig förfrågan: upplösning av www.example.com

Låt oss följa en enskild förfrågan steg för steg. Tänk dig att du skriver in www.example.com i din webbläsare och trycker på Enter. Här är vad som händer bakom kulisserna, förutsatt att inget har cachats ännu:

1. Webbläsaren frågar stubresolvern. Ditt operativsystems stubresolver tar emot förfrågan om www.example.com. Den kontrollerar först sin egen lokala cache. Om den nyligen har sökt efter detta namn returnerar den svaret omedelbart och resan slutar här.
2. Stub-resolvern kontaktar den rekursiva resolvern. Eftersom det inte finns något cachelagrat svar vidarebefordrar stub-resolvern förfrågan till din konfigurerade rekursiva resolver.
3. Den rekursiva resolveren frågar en rotserver. Den rekursiva resolveren vet ännu inte var .com finns, så den frågar en av rotservrarna. Rotservern känner inte till www.example.com, men svarar med en hänvisning: ”Jag har inte det svaret, men här är servrarna som ansvarar för .com.”
4. Den rekursiva resolveren frågar .com-TLD-servern. Efter den hänvisningen frågar resolveren en .com-TLD-server om www.example.com. TLD-servern svarar med en ny hänvisning: ”Jag känner inte till adressen, men här är de auktoritativa namnservrarna för example.com.”
5. Den rekursiva resolveren skickar en förfrågan till den auktoritativa servern. Slutligen frågar resolveren den auktoritativa namnservern för example.com. Denna server innehar de faktiska posterna och svarar definitivt: ”www.example.com finns på 93.184.216.34.”
6. Svaret skickas tillbaka till dig. Den rekursiva resolveren cachelagrar detta svar, vidarebefordrar det till din stub-resolver, och din webbläsare öppnar en anslutning till den IP-adressen. Hela processen tar vanligtvis bara några tiotal millisekunder.

Rekursiva kontra iterativa förfrågningar

Genomgången ovan illustrerar två olika typer av förfrågningar, och att förstå skillnaden klarar upp en hel del förvirring. När din enhet ställer en fråga till den rekursiva resolveren förväntar den sig ett fullständigt slutgiltigt svar. Det är en rekursiv förfrågan: resolveren tar på sig ansvaret att göra vad som krävs för att returnera ett fullständigt resultat. Din enhet lutar sig tillbaka och väntar.

De kommunikationer som den rekursiva resolveren har med rot-, TLD- och auktoritativa servrar är iterativa förfrågningar. Ingen av dessa servrar söker efter svaret åt dig. Istället svarar de med den bästa informationen de har, vilket vanligtvis är en hänvisning som leder ett steg närmare målet. Den rekursiva resolveren upprepar sedan processen och går stegvis nedåt i hierarkin tills den når ett auktoritativt svar. Kort sagt: din enhet frågar rekursivt, och resolveren arbetar iterativt.

Cachelagring och TTL på varje lager

Om varje sökning var tvungen att gå hela vägen till en auktoritativ server skulle internet bli smärtsamt långsamt och rotservrarna skulle kollapsa under belastningen. Cachelagring förhindrar detta. På nästan varje lager lagras svaren tillfälligt så att de kan återanvändas. Din webbläsare lagrar i cache, ditt operativsystem lagrar i cache och den rekursiva resolveren lagrar i cache i stor utsträckning.

Hur länge en post får cachas styrs av dess TTL, eller ”time to live”, som mäts i sekunder och ställs in av domänägaren. En post med en TTL på 3600 kan cachas i en timme innan en resolver måste hämta en ny kopia. Korta TTL-värden gör att du kan ändra poster snabbt, vilket är praktiskt vid en servermigrering, men de ökar volymen av förfrågningar. Långa TTL-värden förbättrar prestandan och minskar belastningen, men innebär att det tar längre tid för ändringarna att spridas över hela världen. Det är därför administratörer ofta sänker en posts TTL en dag före en planerad ändring och höjer den igen efteråt.

DNS-hierarkin och rotservrarna

DNS är organiserat som ett omvänt träd. Högst upp sitter roten, skriven som en enda punkt som vanligtvis är osynlig. Under roten finns toppdomänerna, såsom .com, .org och landskoder som .uk eller .de. Under varje toppdomän finns andranivådomänerna som privatpersoner och organisationer registrerar, till exempel example.com. Under dessa finns underdomäner som www eller mail. När man läser ett domännamn från höger till vänster går man nedåt i hierarkin från det allmänna till det specifika.

Roten betjänas av ett system som ofta beskrivs som de ”13 rotservrarna”. I själva verket är det 13 namngivna kluster, märkta A till M, som var och en drivs av en annan organisation. Bakom var och en av dessa 13 adresser finns hundratals fysiska servrar utspridda över hela världen, som använder en teknik kallad anycast, vilken dirigerar din förfrågan till den närmaste tillgängliga instansen. Det är så en handfull namngivna ingångspunkter på ett tillförlitligt sätt kan besvara hela världens förfrågningar med låg latens och hög motståndskraft mot avbrott och attacker.

Förklaring av olika typer av DNS-poster

En domäns DNS-zon är en samling poster, och varje posttyp fyller ett specifikt syfte. Att förstå dem är avgörande för alla som driver en webbplats eller hanterar e-post. Tabellen nedan sammanfattar de viktigaste typerna med ett exempel på varje.

A- och AAAA-poster

Dessa är de arbetshästar som kopplar samman namn med adresser. En A-post pekar på en IPv4-adress, medan en AAAA-post pekar på en IPv6-adress. En domän kan ha båda så att klienter som använder vilket av protokollen som helst kan nå den. När din webbläsare frågar ”var finns example.com” är det vanligtvis en av dessa två poster som ger det slutgiltiga svaret.

CNAME-poster

En CNAME skapar ett alias som vidarebefordrar ett namn till ett annat kanoniskt namn. Den används ofta för att peka www mot den rena domänen, eller för att peka en anpassad underdomän mot en webbhotellleverantörs adress. En viktig regel är att en CNAME inte kan samexistera med andra poster med samma namn, vilket är anledningen till att domänens rot vanligtvis använder A- eller AAAA-poster istället för en CNAME.

MX- och e-postposter

MX-poster anger vilka servrar som tar emot e-post för din domän, med ett prioritetsnummer som avgör i vilken ordning de testas. Lägre nummer prioriteras, så en server med prioritet 10 testas före en med prioritet 20. Men MX-poster är bara en del av e-postens DNS-historia.

TXT-poster: SPF, DKIM och DMARC

TXT-poster lagrar fritext, och e-postvärlden förlitar sig i hög grad på dem för tre sammanlänkade autentiseringsmekanismer. SPF listar de servrar som har tillstånd att skicka e-post å din domäns vägnar, vilket hjälper mottagare att avvisa förfalskningar. DKIM publicerar en kryptografisk offentlig nyckel så att mottagarna kan verifiera att ett meddelande har signerats av din domän och inte ändrats under överföringen. DMARC kopplar samman de två och talar om för mottagarna vad de ska göra med meddelanden som inte klarar SPF- eller DKIM-kontroller och vart rapporter ska skickas. Tillsammans utgör de ryggraden i modern e-postleverans.

NS- och SOA-poster

NS-poster delegerar behörighet och anger vilka servrar som ansvarar för en zon. SOA-posten finns högst upp i varje zon och innehåller administrativa uppgifter såsom den primära namnservern, den ansvariga kontakten, ett serienummer som ändras när zonen redigeras samt timers som styr hur sekundära servrar uppdaterar sina kopior av zonen.

CAA- och PTR-poster

En CAA-post begränsar vilka certifikatutfärdare som får utfärda certifikat för din domän, vilket lägger till ett extra skyddslager mot obehöriga certifikat. Om du vill förstå hur dessa certifikat skyddar din trafik kan du läsa vår guide om SSL-certifikat. En PTR-post hanterar omvänd DNS och kopplar en IP-adress till ett värdnamn, vilket ofta kontrolleras av e-postservrar för att bedöma avsändarens legitimitet.

DNS och e-postleverans

DNS är förmodligen lika viktigt för e-post som för webben. När en e-postserver vill leverera ett meddelande till din domän söker den upp dina MX-poster för att hitta rätt mottagare. När en mottagande server ska avgöra om ett inkommande meddelande är tillförlitligt kontrollerar den dina SPF-, DKIM- och DMARC-poster och verifierar ofta även avsändarserverns PTR-post. Om någon av dessa saknas eller är felkonfigurerad kan legitima e-postmeddelanden hamna i skräppostmappen eller avvisas direkt. Att se till att dina DNS-poster för e-post är korrekta är en av de åtgärder som har störst inverkan för att dina meddelanden ska hamna i inkorgen istället för att försvinna i skräppostmappen.

DNS-säkerhet

Eftersom DNS är så grundläggande har det blivit ett mål för attacker, och det finns flera tekniker för att stärka säkerheten:

• DNSSEC lägger till kryptografiska signaturer till DNS-poster så att resolverna kan verifiera att ett svar verkligen kom från den auktoritativa källan och inte har manipulerats. Det skyddar datans integritet men krypterar inte själva data.
• DNS över HTTPS (DoH) och DNS över TLS (DoT) krypterar kommunikationen mellan din enhet och den rekursiva resolveren. Traditionellt skickades DNS-förfrågningar i klartext, vilket gjorde att vem som helst längs nätverksvägen kunde se och till och med ändra dem. DoH och DoT täpper till den luckan genom att kryptera förfrågningarna.
• Cacheförgiftning är en klassisk attack där en illvillig aktör lurar en resolver att cacha ett falskt svar, vilket omdirigerar offren till en bedräglig server. DNSSEC och moderna skyddsmekanismer för resolver, såsom slumpmässiga källportar, gör denna attack betydligt svårare att genomföra.

Vanliga DNS-problem och felsökning

När en webbplats inte laddas är det ofta DNS som är orsaken. Några av de vanligaste problemen är:

• Fördröjningar i spridningen. När du ändrar en post kan gamla cachade värden finnas kvar tills deras TTL löper ut. Det är därför en ändring kan synas för dig men inte ännu för andra.
• Skrivfel och saknade poster. Ett felstavat värdnamn eller en glömd A-post leder till fel som är lätta att förbise.
• Namnservrar som inte stämmer överens. Om din registrator pekar domänen mot fel namnservrar kommer ingen av dina noggrant utformade poster någonsin att konsulteras.
• Konflikter mellan CNAME-poster. Att placera en CNAME-post tillsammans med andra poster under samma namn stör upplösningen.
• Cache i resolver. Ibland är problemet en föråldrad post i din egen enhet eller router, vilket kan lösas genom att tömma cachen.

Så här kontrollerar du DNS-poster själv

Du behöver inte vara nätverksingenjör för att söka efter DNS-poster. Kommandoradsverktyg som dig och nslookup, som finns på de flesta system, låter dig söka efter vilken posttyp som helst direkt. Om du till exempel söker efter A-posten för en domän får du tillbaka dess IPv4-adress, medan en sökning efter MX-poster visar dess e-postservrar. Om du inte föredrar kommandoraden kan du använda ett onlineverktyg för DNS-sökning för att söka efter vilken domäns poster som helst direkt från din webbläsare utan att behöva installera någon programvara. Det gör det enkelt att kontrollera om en nyligen gjord ändring har spridits eller att diagnostisera en felkonfiguration.

Att göra det till en vana att kontrollera DNS-poster gör hela systemet mer begripligt. När du väl kan se A-, MX- och TXT-posterna för din egen domän förvandlas den abstrakta telefonkatalogen till en konkret, begriplig uppsättning poster som du själv kontrollerar. Därifrån blir det enklare att diagnostisera en långsam webbplats, ett e-postmeddelande som studsat tillbaka eller en certifikatvarning genom att läsa uppgifterna istället för att gissa.

Vanliga frågor

Vad står DNS för?

DNS står för Domain Name System. Det är det distribuerade systemet som översätter läsbara domännamn till de numeriska IP-adresser som datorer använder för att kommunicera med varandra.

Varför kallas DNS för internetets telefonkatalog?

Precis som en telefonkatalog låter dig slå upp en persons telefonnummer utifrån namnet, låter DNS din dator slå upp en webbplats IP-adress utifrån dess domännamn. Du kommer ihåg det enkla namnet, och DNS sköter omvandlingen till det nummer som datorer faktiskt behöver.

Hur lång tid tar det innan DNS-ändringar träder i kraft?

Det beror på postens TTL och hur aggressivt resolverna längs vägen har cachat den. Ändringar kan synas inom några minuter om TTL är kort, men det kan ta upp till 24 till 48 timmar innan de sprids fullt ut över hela världen när äldre cachade värden fortfarande används.

Vad är skillnaden mellan en rekursiv resolver och en auktoritativ server?

En rekursiv resolver sköter arbetet med att hitta ett svar genom att fråga andra servrar å dina vägnar och cachelagra resultatet. En auktoritativ server är den definitiva källan som faktiskt innehar domänens poster och ger det slutgiltiga svaret.

Är DNS krypterat?

Traditionellt DNS är inte krypterat, vilket innebär att förfrågningar skickas i klartext. Nyare standarder som DNS över HTTPS och DNS över TLS krypterar trafiken mellan din enhet och resolveren, medan DNSSEC lägger till signaturer som verifierar svarens äkthet.

Hur kan jag kontrollera DNS-posterna för en domän?

Du kan använda kommandoradsverktyg som dig eller nslookup, eller en webbläsarbaserad DNS-uppslagstjänst. Med dessa kan du begära specifika posttyper som A, AAAA, MX och TXT så att du kan verifiera konfigurationen eller felsöka problem.