Niska latencija DNS-a ključni je faktor za brzu internetsku uslugu. Kako bismo je minimalizirali, važno je pažljivo odabrati DNS poslužitelje i . No, prvo se trebate riješiti beskorisnih upita.
Zbog toga je DNS izvorno stvoren kao iznimno keširan protokol. Administratori zona postavljaju vrijeme života (TTL) za pojedinačne zapise, a rezolutori koriste te informacije prilikom pohranjivanja zapisa u memoriju kako bi izbjegli nepotrebni promet.
Je li keširanje učinkovito? Prije nekoliko godina moje malo istraživanje pokazalo je da nije savršeno. Pogledajmo trenutačno stanje.
Za prikupljanje informacija ispravio sam da sačuva vrijednost TTL-a za odgovor. Ona se definira kao minimalno TTL njegovih zapisa, za svaki dolazni upit. To pruža dobar pregled raspodjele TTL-a stvarnog prometa, uzimajući u obzir i popularnost pojedinih upita. Ispravljena verzija poslužitelja radila je nekoliko sati.
Rezultantni skup podataka sastoji se od 1 583 579 zapisa (ime, qtype, TTL, vremena oznake). Evo opća raspodjela TTL-a (osa X je TTL u sekundama):
Ako ne računamo mali vrh na 86 400 (uglavnom za zapise SOA), prilično je očito da su TTL-ovi u niskom rasponu. Pogledajmo bliže:
Dobro, TTL veći od 1 sata statistički nije značajan. Tada se usredotočimo na raspon od 0-3600:
Većina TTL-a je od 0 do 15 minuta:
Prema većini od 0 do 5 minuta:
To nije baš dobro.
Kumulativna raspodjela čini problem još očiglednijim:
U polovici DNS odgovora TTL iznosi 1 minutu ili manje, a kod tri četvrtine - 5 minuta ili manje.
No, pričekajte, u stvarnosti je situacija još gora. Naime, ovo su TTL-ovi od autoritativnih poslužitelja. Međutim, klijentski rezolutori (npr. usmjerivači, lokalne predmemorije) dobivaju TTL od viših rezolutora, a on se smanjuje svake sekunde.
Dakle, klijent zapravo može koristiti svaki zapis, u prosjeku, tijekom polovice izvornih TTL-a, nakon čega šalje novi upit.
Možda se ti vrlo niski TTL-ovi odnose samo na neuobičajene upite, a ne na popularne web stranice i API-je? Pogledajmo:
Osa X je TTL, osa Y je popularnost upita.
Nažalost, najpopularniji upiti također su i najlošije keširani.
Približno:
Presuda: stvarno je loše. Već je ranije bilo loše, a sada je postalo još gore. DNS keširanje je postalo praktički beskorisno. Kako sve manje ljudi koristi DNS rezolver svog providera (iz razumnih razloga), povećanje latencije postaje sve primjetnije.
DNS keširanje je postalo korisno samo za sadržaj koji nitko ne posjećuje.
Također obratite pažnju da softver može tumačiti niske TTL.
Zašto tako?
Zašto se za DNS zapise postavlja tako mali TTL?
- Zastarjeli balansirnici opterećenja ostali su s postavkama po defaultu.
- Postoje mitovi da DNS balansiranje opterećenja ovisi o TTL-u (to nije slučaj - od vremena Netscape Navigatora, klijenti biraju slučajnu IP adresu iz skupa RR i transparentno probaju drugu ako se ne mogu povezati)
- Administratori žele da promjene budu primijenjene odmah, jer se tako lakše planira.
- Administrator DNS servera ili balansirnika opterećenja vidi svoj zadatak u učinkovitoj implementaciji konfiguracije koju korisnici traže, a ne u ubrzanju rada web stranica i servisa.
- Niski TTL pružaju duševni mir.
- Ljudi isprva postave niske TTL za testiranje i potom zaborave promijeniti.
Nisam uključio 'otklanjanje neuspjeha' jer je to sve manje relevantno. Ako je potrebno preusmjeriti korisnike na drugu mrežu samo da bi se prikazala stranica s greškom kada je sve ostalo potpuno pokvareno, možda je prihvatljivo kašnjenje od više od 1 minute.
Osim toga, minutni TTL znači da ako autoritativni DNS serveri budu blokirani više od 1 minute, nitko više neće moći pristupiti ovisnim uslugama. I redundancija neće pomoći ako je uzrok greška u konfiguraciji ili hakiranje. S druge strane, s razumnim TTL-ima mnogi klijenti će nastaviti koristiti prethodnu konfiguraciju i nikada ništa ne primijetiti.
Niske TTL znatno su rezultat CDN usluga i balansirnika opterećenja, posebno kada kombiniraju CNAME s malim TTL i zapise s istim malim (ali neovisnim) TTL-ima:
$ 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 istekne CNAME ili bilo koja od A zapisa, potrebno je poslati novi upit. Oba imaju TTL od 30 sekundi, ali se ne poklapaju. Stvarna prosječna TTL će biti 15 sekundi.
Ali čekajte! Situacija je još gora. Neki rezolvači se vrlo loše ponašaju u takvoj 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 IN A 151.101.16.133
Level3 rezolvač, vjerojatno, radi na BIND-u. Ako nastavite slati ovaj upit, uvijek će se vraćati TTL vrijednosti 1. U suštini, raw.githubusercontent.com nikada se 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
Ne manje od tri CNAME zapisa. Opa! Jedan ima pristojan TTL, ali to je potpuno beskorisno. U drugim CNAME-ima, početni TTL je 60 sekundi, dok za domene akamai.net maksimalni TTL iznosi 20 sekundi i nijedan od njih nije u fazi.
Što je s domenama koje neprestano upitavaju 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
Ista situacija kao kod Firefoxa, i TTL većinu vremena ostaje na 1 sekundi kada koristi Level3 rezolvač.
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
U zapisu safebrowsing.googleapis.com vrijednost TTL iznosi 60 sekundi, kao i kod domena Facebooka. I, opet, s gledišta klijenta, te se vrijednosti smanjuju za polovicu.
Što je s postavljanjem minimalnog TTL-a?
Koristeći ime, tip upita, TTL i izvorno spremljeni vremenski oznaku, napisao sam skriptu za simulaciju 1,5 milijuna upita prolazeći kroz keširajući rezolvač, kako bih procijenio količinu suvišnih upita poslanih zbog isteka zapisa iz keša.
47,4% upita bilo je poslanih nakon isteka postojećeg zapisa. To je neopravdano visoko.
Kakav će biti utjecaj na keširanje ako se postavi minimalni TTL?
Os X su minimalne vrijednosti TTL-a. Zapisi s izvornih TTL-ova viših od ove vrijednosti nisu pogođeni.
Os Y predstavlja postotak zahtjeva od klijenta koji već ima keširanu anketu, čiji je rok istekao, i on šalje novi zahtjev.
Udjel „suvišnih“ zahtjeva smanjuje se s 47% na 36% jednostavnom postavkom minimalnog TTL-a od 5 minuta. Kada se postavi minimalni TTL od 15 minuta, broj tih zahtjeva smanjuje se na 29%. Minimalni TTL od 1 sat smanjuje ih na 17%. Nezamjenjiva razlika!
Kako je da ne mijenjamo ništa na strani poslužitelja, a umjesto toga postavljamo minimalne TTL-e u klijentskim DNS kešovima (usmjerivači, lokalni resolveri)?
Broj potrebnih zahtjeva smanjuje se s 47% na 34% postavljanjem minimalnog TTL-a od 5 minuta, na 25% s minimalnim od 15 minuta i na 13% s minimalnim od 1 sata. Možda je optimalna vrijednost 40 minuta.
Utjecaj ove minimalne promjene je ogroman.
Koje su posljedice?
Naravno, uslugu je moguće prebaciti kod novog pružatelja oblaka, na novi poslužitelj, novu mrežu, tražeći od klijenata da koriste najnovije DNS zapise. A dovoljno mali TTL pomaže u glatkom i neprimjetnom prijelazu. No, s prijelazom na novu infrastrukturu, nitko ne očekuje da će klijenti preći na nove DNS zapise unutar 1 minute, 5 minuta ili 15 minuta. Postavljanje minimalnog roka trajanja od 40 minuta umjesto 5 minuta neće spriječiti korisnike da pristupe usluzi.
Međutim, to će značajno smanjiti latenciju i povećati povjerljivost i pouzdanost, izbjegavajući suvišne zahtjeve.
Naravno, RFC-ovi govore da se strogo pridržavate TTL-a. Ali stvarnost je takva da je DNS sustav postao iznimno neučinkovit.
Ako radite s autoritativnim DNS poslužiteljima, molimo vas provjerite svoje TTL-e. Trebate li zaista toliko smiješno niske vrijednosti?
Naravno, postoje dobri razlozi za postavljanje niskih TTL-a za DNS zapise. No ne za 75% DNS prometa koji se praktički ne mijenja.
A ako iz nekog razloga trebate koristiti niske TTL-e za DNS, također provjerite da li vaša stranica nema uključeno keširanje. Iz istih razloga.
Ako imate lokalni DNS keš, poput , koji omogućava postavljanje minimalnog TTL-a, koristite ovu funkciju. To je u redu. Ništa loše neće se dogoditi. Postavite minimalni TTL otprilike između 40 minuta (2400 sekundi) i 1 sat. Sasvim razuman raspon.
Izvor: habr.com
