DNS förklarat: hur ett domännamn blir en webbplats
Om du skriver ett namn visas en webbplats. Däremellan konsulteras fyra separata servrar på mindre än 50 millisekunder. Här är resan, och varför det tar längre tid att ändra en skiva än att göra den.
Typ example.com Tryck på Enter. Innan din webbläsare kan skicka en enda byte av en HTTP-förfrågan 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å långt under 50 millisekunder, och sker osynligt vid varje första besök på varje domän.
Låt oss följa en.
Resan med en enda lookup
Din webbläsare och ditt operativsystem kontrollerar sina egna cacheminnen
Båda håller senaste svaren. Om någon av dem har en som inte har gått ut, slutar uppslagningen här i mikrosekunder. De flesta sökningar på en upptagen maskin lämnar den aldrig.
Den rekursiva resolveren tillfrågas
Körs vanligtvis av din Internetleverantör, eller en offentlig sådan som 1,1.1,1 eller 8,8.8,8. Det är den komponent som gör själva jakten, och det cacher tungt på uppdrag av alla som använder den.
Resolver frågar en rotserver
Det finns 13 root-serveradresser som betjänas av hundratals anycast-instanser över hela världen. Roten vet inte var example.com är. Den vet vem som är ansvarig för .com, och säger det.
TLD-servern är
Namnservrarna för .com 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.
Sedan den auktoritativa namnservern
Den här innehå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
Upplösningen lagrar den, ditt operativsystem lagrar den, din webbläsare lagrar den. Nästa sökning efter samma namn hoppar över det mesta av resan helt och hållet.
Kedjan ser långsam ut, och det skulle vara om det hände varje gång. Det gör det inte. Rot- och toppdomänsvar 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.
Skivorna värda att veta
| Spela in | Vad den gör | Typisk användning |
|---|---|---|
| A | Kartlägger ett namn till en IPv4-adress | Peka en domän på en server |
| AAAA | Kartlägger ett namn till en IPv6-adress | Samma sak gäller för IPv6 |
| CNAME | Kartlägger ett namn till ett annat namn | Peka www på ett värdnamn för CDN |
| MX | Säger var e-post för domänen hamnar | Hem - Kundavdelning |
| TXT | Innehåller godtycklig text | SPF, DKIM, domänverifiering |
| NS | Namnger de auktoritativa servrarna | Delegera en domän eller underdomän |
| CAA | Ange vilka myndigheter som får utfärda intyg | 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 posten förändring ä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 vid 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 som topppunkten måste bära, till exempel MX och NS. Rikta din spets mot ett CNAME så kanske din e-post slutar 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, använd antingen en leverantör som erbjuder det eller använd 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 före 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 det 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, vilket är anledningen till att en förändring kan tyckas ha fungerat överallt utom på maskinen hos den person som gjorde den.
När den 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 visar vad det bredare internet ser, 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 registrarpunkt någonstans du inte redigerar, har du ändrat poster som ingen frågas 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-adresser som 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. Att sänka TTL en dag eller två innan en planerad ändring minskar detta till minuter.
Vad är skillnaden mellan en A-post och en 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. CNAMEs ä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-namn kan inte användas längst ut på 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 ett CNAME kan du bryta e-postleveransen. Leverantörer erbjuder CNAME-, ALIAS- eller ANAME-poster för att kringgå detta genom att lösa målet och returnera en A-post i stället.
Vad är en TTL i DNS?
Tiden att leva är antalet sekunder som 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 TTL:er 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 toppdomän behöver du en A-post eller motsvarande CNAME-platta från din leverantör. Sänk TTL:n i förväg så att ändringen träder i kraft snabbt, och testa på CDN:ns tillfälliga värddatornamn innan du byter.
DNS är en distribuerad uppslagning 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å rekordtyperna som är viktiga, kom ihåg att spetsen inte kan ta ett CNAME och sänk din TTL innan du ändrar någonting. 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 som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, 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.
