Modul 1 · 1.4
En DNS-forespørgsels rejse
Modul 1: Hvad er DNS? · Læsetid: 8 minutter
Læringsmål: Efter denne lektion kan du trin for trin forklare hvordan en resolver finder et svar, og hvor svarene bliver husket undervejs.
Nøglebegreber: resolver (rekursiv), rodserver, TLD-server, autoritativ navneserver, henvisning (delegering), cache
To slags DNS-servere
I lektion 1.1 så du at DNS er opdelt: ingen ved alt. Hvordan finder din browser så alligevel adressen på www.example.com? Det gør den fordi to slags servere samarbejder:
- Autoritative navneservere (på engelsk authoritative) kender svaret for deres eget stykke. Navneserverne for
example.comkender records forexample.com. De slår ikke noget op for andre. - Resolvere (også kaldet rekursive resolvere) finder svaret for dig. De spørger videre indtil de har svaret. Din internetudbyder har en resolver, og der findes offentlige resolvere som dem fra Quad9, Cloudflare eller Google.
Din computer slår næsten ikke selv noget op. Den har en lille stub resolver som sender spørgsmålet videre til resolveren på dit netværk og får svaret tilbage.
Rejsen, trin for trin
Lad os sige: resolveren har endnu ikke husket noget, og du spørger om A-recorden for www.example.com.
- Din computer spørger resolveren: "Hvad er A-recorden for www.example.com?"
- Resolveren spørger en rodserver. Hver resolver har en indbygget liste med adresserne på rodserverne. Rodserveren kender ikke noget til
example.com, men ved hvem der administrerer.com. Den svarer med en henvisning: "Det skal du spørge navneserverne for com om: a.gtld-servers.net, b.gtld-servers.net, og så videre." - Resolveren spørger en navneserver for .com. Den kender heller ikke IP-adressen for
www.example.com, men ved hvilke navneservereexample.comhar. Endnu en henvisning: "Spørg ns1.hosting.example eller ns2.hosting.example." - Resolveren spørger en navneserver for example.com. Den er autoritativ for dette domæne og giver svaret: "www.example.com har A-record 192.0.2.10."
- Resolveren giver svaret til din computer. Din browser opretter forbindelse til 192.0.2.10.
En henvisning fra et højere niveau til navneserverne på et lavere niveau kaldes en delegering. Roden delegerer .com til Verisign, .com delegerer example.com til de navneservere som domæneindehaveren har angivet. For et .nl-domæne foregår det på nøjagtig samme måde, bare henviser roden til navneserverne for .nl (SIDN, for eksempel ns1.dns.nl). Det ser du selv i opgaven nederst i denne lektion. Derfor er det så vigtigt at navneserverne stemmer overens hos registry'en (lektion 2.1).
Cachen: ikke hele rejsen hver gang
Hvis hver resolver skulle starte ved roden for hver eneste forespørgsel, ville roden få en ufattelig mængde forespørgsler. Det sker ikke, fordi resolveren husker svarene et stykke tid. Den hukommelse kaldes cachen.
Hvor længe et svar må huskes, står i selve svaret: TTL'en (time to live), i sekunder. En TTL på 3600 betyder: dette svar må huskes i en time. Også henvisningerne bliver husket. En resolver som lige har hørt hvilke navneservere .com har, behøver ikke spørge roden om det igen næste gang.
Spørger en anden hos samme udbyder om www.example.com et minut senere, svarer resolveren straks fra sin cache. Ingen rejse, ingen ventetid.
Caches findes flere steder:
- i resolveren hos din udbyder eller den offentlige resolver du bruger;
- i dit styresystem (Windows, macOS, din telefon);
- i din browser;
- nogle gange i din router.
Det er hurtigt og effektivt, men det har en konsekvens du ofte støder på senere: ændrer du en record, bliver det gamle svar ved med at blive givet af caches indtil deres TTL er udløbet. Derfor ser nogle en ændring med det samme, mens andre endnu ikke gør. Modul 6 handler udførligt om dette.
Rodserverne
Der findes 13 navne til rodserverne: a.root-servers.net til og med m.root-servers.net. De administreres af tolv forskellige organisationer. Bag hvert navn står der globalt mange servere, på hundredvis af steder, som deler samme adresse (det kaldes anycast). Din resolver havner automatisk hos en der ligger tæt på. Også TLD-navneserverne, som dem for .com og .nl, fungerer på samme måde. Derfor er DNS hurtigt og bliver ved med at fungere selv hvis en server et sted falder ud.
Hvor det kan gå galt
Når du kender rejsen, kan du bedre placere problemer:
- Delegeringen stemmer ikke. Hos registry'en står der navneservere som ikke (længere) kender domænet. Resolveren kommer så ikke videre ved trin 4. Svaret bliver en fejl, eller der kommer slet intet svar.
- Den autoritative server har et andet svar end du forventer. Du har så ændret recorden et andet sted end der hvor navneserverne står (lektion 2.1).
- Cachen har stadig det gamle svar. Så er der ikke noget i stykker. Du skal vente til TTL'en er udløbet, eller tømme din egen cache.
- DNSSEC stemmer ikke. En validerende resolver kontrollerer signaturer undervejs. Stemmer kæden ikke, afviser den svaret (lektion 8.1).
Med værktøjet dig +trace kan du selv gennemgå rejsen, fra roden til den autoritative server. Det lærer du i lektion 8.2. Online værktøjer kan også gøre det.
Opsummering
- Autoritative navneservere kender svaret for deres eget domæne; resolvere finder svaret for dig.
- En resolver starter ved roden, får en henvisning til TLD'en, derefter til domænets navneservere, og får svaret dér.
- Sådan en henvisning kaldes en delegering.
- Svar huskes i caches, så længe TTL'en angiver; derfor er ændringer ikke synlige alle steder med det samme.
- Der findes 13 rodservernavne, men takket være anycast står der mange servere bag dem globalt.
Quiz
Opgave
Opgave Z1.4: Følg rejsen. Følg rejsen for www.sidn.nl, med dig +trace www.sidn.nl eller et online værktøj der viser en trace. Udfyld: (1) én navneserver for nl. som du møder undervejs, (2) én autoritativ navneserver for sidn.nl.
Læs videre
Disse artikler beskriver situationen hos WebOké. Hos andre udbydere fungerer det på lignende vis.