Lav DNS-forsinkelse er nøkkelen til rask nettsurfing. For å minimere det er det viktig å nøye velge DNS-servere og . Men det første trinnet er å bli kvitt ubrukelige spørsmål.
Dette er grunnen til at DNS opprinnelig ble designet som en svært hurtigbufringsprotokoll. Soneadministratorer angir en time to live (TTL) for individuelle oppføringer, og løsere bruker denne informasjonen når de lagrer oppføringer i minnet for å unngå unødvendig trafikk.
Er caching effektiv? For et par år siden viste den lille forskningen min at den ikke var perfekt. La oss ta en titt på den nåværende situasjonen.
For å samle informasjon har jeg lappet for å lagre TTL-verdien for svaret. Det er definert som minimum TTL for sine poster 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 lappede 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 mindre støt på 86 (mest for SOA-poster), er det ganske tydelig at TTL-ene er i det lave området. La oss ta en nærmere titt:
Ok, TTL-er på mer enn 1 time er ikke statistisk signifikante. La oss så fokusere på området 0−3600:
De fleste TTL-er er fra 0 til 15 minutter:
De aller fleste er fra 0 til 5 minutter:
Det er ikke veldig bra.
Kumulativ fordeling gjør problemet enda mer åpenbart:
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. Tross alt er dette TTL fra autoritative servere. Imidlertid mottar klientløsere (f.eks. rutere, lokale cacher) en TTL fra oppstrømsløsere, og den reduseres hvert sekund.
Så klienten kan faktisk bruke hver oppføring for i gjennomsnitt halvparten av den opprinnelige TTL før han sender en ny forespørsel.
Kanskje disse svært lave TTL-ene bare gjelder uvanlige forespørsler og ikke populære nettsteder og API-er? La oss ta en titt:
X-aksen er TTL, Y-aksen er søkepopularitet.
Dessverre er de mest populære spørringene også de verste å cache.
La oss zoome inn:
Dom: det er virkelig ille. Det var allerede ille før, men det ble enda verre. DNS-bufring har blitt praktisk talt ubrukelig. Ettersom færre mennesker bruker Internett-leverandørens DNS-resolver (av gode grunner), blir økningen i latens mer merkbar.
DNS-bufring har blitt nyttig bare for innhold som ingen besøker.
Vær også oppmerksom på at programvaren kan tolke lave TTL-er.
Hvorfor så?
Hvorfor er DNS-poster satt til en så lav TTL?
- Eldre lastbalansere ble stående med standardinnstillinger.
- Det er myter om at DNS-belastningsbalansering avhenger av TTL (dette er ikke sant - siden Netscape Navigator-dagene har klienter valgt en tilfeldig IP-adresse fra et sett med RR-er og transparent prøvd en annen hvis de ikke kan koble seg til)
- Administratorer vil bruke endringer umiddelbart, så det er enklere å planlegge.
- Administratoren av en DNS-server eller lastbalanser ser på sin oppgave som å effektivt distribuere konfigurasjonen som brukere ber om, og ikke øke hastigheten på nettsteder og tjenester.
- Lave TTL-er gir deg trygghet.
- Folk satte i utgangspunktet lave TTL-er for testing og glemmer deretter å endre dem.
Jeg tok ikke med «failover» i listen 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 1 minutt sannsynligvis akseptabel.
I tillegg betyr en ett-minutters TTL at hvis autoritative DNS-servere er blokkert i mer enn 1 minutt, vil ingen andre kunne få tilgang til avhengige tjenester. Og redundans hjelper ikke hvis årsaken er en konfigurasjonsfeil eller et hack. På den annen side, med rimelige TTL-er, vil mange klienter fortsette å bruke den forrige konfigurasjonen og aldri merke noe.
CDN-tjenester og belastningsbalansere har i stor grad skylden for lave TTL-er, 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 30 sekunders TTL, men det er ikke det samme. Den faktiske gjennomsnittlige TTL vil være 15 sekunder.
Men vent! Det er enda verre. Noen løsere oppfører seg veldig dårlig i denne situasjonen med to tilhørende 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 forespørselen, vil en TTL på 1 alltid bli returnert. raw.githubusercontent.com er aldri bufret.
Her er et annet eksempel på en slik situasjon 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. Ja. Den ene har en grei TTL, men den er helt ubrukelig. Andre CNAME-er 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 spørre 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 sitte fast på 1 sekund mesteparten av tiden når du bruker 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 IN A 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
På opptaket safebrowsing.googleapis.com TTL-verdien er 60 sekunder, som Facebook-domener. Og igjen, fra klientens synspunkt, er disse verdiene halvert.
Hva med å sette et minimum TTL?
Ved å bruke navnet, forespørselstypen, TTL og det opprinnelig lagrede tidsstempelet, skrev jeg et skript for å simulere 1,5 millioner forespørsler som går gjennom en hurtigbufferoppløsning for å estimere volumet av unødvendige forespørsler som ble sendt på grunn av en utløpt cache-oppføring.
47,4 % av forespørslene ble gjort etter at en eksisterende post hadde utløpt. Dette er urimelig høyt.
Hva vil innvirkningen på caching hvis minimum TTL er satt?
X-aksen er minimum TTL-verdier. Poster med kilde-TTL-er over denne verdien påvirkes ikke.
Y-aksen er prosentandelen av forespørsler fra en klient som allerede har en bufret oppføring, men den har 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. Ved å sette minimum TTL til 15 minutter, synker antallet av disse forespørslene til 29 %. Et minimum TTL på 1 time reduserer dem til 17 %. Signifikant forskjell!
Hva med å ikke endre noe på serversiden, men i stedet sette minimum TTL i klientens DNS-cacher (rutere, lokale resolvere)?
Antall forespørsler som kreves synker fra 47 % til 34 % med minimum TTL på 5 minutter, til 25 % med minimum 15 minutter og til 13 % med minimum 1 time. Kanskje 40 minutter er optimalt.
Virkningen av denne lille endringen er enorm.
Hva er konsekvensene?
Selvfølgelig kan tjenesten flyttes til en ny skyleverandør, ny server, nytt nettverk, noe som krever at klienter bruker de siste DNS-postene. Og en ganske liten TTL bidrar til å gjøre en slik overgang jevnt og umerkelig. Men med overgangen til ny infrastruktur forventer ingen at klienter skal migrere til nye DNS-poster 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 personvernet og påliteligheten ved å unngå unødvendige forespørsler.
RFC-ene sier selvfølgelig at TTL må følges strengt. Men realiteten er at DNS-systemet har blitt for ineffektivt.
Hvis du jobber med autoritative DNS-servere, sjekk TTL-ene dine. Trenger du virkelig så latterlig lave verdier?
Selvfølgelig er det gode grunner til å sette små TTL-er for DNS-poster. Men ikke for de 75 % av DNS-trafikken som forblir praktisk talt uendret.
Og hvis du av en eller annen grunn virkelig trenger å bruke lave TTL-er for DNS, må du samtidig sørge for at nettstedet ditt ikke har caching aktivert. Av samme grunner.
Hvis du har en lokal DNS-cache som kjører, som f.eks som lar deg angi minimum TTL-er, bruk denne funksjonen. Dette er greit. Ingenting vondt vil skje. Sett minimum TTL til omtrent 40 minutter (2400 sekunder) og 1 time. Ganske rimelig rekkevidde.
Kilde: www.habr.com