VPN மீது BIND: நிபந்தனை முன்னனுப்பல் அல்லது stub மண்டலமா?
VPN வழியாக ஒரு தனிப்பட்ட மண்டலத்தைத் தீர்க்கும் மூன்று வழிகள், ஒவ்வொன்றும் எப்போது பொருத்தம்: forward, stub அல்லது secondary, மேலும் முடிவெடுக்கும் மூல முகவரி சரிபார்ப்பு.
உங்கள் அலுவலக ரிசால்வர் ஒரு நிறுவன பெயர்வெளியைத் தவிர அனைத்திற்கும் பதிலளிக்கிறது, அதை அறிந்த நிறுவன DNS சர்வர் VPN பின்னால் உள்ளது. BIND அந்த ஒரே மண்டலத்தை மூன்று வெவ்வேறு வழிகளில் upstream-க்கு ஒப்படைக்கலாம், அவை வெவ்வேறு வகையில் தோல்வியடைகின்றன. நிபந்தனை முன்னனுப்பல் மிகச் சிறிய உறுதிமொழி, stub மண்டலம் பிரதிநிதித்துவ தரவை வைத்திருக்கும், secondary முழு நகலை வைத்திருக்கும். நீங்கள் முதலில் கண்ட snippet-ஐ வைத்து அல்ல, upstream எதை அனுமதிக்கும், உங்கள் ரிசால்வர் எதை வைத்திருக்க வேண்டும் என்பதன் அடிப்படையில் தேர்ந்தெடுக்கவும்.
ஒரு பெயர்வெளிக்கு மூன்று ஏற்பாடுகள்
| 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 உடன், அணுக முடியாத upstream இந்த மண்டலத்திற்கு மீள்செயல் தீர்வுக்குத் திரும்புவதற்குப் பதிலாக SERVFAIL தருகிறது. தனிப்பட்ட பெயர்வெளிக்கு வழக்கமாக இதுவே தேவை, ஏனெனில் திரும்புவது தனிப்பட்ட பெயர்களை பொது ரிசால்வருக்கு அனுப்பி இணையத்திலிருந்து பயனற்ற பதிலைக் கொண்டுவரும். BIND குறிப்பு இரு கொள்கைகளையும் ஆவணப்படுத்துகிறது, வித்தியாசம் snippet குறிப்பதை விட முக்கியம். அதே பெயருக்கு ஏற்கனவே உள்ள மண்டலத்தை மாற்றுவதற்குப் பதிலாக மண்டலத்தை ஏற்கனவே உள்ள கட்டமைப்பில் இணைக்கவும்.
stub அல்லது secondary: பிரதிநிதித்துவம் முக்கியமானபோது
stub மண்டலம் நிறுவன சர்வரிடம் மண்டலத்தின் NS பதிவுகளைக் கேட்டு பின்னர் அதிகாரம் பெற்ற சர்வர்களை நேரடியாகக் கேட்கிறது. upstream பகுதி பெரியதாகவோ பிரிக்கப்பட்டதாகவோ இருக்கும்போது, எல்லாவற்றையும் ஒரு முகவரியில் ஆணியிடுவதற்குப் பதிலாக உங்கள் ரிசால்வர் பிரதிநிதித்துவத்தைப் பின்பற்ற வேண்டும் என விரும்பினால் இதைத் தேர்ந்தெடுக்கவும். விலை என்பது 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 உள்ளூர் தரவிலிருந்து பதிலளித்து upstream தடையைத் தாங்குகிறது, அதனால்தான் பரிமாற்றச் சார்பை ஏற்கலாம். இதன் பொருள் உங்கள் ரிசால்வர் இப்போது தனக்குச் சொந்தமில்லாத மண்டலத்தின் நகலை வைத்திருக்கிறது, எனவே கோப்பு பாதை, முதன்மை சர்வரில் பரிமாற்ற 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 மண்டலம் எப்படி நடந்துகொண்டாலும் stub மண்டலம் செயல்பட முடியாது.
சுரங்கப்பாதையை அல்ல, பதிலைச் சரிபார்க்கவும்
நீங்கள் ஒருபோதும் கேட்காத பெயருக்கு அலுவலக ரிசால்வர் வழியாக வினவி, பதிலின் authority பகுதியைப் பார்த்து அது நிறுவன மண்டலத்திலிருந்து வந்ததா என்பதைச் சரிபார்க்கவும். கேஷில் உள்ள பதில் தற்போதைய பாதையைப் பற்றி எதையும் நிரூபிக்காது, upstream-க்கு நேரடியாக வெற்றிகரமான வினவல் உங்கள் ரிசால்வர் அந்த மண்டலத்தைத் தேர்ந்தெடுத்தது என்பதை நிரூபிக்காது. அதே வினவலை TCP வழியாக மீண்டும் செய்து பாதை துண்டிப்பைத் தாங்குகிறது என்பதை உறுதிசெய்யவும்.
கிளையண்ட்களை அலுவலக ரிசால்வர் நோக்கி வைத்திருங்கள், மேலும் DNSSEC சரிபார்ப்பை இயக்கத்தில் வைத்திருங்கள். சுயாதீன குறியாக்க ரிசால்வருடன் கட்டமைக்கப்பட்ட உலாவி இந்த ஏற்பாட்டை முழுவதுமாகத் தவிர்க்கிறது, எதிர்பாராத பதில் சரியாகத் தெரிவதற்காகச் சரிபார்ப்பை அணைப்பது தெரியும் தோல்வியைத் தெரியாத தோல்வியுடன் மாற்றுகிறது.
மூன்றில் எந்த வகையைத் தேர்ந்தெடுத்தீர்கள், ஏன் என்பதை எழுதுங்கள். மண்டலம் தோல்வியடைவதைப் பார்க்கும் அடுத்த நபருக்கு கட்டமைப்பு கோப்பை விட அந்த வாக்கியம் அதிகம் தேவைப்படும்.