Lav DNS-forsinkelse er en nøkkelfaktor for rask surfing. For å minimere den er det viktig å velge DNS-servere nøye og Men det første du må gjøre er å kvitte deg med unødvendige spørringer.
Dette er grunnen til at DNS opprinnelig ble utviklet som en protokoll som kan mellomlagres med høy bufferkapasitet. Soneadministratorer setter en TTL (time to live) for individuelle poster, og resolvere bruker denne informasjonen når de lagrer poster i minnet for å unngå unødvendig trafikk.
Er mellomlagring effektiv? For et par år siden viste min lille forskning at den ikke er perfekt. La oss se på den nåværende situasjonen.
For å samle inn informasjon jeg oppdaterte å lagre TTL-verdien for svaret. Den er definert som minimum TTL for postene, for hver innkommende forespørsel. Dette gir en god oversikt over TTL-fordelingen av reell trafikk, og tar også hensyn til populariteten til individuelle forespørsler. Den oppdaterte versjonen av serveren fungerte i flere timer.
Det resulterende datasettet består av 1 583 579 poster (navn, qtype, TTL, tidsstempel). Her er den generelle TTL-fordelingen (x-aksen er TTL i sekunder):
Bortsett fra en liten økning på 86 400 (hovedsakelig for SOA-poster), er det ganske tydelig at TTL-ene er i det lave området. La oss ta en nærmere titt:
Greit, TTL-er over 1 time er statistisk ubetydelige. La oss fokusere på området 0–3600 da:
De fleste TTL-er er mellom 0 og 15 minutter:
De aller fleste er fra 0 til 5 minutter:
Dette er ikke særlig bra.
Kumulativ fordeling gjør problemet enda tydeligere:
Halvparten av DNS-svarene har en TTL på 1 minutt eller mindre, og tre fjerdedeler har en TTL på 5 minutter eller mindre.
Men vent, det er faktisk verre. Dette er TTL-en fra de autoritative serverne. Klientresolvere (f.eks. rutere, lokale hurtigbuffere) får imidlertid TTL-en fra oppstrømsresolvere, og den avtar hvert sekund.
Dermed kan klienten faktisk bruke hver post i gjennomsnitt halvparten av den opprinnelige TTL-en før en ny forespørsel sendes.
Kanskje disse svært lave TTL-ene bare påvirker uvanlige forespørsler og ikke populære nettsteder og API-er? La oss ta en titt:
X-aksen er TTL, Y-aksen er spørringens popularitet.
Dessverre er de mest populære søkene også de dårligst bufrede.
La oss zoome inn:
Konklusjon: Det er virkelig ille. Det var allerede ille, og det har blitt verre. DNS-caching har blitt så godt som ubrukelig. Etter hvert som færre bruker internettleverandørens DNS-resolver (med gode grunner), blir økningen i latens mer merkbar.
DNS-caching har bare blitt nyttig for innhold som ingen besøker.
Vær også oppmerksom på at programvaren kan tolke lave TTL-er.
Hvorfor så?
Hvorfor er DNS-oppføringer satt til en så lav TTL?
- Eldre lastfordelere beholdes med standardinnstillingene.
- Det finnes myter om at DNS-belastningsbalansering er avhengig av TTL (dette stemmer ikke – siden Netscape Navigator velger klienter en tilfeldig IP-adresse fra RR-settet og prøver en annen hvis de ikke kan koble til).
- Administratorer ønsker å implementere endringer umiddelbart, slik at det er enklere å planlegge.
- Administratoren av en DNS-server eller lastbalanserer ser på oppgaven sin som å effektivt distribuere konfigurasjonen som brukerne ber om, og ikke å øke hastigheten på driften av nettsteder og tjenester.
- Lav TTL gir trygghet.
- Folk setter i utgangspunktet lave TTL-verdier for testing, og glemmer deretter å endre dem.
Jeg inkluderte ikke «failover» fordi det blir mindre og mindre relevant. Hvis du trenger å omdirigere brukere til et annet nettverk bare for å vise en feilside når absolutt alt annet er ødelagt, er en forsinkelse på mer enn ett minutt sannsynligvis akseptabelt.
I tillegg betyr en ett-minutts TTL at hvis autoritative DNS-servere er blokkert i mer enn ett minutt, vil ingen andre kunne få tilgang til avhengige tjenester. Og redundans vil ikke hjelpe hvis årsaken er en konfigurasjonsfeil eller et hacking. På den annen side, med rimelige TTL-er, vil mange klienter fortsette å bruke den forrige konfigurasjonen og aldri legge merke til det.
Lave TTL-er er i stor grad feilen til CDN-tjenester og lastbalansører, spesielt når de kombinerer CNAME-er med lave TTL-er og poster med like lave (men uavhengige) 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 noen av A-postene utløper, må en ny forespørsel sendes. Begge har en TTL på 30 sekunder, men de er ikke like. Den faktiske gjennomsnittlige TTL-tiden vil være 15 sekunder.
Men vent! Det blir verre. Noen resolvere oppfører seg veldig dårlig i denne situasjonen med to sammenkoblede 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 I A 151.101.16.133
Level3-resolveren kjører sannsynligvis på BIND. Hvis du fortsetter å sende denne spørringen, vil den alltid returnere en TTL på 1. I hovedsak, raw.githubusercontent.com aldri mellomlagret.
Her er et annet eksempel på denne situasjonen med et veldig populært domene:
$ 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. Au. En har en anstendig TTL, men den er fullstendig ubrukelig. De andre CNAME-ene har en initial TTL på 60 sekunder, men for domener akamai.net Maksimal TTL er 20 sekunder, og ingen av dem er i fase.
Hva med domener som stadig vekk avspør 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
Samme problem som Firefox, og TTL vil henge seg opp i 1 sekund mesteparten av tiden når man bruker Level3-resolveren.
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
På opptaket safebrowsing.googleapis.com TTL-verdi på 60 sekunder, akkurat som Facebook-domener. Og igjen, fra klientens perspektiv, er disse verdiene halvert.
Hva med å sette en minimum TTL?
Ved å bruke navn, forespørselstype, TTL og opprinnelig lagret tidsstempel, skrev jeg et skript for å simulere 1,5 millioner forespørsler som går gjennom en mellomlagringsresolver for å estimere mengden ekstra forespørsler som sendes på grunn av en utløpt mellomlagringsoppføring.
47,4 % av forespørslene ble gjort etter at den eksisterende registreringstiden var utløpt. Dette er urimelig høyt.
Hva vil effekten på mellomlagring være hvis en minimum TTL settes?
X-aksen er minimums-TTL-verdiene. Poster med rå-TTL-er over denne verdien påvirkes ikke.
Y-aksen er prosentandelen av forespørsler fra en klient som allerede har en hurtigbufret oppføring, men den er utløpt og sender en ny forespørsel.
Andelen «ekstra» forespørsler reduseres fra 47 % til 36 % ved ganske enkelt å sette minimum TTL til 5 minutter. Å sette minimum TTL til 15 minutter reduserer antallet av disse forespørslene til 29 %. En minimum TTL på 1 time reduserer dem til 17 %. En betydelig forskjell!
Hva med å ikke endre noe på serversiden, men i stedet sette minimum TTL-er i klientens DNS-cacher (rutere, lokale resolvere)?
Antall nødvendige forespørsler faller fra 47 % til 34 % når minimum TTL settes til 5 minutter, til 25 % med minimum 15 minutter, og til 13 % med minimum 1 time. Kanskje 40 minutter er optimalt.
Effekten av denne minimale endringen er enorm.
Hva er konsekvensene?
Jada, du kan migrere en tjeneste til en ny skyleverandør, en ny server, et nytt nettverk og kreve at kundene bruker de nyeste DNS-oppføringene. Og en liten nok TTL bidrar til å gjøre overgangen smidig og sømløs. Men når du migrerer til en ny infrastruktur, forventer ingen at kundene migrerer til de nye DNS-oppføringene innen 1 minutt, 5 minutter eller 15 minutter. Å sette minimum TTL til 40 minutter i stedet for 5 minutter vil ikke hindre brukere i å få tilgang til tjenesten.
Dette vil imidlertid redusere ventetiden betydelig og forbedre personvern og pålitelighet ved å unngå unødvendige forespørsler.
Jada, RFC-ene sier at TTL-er bør håndheves strengt. Men realiteten er at DNS-systemet har blitt for ineffektivt.
Hvis du jobber med autoritative DNS-servere, bør du sjekke TTL-ene dine. Trenger du virkelig så latterlig lave verdier?
Selvfølgelig finnes det gode grunner til å sette lave TTL-er for DNS-oppføringer. Men ikke for de 75 % av DNS-trafikken som knapt endrer seg.
Og hvis du av en eller annen grunn virkelig trenger å bruke lave TTL-er for DNS, må du også sørge for at nettstedet ditt ikke har aktivert mellomlagring. Av samme grunner.
Hvis du har en lokal DNS-cache kjørende, for eksempel , som lar deg stille inn minimum TTL, bruk denne funksjonen. Dette er normalt. Ingenting galt vil skje. Sett minimum TTL til et sted mellom 40 minutter (2400 sekunder) og 1 time. Et rimelig område.
Kilde: www.habr.com
