Ang mababang DNS latency ay susi sa mabilis na pag-browse sa internet. Upang mabawasan ito, mahalagang maingat na piliin ang mga DNS server at . Ngunit ang unang hakbang ay upang mapupuksa ang mga walang kwentang query.
Ito ang dahilan kung bakit orihinal na idinisenyo ang DNS bilang isang napaka-cacheable na protocol. Ang mga tagapangasiwa ng zone ay nagtakda ng oras para mabuhay (TTL) para sa mga indibidwal na entry, at ginagamit ng mga solver ang impormasyong ito kapag nag-iimbak ng mga entry sa memorya upang maiwasan ang hindi kinakailangang trapiko.
Epektibo ba ang pag-cache? Ilang taon na ang nakalilipas, ipinakita ng aking maliit na pananaliksik na hindi ito perpekto. Tingnan natin ang kasalukuyang kalagayan.
Para mangolekta ng impormasyon ay na-patch ko upang i-save ang halaga ng TTL para sa tugon. Ito ay tinukoy bilang ang pinakamababang TTL ng mga tala nito para sa bawat papasok na kahilingan. Nagbibigay ito ng magandang pangkalahatang-ideya ng TTL distribution ng totoong trapiko, at isinasaalang-alang din ang kasikatan ng mga indibidwal na kahilingan. Ang naka-patch na bersyon ng server ay gumana nang ilang oras.
Ang resultang set ng data ay binubuo ng 1 na tala (pangalan, qtype, TTL, timestamp). Narito ang pangkalahatang pamamahagi ng TTL (ang X-axis ay TTL sa ilang segundo):
Bukod sa isang maliit na bump sa 86 (karamihan para sa mga talaan ng SOA), medyo malinaw na ang mga TTL ay nasa mababang hanay. Tingnan natin nang mas malapitan:
Okay, ang mga TTL na higit sa 1 oras ay hindi makabuluhan ayon sa istatistika. Pagkatapos ay tumuon tayo sa hanay na 0β3600:
Karamihan sa mga TTL ay mula 0 hanggang 15 minuto:
Ang karamihan ay mula 0 hanggang 5 minuto:
Hindi ito masyadong maganda.
Ginagawang mas halata ng pinagsama-samang pamamahagi ang problema:
Kalahati ng mga tugon sa DNS ay may TTL na 1 minuto o mas maikli, at tatlong-kapat ay may TTL na 5 minuto o mas maikli.
Pero teka, mas malala talaga. Pagkatapos ng lahat, ito ay TTL mula sa mga authoritative server. Gayunpaman, ang mga solver ng kliyente (hal. mga router, lokal na cache) ay tumatanggap ng TTL mula sa mga upstream na solver, at bumababa ito bawat segundo.
Kaya talagang magagamit ng kliyente ang bawat entry para sa, sa karaniwan, kalahati ng orihinal na TTL bago magpadala ng bagong kahilingan.
Marahil ang napakababang TTL na ito ay nalalapat lamang sa mga hindi pangkaraniwang kahilingan at hindi sa mga sikat na website at API? Tingnan natin:
Ang X axis ay TTL, ang Y axis ay query popularity.
Sa kasamaang palad, ang pinakasikat na mga query din ang pinakamasama sa cache.
Mag-zoom in tayo:
Verdict: grabe talaga. Masama na nga dati, pero mas lumala pa. Ang DNS caching ay naging halos walang silbi. Habang mas kaunting tao ang gumagamit ng DNS resolver ng kanilang ISP (para sa magagandang dahilan), nagiging mas kapansin-pansin ang pagtaas ng latency.
Ang DNS caching ay naging kapaki-pakinabang lamang para sa nilalamang walang binibisita.
Pakitandaan din na ang software ay maaaring bigyang-kahulugan ang mababang TTL.
Bakit na?
Bakit nakatakda ang mga DNS record sa mababang TTL?
- Ang mga legacy load balancer ay naiwan na may mga default na setting.
- May mga alamat na ang DNS load balancing ay nakasalalay sa TTL (ito ay hindi totoo - mula noong mga araw ng Netscape Navigator, ang mga kliyente ay pumili ng isang random na IP address mula sa isang hanay ng mga RR at malinaw na sinubukan ang isa pa kung hindi sila makakonekta)
- Gusto ng mga administrator na maglapat kaagad ng mga pagbabago, kaya mas madaling magplano.
- Nakikita ng administrator ng isang DNS server o load balancer ang kanyang gawain bilang mahusay na pag-deploy ng configuration na hinihiling ng mga user, at hindi nagpapabilis sa mga site at serbisyo.
- Ang mga mababang TTL ay nagbibigay sa iyo ng kapayapaan ng isip.
- Ang mga tao sa simula ay nagtakda ng mababang TTL para sa pagsubok at pagkatapos ay nakalimutang baguhin ang mga ito.
Hindi ko na isinama ang "failover" sa listahan dahil nagiging paunti-unti na ito. Kung kailangan mong i-redirect ang mga user sa isa pang network para lang magpakita ng pahina ng error kapag ganap na nasira ang lahat, malamang na katanggap-tanggap ang pagkaantala ng higit sa 1 minuto.
Bukod pa rito, ang isang minutong TTL ay nangangahulugan na kung ang mga awtoritatibong DNS server ay na-block nang higit sa 1 minuto, walang ibang makaka-access sa mga serbisyong umaasa. At hindi makakatulong ang redundancy kung ang dahilan ay error sa configuration o hack. Sa kabilang banda, sa mga makatwirang TTL, maraming mga kliyente ang patuloy na gagamit ng nakaraang pagsasaayos at hindi kailanman mapapansin ang anuman.
Ang mga serbisyo ng CDN at load balancer ay higit na may kasalanan para sa mababang TTL, lalo na kapag pinagsama nila ang mga CNAME na may mababang TTL at mga tala na may parehong mababa (ngunit independyente) na mga TTL:
$ 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
Sa tuwing mag-e-expire ang CNAME o alinman sa mga A record, kailangang magpadala ng bagong kahilingan. Parehong may 30 segundong TTL, ngunit hindi ito pareho. Ang aktwal na average na TTL ay magiging 15 segundo.
Ngunit sandali! Mas malala pa. Ang ilang mga solver ay kumikilos nang napakasama sa sitwasyong ito na may dalawang nauugnay na mababang TTL:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 SA CNAME github.map.fastly.net. github.map.fastly.net. 1 SA A 151.101.16.133
Ang Level3 na solver ay malamang na tumatakbo sa BIND. Kung patuloy mong ipapadala ang kahilingang ito, palaging ibabalik ang TTL na 1. Sa pangkalahatan, raw.githubusercontent.com ay hindi kailanman naka-cache.
Narito ang isa pang halimbawa ng ganoong sitwasyon na may napakasikat na domain:
$ 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
Hindi bababa sa tatlong CNAME record. Ay. Ang isa ay may disenteng TTL, ngunit ito ay ganap na walang silbi. Ang ibang mga CNAME ay may paunang TTL na 60 segundo, ngunit para sa mga domain akamai.net ang maximum na TTL ay 20 segundo at wala sa mga ito ang nasa yugto.
Paano naman ang mga domain na patuloy na nagpo-poll sa mga Apple device?
$ 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
Ang parehong problema tulad ng Firefox at TTL ay natigil sa 1 segundo sa karamihan ng oras kapag gumagamit ng Level3 na solver.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 SA CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 SA ISANG 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 SA CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 SA A 162.125.64.3
Sa recording safebrowsing.googleapis.com Ang halaga ng TTL ay 60 segundo, tulad ng mga domain ng Facebook. At, muli, mula sa pananaw ng kliyente, ang mga halagang ito ay hinahati.
Paano ang tungkol sa pagtatakda ng isang minimum na TTL?
Gamit ang pangalan, uri ng kahilingan, TTL, at orihinal na nakaimbak na timestamp, nagsulat ako ng script para gayahin ang 1,5 milyong kahilingang dumadaan sa isang caching resolver upang tantyahin ang dami ng mga hindi kinakailangang kahilingang ipinadala dahil sa isang nag-expire na cache entry.
47,4% ng mga kahilingan ang ginawa pagkatapos mag-expire ang isang kasalukuyang tala. Ito ay hindi makatwirang mataas.
Ano ang magiging epekto sa pag-cache kung nakatakda ang minimum na TTL?
Ang X axis ay ang pinakamababang halaga ng TTL. Ang mga talaan na may mga pinagmulang TTL sa itaas ng halagang ito ay hindi apektado.
Ang Y axis ay ang porsyento ng mga kahilingan mula sa isang kliyente na mayroon nang naka-cache na entry, ngunit nag-expire na ito at gumagawa ng bagong kahilingan.
Ang bahagi ng "dagdag" na mga kahilingan ay binabawasan mula 47% hanggang 36% sa pamamagitan lamang ng pagtatakda ng pinakamababang TTL sa 5 minuto. Sa pamamagitan ng pagtatakda ng pinakamababang TTL sa 15 minuto, bumaba ang bilang ng mga kahilingang ito sa 29%. Ang isang minimum na TTL ng 1 oras ay binabawasan ang mga ito sa 17%. Malaking pagkakaiba!
Paano ang tungkol sa hindi pagbabago ng anuman sa panig ng server, ngunit sa halip ay itakda ang pinakamababang TTL sa mga cache ng DNS ng kliyente (router, mga lokal na solver)?
Bumaba ang bilang ng mga kahilingan mula 47% hanggang 34% na may minimum na TTL na 5 minuto, hanggang 25% na may minimum na 15 minuto, at hanggang 13% na may minimum na 1 oras. Marahil ang 40 minuto ay pinakamainam.
Napakalaki ng epekto ng maliit na pagbabagong ito.
Ano ang mga kahihinatnan?
Siyempre, ang serbisyo ay maaaring ilipat sa isang bagong cloud provider, bagong server, bagong network, na nangangailangan ng mga kliyente na gamitin ang pinakabagong mga tala ng DNS. At ang isang medyo maliit na TTL ay nakakatulong upang magawa ang gayong paglipat nang maayos at hindi mahahalata. Ngunit sa paglipat sa bagong imprastraktura, walang umaasa sa mga kliyente na mag-migrate sa mga bagong tala ng DNS sa loob ng 1 minuto, 5 minuto, o 15 minuto. Ang pagtatakda ng pinakamababang TTL sa 40 minuto sa halip na 5 minuto ay hindi makakapigil sa mga user na ma-access ang serbisyo.
Gayunpaman, ito ay makabuluhang bawasan ang latency at pagbutihin ang privacy at pagiging maaasahan sa pamamagitan ng pag-iwas sa mga hindi kinakailangang kahilingan.
Siyempre, sinasabi ng mga RFC na dapat mahigpit na sundin ang TTL. Ngunit ang katotohanan ay ang sistema ng DNS ay naging masyadong inefficient.
Kung nagtatrabaho ka sa mga makapangyarihang DNS server, pakisuri ang iyong mga TTL. Kailangan mo ba talaga ng katawa-tawang mababang halaga?
Siyempre, may magagandang dahilan para magtakda ng maliliit na TTL para sa mga tala ng DNS. Ngunit hindi para sa 75% ng trapiko ng DNS na nananatiling halos hindi nagbabago.
At kung sa ilang kadahilanan kailangan mo talagang gumamit ng mga mababang TTL para sa DNS, sa parehong oras siguraduhin na ang iyong site ay hindi pinagana ang caching. Para sa parehong mga kadahilanan.
Kung mayroon kang lokal na DNS cache na tumatakbo, gaya ng na nagpapahintulot sa iyo na magtakda ng pinakamababang TTL, gamitin ang function na ito. Ito ay mabuti. Walang masamang mangyayari. Itakda ang pinakamababang TTL sa humigit-kumulang 40 minuto (2400 segundo) at 1 oras. Medyo isang makatwirang saklaw.
Pinagmulan: www.habr.com