domain Name System (DNS) latency er en nøkkelkomponent for å ha en god online opplevelse. Og for å minimere DNS-ventetid spiller nøye plukking AV DNS-servere og anonymiseringsreleer en viktig rolle. Men Den beste måten å minimere ventetid på er å unngå å sende ubrukelige spørringer til å begynne med. DERFOR BLE DNS designet, siden dag ett, for å være en tungt cacheable protokoll. Individuelle poster har en time-to-live (ttl), opprinnelig angitt av soneadministratorer, og resolvere bruker denne informasjonen til å holde disse postene i minnet for å unngå unødvendig trafikk.
er caching effektiv? En rask studie jeg gjorde for noen år siden viste at det var rom for forbedring. I dag vil jeg ta en ny titt på dagens situasjon.
for å gjøre det, lappet jeg En Kryptert DNS-Server for å lagre den opprinnelige TTL for et svar, definert som minimum TTL for sine poster, for hver innkommende spørring. Dette gir oss en god oversikt over VML-distribusjonen av reell trafikk, men forklarer også populariteten til individuelle spørringer.
den patched versjonen ble igjen for å løpe i et par timer. Det resulterende datasettet består av 1,583,579 (navn, qtype, TTL, tidsstempel) tuples. Her er den totale ttl-fordelingen (X-aksen er TTL i sekunder):
Foruten en ubetydelig bump på 86 400 (hovedsakelig FOR SOA-poster), er det ganske åpenbart At Ttler er i lavt område. La oss zoome inn:
Ok, TTLs over 1 time er statistisk ubetydelig. La oss fokusere på 0-3, 600-området:
Og hvor De fleste Ttler sitter mellom 0 og 15 minutter:
det store flertallet er mellom 0 og 5 minutter:
Dette er ikke bra. Den kumulative distribusjonen kan gjøre problemet enda mer åpenbart:
Halvparten Av Internett har en 1-minutters TTL eller mindre, og tre fjerdedeler har en 5-minutters TTL eller mindre.
men vent, dette er faktisk verre. Disse Er Ttler som definert av autoritative servere. Ttler hentet fra klientoppløsere (for eksempel rutere, lokale cacher) får imidlertid EN TTL som oppstrømsoppløsere avtar hvert sekund. Så i gjennomsnitt er den faktiske varigheten en klient kan bruke en bufret oppføring før du krever en ny spørring, halvparten av den opprinnelige TTL.
kanskje disse svært lave Ttlene bare påvirker uvanlige spørringer, og ikke populære nettsteder og Apier. La oss ta en titt:
Dessverre Er De mest populære spørringene også de mest meningsløse å cache. La oss zoome inn:
Verdict: det er veldig ille, eller rettere sagt det var allerede dårlig, og det er blitt verre. DNS caching har blitt ved siden av ubrukelig. Med færre personer som bruker ISP-ens DNS-resolver (av gode grunner), blir den økte latensen mer merkbar. DNS-caching har blitt bare nyttig for innhold som ingen besøker. Vær også oppmerksom på at programvare kan tolke lave Ttler annerledes.
Hvorfor?
Hvorfor er DNS-poster satt med så lave Ttler?
- Eldre lastbalansere er igjen med standardinnstillinger.
- den urbane legenden OM AT DNS-basert lastbalansering avhenger Av TTLs (det gjør det ikke).
- Administratorer ønsker at endringene skal brukes umiddelbart, fordi det kan kreve mindre planleggingsarbeid.
- som DNS-eller lastbalanseadministrator er din plikt å effektivt distribuere konfigurasjonen folk spør, ikke å lage nettsteder og tjenester raskt.
- Lave Ttler gir ro i sinnet.
jeg inkluderer ikke ‘for failover’ i den listen, da dette har blitt mindre og mindre relevant. Hvis hensikten er å omdirigere brukere til et annet nettverk bare for å vise en fail whale-side når absolutt alt annet er i brann, er det sannsynligvis akseptabelt å ha mer enn ett minutt forsinkelse.
Cdn – er og lastbalanserere er i stor grad skyldige, spesielt når DE kombinerer CNAME-poster med korte Ttler med poster som også har korte (men uavhengige) Ttler:
$ 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 spørring må sendes når CNAME eller Noen Av a-postene utløper. De har begge en 30-sekunders VML, men er ikke i fase. Den faktiske gjennomsnittlige TTL vil være 15 sekunder.
men vent! Dette er verre. Noen resolvere oppfører seg ganske dårlig i en slik lav-TTL-CNAME + low-TTL-poster situasjon:
$ 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 kjører BIND. Hvis du fortsetter å sende spørringen, vil den returnerte TTL alltid være 1. I hovedsak, raw.githubusercontent.com vil aldri bli bufret.
her er et annet eksempel på en lav-TTL-CNAME + lav-TTL-poster situasjon, med et veldig 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 enn tre CNAME-poster. Au. En av dem har en anstendig TML, men det er helt ubrukelig. Andre CNAMEs har en original TTL på 60 sekunder; akamai.net navnene har en maksimal TTL på 20 sekunder, og ingen av det er i fase.
Hva med En Som Apple-enheter stadig poll?
$ 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
samme konfigurasjon Som Firefox og TTL sitter fast til 1 mesteparten av tiden når Du bruker Level3s resolver.
Hva med 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-navnene har en 60-sekunders TTL. Og igjen, fra et klientperspektiv, bør disse verdiene halveres.
hva med å sette et minimum TTL?
Ved å Bruke navnet, spørringstypen, TTL og tidsstempel som ble lagret, skrev jeg et skript som simulerer 1,5+ millioner spørringer som går gjennom en caching-resolver for å anslå hvor mange spørringer som ble sendt på grunn av en utløpt cacheoppføring. 47,4% av spørringene ble gjort etter at en eksisterende, bufret oppføring var utløpt. Dette er urimelig høyt.
Hva ville være virkningen på caching hvis et minimum TTL ble satt?
X-aksen er den minste TTL som ble satt. Poster hvis opprinnelige TTL var høyere enn denne verdien, var upåvirket. Y-aksen er prosentandelen av spørringer som er gjort av en klient som allerede hadde en bufret oppføring, men en ny spørring ble gjort og den bufrede oppføringen var utløpt.
antall spørringer faller fra 47% til 36% bare ved å sette et MINIMUM TTL på 5 minutter. Ved å angi ET MINIMUM TTL på 15 minutter reduseres antallet nødvendige spørringer til 29%. ET MINIMUM TTL på 1 time gjør det slippe til 17%. Det er en betydelig forskjell!
Hva med å ikke endre noe server-side, men å ha klient DNS-cacher (rutere, lokale resolvere og cacher…) sett et minimum TTL i stedet?
antallet nødvendige spørringer faller fra 47% til 34% ved å sette 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 kanskje et søtt sted. Effekten av den minimale endringen er enorm.
hva er konsekvensene?
selvfølgelig kan en tjeneste bytte til en ny skyleverandør, en ny server, et nytt nettverk, som krever at klienter bruker oppdaterte DNS-poster. Og å ha rimelig lave Ttler bidrar til å gjøre overgangen friksjonsfri. Men ingen som flytter til en ny infrastruktur kommer til å forvente at kundene skal bruke DE nye DNS-postene innen 1 minutt, 5 minutter eller 15 minutter.
Å Sette EN MINIMUM TTL på 40 minutter i stedet for 5 minutter, forhindrer ikke brukere i å få tilgang til tjenesten. Det vil imidlertid drastisk redusere ventetid, og forbedre personvernet (flere spørringer = flere sporingsmuligheter) og pålitelighet ved å unngå unødvendige spørringer.
Selvfølgelig Sier Rfc at Ttler bør respekteres strengt. MEN realiteten er AT DNS har blitt ineffektiv.
hvis du driver autoritative DNS-servere, kan du gå tilbake TTLs. Trenger du virkelig disse til å være latterlig lav?
Les: HVORDAN velge DNS TTL-verdier
Visst, det er gyldige grunner til å bruke lave DNS Ttler. Men ikke for 75% Av Internett for å betjene innhold som for det meste er uforanderlig, men meningsløst å cache. Og hvis du av en eller annen grunn virkelig trenger å bruke lave DNS-Ttler, må du også sørge for at cachen ikke fungerer på nettstedet ditt heller. Av samme grunner.
hvis du bruker en lokal DNS-buffer, for eksempel dnscrypt-proxy, som gjør det mulig å angi minimum Ttler, kan du bruke denne funksjonen. Dette er greit. Ingenting dårlig vil skje. Sett det minste TTL til noe mellom 40 minutter (2400 sekunder) og 1 time; dette er et helt rimelig utvalg.
Tilpasset fra opprinnelig innlegg som dukket opp på 00f.net