സ്വയം അന്വേഷിക്കുന്ന ക്ലയന്റിന് മാത്രം SRV റെക്കോർഡ് സഹായിക്കുന്നത് എന്തുകൊണ്ട്

നിങ്ങളുടെ സോണിൽ SRV റെക്കോർഡ് ചേർക്കുന്നത് ഒരു VPN ക്ലയന്റിനെയും അത് തിരയാൻ പഠിപ്പിക്കുന്നില്ല. ക്ലയന്റ് ലേബൽ അറിയുകയും ക്വറി അയയ്ക്കാൻ തീരുമാനിക്കുകയും തിരികെ വരുന്നതനുസരിച്ച് പ്രവർത്തിക്കുകയും വേണം, ആദ്യത്തെ രണ്ടെണ്ണം DNS നൽകാൻ കഴിയില്ല. അതിനാൽ പരാജയപ്പെട്ട ഭൂരിഭാഗം SRV പദ്ധതികളും DNS വേഷത്തിലുള്ള ക്ലയന്റ് പ്രശ്നങ്ങളാണ്. ആദ്യം ക്ലയന്റിന്റെ കണ്ടെത്തൽ സ്വഭാവം വായിക്കുക, പിന്നീട് അത് യഥാർത്ഥത്തിൽ അന്വേഷിക്കുന്ന ലേബൽ മാത്രം പ്രസിദ്ധീകരിക്കുക.

ആരും അന്വേഷിക്കാത്ത റെക്കോർഡിന് ആരെയും സഹായിക്കാനാകില്ല

SRV ഒരു സേവനത്തിന്റെ സ്ഥാനം പ്രസിദ്ധീകരിക്കുന്നു; അത് സേവനം പ്രഖ്യാപിക്കുന്നില്ല. റെക്കോർഡിനെ ക്ലയന്റിലേക്ക് തള്ളുന്ന ഒന്നുമില്ല, ഒരിക്കലും ആവശ്യപ്പെടാത്ത ഒരു പേര് ഏതെങ്കിലും റിസോൾവർ സ്വമേധയാ നൽകുന്നുമില്ല. ആപ്ലിക്കേഷൻ അത് ചെയ്യാൻ തീരുമാനിക്കുമ്പോഴാണ് തിരയൽ ആരംഭിക്കുന്നത്, അതിനാൽ ലേബൽ ഉൽപ്പന്ന ഡോക്യുമെന്റേഷനിൽ നിന്നോ നെറ്റ്വർക്കിലെ സോഫ്റ്റ്വേർ നിരീക്ഷണത്തിൽ നിന്നോ വരണം. ക്ലയന്റിന് കണ്ടെത്തൽ ഘട്ടമില്ലാത്തിടത്ത്, റെക്കോർഡ് സോൺ മാറ്റുന്നു, മറ്റൊന്നുമല്ല.

അതുകൊണ്ടാണ് നെറ്റ്വർക്കിലെ ഒരു ഉൽപ്പന്നം പ്രവർത്തിക്കാൻ തുടങ്ങുമ്പോൾ മറ്റൊന്നിനെ അതേ മാറ്റം ബാധിക്കാത്തത്. ചരം സോഫ്റ്റ്വേറാണ്, DNS സെർവർ അതിനോട് പറഞ്ഞത് കൃത്യമായി ചെയ്യുന്നു. എഡിറ്റിന് ശേഷം സോൺ വീണ്ടും വായിക്കുക, കാരണം തെറ്റായി ടൈപ്പ് ചെയ്ത ലേബൽ ഒരുപോലെ കാണുന്ന റെക്കോർഡുകൾക്കിടയിൽ എളുപ്പം ഒളിക്കുന്നു.

എഴുതുന്നതിന് മുമ്പ് ഫീൽഡുകൾ വായിക്കുക

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

ഈ ഫീൽഡുകളൊന്നും ക്രെഡൻഷ്യലുകളോ സർട്ടിഫിക്കറ്റ് നയമോ ആപ്ലിക്കേഷൻ പതിപ്പോ വഹിക്കുന്നില്ല, തൂക്കം അവഗണിക്കുന്ന ക്ലയന്റും ബന്ധിപ്പിക്കുന്നു, ഉദ്ദേശിച്ച സന്തുലിതാവസ്ഥയില്ലാതെ മാത്രം. ലക്ഷ്യത്തിന് സ്വന്തം വിലാസ റെക്കോർഡുകൾ വേണം, അത് അലിയാസിന് പകരം കാനോനിക്കൽ നാമമായിരിക്കണം. ശ്രോതാവില്ലാത്ത ഹോസ്റ്റിലേക്ക് ചൂണ്ടുന്ന റെക്കോർഡ് പ്രസിദ്ധീകരിക്കുന്നത് DNS തകരാറായി വായിക്കുന്ന കണക്ഷൻ പിശക് ഉണ്ടാക്കുന്നു, അതാണ് ഏറ്റവും ചെലവേറിയ തെറ്റായ വഴികാട്ടൽ. മുഴുവൻ ശൃംഖലയും പ്രസിദ്ധീകരിക്കുക, അല്ലെങ്കിൽ അതിൽ ഒന്നും അല്ല.

ക്ലയന്റ് യഥാർത്ഥത്തിൽ അയയ്ക്കുന്ന ലേബൽ കണ്ടെത്തുക

ഉൽപ്പന്നത്തിന്റെ പേരിനെക്കുറിച്ചുള്ള ഊഹത്തിൽ നിന്നല്ല, തെളിവിൽ നിന്ന് ലേബൽ നിർണ്ണയിക്കുക. ഒന്നുകിൽ ഡോക്യുമെന്റേഷൻ സേവനത്തിന്റെ പേര് പറയുന്നു, അല്ലെങ്കിൽ ക്യാപ്ചർ ക്ലയന്റ് ആരംഭിക്കുമ്പോൾ പുറപ്പെടുന്ന ക്വറി കാണിക്കുന്നു. രണ്ട് വഴികളും ഒരേ സ്ഥലത്ത് അവസാനിക്കുന്നു: റിസോൾവറിനെതിരെ പരിശോധിക്കാൻ കൃത്യമായ പേരും തരവും.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

ഉത്തരം നിങ്ങൾ പ്രസിദ്ധീകരിച്ച റെക്കോർഡുമായി അക്ഷരം തോറും താരതമ്യം ചെയ്യുക, കാരണം അണ്ടർസ്കോറുകളും അവസാനത്തെ ഡോട്ടും പേരിന്റെ ഭാഗമാണ്. യഥാർത്ഥത്തിൽ അയച്ച ക്വറിക്കുള്ള ശൂന്യമായ ഉത്തരം സോണിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നു, ക്വറി ഒട്ടുമില്ലാത്തത് ക്ലയന്റിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നു, ഈ കണ്ടെത്തലുകൾ നിങ്ങളെ വ്യത്യസ്ത ടീമുകളിലേക്ക് അയയ്ക്കുന്നു. യഥാർത്ഥ ഉത്തരം താഴെയുള്ള വരി പോലെയാണ്, അവിടെ മുൻഗണന 20 ഏതെങ്കിലും താഴ്ന്ന മുൻഗണനയുള്ള റെക്കോർഡിനോട് തോൽക്കുന്നു, ക്ലയന്റ് പേരിട്ട ലക്ഷ്യത്തിൽ പോർട്ട് 8443 ഡയൽ ചെയ്യുന്നു.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

ലക്ഷ്യവും നിലനിൽക്കണം

റിസോൾവ് ചെയ്യുന്ന ലക്ഷ്യം ഉത്തരം നൽകുന്ന സേവനമല്ല. ലക്ഷ്യത്തിന്റെ വിലാസ റെക്കോർഡുകൾ പരിശോധിക്കുക, തുടർന്ന് പ്രസിദ്ധീകരിച്ച പോർട്ടിലും പ്രോട്ടോക്കോളിലും എന്തെങ്കിലും കേൾക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. UDP മാത്രം കേൾക്കുന്നയിടത്തേക്ക് ചൂണ്ടുന്ന TCP റെക്കോർഡ് ഏതെങ്കിലും സോൺ എഡിറ്റിംഗ് പരിഹരിക്കാത്ത പൊരുത്തക്കേടാണ്. ലക്ഷ്യം ചലനാത്മകമായിരിക്കുമ്പോൾ TTL ചെറുതായി സൂക്ഷിക്കുക, പേര് ചലിക്കുന്നത് നിലയ്ക്കുമ്പോൾ അത് നീട്ടുക.

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

കണ്ടെത്തൽ ഒരു പ്രാമാണീകരണമല്ല

SRV ഉത്തരം എവിടെ ബന്ധിപ്പിക്കണം എന്ന് പറയുന്നു, എത്തിയ ശേഷം ആരെ വിശ്വസിക്കണം എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നുമില്ല. ക്ലയന്റിന്റെ സർട്ടിഫിക്കറ്റ് സാധൂകരണവും സെർവർ ഐഡന്റിറ്റി പരിശോധനകളും മുമ്പുണ്ടായിരുന്നതുപോലെ തന്നെ വയ്ക്കുക, കാരണം മറ്റൊരാൾ വ്യാജമാക്കാവുന്ന റെക്കോർഡ് വിശ്വാസ തീരുമാനമാകരുത്. DNS ഉത്തരങ്ങൾ കാഷ് ചെയ്യാനും സോൺ നിയന്ത്രിക്കുന്ന ആർക്കും എഡിറ്റ് ചെയ്യാനും കഴിയും, ഇത് നയം എൻകോഡ് ചെയ്യാൻ അവയെ മോശം സ്ഥലമാക്കുന്നു.

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