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 पडताळणी सुरू ठेवा. स्वतंत्र एन्क्रिप्टेड रिझॉल्व्हरसह कॉन्फिगर केलेला ब्राउझर ही व्यवस्था पूर्णपणे टाळतो, आणि अनपेक्षित उत्तर बरोबर दिसावे म्हणून पडताळणी बंद करणे दिसणारे अपयश न दिसणाऱ्या अपयशाशी बदलते.
तीनपैकी कोणता प्रकार निवडला आणि का, ते लिहून ठेवा. झोन अपयशी होताना पाहणाऱ्या पुढच्या व्यक्तीला कॉन्फिग फाइलपेक्षा त्या वाक्याची अधिक गरज असेल.