Domain Name System (DNS) latens är en nyckelkomponent för att ha en bra onlineupplevelse. Och för att minimera DNS-latens spelar noggrant plockning av DNS-servrar och anonymiseringsreläer en viktig roll.
men det bästa sättet att minimera latens är att undvika att skicka värdelösa frågor till att börja med. Därför utformades DNS, sedan dag ett, för att vara ett starkt cacheabelt protokoll. Enskilda poster har en time-to-live (TTL), ursprungligen inställd av zonadministratörer, och resolvers använder denna information för att hålla dessa poster i minnet för att undvika onödig trafik.
är caching effektiv? En snabb studie som jag gjorde för några år sedan visade att det fanns utrymme för förbättringar. Idag vill jag ta en ny titt på det aktuella läget.
För att göra det patchade jag en krypterad DNS-Server för att lagra den ursprungliga TTL för ett svar, definierat som minsta TTL för sina poster, för varje inkommande fråga. Detta ger oss en bra översikt över TTL-distributionen av verklig trafik, men står också för populariteten hos enskilda frågor.
den patchade versionen lämnades att köras i ett par timmar. Den resulterande datamängden består av 1,583,579 (namn, qtype, TTL, tidsstämpel) tuples. Här är den totala TTL-fördelningen (X – axeln är TTL i sekunder):
förutom en försumbar bump på 86.400 (främst för SOA-poster) är det ganska uppenbart att TTLs ligger i det låga intervallet. Låt oss zooma in:
okej, TTLs över 1 timme är statistiskt obetydliga. Låt oss fokusera på intervallet 0-3 600:
och där de flesta TTL sitter mellan 0 och 15 minuter:
den stora majoriteten är mellan 0 och 5 minuter:
detta är inte bra. Den kumulativa fördelningen kan göra problemet ännu mer uppenbart:
halva Internet har en 1-minuters TTL eller mindre, och tre fjärdedelar har en 5-minuters TTL eller mindre.
men vänta, det här är faktiskt värre. Dessa är TTLs som definieras av auktoritativa servrar. TTLs som hämtas från klientresolvers (till exempel routrar, lokala cachar) får dock en TTL som uppströms resolvers minskar varje sekund. Så, i genomsnitt, den faktiska varaktigheten en klient kan använda en cachad post innan kräver en ny fråga är hälften av den ursprungliga TTL.
kanske påverkar dessa mycket låga TTLs bara ovanliga frågor, och inte populära webbplatser och API: er. Låt oss ta en titt:
tyvärr är de mest populära frågorna också de mest meningslösa att cache. Låt oss zooma in:
dom: det är riktigt dåligt, eller snarare var det redan dåligt, och det har blivit värre. DNS caching har blivit bredvid värdelös. Med färre personer som använder sin ISP: s DNS-resolver (av goda skäl) blir den ökade latensen mer märkbar. DNS-caching har blivit bara användbart för innehåll som ingen besöker. Observera också att programvara kan tolka låga TTLS annorlunda.
varför?
Varför är DNS-poster inställda med så låga TTLS?
- Legacy lastbalanserare lämnas med standardinställningar.
- den urbana legenden om att DNS-baserad lastbalansering beror på TTLs (det gör det inte).
- administratörer vill att deras ändringar ska tillämpas omedelbart, eftersom det kan kräva mindre planeringsarbete.
- som DNS-eller belastningsbalanseradministratör är din plikt att effektivt distribuera konfigurationen som folk frågar, inte att göra webbplatser och tjänster snabbt.
- låga TTLs ger sinnesro.
Jag inkluderar inte’ för failover ’ i den listan, eftersom detta har blivit mindre och mindre relevant. Om avsikten är att omdirigera användare till ett annat nätverk bara för att visa en fail whale-sida när absolut allt annat brinner, är det förmodligen acceptabelt att ha mer än en minuts fördröjning.
CDNs och lastbalanserare är till stor del skyldiga, särskilt när de kombinerar CNAME-poster med korta TTLs med poster som också har korta (men oberoende) TTLS:
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
en ny fråga måste skickas när CNAME eller någon av A-posterna löper ut. De har båda en 30-sekunders TTL men är inte i fas. Den faktiska genomsnittliga TTL kommer att vara 15 sekunder.
men vänta! Det här är värre. Vissa resolvers beter sig ganska dåligt i en sådan låg-TTL-CNAME + low-TTL-records situation:
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
detta är Level3s resolver, som jag tror kör BIND. Om du fortsätter att skicka den frågan kommer den returnerade TTL alltid att vara 1. I huvudsak, raw.githubusercontent.com kommer aldrig att cachas.
här är ett annat exempel på en låg-TTL-CNAME+låg-TTL-poster situation, med ett mycket populärt namn:
$ drill detectportal.firefox.com @1.1.1.1detectportal.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.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Inte Mindre än tre CNAME-poster. AJ. En av dem har en anständig TTL, men det är helt värdelöst. Andra CNAMEs har en original TTL på 60 sekunder; akamai.net namnen har en maximal TTL på 20 sekunder och inget av det är i fas.
vad sägs om en som dina Apple-enheter ständigt pollar?
$ drill 1-courier.push.apple.com @4.2.2.21-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.84gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
samma konfiguration som Firefox och TTL sitter fast vid 1 för det mesta när du använder Level3s resolver.
vad sägs om Dropbox?
$ drill client.dropbox.com @8.8.8.8client.dropbox.com. 7 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 59 IN A 162.125.67.3$ drill client.dropbox.com @4.2.2.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com har en TTL på 60 sekunder. Facebook-namn har en 60-sekunders TTL. Och återigen, ur ett klientperspektiv, bör dessa värden halveras.
vad sägs om att ställa in ett minimum TTL?
med hjälp av namnet, frågetypen, TTL och tidsstämpeln som ursprungligen lagrades skrev jag ett skript som simulerar de 1,5+ miljoner frågorna som går igenom en cacheupplösare för att uppskatta hur många frågor som skickades på grund av en utgått cachepost. 47,4% av frågorna gjordes efter att en befintlig cachelagrad post hade löpt ut. Detta är orimligt högt.
vad skulle påverka caching om ett minimum TTL sattes?
x-axeln är den minsta TTL som ställdes in. Poster vars ursprungliga TTL var högre än detta värde påverkades inte. Y-axeln är andelen frågor som gjorts av en klient som redan hade en cachad post, men en ny fråga gjordes och den cachade posten hade löpt ut.
antalet frågor sjunker från 47% till 36% bara genom att ställa in ett minimum TTL på 5 minuter. Om du ställer in ett minimum av TTL på 15 minuter sjunker antalet begärda frågor till 29%. En minsta TTL på 1 timme gör att den sjunker till 17%. Det är en stor skillnad!
vad sägs om att inte ändra något på serversidan, men att ha klient-DNS-cachar (routrar, lokala resolvers och cachar…) ställer in ett minimum TTL istället?
antalet nödvändiga frågor sjunker från 47% till 34% genom att ställa in ett minimum TTL på 5 minuter, till 25% med ett minimum på 15 minuter och till 13% med ett minimum på 1 timme. 40 minuter kanske en söt plats. Effekten av den minimala förändringen är enorm.
vilka är konsekvenserna?
naturligtvis kan en tjänst byta till en ny molnleverantör, en ny server, ett nytt nätverk, vilket kräver att klienter använder uppdaterade DNS-poster. Och att ha rimligt låga TTLs hjälper till att göra övergången friktionsfri. Ingen som flyttar till en ny infrastruktur kommer dock att förvänta sig att kunderna använder de nya DNS-posterna inom 1 minut, 5 minuter eller 15 minuter.
att ställa in en minsta TTL på 40 minuter istället för 5 minuter kommer inte att hindra användare från att komma åt tjänsten. Det kommer dock att drastiskt minska latensen och förbättra integriteten (fler frågor = fler spårningsmöjligheter) och tillförlitlighet genom att undvika onödiga frågor.
naturligtvis säger RFC att TTLs bör respekteras strikt. Men verkligheten är att DNS har blivit ineffektivt.
Om du använder auktoritativa DNS-servrar, vänligen se över dina TTLs. Behöver du verkligen dessa för att vara löjligt låga?
Läs: hur man väljer DNS TTL-värden
Visst, det finns giltiga skäl att använda låg DNS TTLS. Men inte för 75% av Internet för att tjäna innehåll som mestadels är oföränderligt, men meningslöst att cache. Och om du av någon anledning verkligen behöver använda låg DNS TTLs, se också till att cachen inte fungerar på din webbplats heller. Av samma skäl.
om du använder en lokal DNS-cache som dnscrypt-proxy som gör det möjligt att ställa in minsta TTLs, använd den funktionen. Det här är okej. Inget dåligt kommer att hända. Ställ in den minsta TTL till något mellan 40 minuter (2400 sekunder) och 1 timme; detta är ett helt rimligt intervall.
anpassad från originalpost som dök upp på 00f.net