കുറഞ്ഞ ഡിഎൻഎസ് ലേറ്റൻസി വേഗതയുള്ള ഇന്റർനെറ്റ് ബ്രൗസിങ്ങിന് പ്രധാനമാണ്. ഇത് കുറയ്ക്കുന്നതിന്, DNS സെർവറുകൾ ശ്രദ്ധാപൂർവ്വം തിരഞ്ഞെടുക്കേണ്ടത് പ്രധാനമാണ് അജ്ഞാത റിലേകൾ. എന്നാൽ ഉപയോഗശൂന്യമായ ചോദ്യങ്ങൾ ഒഴിവാക്കുക എന്നതാണ് ആദ്യപടി.

അതുകൊണ്ടാണ് DNS യഥാർത്ഥത്തിൽ വളരെ കാഷെ ചെയ്യാവുന്ന ഒരു പ്രോട്ടോക്കോൾ ആയി രൂപകൽപ്പന ചെയ്തത്. സോൺ അഡ്‌മിനിസ്‌ട്രേറ്റർമാർ വ്യക്തിഗത എൻട്രികൾക്കായി ഒരു സമയം (TTL) സജ്ജീകരിക്കുന്നു, കൂടാതെ അനാവശ്യമായ ട്രാഫിക് ഒഴിവാക്കാൻ എൻട്രികൾ മെമ്മറിയിൽ സംഭരിക്കുമ്പോൾ പരിഹരിക്കുന്നവർ ഈ വിവരങ്ങൾ ഉപയോഗിക്കുന്നു.

കാഷിംഗ് ഫലപ്രദമാണോ? കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ്, ഇത് തികഞ്ഞതല്ലെന്ന് എന്റെ ചെറിയ ഗവേഷണം തെളിയിച്ചു. ഇപ്പോഴത്തെ അവസ്ഥ നോക്കാം.

വിവരങ്ങൾ ശേഖരിക്കാൻ ഞാൻ പാച്ച് ചെയ്തു എൻക്രിപ്റ്റ് ചെയ്ത DNS സെർവർ പ്രതികരണത്തിനായി TTL മൂല്യം സംരക്ഷിക്കാൻ. ഓരോ ഇൻകമിംഗ് അഭ്യർത്ഥനയ്ക്കും അതിന്റെ റെക്കോർഡുകളുടെ ഏറ്റവും കുറഞ്ഞ TTL ആയി ഇത് നിർവചിച്ചിരിക്കുന്നു. ഇത് യഥാർത്ഥ ട്രാഫിക്കിന്റെ TTL വിതരണത്തിന്റെ നല്ല അവലോകനം നൽകുന്നു, കൂടാതെ വ്യക്തിഗത അഭ്യർത്ഥനകളുടെ ജനപ്രീതിയും കണക്കിലെടുക്കുന്നു. സെർവറിന്റെ പാച്ച് ചെയ്ത പതിപ്പ് മണിക്കൂറുകളോളം പ്രവർത്തിച്ചു.

തത്ഫലമായുണ്ടാകുന്ന ഡാറ്റാ സെറ്റിൽ 1 റെക്കോർഡുകൾ (പേര്, ക്യൂടൈപ്പ്, TTL, ടൈംസ്റ്റാമ്പ്) അടങ്ങിയിരിക്കുന്നു. മൊത്തത്തിലുള്ള TTL ഡിസ്ട്രിബ്യൂഷൻ ഇതാ (എക്സ്-അക്ഷം സെക്കന്റുകൾക്കുള്ളിൽ TTL ആണ്):

86 എന്ന മൈനർ ബമ്പ് മാറ്റിനിർത്തിയാൽ (മിക്കപ്പോഴും SOA റെക്കോർഡുകൾക്ക്), TTL-കൾ താഴ്ന്ന ശ്രേണിയിലാണെന്ന് വളരെ വ്യക്തമാണ്. നമുക്ക് സൂക്ഷ്മമായി നോക്കാം:

ശരി, 1 മണിക്കൂറിൽ കൂടുതലുള്ള TTL-കൾക്ക് സ്ഥിതിവിവരക്കണക്ക് പ്രാധാന്യമില്ല. അപ്പോൾ നമുക്ക് 0−3600 ശ്രേണിയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാം:

മിക്ക TTL-കളും 0 മുതൽ 15 മിനിറ്റ് വരെയാണ്:

ഭൂരിഭാഗവും 0 മുതൽ 5 മിനിറ്റ് വരെയാണ്:

അത് വളരെ നല്ലതല്ല.

ക്യുമുലേറ്റീവ് ഡിസ്ട്രിബ്യൂഷൻ പ്രശ്നം കൂടുതൽ വ്യക്തമാക്കുന്നു:

പകുതി ഡിഎൻഎസ് പ്രതികരണങ്ങൾക്കും 1 മിനിറ്റോ അതിൽ കുറവോ TTL ഉണ്ട്, മുക്കാൽ ഭാഗത്തിനും 5 മിനിറ്റോ അതിൽ കുറവോ TTL ഉണ്ട്.

എന്നാൽ കാത്തിരിക്കൂ, ഇത് യഥാർത്ഥത്തിൽ മോശമാണ്. എല്ലാത്തിനുമുപരി, ഇത് ആധികാരിക സെർവറുകളിൽ നിന്നുള്ള TTL ആണ്. എന്നിരുന്നാലും, ക്ലയന്റ് റിസോൾവറുകൾക്ക് (ഉദാ. റൂട്ടറുകൾ, ലോക്കൽ കാഷെകൾ) അപ്‌സ്ട്രീം റിസോൾവറുകളിൽ നിന്ന് ഒരു TTL ലഭിക്കും, അത് ഓരോ സെക്കൻഡിലും കുറയുന്നു.

അതിനാൽ, ഒരു പുതിയ അഭ്യർത്ഥന അയയ്‌ക്കുന്നതിന് മുമ്പ് ക്ലയന്റിന് യഥാർത്ഥ TTL-ന്റെ പകുതിയോളം ഓരോ എൻട്രിയും ഉപയോഗിക്കാൻ കഴിയും.

വളരെ കുറഞ്ഞ ഈ TTL-കൾ അസാധാരണമായ അഭ്യർത്ഥനകൾക്ക് മാത്രമേ ബാധകമാകൂ, ജനപ്രിയ വെബ്‌സൈറ്റുകൾക്കും API-കൾക്കും ബാധകമല്ലേ? നമുക്ക് ഒന്ന് നോക്കാം:

X അക്ഷം TTL ആണ്, Y അക്ഷം അന്വേഷണ ജനപ്രീതിയാണ്.

നിർഭാഗ്യവശാൽ, ഏറ്റവും ജനപ്രിയമായ ചോദ്യങ്ങളും കാഷെയിൽ ഏറ്റവും മോശമായവയാണ്.

നമുക്ക് സൂം ഇൻ ചെയ്യാം:

വിധി: ഇത് വളരെ മോശമാണ്. ഇത് മുമ്പ് മോശമായിരുന്നു, പക്ഷേ അത് കൂടുതൽ വഷളായി. DNS കാഷിംഗ് ഫലത്തിൽ ഉപയോഗശൂന്യമായി. കുറച്ച് ആളുകൾ അവരുടെ ISP-യുടെ DNS റിസോൾവർ ഉപയോഗിക്കുന്നതിനാൽ (നല്ല കാരണങ്ങളാൽ), കാലതാമസത്തിന്റെ വർദ്ധനവ് കൂടുതൽ ശ്രദ്ധേയമാകും.

ആരും സന്ദർശിക്കാത്ത ഉള്ളടക്കത്തിന് മാത്രം DNS കാഷിംഗ് ഉപയോഗപ്രദമാണ്.

സോഫ്റ്റ്‌വെയർ ആയിരിക്കാം എന്നതും ശ്രദ്ധിക്കുക വ്യത്യസ്തമായി താഴ്ന്ന TTL-കൾ വ്യാഖ്യാനിക്കുക.

എന്തുകൊണ്ടാണ് ഇത്?

എന്തുകൊണ്ടാണ് DNS റെക്കോർഡുകൾ ഇത്രയും കുറഞ്ഞ TTL ആയി സജ്ജീകരിച്ചിരിക്കുന്നത്?

• ലെഗസി ലോഡ് ബാലൻസറുകൾ ഡിഫോൾട്ട് ക്രമീകരണങ്ങളോടെ അവശേഷിക്കുന്നു.
• ഡിഎൻഎസ് ലോഡ് ബാലൻസിങ് ടിടിഎല്ലിനെ ആശ്രയിച്ചിരിക്കുന്നു എന്ന മിഥ്യാധാരണകളുണ്ട് (ഇത് ശരിയല്ല - നെറ്റ്‌സ്‌കേപ്പ് നാവിഗേറ്ററിന്റെ കാലം മുതൽ, ക്ലയന്റുകൾ ഒരു കൂട്ടം RR-കളിൽ നിന്ന് ക്രമരഹിതമായ IP വിലാസം തിരഞ്ഞെടുക്കുകയും അവർക്ക് കണക്റ്റുചെയ്യാൻ കഴിയുന്നില്ലെങ്കിൽ സുതാര്യമായി മറ്റൊന്ന് പരീക്ഷിക്കുകയും ചെയ്തു)
• അഡ്‌മിനിസ്‌ട്രേറ്റർമാർ ഉടൻ തന്നെ മാറ്റങ്ങൾ പ്രയോഗിക്കാൻ ആഗ്രഹിക്കുന്നു, അതിനാൽ ഇത് ആസൂത്രണം ചെയ്യാൻ എളുപ്പമാണ്.
• ഒരു DNS സെർവറിന്റെയോ ലോഡ് ബാലൻസറിന്റെയോ അഡ്‌മിനിസ്‌ട്രേറ്റർ, ഉപയോക്താക്കൾ ആവശ്യപ്പെടുന്ന കോൺഫിഗറേഷൻ കാര്യക്ഷമമായി വിന്യസിക്കുന്നതും സൈറ്റുകളും സേവനങ്ങളും വേഗത്തിലാക്കാതിരിക്കുന്നതും തന്റെ ചുമതലയായി കാണുന്നു.
• കുറഞ്ഞ TTL-കൾ നിങ്ങൾക്ക് മനസ്സമാധാനം നൽകുന്നു.
• ആളുകൾ തുടക്കത്തിൽ കുറഞ്ഞ TTL-കൾ ടെസ്റ്റിംഗിനായി സജ്ജീകരിക്കുകയും പിന്നീട് അവ മാറ്റാൻ മറക്കുകയും ചെയ്യുന്നു.

"പരാജയം" ഞാൻ പട്ടികയിൽ ഉൾപ്പെടുത്തിയില്ല, കാരണം അതിന്റെ പ്രസക്തി കുറഞ്ഞു വരുന്നു. മറ്റെല്ലാം തകരാറിലാകുമ്പോൾ ഒരു പിശക് പേജ് പ്രദർശിപ്പിക്കുന്നതിന് നിങ്ങൾക്ക് ഉപയോക്താക്കളെ മറ്റൊരു നെറ്റ്‌വർക്കിലേക്ക് റീഡയറക്‌ട് ചെയ്യണമെങ്കിൽ, 1 മിനിറ്റിൽ കൂടുതൽ കാലതാമസം ഒരുപക്ഷേ സ്വീകാര്യമാണ്.

കൂടാതെ, ഒരു മിനിറ്റ് TTL എന്നാൽ ആധികാരിക DNS സെർവറുകൾ 1 മിനിറ്റിൽ കൂടുതൽ ബ്ലോക്ക് ചെയ്‌താൽ, മറ്റാർക്കും ആശ്രിത സേവനങ്ങൾ ആക്‌സസ് ചെയ്യാൻ കഴിയില്ല എന്നാണ്. കാരണം കോൺഫിഗറേഷൻ പിശകോ ഹാക്കോ ആണെങ്കിൽ ആവർത്തനം സഹായിക്കില്ല. മറുവശത്ത്, ന്യായമായ TTL-കൾക്കൊപ്പം, പല ക്ലയന്റുകളും മുമ്പത്തെ കോൺഫിഗറേഷൻ ഉപയോഗിക്കുന്നത് തുടരും, ഒരിക്കലും ഒന്നും ശ്രദ്ധിക്കില്ല.

കുറഞ്ഞ TTL-കൾക്ക് CDN സേവനങ്ങളും ലോഡ് ബാലൻസറുകളും വലിയ തോതിൽ കുറ്റപ്പെടുത്തുന്നു, പ്രത്യേകിച്ചും അവ CNAME-കളെ കുറഞ്ഞ TTL-കളും റെക്കോർഡുകളും തുല്യമായ കുറഞ്ഞ (എന്നാൽ സ്വതന്ത്രമായ) 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

CNAME അല്ലെങ്കിൽ ഏതെങ്കിലും A രേഖകൾ കാലഹരണപ്പെടുമ്പോഴെല്ലാം, ഒരു പുതിയ അഭ്യർത്ഥന അയയ്‌ക്കേണ്ടതാണ്. രണ്ടിനും 30 സെക്കൻഡ് TTL ഉണ്ട്, എന്നാൽ ഇത് സമാനമല്ല. യഥാർത്ഥ ശരാശരി TTL 15 സെക്കൻഡ് ആയിരിക്കും.

എന്നാൽ കാത്തിരിക്കുക! അതിലും മോശമാണ്. ചില പരിഹാരകർ ഈ സാഹചര്യത്തിൽ രണ്ട് താഴ്ന്ന TTL-കളുമായി വളരെ മോശമായി പെരുമാറുന്നു:

$ 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

ലെവൽ3 റിസോൾവർ ഒരുപക്ഷേ BIND-ൽ പ്രവർത്തിക്കുന്നു. നിങ്ങൾ ഈ അഭ്യർത്ഥന അയയ്‌ക്കുന്നത് തുടരുകയാണെങ്കിൽ, 1-ന്റെ TTL എല്ലായ്‌പ്പോഴും തിരികെ നൽകും. അടിസ്ഥാനപരമായി, raw.githubusercontent.com ഒരിക്കലും കാഷെ ചെയ്തിട്ടില്ല.

വളരെ ജനപ്രിയമായ ഒരു ഡൊമെയ്‌നുള്ള അത്തരമൊരു സാഹചര്യത്തിന്റെ മറ്റൊരു ഉദാഹരണം ഇതാ:

$ 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

കുറഞ്ഞത് മൂന്ന് CNAME റെക്കോർഡുകളെങ്കിലും. ആയ്. ഒരാൾക്ക് മാന്യമായ TTL ഉണ്ട്, പക്ഷേ അത് പൂർണ്ണമായും ഉപയോഗശൂന്യമാണ്. മറ്റ് CNAME-കൾക്ക് 60 സെക്കൻഡിന്റെ പ്രാരംഭ TTL ഉണ്ട്, എന്നാൽ ഡൊമെയ്‌നുകൾക്ക് akamai.net പരമാവധി TTL 20 സെക്കൻഡാണ്, അവയൊന്നും ഘട്ടത്തിലല്ല.

Apple ഉപകരണങ്ങളിൽ നിരന്തരം വോട്ടെടുപ്പ് നടത്തുന്ന ഡൊമെയ്‌നുകളെ സംബന്ധിച്ചെന്ത്?

$ 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

Level1 റിസോൾവർ ഉപയോഗിക്കുമ്പോൾ മിക്ക സമയത്തും Firefox, TTL എന്നിവ 3 സെക്കൻഡിൽ കുടുങ്ങിക്കിടക്കും.

ഡ്രോപ്പ്ബോക്സ്?

$ 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

റെക്കോർഡിംഗിൽ safebrowsing.googleapis.com TTL മൂല്യം Facebook ഡൊമെയ്‌നുകൾ പോലെ 60 സെക്കൻഡ് ആണ്. വീണ്ടും, ക്ലയന്റിന്റെ വീക്ഷണകോണിൽ നിന്ന്, ഈ മൂല്യങ്ങൾ പകുതിയായി കുറഞ്ഞു.

ഒരു മിനിമം TTL സജ്ജീകരിക്കുന്നത് എങ്ങനെ?

പേര്, അഭ്യർത്ഥന തരം, TTL, തുടക്കത്തിൽ സംഭരിച്ച ടൈംസ്റ്റാമ്പ് എന്നിവ ഉപയോഗിച്ച്, കാലഹരണപ്പെട്ട കാഷെ എൻട്രി കാരണം അയച്ച അനാവശ്യ അഭ്യർത്ഥനകളുടെ അളവ് കണക്കാക്കാൻ ഒരു കാഷിംഗ് റിസോൾവറിലൂടെ കടന്നുപോകുന്ന 1,5 ദശലക്ഷം അഭ്യർത്ഥനകൾ അനുകരിക്കാൻ ഞാൻ ഒരു സ്ക്രിപ്റ്റ് എഴുതി.

നിലവിലുള്ള ഒരു റെക്കോർഡ് കാലഹരണപ്പെട്ടതിന് ശേഷം 47,4% അഭ്യർത്ഥനകൾ നടത്തി. ഇത് യുക്തിരഹിതമായി ഉയർന്നതാണ്.

ഏറ്റവും കുറഞ്ഞ TTL സജ്ജീകരിച്ചാൽ കാഷിംഗിനെ എങ്ങനെ ബാധിക്കും?

ഏറ്റവും കുറഞ്ഞ TTL മൂല്യങ്ങളാണ് X അക്ഷം. ഈ മൂല്യത്തിന് മുകളിലുള്ള ഉറവിട TTL-കളുള്ള റെക്കോർഡുകളെ ബാധിക്കില്ല.

ഇതിനകം കാഷെ ചെയ്‌ത എൻട്രി ഉള്ള ഒരു ക്ലയന്റിൽ നിന്നുള്ള അഭ്യർത്ഥനകളുടെ ശതമാനമാണ് Y അക്ഷം, എന്നാൽ അത് കാലഹരണപ്പെടുകയും പുതിയ അഭ്യർത്ഥന നടത്തുകയും ചെയ്യുന്നു.

ഏറ്റവും കുറഞ്ഞ TTL 47 മിനിറ്റായി സജ്ജീകരിക്കുന്നതിലൂടെ "അധിക" അഭ്യർത്ഥനകളുടെ പങ്ക് 36% ൽ നിന്ന് 5% ആയി കുറയ്ക്കുന്നു. ഏറ്റവും കുറഞ്ഞ TTL 15 മിനിറ്റായി സജ്ജീകരിക്കുന്നതിലൂടെ, ഈ അഭ്യർത്ഥനകളുടെ എണ്ണം 29% ആയി കുറയുന്നു. കുറഞ്ഞത് 1 മണിക്കൂർ TTL അവരെ 17% ആയി കുറയ്ക്കുന്നു. കാര്യമായ വ്യത്യാസം!

സെർവർ വശത്ത് ഒന്നും മാറ്റാതെ, പകരം ക്ലയന്റ് DNS കാഷെകളിൽ (റൗട്ടറുകൾ, ലോക്കൽ റിസോൾവറുകൾ) ഏറ്റവും കുറഞ്ഞ TTL സജ്ജമാക്കുന്നത് എങ്ങനെ?

ആവശ്യമായ അഭ്യർത്ഥനകളുടെ എണ്ണം കുറഞ്ഞത് 47 മിനിറ്റ് TTL-ൽ 34%-ൽ നിന്ന് 5% ആയി കുറഞ്ഞു, കുറഞ്ഞത് 25 മിനിറ്റ് കൊണ്ട് 15%, കുറഞ്ഞത് 13 മണിക്കൂർ കൊണ്ട് 1%. ഒരുപക്ഷേ 40 മിനിറ്റ് അനുയോജ്യമാണ്.

ഈ ചെറിയ മാറ്റത്തിന്റെ ആഘാതം വളരെ വലുതാണ്.

എന്താണ് അനന്തരഫലങ്ങൾ?

തീർച്ചയായും, സേവനം ഒരു പുതിയ ക്ലൗഡ് പ്രൊവൈഡർ, പുതിയ സെർവർ, പുതിയ നെറ്റ്‌വർക്ക് എന്നിവയിലേക്ക് നീക്കാൻ കഴിയും, ക്ലയന്റുകൾ ഏറ്റവും പുതിയ DNS റെക്കോർഡുകൾ ഉപയോഗിക്കേണ്ടതുണ്ട്. വളരെ ചെറിയ TTL അത്തരമൊരു പരിവർത്തനം സുഗമമായും അദൃശ്യമായും നടത്താൻ സഹായിക്കുന്നു. എന്നാൽ പുതിയ ഇൻഫ്രാസ്ട്രക്ചറിലേക്കുള്ള പരിവർത്തനത്തോടെ, ക്ലയന്റുകൾ 1 മിനിറ്റ്, 5 മിനിറ്റ് അല്ലെങ്കിൽ 15 മിനിറ്റിനുള്ളിൽ പുതിയ DNS റെക്കോർഡുകളിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുമെന്ന് ആരും പ്രതീക്ഷിക്കുന്നില്ല. കുറഞ്ഞ TTL 40 മിനിറ്റിന് പകരം 5 മിനിറ്റായി സജ്ജീകരിക്കുന്നത് ഉപയോക്താക്കളെ സേവനം ആക്‌സസ് ചെയ്യുന്നതിൽ നിന്ന് തടയില്ല.

എന്നിരുന്നാലും, ഇത് ലേറ്റൻസി ഗണ്യമായി കുറയ്ക്കുകയും അനാവശ്യ അഭ്യർത്ഥനകൾ ഒഴിവാക്കി സ്വകാര്യതയും വിശ്വാസ്യതയും മെച്ചപ്പെടുത്തുകയും ചെയ്യും.

തീർച്ചയായും, TTL കർശനമായി പാലിക്കണമെന്ന് RFC-കൾ പറയുന്നു. എന്നാൽ ഡിഎൻഎസ് സംവിധാനം വളരെ കാര്യക്ഷമമല്ലെന്നതാണ് യാഥാർത്ഥ്യം.

നിങ്ങൾ ആധികാരിക DNS സെർവറുകളിൽ പ്രവർത്തിക്കുകയാണെങ്കിൽ, ദയവായി നിങ്ങളുടെ TTL-കൾ പരിശോധിക്കുക. നിങ്ങൾക്ക് ശരിക്കും അത്തരം പരിഹാസ്യമായ താഴ്ന്ന മൂല്യങ്ങൾ ആവശ്യമുണ്ടോ?

തീർച്ചയായും, DNS റെക്കോർഡുകൾക്കായി ചെറിയ TTL-കൾ സജ്ജീകരിക്കുന്നതിന് നല്ല കാരണങ്ങളുണ്ട്. എന്നാൽ ഫലത്തിൽ മാറ്റമില്ലാതെ തുടരുന്ന 75% DNS ട്രാഫിക്കിന് വേണ്ടിയല്ല.

ചില കാരണങ്ങളാൽ നിങ്ങൾ DNS-നായി കുറഞ്ഞ TTL-കൾ ഉപയോഗിക്കേണ്ടതുണ്ടെങ്കിൽ, അതേ സമയം നിങ്ങളുടെ സൈറ്റിൽ കാഷിംഗ് പ്രവർത്തനക്ഷമമാക്കിയിട്ടില്ലെന്ന് ഉറപ്പാക്കുക. അതേ കാരണങ്ങളാൽ.

നിങ്ങൾക്ക് ഒരു പ്രാദേശിക DNS കാഷെ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ dnscrypt-proxyമിനിമം TTL-കൾ സജ്ജീകരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു, ഈ ഫംഗ്ഷൻ ഉപയോഗിക്കുക. ഇത് കൊള്ളാം. മോശമായ ഒന്നും സംഭവിക്കില്ല. ഏറ്റവും കുറഞ്ഞ TTL ഏകദേശം 40 മിനിറ്റും (2400 സെക്കൻഡും) 1 മണിക്കൂറും ആയി സജ്ജമാക്കുക. തികച്ചും ന്യായമായ ശ്രേണി.

അവലംബം: www.habr.com