Mala latencija DNS-a ključna je za brzo pregledavanje interneta. Da biste ga smanjili, važno je pažljivo odabrati DNS poslužitelje i . Ali prvi korak je riješiti se beskorisnih upita.
Zbog toga je DNS izvorno zamišljen kao protokol s visokom predmemorijom. Administratori zone postavljaju vrijeme života (TTL) za pojedinačne unose, a razrješivači koriste ove informacije kada pohranjuju unose u memoriju kako bi izbjegli nepotreban promet.
Je li predmemoriranje učinkovito? Prije nekoliko godina, moje malo istraživanje pokazalo je da nije savršeno. Pogledajmo sadašnje stanje stvari.
Za prikupljanje informacija sam zakrpao da biste spremili TTL vrijednost za odgovor. Definiran je kao minimalni TTL njegovih zapisa za svaki dolazni zahtjev. Ovo daje dobar pregled TTL distribucije stvarnog prometa, a također uzima u obzir popularnost pojedinačnih zahtjeva. Zakrpana verzija servera radila je nekoliko sati.
Rezultirajući skup podataka sastoji se od 1 zapisa (ime, qtype, TTL, vremenska oznaka). Ovdje je ukupna TTL distribucija (X-os je TTL u sekundama):
Osim manjeg skoka na 86 (uglavnom za SOA zapise), prilično je jasno da su TTL-ovi u niskom rasponu. Pogledajmo pobliže:
U redu, TTL-ovi već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:
Polovica DNS odgovora ima TTL od 1 minute ili manje, a tri četvrtine ima TTL od 5 minuta ili manje.
Ali čekaj, zapravo je još gore. Uostalom, ovo je TTL s autoritativnih poslužitelja. Međutim, klijentski rezolveri (npr. usmjerivači, lokalne predmemorije) primaju TTL od uzvodnih rezolvera i on se smanjuje svake sekunde.
Dakle, klijent zapravo može koristiti svaki unos za, u prosjeku, pola originalnog TTL-a prije slanja novog zahtjeva.
Možda se ti vrlo niski TTL-ovi odnose samo na neuobičajene zahtjeve, a ne na popularna web-mjesta i API-je? Pogledajmo:
X os je TTL, Y os je popularnost upita.
Nažalost, najpopularnije upite je ujedno i najgore predmemorirati.
Povećajmo:
Presuda: stvarno je loše. I prije je već bilo loše, ali postalo je još gore. DNS keširanje postalo je gotovo beskorisno. Kako sve manje ljudi koristi DNS rezolver svog ISP-a (iz dobrih razloga), povećanje latencije postaje primjetnije.
DNS caching je postao koristan samo za sadržaj koji nitko ne posjećuje.
Također imajte na umu da softver može tumačiti niske TTL-ove.
Zašto je to?
Zašto su DNS zapisi postavljeni na tako nizak TTL?
- Naslijeđeni balanseri opterećenja ostavljeni su sa zadanim postavkama.
- Postoje mitovi da DNS balansiranje opterećenja ovisi o TTL-u (to nije istina - od dana Netscape Navigatora, klijenti su birali nasumične IP adrese iz skupa RR-ova i transparentno pokušavali drugu ako se ne mogu spojiti)
- Administratori žele odmah primijeniti promjene, tako da je lakše planirati.
- Administrator DNS poslužitelja ili balansera opterećenja vidi svoju zadaću kao učinkovito postavljanje konfiguracije koju korisnici traže, a ne ubrzavanje stranica i usluga.
- Niski TTL daju vam mir.
- Ljudi u početku postavljaju niske TTL-ove za testiranje, a zatim ih zaborave promijeniti.
“Failover” nisam uvrstio na popis jer je sve manje relevantan. Ako trebate preusmjeriti korisnike na drugu mrežu samo da biste prikazali stranicu s pogreškom kada je apsolutno sve ostalo pokvareno, kašnjenje od više od 1 minute vjerojatno je prihvatljivo.
Osim toga, jednominutni TTL znači da ako su autoritativni DNS poslužitelji blokirani dulje od 1 minute, nitko drugi neće moći pristupiti ovisnim uslugama. A redundancija neće pomoći ako je uzrok greška u konfiguraciji ili hakiranje. S druge strane, s razumnim TTL-ovima, mnogi će klijenti nastaviti koristiti prethodnu konfiguraciju i nikada neće ništa primijetiti.
CDN usluge i balanseri opterećenja uvelike su krivi za niske TTL-ove, posebno kada kombiniraju CNAME s niskim TTL-ovima i zapise s jednako niskim (ali neovisnim) 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
Svaki put kada CNAME ili bilo koji od zapisa A istekne, mora se poslati novi zahtjev. Oba imaju TTL od 30 sekundi, ali to nije isto. Stvarni prosječni TTL bit će 15 sekundi.
Ali čekaj! Još je gore. Neki se razlučivači 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 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 U 151.101.16.133
Resolver Level3 vjerojatno radi na BIND-u. Ako nastavite slati ovaj zahtjev, uvijek će se vraćati TTL od 1. U biti, raw.githubusercontent.com nikad se ne sprema u predmemoriju.
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. da Jedan ima pristojan TTL, ali je potpuno beskoristan. Ostali CNAME-ovi imaju početni TTL od 60 sekundi, ali za domene akamai.net maksimalni TTL je 20 sekundi i nijedan od njih nije u fazi.
Što je s domenama koje stalno ispituju Appleove 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 zaglaviti na 1 sekundi većinu vremena kada koristite razrješivač razine 3.
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 U 162.125.64.3
Na snimanju safebrowsing.googleapis.com TTL vrijednost je 60 sekundi, kao kod Facebook domena. I opet, sa gledišta klijenta, te su vrijednosti prepolovljene.
Kako bi bilo s postavljanjem minimalnog TTL-a?
Koristeći naziv, vrstu zahtjeva, TTL i izvorno pohranjenu vremensku oznaku, napisao sam skriptu za simulaciju 1,5 milijuna zahtjeva koji prolaze kroz razrješavač predmemorije kako bih procijenio količinu nepotrebnih zahtjeva poslanih zbog isteklog unosa u predmemoriju.
47,4% zahtjeva podneseno je nakon što je postojeći zapis istekao. Ovo je nerazumno visoko.
Kakav će biti utjecaj na predmemoriranje ako se postavi minimalni TTL?
Os X su minimalne TTL vrijednosti. To ne utječe na zapise s izvornim TTL-ovima iznad ove vrijednosti.
Y os je postotak zahtjeva od klijenta koji već ima predmemorirani unos, ali je istekao i šalje novi zahtjev.
Udio "dodatnih" zahtjeva smanjen je 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 sata smanjuje ih na 17%. Značajna razlika!
Što kažete na to da ne mijenjate ništa na strani poslužitelja, već umjesto toga postavite minimalni TTL u DNS predmemoriji klijenta (usmjerivači, lokalni razrješavači)?
Broj potrebnih zahtjeva pada sa 47% na 34% s minimalnim TTL-om od 5 minuta, na 25% s minimalnim 15 minuta i na 13% s minimalnim 1 satom. Možda je 40 minuta optimalno.
Utjecaj ove male promjene je golem.
Koje su posljedice?
Naravno, usluga se može premjestiti na novog pružatelja usluga oblaka, novi poslužitelj, novu mrežu, zahtijevajući od klijenata da koriste najnovije DNS zapise. A prilično mali TTL pomaže da se takav prijelaz učini glatkim i neprimjetnim. Ali s prelaskom na novu infrastrukturu, nitko ne očekuje da će klijenti migrirati na nove DNS zapise unutar 1 minute, 5 minuta ili 15 minuta. Postavljanje minimalnog TTL-a na 40 minuta umjesto 5 minuta neće spriječiti korisnike u pristupu usluzi.
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 strogo poštivati. Ali stvarnost je da je DNS sustav postao previše neučinkovit.
Ako radite s autoritativnim DNS poslužiteljima, provjerite svoje TTL-ove. Trebate li stvarno 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 stvarno morate koristiti niske TTL-ove za DNS, u isto vrijeme provjerite da vaša stranica nema omogućeno predmemoriju. Iz istih razloga.
Ako imate pokrenutu lokalnu DNS predmemoriju, kao što je koja vam omogućuje postavljanje minimalnih TTL-ova, koristite ovu funkciju. Ovo je u redu. Ništa se loše neće dogoditi. Postavite minimalni TTL na približno 40 minuta (2400 sekundi) i 1 sat. Sasvim razuman raspon.
Izvor: www.habr.com