Låg DNS-latens är nyckeln till snabb internetsurfning. För att minimera det är det viktigt att noggrant välja DNS-servrar och anonyma reläer. Men det första du behöver göra är att bli av med värdelösa 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 research att den inte var perfekt. Låt oss ta en titt på det aktuella läget.

För att samla information har jag patchat Krypterad DNS-server för att lagra 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 enskilda frågor. 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 stöt på 86 400 (mest för SOA-poster) är det ganska uppenbart att TTL:erna är i det låga intervallet. Låt oss ta en närmare titt:

Ok, TTL över 1 timme är inte statistiskt signifikanta. Låt oss sedan fokusera på intervallet 0-3600:

De flesta TTL:er är mellan 0 och 15 minuter:

De allra flesta är från 0 till 5 minuter:

Det här ä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 ännu värre. Detta är trots allt TTL från auktoritativa servrar. Men klientupplösare (t.ex. routrar, lokala cachar) tar emot TTL från uppströmslösare, och den minskar för varje sekund.

Således kan klienten faktiskt använda varje post för i genomsnitt hälften av den ursprungliga TTL innan han skickar en ny begäran.

Kanske påverkar 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 sämst cachade.

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 bara blivit användbart för innehåll som ingen besöker.

Observera också att programvaran kan på olika sätt tolka låga TTL.

Varför så?

Varför är DNS-poster inställda på en så liten TTL?

• Äldre lastbalanserare lämnas med standardinställningar.
• Det finns myter om att DNS-belastningsbalansering beror på TTL (detta stämmer inte - eftersom Netscape Navigator väljer klienter en slumpmässig IP-adress från RR-uppsättningen och försöker transparent med en annan om de inte kan ansluta)
• Administratörer vill tillämpa ändringar omedelbart, så det är lättare att planera.
• Administratören för en DNS-server eller belastningsutjämnare ser sin uppgift som att effektivt distribuera den konfiguration som efterfrågas av användare, och inte påskynda driften av webbplatser och tjänster.
• Låg TTL ger 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 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 innebär 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 att använda den tidigare konfigurationen och märker aldrig något.

Låga TTL:er är till stor del felet hos CDN-tjänster och lastbalanserare, särskilt när de kombinerar CNAME:er med låga TTL:er och poster med lika låga (men oberoende) TTL:er:

$ 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

Varje gång CNAME eller någon av A-posterna löper ut måste en ny begäran skickas. Båda har 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å länkade 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 den alltid att returnera en TTL på 1. I huvudsak, raw.githubusercontent.com aldrig cachad.

Här är ett annat exempel på den här situationen 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 hyfsad TTL, men den är helt värdelös. I andra CNAME är den initiala TTL 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 fastna 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, samma 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 går genom en caching-resolver för att uppskatta mängden extra förfrågningar som skickas på grund av en utgången cachepost.

47,4 % av förfrågningarna gjordes efter att den befintliga posten hade löpt ut. Detta är orimligt högt.

Vad blir effekten på cachning om ett lägsta TTL ställs in?

X-axeln är de minsta TTL-värdena. Poster med original-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 nödvändiga förfrågningar minskas från 47 % till 34 % när man ställer in en minsta TTL på 5 minuter, till 25 % med minst 15 minuter och till 13 % med minst 1 timme. Det optimala värdet är kanske 40 minuter.

Effekten av denna minimala förändring är enorm.

Vilka är konsekvenserna?

Naturligtvis kan tjänsten migreras till en ny molnleverantör, en ny server, ett 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 en ny infrastruktur förväntar sig ingen att kunderna ska migrera till nya DNS-poster inom 1 minut, 5 minuter eller 15 minuter. Att ställa in minimilivslängden till 40 minuter istället för 5 minuter hindrar inte 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 för 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:er för DNS, se också till att caching inte är aktiverat på din webbplats. Av samma skäl.

Om du har en lokal DNS-cache igång, som t.ex dnscrypt-proxy, som låter dig ställa in minsta TTL, använd denna funktion. Det här är bra. 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