सार्वजनिक DNS में निजी आईपी पता

Question

हमारे पास फ़ायरवॉल के पीछे एक SMTP केवल मेल सर्वर है, जिसमें मेल का सार्वजनिक A रिकॉर्ड होगा। । इस मेल सर्वर तक पहुँचने का एकमात्र तरीका उसी फ़ायरवॉल के पीछे किसी अन्य सर्वर से है। हम अपना निजी DNS सर्वर नहीं चलाते हैं।

क्या एक सार्वजनिक DNS सर्वर में A रिकॉर्ड के रूप में निजी IP पते का उपयोग करना एक अच्छा विचार है - या इन सर्वर रिकॉर्ड को प्रत्येक सर्वर स्थानीय होस्ट फ़ाइल में रखना सबसे अच्छा है?

Answer 1

कुछ लोग कहेंगे कि कोई सार्वजनिक डीएनएस रिकॉर्ड कभी भी निजी आईपी पते का खुलासा नहीं करना चाहिए .... इस सोच के साथ कि आप संभावित हमलावरों को कुछ जानकारी देने के लिए एक पैर दे रहे हैं जो निजी सिस्टम का शोषण करने के लिए आवश्यक हो सकता है।

व्यक्तिगत रूप से, मुझे लगता है कि ओफ़्यूसकेशन सुरक्षा का एक खराब रूप है, खासकर जब हम आईपी पते के बारे में बात कर रहे हैं क्योंकि सामान्य तौर पर वे वैसे भी अनुमान लगाने में आसान होते हैं, इसलिए मैं इसे एक यथार्थवादी सुरक्षा समझौते के रूप में नहीं देखता हूं।

यहां बड़ा विचार यह सुनिश्चित कर रहा है कि आपके सार्वजनिक उपयोगकर्ता आपके होस्ट किए गए एप्लिकेशन की सामान्य सार्वजनिक सेवाओं के हिस्से के रूप में इस DNS रिकॉर्ड को पिक नहीं करते हैं। यानी: बाहरी डीएनएस लुकअप किसी भी तरह एक पते पर हल करना शुरू कर देता है जो उन्हें नहीं मिल सकता है।

इसके अलावा, मुझे कोई मूलभूत कारण दिखाई नहीं देता है कि निजी पते को सार्वजनिक स्थान पर रिकॉर्ड करना एक समस्या है .... खासकर जब आपके पास उन्हें होस्ट करने के लिए कोई वैकल्पिक DNS सर्वर नहीं है।

यदि आप इस रिकॉर्ड को सार्वजनिक DNS स्थान में रखने का निर्णय लेते हैं, तो आप सभी "निजी" रिकॉर्ड रखने के लिए एक ही सर्वर पर एक अलग क्षेत्र बनाने पर विचार कर सकते हैं। यह स्पष्ट कर देगा कि वे निजी होने का इरादा रखते हैं .... हालांकि सिर्फ एक ए रिकॉर्ड के लिए, मैं शायद परेशान नहीं करूंगा।

Comments

+1, कारण के लिए

— वोमल

यह इस विचार के साथ एक समस्या का एक अच्छा उदाहरण है: merit.edu/mail.archives/nanog/2006-09/msg00364.html

— सुपुरी

क्या यह सलाह तब भी लागू होती है जब आपके पास सार्वजनिक आईपी पतों के साथ संवेदनशील सर्वर होते हैं, लेकिन एक फ़ायरवॉल तक पहुँच को रोकना? यदि सार्वजनिक IP पते के लिए सार्वजनिक DNS बुनियादी ढांचे का एक रोडमैप देता है, तो क्या यह किसी हमलावर के लिए कुछ उपयोग नहीं है? मेजबान पहचान?

— केनी

@ केनी हां, सिद्धांत में इसका कुछ उपयोग है, लेकिन यह ऐसी जानकारी है जिसे प्राप्त करना कठिन नहीं है क्योंकि सार्वजनिक आईपी पते की सीमा वैसे भी आसानी से खोजी जा सकती है। मैंने उत्तर में इस तरह का संबोधन किया और उस धारणा को जोड़ते हुए मैंने तर्क दिया कि यदि आप आईपी पते या होस्टनाम को किसी भी प्रकार की सामग्री की रक्षा पंक्ति के रूप में छिपाने पर निर्भर हैं, तो आपको पहले से ही बहुत बड़ी समस्याएं हैं।

— टॉल जेफ

@ केनी अपनी बात के लिए, यह निश्चित रूप से जानकारी की मात्रा को कम करने के लिए वांछनीय है जो सार्वजनिक रूप से खोज योग्य है और आप किसी ऐसी चीज का खुलासा नहीं करना चाहते हैं जिसकी आपको कम से कम अच्छी लागत / लाभ व्यापार की जरूरत नहीं थी या नहीं थी- विचार करने के लिए शामिल किया गया। वहां कोई तर्क नहीं। उस के अलावा, मेरी बात का मूल (और मुझे लगता है कि हम सहमत हैं) बस इतना था कि आपत्ति करना सुरक्षा का एक खराब रूप है और यह कि कोई पूर्ण अच्छा / बुरा नहीं है, लेकिन केवल लागत / लाभ व्यापार-बंद होने का एक निरंतरता होना आपके जोखिम सहिष्णुता, आदि के आधार पर एक केस-दर-मामला आधार पर माना जाता है

— जेफ

Answer 2

मैंने कुछ समय पहले NANOG सूची पर इस विषय पर एक लंबी चर्चा की थी। हालांकि मैंने हमेशा सोचा था कि यह एक बुरा विचार था, पता चलता है कि यह व्यवहार में ऐसा बुरा विचार नहीं है। ज्यादातर कठिनाइयाँ rDNS लुकअप से आती हैं (जो कि निजी पते के लिए बस बाहरी दुनिया में काम नहीं करते हैं), और जब आप किसी वीपीएन से अधिक पते पर पहुँच प्रदान कर रहे हों या इसी तरह यह सुनिश्चित करना महत्वपूर्ण हो कि वीपीएन क्लाइंट ठीक से सुरक्षित हैं। वीपीएन डाउन होने पर "लीक" ट्रैफ़िक।

मेरा कहना है कि इसे कर ही दो. अगर किसी हमलावर को आंतरिक पतों पर नामों को हल करने में सक्षम होने से कुछ भी सार्थक मिल सकता है, तो आपको बड़ी सुरक्षा समस्याएं हैं।

Comments

+1, इस प्रश्न के सभी FUD प्रतिक्रियाओं में पवित्रता की आवाज़ बनने के लिए धन्यवाद। "सिक्योरिटी रिस्क" मेरे निचले पृष्ठीय क्षेत्रों, और राउटिंग समस्याओं और DNS मुद्दों को एक घुटने के झटके में देखते हुए "ऐसा नहीं करते" प्रतिक्रिया सिर्फ मुझे सभी जगह नेटवर्क चलाने वाले लोगों की क्षमता के बारे में आश्चर्यचकित करती है।

— मिहाई लिम्बायसन

सुधार: कि "रूटिंग समस्याओं और DNS मुद्दों और प्रमाणीकरण / पहचान के मुद्दों को धराशायी देखकर" बनाएं ।

— मिहाई लिम्बायसन

Answer 3

आम तौर पर सार्वजनिक DNS में RFC1918 पतों को शुरू करने से भविष्य में कुछ बिंदु पर, वास्तविक समस्या नहीं होने पर भ्रम पैदा होगा। अपने फ़ायरवॉल के पीछे RFC1918 पतों का उपयोग करने के लिए IP, होस्ट रिकॉर्ड या अपने ज़ोन का एक निजी DNS दृश्य का उपयोग करें, लेकिन उन्हें सार्वजनिक दृश्य में शामिल न करें।

अन्य सबमिट की गई प्रतिक्रिया के आधार पर अपनी प्रतिक्रिया स्पष्ट करने के लिए, मुझे लगता है कि सार्वजनिक DNS में RFC1918 पतों को पेश करना एक फ़ॉक्स पेस है, सुरक्षा मुद्दा नहीं। अगर कोई मुझे किसी मुद्दे को शूट करने के लिए परेशान करता है और मैं उनके DNS में RFC1918 पतों को ठोकर मारता हूं, तो मैं वास्तव में धीरे-धीरे बात करना शुरू करता हूं और उनसे पूछता हूं कि क्या उन्होंने हाल ही में रिबूट किया है। हो सकता है कि यह मेरी तरफ से झांसा दे, मुझे नहीं पता। लेकिन जैसा मैंने कहा, यह कोई आवश्यक बात नहीं है और यह किसी समय पर भ्रम और गलतफहमी (मानव, कंप्यूटर नहीं) पैदा करने की संभावना है। यह जोखिम क्यों है?

Comments

वास्तविक समस्याएँ क्या हैं? किन तरीकों से लोग भ्रमित होंगे?

— वोमबल

तो यह है ... विनम्र ... सार्वजनिक DNS में 1918 पते नहीं डालें? मैंने बहुत सारी समस्याओं को मारा है जो "छिपी हुई" और "विभाजित क्षितिज" DNS ज़ोन हैं, लेकिन सार्वजनिक DNS में निजी आईपी के कारण लगभग इतने सारे नहीं हैं। मैं अभी समस्या नहीं देख रहा हूँ।

— Womble

@womble, कंप्यूटर भ्रमित हो सकते हैं यदि किसी कारण से वे आपके नेटवर्क के बाहर उस होस्ट से कनेक्ट करने का प्रयास करते हैं और एसएमटीपी सर्वर प्राप्त करने के बजाय वे उम्मीद करते हैं कि वे उस आईपी पते पर उस आईपी पते पर रह रहे हैं जहां वे वर्तमान में जुड़े हैं। यह भी हो सकता है कि रिमोट पर लैपटॉप का उपयोग करने वाला आपका कोई कर्मचारी उपयोगकर्ता के नाम और पासवर्ड को किसी अन्य व्यक्ति के नेटवर्क पर सादे-पाठ में

— बताना शुरू

आपके जवाब के साथ मुझे जो समस्या है, वह यह है कि आप समस्याओं के प्रति सहमत हैं, लेकिन कोई भी विवरण प्रदान नहीं करते हैं। यदि ऐसा नहीं करने के कारण हैं, तो मैं उनके बारे में जानना चाहता हूं, इसलिए मैं इस विषय पर पूरी तरह से निर्णय ले सकता हूं।

— वोमबल

@Zoredache: कोई ऐसे नाम का समाधान क्यों कर रहा है, जिसकी पहुंच उनके पास नहीं है? डीएनएस केवल जगह आप निजी पते, वैसे भी मिल सकता है नहीं है - एचटीएमएल उदाहरण ... के लिए, आईपी शाब्दिक उपयोग कर सकते हैं

— Womble

Answer 4

नहीं, अपने निजी आईपी पते सार्वजनिक डीएनएस में न डालें।

सबसे पहले, यह जानकारी लीक करता है, हालांकि यह एक अपेक्षाकृत छोटी समस्या है।

यदि आपका एमएक्स रिकॉर्ड उस विशेष मेजबान प्रविष्टि को इंगित करता है तो इससे भी बदतर समस्या यह है कि जो कोई भी इसे मेल भेजने की कोशिश करता है, उसे मेल डिलीवरी टाइमआउट सबसे अच्छा मिलेगा।

प्रेषक के मेल सॉफ़्टवेयर के आधार पर उन्हें बाउंस मिल सकता है।

इससे भी बदतर, यदि आप RFC1918 एड्रेस स्पेस (जो आपको अपने नेटवर्क के अंदर चाहिए) का उपयोग कर रहे हैं, और प्रेषक भी है, तो हर मौका है कि वे मेल करके अपने नेटवर्क को वितरित करने का प्रयास करेंगे।

उदाहरण के लिए:

• नेटवर्क में आंतरिक मेल सर्वर है, लेकिन कोई विभाजन DNS नहीं है
• प्रशासन इसलिए DNS में सार्वजनिक और आंतरिक दोनों IP पते डालता है
• और एमएक्स रिकॉर्ड दोनों को इंगित करते हैं:

---

 $ORIGIN example.com
 @        IN   MX    mail.example.com
 mail     IN   A     192.168.1.2
          IN   A     some_public_IP

---

• इसे देखने वाला कोई व्यक्ति 192.168.1.2 से जुड़ने का प्रयास कर सकता है
• सबसे अच्छा मामला, यह उछलता है, क्योंकि उन्हें कोई रास्ता नहीं मिला है
• लेकिन अगर उन्हें 192.168.1.2 का उपयोग करते हुए एक सर्वर भी मिला है, तो मेल गलत जगह जाएगा

हां, यह एक टूटा हुआ कॉन्फ़िगरेशन है, लेकिन मैंने इसे (और बदतर) होते देखा है।

नहीं, यह डीएनएस की गलती नहीं है, यह वही कर रहा है जो इसे बताया गया है।

Comments

गलत मशीन को DNS समस्या के लिए मेल कैसे पहुँचा रहा है? आपको SMTP सर्वर को प्रमाणित करना चाहिए। यह एक SMTP कॉन्फ़िगरेशन समस्या है जिसका DNS से ​​कोई लेना-देना नहीं है। आप यहां सेब की तुलना संतरे से नहीं कर रहे हैं, आप एक छड़ी पर लैग्रैनिजियन डेरिवेटिव के पांच मिलीग्राम के लिए एक रेडियोधर्मी ब्यूटेड टोस्ट की तुलना कर रहे हैं। यदि आप गलत एमएक्स या ए परिणाम प्राप्त करने के बारे में चिंता कर रहे हैं, तो आपको डीएनएसएसएसईसी का उपयोग डीएनएस को पकड़ने के बजाय उसके लिए जिम्मेदार होना चाहिए जो इसके लिए ज़िम्मेदार नहीं है, और यदि आप गलती से एसएमटीपी को गलत RFC1918 नंबर पर वितरित कर रहे हैं जिसे आपने गलत या गलत तरीके से अपने नेटवर्क को वितरित किया है।

— मिहाई लिम्बायसन

(स्पष्टीकरण के लिए फिर से शुरू)

— मिहाई लिम्बासन

अगर आपके नेटवर्क पर किसी ने एक आईपी नंबर बनाया है, तो आईपी प्रोटोकॉल ठीक उसी तरह से काम कर रहा है, जैसे बिना सुरक्षा को ध्यान में रखे। आप जो पूछ रहे हैं वह है "मैं कैसे विश्वास कर सकता हूं कि मैं वास्तव में जिस पर बात करने वाला हूं, उससे बात करने वाला हूं?" और इसका उत्तर IP और / या DNS द्वारा वितरित नहीं किया जा सकता है, इसका उत्तर DNSSEC और / या SSL / TLS और / या एक एप्लिकेशन लेयर तंत्र द्वारा दिया जाता है।

— Mihai Limbăşan 16

बस डेव की पोस्ट पर अपनी टिप्पणी पढ़ें - आपकी पोस्ट अब अधिक समझ में आती है :) मैं अभी भी आधार से असहमत हूं, लेकिन मुझे नहीं लगता कि यह अब और तर्कहीन है ...

— मिहाई लिम्बायसन

नहीं, यह प्रमाणीकरण के बारे में बिल्कुल नहीं था, बस गलत स्थान पर कनेक्शन समाप्त होने के बारे में। मैंने देखा कि बहुत सारे है कि जब Verisign वाइल्डकार्ड * .com ~ 2001 में फैसला किया।

— अलनीतक

Answer 5

हालांकि संभावना दूरस्थ है मुझे लगता है कि आप MITM के कुछ हमलों के लिए खुद को स्थापित कर रहे होंगे।

मेरी चिंता यह होगी। कहते हैं कि मेल सर्वर पर कॉन्फ़िगर किए गए मेल क्लाइंट के साथ आपके उपयोगकर्ता में से एक अपने लैपटॉप को किसी अन्य नेटवर्क पर ले जाता है। यदि ऐसा होता है तो अन्य नेटवर्क भी उसी RFC1918 के उपयोग में होते हैं। वह लैपटॉप smtp सर्वर में प्रवेश करने का प्रयास कर सकता है और उपयोगकर्ता के क्रेडेंशियल्स को उस सर्वर पर प्रस्तुत कर सकता है जो उसके पास नहीं होना चाहिए। यह विशेष रूप से सच होगा क्योंकि आपने एसएमटीपी कहा था और यह उल्लेख नहीं किया था कि आपको एसएसएल की आवश्यकता है।

Comments

यदि उपयोगकर्ता के पास एक लैपटॉप है जिसका वे आपके कार्यालय में और साथ ही कहीं और उपयोग करते हैं, तो संभावना है कि उन्होंने अपनी मेजबानों की फाइल को एमटीए के आंतरिक आईपी पर इंगित करने के लिए कॉन्फ़िगर किया होगा, या सीधे अपने एमयूए कॉन्फ़िगरेशन में आईपी का उपयोग किया होगा। समान अंतिम परिणाम। IPv6 पर लाने के लिए और RFC1918 की मौत, यह एक ही तरीका है सुनिश्चित करने के लिए है ...

— Womble

उत्कृष्ट बिंदु Zoredache। यह एक दिलचस्प हमला वेक्टर है। MUA के आधार पर यह सामान्य रूप से प्रस्तुत हो सकता है "कुछ कष्टप्रद हुआ, कृपया मुझे वह करने के लिए क्लिक करें जो आप मुझे पहली जगह" डायलॉग बॉक्स में करना चाहते थे, या यदि एसएसएल प्रमाणपत्र मेल नहीं खाता तो यह एकमुश्त विफल हो सकता है।

— डेव चेनी

क्या वैध नेटवर्क में सभी सर्वर (अर्थात वेब / HTTPS, IMAP, और SMTP) को प्रभावी ढंग से समाप्त कर दिया गया है, इसके लिए SSL / TLS- आधारित क्लाइंट कनेक्शन की आवश्यकता है?

— जॉनी उथाह

@JohnnyUtahh, अच्छी तरह से आपको मान्य सर्वरों के साथ TLS का समर्थन करने के लिए सभी सर्वरों की आवश्यकता होती है, और आपको सभी ग्राहकों को समारोहों को सत्यापित करने के लिए कॉन्फ़िगर करने की आवश्यकता होती है, और कभी भी गैर-टीएलएस कनेक्शन की कोशिश न करें। जो अब अधिक सामान्य डिफ़ॉल्ट है, फिर 10 साल पहले। लेकिन अभी भी पुराना / बेवकूफ सॉफ्टवेयर है जो गैर-टीएलएस कनेक्शन की कोशिश कर सकता है।

— ज़ॉडेचेस

हां, सभी समझ में आता है, धन्यवाद @Zoredache।

— जॉनी उटाह

Answer 6

आपके दो विकल्प / etc / मेजबान हैं और आपके सार्वजनिक क्षेत्र में एक निजी IP पता डाल रहे हैं। मैं पूर्व की सिफारिश करूंगा। यदि यह बड़ी संख्या में मेजबानों का प्रतिनिधित्व करता है, तो आपको आंतरिक रूप से अपनी रिवाल्वर चलाने पर विचार करना चाहिए, यह उतना कठिन नहीं है।

Comments

यह निश्चित रूप से एक विकल्प है, लेकिन क्यों? एक आंतरिक रिज़ॉल्वर या (बहुत अधिक होशियार) चलाने से क्या मिलता है जैसे कि BIND विचारों का उपयोग आपको प्रशासनिक ओवरहेड और रखरखाव के बोझ के साथ होता है? यही मेरी समझ में नहीं आता।

— Mihai Limbăşan

अपना खुद का नाम सर्वर चलाना रॉकेट साइंस नहीं है। यदि आपका नेटवर्क पर्याप्त आकार का है जिसे आप हैक के रूप में / etc / मेजबानों को हैक या समय लेने के लिए उपयोग करने पर विचार करते हैं, तो आपको अपने नेटवर्क में एक जोड़ी रिज़ॉल्वर स्थापित करने की आवश्यकता है। एक साइड बेनिफिट के रूप में आप अपने नेटवर्क को छोड़ते हुए dns ट्रैफिक की मात्रा को कम करते हैं और आप सामान्य प्रश्नों के समाधान को गति देते हैं।

— डेव चेनी

मुझे पता है कि यह रॉकेट साइंस नहीं है, लेकिन यह एक रखरखाव ओवरहेड और एक संभावित सुरक्षा जोखिम है। निश्चित रूप से एक RFC1918 नेटवर्क के अस्तित्व को लीक करने की तुलना में एक उच्च सुरक्षा जोखिम। DNS ट्रैफ़िक पूरी तरह से नगण्य है - मैं काम पर अपने DNS पर 80 से अधिक बड़ी और व्यस्त ज़ोन फ़ाइलों की मेजबानी करता हूं और साप्ताहिक DNS ट्रैफ़िक Youtube के 2 मिनट से कम है। क्वेरी रिज़ॉल्यूशन को तेज़ करना वास्तव में DNS में RFC1918 नंबरों के खिलाफ पहला आधा लेन का तर्क है जो मैंने यहां देखा है :) वास्तव में सामान्य घुटने-झटका से परे थोड़ा सोचने के लिए तैयार "ओह, नोज़, यह एक सुरक्षा जोखिम है" प्रतिक्रिया :)

— Mihai लिम्बायसन

@Alnitak: मैं समझता हूं कि आप कहां से आ रहे हैं, लेकिन यह अभी भी एक DNS समस्या नहीं है, और मैं यह बनाए रखता हूं कि DNS के माध्यम से कहीं और उत्पन्न होने वाली समस्याओं को ठीक करने की कोशिश करना एक अच्छा विचार नहीं है। समस्याओं को स्रोत पर तय किया जाना चाहिए, डीएनएस हैक द्वारा पैच नहीं किया गया - हैक नेटवर्क को भंगुर बनाते हैं।

— मिहाई लिम्बायसन

अच्छा, हाँ, मैं सहमत हूँ। और अपने निजी होस्ट की जानकारी को सार्वजनिक DNS में डालना आंतरिक DNS सर्वर के नहीं होने की समस्या का एक हैक समाधान है ... :) समस्या यह है कि उच्चतर परतें यह नहीं जानती हैं कि यह जानकारी "निजी" मानी जाती है ।

— अलनीतक

Answer 7

इसके साथ सूक्ष्म समस्याएं हो सकती हैं। एक यह है कि DNS रिबाइंड हमलों का सामान्य समाधान सार्वजनिक DNS सर्वरों से हल की गई स्थानीय DNS प्रविष्टियों को फ़िल्टर करता है। तो आप या तो खुद को विद्रोही हमलों के लिए खोलते हैं, या स्थानीय पते काम नहीं करते हैं, या अधिक परिष्कृत कॉन्फ़िगरेशन की आवश्यकता होती है (यदि आपका सॉफ़्टवेयर / राउटर इसे अनुमति भी देता है)।

Comments

+1 DNS विद्रोह बुरा है !! medium.com/@brannondorsey/…

— ओहद श्नाइडर

Answer 8

इसे होस्ट्स फ़ाइल में रखना सबसे अच्छा है। यदि किसी भी मशीन को कभी भी किसी भी तरह से कनेक्ट करना है, तो उसे सार्वजनिक DNS में डालने से आपको क्या लाभ होगा?

Comments

क्लाउड में काम करने से आपके पास हजारों निजी मशीनें हो सकती हैं। कुछ साल पहले, नेटफ्लिक्स ने कहा कि उनके पास 2,000+ कैसंड्रा नोड्स थे। यह /etc/hostsफ़ाइल का उपयोग करने के लिए व्यावहारिक नहीं है क्योंकि सभी 2,000 मशीनों को इन आईपी / नाम जोड़े का प्रबंधन करने की आवश्यकता है ...

— एलेक्सिस विलके

Answer 9

यदि निजी द्वारा आपका मतलब 10.0.0.0/8, 192.168.0.0/16, या 172.16.0.0/12 है, तो नहीं । अधिकांश इंटरनेट राउटर इसे पहचानते हैं कि यह क्या है - एक निजी पता जिसे कभी भी सार्वजनिक इंटरनेट पर सीधे फैशन में रूट नहीं किया जाना चाहिए , जो कि NAT की लोकप्रियता में मदद करता है। आपके सार्वजनिक DNS सर्वर से संपर्क करने का प्रयास करने वाला कोई भी व्यक्ति DNS से ​​निजी आईपी पते को पुनः प्राप्त करेगा, केवल एक पैकेट भेजने के लिए .... कहीं नहीं। जैसा कि उनका कनेक्शन इंटरनेट को आपके निजी पते पर भेजने का प्रयास करता है, कुछ (पूरी तरह से कॉन्फ़िगर) राउटर रास्ते में बस पैकेट को जिंदा खा जाएगा।

यदि आप "बाहर" से "अंदर" आने के लिए ईमेल प्राप्त करना चाहते हैं, तो कुछ बिंदु पर, पैकेट को आपके फ़ायरवॉल को पार करना होगा। मैं इसे संभालने के लिए एक डीएमजेड पता स्थापित करने का सुझाव दूंगा - एक एकल सार्वजनिक आईपी पता जो किसी भी राउटर / फ़ायरवॉल द्वारा आपके द्वारा नियंत्रित किया जाता है। मौजूदा सेटअप जिसे आप ध्वनियों का वर्णन करते हैं, यह बिल्कुल वैसा ही करता है।

संपादित करें: इरादे का स्पष्टीकरण ... (नीचे टिप्पणी देखें)। यदि यह समझ में नहीं आता है, तो मैं अपना स्वयं का पद निकालने के लिए मतदान करूंगा।

Comments

यह सब अच्छा और सत्य है, लेकिन आपने इसका वास्तविक कारण नहीं बताया है कि किसी को DNS में RFC1918 पतों को क्यों नहीं प्रकाशित करना चाहिए। आपने अभी वर्णन किया है कि RFC1918 पते क्या हैं और उनमें से कुछ के लिए मार्ग नहीं होना संभव है। यह किसी अन्य आईपी नंबर से कैसे अलग है? 198.41.0.4 के लिए मार्ग नहीं होना संभव है - इसका मतलब है कि DNS में 198.41.0.4 प्रकाशित करना गलत है? DNS एक नाम रिज़ॉल्यूशन सिस्टम है । इसका रूटिंग से कोई लेना-देना नहीं है, दोनों ऑर्थोगोनल हैं। आप समस्याओं की दो श्रेणियों से टकरा रहे हैं, जो मूल रूप से FUD के लिए हैं।

— Mihai Limbăşan

चर्चा का संदर्भ सार्वजनिक DNS सर्वर में निजी आईपी पतों का उपयोग था । पोस्ट का बिंदु यह इंगित करना था कि, डिफ़ॉल्ट रूप से, राउटर निजी आईपी पते को रूट करने के लिए नहीं हैं। मैं यह संकेत देने का प्रयास नहीं कर रहा था कि आप DNS सर्वर में निजी आईपी पतों का उपयोग नहीं कर सकते , केवल यह कि आप उन आईपी पतों को "बाहरी" को प्रदान नहीं करें। यदि यह पर्याप्त स्पष्ट नहीं है, तो मैं ख़ुशी से पोस्ट को वापस ले लूंगा। अन्यथा, मैं असहमत हूं, पोस्ट 100% स्पॉट-ऑन है - इस व्यक्ति के लिए शुद्ध प्रभाव यह है कि / उन्हें समस्या होगी / यदि वे ऐसा करते हैं।

— अवनी पायने

सिर हिलाते हैं एल्निटैक पद के अंतर्गत आपकी टिप्पणी यह मंजूरी दे दी अप :) धन्यवाद।

— Mihai Limbăşan

"कोई भी आपके सार्वजनिक DNS सर्वर से संपर्क करने का प्रयास कर रहा है, DNS से ​​निजी आईपी पते को पुनः प्राप्त करेगा, केवल एक पैकेट भेजने के लिए .... कहीं नहीं" - नहीं , आपने वास्तव में सिर्फ डीएनएस विद्रोह का वर्णन किया है और यह कुछ सबसे सुरक्षित राउटर पर काम करता है। मेरे पेप्पवे सर्फ SOHO सहित वहाँ से बाहर: rebind.network/rebind

— ओहद श्नाइडर

Answer 10

मैं इसी तरह की जानकारी की तलाश में यहां पहुंचा था और आश्चर्यचकित था कि कई लोग कहते हैं कि यह आपके निजी आईपी पते को लीक करना ठीक है। मुझे लगता है कि हैक किए जाने के संदर्भ में, यह बहुत बड़ा अंतर नहीं है अगर आप सुरक्षित नेटवर्क पर हैं। हालाँकि, DigitalOcean में सभी स्थानीय नेटवर्क ट्रैफ़िक ठीक उसी केबलों पर हैं, जहाँ हर किसी के पास वास्तव में बाकी सभी ट्रैफ़िक तक पहुँच हो सकती है (संभवत: मैन इन द मिडल अटैक)। यदि आपको बस एक ही डेटा सेंटर में एक कंप्यूटर मिलेगा। जानकारी निश्चित रूप से आपको मेरे ट्रैफ़िक को हैक करने के करीब एक कदम देती है। (अब प्रत्येक ग्राहक का अपना निजी नेटवर्क है जैसे अन्य क्लाउड सेवाओं जैसे AWS के साथ।)

कहा जा रहा है, अपनी खुद की BIND9 सेवा के साथ, आप आसानी से अपने सार्वजनिक और निजी आईपी को परिभाषित कर सकते हैं। यह viewसुविधा का उपयोग करके किया जाता है , जिसमें एक सशर्त शामिल होता है। यह आपको एक DNS को क्वेरी करने और आंतरिक आईपी के बारे में एक उत्तर प्राप्त करने की अनुमति देता है, यदि आप अपने स्वयं के आंतरिक आईपी पते से पूछ रहे हों।

सेटअप के लिए दो ज़ोन की आवश्यकता होती है। चयन का उपयोग करता है match-clients। यहाँ BIND9 के साथ दो-इन-वन DNS सर्वर से सेटअप का एक उदाहरण है :

acl slaves {
    195.234.42.0/24;    // XName
    193.218.105.144/28; // XName
    193.24.212.232/29;  // XName
};

acl internals {
    127.0.0.0/8;
    10.0.0.0/24;
};

view "internal" {
    match-clients { internals; };
    recursion yes;
    zone "example.com" {
        type master;
        file "/etc/bind/internals/db.example.com";
    };
};
view "external" {
    match-clients { any; };
    recursion no;
    zone "example.com" {
        type master;
        file "/etc/bind/externals/db.example.com";
        allow-transfer { slaves; };
    };
};

यहां बाहरी क्षेत्र है और हम देख सकते हैं कि आईपी निजी नहीं हैं

; example.com
$TTL    604800
@       IN      SOA     ns1.example.com. root.example.com. (
                     2006020201 ; Serial
                         604800 ; Refresh
                          86400 ; Retry
                        2419200 ; Expire
                         604800); Negative Cache TTL
;
@       IN      NS      ns1
        IN      MX      10 mail
        IN      A       192.0.2.1
ns1     IN      A       192.0.2.1
mail    IN      A       192.0.2.128 ; We have our mail server somewhere else.
www     IN      A       192.0.2.1
client1 IN      A       192.0.2.201 ; We connect to client1 very often.

आंतरिक क्षेत्र के लिए, हम पहले बाहरी क्षेत्र को शामिल करते हैं, जो कि यह कैसे काम करता है। यदि आप एक आंतरिक कंप्यूटर हैं, तो आप केवल आंतरिक क्षेत्र का उपयोग करते हैं, इसलिए आपको अभी भी बाहरी क्षेत्र परिभाषाओं की आवश्यकता है, इसलिए $includeकमांड:

$include "/etc/bind/external/db.example.com"
@       IN      A       10.0.0.1
boss    IN      A       10.0.0.100
printer IN      A       10.0.0.101
scrtry  IN      A       10.0.0.102
sip01   IN      A       10.0.0.201
lab     IN      A       10.0.0.103

अंत में, आपको यह सुनिश्चित करना होगा कि आपके सभी कंप्यूटर अब उस DNS और उसके दासों का उपयोग करें। एक स्थैतिक नेटवर्क को मानते हुए, इसका अर्थ होगा आपकी /etc/network/interfacesफ़ाइल का संपादन करना और nameserverविकल्प में अपने DNS IP का उपयोग करना । कुछ इस तरह:

iface eth0 inet static
    ...
    nameserver 10.0.0.1 10.0.0.103 ...

अब आप सभी को सेट होना चाहिए।