VPN पर BIND: कंडीशनल फ़ॉरवर्ड या स्टब ज़ोन?
VPN के ज़रिए एक निजी ज़ोन हल करने के तीन तरीके और हर एक कब उपयुक्त है: फ़ॉरवर्ड, स्टब या सेकंडरी, साथ में स्रोत-पता जाँच जो फ़ैसला करती है।
आपका ऑफ़िस रिज़ॉल्वर एक कॉर्पोरेट नेमस्पेस को छोड़कर सबका जवाब देता है, और उसे जानने वाला कॉर्पोरेट DNS सर्वर VPN के पीछे है। BIND उस एक ज़ोन को अपस्ट्रीम को तीन अलग तरीकों से सौंप सकता है, और वे अलग-अलग तरीके से विफल होते हैं। कंडीशनल फ़ॉरवर्ड सबसे छोटी प्रतिबद्धता है, स्टब ज़ोन डेलिगेशन डेटा रखता है, और सेकंडरी पूरी प्रतिलिपि रखता है। अपस्ट्रीम क्या अनुमति देगा और आप अपने रिज़ॉल्वर में क्या रखना चाहते हैं, उसके आधार पर चुनें, न कि इस आधार पर कि आपको पहले कौन-सा स्निपेट मिला।
एक नेमस्पेस के लिए तीन व्यवस्थाएँ
| 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 संदर्भ दोनों नीतियों का दस्तावेज़ीकरण करता है, और अंतर स्निपेट के संकेत से अधिक मायने रखता है। ज़ोन को मौजूदा कॉन्फ़िगरेशन में मिलाएँ, उस ज़ोन को बदलने के बजाय जो उसी नाम के लिए पहले से मौजूद है।
स्टब या सेकंडरी: जब डेलिगेशन मायने रखता है
स्टब ज़ोन कॉर्पोरेट सर्वर से ज़ोन के 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";
};सेकंडरी स्थानीय डेटा से जवाब देता है और अपस्ट्रीम आउटेज सह लेता है, और यही ट्रांसफ़र निर्भरता स्वीकार करने का कारण है। इसका मतलब यह भी है कि आपका रिज़ॉल्वर अब ऐसे ज़ोन की प्रतिलिपि रखता है जो उसका नहीं है, इसलिए फ़ाइल पथ, प्राइमरी पर ट्रांसफ़र 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 क्वेरी विफल हो, तो फ़ॉरवर्ड ज़ोन जैसा भी व्यवहार करे, स्टब ज़ोन काम नहीं कर सकता।
जवाब सत्यापित करें, टनल नहीं
ऑफ़िस रिज़ॉल्वर से ऐसे नाम की क्वेरी करें जो आपने कभी नहीं माँगा, और जवाब के authority भाग को देखें कि वह कॉर्पोरेट ज़ोन से आया है या नहीं। कैश में रखा जवाब मौजूदा पथ के बारे में कुछ साबित नहीं करता, और अपस्ट्रीम से सीधी सफल क्वेरी यह साबित नहीं करती कि आपके रिज़ॉल्वर ने वह ज़ोन चुना। वही क्वेरी TCP पर दोहराएँ ताकि पुष्टि हो कि पथ कटाव सह लेता है।
क्लाइंट को ऑफ़िस रिज़ॉल्वर की ओर रखें, और DNSSEC सत्यापन चालू रखें। स्वतंत्र एन्क्रिप्टेड रिज़ॉल्वर के साथ कॉन्फ़िगर किया गया ब्राउज़र इस व्यवस्था को पूरी तरह बायपास करता है, और अप्रत्याशित जवाब को सही दिखाने के लिए सत्यापन बंद करना दिखने वाली विफलता को अदृश्य विफलता से बदल देता है।
लिखें कि आपने तीन में से कौन-सा प्रकार चुना और क्यों। अगली बार ज़ोन को विफल देखने वाले व्यक्ति को कॉन्फ़िग फ़ाइल से ज़्यादा उस वाक्य की ज़रूरत होगी।