Låg DNS-fördröjning är en nyckelfaktor för snabb internetanvändning. För att minimera den är det viktigt att noggrant välja DNS-servrar och anonyma reläer. Men först och främst bör man bli av med onödiga förfrågningar.

Därför skapades DNS ursprungligen som en starkt cachad protokoll. Zonadministratörer sätter livslängd (TTL) för individuella poster, och resolverar använder denna information när de lagrar poster i minnet för att undvika onödig trafik.

Är cachningen effektiv? För ett par år sedan visade min lilla studie att den inte är perfekt. Låt oss titta på den nuvarande situationen.

För att samla information har jag patchat Encrypted DNS Server för att bevara TTL-värdet för svaret. Det definieras som den minimi TTL av dess poster för varje inkommande förfrågan. Detta ger en bra översikt av TTL-fördelningen för den verkliga trafiken och tar även hänsyn till populäriteten av individuella förfrågningar. Den patchade versionen av servern kördes i flera timmar.

Det resulterande datasetet består av 1 583 579 poster (namn, qtyp, TTL, tidsstämpel). Här är den övergripande fördelningen av TTL (X-axeln är TTL i sekunder):

Bortsett från det lilla toppvärdet på 86 400 (främst för SOA-poster) är det ganska uppenbart att TTL ligger i det låga intervallet. Låt oss titta närmare:

Okej, TTL över 1 timme är statistiskt ovidkommande. Låt oss fokusera på intervallet 0−3600:

De flesta TTL ligger mellan 0 och 15 minuter:

Den överväldigande majoriteten ligger mellan 0 och 5 minuter:

Detta är inte bra.

Den kumulativa fördelningen gör problemet ännu mer uppenbart:

I hälften av DNS-svaren är TTL 1 minut eller mindre, och för tre fjärdedelar är det 5 minuter eller mindre.

Men vänta, det är faktiskt ännu värre. Dessa är TTL från auktoritativa servrar. Men klientresolverare (t.ex. routrar, lokala cachar) får TTL från överordnade resolverare, och den minskar med varje sekund.

Därför kan klienten i genomsnitt använda varje post under hälften av den ursprungliga TTL, efter vilket ett nytt förfrågan skickas.

Kanske gäller dessa mycket låga TTL bara ovanliga förfrågningar, och inte populära webbplatser och API:er? Låt oss se:

X-axeln är TTL, Y-axeln är populariteten hos förfrågningarna.

Tyvärr är de mest populära förfrågningarna också de som cachas sämst.

Låt oss zooma in:

Dom: det är verkligen dåligt. Det har alltid varit dåligt, men nu har det blivit ännu sämre. DNS-caching har blivit praktiskt taget värdelöst. Eftersom färre och färre människor använder sin leverantörs DNS-resolver (av legitima skäl) blir ökningen av latens mer märkbar.

DNS-caching har blivit användbart endast för innehåll som ingen besöker.

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

Varför så?

Varför sätts en så låg TTL för DNS-poster?

• Föråldrade lastbalanserare har kvar standardinställningar.
• Det går myter om att lastbalansering via DNS beror på TTL (det gör den inte - ända sedan Netscape Navigator väljer klienter en slumpmässig IP-adress från en uppsättning RR och försöker osynligt en annan om de inte kan ansluta)
• Administratörer vill tillämpa förändringar omedelbart, eftersom det är mycket enklare att planera.
• DNS-serverns eller lastbalanserarens administratör ser det som sin uppgift att effektivt distribuera den konfiguration som användare begär, snarare än att snabba upp webbplatser och tjänster.
• Låga TTL ger sinnesro.
• Folk sätter initialt låga TTL för testning och glömmer sedan att ändra dem.

Jag inkluderade inte "felhantering" i listan, eftersom det blir mindre aktuellt. Om du behöver omdirigera användare till ett annat nätverk bara för att visa en felmeddelandesida när allt annat är trasigt, är kanske en latens på över 1 minut acceptabel.

Dessutom betyder en minut TTL att om de auktoritativa DNS-servrarna blockeras i mer än 1 minut, kan ingen annan få tillgång till beroende tjänster. Och redundans hjälper inte om orsaken är en konfigurationsfel eller hack. Å andra sidan, med rimliga TTL fortsätter många klienter att använda den tidigare konfigurationen och märker aldrig något.

Låga TTL ansvarar i hög grad för CDN-tjänster och lastbalanserare, särskilt när de kombinerar CNAME med låga TTL och poster med samma 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

Varje gång en CNAME- eller någon av A-posterna går ut, måste en ny förfrågan skickas. De har båda en TTL på 30 sekunder, men de matchar inte. Den faktiska genomsnittliga TTL kommer att vara 15 sekunder.

Men vänta! Det är fortfarande värre. Vissa resolverare beter sig väldigt dåligt i en sådan situation med två relaterade låga TTL:

$ drill raw.githubusercontent.com @4.2.2.2
raw.githubusercontent.com.	1	IN	CNAME	github.map.fastly.net.
github.map.fastly.net.	1	IN	A	151.101.16.133

Level3-resolveraren arbetar sannolikt med BIND. Om du fortsätter att skicka denna förfrågan, kommer TTL alltid att returneras som 1. I grund och botten, raw.githubusercontent.com kan aldrig cacheras.

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. Aj. En har en acceptabel TTL, men det är helt värdelöst. I andra CNAME är den ursprungliga TTL 60 sekunder, men för domänerna akamai.net är den maximala TTL 20 sekunder, och ingen av dem är synkroniserade.

Hur är det med domäner som ständigt queryar 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 med Firefox, och TTL kommer för det mesta att fastna på 1 sekund när man använder Level3-resolveraren.

Dropbox?

$ drill client.dropbox.com @8.8.8.8
client.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.2
client.dropbox.com.	1	IN	CNAME	client.dropbox-dns.com.
client.dropbox-dns.com.	1	IN	A	162.125.64.3

I posten safebrowsing.googleapis.com är TTL-värdet 60 sekunder, precis som för Facebook-domäner. Och återigen, sett ur ett kundperspektiv, minskar dessa värden med hälften.

Hur är det med att ställa in en minimal TTL?

Genom att använda namnet, begärningstypen, TTL och den ursprungligen sparade tidsstämpeln skrev jag ett skript för att simulera 1,5 miljoner förfrågningar som passerade genom en cache-resolver för att bedöma mängden onödiga förfrågningar som skickades på grund av en utgången cache-poster.

47,4% av förfrågningarna gjorde efter att den befintliga posten hade gått ut. Det är orimligt högt.

Vad kommer att bli effekten på caching om en minimal TTL sätts?

X-axeln representerar de minimi TTL-värden. Poster med ursprungliga TTL-värden över detta påverkas inte.

Y-axeln visar procentandelen förfrågningar från klienter som redan har en cachelagrad post, men vars giltighetstid har löpt ut och som gör en ny förfrågan.

Andelen "överskotts" förfrågningar minskar från 47% till 36% genom att enkelt ställa in en minimal TTL på 5 minuter. Vid en minimal TTL på 15 minuter minskar antalet dessa förfrågningar till 29%. En minimal TTL på 1 timme sänker dem till 17%. En betydande skillnad!

Vad sägs om att inte förändra något på serversidan, utan istället ställa in minimala TTL-värden i klienternas DNS-cacher (routrar, lokala resolvers)?

Antalet nödvändiga förfrågningar minskar från 47% till 34% vid en minimal TTL på 5 minuter, till 25% med ett minimum på 15 minuter och till 13% med ett minimum på 1 timme. Kanske är det optimala värdet 40 minuter.

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

Vad får detta för konsekvenser?

Självklart kan tjänsten överföras till en ny molnleverantör, en ny server, ett nytt nätverk, vilket kräver att kunderna använder de senaste DNS-posterna. En tillräckligt låg TTL hjälper till att göra en sådan övergång smidig och osynlig. Men med övergången till en ny infrastruktur förväntar sig ingen att kunderna skal byta till nya DNS-poster inom 1 minut, 5 minuter eller 15 minuter. Att sätta en minimal livslängd på 40 minuter istället för 5 minuter hindrar inte användarna från att få åtkomst till tjänsten.

Men detta kommer att kraftigt minska latensen och förbättra sekretessen och pålitligheten, genom att undvika onödiga förfrågningar.

Självklart säger RFC att man strikt ska följa TTL. Men verkligheten är att DNS-systemet har blivit för ineffektivt.

Om du arbetar med auktoritativa DNS-servrar, kontrollera vänligen dina TTL-värden. Behöver du verkligen så löjligt låga värden?

Självklart finns det goda skäl att ställa in små TTL-värden för DNS-poster. Men inte för 75% av DNS-trafiken som praktiskt taget inte förändras.

Och om du av någon anledning verkligen behöver använda låga TTL-värden för DNS, se också till att det inte finns något cachelagring aktiverat på din webbplats. Av samma skäl.

Om du har en lokal DNS-cache som fungerar, såsom dnscrypt-proxy, som låter dig ställa in en minimal TTL, använd denna funktion. Det är okej. Inget dåligt kommer att hända. Ställ in en minimal TTL på ungefär mellan 40 minuter (2400 sekunder) och 1 timme. En helt rimlig spann.

Källa: habr.com