ഒരു ക്ലയന്റിന് resolver വിലാസം നൽകുന്നത് ചോദ്യങ്ങൾ എവിടേക്ക് പോകുന്നു എന്ന് തീരുമാനിക്കുന്നു, resolver ഏത് ഉറവിടം കാണും എന്നല്ല. റൂട്ടിംഗ്, ഫോർവേഡിംഗ്, വിലാസപരിവർത്തനം എന്നിവ രണ്ട് അറ്റങ്ങൾക്കിടയിൽ ഊഴം വെച്ച് ഇടപെടുന്നു. ഉറവിടത്തെക്കുറിച്ചുള്ള ചോദ്യങ്ങൾക്കായുള്ള കൈപ്പുസ്തകം ചോദ്യത്തെ ഘട്ടം ഘട്ടമായി പിന്തുടരുകയും ഓരോ നിരീക്ഷകനും യഥാർത്ഥത്തിൽ എന്ത് കണ്ടു എന്ന് രേഖപ്പെടുത്തുകയും ചെയ്യുന്നു. ക്രമം പ്രധാനമാണ്, കാരണം നിരീക്ഷണത്തിന് മുൻപ് പറയുന്ന അവകാശവാദം മികച്ച രൂപത്തിലുള്ള ഊഹം മാത്രമാണ്.

തെളിവുകൾ ശേഖരിക്കുന്നതിന് മുൻപ് ക്രമീകരണം എഴുതുക

നാല് സ്ഥലങ്ങൾക്ക് DNS ഉറവിടത്തെക്കുറിച്ച് നിങ്ങളോട് എന്തെങ്കിലും പറയാനാകും, എല്ലാം ഒരേ കാര്യം പറയുന്നില്ല. ക്ലയന്റിന്റെ കേർണലിന് ഏത് ഉറവിടം ഉപയോഗിക്കുമെന്ന് അറിയാം, ഫോർവേഡർക്ക് മുകളിലേക്ക് എന്ത് അയച്ചു എന്ന് അറിയാം, പരിവർത്തനം ചെയ്യുന്ന ഉപകരണത്തിന് എന്ത് വീണ്ടും എഴുതി എന്ന് അറിയാം, സ്വീകരിക്കുന്ന resolver-ന് എന്ത് എത്തി എന്ന് അറിയാം. എന്തെങ്കിലും ശേഖരിക്കുന്നതിന് മുൻപ് ഇവയിൽ ഏതൊക്കെയിലേക്ക് നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ എത്താനാകും എന്ന് എഴുതുക.

Observation pointWhat it can proveWhat it cannot proveHow to read it
client kernelwhich source address it would use for that resolveranything a device in between rewroteip route get against the resolver address
forwarderthat it sent an upstream query, and from which sourcewhat the client originally asked forits own log and its cache state
translating devicethat a source was rewritten, and to whatwhether the query was legitimateNAT policy and its counters
receiving resolverthe address that actually arrivedwhich client behind that address askeda scoped capture on port 53

ഉപയോഗത്തിലുണ്ടെന്ന് നിങ്ങൾ കരുതുന്ന resolver ഉൾപ്പെടെ നിങ്ങളുടെ പ്രതീക്ഷയും എഴുതുക. വിഭജിത പാത ചോദ്യത്തെ തികച്ചും വേറെയെവിടെയോ അയക്കാം, കാഷെക്ക് മുകളിലേക്കുള്ള ഒരു കൈമാറ്റവുമില്ലാതെ ഉത്തരം നൽകാം, അതിനാൽ മനസ്സിൽ മാത്രം സൂക്ഷിക്കുന്ന അനുമാനം ആദ്യത്തെ അത്ഭുതം വരെ നിലനിൽക്കില്ല. പ്രഖ്യാപിത രൂപകൽപ്പനയും നിരീക്ഷിച്ച പാതയും ഒരേ കുറിപ്പിന്റെ വെവ്വേറെ നിരകളിൽ സൂക്ഷിക്കുക; രണ്ടും ഒത്തുപോകാത്തപ്പോൾ, പിന്തുടരാൻ അർഹതയുള്ള ചോദ്യം നിങ്ങൾ കണ്ടെത്തി.

ചോദ്യം യഥാർത്ഥത്തിൽ ഏത് പ്രക്രിയയാണ് അയച്ചതെന്ന് പരിശോധിക്കുക

ക്ലയന്റിൽ നിന്ന് തുടങ്ങുക: resolver വിലാസം, ചോദ്യത്തിന്റെ പേര്, സമയം എന്നിവ രേഖപ്പെടുത്തി, ഏത് പ്രക്രിയയാണ് അയച്ചതെന്ന് സ്ഥിരീകരിക്കുക. താഴെയുള്ള ആദ്യ വരി UDP സോക്കറ്റ് കൈവശം വയ്ക്കുന്ന പ്രക്രിയയെ പേരിടുന്നു, അതാണ് ഈ തലക്കെട്ട് വാഗ്ദാനം ചെയ്യുന്ന പരിശോധന. ആ പ്രക്രിയ സിസ്റ്റം resolver-ന് പകരം ബ്രൗസർ സഹായിയോ കണ്ടെയ്നർ റൺടൈമോ ആണെങ്കിൽ, ബാക്കി ട്രെയ്സ് ആരും ആവശ്യപ്പെടാത്ത ഒരു പാതയെ വിവരിക്കുന്നു.

ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53

ഒന്നിലധികം ഇന്റർഫേസുകളുള്ള ഹോസ്റ്റിൽ, മറ്റെവിടെയും നോക്കുന്നതിന് മുൻപ് ആ ലക്ഷ്യത്തിന് കേർണൽ ഏത് ഉറവിട വിലാസം തിരഞ്ഞെടുക്കുന്നു എന്ന് കണ്ടെത്തുക. പാത പൂർണ്ണമായും നിങ്ങളുടെ നിയന്ത്രണത്തിലുള്ള അവസാന പോയിന്റ് അതാണ്, resolver റിപ്പോർട്ട് ചെയ്യുന്നതുമായി നിങ്ങൾ താരതമ്യം ചെയ്യുന്ന മൂല്യവും അതാണ്. വ്യത്യാസം എന്നത് ഇടയിൽ എന്തോ പാക്കറ്റ് വീണ്ടും എഴുതി, അല്ലെങ്കിൽ രണ്ട് വ്യത്യസ്ത ചോദ്യങ്ങൾ അയച്ചു എന്നതിന്റെ സൂചനയാണ്.

പരീക്ഷണ നാമങ്ങൾ ആന്തരികമായി സൂക്ഷിക്കുക, കാരണം പൊതു resolver-ന് അയക്കുന്ന ആന്തരിക നാമം ആന്തരിക പാതയെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, കൂടാതെ പ്രസിദ്ധീകരിക്കേണ്ട ആവശ്യമില്ലാത്ത ഒരു നാമം പ്രസിദ്ധീകരിക്കുന്നു. സുരക്ഷിത DNS ഓണാക്കിയ ബ്രൗസർ ആ സോക്കറ്റ് പട്ടികയിൽ ഒട്ടും പ്രത്യക്ഷപ്പെടില്ല, ആ അഭാവം തന്നെയാണ് ഉത്തരം.

ഫോർവേഡർ രണ്ടാമത്തെ, വേറിട്ട ഒരു ചോദ്യം ചെയ്യുന്നു

ഫോർവേഡർ ഒരു കൈമാറ്റത്തെ രണ്ടാക്കി മാറ്റുന്നു. താഴെ നിന്നുള്ള അഭ്യർത്ഥന എത്തുന്നു, തുടർന്ന് ഫോർവേഡർ താൻ തിരഞ്ഞെടുക്കുന്ന വിലാസത്തിൽ നിന്ന് സ്വന്തം ചോദ്യം മുകളിലേക്ക് അയക്കുന്നു. മുകളിലെ resolver എന്ത് കാണുന്നു എന്ന് ക്ലയന്റല്ല, അതിന്റെ കോൺഫിഗറേഷനാണ് തീരുമാനിക്കുന്നത്.

dnsmasq കൈപ്പുസ്തകം അതേ കാരണത്താൽ വായിക്കാൻ യോഗ്യമാണ്: ഫോർവേഡർ മുകളിലെ സെർവറുകൾ എങ്ങനെ തിരഞ്ഞെടുക്കുന്നു, തന്റെ കേൾവി വശം എങ്ങനെ ബന്ധിക്കുന്നു എന്ന് അത് രേഖപ്പെടുത്തുന്നു, ആ ക്രമീകരണത്തിൽ ഒന്നും ക്ലയന്റിന്റെ ഉറവിടം മുകളിലേക്ക് കൊണ്ടുപോകുന്നില്ല. അതിനാൽ ഗേറ്റ്‌വേ വിലാസം കാണിക്കുന്ന resolver ലോഗ് സാധാരണമാണ്, തകരാറിന്റെ തെളിവല്ല. അഭാവവും അത്രതന്നെ എളുപ്പം തെറ്റായി വായിക്കാം, കാരണം കാഷെ ഹിറ്റ് ഒരു മുകളിലേക്കുള്ള ചോദ്യവും സൃഷ്ടിക്കുന്നില്ല, ഒരിക്കലും എത്താത്ത ചോദ്യത്തോട് തികച്ചും സമാനമായി കാണപ്പെടുന്നു. രണ്ടിൽ ഏതെങ്കിലും ഒരു നിഗമനത്തിലെത്തുന്നതിന് മുൻപ് ഫോർവേഡറുടെ കോൺഫിഗറേഷനും അതിന്റെ കാഷെ അവസ്ഥയും വായിക്കുക. രണ്ട് ചോദ്യങ്ങൾ, നോക്കാൻ രണ്ട് സ്ഥലങ്ങൾ.

ഉറവിടം സ്വീകരിക്കുന്ന resolver-ൽ വായിക്കുക

ഇത് തീരുമാനിക്കുന്ന ഏക നിരീക്ഷണം സെർവർ ഭാഗത്ത് നിന്നാണ് എടുക്കുന്നത്. ക്ലയന്റിന്റെ ഇന്റർഫേസ് പട്ടികയിൽ നിന്ന് അനുമാനിക്കുന്നതെല്ലാം resolver യഥാർത്ഥത്തിൽ എന്ത് എത്തി എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നത് വരെ അനുമാനം തന്നെയാണ്.

tcpdump -ni any port 53 and host 10.20.30.53

resolver ഹോസ്റ്റിൽ ക്യാപ്ചർ ചെയ്യുക, ക്യാപ്ചർ ചെറുതും പരിമിതവുമായി സൂക്ഷിക്കുക, നയം അനുവദിക്കുന്നിടത്ത് സംഭരിക്കുക. നിരീക്ഷിച്ച ഉറവിടം പരിവർത്തനം ചെയ്ത വിലാസമാണെങ്കിൽ, അടുത്ത ചോദ്യം ഏത് ഉപകരണമാണ് പരിവർത്തനം ചെയ്തത്, അതിന്റെ നയം ഉദ്ദേശിച്ചതാണോ എന്നതാണ്. ക്യാപ്ചർ എന്ത് എത്തി എന്ന് ഉത്തരം നൽകുന്നു; നയം എന്തുകൊണ്ട് അനുവദിച്ചു എന്ന് വിശദീകരിക്കുന്നില്ല. കുറിപ്പിൽ നിരീക്ഷകനെയും ഘട്ടത്തെയും പേരിടുക, കാരണം ഗേറ്റ്‌വേയെക്കുറിച്ചുള്ള സ്വകാര്യതാ അവകാശവാദം ആ ഘട്ടത്തെക്കുറിച്ചാണ്, മുഴുവൻ പാതയെക്കുറിച്ചല്ല.

കണ്ടെത്തൽ പാതയായി എഴുതുക, വിലാസമായി അല്ല

ക്ലയന്റ്, resolver, ഏതെങ്കിലും ഫോർവേഡർ, ഓരോ ഘട്ടത്തിലും നിരീക്ഷിച്ച ഉറവിടം, അതിനെ നിയന്ത്രിക്കുന്ന നയം എന്നിവ രേഖപ്പെടുത്തുക. അത്തരം ഒരു രേഖ മറ്റൊരു ക്യാപ്ചർ കൂടാതെ ഭാവിയിലെ മിക്ക ചോദ്യങ്ങൾക്കും ഉത്തരം നൽകുന്നു. അത് ഒരു ശൃംഖലയായി വരയ്ക്കുക, കാരണം വിലാസങ്ങളുടെ പട്ടിക ഏത് ഘട്ടം ഏത് ഉണ്ടാക്കി എന്ന് മറയ്ക്കുന്നു.

ചിത്രത്തിൽ തീയതി, ക്ലയന്റ് പതിപ്പ്, കോൺഫിഗറേഷൻ പുനരവലോകനം എന്നിവ ചേർക്കുക, പിന്നീട് വരുന്ന വായനക്കാരന് അത് ഇപ്പോഴും ബാധകമാണോ എന്ന് പറയാൻ കഴിയും. ഗതാഗത ഉറവിടത്തെ സേവനം പ്രോസസ്സ് ചെയ്യുന്ന മറ്റെല്ലാത്തിൽ നിന്നും വേർതിരിക്കുക, കാരണം ഗേറ്റ്‌വേ വിലാസം കാണുന്നത് മറ്റെന്ത് സൂക്ഷിക്കുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. resolver-ന്റെ സ്ഥാനവും ഏത് ക്ലയന്റ് ചോദിച്ചു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഈ അവകാശവാദങ്ങൾ വേർതിരിച്ച് സൂക്ഷിക്കുന്നതാണ് നിഗമനത്തെ അവലോകനത്തിൽ നിലനിർത്തുന്നത്.

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