Muda wa kusubiri wa chini wa DNS ni ufunguo wa kuvinjari kwa haraka kwenye mtandao. Ili kuipunguza, ni muhimu kuchagua kwa makini seva za DNS na relay zisizojulikana. Lakini hatua ya kwanza ni kuondoa maswali yasiyo na maana.

Hii ndiyo sababu DNS iliundwa awali kama itifaki inayoweza kuakibishwa sana. Wasimamizi wa eneo huweka muda wa kuishi (TTL) kwa maingizo binafsi, na wasuluhishi hutumia maelezo haya wakati wa kuhifadhi maingizo kwenye kumbukumbu ili kuepuka trafiki isiyo ya lazima.

Je, uakibishaji unafaa? Miaka michache iliyopita, utafiti wangu mdogo ulionyesha kuwa haikuwa kamilifu. Wacha tuangalie hali ya sasa ya mambo.

Ili kukusanya habari niliweka viraka Seva ya DNS Iliyosimbwa kwa njia fiche ili kuokoa thamani ya TTL kwa jibu. Inafafanuliwa kama TTL ya chini kabisa ya rekodi zake kwa kila ombi linaloingia. Hii inatoa muhtasari mzuri wa usambazaji wa TTL wa trafiki halisi, na pia inazingatia umaarufu wa maombi ya mtu binafsi. Toleo lililo na viraka la seva lilifanya kazi kwa saa kadhaa.

Seti ya data inayotokana ina rekodi 1 (jina, qtype, TTL, muhuri wa muda). Hapa kuna usambazaji wa jumla wa TTL (mhimili wa X ni TTL kwa sekunde):

Kando na mgongano mdogo kwa 86 (zaidi kwa rekodi za SOA), ni wazi kuwa TTL ziko katika safu ya chini. Hebu tuangalie kwa karibu:

Sawa, TTL zilizo kubwa zaidi ya saa 1 si muhimu kitakwimu. Kisha tuzingatie masafa 0−3600:

TTL nyingi ni kutoka dakika 0 hadi 15:

Idadi kubwa ni kutoka dakika 0 hadi 5:

Sio nzuri sana.

Usambazaji wa jumla hufanya shida kuwa wazi zaidi:

Nusu ya majibu ya DNS yana TTL ya dakika 1 au chini ya hapo, na robo tatu ina TTL ya dakika 5 au chini ya hapo.

Lakini subiri, ni mbaya zaidi. Baada ya yote, hii ni TTL kutoka kwa seva za mamlaka. Walakini, visuluhishi vya mteja (k.m. ruta, akiba za ndani) hupokea TTL kutoka kwa visuluhishi vya juu, na hupungua kila sekunde.

Kwa hivyo mteja anaweza kutumia kila ingizo, kwa wastani, nusu ya TTL asili kabla ya kutuma ombi jipya.

Labda TTL hizi za chini sana zinatumika tu kwa maombi yasiyo ya kawaida na sio tovuti na API maarufu? Hebu tuangalie:

Mhimili wa X ni TTL na mhimili wa Y ni umaarufu wa maswali.

Kwa bahati mbaya, maswali maarufu zaidi pia ni mabaya zaidi kuhifadhiwa.

Hebu kuvuta ndani:

Uamuzi: ni mbaya sana. Ilikuwa tayari mbaya hapo awali, lakini ilizidi kuwa mbaya zaidi. Uakibishaji wa DNS umekuwa hauna maana. Kadiri watu wachache wanavyotumia kisuluhishi cha DNS cha ISP (kwa sababu nzuri), ongezeko la muda wa kusubiri linaonekana zaidi.

Uakibishaji wa DNS umekuwa muhimu kwa maudhui ambayo hakuna mtu anayeyatembelea.

Tafadhali kumbuka kuwa programu inaweza tofauti kutafsiri TTL za chini.

Kwa nini?

Kwa nini rekodi za DNS zimewekwa kwa TTL ya chini sana?

• Mizani ya upakiaji wa urithi iliachwa na mipangilio chaguomsingi.
• Kuna hadithi kwamba kusawazisha upakiaji wa DNS kunategemea TTL (hii si kweli - tangu siku za Netscape Navigator, wateja wamechagua anwani ya IP isiyo ya kawaida kutoka kwa seti ya RRs na kujaribu nyingine kwa uwazi ikiwa hawawezi kuunganisha)
• Wasimamizi wanataka kutekeleza mabadiliko mara moja, kwa hivyo ni rahisi kupanga.
• Msimamizi wa seva ya DNS au kisawazisha mzigo huona kazi yake kama kusambaza kwa ustadi usanidi ambao watumiaji huomba, na si kuharakisha tovuti na huduma.
• TTL za chini hukupa amani ya akili.
• Watu mwanzoni waliweka TTL za chini kwa majaribio na kisha kusahau kuzibadilisha.

Sikujumuisha "aliyeshindwa" kwenye orodha kwa sababu inazidi kuwa muhimu. Ikiwa unahitaji kuelekeza watumiaji kwenye mtandao mwingine ili tu kuonyesha ukurasa wa hitilafu wakati kila kitu kingine kimeharibika, ucheleweshaji wa zaidi ya dakika 1 huenda unakubalika.

Zaidi ya hayo, TTL ya dakika moja inamaanisha kuwa seva za DNS zinazoidhinishwa zikizuiwa kwa zaidi ya dakika 1, hakuna mtu mwingine atakayeweza kufikia huduma tegemezi. Na upungufu hautasaidia ikiwa sababu ni hitilafu ya usanidi au udukuzi. Kwa upande mwingine, kwa kutumia TTL zinazofaa, wateja wengi wataendelea kutumia usanidi uliopita na kamwe hawatambui chochote.

Huduma za CDN na visawazisha mizigo vinalaumiwa kwa kiasi kikubwa kwa TTL za chini, haswa zinapochanganya CNAME na TTL za chini na rekodi zilizo na TTL za chini sawa (lakini zinazojitegemea):

$ 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

Wakati wowote CNAME au rekodi zozote za A zinapoisha, ni lazima ombi jipya litumwe. Wote wana TTL ya sekunde 30, lakini sio sawa. Kiwango halisi cha TTL kitakuwa sekunde 15.

Lakini ngoja! Ni mbaya zaidi. Baadhi ya visuluhishi hutenda vibaya sana katika hali hii na TTL mbili za chini zinazohusiana:

$ chimba raw.githubusercontent.com @4.2.2.2
ghafi.githubusercontent.com. 1 KATIKA CNAME github.map.fastly.net.
github.map.fastly.net. 1 KATIKA A 151.101.16.133

Kitatuzi cha Level3 labda kinatumia BIND. Ukiendelea kutuma ombi hili, TTL ya 1 itarejeshwa kila wakati. Kimsingi, raw.githubusercontent.com haijahifadhiwa kamwe.

Hapa kuna mfano mwingine wa hali kama hii na kikoa maarufu sana:

$ 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

Angalau rekodi tatu za CNAME. Ay. Mtu ana TTL nzuri, lakini haina maana kabisa. CNAME zingine zina TTL ya awali ya sekunde 60, lakini kwa vikoa akamai.net kiwango cha juu cha TTL ni sekunde 20 na hakuna hata moja iliyo katika awamu.

Je, vipi kuhusu vikoa ambavyo huchagulia vifaa vya Apple kila mara?

$ 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

Shida sawa na Firefox na TTL itakwama kwa sekunde 1 mara nyingi wakati wa kutumia kisuluhishi cha Level3.

Dropbox?

$ drill client.dropbox.com @8.8.8.8
client.dropbox.com. 7 KATIKA CNAME client.dropbox-dns.com.
client.dropbox-dns.com. 59 KATIKA A 162.125.67.3

$ drill client.dropbox.com @4.2.2.2
client.dropbox.com. 1 KATIKA CNAME client.dropbox-dns.com.
client.dropbox-dns.com. 1 KATIKA A 162.125.64.3

Kwenye rekodi safebrowsing.googleapis.com Thamani ya TTL ni sekunde 60, kama vikoa vya Facebook. Na, tena, kutoka kwa maoni ya mteja, maadili haya yamepunguzwa kwa nusu.

Vipi kuhusu kuweka TTL ya chini?

Kwa kutumia jina, aina ya ombi, TTL, na muhuri wa wakati uliohifadhiwa awali, niliandika hati kuiga maombi milioni 1,5 kupitia kisuluhishi cha kache ili kukadiria kiasi cha maombi yasiyo ya lazima yaliyotumwa kwa sababu ya ingizo la kache lililoisha.

Asilimia 47,4 ya maombi yalifanywa baada ya rekodi iliyopo kuisha muda wake. Hii ni ya juu bila sababu.

Kutakuwa na athari gani kwenye kache ikiwa kiwango cha chini cha TTL kimewekwa?

Mhimili wa X ndio thamani za chini kabisa za TTL. Rekodi zilizo na TTL chanzo juu ya thamani hii haziathiriwi.

Mhimili wa Y ni asilimia ya maombi kutoka kwa mteja ambaye tayari ana ingizo lililohifadhiwa, lakini muda wake umeisha na anatuma ombi jipya.

Sehemu ya maombi ya "ziada" imepunguzwa kutoka 47% hadi 36% kwa kuweka TTL ya chini hadi dakika 5. Kwa kuweka kiwango cha chini cha TTL hadi dakika 15, idadi ya maombi haya inashuka hadi 29%. Kiwango cha chini cha TTL cha saa 1 kinazipunguza hadi 17%. Tofauti kubwa!

Vipi kuhusu kutobadilisha chochote kwa upande wa seva, lakini badala yake kuweka TTL ya chini kwenye kashe za mteja za DNS (ruta, visuluhishi vya kawaida)?

Idadi ya maombi yanayohitajika inashuka kutoka 47% hadi 34% na TTL ya chini ya dakika 5, hadi 25% kwa angalau dakika 15, na hadi 13% kwa angalau saa 1. Labda dakika 40 ni bora.

Athari za mabadiliko haya madogo ni makubwa sana.

Je, matokeo yake ni nini?

Bila shaka, huduma inaweza kuhamishiwa kwa mtoa huduma mpya wa wingu, seva mpya, mtandao mpya, unaohitaji wateja kutumia rekodi za hivi karibuni za DNS. Na TTL ndogo husaidia kufanya mabadiliko kama haya vizuri na bila kuonekana. Lakini pamoja na mabadiliko ya miundombinu mpya, hakuna anayetarajia wateja kuhamia rekodi mpya za DNS ndani ya dakika 1, dakika 5 au dakika 15. Kuweka kiwango cha chini cha TTL hadi dakika 40 badala ya dakika 5 hakutazuia watumiaji kufikia huduma.

Hata hivyo, hii itapunguza sana muda wa kusubiri na kuboresha faragha na kutegemewa kwa kuepuka maombi yasiyo ya lazima.

Bila shaka, RFCs zinasema kwamba TTL lazima ifuatwe kikamilifu. Lakini ukweli ni kwamba mfumo wa DNS umekuwa usiofaa sana.

Ikiwa unafanya kazi na seva zilizoidhinishwa za DNS, tafadhali angalia TTL zako. Je, kweli unahitaji maadili ya chini kiasi hicho?

Bila shaka, kuna sababu nzuri za kuweka TTL ndogo kwa rekodi za DNS. Lakini si kwa 75% ya trafiki ya DNS ambayo bado haijabadilika.

Na ikiwa kwa sababu fulani unahitaji kutumia TTL za chini kwa DNS, wakati huo huo hakikisha kuwa tovuti yako haina caching iliyowezeshwa. Kwa sababu sawa.

Ikiwa una kache ya ndani ya DNS inayoendesha, kama vile dnscrypt-proksiambayo hukuruhusu kuweka TTL za chini, tumia kazi hii. Hii ni sawa. Hakuna kitu kibaya kitatokea. Weka kiwango cha chini zaidi cha TTL kuwa takriban dakika 40 (sekunde 2400) na saa 1. Safu inayofaa kabisa.

Chanzo: mapenzi.com