Låg DNS-latens är nyckeln till snabb internetsurfning. För att minimera det är det viktigt att noggrant välja DNS-servrar och . Men det första steget är att bli av med onödiga frågor.
Det är därför DNS ursprungligen designades som ett mycket cachebart protokoll. Zonadministratörer ställer in en tid att leva (TTL) för enskilda poster, och resolvers använder denna information när de lagrar poster i minnet för att undvika onödig trafik.
Är cachning effektiv? För ett par år sedan visade min lilla forskning att det inte var perfekt. Låt oss ta en titt på det aktuella läget.
För att samla information har jag patchat för att spara TTL-värdet för svaret. Den definieras som den minsta TTL för dess poster för varje inkommande begäran. Detta ger en bra översikt över TTL-fördelningen av verklig trafik, och tar även hänsyn till populariteten för individuella förfrågningar. Den korrigerade versionen av servern fungerade i flera timmar.
Den resulterande datamängden består av 1 583 579 poster (namn, qtype, TTL, tidsstämpel). Här är den övergripande TTL-fördelningen (X-axeln är TTL i sekunder):
Bortsett från en mindre bump vid 86 (mest för SOA-poster), är det ganska tydligt att TTL:erna är i det låga intervallet. Låt oss ta en närmare titt:
Okej, TTL som är längre än 1 timme är inte statistiskt signifikanta. Låt oss sedan fokusera på området 0−3600:
De flesta TTL:er är från 0 till 15 minuter:
De allra flesta är från 0 till 5 minuter:
Det är inte särskilt bra.
Kumulativ fördelning gör problemet ännu mer uppenbart:
Hälften av DNS-svaren har en TTL på 1 minut eller mindre och tre fjärdedelar har en TTL på 5 minuter eller mindre.
Men vänta, det är faktiskt värre. Detta är trots allt TTL från auktoritativa servrar. Men klientupplösare (t.ex. routrar, lokala cachar) tar emot en TTL från uppströmslösare, och den minskar för varje sekund.
Så klienten kan faktiskt använda varje post för i genomsnitt hälften av den ursprungliga TTL innan han skickar en ny begäran.
Kanske gäller dessa mycket låga TTL:er bara ovanliga förfrågningar och inte populära webbplatser och API:er? Låt oss ta en titt:
X-axeln är TTL, Y-axeln är sökpopularitet.
Tyvärr är de mest populära frågorna också de värsta att cache.
Låt oss zooma in:
Omdöme: det är riktigt dåligt. Det var redan dåligt innan, men det blev ännu värre. DNS-cachelagring har blivit praktiskt taget värdelös. Eftersom färre personer använder sin internetleverantörs DNS-resolver (av goda skäl) blir ökningen av latens mer märkbar.
DNS-cache har blivit användbar endast för innehåll som ingen besöker.
Observera också att programvaran kan tolka låga TTL.
Varför så?
Varför är DNS-poster inställda på en så låg TTL?
- Äldre lastbalanserare lämnades med standardinställningar.
- Det finns myter om att DNS-belastningsbalansering beror på TTL (detta är inte sant - sedan Netscape Navigators dagar har klienter valt en slumpmässig IP-adress från en uppsättning RR:er och öppet provat en annan om de inte kan ansluta)
- Administratörer vill tillämpa ändringar omedelbart, så det är lättare att planera.
- Administratören av en DNS-server eller belastningsutjämnare ser sin uppgift som att effektivt distribuera den konfiguration som användarna begär, och inte påskynda webbplatser och tjänster.
- Låga TTL ger dig sinnesfrid.
- Människor satte initialt låga TTL för testning och glömmer sedan att ändra dem.
Jag tog inte med "failover" i listan eftersom det blir mindre och mindre relevant. Om du behöver omdirigera användare till ett annat nätverk bara för att visa en felsida när absolut allt annat är trasigt, är en fördröjning på mer än 1 minut förmodligen acceptabel.
Dessutom betyder en en minuts TTL att om auktoritativa DNS-servrar blockeras i mer än 1 minut, kommer ingen annan att kunna komma åt beroende tjänster. Och redundans hjälper inte om orsaken är ett konfigurationsfel eller ett hack. Å andra sidan, med rimliga TTL:er kommer många klienter att fortsätta använda den tidigare konfigurationen och aldrig märka något.
CDN-tjänster och lastbalanserare är till stor del skyldiga till låga TTL, särskilt när de kombinerar CNAME med låga TTL och poster med lika låga (men oberoende) TTL:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Närhelst CNAME eller någon av A-posterna löper ut måste en ny begäran skickas. Båda har en 30 sekunders TTL, men det är inte samma sak. Den faktiska genomsnittliga TTL kommer att vara 15 sekunder.
Men vänta! Det är ännu värre. Vissa resolvers beter sig väldigt dåligt i den här situationen med två associerade låga TTL:er:
$ borra raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 I CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Level3-resolvern körs förmodligen på BIND. Om du fortsätter att skicka denna begäran kommer en TTL på 1 alltid att returneras. raw.githubusercontent.com cachelagras aldrig.
Här är ett annat exempel på en sådan situation med en mycket populär domän:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Minst tre CNAME-poster. Ja. En har en hyfsad TTL, men den är helt värdelös. Andra CNAME:er har en initial TTL på 60 sekunder, men för domäner akamai.net den maximala TTL är 20 sekunder och ingen av dem är i fas.
Hur är det med domäner som ständigt efterfrågar Apple-enheter?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Samma problem som Firefox och TTL kommer att ha fastnat på 1 sekund för det mesta när du använder Level3 resolver.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 I CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 I CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
Vid inspelningen safebrowsing.googleapis.com TTL-värdet är 60 sekunder, som Facebook-domäner. Och återigen, ur kundens synvinkel, halveras dessa värden.
Vad sägs om att ställa in en lägsta TTL?
Med hjälp av namnet, förfrågningstypen, TTL och den ursprungligen lagrade tidsstämpeln skrev jag ett skript för att simulera 1,5 miljoner förfrågningar som passerar genom en caching-resolver för att uppskatta volymen extra förfrågningar som skickas på grund av en utgången cache-post.
47,4 % av förfrågningarna gjordes efter att ett befintligt register hade löpt ut. Detta är orimligt högt.
Vad blir effekten på cachning om den lägsta TTL är inställd?
X-axeln är de minsta TTL-värdena. Poster med käll-TTL över detta värde påverkas inte.
Y-axeln är procentandelen förfrågningar från en klient som redan har en cachad post, men den har löpt ut och gör en ny begäran.
Andelen "extra" förfrågningar minskas från 47 % till 36 % genom att helt enkelt ställa in minsta TTL till 5 minuter. Genom att ställa in minsta TTL till 15 minuter sjunker antalet förfrågningar till 29 %. En minsta TTL på 1 timme minskar dem till 17 %. Betydande skillnad!
Vad sägs om att inte ändra något på serversidan, utan istället ställa in minsta TTL i klientens DNS-cachar (routrar, lokala resolvers)?
Antalet förfrågningar som krävs sjunker från 47 % till 34 % med en minsta TTL på 5 minuter, till 25 % med minst 15 minuter och till 13 % med minst 1 timme. Kanske 40 minuter är optimalt.
Effekten av denna lilla förändring är enorm.
Vilka är konsekvenserna?
Naturligtvis kan tjänsten flyttas till en ny molnleverantör, ny server, nytt nätverk, vilket kräver att klienter använder de senaste DNS-posterna. Och en ganska liten TTL hjälper till att göra en sådan övergång smidigt och omärkligt. Men med övergången till ny infrastruktur förväntar sig ingen att klienter ska migrera till nya DNS-poster inom 1 minut, 5 minuter eller 15 minuter. Att ställa in minsta TTL till 40 minuter istället för 5 minuter kommer inte att hindra användare från att komma åt tjänsten.
Detta kommer dock att avsevärt minska latensen och förbättra integriteten och tillförlitligheten genom att undvika onödiga förfrågningar.
Naturligtvis säger RFC:erna att TTL måste följas strikt. Men verkligheten är att DNS-systemet har blivit för ineffektivt.
Om du arbetar med auktoritativa DNS-servrar, kontrollera dina TTL:er. Behöver du verkligen så löjligt låga värden?
Naturligtvis finns det goda skäl att ställa in små TTL:er för DNS-poster. Men inte för de 75 % av DNS-trafiken som förblir praktiskt taget oförändrad.
Och om du av någon anledning verkligen behöver använda låga TTL för DNS, se samtidigt till att din webbplats inte har caching aktiverat. Av samma skäl.
Om du har en lokal DNS-cache igång, som t.ex som låter dig ställa in minsta TTL, använd denna funktion. Det här är okej. Inget dåligt kommer att hända. Ställ in minsta TTL till cirka 40 minuter (2400 sekunder) och 1 timme. Ganska rimlig räckvidd.
Källa: will.com