DNS förklarat: hur ett domännamn blir en webbplats
Du skriver ett namn, en webbplats visas. Däremellan blir fyra separata servrar konsulterade på under 50 millisekunder. Här är resan, och varför det tar längre tid att ändra en post än att göra den.
Typ example.com Tryck på Enter. Innan din webbläsare kan skicka en enda byte av en HTTP-begäran måste den ta reda på var example.com är - och den uppslagningen innebär att du konsulterar upp till fyra olika servrar, vanligtvis slutförs på väl under 50 millisekunder, och sker osynligt vid varje första besök på varje domän.
Låt oss följa en.
Resan för en enda lookup
Din webbläsare och operativsystem kontrollerar sina egna cacher
Båda behåller de senaste svaren. Om någon av dem har en som inte har gått ut, slutar uppslagningen här i mikrosekunder. De flesta uppslagningar på en upptagen maskin lämnar den aldrig.
Den rekursiva resolveren tillfrågas
Vanligtvis körs av din Internetleverantör, eller en offentlig som 1.1.1.1 eller 8.8.8.8. Det är den komponent som gör den faktiska jakten, och det cacher kraftigt på uppdrag av alla som använder den.
Resolver frågar en rotserver
Det finns 13 root serveradresser, betjänas av hundratals anycast instanser över hela världen. Roten vet inte var example.com är. Det vet vem som är ansvarig för .com, och säger så.
TLD-servern är
.com-namnservrarna känner inte heller till adressen. De vet vilka namnservrar som är auktoritativa till exempel.com - de som din registrar pekar på - och returnerar dem.
Den auktoritativa namnservern
Den här håller de faktiska posterna, och slutligen svarar: example.com är på den här adressen, och här är hur länge du kanske kommer ihåg det.
Alla lägger fram svaret
Resolver lagrar det, ditt operativsystem lagrar det, din webbläsare lagrar det. Nästa uppslag för samma namn hoppar över det mesta av resan helt.
Den kedjan ser långsam ut, och det skulle vara om det hände varje gång. Det gör det inte. Rot- och TLD-svar cachas i timmar eller dagar av varje resolver på jorden, så i praktiken börjar en resolver nästan alltid halvvägs ner i kedjan, och en återkommande besökares webbläsare hoppar ofta över det helt och hållet.
Skivor värda att veta
| Rekord | Vad det gör | Typisk användning |
|---|---|---|
| A | Avbilda ett namn till en IPv4-adress | Peka en domän på en server |
| AAAA | Avbildar ett namn till en IPv6-adress | Samma sak för IPv6 |
| CNAME | Kartlägger ett namn till ett annat namn | Peka www på ett CDN-värdnamn |
| MX | Säger var e-post för domänen går | E-postvärd |
| TXT | Innehåller godtycklig text | SPF, DKIM, domänverifiering |
| NS | Namnge de auktoritativa servrarna | Delegera en domän eller underdomän |
| CAA | Säger vilka myndigheter som får utfärda certifikat | Förhindra obehöriga certifikat |
Att peka en domän på ett CDN innebär normalt att ändra en A-post eller ett CNAME så att namnet löser sig till kantnätverket snarare än till ditt ursprung. Den enda poständringen är det som sätter CDN framför din webbplats.
Apex rekordproblem
En rynka som fångar nästan alla. DNS-specifikationen tillåter inte ett CNAME i toppen av en domän example.com själv, i motsats till www.example.com eftersom en CNAME inte kan samexistera med de andra posterna måste apex bära, till exempel MX och NS. Rikta din apex på en CNAME och din e-post kan sluta fungera.
Leverantörer arbetar runt detta med funktioner som omväxlande kallas CNAME-platta, ALIAS eller ANAME-poster, som löser målet bakom kulisserna och returnerar en A-post. Om du behöver din nakna domän på ett CDN, antingen använda en leverantör som erbjuder det eller använda en vanlig A-post och acceptera att du måste uppdatera den manuellt om adressen ändras.
TTL, och varför förändringar tar tid
Varje DNS-post har en tid att leva: hur många sekunder en resolver kan cacha svaret innan du frågar igen. Det är anledningen till att DNS-skalor - utan cachning, root och TLD-servrar skulle fält varje uppslag på internet - och det är också anledningen till att förändringar inte är omedelbara.
När du ändrar en post visas det nya värdet omedelbart av dina auktoritativa namnservrar. Men varje resolver som redan har det gamla svaret fortsätter att tjäna det tills dess kopia löper ut. Med en 24-timmars TTL kommer vissa besökare att nå den gamla adressen en hel dag efter att du gjorde ändringen.
Sänk TTL tidigare En planerad förändring, inte under den. Släpp den till 300 sekunder om dagen eller två framåt, vänta på att den gamla långa TTL ska löpa ut överallt, gör sedan förändringen - den fortplantar sig nu på några minuter. Höj den igen efteråt. Sänka TTL i samma ögonblick som du ändrar posten uppnår ingenting, eftersom resolvers fortfarande håller den gamla posten med sin gamla TTL.
Ytterligare två verkligheter värda att känna till. Vissa resolver ignorerar korta TTL:er och inför sitt eget minimum, så "propagation" är aldrig helt förutsägbar. Och webbläsare behåller sina egna DNS-cacher som överlever operativsystemets cache, varför en förändring kan tyckas ha fungerat överallt utom på maskinen för den person som gjorde det.
När det går sönder, kolla i den här ordningen
- Fråga dina auktoritativa servrar direkt.
dig @ns1.yourprovider.com example.comvisar vad som faktiskt publiceras, förbi varje cache däremellan. Om detta är fel, är ingenting nedströms viktigt. - Fråga sedan en offentlig resolver.
dig @1.1.1.1 example.comDet är vad internet ser idag, vilket fortfarande kan vara det gamla värdet. - Kolla TTL i svaret. Det räknas ner när den cachade kopian åldras, så det berättar hur mycket längre det inaktuella svaret kommer att leva.
- Bekräfta namnservrarna hos registratorn. Om NS- posterna på din registratorpunkt någonstans du inte redigerar, har du ändrat poster som ingen blir tillfrågad om.
Vanliga frågor
Vad är DNS?
DNS, domännamnssystemet, översätter mänskligt läsbara domännamn som example.com till de numeriska IP-adresserna datorer använder för att nå varandra. Varje anslutning till en webbplats börjar med en DNS-sökning, som besvaras antingen från en cache eller genom att konsultera root, toppnivådomän och auktoritativa namnservrar i sin tur.
Hur lång tid tar DNS-utbredningen?
Det beror på den TTL som angavs i posten innan du ändrade den, inte på det nya värdet. Resolvers som håller det gamla svaret fortsätter att tjäna det tills deras kopia löper ut, så en post med en 24-timmars TTL kan ta en hel dag att uppdatera överallt. Sänkning av TTL en dag eller två innan en planerad förändring minskar detta till minuter.
Vad är skillnaden mellan en A-post och ett CNAME?
En A-post mappar ett namn direkt till en IPv4-adress. Ett CNAME mappar ett namn till ett annat namn, som sedan måste lösas i tur och ordning. CNAME-filer är användbara för att peka en underdomän på en leverantörs värdnamn, eftersom leverantören kan ändra den underliggande adressen utan att du redigerar något. Ett CNAME kan inte användas vid toppen av en domän.
Varför kan jag inte använda ett CNAME på min rotdomän?
Eftersom DNS-specifikationen inte tillåter en CNAME att samexistera med andra poster med samma namn, och toppen av en domän måste bära NS och vanligtvis MX poster. Med hjälp av en CNAME kan det bryta e-postleverans. Leverantörer erbjuder CNAME-, ALIAS- eller ANAME-poster för att kringgå detta genom att lösa målet och returnera en A-post istället.
Vad är en TTL i DNS?
Tiden att leva är antalet sekunder en resolver kan cacha en post innan den måste fråga igen. Längre TTL:er minskar uppslagstrafiken och förbättrar prestandan; kortare gör att ändringar sprids snabbare. Vanliga värden varierar från 300 sekunder för poster som du förväntar dig att ändra till 86 400 sekunder för stabila.
Hur pekar jag min domän mot ett CDN?
Vanligtvis genom att ändra en CNAME-post så att ditt värdnamn, till exempel www.example.com, löser till värdnamnet som CDN tillhandahåller, snarare än till din ursprungsservers adress. För en ren apex-domän behöver du en A-post eller din leverantörs CNAME-platta. Sänk TTL i förväg så ändringen träder i kraft snabbt, och testa på CDN: s tillfälliga värdnamn innan du byter.
DNS är en distribuerad sökning som förvandlar namn till adresser, besvaras av en kedja av root, TLD och auktoritativa servrar och cachas aggressivt vid varje steg. Lär dig de få posttyper som är viktiga, kom ihåg att spetsen inte kan ta en CNAME och sänk din TTL innan du ändrar något. De flesta DNS-smärtor fungerar precis som de är utformade.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT - mestadels värd - sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till Vismas förvärv, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.
