നിങ്ങൾ 1.1.1.1 VPN-ന്റെ DNS ഫീൽഡിൽ ഒട്ടിച്ചു, പേജ് ലോഡ് ചെയ്തു, ട്യൂട്ടോറിയൽ ഇപ്പോൾ സ്ഥിരീകരിച്ചതായി തോന്നുന്നു. ആ നിരീക്ഷണം തോന്നുന്നതിലും ഇടുങ്ങിയതാണ്: ആപ്ലിക്കേഷൻ വ്യത്യസ്തമായി പെരുമാറി, മാറ്റം ഇപ്പോഴും ചോദ്യത്തിന് ആരാണ് ഉത്തരം നൽകിയത് അല്ലെങ്കിൽ പഴയ ക്രമീകരണം എന്തുകൊണ്ട് പരാജയപ്പെട്ടു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. പകർത്തിയ ട്യൂട്ടോറിയൽ പരിചിതമായ ഒരു പൊതു വിലാസത്തെ “VPN-ന്റെ DNS” എന്ന് വിളിക്കാറുണ്ട്, അത് ഉടമസ്ഥതയെക്കുറിച്ചുള്ള അവകാശവാദമാണ്, എത്തിച്ചേരാനുള്ള കഴിവിനെക്കുറിച്ചല്ല. വിലാസം എന്തിനെ പ്രതിനിധീകരിക്കുന്നു എന്ന് പരിശോധിക്കാൻ അഞ്ച് മിനിറ്റെടുക്കും, തെറ്റായ കാരണത്താൽ ഉണ്ടാകുന്ന സ്ഥിരമായ മാറ്റം ഇത് തടയുന്നു.

പ്രവർത്തിക്കുന്ന ഒരു ക്രമീകരണം ഐഡന്റിറ്റിയല്ല

ക്രമീകരണ ഫീൽഡിലെ വിലാസം ഒരു അന്ത്യബിന്ദുവാണ്, അന്ത്യബിന്ദുവിന് ഒരു ഓപ്പറേറ്ററുണ്ട്. ഈ രണ്ട് വസ്തുതകൾ വെവ്വേറെയാണ്, രണ്ടാമത്തേതാണ് ആളുകൾ ഒഴിവാക്കുന്നത്. ഏറ്റവും കൂടുതൽ പകർത്തപ്പെടുന്ന ജോഡിക്ക് ഉത്തരം പൊതുവാണ്: Cloudflare 1.1.1.1 ഉം 1.0.0.1 ഉം തന്റെ റെസോൾവർ വിലാസങ്ങളായി പ്രസിദ്ധീകരിക്കുന്നു, അവ തന്റെ ഔദ്യോഗിക വിലാസ റഫറൻസിൽ പട്ടികപ്പെടുത്തുന്നു. അതുകൊണ്ടാണ് ഓപ്പറേറ്ററുടെ പേര് വിലാസത്തിനൊപ്പം വേണ്ടത്, വേറിട്ട ട്യൂട്ടോറിയലിൽ അല്ല.

ടണൽ ഓണായിരിക്കുമ്പോൾ ആ ജോഡി നൽകുന്നത് VPN കമ്പനിയെ അതിന്റെ ഓപ്പറേറ്ററാക്കുന്നില്ല, ട്രാഫിക്കിനെ അജ്ഞാതമാക്കുന്നുമില്ല. ചോദ്യം നിങ്ങളുടെ യന്ത്രത്തിൽനിന്ന് വിലാസ ശ്രേണി പ്രസിദ്ധീകരിക്കുന്ന കമ്പനിയിലേക്ക് പോകുന്നു, ആ കമ്പനി മാന്യമായിരിക്കാം, എന്നിട്ടും ട്യൂട്ടോറിയൽ സൂചിപ്പിച്ച കക്ഷിയാകണമെന്നില്ല. നിർദ്ദേശങ്ങളിലെ ലേബലും യാഥാർത്ഥ്യത്തിലെ ഓപ്പറേറ്ററും രണ്ട് വ്യത്യസ്ത അവകാശവാദങ്ങളാണ്. ഇടയിലുള്ള നെറ്റ്വർക്ക് പാത ആരാണ് നടത്തുന്നതെന്ന് രണ്ടും പറയുന്നില്ല.

ഒരു വിലാസ ജോഡിയോ എൻക്രിപ്റ്റ് ചെയ്ത അന്ത്യബിന്ദുവോ സ്ഥിരീകരിക്കാൻ റെസോൾവറിന്റെ സ്വന്തം പ്രസിദ്ധീകരിച്ച റഫറൻസ് ഉപയോഗിക്കുക. മറ്റൊരു വിൽപ്പനക്കാരന്റെ ശുപാർശ സാധുവായിരിക്കാം, “ശുപാർശ ചെയ്തത്”, “വഴി എത്തിയത്”, “നടത്തുന്നത്” എന്നിവ ഇപ്പോഴും മൂന്ന് വ്യത്യസ്ത ബന്ധങ്ങളെ വിവരിക്കുന്നു.

ഒരു രേഖയ്ക്ക് ആവശ്യമായ മൂന്ന് കാര്യങ്ങൾ താരതമ്യം ചെയ്യുക

അവലോകനത്തിന് തയ്യാറായ രേഖ മൂന്ന് ചോദ്യങ്ങൾ വേർതിരിക്കുന്നു: ചോദ്യം ആർക്ക് ലഭിക്കണം, കൈമാറ്റം ലളിതമാണോ എൻക്രിപ്റ്റ് ചെയ്തതാണോ, ഏത് പാത അതിനെ വഹിക്കണം. ഒരു ദാതാവിന്റെ പേരിന് രണ്ടാമത്തേതോ മൂന്നാമത്തേതോ നിറയ്ക്കാനാകില്ല, ഒരു രാജ്യ ലേബലിന് അവയിലൊന്നും നിറയ്ക്കാനാകില്ല. മാറ്റത്തിന് മുമ്പ് മൂന്ന് എൻട്രികൾ എഴുതി സൂക്ഷിക്കുക, ശേഷം അവ താരതമ്യം ചെയ്യുക. ആ എൻട്രികൾ പരസ്പരം മാറ്റാവുന്നവയല്ല, അവയെ ഒന്നായി കാണുന്നതാണ് ഒരു ഊഹം രേഖയാകുന്ന വഴി.

പ്രവർത്തിക്കുന്ന ക്രമീകരണത്തെ രേഖപ്പെടുത്തിയ തീരുമാനമാക്കി മാറ്റുന്നത് താരതമ്യമാണ്. അതില്ലാതെ അടുത്ത വ്യക്തിക്ക് യാതൊരു കാരണവുമില്ലാത്ത ഒരു വിലാസം പാരമ്പര്യമായി ലഭിക്കുന്നു. താഴെയുള്ള പട്ടികയുടെ മൂന്നാം നിര ആദ്യം വായിക്കുക, കാരണം മിക്ക ആത്മവിശ്വാസമുള്ള വിശദീകരണങ്ങളും യഥാർത്ഥത്തിൽ അവസാനിക്കുന്നത് അവിടെയാണ്.

EntryWhat it recordsWhat it cannot tell you
RecipientWhich resolver should answerWho operates the path to it
TransportPlain DNS or an encrypted variantWhether names stay private
PathWhich interface carries the queryWhich upstream answers last

പട്ടിക ബോധപൂർവം ചെറുതാണ്. അതിന്റെ കാര്യം ഓരോ എൻട്രിയും വ്യത്യസ്ത ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു എന്നതും ഒരു ഫീൽഡും മൂന്നും നിറയ്ക്കുന്നില്ല എന്നതുമാണ്.

ഒരു പ്രാദേശിക ഫോർവേഡർ യഥാർത്ഥ ഉറവിടം മറയ്ക്കുന്നു

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

സ്റ്റബ് അതേ ഔട്ട്പുട്ട് പട്ടികപ്പെടുത്തുന്ന ഉറവിടങ്ങളിലേക്ക് കൈമാറുന്നു, സാധാരണയായി കൂടുതൽ താഴെ. ഓപ്പറേറ്ററെക്കുറിച്ച് എന്തെങ്കിലും അനുമാനിക്കുന്നതിന് മുമ്പ് മുഴുവൻ ശൃംഖലയും വായിക്കുക, ആദ്യ വരി മുഴുവൻ ഉത്തരമല്ല. അല്ലെങ്കിൽ നിങ്ങൾ സ്വീകരണത്തെ കമ്പനി എന്ന് വിളിക്കുകയാണ്.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

രണ്ടാമത്തെ കമാൻഡ് റെസോൾവറിന്റെ പ്രതിധ്വനി നാമം ഉപയോഗിക്കുന്നു, ഓപ്പറേറ്റർ ഒന്ന് പ്രസിദ്ധീകരിക്കുന്നിടത്ത്, അത് കാണുന്ന ഉറവിട വിലാസം റിപ്പോർട്ട് ചെയ്യാൻ. മൂന്നാമത്തേത് ഉത്തരം നൽകിയ സെർവറിനെ പേരിടുന്നു, അത് പലപ്പോഴും നിങ്ങൾ ക്രമീകരിച്ച വിലാസമല്ല. ഓപ്പറേറ്ററെ എഴുതുന്നതിന് മുമ്പ് മൂന്ന് ഔട്ട്പുട്ടുകളും താരതമ്യം ചെയ്യുക.

എൻക്രിപ്റ്റ് ചെയ്ത DNS എന്ത് കാണാമെന്നത് മാറ്റുന്നു, ആര് കാണുന്നു എന്നതല്ല

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

മാറാത്തത് വിശ്വാസ ബന്ധമാണ്, അത് ഇപ്പോഴും ആ അന്ത്യബിന്ദു നടത്തുന്ന സ്ഥാപനത്തിലേക്കാണ് ചൂണ്ടുന്നത്. സ്വന്തം സുരക്ഷിത DNS ക്രമീകരണമുള്ള ഒരു ബ്രൗസറിന് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ റെസോൾവറിനെ പൂർണ്ണമായി ഒഴിവാക്കാം. ഇവയെ രണ്ടുതവണ പ്രയോഗിച്ച ഒരു ക്രമീകരണമായല്ല, യോജിക്കാതിരിക്കാവുന്ന രണ്ട് കോൺഫിഗറേഷനുകളായി കാണുക.

സ്വകാര്യ നാമങ്ങൾക്ക് വീണ്ടും സ്വന്തം തീരുമാനം വേണം. ഒരു ജോലി ടണലിന് തിരഞ്ഞെടുത്ത ഡൊമെയ്നുകൾ സ്ഥാപന റെസോൾവറുകളിലേക്ക് അയക്കാം, അത് പൊതു സേവനം കൊണ്ട് മാറ്റുന്നത് ആന്തരിക തിരച്ചിലുകൾ തകർക്കാം അല്ലെങ്കിൽ ആന്തരിക നാമങ്ങൾ തെറ്റായ കക്ഷിക്ക് വെളിപ്പെടുത്താം. മുഴുവൻ അഡാപ്റ്ററിന്റെ ക്രമീകരണങ്ങളും മാറ്റുന്നതിന് മുമ്പ് ഡൊമെയിൻ നയം പരിശോധിക്കുക.

നിരീക്ഷണം ഇടുങ്ങിയതായി നിർത്തുക

താരതമ്യം ചെയ്യുമ്പോൾ പഴയ കോൺഫിഗറേഷൻ സൂക്ഷിക്കുക, ഒരു സമയത്ത് ഒരു ക്രമീകരണം മാറ്റുക. ആപ്ലിക്കേഷൻ, പ്രവർത്തനം, റെസോൾവർ നയം, വീണ്ടും കണക്ട് ചെയ്തതിന് ശേഷം പൊതു, അനുവദിച്ച സ്വകാര്യ നാമങ്ങൾ ഇപ്പോഴും പരിഹരിക്കപ്പെടുന്നുണ്ടോ എന്നിവ രേഖപ്പെടുത്തുക. രണ്ട് മാറ്റങ്ങളുള്ള താരതമ്യം ഒന്നിനെയും തെളിയിക്കുന്നില്ല. ഫലം അടുത്ത വ്യക്തി കണ്ടെത്തുന്നിടത്ത്, ക്രമീകരണത്തിന് തൊട്ടടുത്ത് എഴുതുക.

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കാൻ തുടങ്ങിയാൽ, തെളിവുകൾ അനുവദിക്കുന്നത്ര ചെറുതായി അവകാശവാദം നിർത്തുക. ആ മാറ്റം ഒരു പരീക്ഷണത്തിന് സഹായിച്ചു, മുമ്പത്തെ റെസോൾവർ ദുരുദ്ദേശ്യത്തോടെ പ്രവർത്തിച്ചോ, ടണൽ തകർന്നിരുന്നോ, മറ്റൊരു ഉപകരണത്തിന് അതേ മാറ്റിസ്ഥാപനം വേണോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ശാശ്വതമായ ഫലം അതിന്റെ ഓപ്പറേറ്ററും ഉദ്ദേശ്യവും വിശദീകരിക്കാനാകുന്ന ഒരു കോൺഫിഗറേഷനാണ്.

അനുബന്ധ ലേഖനങ്ങൾ