VPN DNS ശരിയാക്കിയോ, അതോ കാഷ് ചെയ്ത ഉത്തരം വീണ്ടും ഉപയോഗിച്ചോ?

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

മാറ്റത്തിന് ക്രെഡിറ്റ് നൽകുന്നതിന് മുമ്പ് ഓരോ പരിശോധനയും യഥാർത്ഥത്തിൽ എന്താണ് പരിശീലിപ്പിച്ചതെന്ന് താരതമ്യം ചെയ്യുക.

പേജ് ലോഡ് ചെയ്യുന്നത് ഒരു ചോദ്യമല്ല

ആപ്ലിക്കേഷനും റിസോൾവറും തമ്മിലുള്ള ഓരോ പാളിക്കും അതിന്റെ ആയുസ്സിൽ ഒരു ഉത്തരം ഓർക്കാൻ അനുവാദമുണ്ട്. ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ഒന്ന് സൂക്ഷിക്കുന്നു, ബ്രൗസർ സ്വന്തം സൂക്ഷിക്കുന്നു, ദീർഘകാല കണക്ഷനുള്ള ഒരു ആപ്ലിക്കേഷൻ സെഷനിൽ ഇനി ഒന്നും പരിഹരിക്കാനിടയില്ല. അതിനാൽ ടണൽ മാറ്റത്തിന് ശേഷം വിജയിക്കുന്ന ലോഡ് റൂട്ടിംഗിന്റെയല്ല, ഓർമ്മയുടെ പ്രദർശനമായിരിക്കാം. പരാജയത്തിന്റെ അഭാവം ഒരു ചോദ്യത്തിന്റെ സാന്നിധ്യമല്ല.

ഈ വ്യത്യാസം അടുത്തതായി എന്ത് പരിശോധിക്കണം എന്നത് മാറ്റുന്നു. പുതിയ റിസോൾവർ ഉത്തരം നൽകുന്നു എന്ന് കാണിക്കുകയാണ് ലക്ഷ്യമെങ്കിൽ, നിങ്ങൾ മായ്ച്ചിട്ടില്ലാത്ത ഒരു കാഷിൽ നിന്ന് നൽകാൻ കഴിയാത്ത ഒരു ചോദ്യം വേണം.

കാഷ് ചെയ്ത വിജയത്തെ മുമ്പ് എത്തിച്ചേരാനാകാത്ത ഒരു സെർവർ സുഖം പ്രാപിച്ചു എന്നതിന് തെളിവായി വായിക്കുന്നത് ഈ തെറ്റിന്റെ ഏറ്റവും ചെലവേറിയ രൂപമാണ്, കാരണം അത് തെറ്റായ ഒരു ധാരണയിൽ സംഭവം അവസാനിപ്പിക്കുന്നു.

തീരുമാനിക്കുന്നതിന് മുമ്പ് കാഷുകൾ എണ്ണുക

നാലെണ്ണം പേര് പറയാൻ അർഹിക്കുന്നു: ആപ്ലിക്കേഷന്റെ സ്വന്തം പരിഹാരം, ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ ക്ലൈന്റ് കാഷ്, ബ്രൗസറിന്റെ ആന്തരിക അവസ്ഥ, ഒടുവിൽ ചോദ്യം എത്തുന്ന ഏതൊരു ആവർത്തന റിസോൾവറും. ഓരോന്നിനും വെവ്വേറെ ആയുസ്സും വെവ്വേറെ മായ്ക്കാനുള്ള വഴിയുമുണ്ട്. ഒന്ന് മായ്ച്ച് മറ്റൊന്ന് പരിശോധിക്കുന്നതാണ് മായ്ക്കൽ ഒന്നും ചെയ്തില്ല എന്ന് ആളുകൾ തീരുമാനിക്കുന്ന വഴി. ഒരു ഫ്ലഷ് കമാൻഡ് ഒരിക്കലും ചോദ്യം തീർപ്പാക്കുന്നില്ല.

നെഗറ്റീവ് ഉത്തരങ്ങളും കാഷ് ചെയ്യപ്പെടുന്നു. കാണാനില്ലെന്ന് റിപ്പോർട്ട് ചെയ്ത ഒരു പേര് നെറ്റ്വർക്ക് ശരിയാക്കിയ ശേഷവും കാണാതെ തുടരാം, അത് തകർന്ന ടണലായി വായിക്കപ്പെടുന്നു, യഥാർത്ഥത്തിൽ അത് കാലഹരണപ്പെടാത്ത ഒരു TTL ആണ്. DNS വിവരണം ഈ ഡാറ്റ എങ്ങനെ സൂക്ഷിക്കണം, വീണ്ടും ഉപയോഗിക്കണം എന്ന് വിവരിക്കുന്നു.

മതിപ്പല്ല, സംഭവം രേഖപ്പെടുത്തുക

മൂന്നിൽ ഏതാണ് മാറിയതെന്ന് എഴുതുക: റെക്കോർഡ്, റിസോൾവറിലേക്കുള്ള പാത, അല്ലെങ്കിൽ ക്ലൈന്റ് ക്രമീകരണം. റെക്കോർഡ് എഡിറ്റിംഗ് അതിന്റെ സ്വന്തം ഷെഡ്യൂളിൽ പ്രചരിക്കുന്നു, റൂട്ട് മാറ്റം വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ പ്രാബല്യത്തിൽ വരുന്നു, ബ്രൗസർ ക്രമീകരണം ആ ബ്രൗസറിന് മാത്രം ബാധകമാണ്. അവയെ ഒരൊറ്റ മുൻപും-ശേഷവും ആക്കി ചുരുക്കുന്നത് ആർക്കും ഓഡിറ്റ് ചെയ്യാനാകാത്ത ഒരു സമയരേഖ ഉണ്ടാക്കുന്നു.

സമയം, ഉപയോഗിച്ച റിസോൾവർ, ലഭിച്ച ഉത്തരം എന്നിവ രേഖപ്പെടുത്തുക, ഉത്തരം നെഗറ്റീവ് ആകുന്ന സാഹചര്യം ഉൾപ്പെടെ. അത് മറ്റൊരാൾക്ക് പരിശോധിക്കാവുന്ന ഒരു വസ്തുതയാണ്.

താരതമ്യം രണ്ടുതവണ ഒരേ രീതിയിൽ ചെയ്യുക

പരിശോധിക്കാൻ ഉദ്ദേശിക്കുന്ന കാഷ് മായ്ക്കുക, യഥാർത്ഥ നിരീക്ഷണം സൂക്ഷിക്കുക, എന്നിട്ട് കഴിയുന്നത്ര ഓർമ്മ ഒഴിവാക്കുന്ന രീതിയിൽ ചോദ്യം ചെയ്യുക. റിസോൾവറിനെ വ്യക്തമായി പേരിടുന്നത് ആ റിസോൾവറിന് എന്തറിയാമെന്ന് പറയുന്നു; ആപ്ലിക്കേഷൻ ഏത് റിസോൾവർ തിരഞ്ഞെടുക്കുമായിരുന്നു എന്ന് പറയുന്നില്ല.

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

Windows-ൽ, ക്ലൈന്റ് കാഷ് ഫ്ലഷ് DNS ക്ലൈന്റ് കാഷ് മായ്ക്കുന്നു, മറ്റൊന്നുമല്ല. അത് ബ്രൗസറിന്റെ സ്വകാര്യ അവസ്ഥ വിവരിക്കുന്നില്ല, അപ്സ്ട്രീം സെർവർ മായ്ക്കുന്നുമില്ല, അതിനാൽ അതിനെ അടിസ്ഥാനമാക്കിയ പരിശോധന വീതിയുള്ളതല്ലാതെ വ്യാഖ്യാനിക്കാനാവില്ല. ഫലം റിപ്പോർട്ട് ചെയ്യുമ്പോഴെല്ലാം ഏത് കാഷ് മായ്ച്ചു എന്ന് പറയുക.

തുടർന്ന് പുതിയ അഭ്യർത്ഥനയും ഉദ്ദേശിച്ച റിസോൾവർ നയവും സജീവമാക്കി യഥാർത്ഥ ആപ്ലിക്കേഷൻ വീണ്ടും പരിശോധിക്കുക. മറ്റൊരു നയത്തിന് കീഴിൽ ഉണ്ടാക്കിയ ഫലം കൈമാറ്റം ചെയ്യപ്പെടുന്നില്ല.