Lav DNS-forsinkelse er nøglen til hurtig internetbrowsing. For at minimere det er det vigtigt omhyggeligt at vælge DNS-servere og . Men det første skridt er at slippe af med ubrugelige forespørgsler.
Dette er grunden til, at DNS oprindeligt blev designet som en protokol, der kan cachelagres. Zoneadministratorer indstiller en time to live (TTL) for individuelle poster, og resolvere bruger disse oplysninger, når de gemmer poster i hukommelsen for at undgå unødvendig trafik.
Er caching effektiv? For et par år siden viste min lille research, at den ikke var perfekt. Lad os tage et kig på den aktuelle situation.
For at indsamle oplysninger har jeg rettet for at gemme TTL-værdien for svaret. Det er defineret som minimums-TTL for dets poster for hver indkommende anmodning. Dette giver et godt overblik over TTL-fordelingen af reel trafik, og tager også højde for populariteten af individuelle anmodninger. Den patchede version af serveren virkede i flere timer.
Det resulterende datasæt består af 1 poster (navn, qtype, TTL, tidsstempel). Her er den overordnede TTL-fordeling (X-aksen er TTL i sekunder):
Bortset fra et mindre bump ved 86 (mest for SOA-poster), er det ret tydeligt, at TTL'erne er i det lave område. Lad os se nærmere:
Okay, TTL'er på mere end 1 time er ikke statistisk signifikante. Lad os derefter fokusere på området 0-3600:
De fleste TTL'er er fra 0 til 15 minutter:
Langt de fleste er fra 0 til 5 minutter:
Det er ikke særlig godt.
Kumulativ fordeling gør problemet endnu mere indlysende:
Halvdelen af DNS-svarene har en TTL på 1 minut eller mindre, og tre fjerdedele har en TTL på 5 minutter eller mindre.
Men vent, det er faktisk værre. Dette er trods alt TTL fra autoritative servere. Imidlertid modtager klientresolvere (f.eks. routere, lokale caches) en TTL fra upstream-resolvere, og den falder hvert sekund.
Så klienten kan faktisk bruge hver post til i gennemsnit halvdelen af den oprindelige TTL, før den sender en ny anmodning.
Måske gælder disse meget lave TTL'er kun for usædvanlige anmodninger og ikke populære websteder og API'er? Lad os tage et kig:
X-aksen er TTL, Y-aksen er forespørgselspopularitet.
Desværre er de mest populære forespørgsler også de værste at cache.
Lad os zoome ind:
Bedømmelse: det er virkelig slemt. Det var allerede slemt før, men det blev endnu værre. DNS-caching er blevet praktisk talt ubrugelig. Efterhånden som færre bruger deres internetudbyders DNS-resolver (af gode grunde), bliver stigningen i latens mere mærkbar.
DNS-caching er kun blevet nyttigt for indhold, som ingen besøger.
Bemærk også, at softwaren evt fortolke lave TTL'er.
Hvorfor så?
Hvorfor er DNS-poster sat til så lav en TTL?
- Ældre belastningsbalancere blev efterladt med standardindstillinger.
- Der er myter om, at DNS-belastningsbalancering afhænger af TTL (dette er ikke sandt - siden Netscape Navigators dage har klienter valgt en tilfældig IP-adresse fra et sæt RR'er og gennemsigtigt prøvet en anden, hvis de ikke kan oprette forbindelse)
- Administratorer ønsker at anvende ændringer med det samme, så det er nemmere at planlægge.
- Administratoren af en DNS-server eller load balancer ser sin opgave som effektivt at implementere den konfiguration, som brugerne anmoder om, og ikke at fremskynde websteder og tjenester.
- Lave TTL'er giver dig ro i sindet.
- Folk satte oprindeligt lave TTL'er til test og glemmer derefter at ændre dem.
Jeg har ikke inkluderet "failover" på listen, fordi det bliver mindre og mindre relevant. Hvis du har brug for at omdirigere brugere til et andet netværk bare for at vise en fejlside, når absolut alt andet er brudt, er en forsinkelse på mere end 1 minut sandsynligvis acceptabel.
Derudover betyder en et-minuts TTL, at hvis autoritative DNS-servere er blokeret i mere end 1 minut, vil ingen andre være i stand til at få adgang til afhængige tjenester. Og redundans hjælper ikke, hvis årsagen er en konfigurationsfejl eller et hack. På den anden side, med rimelige TTL'er, vil mange klienter fortsætte med at bruge den tidligere konfiguration og aldrig bemærke noget.
CDN-tjenester og load balancere er i høj grad skyld i lave TTL'er, især når de kombinerer CNAME'er med lave TTL'er og poster med lige så lave (men uafhængige) 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
Hver gang CNAME eller nogen af A-posterne udløber, skal der sendes en ny anmodning. Begge har en 30 sekunders TTL, men det er ikke det samme. Den faktiske gennemsnitlige TTL vil være 15 sekunder.
Men vent! Det er endnu værre. Nogle resolvere opfører sig meget dårligt i denne situation med to tilknyttede lave TTL'er:
$ drill 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-resolveren kører sandsynligvis på BIND. Hvis du fortsætter med at sende denne anmodning, vil en TTL på 1 altid blive returneret. raw.githubusercontent.com er aldrig cachelagret.
Her er endnu et eksempel på en sådan situation med et meget populært domæne:
$ 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
Mindst tre CNAME-poster. Ja. Den ene har en anstændig TTL, men den er fuldstændig ubrugelig. Andre CNAME'er har en initial TTL på 60 sekunder, men for domæner akamai.net den maksimale TTL er 20 sekunder, og ingen af dem er i fase.
Hvad med domæner, der konstant poller Apple-enheder?
$ 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
Samme problem som Firefox og TTL vil sidde fast på 1 sekund det meste af tiden, når du bruger 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 I EN 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
Ved optagelsen safebrowsing.googleapis.com TTL-værdien er 60 sekunder, ligesom Facebook-domæner. Og igen, fra kundens synspunkt, er disse værdier halveret.
Hvad med at indstille en minimum TTL?
Ved at bruge navnet, anmodningstypen, TTL og det oprindeligt gemte tidsstempel skrev jeg et script til at simulere 1,5 millioner anmodninger, der passerede gennem en caching-resolver for at estimere mængden af unødvendige anmodninger, der blev sendt på grund af en udløbet cache-indgang.
47,4 % af anmodningerne blev fremsat efter en eksisterende registrering var udløbet. Dette er urimeligt højt.
Hvad vil indvirkningen på caching være, hvis minimum TTL er indstillet?
X-aksen er minimum TTL-værdier. Records med kilde-TTL'er over denne værdi påvirkes ikke.
Y-aksen er procentdelen af anmodninger fra en klient, der allerede har en cachepost, men den er udløbet og laver en ny anmodning.
Andelen af "ekstra" anmodninger reduceres fra 47 % til 36 % ved blot at sætte minimums-TTL til 5 minutter. Ved at indstille minimum TTL til 15 minutter falder antallet af disse anmodninger til 29 %. En minimum TTL på 1 time reducerer dem til 17%. Betydelig forskel!
Hvad med ikke at ændre noget på serversiden, men i stedet sætte minimum TTL i klientens DNS-cache (routere, lokale resolvere)?
Antallet af krævede anmodninger falder fra 47 % til 34 % med en minimum TTL på 5 minutter, til 25 % med minimum 15 minutter og til 13 % med minimum 1 time. Måske 40 minutter er optimalt.
Virkningen af denne lille ændring er enorm.
Hvad er konsekvenserne?
Selvfølgelig kan tjenesten flyttes til en ny cloud-udbyder, ny server, nyt netværk, hvilket kræver, at klienter bruger de seneste DNS-poster. Og en ret lille TTL er med til at gøre sådan en overgang jævnt og umærkeligt. Men med overgangen til ny infrastruktur forventer ingen, at klienter migrerer til nye DNS-poster inden for 1 minut, 5 minutter eller 15 minutter. Indstilling af minimum TTL til 40 minutter i stedet for 5 minutter forhindrer ikke brugere i at få adgang til tjenesten.
Dette vil dog reducere ventetiden betydeligt og forbedre privatlivets fred og pålidelighed ved at undgå unødvendige anmodninger.
RFC'erne siger selvfølgelig, at TTL skal følges nøje. Men virkeligheden er, at DNS-systemet er blevet for ineffektivt.
Hvis du arbejder med autoritative DNS-servere, skal du tjekke dine TTL'er. Har du virkelig brug for så latterligt lave værdier?
Selvfølgelig er der gode grunde til at sætte små TTL'er til DNS-poster. Men ikke for de 75 % af DNS-trafikken, der forbliver stort set uændret.
Og hvis du af en eller anden grund virkelig skal bruge lave TTL'er til DNS, så sørg samtidig for, at dit websted ikke har caching aktiveret. Af samme grunde.
Hvis du har en lokal DNS-cache kørende, som f.eks som giver dig mulighed for at indstille minimum TTL'er, brug denne funktion. Det er fint. Intet dårligt vil ske. Indstil minimum TTL til cirka 40 minutter (2400 sekunder) og 1 time. Ganske rimelig rækkevidde.
Kilde: www.habr.com