Reisen til en DNS-forespørsel

Modul 1: Hva er DNS? · Lesetid: 8 minutter

Læringsmål: Etter denne leksjonen kan du forklare steg for steg hvordan en resolver finner et svar, og hvor svarene blir husket underveis.

Nøkkelbegreper: resolver (rekursiv), rotserver, TLD-server, autoritativ navnetjener, henvisning (delegering), cache

To typer DNS-servere

I leksjon 1.1 så du at DNS er delt opp: ingen vet alt. Hvordan får nettleseren din likevel tak i adressen til www.example.com? Det løses ved at to typer servere samarbeider:

• Autoritative navnetjenere (på engelsk authoritative) kjenner svaret for sin egen del. Navnetjenerne til example.com kjenner postene til example.com. De slår ikke opp noe for andre.
• Resolvere (også kalt rekursive resolvere) slår opp svaret for deg. De spør videre helt til de får svar. Internettleverandøren din har en resolver, og det finnes offentlige resolvere som de fra Quad9, Cloudflare eller Google.

Din egen datamaskin slår nesten ikke opp noe selv. Den har en liten stub-resolver som sender spørsmålet videre til resolveren i nettverket ditt og får svaret tilbake.

Reisen, steg for steg

Si at resolveren ikke har husket noe fra før, og du spør etter A-posten til www.example.com.

1. Datamaskinen din spør resolveren: «Hva er A-posten til www.example.com?»
2. Resolveren spør en rotserver. Hver resolver har en innebygd liste med adressene til rotserverne. Rotserveren vet ingenting om example.com, men vet hvem som forvalter .com. Den svarer med en henvisning: «For det må du gå til navnetjenerne for com: a.gtld-servers.net, b.gtld-servers.net, og så videre.»
3. Resolveren spør en navnetjener for .com. Den vet heller ikke IP-adressen til www.example.com, men vet hvilke navnetjenere example.com har. Igjen en henvisning: «Spør ns1.hosting.example eller ns2.hosting.example.»
4. Resolveren spør en navnetjener for example.com. Den er autoritativ for domenet og gir svaret: «www.example.com har A-post 192.0.2.10.»
5. Resolveren gir svaret til datamaskinen din. Nettleseren din kobler seg til 192.0.2.10.

En henvisning fra et høyere nivå til navnetjenerne på et lavere nivå kalles en delegering. Roten delegerer .com til Verisign, .com delegerer example.com til navnetjenerne som domeneinnehaveren har oppgitt. For et .nl-domene fungerer det på nøyaktig samme måte, bare at roten da henviser til navnetjenerne for .nl (SIDN, for eksempel ns1.dns.nl). Det ser du selv i oppgaven nederst i denne leksjonen. Derfor er det så viktig at navnetjenerne stemmer hos registerforvalteren (leksjon 2.1).

Cachen: ikke hele reisen hver gang

Hvis hver resolver måtte begynne hos roten ved hvert eneste spørsmål, ville roten fått en ufattelig mengde forespørsler. Det skjer ikke, for resolveren husker svarene en stund. Dette minnet kalles cache.

Hvor lenge et svar kan huskes, står i selve svaret: TTL (time to live), i sekunder. En TTL på 3600 betyr: dette svaret kan huskes i en time. Også henvisningene blir husket. En resolver som nettopp har fått vite hvilke navnetjenere .com har, trenger ikke spørre roten om det på nytt neste gang.

Spør noen andre hos samme leverandør om www.example.com et minutt senere, svarer resolveren umiddelbart fra cachen. Ingen reise, ingen ventetid.

Cacher finnes flere steder:

• i resolveren til leverandøren din eller den offentlige resolveren du bruker;
• i operativsystemet ditt (Windows, macOS, telefonen din);
• i nettleseren din;
• noen ganger i ruteren din.

Det er raskt og effektivt, men det har en konsekvens du ofte møter senere: endrer du en post, fortsetter cacher å gi det gamle svaret helt til deres TTL har gått ut. Derfor ser én person en endring mens en annen ennå ikke gjør det. Modul 6 går grundig gjennom dette.

Rotserverne

Det finnes 13 navn for rotserverne: a.root-servers.net til og med m.root-servers.net. De forvaltes av tolv forskjellige organisasjoner. Bak hvert navn står det mange servere verden over, på hundrevis av steder, som deler samme adresse (dette kalles anycast). Resolveren din havner automatisk hos en som er i nærheten. Også TLD-navnetjenerne, som de for .com og .nl, fungerer slik. Derfor er DNS raskt og fortsetter å fungere selv om en server et sted faller ut.

Hvor det kan gå galt

Kjenner du reisen, kan du plassere problemer bedre:

• Delegeringen stemmer ikke. Hos registerforvalteren står det navnetjenere som ikke (lenger) kjenner domenet. Da kommer ikke resolveren videre i steg 4. Svaret blir en feilmelding, eller det kommer ikke noe svar i det hele tatt.
• Den autoritative serveren gir et annet svar enn du forventer. Da har du endret posten et annet sted enn der navnetjenerne står (leksjon 2.1).
• Cachen har fortsatt det gamle svaret. Da er ingenting ødelagt. Du må vente til TTL-en har gått ut, eller tømme din egen cache.
• DNSSEC stemmer ikke. En validerende resolver kontrollerer signaturer underveis. Stemmer ikke kjeden, nekter den å gi svaret (leksjon 8.1).

Med verktøyet dig +trace kan du selv gjenskape reisen, fra roten til den autoritative serveren. Det lærer du i leksjon 8.2. Nettbaserte verktøy kan også vise dette.

Oppsummering

• Autoritative navnetjenere kjenner svaret for sitt eget domene; resolvere slår opp svaret for deg.
• En resolver begynner hos roten, får en henvisning til TLD-en, deretter til navnetjenerne for domenet, og får svaret der.
• En slik henvisning kalles en delegering.
• Svar blir husket i cacher, så lenge TTL-en sier; derfor er endringer ikke synlige overalt med en gang.
• Det finnes 13 rotservernavn, men takket være anycast står det mange servere bak dem verden over.

Quiz

Oppgave

Oppgave Z1.4: Følg reisen. Følg reisen for www.sidn.nl (nettsiden til SIDN, registerforvalteren for .nl i Nederland), med dig +trace www.sidn.nl eller et nettbasert verktøy som viser en trace. Fyll inn: (1) én navnetjener for nl. som du møter underveis, (2) én autoritativ navnetjener for sidn.nl.

Les mer

Disse artiklene beskriver situasjonen hos WebOké. Hos andre leverandører fungerer det på lignende måte.

• DirectAdmin-veiledning 5.11: Når gjelder en endring? Ventetid og TTL
• Hvor lenge tar en nameserver- eller DNS-endring, og hva om du ikke ser den?