Malalta DNS-latenteco estas ŝlosilo por rapida interreta retumado. Por minimumigi ĝin, gravas zorge elekti DNS-servilojn kaj . Sed la unua paŝo estas forigi senutilajn demandojn.
Tial DNS estis origine dizajnita kiel tre kaŝmemorebla protokolo. Zonoadministrantoj fiksas tempon por vivi (TTL) por individuaj kontribuoj, kaj solvantoj uzas ĉi tiujn informojn dum konservado de enskriboj en memoro por eviti nenecesan trafikon.
Ĉu kaŝmemoro efika? Antaŭ kelkaj jaroj, mia eta esploro montris, ke ĝi ne estis perfekta. Ni rigardu la nunan staton de aferoj.
Por kolekti informojn mi flikis por konservi la TTL-valoron por la respondo. Ĝi estas difinita kiel la minimuma TTL de siaj rekordoj por ĉiu envenanta peto. Ĉi tio donas bonan superrigardon pri la TTL-distribuo de reala trafiko, kaj ankaŭ konsideras la popularecon de individuaj petoj. La flikita versio de la servilo funkciis dum pluraj horoj.
La rezulta datumaro konsistas el 1 rekordoj (nomo, qtipo, TTL, tempomarko). Jen la ĝenerala TTL-distribuo (X-akso estas TTL en sekundoj):
Krom malgranda ŝvelaĵo ĉe 86 (plejparte por SOA-rekordoj), estas sufiĉe klare, ke la TTL-oj estas en la malalta gamo. Ni rigardu pli detale:
Bone, TTL-oj pli grandaj ol 1 horo ne estas statistike signifaj. Tiam ni koncentriĝu sur la intervalo 0−3600:
Plej multaj TTL-oj estas de 0 ĝis 15 minutoj:
La granda plimulto estas de 0 ĝis 5 minutoj:
Ĝi ne estas tre bona.
Akumula distribuo igas la problemon eĉ pli evidenta:
Duono de la DNS-respondoj havas TTL de 1 minuto aŭ malpli, kaj tri kvaronoj havas TTL de 5 minutoj aŭ malpli.
Sed atendu, ĝi efektive estas pli malbona. Post ĉio, ĉi tio estas TTL de aŭtoritataj serviloj. Tamen, klientsolviloj (ekz. enkursigiloj, lokaj kaŝmemoroj) ricevas TTL de kontraŭfluaj solvantoj, kaj ĝi malpliiĝas ĉiun sekundon.
Do la kliento povas efektive uzi ĉiun eniron por, averaĝe, duono de la originala TTL antaŭ sendi novan peton.
Eble ĉi tiuj tre malaltaj TTL validas nur por nekutimaj petoj kaj ne popularaj retejoj kaj API-oj? Ni rigardu:
La X-akso estas TTL, la Y-akso estas demanda populareco.
Bedaŭrinde, la plej popularaj demandoj ankaŭ estas la plej malbonaj por kaŝmemori.
Ni zomi:
Verdikto: ĝi estas vere malbona. Jam antaŭe estis malbone, sed eĉ plimalboniĝis. DNS-kaŝmemoro fariĝis preskaŭ senutila. Ĉar malpli da homoj uzas la DNS-solvilon de sia ISP (pro bonaj kialoj), la pliiĝo de latencia fariĝas pli rimarkebla.
DNS-kaŝmemoro fariĝis utila nur por enhavo, kiun neniu vizitas.
Bonvolu noti ankaŭ, ke la programaro povas interpretu malaltajn TTLojn.
Kial?
Kial DNS-rekordoj estas agordita al tiel malalta TTL?
- Heredaj ŝarĝbalanciloj restis kun defaŭltaj agordoj.
- Estas mitoj, ke DNS-ŝarĝo-ekvilibro dependas de TTL (ĉi tio ne veras - ekde la tagoj de Netscape Navigator, klientoj elektis hazardan IP-adreson el aro da RR-oj kaj travideble provis alian se ili ne povas konektiĝi)
- Administrantoj volas tuj apliki ŝanĝojn, do estas pli facile plani.
- La administranto de DNS-servilo aŭ ŝarĝbalancilo vidas sian taskon kiel efike deploji la agordon, kiun petas uzantoj, kaj ne akceli retejojn kaj servojn.
- Malaltaj TTL-oj donas al vi trankvilon.
- Homoj komence fiksas malaltajn TTL-ojn por testado kaj poste forgesas ŝanĝi ilin.
Mi ne enmetis "failover" en la liston ĉar ĝi fariĝas malpli kaj malpli grava. Se vi bezonas redirekti uzantojn al alia reto nur por montri erarpaĝon kiam absolute ĉio alia estas rompita, prokrasto de pli ol 1 minuto estas verŝajne akceptebla.
Aldone, unuminuta TTL signifas, ke se aŭtoritataj DNS-serviloj estas blokitaj dum pli ol 1 minuto, neniu alia povos aliri dependajn servojn. Kaj redundo ne helpos se la kaŭzo estas agorda eraro aŭ hako. Aliflanke, kun raciaj TTL-oj, multaj klientoj daŭre uzos la antaŭan agordon kaj neniam rimarkos ion ajn.
CDN-servoj kaj ŝarĝbalanciloj estas plejparte kulpaj por malaltaj TTL-oj, precipe kiam ili kombinas CNAME-ojn kun malaltaj TTL-oj kaj rekordojn kun same malaltaj (sed sendependaj) TTL-oj:
$ 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
Kiam ajn la CNAME aŭ iu ajn el la A-rekordoj eksvalidiĝas, nova peto devas esti sendita. Ambaŭ havas 30 sekundan TTL, sed ĝi ne estas la sama. La reala meza TTL estos 15 sekundoj.
Sed atendu! Estas eĉ pli malbona. Kelkaj solvantoj kondutas tre malbone en tiu situacio kun du rilataj malaltaj TTLoj:
$ bori raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 EN CNAME github.map.fastly.net. github.map.fastly.net. 1 EN A 151.101.16.133
La Level3-solvilo verŝajne funkcias per BIND. Se vi daŭre sendas ĉi tiun peton, TTL de 1 ĉiam estos resendita. Esence, raw.githubusercontent.com neniam estas kaŝmemorigita.
Jen alia ekzemplo de tia situacio kun tre populara domajno:
$ 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
Almenaŭ tri CNAME-rekordoj. Jes. Oni havas decan TTL, sed ĝi estas tute senutila. Aliaj CNAMEoj havas komencan TTL de 60 sekundoj, sed por domajnoj akamai.net la maksimuma TTL estas 20 sekundoj kaj neniu el ili estas en fazo.
Kio pri domajnoj, kiuj konstante sondas Apple-aparatojn?
$ 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
Sama problemo kiel Fajrovulpo kaj TTL estos blokitaj je 1 sekundo plejofte kiam uzado de Nivel3-solvilo.
Dropbox?
$ borilo client.dropbox.com @8.8.8.8 client.dropbox.com. 7 EN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 EN A 162.125.67.3 $ borilo client.dropbox.com @4.2.2.2 client.dropbox.com. 1 EN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 EN A 162.125.64.3
Ĉe la registrado safebrowsing.googleapis.com TTL-valoro estas 60 sekundoj, kiel Facebook-domajnoj. Kaj, denove, de la vidpunkto de la kliento, ĉi tiuj valoroj estas duonigitaj.
Kiel pri agordo de minimuma TTL?
Uzante la nomon, petospecon, TTL, kaj originale konservitan tempostampilon, mi skribis skripton por simuli 1,5 milionojn da petoj trapasantajn kaŝan solvilon por taksi la volumon de nenecesaj petoj senditaj pro eksvalidiĝinta kaŝmemoro.
47,4% de petoj estis faritaj post kiam ekzistanta rekordo eksvalidiĝis. Ĉi tio estas senracie alta.
Kio estos la efiko al kaŝmemoro se la minimuma TTL estas fiksita?
La X-akso estas la minimumaj TTL-valoroj. Rekordoj kun fontaj TTL-oj super ĉi tiu valoro ne estas tuŝitaj.
La Y-akso estas la procento de petoj de kliento, kiu jam havas kaŝmemorigitan eniron, sed ĝi eksvalidiĝis kaj faras novan peton.
La parto de "ekstraj" petoj estas reduktita de 47% al 36% simple fiksante la minimuman TTL al 5 minutoj. Agordante la minimuman TTL al 15 minutoj, la nombro de ĉi tiuj petoj falas al 29%. Minimuma TTL de 1 horo reduktas ilin al 17%. Grava diferenco!
Kiom pri ne ŝanĝi ion flanke de la servilo, sed anstataŭe agordi la minimuman TTL en klientaj DNS-kaŝmemoroj (enkursigiloj, lokaj solviloj)?
La nombro da petoj bezonataj falas de 47% al 34% kun minimuma TTL de 5 minutoj, al 25% kun minimumo de 15 minutoj, kaj al 13% kun minimumo de 1 horo. Eble 40 minutoj estas optimuma.
La efiko de ĉi tiu malgranda ŝanĝo estas enorma.
Kio estas la konsekvencoj?
Kompreneble, la servo povas esti movita al nova nuba provizanto, nova servilo, nova reto, postulante klientojn uzi la plej novajn DNS-rekordojn. Kaj sufiĉe malgranda TTL helpas fari tian transiron glate kaj nerimarkeble. Sed kun la transiro al nova infrastrukturo, neniu atendas, ke klientoj migris al novaj DNS-rekordoj ene de 1 minuto, 5 minutoj aŭ 15 minutoj. Agordi la minimuman TTL al 40 minutoj anstataŭ 5 minutoj ne malhelpos uzantojn aliri la servon.
Tamen, ĉi tio signife reduktos latencian kaj plibonigos privatecon kaj fidindecon evitante nenecesajn petojn.
Kompreneble, la RFC-oj diras, ke TTL devas esti strikte sekvita. Sed la realo estas, ke la DNS-sistemo fariĝis tro malefika.
Se vi laboras kun aŭtoritataj DNS-serviloj, bonvolu kontroli viajn TTL-ojn. Ĉu vi vere bezonas tiajn ridinde malaltajn valorojn?
Kompreneble, estas bonaj kialoj por agordi malgrandajn TTL-ojn por DNS-rekordoj. Sed ne por la 75% de DNS-trafiko, kiu restas preskaŭ senŝanĝa.
Kaj se ial vi vere bezonas uzi malaltajn TTL-ojn por DNS, samtempe certigu, ke via retejo ne havas kaŝmemoron ebligita. Pro la samaj kialoj.
Se vi havas lokan DNS-kaŝmemoron funkciantan, kiel ekzemple kiu permesas vin agordi minimumajn TTL-ojn, uzu ĉi tiun funkcion. Ĉi tio estas bone. Nenio malbona okazos. Agordu la minimuman TTL al proksimume 40 minutoj (2400 sekundoj) kaj 1 horo. Sufiĉe racia gamo.
fonto: www.habr.com