രണ്ട് സൈറ്റുകൾ, ഒരു സ്വകാര്യ DNS സോൺ: റെക്കോർഡുകൾ ആരുടേതാണ്?

നിങ്ങൾ പച്ച സൈറ്റിൽ ഒരു ഹോസ്റ്റ് ചേർക്കുന്നു, അത് പച്ച ഉപയോക്താക്കൾക്ക് പരിഹരിക്കപ്പെടുന്നു, മഞ്ഞ ഓഫീസിന് ഇപ്പോഴും NXDOMAIN ലഭിക്കുന്നു. ഇത് VPN പരാജയമല്ല, കേടായ റിസോൾവറുമല്ല; ഇത് സ്വകാര്യ സോണിലെ ഉടമസ്ഥതയുടെ വിടവാണ്. വേറിട്ട് തിരുത്തിയ രണ്ട് റെക്കോർഡ് പട്ടികകൾ സൈറ്റുകൾ പരസ്പരം എത്തുന്നതുകൊണ്ട് മാത്രം ഒരു സോണാകുന്നില്ല. പരിഹാരം ഒരു പ്രസിദ്ധീകരണ പദ്ധതിയാണ്, മറ്റൊരു ഫയർവാൾ നിയമമല്ല.

രോഗലക്ഷണം കാണാത്ത ഉടമയെ പേരിടുന്നു

ഓരോ സൈറ്റിലും ആരെങ്കിലും ഒരു പേര് ആവശ്യമായപ്പോൾ ചേർത്ത പ്രാദേശിക ഓവർറൈഡ്, Pi-hole എൻട്രി അല്ലെങ്കിൽ dnsmasq വരി ഉണ്ടാകാം. പച്ച റെക്കോർഡ് പച്ച റിസോൾവറിൽ മാത്രമേ ഉള്ളൂ, അതിനാൽ മഞ്ഞയിലുള്ള ക്ലയന്റ് സ്വന്തം റിസോൾവറിനോട് ചോദിച്ച് സത്യമായ "അത്തരം പേരില്ല" ലഭിക്കുന്നു. പഴയ ഉത്തരം വ്യത്യസ്തമായി കാണപ്പെടുന്നു: ഹോസ്റ്റ് മാറി, ഒരു സൈറ്റ് അതിന്റെ പകർപ്പ് പുതുക്കി, മറ്റൊന്ന് ഇപ്പോഴും പഴയ വിലാസം തിരികെ നൽകുന്നു.

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

അതിനാൽ ഡിസൈൻ ചോദ്യം ഇടുങ്ങിയതും ഉത്തരം നൽകാവുന്നതുമാണ്: ആർക്ക് റെക്കോർഡ് സൃഷ്ടിക്കാം, അത് റെക്കോർഡ് അതിന് ഉത്തരം നൽകേണ്ട ഓരോ റിസോൾവറിലും എങ്ങനെ എത്തുന്നു?

ഓപ്ഷൻ A: സെക്കൻഡറികളുള്ള ഒരു അധികാര സോൺ

internal.example.com നുള്ള പ്രൈമറി പ്രവർത്തിപ്പിച്ച്, പിന്തുണയുള്ള സെക്കൻഡറികൾ ഓരോ സൈറ്റിലും സോൺ നേടാൻ അനുവദിക്കുക. ഓരോ സൈറ്റിന്റെയും റിക്കർസീവ് റിസോൾവർ പ്രാദേശിക സെക്കൻഡറിയോട് ചോദിക്കുന്നു, അതിനാൽ ഉത്തരങ്ങൾ ക്യാഷിൽ നിന്നല്ല, അധികാരമുള്ള ഉറവിടത്തിൽ നിന്ന് വരുന്നു, ഒരിക്കൽ ചെയ്ത മാറ്റം വീണ്ടും ടൈപ്പ് ചെയ്യുന്നതിനുപകരം കൈമാറ്റം ചെയ്യപ്പെടുന്നു.

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

സോൺ കൈമാറ്റങ്ങൾ വിലാസം അനുസരിച്ച് അറിയപ്പെടുന്ന സെക്കൻഡറികളിൽ പരിമിതപ്പെടുത്തുക, ഇംപ്ലിമെന്റേഷൻ പിന്തുണയ്ക്കുന്നിടത്ത് ഇടപാട് ഒപ്പുകൾ ഉപയോഗിക്കുക. തുറന്ന കൈമാറ്റം പോർട്ട് എത്താൻ കഴിയുന്ന ഏവർക്കുമുള്ള നിങ്ങളുടെ ആന്തരിക നാമസ്ഥലത്തിന്റെ പകർപ്പാണ്.

ചെലവ് ഏകോപനമാണ്: ഒരു തിരുത്തൽ പാത, ഒരു മാറ്റ അവലോകനം, റെക്കോർഡ് തെറ്റാകുമ്പോൾ ആരാണ് ഡ്യൂട്ടിയിൽ എന്നതിനെക്കുറിച്ചുള്ള പങ്കിട്ട ധാരണ.

ഓപ്ഷൻ B: ഓരോ സൈറ്റിനും ഒരു സബ്ഡൊമെയ്ൻ

പച്ച സൈറ്റിന് green.internal.example.com ഉം മഞ്ഞ സൈറ്റിന് yellow.internal.example.com ഉം നിയോഗിക്കുക. ഓരോ സൈറ്റും സ്വന്തം പേരുകൾക്ക് അധികാരമുള്ളതാകുന്നു, മാതൃ സോൺ നിയോഗ റെക്കോർഡുകൾ മാത്രം വഹിക്കുന്നു. ഒരു ഫയലിനുവേണ്ടിയുള്ള മത്സരം അപ്രത്യക്ഷമാകുന്നു, പ്രാദേശിക സംഘത്തിന് കേന്ദ്ര മാറ്റത്തിനായി കാത്തിരിക്കാതെ ഹോസ്റ്റ് ചേർക്കാം.

നിയോഗം മാതൃ സോണിൽ ഉണ്ടായിരിക്കണം, സൈറ്റിന്റെ അധികാര സെർവറുകളിലേക്ക് ചൂണ്ടുന്ന NS റെക്കോർഡുകളോടെ. പൂർണ്ണ നിയോഗം പ്രായോഗികമല്ലാത്തപ്പോൾ സബ്ഡൊമെയ്നിന് സോപാധിക ഫോർവേഡ് സാധുവായ ബദലാണ്, പക്ഷേ അത് റിസോൾവർ ക്രമീകരണമാണ്, പ്രസിദ്ധീകരിച്ച വസ്തുതയല്ല, അതിനാൽ ഓരോ റിസോൾവറിനും ഒരേ നിയമം വേണം.

ചെലവ് അപ്രത്യക്ഷമാകുന്നതിനുപകരം നീങ്ങുന്നു: മാതൃ സോണിന് ഇപ്പോഴും ഉടമ വേണം, പുതിയ സൈറ്റ് സൃഷ്ടിക്കുന്നത് ഇപ്പോൾ ഒന്നിനുപകരം രണ്ടിടത്ത് മാറ്റമാണ്.

ഓരോ റിസോൾവറും തിരഞ്ഞെടുപ്പ് പിന്തുടരട്ടെ

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

Pi-hole പ്രാദേശിക പരിഹാരം നൽകുന്നുവെങ്കിൽ, ഏത് റെക്കോർഡുകൾ അതിന്റെ ഉടമസ്ഥതയിലാണെന്നും ഏത് അന്വേഷണങ്ങൾ അത് ഫോർവേഡ് ചെയ്യുന്നുവെന്നും എഴുതിവയ്ക്കുക. വേറിട്ട് തിരുത്തിയ രണ്ട് Pi-hole പട്ടികകൾ ഇപ്പോഴും പകർപ്പെടുക്കുന്നില്ല. Pi-hole v6 ൽ ഇഷ്ടാനുസൃത dnsmasq വരികൾ TOML, CLI അല്ലെങ്കിൽ പരിസ്ഥിതി ചരങ്ങൾ പോലുള്ള ഹോസ്റ്റ് വശത്തെ ഓപ്ഷനുകളിലൂടെ സജ്ജീകരിക്കുന്നു, API വഴി വെളിപ്പെടുത്തുന്നില്ല; /etc/dnsmasq.d/ ഫയലുകൾ ലോഡ് ചെയ്യുന്നത് സ്വതേ ഓഫ് ആയ വേറിട്ട ഓപ്ഷനാണ്.

പിന്നീട് എല്ലായിടത്തും കാണേണ്ട ഒരു പേരുമായി ഇരുവശത്തുനിന്നും പരിശോധിക്കുക:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

SOA ഉത്തരം മഞ്ഞ റിസോൾവർ തന്നെ അധികാരമുള്ളതായി കരുതുന്നുണ്ടോ, സെക്കൻഡറിയോട് ചോദിക്കുന്നുണ്ടോ, അതോ വെറും ഫോർവേഡ് മാത്രമാണോ എന്ന് പറയുന്നു. ഇവ വ്യത്യസ്ത പരാജയ രീതികളുള്ള വ്യത്യസ്ത ഡിസൈനുകളാണ്, ഉത്തരം സാധാരണയായി നിങ്ങൾ യഥാർത്ഥത്തിൽ വിന്യസിച്ചത് ഏതെന്ന് തിരിച്ചറിയിക്കുന്നു.

മൂന്ന് സ്വീകാര്യതാ കേസുകളോടെ അവസാനിപ്പിക്കുക: ഓരോ സൈറ്റിൽ നിന്നും ഒരു പേര്, ഒരു മണിക്കൂറിനുള്ളിൽ മാറ്റിയ ഒരു റെക്കോർഡ്, സൈറ്റുകൾക്കിടയിലെ ലിങ്ക് ലഭ്യമല്ലായിരിക്കുക. ആദ്യത്തേത് മാത്രം പാസാകുന്ന ഡിസൈനിന് കടലാസിൽ പ്രസിദ്ധീകരണ പദ്ധതിയും ഉൽപാദനത്തിൽ പ്രാദേശിക ഓവർറൈഡും ഉണ്ട്.