DNS forklaret: hvordan et domænenavn bliver til en hjemmeside
Du skriver et navn, en hjemmeside vises. I mellem bliver fire separate servere konsulteret på under 50 millisekunder. Her er rejsen, og hvorfor det tager længere tid at ændre en post end at gøre det.
Type example.com Tryk på Enter. Før din browser kan sende en enkelt byte af en HTTP-anmodning, skal den finde ud af, hvor example.com er - og det opslag indebærer at konsultere op til fire forskellige servere, som normalt fuldføres på godt under 50 millisekunder, og sker usynligt ved hvert første besøg på hvert domæne.
Lad os følge en.
Rejsen med et enkelt opslag
Din browser og OS tjekker deres egne caches
Begge beholder de seneste svar. Hvis en af dem har et der ikke er udløbet, slutter opslaget her i mikrosekunder. De fleste opslag på en travl maskine forlader det aldrig.
Den rekursive resolver bliver spurgt
Normalt køres af din internetudbyder, eller en offentlig en som 1.1.1.1 eller 8.8.8.8. Det er den komponent, der gør den faktiske jagt, og det caches kraftigt på vegne af alle, der bruger det.
Resolveren spørger en rodserver
Der er 13 rodserveradresser, der betjenes af hundredvis af anycast-instanser over hele verden. Roden ved ikke, hvor example.com er. Det ved, hvem der er ansvarlig for .com, og siger det.
Så TLD-serveren
.com-navneserverne kender heller ikke adressen. De ved, hvilke navneservere der er autoritative for eksempel.com - dem, som din registrator peger på - og returnerer dem.
Så den autoritative navneserver
Denne ene holder de faktiske poster, og til sidst svar: example.com er på denne adresse, og her er hvor længe du kan huske det.
Alle gemmer svaret
Resolver gemmer det, dit OS gemmer det, din browser gemmer det. Det næste opslag for det samme navn springer det meste af rejsen helt over.
Den kæde ser langsomt udskrevet ud, og det ville det være, hvis det skete hver gang. Det gør det ikke. Root og TLD svar er cachelagret i timer eller dage af hver resolver på jorden, så i praksis en resolver næsten altid starter halvvejs ned i kæden, og en gentagelse besøgendes browser ofte springer det helt.
Optegnelser værd at vide
| Optag | Hvad det gør | Typisk brug |
|---|---|---|
| A | Tilknytter et navn til en IPv4-adresse | Peger et domæne på en server |
| AAAA | Tilknytter et navn til en IPv6-adresse | Det samme gælder IPv6 |
| CNAME | Tilknytte et navn til et andet navn | Peger www på et CDN-værtnavn |
| MX | Siger hvor e-mail til domænet går | Kundeområde - Host |
| TXT | Indeholder vilkårlig tekst | SPF, DKIM, domæneverifikation |
| NS | Navne på autoritative servere | Delegere et domæne eller underdomæne |
| CAA | Angiver, hvilke myndigheder der kan udstede certifikater | Forebyggelse af uautoriserede certifikater |
At pege et domæne på et CDN betyder normalt at ændre en A-post eller et CNAME, så navnet løser til kantnetværket i stedet for til din oprindelse. Den enkelte postændring er det, der sætter CDN foran dit websted.
Apex rekord problem
En rynke, der fanger næsten alle. DNS-specifikationen tillader ikke et CNAME i toppen af et domæne example.com sig selv, i modsætning til www.example.com fordi en CNAME ikke kan eksistere sammen med de andre optegnelser, skal toppunktet bære, såsom MX og NS. Peg din toppunkt på en CNAME, og din e-mail kan stoppe med at fungere.
Udbydere arbejder omkring dette med funktioner, der skiftevis kaldes CNAME-flatning, ALIAS eller ANAME-poster, som løser målet bag kulisserne og returnerer en A-post. Hvis du har brug for dit nøgne domæne på et CDN, skal du enten bruge en udbyder, der tilbyder det, eller bruge en almindelig A-post og acceptere, at du bliver nødt til at opdatere det manuelt, hvis adressen ændres.
TTL, og hvorfor ændringer tager tid
Hver DNS-post bærer en tid til at leve: hvor mange sekunder en resolver kan cache svaret, før du spørger igen. Det er grunden til, at DNS-skalaer - uden caching, root og TLD-servere ville felt hver opslag på internettet - og det er også grunden til, at ændringer ikke er øjeblikkelige.
Når du ændrer en post, betjenes den nye værdi med det samme af dine autoritative navneservere. Men enhver resolver, der allerede har det gamle svar, fortsætter med at tjene det, indtil dets kopi udløber. Med en 24-timers TTL vil nogle besøgende nå den gamle adresse en hel dag efter du har foretaget ændringen.
Sænk TTL før Det er en planlagt forandring, ikke under den. Drop det til 300 sekunder om dagen eller to fremad, vent på, at den gamle lange TTL udløber overalt, og foretag derefter ændringen - den udbreder sig nu på få minutter. Hæv det igen bagefter. Sænkning af TTL i samme øjeblik du ændrer posten opnår intet, fordi resolvere stadig holder den gamle post med sin gamle TTL.
To andre virkeligheder, der er værd at kende. Nogle resolvere ignorerer korte TTL'er og pålægger deres eget minimum, så "udbredelse" er aldrig helt forudsigelig. Og browsere opretholder deres egne DNS-cacher, der overlever OS-cachen, hvorfor en ændring kan synes at have fungeret overalt undtagen på maskinen til den person, der lavede den.
Når det går i stykker, skal du kontrollere i denne rækkefølge
- Forespørg dine autoritative servere direkte.
dig @ns1.yourprovider.com example.comviser, hvad der faktisk er offentliggjort, omgå hver cache i mellem. Hvis dette er forkert, intet nedstrøms spørgsmål. - Søg derefter en offentlig resolver.
dig @1.1.1.1 example.comfortæller dig, hvad det bredere internet i øjeblikket ser, som stadig kan være den gamle værdi. - Tjek TTL i svaret. Det tæller ned som den cachelagrede kopi aldre, så det fortæller dig, hvor meget længere det forældede svar vil leve.
- Bekræft navneserverne hos registratoren. Hvis NS- posterne på dit registratorpunkt et sted du ikke redigerer, har du ændret poster, som ingen bliver spurgt om.
Ofte stillede spørgsmål
Hvad er DNS?
DNS, Domain Name System, oversætter menneskelæsbare domænenavne som example.com til de numeriske IP-adresser computere bruger til at nå hinanden. Hver forbindelse til et websted begynder med et DNS-opslag, som besvares enten fra en cache eller ved at konsultere root, topniveau domæne og autoritative navneservere til gengæld.
Hvor lang tid tager DNS-udbredelse?
Det afhænger af den TTL, der blev angivet på posten, før du ændrede den, ikke på den nye værdi. Resolvere, der holder det gamle svar, fortsætter med at betjene det, indtil deres kopi udløber, så en post med en 24-timers TTL kan tage en hel dag at opdatere overalt. Sænkning af TTL en dag eller to før en planlagt ændring reducerer dette til minutter.
Hvad er forskellen mellem en A record og en CNAME?
En A-post knytter et navn direkte til en IPv4-adresse. Et CNAME knytter et navn til et andet navn, som derefter skal løses efter tur. CNAME'er er nyttige til at pege et underdomæne på en udbyders værtsnavn, da udbyderen kan ændre den underliggende adresse, uden at du redigerer noget. Et CNAME kan ikke bruges i toppen af et domæne.
Hvorfor kan jeg ikke bruge et CNAME på mit roddomæne?
Fordi DNS-specifikationen ikke tillader en CNAME at eksistere sammen med andre poster med samme navn, og toppunktet af et domæne skal bære NS og normalt MX-poster. Ved hjælp af en CNAME der kan bryde e-mail-levering. Udbydere tilbyder CNAME-flatning, ALIAS eller ANAME-poster for at omgå dette ved at løse målet og returnere en A-post i stedet.
Hvad er en TTL i DNS?
Tiden til at leve er det antal sekunder, en resolver kan cache en post, før den skal spørge igen. Længere TTL'er reducerer opslagstrafik og forbedrer ydeevnen; kortere gør ændringerne hurtigere. Fælles værdier spænder fra 300 sekunder for poster, du forventer at ændre til 86.400 sekunder for stabile.
Hvordan peger jeg mit domæne på et CDN?
Normalt ved at ændre en CNAME-post, så dit værtsnavn, f.eks. www.example.com, løser til værtsnavnet, som CDN angiver, i stedet for til din oprindelsesservers adresse. For et simpelt apex-domæne skal du bruge en A-post eller din udbyders CNAME-flatning. Sænk TTL på forhånd, så ændringen træder i kraft hurtigt, og test på CDN's midlertidige værtsnavn, før du skifter.
DNS er et distribueret opslag, der gør navne til adresser, besvaret af en kæde af root, TLD og autoritative servere og cachelagret aggressivt ved hvert trin. Lær den håndfuld posttyper, der betyder noget, husk at apex ikke kan tage en CNAME, og sænk din TTL, før du ændrer noget. De fleste DNS smerte er caching fungerer nøjagtigt som designet.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet i IT - for det meste hosting - siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig, sikker infrastruktur enkel at bruge.
