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


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

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


52
2018-05-05 02:21


मूल




जवाब:


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

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

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

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

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


51
2018-05-05 02:37



+1, कारण के लिए गर्भ के जवाब पर टिप्पणी देखें :) - Mihai Limbăşan
यह इस विचार के साथ किसी मुद्दे का एक अच्छा उदाहरण है: merit.edu/mail.archives/nanog/2006-09/msg00364.html - sucuri
क्या यह सलाह अभी भी लागू होती है यदि आपके पास सार्वजनिक आईपी पते वाले संवेदनशील सर्वर हैं, लेकिन फ़ायरवॉल के पीछे पहुंच प्रतिबंधित है? यदि सार्वजनिक आईपी पते के लिए सार्वजनिक DNS बुनियादी ढांचे का एक रोडमैप देता है, तो क्या कुछ हमलावर के लिए उपयोग नहीं करते हैं? मेजबान पहचान? - Kenny
@ केनी हां, सिद्धांत रूप में इसका कुछ उपयोग होता है, लेकिन यह ऐसी जानकारी है जो प्राप्त करना मुश्किल नहीं है क्योंकि सार्वजनिक आईपी पते की सीमा वैसे भी आसानी से खोजी जा सकती है। मैंने जवाब में इसे संबोधित किया और उस धारणा को जोड़कर मैं तर्क दूंगा कि यदि आप किसी भी तरह की सुरक्षा रेखा के रूप में आईपी पते या होस्टनामों को छिपाने के आधार पर हैं, तो आपके पास पहले से ही बहुत बड़ी समस्याएं हैं। - Tall Jeff
@ केनी आपके बिंदु पर, यह निश्चित रूप से वांछित जानकारी की मात्रा को कम करने के लिए वांछनीय है जो सार्वजनिक रूप से खोजने योग्य है और आप उस चीज़ का खुलासा नहीं करना चाहते हैं जिसकी आपको आवश्यकता नहीं थी या कम से कम किसी प्रकार की अच्छी लागत / लाभ व्यापार नहीं था- इसे विचार करने के लिए शामिल बंद। वहां कोई तर्क नहीं है। इसके अलावा, मेरे बिंदु का मूल (और मुझे लगता है कि हम सहमत हैं) बस इतना था कि obfuscation सुरक्षा का एक गरीब रूप है और कोई पूर्ण अच्छा / बुरा नहीं है, लेकिन केवल लागत / लाभ व्यापार बंद होने की एक निरंतरता है आपके जोखिम सहनशीलता इत्यादि के आधार पर केस-दर-मामले आधार पर विचार किया जाता है। - Tall Jeff


कुछ समय पहले नैनोग सूची में इस विषय पर मेरी लंबी चर्चा हुई थी। हालांकि मैंने हमेशा सोचा था कि यह एक बुरा विचार था, यह पता चला कि यह अभ्यास में इतना बुरा विचार नहीं है। कठिनाइयों ज्यादातर आरडीएनएस लुकअप से आती हैं (जो निजी पते के लिए बस बाहरी दुनिया में काम नहीं करती हैं), और जब आप वीपीएन पर पते तक पहुंच प्रदान कर रहे हों या इसी तरह यह सुनिश्चित करना महत्वपूर्ण है कि वीपीएन क्लाइंट ठीक से सुरक्षित हैं जब वीपीएन नीचे होता है तो "लीकिंग" यातायात।

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


30
2018-05-05 02:30



+1, इस प्रश्न के सभी एफयूडी प्रतिक्रियाओं में स्वच्छता की आवाज होने के लिए धन्यवाद। मेरे निचले पृष्ठीय क्षेत्रों में "सुरक्षा जोखिम", और रूटिंग समस्याओं और डीएनएस मुद्दों को एक घुटने-झटके में घुमाया गया "इसे मत करो" प्रतिक्रिया सिर्फ मुझे जगह पर नेटवर्क चलाने वाले लोगों की क्षमता के बारे में आश्चर्यचकित करती है। - Mihai Limbăşan
सुधार: इसे "रूटिंग समस्याओं और DNS समस्याओं को देखते हुए बनाएं तथा प्रमाणीकरण / पहचान मुद्दों को टक्कर लगी "। - Mihai Limbăşan


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

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


8
2018-05-05 02:29



ये असली समस्या क्या हैं? लोगों को किस तरह से भ्रमित किया जाएगा? - womble♦
तो यह ... विनम्र ... 1 9 18 पते सार्वजनिक DNS में नहीं डालना है? मैंने कई समस्याओं को मारा है जो "छुपा" और "विभाजित क्षितिज" DNS जोनों के कारण हैं, लेकिन सार्वजनिक DNS में निजी आईपी के कारण लगभग इतने सारे नहीं हैं। मुझे बस समस्या नहीं दिख रही है। - womble♦
@Womble, कंप्यूटर भ्रमित हो सकते हैं अगर किसी कारण से वे आपके नेटवर्क के बाहर उस होस्ट से कनेक्ट करने का प्रयास करते हैं और एसएमटीपी सर्वर प्राप्त करने की बजाय उन्हें उम्मीद है कि वे उस आईपी पते पर जो कुछ भी वर्तमान में जुड़े हुए हैं, उस पर वे जो भी रह रहे थे, उन्हें मिला। यह भी हो सकता है कि रिमोट पर लैपटॉप का उपयोग करने वाले आपके कर्मचारियों में से एक उपयोगकर्ता के नाम और पासवर्ड को किसी और के नेटवर्क पर सादा पाठ में बाहर कर सकता है क्योंकि उनके पास 1 9 2.168.1.1 भी होता है - Zoredache
आपके उत्तर में मेरी समस्या यह है कि आप समस्याओं का समाधान करते हैं, लेकिन कोई विवरण नहीं देते हैं। अगर ऐसा करने के कारण नहीं हैं, तो मैं उनके बारे में जानना चाहता हूं, इसलिए मैं इस विषय पर पूरी तरह तर्कसंगत निर्णय ले सकता हूं। - womble♦
मैं यह भी जानना चाहूंगा कि "भ्रम" क्या हो सकता है। एकमात्र "भ्रम" मैं सार्वजनिक एनएस या एमएक्स रिकॉर्ड में आरएफसी 1 9 18 पते के बारे में सोच सकता हूं, और यह एक बड़ी वसा त्रुटि है, भ्रम नहीं। सुरक्षा समस्या एक लाल हेरिंग है, 9 0% लोगों के पास पहले से ही 1 9 2.168.1.0/24 होगा और कोई भी वास्तव में अधिक से अधिक DNS जांचने के लिए परेशान नहीं होगा, और यदि आप आंतरिक नेटवर्क लीक करने के बारे में परेशान हैं, तो क्या आपने हाल ही में अपने एसएमटीपी शीर्षलेखों की जांच की है? ऐसा ही सोचा था। - Mihai Limbăşan


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

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

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

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

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

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

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

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

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

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

नहीं, यह DNS की गलती नहीं है, यह सिर्फ वही कर रहा है जो इसे बताया गया है।


6
2018-05-05 09:35



गलत मशीन पर मेल को एक DNS समस्या कैसे वितरित कर रहा है? आपको एसएमटीपी सर्वर प्रमाणीकृत करना चाहिए। यह एक एसएमटीपी कॉन्फ़िगरेशन समस्या है जिसमें DNS के साथ बिल्कुल कुछ नहीं है। आप यहां संतरे से सेब की तुलना भी नहीं कर रहे हैं, आप एक छड़ी पर लग्रैंगियन डेरिवेटिव के पांच मिलीग्राम तक एक रेडियोधर्मी बटरर्ड टोस्ट की तुलना कर रहे हैं। यदि आप गलत एमएक्स या ए परिणाम प्राप्त करने के बारे में चिंतित हैं, तो आपको जिम्मेदार नहीं होने के लिए जिम्मेदार DNS को रखने के बजाय DNSSEC का उपयोग करना चाहिए, और यदि आप गलती से गलत आरएफसी 1 9 18 नंबर पर एसएमटीपी वितरित कर रहे हैं तो आपने अपने नेटवर्क को गलत कॉन्फ़िगर किया है या गलत तरीके से डिज़ाइन किया है। - Mihai Limbăşan
(दोबारा स्पष्टीकरण के लिए प्रशंसा) - Mihai Limbăşan
यदि आपके नेटवर्क पर कोई व्यक्ति आईपी नंबर "बना" बना देता है तो आईपी प्रोटोकॉल ठीक तरह से काम कर रहा है, यानी बिना किसी सुरक्षा के। आप जो पूछ रहे हैं वह है "मैं कैसे भरोसा कर सकता हूं कि मैं वास्तव में उनसे बात कर रहा हूं जिनसे मुझे बात करनी है?" और इसका उत्तर आईपी और / या DNS द्वारा वितरित नहीं किया जा सकता है, इसका उत्तर DNSSEC और / या SSL / TLS और / या अनुप्रयोग परत तंत्र द्वारा वितरित किया जाता है। - Mihai Limbăşan
डेव के पोस्ट पर बस अपनी टिप्पणी पढ़ें - आपकी पोस्ट अब और अधिक समझ में आता है :) मैं अभी भी आधार से असहमत हूं, लेकिन मुझे नहीं लगता कि यह अब तर्कहीन है ... - Mihai Limbăşan
नहीं, यह गलत जगह पर समाप्त होने वाले कनेक्शन के बारे में बिल्कुल प्रमाणीकरण के बारे में नहीं था। मैंने देखा खूब उस समय जब Verisign ~ 2001 में वाइल्डकार्ड * .com वापस फैसला किया। - Alnitak


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


3
2018-05-05 04:32



यह निश्चित रूप से एक विकल्प है, लेकिन क्यों? BIND विचारों जैसे कुछ का उपयोग करके आंतरिक रिज़ॉल्वर या (बहुत चालाक) चलाने से प्रशासनिक ओवरहेड और रखरखाव बोझ के बगल में आपको क्या लाभ होता है? यही वह है जो मुझे समझ में नहीं आता है। - Mihai Limbăşan
अपना खुद का नाम सर्वर चलाना रॉकेट विज्ञान नहीं है। यदि आपका नेटवर्क पर्याप्त आकार का है जिसे आप / etc / hosts का उपयोग हैक या समय लेने के लिए करते हैं, तो आपको अपने नेटवर्क में रिज़ॉल्यूशन की एक जोड़ी सेट करने की आवश्यकता है। एक साइड लाभ के रूप में आप अपने नेटवर्क को छोड़कर डीएनएस यातायात की मात्रा को कम करते हैं और आप सामान्य प्रश्नों के समाधान को तेज करते हैं। - Dave Cheney
मुझे पता है कि यह रॉकेट विज्ञान नहीं है, लेकिन यह एक रखरखाव ओवरहेड और एक संभावित सुरक्षा जोखिम है। आरएफसी 1 9 18 नेटवर्क के अस्तित्व को लीक करने से निश्चित रूप से एक उच्च सुरक्षा जोखिम। DNS यातायात पूरी तरह से नगण्य है - मैं काम पर अपने DNS पर 80 से अधिक बड़ी और व्यस्त जोन फ़ाइलों को होस्ट करता हूं और साप्ताहिक DNS ट्रैफ़िक यूट्यूब के 2 मिनट से कम है। क्वेरी रिज़ॉल्यूशन को तेज़ करना वास्तव में डीएनएस में आरएफसी 1 9 18 नंबरों के खिलाफ पहला आधा रास्ते तर्क है जो मैंने देखा है :) वास्तव में सामान्य घुटने-झटका से थोड़ा आगे सोचने के लिए उपरोक्त "ओह, नोएस, यह एक सुरक्षा जोखिम है" प्रतिक्रिया :) - Mihai Limbăşan
@Annitak: मैं समझता हूं कि आप कहां से आ रहे हैं लेकिन यह अभी भी एक DNS समस्या नहीं है, और मैं यह मानता हूं कि DNS के माध्यम से कहीं और उत्पन्न होने वाले मुद्दों को ठीक करने का प्रयास करना एक अच्छा विचार नहीं है। समस्याएं स्रोत पर तय की जानी चाहिए, न कि DNS हैक्स द्वारा पैच किए गए - हैक्स नेटवर्क को भंगुर बनाते हैं। - Mihai Limbăşan
अच्छा, हाँ, मैं सहमत हूं। और सार्वजनिक DNS में अपनी निजी होस्ट की जानकारी डालने से आंतरिक DNS सर्वर नहीं होने की समस्या के लिए एक हैक समाधान है ... :) समस्या यह है कि उच्च परतें नहीं होती हैं जानना कि यह जानकारी "निजी" माना जाता है। - Alnitak


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

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


2
2018-05-05 02:56



यदि उपयोगकर्ता के पास लैपटॉप है जो वे आपके कार्यालय के साथ-साथ कहीं और उपयोग करते हैं, तो संभावना है कि वे एमटीए के आंतरिक आईपी पर इंगित करने के लिए अपनी मेजबान फ़ाइल को कॉन्फ़िगर कर चुके हैं, या सीधे आईयूए कॉन्फ़िगरेशन में आईपी का इस्तेमाल करते हैं। वही अंतिम परिणाम। आईपीवी 6 और आरएफसी 1 9 18 की मौत पर लाओ, यह सुनिश्चित करने का एकमात्र तरीका है ... - womble♦
उत्कृष्ट बिंदु Zoredache। यह एक दिलचस्प हमला वेक्टर है। एमयूए के आधार पर यह सामान्य "कुछ परेशान हुआ, कृपया मुझे पहले स्थान पर जो करना चाहता था उसे करने के लिए क्लिक करें" संवाद बॉक्स, या अगर एसएसएल प्रमाण मेल नहीं खाता है तो यह असफल हो सकता है। - Dave Cheney


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


1
2018-05-05 15:13





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

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

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


1
2018-05-05 13:39



यह सब अच्छा और सही है, लेकिन आपने वास्तविक कारण नहीं दिया है कि किसी को DNS में RFC1918 पते क्यों प्रकाशित नहीं करना चाहिए। आपने अभी वर्णन किया है कि आरएफसी 1 9 18 के पते क्या हैं और उनमें से कुछ के लिए मार्ग नहीं है। यह किसी अन्य आईपी नंबर से अलग कैसे है? 198.41.0.4 का मार्ग नहीं होना संभव है - क्या इसका मतलब है कि DNS में 198.41.0.4 प्रकाशित करना गलत है? डीएनएस एक है नाम संकल्प प्रणाली। रूटिंग के साथ इसका कोई लेना-देना नहीं है, दोनों ऑर्थोगोनल हैं। आप दो श्रेणियों की समस्याओं को जोड़ रहे हैं, जो मूल रूप से एफयूडी के बराबर है। - Mihai Limbăşan
चर्चा का संदर्भ ए में निजी आईपी पते का उपयोग था जनता DNS सर्वर पद का बिंदु यह इंगित करना था कि, डिफ़ॉल्ट रूप से, राउटर निजी आईपी पते को रूट नहीं करना चाहते हैं। मैं आपको इंगित करने का प्रयास नहीं कर रहा था नहीं कर सकते हैं एक DNS सर्वर में निजी आईपी पते का उपयोग करें, केवल इतना है कि आपको उन आईपी पते "बाहर के लिए" प्रदान नहीं करना चाहिए। यदि यह पर्याप्त स्पष्ट नहीं है, तो मैं खुशी से पोस्ट वापस ले जाऊंगा। अन्यथा, मैं असहमत हूं, पोस्ट 100% स्पॉट-ऑन है - इस व्यक्ति के लिए शुद्ध प्रभाव यह है कि / यदि वे ऐसा करते हैं तो उन्हें समस्या होगी। - Avery Payne
सिर हिला देते हैं Alnitak के पद के तहत आपकी टिप्पणी इसे मंजूरी दे दी :) धन्यवाद। - Mihai Limbăşan
"कोई भी जो आपके सार्वजनिक DNS सर्वर से संपर्क करने का प्रयास कर रहा है, वह DNS से ​​निजी आईपी पता पुनर्प्राप्त करेगा, केवल पैकेट भेजने के लिए .... कहीं नहीं" - नहीं, आपने वास्तव में सिर्फ डीएनएस रीबंडिंग का वर्णन किया है और यह मेरे पेपवेव सर्फ एसओएचओ समेत कुछ सबसे सुरक्षित राउटर पर काम करता है: rebind.network/rebind - Ohad Schneider


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


1
2017-09-16 08:17



+1 DNS रिबाइंडिंग खराब है !! medium.com/@brannondorsey/... - Ohad Schneider