निजी अवसंरचना / कोई आईडी आवश्यक नहींगोपनीयता सिद्धांत पढ़ें
KoalaVPS फ़ील्ड नोट्स

आपके उपकरणों के लिए एक रिज़ॉल्वर, खुला एम्प्लीफायर नहीं।

एक निजी DNS रिज़ॉल्वर आपको रिज़ॉल्यूशन और फ़िल्टरिंग पर नियंत्रण दे सकता है जब पहुँच जानबूझकर प्रतिबंधित हो।

भूमिका चुनें

Unbound जैसा पुनरावर्ती रिज़ॉल्वर और AdGuard Home जैसा फ़िल्टरिंग इंटरफ़ेस संबंधित लेकिन अलग समस्याओं का समाधान करते हैं। तय करें कि सेवा स्वयं पुनरावर्तन करती है या किसी अपस्ट्रीम को अग्रेषित करती है और फिर कौन सा पक्ष क्वेरी देखता है।

इसे निजी रखें

एक अप्रतिबंधित सार्वजनिक रिज़ॉल्वर का दुरुपयोग रिफ्लेक्शन हमलों के लिए किया जा सकता है। किसी निजी नेटवर्क से बाइंड करें या केवल अधिकृत स्रोतों को अनुमति दें, जिनमें IPv6 शामिल है। एन्क्रिप्टेड DNS का उपयोग करते समय, पहुँच को प्रमाणित करें या अन्यथा उचित रूप से प्रतिबंधित करें, बजाय यह मानने के कि HTTPS इसे निजी बना देता है।

लॉगिंग नीति निर्धारित करें

DNS क्वेरी संवेदनशील ब्राउज़िंग और एप्लिकेशन गतिविधि को उजागर कर सकती हैं। अनावश्यक प्रतिधारण अक्षम करें, रखे गए रिकॉर्ड की सुरक्षा करें और उपयोगकर्ताओं को दायरा समझाएँ। एन्क्रिप्टेड परिवहन एक पथ की रक्षा करता है; यह रिज़ॉल्वर को स्वयं क्वेरी देखने से नहीं रोकता।

एक से अधिक नाम का परीक्षण करें

जहाँ सक्षम हो वहाँ DNSSEC व्यवहार, IPv4 और IPv6 परिणाम, फ़िल्टरिंग अपवाद और अपस्ट्रीम विफल होने पर पुनर्प्राप्ति सत्यापित करें। जिस रिज़ॉल्वर की आप मरम्मत कर रहे हैं उस पर विशेष रूप से निर्भर किए बिना पहुँच ठीक करने का एक सुरक्षित तरीका रखें।

सिद्ध करें कि अजनबी इसे क्वेरी नहीं कर सकते

रिज़ॉल्वर को इच्छित इंटरफ़ेस से बाँधें, अनुमत क्लाइंट श्रेणियाँ परिभाषित करें और फ़ायरवॉल को प्रतिबंधित करें। पुनः आरंभ करने से पहले कॉन्फ़िगरेशन सत्यापित करें। किसी अधिकृत क्लाइंट से इसे क्वेरी करें, फिर विश्वसनीय नेटवर्क के बाहर से दोहराएँ: उस अनुरोध को अस्वीकार या टाइम आउट होना चाहिए। IPv6 की अलग से जाँच करें। जो रिज़ॉल्वर मनमानी इंटरनेट क्वेरी स्वीकार करता है वह दुरुपयोग का स्रोत बन सकता है।

  • परिवर्तन लागू करने से पहले कॉन्फ़िगरेशन वैलिडेटर चलाएं
  • एक अनुमत क्लाइंट और एक अस्वीकृत क्लाइंट का परीक्षण करें
  • वर्बोज़ क्वेरी डायग्नोस्टिक्स को अस्थायी रखें
unbound-checkconf

एन्क्रिप्टेड DNS दावों को सटीक रखें

DNS-over-HTTPS या DNS-over-TLS एक विशेष ट्रांसपोर्ट पथ को एन्क्रिप्ट करता है। रिज़ॉल्वर को अभी भी क्वेरी प्राप्त होती है, और एक फ़ॉरवर्डिंग रिज़ॉल्वर इसे किसी अन्य ऑपरेटर को पास कर सकता है। अपस्ट्रीम चयन और प्रतिधारण की समीक्षा करें। यदि आप एक एन्क्रिप्टेड रिज़ॉल्वर एंडपॉइंट उजागर करते हैं, तो उसकी पहुँच नीति को सामान्य DNS पोर्ट जितना ही सुविचारित बनाएँ।

पोर्ट खोलने से पहले रिज़ॉल्वर श्रृंखला चुनें

एक उपयोगी निजी डिज़ाइन है एक VPN क्लाइंट जो AdGuard Home से क्वेरी करता है, और AdGuard लूपबैक पर Unbound को अग्रेषित करता है। फिर Unbound रिकर्सन करता है; AdGuard फ़िल्टरिंग और एक प्रबंधन इंटरफ़ेस जोड़ता है। वैकल्पिक रूप से छोटे स्टैक के लिए केवल Unbound का उपयोग करें। प्रत्येक लिसनर को एक अलग पता/पोर्ट दें और अग्रेषण की दिशा बनाएं: Unbound को वापस AdGuard पर भेजने से लूप बनता है। कुछ भी प्रकाशित करने से पहले तय करें कि कौन से निजी क्लाइंट इस सेवा का उपयोग कर सकते हैं।

  • सार्वजनिक इनबाउंड TCP और UDP 53 को बंद रखें, जब तक कि कोई विशिष्ट अधिकृत-क्लाइंट नीति न हो।
  • फ़िल्टरिंग इंटरफ़ेस और DNS लिसनर को अलग-अलग एक्सेस नियम दें।
  • इंस्टॉलेशन से पहले पोर्ट स्वामित्व जाँचें; कोई मौजूदा सिस्टम रिज़ॉल्वर पहले से ही इच्छित पता बाइंड कर सकता है।

एक लूपबैक Unbound प्रारंभिक बिंदु

जिस सिस्टम पर Unbound पहले से इंस्टॉल है, वहाँ निम्नलिखित अंश एक ऐसा बैकएंड दर्शाता है जो केवल होस्ट पर पहुँच योग्य है। इसे पैकेज सेटिंग्स या ट्रस्ट-एंकर प्रबंधन को अधिलेखित करने के बजाय डिस्ट्रिब्यूशन कॉन्फ़िगरेशन के साथ एकीकृत करें। उच्च पोर्ट किसी अन्य DNS फ्रंटएंड को पोर्ट 53 का उपयोग करने देता है। पूरी प्रभावी फ़ाइल को सत्यापित करें, फिर इंस्टॉल किए गए सेवा प्रबंधक के माध्यम से पुनः लोड करें। एक रिमोट क्लाइंट को अलग से नियंत्रित टनल या फ्रंटएंड की आवश्यकता होती है; यह अंश जानबूझकर कोई सार्वजनिक रिज़ॉल्वर नहीं बनाता।

server:
  interface: 127.0.0.1
  port: 5335
  access-control: 127.0.0.0/8 allow
  access-control: 0.0.0.0/0 refuse
  access-control: ::0/0 refuse

# Validate the complete installed configuration:
unbound-checkconf

दो नेटवर्क से स्वीकृति चेकलिस्ट चलाएँ

पहले बैकएंड को स्थानीय रूप से क्वेरी करें, फिर सामान्य क्लाइंट पथ से। सामान्य A/AAAA रिकॉर्ड, जानबूझकर बनाया गया गैर-मौजूद नाम और प्रलेखित परीक्षण डोमेन का उपयोग करके DNSSEC सत्यापन जाँचें। अनुमत सबनेट के बाहर की मशीन से दोहराएँ: उसे रिकर्सन नहीं मिलना चाहिए। जाँचें कि क्या ब्राउज़र अपना स्वयं का एन्क्रिप्टेड रिज़ॉल्वर उपयोग करके कॉन्फ़िगर किए गए डिवाइस DNS को बायपास करता है। परिवर्तन के दौरान एक अस्थायी स्वतंत्र रिज़ॉल्वर उपलब्ध रखें ताकि DNS गलती आपका प्रशासन मार्ग न हटा दे।

  • स्थानीय निदान: dig @127.0.0.1 -p 5335 example.org A
  • UDP और TCP दोनों की पहुँच, साथ ही IPv6 लिसनर का निरीक्षण करें।
  • फ़िल्टरिंग अपवादों की पुष्टि करें और केवल वास्तव में आवश्यक डायग्नोस्टिक्स रिकॉर्ड करें।

टाइमआउट, लूप और सत्यापन विफलताओं का निदान करें

काम कर रहे स्थानीय बैकएंड के साथ फ्रंटएंड टाइमआउट फ्रंटएंड पते, फ़ायरवॉल या फ़ॉरवर्डिंग लक्ष्य की ओर संकेत करता है। बार-बार स्व-निर्देशित क्वेरीज़ लूप का संकेत देती हैं। व्यापक DNSSEC विफलताओं में गलत सिस्टम समय या ट्रस्ट-एंकर रखरखाव शामिल हो सकता है; सत्यापन अक्षम छोड़ने के बजाय कारण ठीक करें। यदि केवल बड़े उत्तर विफल होते हैं, तो TCP फ़ॉलबैक और नेटवर्क पथ की जाँच करें। क्वेरी लॉगिंग अस्थायी रखें, और रिज़ॉल्वर को हर डिवाइस के लिए निर्भरता बनाने से पहले पुनः आरंभ और कॉन्फ़िगरेशन पुनर्स्थापन का परीक्षण करें।

अपना इंफ्रास्ट्रक्चर कॉन्फ़िगर करें

नियंत्रण लें।
अपनी शर्तों पर तैनात करें।

कोई पहचान कागज़ी कार्रवाई नहीं। पूर्ण प्रशासक पहुँच। क्रिप्टो-नेटिव बिलिंग।