Resan för en DNS-fråga

Modul 1: Vad är DNS? · Lästid: 8 minuter

Lärandemål: Efter den här lektionen kan du steg för steg förklara hur en resolver hittar ett svar, och var svar sparas i minnet på vägen.

Nyckelbegrepp: resolver (rekursiv), rootserver, TLD-server, auktoritativ namnserver, hänvisning (delegering), cache

Två typer av DNS-servrar

I lektion 1.1 såg du att DNS är uppdelat: ingen vet allt. Hur hittar då din webbläsare adressen till www.example.com? Det klaras av genom att två typer av servrar samarbetar:

• Auktoritativa namnservrar (på engelska authoritative) vet svaret för sin egen del. Namnservrarna för example.com känner till posterna för example.com. De slår inte upp något åt andra.
• Resolvrar (även kallade rekursiva resolvrar) söker upp svaret åt dig. De frågar vidare tills de får svar. Din internetleverantör har en resolver, och det finns öppna resolvrar som Quad9, Cloudflare eller Google.

Din dator själv slår nästan inget upp. Den har en liten stub resolver som skickar vidare frågan till nätverkets resolver och får tillbaka svaret.

Resan, steg för steg

Säg att resolvern inte har något sparat ännu och du frågar efter A-posten för www.example.com.

1. Din dator frågar resolvern: "Vad är A-posten för www.example.com?"
2. Resolvern frågar en rootserver. Varje resolver har en inbyggd lista med adresser till rootservrarna. Rootservern vet inget om example.com, men väl vem som hanterar .com. Den svarar med en hänvisning: "Det får du fråga namnservrarna för com om: a.gtld-servers.net, b.gtld-servers.net, och så vidare."
3. Resolvern frågar en namnserver för .com. Den vet inte heller IP-adressen för www.example.com, men väl vilka namnservrar example.com har. Ännu en hänvisning: "Fråga ns1.hosting.example eller ns2.hosting.example."
4. Resolvern frågar en namnserver för example.com. Den är auktoritativ för domänen och ger svaret: "www.example.com har A-posten 192.0.2.10."
5. Resolvern ger svaret till din dator. Din webbläsare ansluter till 192.0.2.10.

En hänvisning från en högre nivå till namnservrarna på en lägre nivå kallas en delegering. Roten delegerar .com till Verisign, .com delegerar example.com till de namnservrar som domäninnehavaren har angett. För en .nl-domän går det till på precis samma sätt, förutom att roten då hänvisar till namnservrarna för .nl (SIDN, till exempel ns1.dns.nl). Det ser du själv i uppgiften längst ner i den här lektionen. Därför är det så viktigt att namnservrarna hos registryn stämmer (lektion 2.1).

Cachen: inte hela resan varje gång

Om varje resolver skulle börja om från roten vid varje fråga skulle roten få en ofattbar mängd frågor. Det händer inte, för resolvern sparar svaren en tid. Det minnet kallas cache.

Hur länge ett svar får sparas står i själva svaret: TTL (time to live), i sekunder. En TTL på 3600 betyder: det här svaret får sparas i en timme. Även hänvisningarna sparas. En resolver som nyss har fått veta vilka namnservrar .com har behöver inte fråga roten om det igen nästa gång.

Om någon annan hos samma leverantör frågar efter www.example.com en minut senare svarar resolvern direkt från sin cache. Ingen resa, ingen väntetid.

Cacher finns på flera ställen:

• i resolvern hos din leverantör eller den öppna resolver du använder;
• i ditt operativsystem (Windows, macOS, din telefon);
• i din webbläsare;
• ibland i din router.

Det är snabbt och effektivt, men det får en följd du ofta stöter på senare: ändrar du en post fortsätter cacher att ge det gamla svaret tills deras TTL har löpt ut. Därför ser en person en ändring medan en annan ännu inte gör det. Modul 6 går igenom det här i detalj.

Rootservrarna

Det finns 13 namn för rootservrarna: a.root-servers.net till och med m.root-servers.net. De sköts av tolv olika organisationer. Bakom varje namn finns många servrar världen över, på hundratals platser, som delar samma adress (det kallas anycast). Din resolver hamnar automatiskt hos en som ligger nära. Även TLD-namnservrarna, som de för .com och .nl, fungerar så. Därför är DNS snabbt och fortsätter fungera även om en server slutar fungera någonstans.

Var det kan gå fel

Om du känner till resan kan du lättare placera problem:

• Delegeringen stämmer inte. Hos registryn finns namnservrar som inte (längre) känner till domänen. Resolvern kommer då inte vidare vid steg 4. Svaret blir ett fel eller så kommer det inget svar alls.
• Den auktoritativa servern har ett annat svar än du förväntar dig. Du har då ändrat posten på en annan plats än där namnservrarna finns (lektion 2.1).
• Cachen har fortfarande kvar det gamla svaret. Då är inget trasigt. Du behöver vänta tills TTL:n har löpt ut, eller tömma din egen cache.
• DNSSEC stämmer inte. En validerande resolver kontrollerar signaturer på vägen. Stämmer inte kedjan vägrar den svaret (lektion 8.1).

Med verktyget dig +trace kan du göra om resan själv, från roten till den auktoritativa servern. Det lär du dig i lektion 8.2. Det finns även onlineverktyg som klarar det.

Sammanfattning

• Auktoritativa namnservrar vet svaret för sin egen domän; resolvrar söker upp svaret åt dig.
• En resolver börjar vid roten, får en hänvisning till TLD:n, därefter till domänens namnservrar, och får svaret där.
• En sådan hänvisning kallas en delegering.
• Svar sparas i cacher, så länge TTL:n anger; därför syns ändringar inte överallt direkt.
• Det finns 13 rootservernamn, men tack vare anycast finns det många servrar bakom dem världen över.

Quiz

Uppgift

Uppgift Z1.4: Följ resan. Följ resan för www.sidn.nl (webbplatsen för SIDN, registryn för .nl i Nederländerna), med dig +trace www.sidn.nl eller ett onlineverktyg som visar en trace. Fyll i: (1) en namnserver för nl. som du stöter på längs vägen, (2) en auktoritativ namnserver för sidn.nl.

Läs vidare

De här artiklarna beskriver situationen hos WebOké. Hos andra leverantörer fungerar det på liknande sätt.

• DirectAdmin-guide 5.11: När börjar en ändring gälla? Väntetid och TTL
• Hur lång tid tar en ändring av nameserver eller DNS, och vad gör du om du inte ser den?