Nätverk och protokoll

DNS

Distribuerat namnsystem som mappar domännamn till poster som IP-adresser.

Var du ser detta: Syns i paketfångster, nätverksdiagram, brandväggsregler samt system- och nätverksloggar.

Vad det är

DNS (Domain Name System) är Internets telefonbok och mycket mer. Den lagrar poster under domännamn, till exempel vilka IP-adresser som tjänar ett värdnamn, vilka e-postservrar som hanterar en domän eller vilka nycklar som används för DNSSEC.

Nyckelpunkter

Upplösare cachelagrar svar med TTL för att minska belastning och latens.
Frågor använder vanligtvis UDP, med TCP för större svar eller zonöverföringar.
Att förstå rekursion och auktoritet förklarar de flesta DNS beteenden.

Hur det fungerar i stora drag

Din enhet ber en lokal resolver (ofta din router eller OS-stubresolver) om ett namn, som www.example.com.
Om svaret är cachelagrat och fortfarande är giltigt (TTL har inte löpt ut) svarar resolvern omedelbart.
Om den inte är cachad, utför en rekursiv resolver uppslagningen genom att fråga DNS rotservrarna var de kan hitta den relevanta toppdomänen.
Resolvern frågar toppdomänservrarna om de auktoritativa servrarna för domänen.
Resolvern ber en auktoritativ server om den slutliga posten, som en A- eller AAAA-post.
Det auktoritativa svaret kommer tillbaka med ett TTL. Resolvern cachar den och returnerar den till klienten.
Om svaret är stort kan resolvern försöka igen över TCP, och moderna miljöer använder också krypterade transporter som DoH eller DoT för sekretess.

Konkret exempel

Du skriver en URL. Innan någon TCP eller TLS anslutning sker, löser din maskin värdnamnet genom en resolver. Om resolvern redan har cachat svaret kan uppslagningen vara mikrosekunder. Om inte, kan den kontakta flera servrar i DNS-hierarkin innan den returnerar den slutliga IP-adressen.

Varför det är viktigt

Hårdkodning av IP-adresser skalas inte. Tjänster flyttar, lastbalanserar och misslyckas. DNS ger ett stabilt namn medan de underliggande adresserna och routingen kan ändras.

Säkerhetsperspektiv

DNS kan förgiftas eller förfalskas utan skydd, så lösare använder randomisering och kan validera DNSSEC där det är tillgängligt.
Öppna resolver kan missbrukas för förstärkning. Rekursiva resolvers bör begränsas till betrodda klienter.
Krypterad DNS (DoH, DoT) förbättrar integriteten men kan också dölja DNS från traditionell nätverksövervakning.

Vanliga fallgropar

Jagar fel server. Klienten pratar vanligtvis med en rekursiv resolver, inte den auktoritativa servern.
Ignorerar cachelagring. En ändring kanske inte visas förrän TTLs löper ut.
Om vi antar att DNS alltid betyder A-poster. Många fel är faktiskt MX, TXT, CNAME eller SRV relaterade.
Att glömma negativ caching. NXDOMAIN svar kan också cachelagras.
Felsökning genom att endast pinga en IP. Namnupplösning och anslutning är olika problem.

FÖRDJUPNING

▾

Rollerna: stubresolver, rekursiv resolver och auktoritativ server

På de flesta enheter talar en applikation inte direkt till det globala DNS-systemet. Den frågar en lokal stubresolver, vanligtvis en del av operativsystemet, som sedan frågar en rekursiv resolver. Den rekursiva resolvern är arbetshästen. Den utför sökningen över DNS-hierarkin och returnerar ett slutgiltigt svar till stubben.

Auktoritativa servrar är olika. De söker inte. De svarar för zoner de kontrollerar, som example.com, och de returnerar poster tillsammans med TTL-värden. Rotservrar och toppdomänservrar är också auktoritativa för sina specifika zoner, och deras huvudsakliga uppgift är att tala om för resolvern vart den ska gå härnäst.

Att tänka i roller förtydligar felsökning. Om din bärbara dator inte kan lösa namn men en annan resolver fungerar, är problemet ofta den rekursiva resolvern eller sökvägen till den. Om alla på internet inte kan lösa en domän är problemet mer troligt i den auktoritativa sidan eller zonkonfigurationen.

Steg för steg: lösa ett namn du aldrig har sett

Föreställ dig att du skriver en ny domän i webbläsaren. Stubresolvern kontrollerar först lokal cache och hosts-fil. Finns inget svar skickas frågan till den konfigurerade rekursiva resolvern. Om inte heller den har ett cachat svar startar en iterativ uppslagning ned genom DNS-hierarkin.

Först frågar den en rotserver för domänen. Rotservern vet inte det slutliga svaret, men den returnerar en hänvisning till rätt toppdomänservrar. Därefter frågar resolvern en toppdomänserver, som returnerar en hänvisning till domänens auktoritativa namnservrar. Slutligen frågar resolvern en auktoritativ server efter posttypen den behöver, såsom A eller AAAA, och får svaret med TTL-värden.

Resolvern cachar sedan resultatet och returnerar det till din enhet. Ur ditt perspektiv ser det hela ut som en uppslagning, men under huven är det flera nätverksresor. Vinsten är att framtida sökningar är snabba eftersom de flesta delar av sökvägen är cachade, inklusive hänvisningar.

Cachning är anledningen till att DNS skalar

Cachning sker på flera lager: i stubresolvern, i den rekursiva resolvern, i vidarebefordrare och ibland i själva applikationerna. TTL på en DNS post talar om för cachar hur länge de får återanvända datan. När TTL löper ut måste cachen fråga igen, vilket är anledningen till att ändringar inte sprids direkt även om den auktoritativa servern uppdaterades.

Negativ cachning spelar också roll. Om ett namn inte finns kan resolvern cache det faktum ett tag för att undvika att upprepa samma misslyckade sökning. Detta förbättrar motståndskraften under stavfel och attacker, men det kan överraska dig under driftsättningen om du skapar en post kort efter ett cachat negativt svar.

En användbar mental modell är att DNS inte är en enda databas. Det är en uppsättning auktoritativa sanningar plus ett stort antal tillfälliga kopior. Felsökning innebär ofta att hitta vilken kopia någon använder och om den kopian är inaktuell.

Transportdetaljer du märker i det vilda

De flesta DNS frågor och svar använder UDP eftersom det är snabbt och enkelt. Om ett svar är för stort för UDP, kan servern ställa in en trunkeringsflagga och klienten försöker igen med TCP. TCP används också för zonöverföringar mellan auktoritativa servrar och i vissa DNSSEC tunga scenarier.

Moderna DNS använder EDNS för att tillåta större UDP nyttolaster än den gamla standarden, men storleken spelar fortfarande roll eftersom överdimensionerade datagram kan fragmenteras. Operatörer ställer ofta in DNS svarsstorlekar för att undvika fragmentering på vanliga vägar, vilket är anledningen till att vissa svar är avsiktligt kompakta.

Om du ser intermittenta fel, leta efter mellanlådor som misshandlar UDP-fragment, eller efter resolvers som inte kan nå auktoritativa servrar på grund av brandväggsregler. DNS är känslig för små anslutningsproblem eftersom den förlitar sig på flera distinkta destinationer under en enda lösning.

Säkerhets- och integritetsöverväganden

Klassisk DNS har ingen kryptering, så observatörer på vägen kan se vilka namn du slår upp och angripare kan försöka förfalska svar. Upplösare försvarar sig med slumpmässiga transaktions-ID:n, slumpmässiga källportar och noggranna cachningsregler, men det är fortfarande ett protokoll som förutsätter ett mestadels ärligt nätverk.

DNSSEC lägger till autenticitet genom att låta resolvers validera signerade poster, men den krypterar inte frågan. DNS över TLS och DNS över HTTPS lägger till kryptering för klienten till resolver-benet, vilket förbättrar integriteten i lokala nätverk, men de ändrar inte hur resolvern pratar med auktoritativa servrar om den inte är konfigurerad för att göra det.

En pragmatisk takeaway är att skilja integritet från konfidentialitet. DNSSEC hjälper dig att lita på svaret. DoT och DoH hjälper till att dölja frågan vid det första hoppet.