Vad är DNS?

Det Domännamnssystemet (DNS) är internetets telefonkatalog. Människor får tillgång till information online genom domännamn, som nytimes.com eller espn.com. Webbläsare kommunicerar genom Internetprotokoll (IP)-adresser. DNS översätter domännamn till IP-adresser så att webbläsare kan ladda internetresurser.

Varje enhet ansluten till internet har en unik IP-adress som andra enheter använder för att hitta den. DNS-servrar eliminerar behovet för människor att memorera IP-adresser såsom 192.168.1.1 (i IPv4), eller mer komplexa alfanumeriska IP-adresser såsom 2400:cb00:2048:1::c629:d7a2 (i IPv6).

Hur fungerar DNS?

Processen för DNS-upplösning innebär att omvandla ett värdnamn (t.ex. www.example.com) till en datorvänlig IP-adress (t.ex. 192.168.1.1). En IP-adress tilldelas varje enhet på internet, och den adressen är nödvändig för att hitta rätt internetenhet – på samma sätt som en gatuadress används för att hitta ett specifikt hem. När en användare vill ladda en webbsida måste en översättning ske mellan vad användaren skriver in i sin webbläsare (exempel.com) och den maskinvänliga adress som krävs för att lokalisera webbsidan exmpel.com.

För att förstå processen bakom DNS-upplösning är det viktigt att lära sig om de olika hårdvarukomponenter som en DNS-förfrågan måste passera mellan. För webbläsaren sker DNS-sökningen ”bakom kulisserna” och kräver ingen interaktion från användarens dator förutom den initiala förfrågan.

Det finns 4 DNS-servrar involverade i laddningen av en webbsida:

• DNS-omdirigerare – Omdirigeraren kan ses som en bibliotekarie som ombeds att leta upp en särskild bok någonstans i ett bibliotek. DNS-omdirigeraren är en server avsedd att ta emot förfrågningar från klientmaskiner genom program som webbläsare. Vanligtvis är omdirigeraren sedan ansvarig för att göra ytterligare förfrågningar för att tillfredsställa klientens DNS-förfrågan.
• Rotnamnservrar – Rotservern är första steget i att översätta (lösa) mänskligt läsbara värdnamn till IP-adresser. Den kan ses som ett index i ett bibliotek som pekar på olika hyllor med böcker – vanligtvis fungerar den som en referens till andra mer specifika platser.
• Toppdomänservrar (TLD) – Toppdomänservrarna kan ses som en specifik hylla med böcker i ett bibliotek. Denna namnserver är nästa steg i sökandet efter en specifik IP-adress och den hanterar den sista delen av ett värdnamn (I exemplet.com, är TLD-servern ”com”).
• Auktoritativa namnservrar – Denna slutliga namnserver kan ses som en ordbok på en hylla med böcker, där ett specifikt namn kan översättas till sin definition. Den auktoritativa namnservern är det sista stoppet i namnserverförfrågan. Om den auktoritativa namnservern har tillgång till den begärda posten kommer den att returnera IP-adressen för det begärda värdnamnet till DNS-omdirigeraren (bibliotekarien) som gjorde den initiala förfrågan.

Vad är skillnaden mellan en auktoritativ DNS-server och en rekursiv DNS?

Båda begreppen syftar på servrar (grupper av servrar) som är en integrerad del av DNS-infrastrukturen, men var och en utför en annan roll och befinner sig på olika platser i pipelinen för en DNS-förfrågan. Ett sätt att tänka på skillnaden är att den rekursiva lösaren är i början av DNS-förfrågan och den auktoritativa namnservern är i slutet.

Rekursiv DNS-resolver

Den rekursiva lösaren är datorn som svarar på en rekursiv förfrågan från en klient och tar sig tid att söka efter DNS-posten. Den gör detta genom att göra en serie förfrågningar tills den når den auktoritativa DNS-namnservern för den begärda posten (eller timear ut eller returnerar ett fel om ingen post hittas). Lyckligtvis behöver inte rekursiva DNS-lösare alltid göra flera förfrågningar för att hitta de poster som behövs för att svara på en klient; caching är en process för datahållbarhet som hjälper till att förkorta de nödvändiga förfrågningarna genom att servera den begärda resursposten tidigare i DNS-sökningen.

Auktoritativ DNS-server

En auktoritativ DNS-server är en server som faktiskt håller, och är ansvarig för, DNS-resursposter. Detta är servern längst ner i DNS-uppslagets kedja som kommer att svara med den frågade resursposten och möjliggöra för webbläsaren att göra den förfrågde IP-adressen som behövs för att komma åt en webbplats eller andra webbresurser. En auktoritativ namnserver kan tillfredsställa förfrågningar från sin egen data utan att behöva fråga en annan källa, eftersom den är den slutgiltiga sanningen för vissa DNS-poster.

Det är värt att nämna att vid förfrågningar om en underdomän såsom foo.example.com eller blog.cloudflare.com kommer en ytterligare namnserver att läggas till i sekvensen efter den auktoritativa namnservern, som är ansvarig för att lagra underdomänens CNAME-post.

Det finns en viktig skillnad mellan många DNS-tjänster och den som Cloudflare tillhandahåller. Olika rekursiva DNS-lösare som Google DNS, OpenDNS och leverantörer som Comcast underhåller alla datacenterinstallationer av rekursiva DNS-lösare. Dessa lösare möjliggör snabba och enkla förfrågningar genom optimerade kluster av datorer som är optimerade för DNS, men de skiljer sig fundamentalt från namnserverna som Cloudflare värd.

Vilka är stegen i en DNS-sökning?

För de flesta situationer handlar DNS om att ett domännamn översätts till den lämpliga IP-adressen. För att förstå hur denna process fungerar kan det vara till hjälp att följa vägen för en DNS-uppslagning när den färdas från en webbläsare, genom DNS-uppslagningsprocessen, och tillbaka igen. Låt oss titta på stegen.

Observera: Ofta kommer DNS-uppslagsinformation att cachas antingen lokalt inuti den frågande datorn eller på distans i DNS-infrastrukturen. Det finns vanligtvis 8 steg i en DNS-uppslagning. När DNS-informationen cachelagras hoppas steg över från DNS-uppslagsprocessen vilket gör den snabbare. Exemplet nedan beskriver alla 8 steg när ingenting är cachat.

De 8 stegen i en DNS-sökning:

1. En användare skriver ’exempel.com’ i en webbläsare och förfrågan färdas ut i internet och tas emot av en DNS-rekursiv lösare.
2. Den rekursiva lösaren förfrågar sedan en DNS-rotserver (.).
3. Rotservern svarar sedan till lösaren med adressen till en toppdomäns (TLD) DNS-server (t.ex. .com eller .net), som lagrar informationen för sina domäner. När man söker efter exempel.com, riktas vår förfrågan mot .com TLD.
4. Lösaren gör sedan en förfrågan till .com TLD.
5. TLD-servern svarar sedan med IP-adressen för domänens namnserver, exempel.com.
6. Slutligen skickar den rekursiva lösaren en förfrågan till domänens namnserver.
7. IP-adressen för exempel.com returneras sedan till lösaren från namnservern.
8. DNS-lösaren svarar sedan till webbläsaren med IP-adressen för den ursprungligen efterfrågade domänen.

När de 8 stegen i DNS-uppslagningen har returnerat IP-adressen för exempel.com, kan webbläsaren göra förfrågan för webbsidan:

1. Webbläsaren gör en HTTP-förfrågan till IP-adressen.
2. Servern på den IP-adressen returnerar webbsidan för att visas i webbläsaren (steg 10).

Vad är en DNS-resolver?

DNS-resolvern är det första stoppet i DNS-uppslagningen, och den är ansvarig för att hantera klienten som gjorde den ursprungliga förfrågan. Lösaren startar sekvensen av förfrågningar som i slutändan leder till att en URL översätts till den nödvändiga IP-adressen.

Observera: En typisk ocachead DNS-uppslagning kommer att involvera både rekursiva och iterativa förfrågningar.

Det är viktigt att skilja mellan en rekursiv DNS-förfrågan och en rekursiv DNS-lösare. Förfrågan hänvisar till begäran som görs till en DNS-lösare som kräver att förfrågan löses. En DNS-rekursiv lösare är datorn som accepterar en rekursiv förfrågan och behandlar svaret genom att göra nödvändiga förfrågningar.

Vilka typer av DNS-requests finns det?

I en typisk DNS-uppslagning sker tre typer av förfrågningar. Genom att använda en kombination av dessa förfrågningar kan en optimerad process för DNS-upplösning resultera i en minskning av avståndet som färdas. I en idealisk situation kommer cachad data vara tillgänglig, vilket gör att en DNS-namnserver kan returnera en icke-rekursiv förfrågan.

3 typer av DNS-förfrågningar:

1. Rekursiv förfrågan – I en rekursiv förfrågan kräver en DNS-klient att en DNS-server (vanligtvis en DNS-rekursiv lösare) ska svara till klienten med antingen den begärda resursposten eller ett felmeddelande om lösaren inte kan hitta posten.
2. Iterativ förfrågan – i denna situation kommer DNS-klienten att tillåta att en DNS-server returnerar det bästa svaret den kan. Om den frågade DNS-servern inte har en matchning för frågenamnet, kommer den att returnera en hänvisning till en DNS-server som är auktoritativ för en lägre nivå av domännamnsutrymmet. DNS-klienten kommer sedan att göra en förfrågan till hänvisningsadressen. Denna process fortsätter med ytterligare DNS-servrar längre ner i förfrågningsserien tills antingen ett fel uppstår eller en tidsgräns överskrids.
3. Icke-rekursiv förfrågan – vanligtvis kommer detta att inträffa när en DNS-rekursiv lösareklient förfrågar en DNS-server om en post som den har tillgång till antingen för att den är auktoritativ för posten eller för att posten finns i dess cache. Vanligtvis kommer en DNS-server att cachelagra DNS-poster för att förhindra ytterligare bandbreddsförbrukning och belastning på uppströms servrar.

Vad är DNS-cachelagring? Var sker DNS-cachelagring?

Syftet med caching är att tillfälligt lagra data på en plats som resulterar i förbättringar i prestanda och tillförlitlighet för datförfrågningar. DNS-caching innebär att lagra data närmare den begärande klienten så att DNS-förfrågan kan lösas tidigare och ytterligare förfrågningar längre ner i DNS-uppslagskedjan kan undvikas, vilket förbättrar laddningstiderna och minskar bandbredds-/CPU-förbrukningen. DNS-data kan cachelagras på olika platser, var och en som kommer att lagra DNS-poster under en bestämd tid som bestäms av en ”time-to-live” (TTL).

Webbläsarens DNS-caching Modernt webbläsare är som standard utformade för att cachelagra DNS-poster under en bestämd tid. Syftet här är uppenbart; ju närmare DNS-caching sker webbläsaren, desto färre bearbetningssteg måste tas för att kontrollera cachen och göra de korrekta förfrågningarna till en IP-adress. När en förfrågan görs för en DNS-post, är webbläsarcachen den första platsen som kontrolleras för den begärda posten.

I Chrome kan du se statusen för din DNS-cache genom att gå till chrome://net-internals/#dns.

Operativsystemnivå DNS-caching DNS-resolvern på operativsystemnivån är den andra och sista lokala anhalten innan en DNS-förfrågan lämnar din dator. Processen inuti ditt operativsystem som är utformad för att hantera denna förfrågan kallas vanligtvis en ”stub resolver” eller DNS-klient. När en stub resolver får en förfrågan från en applikation, kontrollerar den först sin egen cache för att se om den har posten. Om den inte har det, skickar den sedan en DNS-förfrågan (med en rekursiv flagga satt), utanför det lokala nätverket till en DNS-rekursiv lösare inuti internetleverantören (ISP).

När den rekursiva lösaren inuti ISP tar emot en DNS-förfrågan, precis som alla tidigare steg, kommer den också att kontrollera om den begärda värd-till-IP-adressöversättningen redan är lagrad i sin lokala persistenta lager.

Den rekursiva lösaren har också ytterligare funktionalitet beroende på vilka typer av poster som finns i dess cache:

• Om lösaren inte har A-posterna, men har NS-posterna för de auktoritativa namnservrarna, kommer den att fråga dessa namnservrar direkt och kringgå flera steg i DNS-förfrågan. Denna genväg förhindrar uppslag från rot- och .com-namnservrarna (i vår sökning efter exempel.com) och hjälper till att snabba upp lösningen av DNS-förfrågan.
• Om lösaren inte har NS-posterna, kommer den att skicka en förfrågan till TLD-servrarna (.com i vårt fall) och hoppa över rotservern.
• I händelse av att lösaren inte har poster som pekar till TLD-servrarna, kommer den sedan att förfråga rotserverna. Detta inträffar vanligtvis efter att en DNS-cache har rensats.