DNS forklaret: hvordan et domænenavn bliver til et websted
Hvis du skriver et navn, vises der et websted. I mellemtiden bliver fire separate servere konsulteret på under 50 millisekunder. Her er rejsen, og hvorfor det tager længere tid at ændre en rekord end at lave den.
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 dit operativsystem tjekker deres egne cacher
Begge dele indeholder de seneste svar. Hvis en af dem har en, der ikke er udløbet, slutter opslaget her i mikrosekunder. De fleste opslag på en travl maskine forlader den aldrig.
Den rekursive resolver bliver spurgt
Køres normalt af din internetudbyder eller en offentlig som 1,1.1,1 eller 8,8.8,8. Det er den komponent, der gør den faktiske jagt, og det cacher 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. Den ved, hvem der er ansvarlig for .com, og det siger den også.
Så TLD-serveren
.com navneserverne kender heller ikke adressen. De ved, hvilke navneservere der er autoritative, f.eks. dem, som din registrator peger på, og returnerer dem.
Derefter den autoritative navneserver
Denne holder de faktiske poster, og endelig svarer: example.com er på denne adresse, og her er hvor længe du måske husker det.
Alle gemmer svaret
Resolveren gemmer den, dit operativsystem gemmer den, din browser gemmer den. Det næste opslag efter det samme navn springer det meste af rejsen over.
Kæden ser langsom ud, og det ville den 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øgende browser ofte springer det helt.
Optegnelserne værd at kende
| Optag | Hvad det gør | Typisk brug |
|---|---|---|
| A | Tilknytter et navn til en IPv4-adresse | Peger et domæne på en server |
| AAAAA | 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ærtsnavn |
| MX | Angiver, hvor e-mailen til domænet skal hen | Mail hosting |
| TXT | Indeholder vilkårlig tekst | SPF, DKIM, domæneverifikation |
| NS | Navngivning af de 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 sig til kantnetværket i stedet for til din oprindelse. Den eneste rekordæ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 på toppen af et domæne example.com selv, i modsætning til www.example.com fordi en CNAME ikke kan eksistere side om side med de andre registreringer, som toppunktet skal indeholde, f.eks. MX og NS. Peg dit toppunkt mod et CNAME, og din e-mail vil muligvis ikke længere virke.
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 har en tid til at leve: hvor mange sekunder en resolver kan cachelagre 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, vises den nye værdi straks 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, at du har foretaget ændringen.
Sænk TTL før en planlagt ændring, 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 i minutter. Hæv det igen bagefter. Sænkning af TTL i samme øjeblik du ændrer posten opnår ingenting, 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 tjekke i denne rækkefølge
- Spørg dine autoritative servere direkte.
dig @ns1.yourprovider.com example.comviser, hvad der faktisk offentliggøres, uden om hver cache imellem. Hvis dette er forkert, er der intet nedstrøms vigtigt. - Spørg derefter en offentlig resolver.
dig @1.1.1.1 example.comDet fortæller dig, hvad det bredere internet i øjeblikket ser, hvilket måske stadig er den gamle værdi. - Tjek TTL i svaret. Det tæller ned, efterhånden som den cachelagrede kopi bliver ældre, så det fortæller dig, hvor meget længere det forældede svar vil leve.
- Bekræft navneserverne hos registratoren. Hvis du ikke redigerer dine NS-poster et sted, hvor du er registreret, 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.
Hvor lang tid tager DNS-udbredelsen?
Det afhænger af den TTL, der blev angivet på posten, før du ændrede den, ikke af 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. Hvis du sænker TTL en dag eller to før en planlagt ændring, reduceres dette til minutter.
Hvad er forskellen mellem en A-post og et 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-, ALIAS- eller ANAME-poster til 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 antallet af sekunder, en resolver kan cachelagre en post, før den skal spørge igen. Længere TTL'er reducerer opslagstrafik og forbedrer ydeevnen. Kortere TTL'er gør ændringer 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, som f.eks. www.example.com, løses til værtsnavnet, som CDN angiver, i stedet for til din oprindelsesservers adresse. Hvis du ønsker et topdomæne, skal du bruge en A-registrering eller tilsvarende CNAME-flatning fra din udbyder. Sænk TTL'en på forhånd, så ændringen træder i kraft hurtigt, og test CDN'ens midlertidige værtsnavn, før du skifter.
DNS er et distribueret opslag, der forvandler navne til adresser, besvaret af en kæde af root, TLD og autoritative servere og cachelagret aggressivt ved hvert trin. Lær de få recordtyper, der betyder noget, husk, at toppunktet ikke tåler et 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 med IT – mest som vært – 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 og sikker infrastruktur enkel at bruge.
