Niska DNS latencija je ključna za brzo pretraživanje interneta. Da biste ga minimizirali, važno je pažljivo odabrati DNS servere i . Ali prvi korak je da se riješite beskorisnih upita.
Zbog toga je DNS prvobitno dizajniran kao protokol koji se može keširati. Administratori zone postavljaju vrijeme života (TTL) za pojedinačne unose, a razrješači koriste ove informacije kada pohranjuju unose u memoriju kako bi izbjegli nepotreban promet.
Da li je keširanje efikasno? Prije nekoliko godina, moje malo istraživanje je pokazalo da nije savršeno. Pogledajmo trenutno stanje stvari.
Za prikupljanje informacija sam zakrpio da sačuvate TTL vrijednost za odgovor. Definiše se kao minimalni TTL njegovih zapisa za svaki dolazni zahtjev. Ovo daje dobar pregled TTL distribucije stvarnog prometa, a uzima u obzir i popularnost pojedinačnih zahtjeva. Zakrpljena verzija servera radila je nekoliko sati.
Rezultirajući skup podataka sastoji se od 1 zapisa (ime, qtype, TTL, vremenska oznaka). Evo ukupne TTL distribucije (X-osa je TTL u sekundama):
Osim manjeg porasta na 86 (uglavnom za SOA zapise), prilično je jasno da su TTL-ovi u niskom rasponu. Pogledajmo izbliza:
U redu, TTL duži od 1 sata nisu statistički značajni. Zatim se fokusirajmo na raspon 0−3600:
Većina TTL-ova je od 0 do 15 minuta:
Velika većina je od 0 do 5 minuta:
Nije baš dobro.
Kumulativna distribucija čini problem još očiglednijim:
Polovina DNS odgovora ima TTL od 1 minute ili manje, a tri četvrtine ima TTL od 5 minuta ili manje.
Ali čekajte, zapravo je gore. Na kraju krajeva, ovo je TTL sa autoritativnih servera. Međutim, klijentski razrješači (npr. ruteri, lokalni kešovi) primaju TTL od uzvodnih razrješavača i on se smanjuje svake sekunde.
Dakle, klijent može zapravo koristiti svaki unos za, u prosjeku, polovinu originalnog TTL-a prije nego što pošalje novi zahtjev.
Možda se ovi vrlo niski TTL-ovi odnose samo na neobične zahtjeve, a ne na popularne web stranice i API-je? Hajde da pogledamo:
X osa je TTL, osa Y je popularnost upita.
Nažalost, najpopularniji upiti su i najgori za keširanje.
Uvećajmo:
Presuda: zaista je loše. Već je prije bilo loše, ali je postalo još gore. DNS keširanje je postalo gotovo beskorisno. Kako sve manje ljudi koristi DNS rezolver svog ISP-a (iz dobrih razloga), povećanje latencije postaje primjetnije.
DNS keširanje postalo je korisno samo za sadržaj koji niko ne posjećuje.
Također imajte na umu da softver može interpretirati niske TTL-ove.
Zašto je to tako?
Zašto su DNS zapisi postavljeni na tako nizak TTL?
- Naslijeđeni balanseri opterećenja su ostavljeni sa zadanim postavkama.
- Postoje mitovi da balansiranje opterećenja DNS-a zavisi od TTL-a (to nije tačno - od vremena Netscape Navigatora, klijenti su birali slučajnu IP adresu iz skupa RR-ova i transparentno pokušavali drugu ako ne mogu da se povežu)
- Administratori žele odmah primijeniti promjene, tako da je lakše planirati.
- Administrator DNS servera ili balansera opterećenja vidi svoj zadatak kao efikasno postavljanje konfiguracije koju korisnici traže, a ne ubrzavanje sajtova i usluga.
- Niski TTL vam pružaju mir.
- Ljudi u početku postavljaju niske TTL-ove za testiranje, a zatim ih zaboravljaju promijeniti.
Nisam uključio "failover" na listu jer postaje sve manje relevantan. Ako trebate preusmjeriti korisnike na drugu mrežu samo da biste prikazali stranicu s greškom kada je apsolutno sve ostalo pokvareno, kašnjenje od više od 1 minute je vjerojatno prihvatljivo.
Dodatno, jednominutni TTL znači da ako su autoritativni DNS serveri blokirani duže od 1 minute, niko drugi neće moći pristupiti zavisnim uslugama. A redundantnost neće pomoći ako je uzrok greška u konfiguraciji ili hak. S druge strane, uz razumne TTL-ove, mnogi klijenti će nastaviti koristiti prethodnu konfiguraciju i nikada ništa neće primijetiti.
CDN usluge i balanseri opterećenja su u velikoj mjeri krivi za niske TTL-ove, posebno kada kombinuju CNAME-ove s niskim TTL-ovima i zapise s jednako niskim (ali nezavisnim) TTL-ovima:
$ 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
Kad god CNAME ili bilo koji od A zapisa istekne, mora se poslati novi zahtjev. Oba imaju TTL od 30 sekundi, ali to nije isto. Stvarni prosječni TTL će biti 15 sekundi.
Ali čekaj! Još je gore. Neki razrješači se ponašaju vrlo loše u ovoj situaciji s dva povezana niska TTL-a:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 U CNAME github.map.fastly.net. github.map.fastly.net. 1 U A 151.101.16.133
Resolver nivoa 3 verovatno radi na BIND-u. Ako nastavite sa slanjem ovog zahtjeva, uvijek će se vratiti TTL od 1. U suštini, raw.githubusercontent.com se nikada ne kešira.
Evo još jednog primjera takve situacije s vrlo popularnom domenom:
$ 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
Najmanje tri CNAME zapisa. Ay. Jedan ima pristojan TTL, ali je potpuno beskorisan. Drugi CNAME-ovi imaju početni TTL od 60 sekundi, ali za domene akamai.net maksimalni TTL je 20 sekundi i nijedna od njih nije u fazi.
Što je s domenama koje stalno anketiraju Apple uređaje?
$ 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
Isti problem kao Firefox i TTL će se zaglaviti na 1 sekundu većinu vremena kada se koristi Level3 resolver.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 U 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 U CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 U A 162.125.64.3
Na snimanju safebrowsing.googleapis.com TTL vrijednost je 60 sekundi, poput Facebook domena. I opet, sa stanovišta klijenta, ove vrijednosti su prepolovljene.
Šta kažete na postavljanje minimalnog TTL-a?
Koristeći ime, tip zahtjeva, TTL i originalno pohranjenu vremensku oznaku, napisao sam skriptu za simulaciju 1,5 miliona zahtjeva koji prolaze kroz keš razrješavač kako bih procijenio obim nepotrebnih zahtjeva poslatih zbog isteka unosa u keš memoriju.
47,4% zahtjeva podneseno je nakon isteka postojeće evidencije. Ovo je neopravdano visoko.
Kakav će biti utjecaj na keširanje ako se postavi minimalni TTL?
X osa je minimalne TTL vrijednosti. To ne utiče na zapise sa izvornim TTL-ovima iznad ove vrednosti.
Y osa je postotak zahtjeva od klijenta koji već ima keširani unos, ali je istekao i postavlja novi zahtjev.
Udio “ekstra” zahtjeva je smanjen sa 47% na 36% jednostavnim postavljanjem minimalnog TTL-a na 5 minuta. Postavljanjem minimalnog TTL-a na 15 minuta, broj ovih zahtjeva pada na 29%. Minimalni TTL od 1 sat smanjuje ih na 17%. Značajna razlika!
Šta kažete na to da ništa ne mijenjate na strani servera, već umjesto toga postavite minimalni TTL u klijentskim DNS kešovima (ruteri, lokalni razrješači)?
Broj zahtevanih zahteva pada sa 47% na 34% sa minimalnim TTL od 5 minuta, na 25% sa minimalnim 15 minuta, i na 13% sa minimalnim 1 sat. Možda je 40 minuta optimalno.
Uticaj ove male promjene je ogroman.
Koje su posljedice?
Naravno, usluga se može premjestiti na novog cloud provajdera, novi server, novu mrežu, zahtijevajući od klijenata da koriste najnovije DNS zapise. A prilično mali TTL pomaže da se takav prijelaz napravi glatko i neprimjetno. Ali sa prelaskom na novu infrastrukturu, niko ne očekuje da će klijenti preći na nove DNS zapise u roku od 1 minuta, 5 minuta ili 15 minuta. Postavljanje minimalnog TTL-a na 40 minuta umjesto 5 minuta neće spriječiti korisnike da pristupe servisu.
Međutim, ovo će značajno smanjiti kašnjenje i poboljšati privatnost i pouzdanost izbjegavanjem nepotrebnih zahtjeva.
Naravno, RFC-ovi kažu da se TTL mora striktno pridržavati. Ali realnost je da je DNS sistem postao previše neefikasan.
Ako radite sa autoritativnim DNS serverima, provjerite svoje TTL-ove. Da li su vam zaista potrebne tako smiješno niske vrijednosti?
Naravno, postoje dobri razlozi za postavljanje malih TTL-ova za DNS zapise. Ali ne i za 75% DNS prometa koji ostaje gotovo nepromijenjen.
A ako iz nekog razloga zaista trebate koristiti niske TTL-ove za DNS, u isto vrijeme provjerite da vaša stranica nema omogućeno keširanje. Iz istih razloga.
Ako imate pokrenutu lokalnu DNS keš memoriju, kao što je koji vam omogućava da postavite minimalne TTL-ove, koristite ovu funkciju. Ovo je u redu. Ništa loše se neće dogoditi. Postavite minimalni TTL na otprilike 40 minuta (2400 sekundi) i 1 sat. Sasvim razuman raspon.
izvor: www.habr.com