TLS-ന് മേലെ DNS ഒപ്പം VPN: ഏത് ഭാഗമാണ് സംരക്ഷിതം

TLS-ന് മേലെയുള്ള DNS ക്ലയന്റും അത് തിരഞ്ഞെടുത്ത resolver-ഉം തമ്മിലുള്ള കൈമാറ്റം എൻക്രിപ്റ്റ് ചെയ്യുന്നു, എന്നാൽ resolver ഇപ്പോഴും പേര് വായിക്കുന്നു. ഈ വാക്യം DoT-ഉം VPN-ഉം ചുറ്റുമുള്ള ആശയക്കുഴപ്പത്തിന്റെ ഭൂരിഭാഗവും തീർക്കുന്നു. എൻക്രിപ്റ്റ് ചെയ്ത ക്വറി ഏത് വഴിയിലൂടെ പോകുന്നു എന്ന് ടണൽ തീരുമാനിക്കുന്നു, അതേസമയം resolver എന്താണ് ചോദിച്ചതെന്ന് അറിയുന്നു. രണ്ട് സംവിധാനങ്ങളും പരസ്പരം പകരമാകുന്നില്ല, ഒന്നും മറ്റൊന്നിനെ അനാവശ്യമാക്കുന്നുമില്ല.

നിങ്ങളുടെ പക്കലുള്ള ക്രമീകരണം നിങ്ങൾ കരുതുന്നത് തന്നെയാണോ എന്ന് നാല് പരിശോധനകൾ തീരുമാനിക്കുന്നു.

പരിശോധന 1: എൻക്രിപ്ഷൻ എന്തിനെ ഉൾക്കൊള്ളുന്നു

DoT DNS കൈമാറ്റം TLS-ൽ പൊതിയുന്നു, അതിനാൽ വഴിയിലുള്ള നിരീക്ഷകൻ ക്വറിയിലെ പേരിന് പകരം വിലാസത്തിലേക്കും പോർട്ടിലേക്കുമുള്ള കണക്ഷൻ കാണുന്നു. resolver തന്നെ ഡീക്രിപ്റ്റ് ചെയ്ത് ഉത്തരം നൽകുന്നു. HTTPS-ന് മേലെയുള്ള DNS-മായി ഇതിനെ താരതമ്യം ചെയ്യുക: രണ്ടും എൻക്രിപ്റ്റ് ചെയ്യുന്നു, വ്യത്യസ്ത ട്രാൻസ്പോർട്ടുകൾ ഉപയോഗിക്കുന്നു, അതിനാൽ വെബ് ട്രാഫിക്ക് അനുവദിക്കുന്ന നെറ്റ്വർക്ക് DoT കണക്ഷൻ സ്വയമേവ അനുവദിക്കുന്നില്ല.

ഒരു കാപ്റ്റീവ് പോർട്ടലോ ഫിൽട്ടർ ചെയ്യുന്ന ഇടനില പെട്ടിയോ 443 അനുവദിച്ച് 853 തടയുമ്പോൾ ഈ വ്യത്യാസം പ്രധാനമാണ്. അവിടെ പ്രവർത്തിച്ച ഉപകരണം മറ്റൊന്നും പ്രവർത്തിക്കും എന്നതിന് തെളിവല്ല.

പരിശോധന 2: ക്വറി ഏത് റൂട്ടിലൂടെ പോകുന്നു

റൂട്ട് ക്ലയന്റ് നയത്തിന്റെ ചോദ്യമാണ്. DoT resolver-ൽ ടണലിലൂടെയും പുറത്തുനിന്നും നെറ്റ്വർക്കിനൊപ്പം മാറുന്ന വഴിയിലൂടെയും എത്താം. ഏത് സംഭവിക്കുന്നു എന്നത് റൂട്ടുകളെയും ക്ലയന്റ് സ്വന്തം DNS സോക്കറ്റ് സംരക്ഷിക്കുന്നുണ്ടോ എന്നതിനെയും ആശ്രയിച്ചിരിക്കുന്നു. എല്ലാ ട്രാഫിക്കും പിടിക്കുന്ന ടണൽ സാധാരണയായി ക്വറിയും കൂടെ കൊണ്ടുപോകുന്നു, resolver വിലാസം എന്ത് പറഞ്ഞാലും.

പരീക്ഷയിൽ മൂന്നാം കക്ഷി resolver വിലാസം കാണുന്നത് ബൈപ്പാസ് തെളിയിക്കുന്നില്ല, എൻക്രിപ്ഷൻ കാണുന്നത് ഉദ്ദേശിച്ച സ്വീകർത്താവിനെ തെളിയിക്കുന്നുമില്ല. resolver-ഉം വഴിയും വെവ്വേറെ വായിക്കുക, എന്നിട്ട് ജോഡി നിങ്ങൾ രൂപകൽപ്പന ചെയ്തത് തന്നെയാണോ എന്ന് തീരുമാനിക്കുക.

പരിശോധന 3: ആന്തരിക നാമങ്ങൾ

ആന്തരിക നാമങ്ങൾ പ്രസിദ്ധീകരിക്കുന്ന സ്ഥാപനത്തിന് ആ റെക്കോർഡുകൾ സൂക്ഷിക്കുന്ന resolver വേണം. പൊതു DoT സേവനത്തിന് നിങ്ങളുടെ സ്വകാര്യ നാമമേഖല അറിയില്ല, ക്ലയന്റിനെ അതിലേക്ക് തിരിച്ചുവിടുന്നത് ആ നാമങ്ങൾ പരാജയപ്പെടുമെന്ന് ഉറപ്പാക്കുന്നു. മാനേജ് ചെയ്യുന്ന ഉപകരണത്തിൽ ആരെങ്കിലും എൻക്രിപ്റ്റ് ചെയ്ത DNS പ്രവർത്തനക്ഷമമാക്കുമ്പോൾ ഏറ്റവും സാധാരണമായ പ്രായോഗിക തിരിച്ചടി ഇതാണ്.

ആന്തരിക പ്രത്യയങ്ങൾക്ക് ആന്തരിക resolver നിലനിർത്തുക, നയം ആവശ്യപ്പെടുന്നുവെങ്കിൽ ആ ചാട്ടം എൻക്രിപ്റ്റ് ചെയ്യുക, അതിനെ ഒരു പൊതു ദാതാവ് ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നതിന് പകരം.

പരിശോധന 4: പരാജയത്തിലെ പെരുമാറ്റം

എത്താവുന്ന resolver ഇല്ലാത്ത കർശന resolver ക്രമീകരണം ടണൽ ഉയർന്നു നിൽക്കുമ്പോൾ തന്നെ നാമപരിഹാര പരാജയം ഉണ്ടാക്കുന്നു. കീകളോ സർട്ടിഫിക്കറ്റുകളോ തൊടുന്നതിന് പകരം പ്ലാറ്റ്ഫോം മോഡും അതിന്റെ രേഖപ്പെടുത്തിയ ഫോൾബാക്കും നോക്കുക.

നിശ്ശബ്ദമായി സാധാരണ DNS ഉപയോഗിക്കുന്ന ഫോൾബാക്ക് ഒരു നയ തീരുമാനമാണ്, സൗകര്യമല്ല. പരാജയം ദൃശ്യമാകണോ അതോ ബലഹീനമായ എന്തിലേക്കെങ്കിലും താഴണോ എന്ന് തീരുമാനിച്ച് ഉത്തരം എഴുതുക.

സർട്ടിഫിക്കറ്റിൽ വിശ്വസിക്കുക, ഉത്തരത്തിലല്ല

സേവനത്തിനായി രേഖപ്പെടുത്തിയ ദാതാവിന്റെ ഹോസ്റ്റ്നാമും പരിശോധന കോൺഫിഗറേഷനും ഉപയോഗിക്കുക. അപരിചിതമായ resolver ഉത്തരം നൽകാൻ TLS പരിശോധനകൾ ഓഫ് ചെയ്യുന്നത് പരിശോധിക്കാത്ത എൻഡ്പോയിന്റിലേക്ക് എൻക്രിപ്റ്റ് ചെയ്ത ചാനൽ തരുന്നു, ഇത് മാറ്റിസ്ഥാപിച്ച സാധാരണ ക്വറിയേക്കാൾ ഒരു പ്രത്യേക കാര്യത്തിൽ മോശമാണ്: അത് സുരക്ഷിതമായി തോന്നുന്നു. DNS over TLS സ്പെസിഫിക്കേഷൻ ആ പരിശോധനയുടെ പിന്നിലെ പ്രാമാണീകരണ പ്രതീക്ഷ വിശദീകരിക്കുന്നു.

നിങ്ങൾക്ക് പ്രാമാണീകരിക്കാൻ കഴിയാത്ത resolver-ന്റെ ഉത്തരം ഒരു അവകാശവാദമാണ്, ഫലമല്ല.

ഇത് എന്താണ് വിശദീകരിക്കാതെ വിടുന്നത്

DoT resolver-ൽ നിന്ന് പേര് മറയ്ക്കുന്നില്ല, കണക്ഷന്റെ ലക്ഷ്യവിലാസം നെറ്റ്വർക്കിൽ നിന്ന് മറയ്ക്കുന്നില്ല, ക്വറി ടണലിലൂടെ പോയോ എന്ന് തീരുമാനിക്കുന്നുമില്ല. അവ മൂന്ന് വെവ്വേറെ ചോദ്യങ്ങളും മൂന്ന് വെവ്വേറെ ഉത്തരങ്ങളുമാണ്.

resolver ഐഡന്റിറ്റി, ട്രാൻസിറ്റ് വഴി, ആന്തരിക-നാമ നയം എന്നിവ മൂന്ന് വരികളായി എഴുതുക. അടുത്തതായി ലഭിക്കുന്ന DNS ചോദ്യം അവയിലൊന്നായിരിക്കും.