VPN-ൽ BIND: സോപാധിക ഫോർവേഡോ സ്റ്റബ് സോണോ?
VPN വഴി ഒരു സ്വകാര്യ സോൺ പരിഹരിക്കാനുള്ള മൂന്ന് വഴികളും ഓരോന്നും എപ്പോൾ അനുയോജ്യമെന്നും: forward, stub അല്ലെങ്കിൽ secondary, കൂടെ തീരുമാനിക്കുന്ന ഉറവിട വിലാസ പരിശോധനയും.
നിങ്ങളുടെ ഓഫീസ് റിസോൾവർ ഒരു കോർപ്പറേറ്റ് നെയിംസ്പേസ് ഒഴികെ എല്ലാറ്റിനും ഉത്തരം നൽകുന്നു, അത് അറിയുന്ന കോർപ്പറേറ്റ് DNS സർവർ VPN-ന് പിന്നിലാണ്. BIND ആ ഒരു സോൺ മൂന്ന് വ്യത്യസ്ത രീതികളിൽ അപ്സ്ട്രീമിന് നൽകാം, അവ വ്യത്യസ്ത രീതികളിൽ പരാജയപ്പെടുന്നു. സോപാധിക ഫോർവേഡ് ഏറ്റവും ചെറിയ പ്രതിബദ്ധതയാണ്, സ്റ്റബ് സോൺ ഡെലിഗേഷൻ ഡാറ്റ സൂക്ഷിക്കുന്നു, secondary പൂർണ്ണ പകർപ്പ് സൂക്ഷിക്കുന്നു. ആദ്യം കണ്ട സ്നിപ്പെറ്റ് അനുസരിച്ചല്ല, അപ്സ്ട്രീം എന്ത് അനുവദിക്കും, നിങ്ങളുടെ റിസോൾവർ എന്ത് സൂക്ഷിക്കണം എന്നിവയുടെ അടിസ്ഥാനത്തിൽ തിരഞ്ഞെടുക്കുക.
ഒരു നെയിംസ്പേസിനുള്ള മൂന്ന് ക്രമീകരണങ്ങൾ
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
സോപാധിക ഫോർവേഡ്: ഏറ്റവും ചെറിയ പ്രതിബദ്ധത
ഓഫീസ് റിസോൾവർ 192.168.10.53-ൽ, കോർപ്പറേറ്റ് സർവർ 10.40.0.53-ൽ, അനുവദിച്ച ടണലിലൂടെ എത്താമെന്ന് കരുതുക. പ്രഖ്യാപനം മൂന്ന് വരികളാണ്, രസകരമായത് forward only ആണ്, കാരണം അത് പാതയല്ല, പരാജയ സ്വഭാവമാണ് മാറ്റുന്നത്.
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};forward only ഉള്ളപ്പോൾ എത്തിച്ചേരാനാകാത്ത അപ്സ്ട്രീം ഈ സോണിന് ആവർത്തന പരിഹാരത്തിലേക്ക് മടങ്ങുന്നതിന് പകരം SERVFAIL നൽകുന്നു. സ്വകാര്യ നെയിംസ്പേസിന് സാധാരണ ഇതാണ് വേണ്ടത്, കാരണം മടങ്ങിപ്പോകൽ സ്വകാര്യ നാമങ്ങളെ പൊതു റിസോൾവറിലേക്ക് അയച്ച് ഇന്റർനെറ്റിൽ നിന്ന് ഉപയോഗശൂന്യമായ ഉത്തരം കൊണ്ടുവരും. BIND റഫറൻസ് രണ്ട് നയങ്ങളും രേഖപ്പെടുത്തുന്നു, വ്യത്യാസം സ്നിപ്പെറ്റ് സൂചിപ്പിക്കുന്നതിലും പ്രധാനമാണ്. അതേ പേരിന് ഇതിനകം നിലവിലുള്ള സോൺ മാറ്റിസ്ഥാപിക്കുന്നതിന് പകരം സോൺ നിലവിലുള്ള കോൺഫിഗറേഷനിൽ ലയിപ്പിക്കുക.
സ്റ്റബ് അല്ലെങ്കിൽ secondary: ഡെലിഗേഷൻ പ്രധാനമാകുമ്പോൾ
സ്റ്റബ് സോൺ കോർപ്പറേറ്റ് സർവറിനോട് സോണിന്റെ NS റെക്കോർഡുകൾ ചോദിക്കുന്നു, തുടർന്ന് അധികാരമുള്ള സർവറുകളോട് നേരിട്ട് ചോദിക്കുന്നു. അപ്സ്ട്രീം മേഖല വലുതോ വിഭജിതമോ ആകുമ്പോൾ, എല്ലാം ഒരു വിലാസത്തിൽ പിന്നിയിടുന്നതിന് പകരം നിങ്ങളുടെ റിസോൾവർ ഡെലിഗേഷൻ പിന്തുടരണമെന്ന് ആഗ്രഹിക്കുമ്പോൾ ഇത് തിരഞ്ഞെടുക്കുക. വില NS ഡാറ്റ കാലികമായിരിക്കുന്നതിലും, പട്ടികയിലുള്ള ഓരോ നെയിംസർവറും നിങ്ങളുടെ റിസോൾവറിന്റെ ഉറവിട വിലാസത്തിൽ നിന്ന് എത്താവുന്നതിലുമുള്ള ആശ്രിതത്വമാണ്.
zone "corp.example" {
type stub;
masters { 10.40.0.53; };
};
zone "corp.example" {
type secondary;
primaries { 10.40.0.53; };
file "corp.example.db";
};secondary പ്രാദേശിക ഡാറ്റയിൽ നിന്ന് ഉത്തരം നൽകുന്നു, അപ്സ്ട്രീം തകരാറിനെ അതിജീവിക്കുന്നു, അതാണ് കൈമാറ്റ ആശ്രിതത്വം സ്വീകരിക്കാനുള്ള കാരണം. ഇതിനർത്ഥം നിങ്ങളുടെ റിസോൾവർ ഇപ്പോൾ തന്റേതല്ലാത്ത ഒരു സോണിന്റെ പകർപ്പ് സൂക്ഷിക്കുന്നു എന്നാണ്, അതിനാൽ ഫയൽ പാത, പ്രൈമറിയിലെ കൈമാറ്റ ACL, പുതുക്കൽ ടൈമറുകൾ എന്നിവയെല്ലാം നിങ്ങളുടെ പ്രവർത്തന ഉപരിതലത്തിന്റെ ഭാഗമാകുന്നു.
അവയ്ക്കിടയിൽ തീരുമാനിക്കുന്ന പരിശോധന
BIND സ്വന്തം പുറത്തേക്കുള്ള ക്വറി സ്വയം സൃഷ്ടിക്കുന്നു, അതിനാൽ ചോദ്യം ലാപ്ടോപ്പിന് 10.40.0.53-ൽ എത്താമോ എന്നല്ല, റിസോൾവർ ഹോസ്റ്റിന് കോർപ്പറേറ്റ് സർവർ കാണുന്ന ഉറവിട വിലാസത്തിൽ നിന്ന് എത്താമോ എന്നാണ്. ആദ്യം കെർണലിനോട്, പിന്നെ സർവറിനോട്, ആ ക്രമത്തിൽ ചോദിക്കുക.
ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.exampleപാതയിൽ UDP-യും TCP-യും അനുവദിക്കുക: മുറിഞ്ഞ ഉത്തരം TCP-യെ നിർബന്ധിക്കുന്നു, UDP മാത്രം അനുവദിക്കുന്ന നയം പാക്കറ്റ് നഷ്ടം പോലെ തോന്നുന്ന ഇടവിട്ട പരാജയങ്ങൾ ഉണ്ടാക്കുന്നു. കോർപ്പറേറ്റ് വശത്തിന് നിങ്ങളുടെ റിസോൾവറിന്റെ ഉറവിടത്തിനുള്ള സ്വീകരണ നിയമവും അങ്ങോട്ടുള്ള മടക്ക പാതയും വേണം; ആ ഉറവിടം റിസോൾവറിന്റെ റൂട്ട് ചെയ്ത വിലാസമോ വ്യക്തമായി വിവർത്തനം ചെയ്ത ഒന്നോ ആകാം, ക്ലയന്റ് പൂളിന്റെ വിലാസം അപൂർവമാണ്. NS ക്വറി പരാജയപ്പെട്ടാൽ, forward സോൺ എങ്ങനെ പെരുമാറിയാലും സ്റ്റബ് സോണിന് പ്രവർത്തിക്കാനാകില്ല.
ടണൽ അല്ല, ഉത്തരം പരിശോധിക്കുക
നിങ്ങൾ ഒരിക്കലും ആവശ്യപ്പെടാത്ത ഒരു പേരിനായി ഓഫീസ് റിസോൾവർ വഴി ക്വറി ചെയ്ത്, ഉത്തരത്തിന്റെ authority ഭാഗം നോക്കി അത് കോർപ്പറേറ്റ് സോണിൽ നിന്നാണോ എന്ന് പരിശോധിക്കുക. കാഷെ ചെയ്ത ഉത്തരം നിലവിലെ പാതയെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, അപ്സ്ട്രീമിലേക്കുള്ള നേരിട്ടുള്ള വിജയകരമായ ക്വറി നിങ്ങളുടെ റിസോൾവർ ആ സോൺ തിരഞ്ഞെടുത്തു എന്ന് തെളിയിക്കുന്നില്ല. അതേ ക്വറി TCP-യിൽ ആവർത്തിച്ച് പാത മുറിവിനെ അതിജീവിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക.
ക്ലയന്റുകളെ ഓഫീസ് റിസോൾവറിലേക്ക് തിരിച്ചുനിർത്തുക, DNSSEC പരിശോധന ഓണായി സൂക്ഷിക്കുക. സ്വതന്ത്ര എൻക്രിപ്റ്റ് ചെയ്ത റിസോൾവർ ഉപയോഗിച്ച് ക്രമീകരിച്ച ബ്രൗസർ ഈ ക്രമീകരണത്തെ പൂർണ്ണമായി ഒഴിവാക്കുന്നു, അപ്രതീക്ഷിത ഉത്തരം ശരിയാണെന്ന് തോന്നാൻ പരിശോധന ഓഫ് ചെയ്യുന്നത് കാണാവുന്ന പരാജയത്തെ കാണാനാകാത്ത ഒന്നുമായി കൈമാറുന്നു.
മൂന്നിൽ ഏത് തരം തിരഞ്ഞെടുത്തു, എന്തുകൊണ്ട് എന്ന് എഴുതിവയ്ക്കുക. സോൺ പരാജയപ്പെടുന്നത് കാണുന്ന അടുത്ത വ്യക്തിക്ക് കോൺഫിഗ് ഫയലിനെക്കാൾ ആ വാക്യം ആവശ്യമാകും.