DNS ചോര്‍ച്ച പരിശോധന: റിസോൾവറിന്റെ പേര് വഴിയല്ല

VPN ഉപയോക്താവിന് ശരിയായ DNS ആയി മൂന്ന് ക്രമീകരണങ്ങളാണ് കണക്കാക്കുന്നത്: ഓപ്പറേറ്ററുടെ റിസോൾവറിലേക്കുള്ള ചോദ്യങ്ങൾ, നിങ്ങൾ തിരഞ്ഞെടുത്ത എൻക്രിപ്റ്റ് ചെയ്ത റിസോൾവറിലേക്കുള്ള ചോദ്യങ്ങൾ, ജോലി നാമങ്ങൾ സംഘടനയിലേക്ക് അയയ്ക്കുന്ന split DNS. ചോര്‍ച്ച പരിശോധന ഒരു റിസോൾവർ റിപ്പോർട്ട് ചെയ്യുന്നു, ആ ഒരു ലേബലിന് യഥാർത്ഥത്തിൽ ഏത് ക്രമീകരണമാണെന്ന് പറയാനാവില്ല. ആദ്യം ഉദ്ദേശിച്ച നയം തീരുമാനിച്ച ശേഷം അതിനെതിരെ പരിശോധിക്കുക. അല്ലെങ്കിൽ നിങ്ങൾ ഒരു സംഖ്യയെ ഒരു തോന്നലുമായി താരതമ്യം ചെയ്യുകയാണ്.

ഫലം വായിക്കുന്നതിന് മുമ്പ് എന്താണ് വേണ്ടതെന്ന് തീരുമാനിക്കുക

നയം ഒരു വാക്യത്തിൽ പറയുക: എല്ലാ നാമങ്ങളും VPN റിസോൾവറിലേക്ക്, എല്ലാ നാമങ്ങളും തിരഞ്ഞെടുത്ത എൻക്രിപ്റ്റ് റിസോൾവറിലേക്ക്, അല്ലെങ്കിൽ ആന്തരിക നാമങ്ങൾ സംഘടനയിലേക്ക് പോകുന്ന split DNS. ഓരോന്നും വ്യത്യസ്ത ഉപയോക്താവിന് ന്യായീകരിക്കാവുന്നതാണ്, ഓരോന്നും വ്യത്യസ്ത പ്രതീക്ഷിത ഉത്തരം നൽകുന്നു. ആ വാക്യമില്ലെങ്കിൽ ഫോറം പോസ്റ്റിലെ സ്ക്രീൻഷോട്ടിൽ നിന്ന് വ്യത്യസ്തമായ ഏത് ഫലവും ഭയപ്പെടുത്തുന്നതായി തോന്നും. ആദ്യ പരിശോധനയ്ക്ക് മുമ്പ് നയം എഴുതി വയ്ക്കുക.

നയം നിർവചിക്കുന്നതിന് മുമ്പ് ചെയ്ത പരിശോധന ഒന്നും അളക്കുന്നില്ല. അത് ഒരു റഫറൻസ് പോയിന്റുമില്ലാത്ത റിസോൾവർ നാമം നൽകുന്നു.

റിസോൾവർ നാമം വഴിയോ സ്വീകർത്താവിനെയോ തെളിയിക്കുന്നില്ല

രണ്ട് ചോദ്യങ്ങളാണ് പ്രധാനം: ചോദ്യം ആര് സ്വീകരിച്ചു, ഏത് വഴിയാണ് അതിനെ കൊണ്ടുപോയത്. ക്രമീകരണ സ്ക്രീൻ ദാതാവിന്റെ വിലാസം കാണിക്കുമ്പോഴും ടണലിലൂടെ മൂന്നാം കക്ഷി റിസോൾവറിലേക്ക് എത്താം. ചോര്‍ച്ച പരിശോധനാ പേജിലെ ലേബൽ നിരീക്ഷകന്റെ കാഴ്ചയെ വിവരിക്കുന്നു, നിങ്ങളുടെ റൂട്ടിംഗ് പട്ടികയെയല്ല.

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

resolvectl status
resolvectl query example.com
dig +short example.com

split DNS ഒന്നിലധികം റിസോൾവറുകളെ ശരിയാക്കുന്നു

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

split tunneling-ഉം split DNS-ഉം വ്യത്യസ്ത തിരഞ്ഞെടുപ്പുകളാണ്: ഒന്ന് പാക്കറ്റുകൾ റൂട്ട് ചെയ്യുന്നു, മറ്റൊന്ന് ചോദ്യങ്ങൾ. ടണൽ വഴി മാറ്റുന്നത് നാമ തിരയൽ നീക്കുന്നില്ല, റിസോൾവർ മാറ്റുന്നത് വെബ്സൈറ്റ് വഴി ശരിയാക്കുന്നുമില്ല. IPv6 മൂന്നാമത്തെ ചോദ്യമാണ്, കാരണം ഉദ്ദേശിക്കാത്ത IPv6 കണക്ഷൻ സ്വയം DNS ചോര്‍ച്ചയല്ല.

ഫലത്തെ അന്വേഷണമാക്കി മാറ്റുക

പരിശോധനയ്ക്ക് മുമ്പ് ഉദ്ദേശിച്ച നയവും ബ്രൗസറിന്റെ സുരക്ഷിത DNS ക്രമീകരണവും രേഖപ്പെടുത്തുക. ടണൽ സജീവമായി പരിശോധന നടത്തുക, അത് പേരിടുന്ന ഓരോ റിസോൾവറും രേഖപ്പെടുത്തുക, ഗണത്തെ ഒരു പ്രതീക്ഷിത വിലാസവുമായല്ല, നയവുമായി താരതമ്യം ചെയ്യുക.

ലക്ഷണം അപ്പോൾ പ്രത്യക്ഷപ്പെടുന്നെങ്കിൽ വീണ്ടും കണക്ട് ചെയ്ത ശേഷം ആവർത്തിക്കുക, കാരണം കണക്ട് ചെയ്യുമ്പോൾ പ്രയോഗിച്ച നയം പിന്നീട് നഷ്ടപ്പെടാം. ക്രമീകരണങ്ങൾ ഊഹിക്കാതെ ആന്തരിക DNS ഒഴിവാക്കലുകൾക്ക് ക്ലയന്റിന്റെ ഡോക്യുമെന്റേഷൻ ഉപയോഗിക്കുക.

കണ്ടെത്തിയ പൊരുത്തക്കേട് ശരിയാക്കുക: ബ്രൗസർ തിരഞ്ഞെടുപ്പ്, VPN DNS ക്രമീകരണം അല്ലെങ്കിൽ split DNS നിയമം. ടണൽ പരാജയപ്പെടുമ്പോൾ ചോദ്യങ്ങൾ നിർത്തണമെങ്കിൽ, kill switch വേറെ ക്രമീകരണമാണ്, DNS കോൺഫിഗറേഷൻ മാത്രം അത് നൽകില്ല. എൻക്രിപ്റ്റ് ചെയ്ത റിസോൾവർ എന്ത് മറയ്ക്കുന്നു, എന്ത് മറയ്ക്കുന്നില്ല എന്ന് വിശദീകരിക്കേണ്ടിവരുമ്പോൾ RFC 8484 സ്പെസിഫിക്കേഷൻ ഉപകാരപ്രദമാണ്.