Domain Name System (DNS) latency er en nøglekomponent til at have en god online oplevelse. Og for at minimere DNS-latenstid spiller omhyggeligt valg af DNS-servere og anonymiseringsrelæer en vigtig rolle.
men den bedste måde at minimere latenstid på er at undgå at sende ubrugelige forespørgsler til at begynde med. Derfor blev DNS designet siden første dag til at være en stærkt cacheabel protokol. Individuelle poster har en time-to-live (TTL), oprindeligt indstillet af områdeadministratorer, og resolvere bruger disse oplysninger til at opbevare disse poster i hukommelsen for at undgå unødvendig trafik.
er caching effektiv? En hurtig undersøgelse, jeg lavede for et par år siden, viste, at der var plads til forbedringer. I dag vil jeg tage et nyt kig på den aktuelle situation.
for at gøre det lappede jeg en krypteret DNS-Server for at gemme den originale TTL for et svar, defineret som den mindste TTL for dens poster, for hver indgående forespørgsel. Dette giver os et godt overblik over TTL-distributionen af den virkelige trafik, men tegner os også for populariteten af individuelle forespørgsler.
den patched version blev efterladt til at køre i et par timer. Det resulterende datasæt består af 1.583.579 (navn, kvtype, TTL, tidsstempel) tupler. Her er den samlede TTL – fordeling (aksen er TTL i sekunder):
udover en ubetydelig bump på 86.400 (hovedsagelig for SOA records), er det ret indlysende, at TTL ‘ er er i det lave område.
okay, TTL ‘ er over 1 time er statistisk ubetydelige. Lad os fokusere på området 0-3,600:
og hvor de fleste TTL ‘ er sidder mellem 0 og 15 minutter:
langt størstedelen er mellem 0 og 5 minutter:
Dette er ikke godt. Den kumulative fordeling kan gøre problemet endnu mere indlysende:
halvdelen af internettet har en 1-minutters TTL eller mindre, og tre fjerdedele har en 5-minutters TTL eller mindre.
men vent, det er faktisk værre. Disse er TTL ‘ er som defineret af autoritative servere. Imidlertid får TTL ‘ er hentet fra klientopløsere (for eksempel routere, lokale cacher) en TTL, der opstrømsopløsere formindsker hvert sekund. Så i gennemsnit er den faktiske varighed, som en klient kan bruge en cachelagret post, før der kræves en ny forespørgsel, halvdelen af den originale TTL.
måske påvirker disse meget lave TTL ‘er kun usædvanlige forespørgsler og ikke populære hjemmesider og API’ er. Lad os tage et kig:
Desværre er de mest populære forespørgsler også de mest meningsløse at cache. Lad os gå ind:
bedømmelse: det er virkelig dårligt, eller rettere det var allerede dårligt, og det er blevet værre. DNS-caching er blevet næsten ubrugelig. Med færre mennesker, der bruger deres internetudbyders DNS-resolver (af gode grunde), bliver den øgede latenstid mere mærkbar. DNS-caching er kun blevet nyttigt til indhold, som ingen besøger. Bemærk også, at programmer kan fortolke lave TTL ‘ er forskelligt.
hvorfor?
hvorfor er DNS-poster indstillet med så lave TTL ‘ er?
- Legacy load balancers er tilbage med standardindstillinger.
- den urbane legende om, at DNS-baseret belastningsbalancering afhænger af TTLs (det gør det ikke).
- administratorer, der ønsker, at deres ændringer skal anvendes med det samme, fordi det kan kræve mindre planlægningsarbejde.
- som DNS-eller load-balancer-administrator er din pligt at effektivt implementere den konfiguration, folk spørger, ikke at gøre hjemmesider og tjenester hurtige.
- lave TTL ‘ er giver ro i sindet.
Jeg inkluderer ikke ‘for failover’ på denne liste, da dette er blevet mindre og mindre relevant. Hvis hensigten er at omdirigere brugere til et andet netværk bare for at vise en fejlhvalside, når absolut alt andet er i brand, er det sandsynligvis acceptabelt at have mere end et minuts forsinkelse.
CDN ‘er og load-balancere har stort set skylden, især når de kombinerer CNAME-poster med korte TTL’ er med poster, der også har korte (men uafhængige) TTL ‘ er:
$ 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 forespørgsel skal sendes, når CNAME eller nogen af A-posterne udløber. De har begge en 30-sekunders TTL, men er ikke i fase. Den faktiske gennemsnitlige TTL vil være 15 sekunder.
men vent! Det er værre. Nogle resolvere opfører sig temmelig dårligt i en så lav-TTL-CNAME+lav-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
Dette er Level3s resolver, som jeg tror kører BIND. Hvis du fortsætter med at sende denne forespørgsel, vil den returnerede TTL altid være 1. I det væsentlige, raw.githubusercontent.com vil aldrig blive cachelagret.
Her er et andet eksempel på en situation med lav-TTL-CNAME+lav-TTL-poster med et meget populært navn:
$ 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
ikke mindre end tre CNAME-poster. Av. En af dem har en anstændig TTL, men det er helt ubrugeligt. Andre CNAMEs har en original TTL på 60 sekunder; akamai.net Navne har en maksimal TTL på 20 sekunder, og intet af det er i fase.
hvad med en, som dine Apple-enheder konstant afstemmer?
$ 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
den samme konfiguration som Firefoks og TTL sidder fast til 1 det meste af tiden, når du bruger Level3s resolver.
hvad så?
$ 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-Navne har en 60-sekunders TTL. Og endnu en gang, fra et klientperspektiv, bør disse værdier halveres.
hvad med at indstille et minimum TTL?
Ved hjælp af navnet, forespørgselstypen, TTL og tidsstemplet, der oprindeligt blev gemt, skrev jeg et script, der simulerer de 1,5+ millioner forespørgsler, der går gennem en cacheopløser for at estimere, hvor mange forespørgsler der blev sendt på grund af en udløbet cache-post. 47,4% af forespørgslerne blev foretaget, efter at en eksisterende cachelagret Post var udløbet. Dette er urimeligt højt.
Hvad ville have indflydelse på caching, hvis der blev indstillet et minimum TTL?
h-aksen er den mindste TTL, der blev indstillet. Poster, hvis oprindelige TTL var højere end denne værdi, var upåvirket. Y-aksen er procentdelen af forespørgsler foretaget af en klient, der allerede havde en cachelagret post, men en ny forespørgsel blev foretaget, og den cachelagrede Post var udløbet.
antallet af forespørgsler falder fra 47% Til 36% bare ved at indstille et minimum TTL på 5 minutter. Indstilling af et minimum TTL på 15 minutter får antallet af krævede forespørgsler til at falde til 29%. Et minimum TTL på 1 time gør det falde til 17%. Det er en væsentlig forskel!
hvad med ikke at ændre noget server-side, men at have klient DNS caches (routere, lokale resolvere og caches…) sæt et minimum TTL i stedet?
antallet af krævede forespørgsler falder fra 47% Til 34% ved at indstille et minimum TTL på 5 minutter, til 25% med et minimum på 15 minutter og til 13% med et minimum på 1 time. 40 minutter måske en sød plet. Virkningen af den minimale ændring er enorm.
hvad er konsekvenserne?
selvfølgelig kan en tjeneste skifte til en ny skyudbyder, en ny server, et nyt netværk, der kræver, at klienter bruger opdaterede DNS-poster. Og at have rimeligt lave TTL ‘ er hjælper med at gøre overgangen friktionsfri. Ingen, der flytter til en ny infrastruktur, forventer dog, at klienter bruger de nye DNS-poster inden for 1 minut, 5 minutter eller 15 minutter.
Indstilling af et minimum TTL på 40 minutter i stedet for 5 minutter forhindrer ikke brugere i at få adgang til tjenesten. Det vil dog drastisk reducere latenstiden og forbedre privatlivets fred (flere forespørgsler = flere sporingsmuligheder) og pålidelighed ved at undgå unødvendige forespørgsler.
selvfølgelig siger RFC ‘er, at TTL’ er skal overholdes strengt. Men virkeligheden er, at DNS er blevet ineffektiv.
Hvis du driver autoritative DNS-servere, skal du besøge dine TTLs igen. Har du virkelig brug for disse for at være latterligt lave?
Læs: Sådan vælger du DNS TTL-værdier
sikker på, at der er gyldige grunde til at bruge lave DNS TTLs. Men ikke for 75% af internettet til at servere indhold, der for det meste er uforanderligt, men meningsløst at cache. Og hvis du af en eller anden grund virkelig skal bruge lave DNS TTLs, skal du også sørge for, at cachen heller ikke virker på din hjemmeside. Af de samme grunde.
Hvis du bruger en lokal DNS-cache som dnscrypt-fuldmagt, der gør det muligt at indstille minimum TTL ‘ er, skal du bruge denne funktion. Det er okay. Intet dårligt vil ske. Indstil det mindste TTL til noget mellem 40 minutter (2400 sekunder) og 1 time; dette er et helt rimeligt interval.
tilpasset fra originalt indlæg, som dukkede op på 00f.net