Derengiya kêm DNS ji bo geroka bilez a înternetê mifteya sereke ye. Ji bo kêmkirina wê, girîng e ku meriv bi baldarî serverên DNS-ê hilbijêrin û . Lê gava yekem ev e ku meriv ji pirsên bêkêr xilas bibe.
Ji ber vê yekê DNS bi eslê xwe wekî protokolek pir cacheable hate sêwirandin. Rêvebirên Zonê ji bo têketinên kesane demek jiyînê (TTL) destnîşan dikin, û çareserker dema ku navnîşan di bîranînê de hilînin vê agahiyê bikar tînin da ku ji seyrûsefera nehewce dûr bikevin.
Ma caching bi bandor e? Çend sal berê, lêkolîna min a piçûk nîşan da ku ew ne bêkêmasî bû. Werin em li rewşa heyî binerin.
Ji bo berhevkirina agahiyan min patch kir ji bo bersivê nirxa TTL xilas bike. Ew ji bo her daxwazek gihîştî wekî herî kêm TTL ya tomarên wê tê destnîşankirin. Ev li ser belavkirina TTL ya seyrûsefera rastîn nêrînek baş dide, û di heman demê de populerbûna daxwazên kesane jî digire ber çavan. Guhertoya patched a serverê çend demjimêran xebitî.
Daneyên encam ji 1 tomar (nav, qtype, TTL, demjimêr) pêk tê. Li vir belavkirina giştî ya TTL-ê ye (X-axis TTL di çirkeyan de ye):
Ji bilî 86-ê piçûkek piçûktir (bi piranî ji bo tomarên SOA), pir zelal e ku TTL di rêza nizm de ne. Ka em ji nêz ve lê binêrin:
Baş e, TTL ji 1 demjimêran mezintir ji hêla statîstîkî ve ne girîng in. Dûv re em bala xwe bidin rêza 0−3600:
Piraniya TTL ji 0 heta 15 hûrdem in:
Piraniya mezin ji 0 heta 5 hûrdem in:
Ew ne pir baş e.
Dabeşkirina berhevkirî pirsgirêkê hîn zelaltir dike:
Nîvê bersivên DNS-ê TTL 1 hûrdem an kêmtir heye, û sê-çaran jî TTL-ya 5 hûrdeman an kêmtir heye.
Lê bisekinin, ew bi rastî xirabtir e. Beriya her tiştî, ev TTL ji serverên rayedar e. Lêbelê, çareserkerên xerîdar (mînak router, kaşên herêmî) TTL ji çareserkerên jorîn distînin, û ew her saniye kêm dibe.
Ji ber vê yekê xerîdar dikare bi rastî berî şandina daxwazek nû, bi navînî, nîvê TTL-ya orjînal bikar bîne.
Dibe ku ev TTL-yên pir kêm tenê ji bo daxwazên neasayî û ne malper û API-yên populer derbas dibin? Ka em lê binêrin:
Axîna X TTL ye û teşeya Y populerbûna pirsê ye.
Mixabin, lêpirsinên herî populer di heman demê de yên herî xirab ên cache jî ne.
Ka em zoom bikin:
Dadgeh: ew bi rastî xirab e. Berê jî xerab bû, lê hê xerabtir bû. Cachkirina DNS bi rastî bêkêr bûye. Her ku hindik kes çareserkera DNS-ya ISP-ya xwe bikar tînin (ji ber sedemên baş), zêdebûna derengbûnê bêtir xuya dibe.
Cachkirina DNS-ê tenê ji bo naveroka ku kes naçe bikêr bûye.
Ji kerema xwe jî not bikin ku nermalava dibe TTLyên kêm şirove bikin.
Çima wusa?
Çima tomarên DNS li ser TTL-ya weha kêm têne danîn?
- Balkêşên barkirina mîras bi mîhengên xwerû hatin hiştin.
- Mît hene ku hevsengiya barkirina DNS bi TTL-ê ve girêdayî ye (ev ne rast e - ji rojên Netscape Navigator ve, xerîdar navnîşek IP-ya rasthatî ji komek RR-yan hilbijartiye û heke nikaribin bi hev ve girêbidin, navnîşek IP-ya rasthatî hilbijartine)
- Rêvebir dixwazin tavilê guhartinan bicîh bînin, ji ber vê yekê plansazkirin hêsantir e.
- Rêvebirê serverek DNS an hevsengkerek barkirinê peywira xwe wekî bibandorkirina veavakirina ku bikarhêner daxwaz dikin dibîne, û ne lezkirina malper û karûbaran.
- TTLyên kêm aştiya hişê we dide.
- Mirov di destpêkê de ji bo ceribandinê TTL-yên kêm danîne û dûv re ji bîr dikin ku wan biguhezînin.
Min "failover" nexist nav lîsteyê ji ber ku ew her ku diçe kêmtir têkildar dibe. Heke hûn hewce ne ku bikarhêneran berbi torgilokek din vegerînin tenê ji bo ku hûn rûpelek xeletiyek nîşan bidin dema ku bê guman her tiştê din şikestî ye, derengek ji 1 hûrdemî zêdetir dibe ku were pejirandin.
Wekî din, TTL-yek-hûrqeyek tê vê wateyê ku ger serverên DNS-ê yên rayedar ji 1 hûrdemî zêdetir werin asteng kirin, dê kesek din nikaribe bigihîje karûbarên girêdayî. Û eger sedem xeletiyek mîhengê an hackek be, zêdebûn dê alîkariyê neke. Ji hêla din ve, digel TTL-yên maqûl, gelek xerîdar dê berdewam bikin ku veavakirina berê bikar bînin û qet tiştek nabînin.
Karûbarên CDN û hevsengkerên barkirinê bi giranî ji bo TTLyên nizm sûcdar in, nemaze dema ku ew CNAME bi TTL-yên nizm re û tomarên bi TTL-yên wekhev kêm (lê serbixwe) berhev dikin:
$ 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
Dema ku CNAME an yek ji tomarên A biqede, divê daxwazek nû were şandin. Her du jî xwedî TTL-ya 30 duyemîn e, lê ew ne yek e. TTL-ya navînî ya rastîn dê 15 saniye be.
Lê bisekine! Hîn xerabtir e. Hin çareserker di vê rewşê de bi du TTLyên kêm ên têkildar re pir xirab tevdigerin:
$ raw.githubusercontent.com @4.2.2.2 derxe raw.githubusercontent.com. 1 DI CNAME de github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Dibe ku çareserker Level3 li ser BIND-ê dimeşîne. Ger hûn şandina vê daxwazê bidomînin, dê TTL-ya 1-ê her dem were vegerandin. raw.githubusercontent.com qet nayê girtin.
Li vir mînakek din a rewşek weha bi domainek pir populer heye:
$ 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
Bi kêmanî sê tomarên CNAME. Ay. Yek xwedan TTL-ya maqûl e, lê ew bi tevahî bêkêr e. CNAMEyên din xwedî TTL-ya destpêkê ya 60 çirkeyan e, lê ji bo domanan akamai.net herî zêde TTL 20 çirke ye û yek ji wan di qonaxê de ne.
Li ser domainên ku bi domdarî li ser cîhazên Apple-ê dipirsin çi ye?
$ 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
Heman pirsgirêk wekî Firefox û TTL dema ku çareserkerê Level1 bikar bînin dê pir caran di 3 duyemîn de bimîne.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 DI CNAME de client.dropbox-dns.com. client.dropbox-dns.com. 59 DI A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 DI CNAME de client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
Di tomarkirinê de safebrowsing.googleapis.com Nirxa TTL 60 çirke ye, mîna domên Facebookê. Û, dîsa, ji hêla xerîdar ve, ev nirx nîvî dibin.
Çawa li ser danîna herî kêm TTL?
Bi karanîna nav, celebê daxwazê, TTL, û di destpêkê de mohra dema hilanîn de, min skrîptek nivîsand ku 1,5 mîlyon daxwazên ku di nav çareserkerek caching re derbas dibin simule bike da ku qebareya daxwazên nehewce yên ku ji ber têketina cache qediyaye hatine şandin texmîn bike.
47,4% ji daxwazan piştî ku qeydek heyî qediya bû. Ev bêmaqûl bilind e.
Ger hindiktirîn TTL were danîn dê bandorek li ser cachkirinê çi be?
Axe X herî kêm nirxên TTL ye. Qeydên bi TTL-yên çavkanî yên li jor vê nirxê nayên bandor kirin.
Eksê Y rêjeya daxwazên ji xerîdarek e ku berê xwedan têketinek cache ye, lê ew qediya ye û daxwazek nû dike.
Parçeya daxwazên "zêde" ji% 47 daket 36% bi tenê danîna herî kêm TTL bo 5 hûrdeman. Bi danîna herî kêm TTL bo 15 hûrdeman, hejmara van daxwazan dadikeve %29. Kêmtirîn TTL ya 1 demjimêr wan kêm dike 17%. Cûdahiya girîng!
Meriv çawa li ser milê serverê tiştek naguhezîne, lê di şûna wê de TTL-ya herî kêm di kaşên DNS-ya xerîdar de (rûter, çareserkerên herêmî) saz bike?
Hejmara daxwazên pêwîst ji %47 dadikeve %34 bi kêmtirîn TTL 5 hûrdeman, ji % 25 bi kêmtirîn 15 hûrdeman, û heya %13 bi kêmtirîn 1 demjimêran. Dibe ku 40 hûrdeman çêtirîn e.
Bandora vê guherîna piçûk pir mezin e.
Encam çi ne?
Bê guman, karûbar dikare berbi peydakerek ewr a nû, serverek nû, tora nû ve were veguheztin, ku ji xerîdar hewce dike ku tomarên herî dawî yên DNS bikar bînin. Û TTL-ya pir piçûk arîkar dike ku veguheztinek wusa bi rêk û pêk bê. Lê digel veguheztina binesaziya nû, kes li bendê ne ku xerîdar di nav 1 hûrdem, 5 hûrdem, an 15 hûrdeman de koçî tomarên DNS yên nû bikin. Li şûna 40 hûrdeman danîna herî kêm TTL 5 hûrdem dê rê li ber bikarhêneran negire ku bigihîjin karûbarê.
Lêbelê, ev ê bi girîngî dereng kêm bike û nepenî û pêbaweriyê bi dûrxistina daxwazên nehewce baştir bike.
Bê guman, RFC dibêjin ku divê TTL bi hişkî were şopandin. Lê rastî ev e ku pergala DNS pir bêkêr bûye.
Heke hûn bi serverên DNS-ê yên desthilatdar re dixebitin, ji kerema xwe TTL-yên xwe kontrol bikin. Ma hûn bi rastî hewcedariya we bi nirxên wusa bêkêmasî kêm in?
Bê guman, sedemên baş hene ku hûn TTL-yên piçûk ji bo tomarên DNS-ê saz bikin. Lê ne ji% 75-ê seyrûsefera DNS-ê ya ku bi rastî nayê guhertin dimîne.
Û heke ji ber hin sedeman hûn bi rastî hewce ne ku ji bo DNS-yên kêm TTL bikar bînin, di heman demê de pê ewle bine ku malpera we caching ne çalak e. Ji ber heman sedeman.
Ger we cacheyek DNS ya herêmî heye ku dimeşîne, wek ku destûrê dide te ku hûn TTL-ên herî kêm saz bikin, vê fonksiyonê bikar bînin. Ev baş e. Tiştekî xerab dê çênebe. Kêmtirîn TTL bi qasî 40 hûrdem (2400 çirke) û 1 demjimêr bicîh bikin. Rêjeyek pir maqûl.
Source: www.habr.com