Sådan fungerer DNS — domænenavne til IP-adresser

Sådan fungerer DNS — domænenavne til IP-adresser

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Start i gruppen »Din enhed« med »Du skriver et domæne«, og følg de to rækker videre: enheden spørger resolveren, og resolveren afgør, om den allerede kender svaret.
• Når resolveren ikke kender svaret, rykker pilen ind i kolonnen »Opslag« og ned gennem kæden — rod til TLD til autoritativ server — før den vender tilbage til resolveren og videre til din enhed.
• »Ja«-grenen på cachebeslutningen springer direkte til slutningen og viser den hurtige vej, som alle oplever ved et gentaget besøg.

Opslagskæden

»Browseren sender forespørgslen til en rekursiv resolver« giver spørgsmålet videre til en server, der må spørge andre på dine vegne — typisk din internetudbyders eller en offentlig tjeneste som dit netværks DNS. Derfra går »Nej«-grenen af cachebeslutningen hele kæden igennem: »Resolveren spørger rodserveren«, »Rodserveren peger på .io-TLD-serveren«, »TLD-serveren peger på den autoritative server« og til sidst »Den autoritative server returnerer IP-adressen«. Hvert hop indsnævrer spørgsmålet med ét niveau af navnet.

Resolverens rolle

Resolveren sidder mellem din enhed og de tre servergrupper af en grund: den er den del, der husker. »Resolveren gemmer svaret i cachen og returnerer det« er årsagen til, at et andet besøg på samme side springer hele kæden over, og »Ja«-grenen på cachebeslutningen er den hurtige vej tegnet eksplicit. Resolveren håndterer også genforsøg og sikkerhedsudvidelser, alt sammen usynligt for browseren.

Hvor kæden ender

»Browseren forbinder til IP-adressen« lukker cirklen tilbage i gruppen »Din enhed« — opslaget findes kun for at skaffe en destination til den egentlige forespørgsel. Den destination er den, som trinnet »Browseren spørger DNS, hvor domænet ligger« i forklaringen om internettet bruger, og som forklaringen om en API-forespørgsels livscyklus går ud fra allerede er slået op.

Key relationships and takeaways

• DNS er en delegeret kæde: rod peger på TLD, TLD peger på autoritativ, og kun den autoritative server har den endelige record.
• Den rekursive resolver gør arbejdet én gang og gemmer svaret i cachen, og derfor er gentagne opslag næsten øjeblikkelige.
• Domæneejeren råder kun over den autoritative server — ikke over rod- eller TLD-serverne.
• En fejl et vilkårligt sted i kæden betyder, at browseren ingen destination har, og at der ikke sendes nogen forespørgsel.
• DNS-opslaget går forud for enhver forbindelse, og derfor er det det første hop i en API-forespørgsels livscyklus.

When to use this visual

• At forklare et nyt teammedlem, hvorfor et domæne er langsomt at slå op første gang og øjeblikkeligt bagefter.
• At fejlsøge en melding om »siden blev ikke fundet« ved at gå kæden igennem — cache, autoritative records, TTL — i stedet for at gætte.
• At undervise i ejerskabsmodellen: hvilke DNS-records jeres team råder over, og hvilke registrator eller hostingudbyder råder over.

Sådan fungerer det

1. Følg jeres eget domæne gennem kæden

   Erstat »querychart.io« med et domæne, I råder over, og notér på trinnet med den autoritative server, hvilken udbyder der hoster dets records — jeres registrator, en DNS-tjeneste eller jeres hostingselskab.

2. Tilføj de sikkerhedsudvidelser, I bruger

   Indsæt et DNSSEC-valideringstrin mellem resolveren og svaret, eller et stub-resolver-trin på enheden, så diagrammet viser de dele, jeres opsætning faktisk kører.

3. Notér de rigtige TTL'er på cachen

   Sæt jeres records' time-to-live på cachebeslutningen, så diagrammet siger, hvor længe en ændring er om at slå igennem — det tal, der gør hele billedet brugbart.

4. Tilføj fejlgrenene

   Tag med, hvad der sker, når en server i kæden ikke kan nås eller ikke returnerer nogen record (en SERVFAIL), og lad hver gren ende i et eksplicit udfald, så lærredet dækker rigtige driftshændelser.

Ofte stillede spørgsmål

Hvad er DNS forklaret enkelt?

DNS, Domain Name System, er den fortegnelse, der oversætter et domænenavn som querychart.io til den IP-adresse, en computer kan forbinde til. Det virker ved delegering: en kæde af servere, der hver har ansvaret for én del af navnet, og som tilsammen giver den endelige adresse. Uden den skulle du huske og skrive IP-adresser.

Hvad er forskellen på en rekursiv resolver og en autoritativ server?

Den rekursive resolver er den server, din enhed spørger; den søger, følger kæden på dine vegne og gemmer resultatet i cachen. Den autoritative server er domæneejerens egen server og sandhedskilden for det domæne — den har de endelige records og er den eneste server, der kan svare autoritativt. Netop derfor placerer forklaringen dem i hver sin ende af kæden.

Hvorfor caches DNS, og hvad er en TTL?

Cachen er det, der holder DNS hurtigt: uden den ville hver sideindlæsning udløse en hel kæde af opslag. Hver DNS-record bærer en time-to-live (TTL), der siger, hvor længe en resolver må huske den. Cachebeslutningen i forklaringen er netop den mekanisme — når en records TTL udløber, må resolveren gå kæden igennem igen.

Hvad sker der, når DNS fejler?

Hvis ingen server i kæden kan give et svar, returnerer resolveren en fejl, og browseren viser, at domænet ikke kan nås. De sædvanlige årsager er en manglende eller forkert indtastet record på den autoritative server, et udløbet domæne eller en resolver, der ikke kan nå kæden. At gå opslagets rækkefølge igennem i denne forklaring er en praktisk måde at finde ud af, hvilken af delene det er.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis det lærred med DNS-opslaget, du ser ovenfor, som dit eget diagram, omdøb serverne til jeres udbydere, og følg jeres egne domæner gennem kæden.

Redigér dette diagram i QueryChart (FlowJam)