Lav DNS-forsinkelse er nøglen til hurtig browsing. For at minimere det er det vigtigt omhyggeligt at vælge DNS-servere og . Men den første ting du skal gøre 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 registreringer for hver indkommende anmodning. Dette giver et godt overblik over TTL-fordelingen af reel trafik og tager også højde for individuelle forespørgslers popularitet. 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 lille 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:
Ok, TTL'er over 1 time er ikke statistisk signifikante. Lad os derefter fokusere på området 0-3600:
De fleste TTL'er er mellem 0 og 15 minutter:
Langt de fleste er fra 0 til 5 minutter:
Det her er ikke særlig godt.
Kumulativ fordeling gør problemet endnu mere indlysende:
Halvdelen af DNS-svar 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) TTL fra upstream-resolvere, og det falder hvert sekund.
Dermed kan klienten faktisk bruge hver post til i gennemsnit halvdelen af den oprindelige TTL, før den sender en ny anmodning.
Måske påvirker disse meget lave TTL'er kun 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 dårligste cachelagrede.
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å lille en TTL?
- Ældre belastningsbalancere er tilbage med standardindstillinger.
- Der er myter om, at DNS-belastningsbalancering afhænger af TTL (dette er ikke sandt - siden Netscape Navigator vælger klienter en tilfældig IP-adresse fra RR-sættet og prøver gennemsigtigt 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, brugerne anmoder om, og ikke fremskynde driften af websteder og tjenester.
- Lav TTL giver 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 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 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.
Lave TTL'er er i vid udstrækning skyld i CDN-tjenester og load balancers, 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 en af A-posterne udløber, skal der sendes en ny anmodning. Begge har 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 forbundne 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, returnerer den altid en TTL på 1. raw.githubusercontent.com aldrig cachelagret.
Her er endnu et eksempel på denne 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 anstændig TTL, men den er fuldstændig ubrugelig. I andre CNAME'er er den indledende TTL 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, det samme som 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 går gennem en caching-resolver for at estimere mængden af ekstra anmodninger sendt på grund af en udløbet cache-indgang.
47,4 % af anmodningerne blev fremsat efter den eksisterende rekord var udløbet. Dette er urimeligt højt.
Hvad vil påvirkningen have på caching, hvis der er indstillet et minimum af TTL?
X-aksen er minimum TTL-værdier. Records med originale 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 en minimum TTL på 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'er i klientens DNS-cache (routere, lokale resolvere)?
Antallet af påkrævede anmodninger reduceres fra 47 % til 34 % ved indstilling af en minimum TTL på 5 minutter, til 25 % med minimum 15 minutter og til 13 % med minimum 1 time. Måske er den optimale værdi 40 minutter.
Virkningen af denne minimale ændring er enorm.
Hvad er konsekvenserne?
Selvfølgelig kan tjenesten migreres til en ny cloud-udbyder, en ny server, et 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 en ny infrastruktur forventer ingen, at kunderne migrerer til nye DNS-poster inden for 1 minut, 5 minutter eller 15 minutter. Indstilling af minimumslevetiden 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.
Selvfølgelig siger RFC'erne, at TTL skal overholdes strengt. 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 indstille 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 har brug for at bruge lave TTL'er til DNS, så sørg også for, at caching ikke er aktiveret på dit websted. Af samme grunde.
Hvis du har en lokal DNS-cache kørende, som f.eks , som giver dig mulighed for at indstille minimum TTL, brug denne funktion. Det er fint. Intet dårligt vil ske. Indstil minimum TTL til cirka 40 minutter (2400 sekunder) og 1 time. En ganske fornuftig rækkevidde.
Kilde: www.habr.com
