DEFCON 21. DNS सम्मेलन आपके स्वास्थ्य के लिए खतरनाक हो सकता है। भाग 1

मेरा नाम रॉब स्टैकल है, मैं फीनिक्स, एरिजोना से एक सुरक्षा सलाहकार हूं, और मैं मुख्य रूप से एक पेंटर के रूप में काम करता हूं। मैं 1996 से डेफकॉन सम्मेलनों में भाग ले रहा हूं, मैं उच्च-ऊंचाई वाली फोटोग्राफी का शौकीन हूं, और इस सप्ताह के अंत में हमारी शादी की ग्यारहवीं वर्षगांठ थी। मैं अपनी अद्भुत और समझदार पत्नी लिंडा को धन्यवाद देना चाहता हूं, जिन्होंने उम्मीद नहीं की थी कि डेफकॉन में मेरी भागीदारी का मतलब है कि हर साल मुझे वेगास में अपनी शादी की सालगिरह मनाने के लिए मजबूर होना पड़ेगा, जिसका मुझे बहुत अफसोस है।



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

गलत कॉन्फ़िगरेशन का पता लगाने के लिए बाजार में कमजोरियों की अनुपस्थिति मुझे हमेशा "दरवाजे में अपना पैर रखने का मौका देती है।" आज हम विभिन्न विषयों पर चर्चा करेंगे जिनमें मैं DNS के साथ अपने कारनामों के बारे में बात करूंगा और DNS से ​​संबंधित लोगों पर मेरी चालें।

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

2011 में ब्लैक हैट और डेफकॉन सम्मेलनों में, एर्टोम डाइनबर्ग ने बात की कि उन्होंने बीट स्क्वेटिंग को क्या कहा, या "एक बीट फ्लिपिंग"। जो इस अध्ययन से परिचित नहीं हैं, लेकिन जो लोकप्रिय डोमेन के DNS में इस समस्या में रुचि रखते हैं, वे इस स्लाइड पर दिए गए लिंक का उपयोग करके अपनी प्रस्तुति की सामग्री डाउनलोड कर सकते हैं।



परियोजना पृष्ठ / वीडियो प्रस्तुति / स्लाइड्स

जब मैंने उनके भाषण की घोषणा को पढ़ा, तो ब्लैक हैट पर रिपोर्ट से पहले ही प्रकाशित किया गया था, मुझे तुरंत दिलचस्पी हो गई कि यह मेरे अपने उद्देश्यों के लिए कैसे उपयोग किया जा सकता है। विवरण में जाने के बिना, मैं बताऊंगा कि बीट स्क्वेटिंग क्या है, ऐसा क्यों होता है और इसका क्या प्रभाव पड़ता है। मैं आपको याद रखने के जोखिम के कुछ उदाहरण दिखाऊंगा जब 1 में 0 हो जाता है और इसके विपरीत, मेमोरी में थोड़ा सा फ़्लिप होता है। निम्नलिखित स्लाइड्स यह दिखाती हैं कि यह कैसे एक लाइन का उदाहरण स्मृति में दिखता है जो एक डोमेन नाम प्रदर्शित करता है।



ऐसी रेखा के बीच में, इकाई शून्य में बदल जाती है। आर्टीम ने उस घटना की जांच की जिसमें सही समय पर मेमोरी के सही हिस्से में एक एकल बिट त्रुटि ने क्लाइंट को पूरी तरह से वैध लेकिन गलत डोमेन नाम का अनुरोध करने के लिए मजबूर किया।

इस तरह की त्रुटि की संभावना और कारणों के बारे में बहुत सारी बातें हुईं, लेकिन मैंने उन सभी तरीकों का अध्ययन करना शुरू किया जो इस त्रुटि को दुर्भावनापूर्ण उद्देश्यों के लिए उपयोग करने की अनुमति देते हैं। तो, DNS स्क्वाटिंग आपको डोमेन नामों को विकृत करने की अनुमति देता है, फिर इन "गलत" डोमेन को पंजीकृत करें और उनके लिए उपयोगकर्ता अनुरोध भेजें।

निम्न स्लाइड से पता चलता है कि Google डोमेन नाम के बिट-स्क्वाटिंग के परिणामस्वरूप, जब मेमोरी "हिट" 1 में एक उच्च-ऊर्जा प्रोटॉन, जिसका अर्थ अक्षर जी है, इसे 0 में बदल देता है, जिसका अर्थ है अक्षर f, और परिणामस्वरूप, उपयोगकर्ता goofle.com पर पुनर्निर्देशित होता है ।



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

हालाँकि, इस प्रकार की मेमोरी बहुत सामान्य नहीं है, और भले ही आपने ईसीसी का उपयोग किया हो, फिर भी कई स्थान ऐसे हैं, जहां बिट स्क्वेटिंग हो सकती है और जहां ईसीसी मेमोरी का उपयोग कभी नहीं किया जाता है, उदाहरण के लिए, नेटवर्क कार्ड में या हार्ड डिस्क के डीआरएएम कैश में।

डिवाइनबर्ग ने समस्या के कारणों का विस्तार से वर्णन किया है, लेकिन सामान्य तौर पर यह कहा जा सकता है कि मेमोरी त्रुटियां होती हैं, कभी-कभी वे मेमोरी को नुकसान पहुंचाती हैं और कभी-कभी इसका DNS पर प्रभाव पड़ता है। मूल रूप से, थोड़ा सा "फ़्लिपिंग" मेमोरी, ओवरहीटिंग, इलेक्ट्रिकल समस्याओं, विकिरण के संपर्क और यहां तक ​​कि कॉस्मिक रेडिएशन के कारण होने वाली शारीरिक क्षति के कारण होता है।

डेफकॉन आयोजकों के मंच पर उपस्थिति से बाधित होता है, जो स्पीकर और उनकी पत्नी लिंडा को बधाई देता है, जो ग्यारहवीं शादी की सालगिरह पर पहली बार सम्मेलन में मौजूद है। रॉबर्ट ने उन्हें बधाई के लिए धन्यवाद दिया और प्रस्तुति जारी रखी।
कॉस्मिक रेडिएशन बिट स्क्वाटिंग को प्रभावित करने वाला एक अत्यंत दुर्लभ कारक है, लेकिन ओवरहीटिंग मेमोरी त्रुटियों का एक बहुत ही सामान्य कारण है। मैंने देखा कि अत्यधिक परिचालन की स्थिति के कारण स्मार्टफोन विशेष रूप से कमजोर होते हैं, जिससे वे उजागर होते हैं। स्मार्टफोन की बैटरी का अधिक गर्म होना एक सामान्य घटना है। अधिकांश अन्य उपकरणों में शीतलन है, लेकिन यहां तक ​​कि वे मुश्किल परिचालन स्थितियों को बनाने का प्रबंधन करते हैं।



बहुत समय पहले नहीं, Google ने अपने डेटा केंद्रों के काम के बारे में जानकारी प्रकाशित की थी। जिन दिलचस्प चीजों के बारे में मुझे पता चला उनमें से एक यह संदेश था कि, ऊर्जा बचाने के लिए, वे अपने डेटा केंद्रों को ऐसी परिस्थितियों में संचालित करते हैं कि हममें से अधिकांश अनुचित समझेंगे। यदि विशिष्ट डेटा केंद्र 60-70 डिग्री फ़ारेनहाइट (15-20 डिग्री सेल्सियस) के अधिकतम तापमान पर संचालित होते हैं, तो Google विशेषज्ञ कंपनियों को कम से कम 80 डिग्री (27 डिग्री सेल्सियस) और एक बेल्जियम डेटा केंद्र के तापमान पर डेटा केंद्र संचालित करने की सलाह देते हैं। अपने सर्वर को 95 डिग्री (35 ° C) के तापमान पर संचालित किया।



कैप्शन: "मैंने सुना है कि यह हमें पैसे बचाता है।"

इंटेल और माइक्रोसॉफ्ट का दावा है कि उनके सर्वर उच्च तापमान पर अच्छा व्यवहार करते हैं, और डेल गारंटी देता है कि उनके सर्वर 115 डिग्री फ़ारेनहाइट (46 डिग्री सेल्सियस) पर चलेंगे। मुझे लगता है कि यह एक बुरा विचार है, क्योंकि स्थिर मेमोरी ऑपरेशन सुनिश्चित करने के लिए तापमान मुख्य कारक है, और Google डेटा केंद्र "आग" तापमान पर काम करते हैं।

मैंने यह अध्ययन करना शुरू कर दिया कि यह क्या फायदे दे सकता है और कौन से डोमेन बिट स्क्वेटिंग के लिए सबसे अधिक असुरक्षित थे, अर्थात, मैंने इस तरह की त्रुटियों को बढ़ाने की संभावना बढ़ाने के लिए सबसे अक्सर अनुरोध किए गए नामों को खोजने की कोशिश की। मैंने सबसे आम डोमेन नाम खोजने के लिए बड़ी कंपनियों के डीएनएस लॉग इकट्ठा करना शुरू किया और पता लगाया कि सबसे अनुरोधित नाम gstatic.com था। यह उन डोमेन में से एक है जो Google CSS, छवियाँ, जावास्क्रिप्ट और XML फ़ाइलों जैसी स्थिर जानकारी प्रदान करने का कार्य करता है।



मैंने इस gstatic.com डोमेन नाम में बिट्स के संभावित "उथल-पुथल" की पहचान करने के लिए एक स्क्रिप्ट लिखी, और मुझे इस नाम की सभी विविधताओं की सूची 34 टुकड़ों की मात्रा में मिली। उनमें से पांच कानूनी उद्देश्यों के लिए उपयोग किए गए थे, शेष 29 उपलब्ध थे, इसलिए मैंने उन सभी को खरीदा।



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



पृष्ठ पर आप एक विशिष्ट नाम ट्रिशा जोन्स के लिए एक अनुरोध के रूप में एक दिलचस्प कलाकृति देख सकते हैं।



इसके अलावा, अनुरोधों की संख्या बढ़ी, अधिक विकृत नाम, अधिक छवि अनुरोध और मूल अनुरोध के अधिक लिंक थे, जिसके परिणामस्वरूप मैंने 50,000 से अधिक अद्वितीय अनुरोध एकत्र किए, और यह, जैसा कि यह निकला, सामान्य था।



स्लाइड में अभिनेत्री सेलेना गोमेज़ की "फोटो खींची" छवि के लिए एक अनुरोध दिखाया गया है, जो हॉल में हँसी का कारण बनता है।

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

अब मेरे लॉग सभी शोर से भरे हुए हैं, मुझे हर दिन इतनी मात्रा में विकृत अनुरोध मिलते हैं कि मैं उन्हें मैन्युअल रूप से देखने में सक्षम नहीं हूं।



इसलिए, मैं समान क्वेरी पैटर्न खोजने के प्रयास में स्क्रिप्ट लिखता हूं, और मुझे जो सबसे बड़ा मिला है, वही विकृत डोमेन नाम के लिए एक ही छवि के बहुत सारे प्रश्न थे, और वे सभी मोबाइल फोन से आए थे। मुझे ये अनुरोध हर कुछ सेकंड में प्राप्त हुए, क्योंकि इन सभी फ़ोनों ने Google वेबसाइट के खोज पृष्ठ का उपयोग करने की कोशिश की और मुझे मूल पृष्ठ लोगो की एक छोटी सी तस्वीर प्रदान करने के लिए कहा।

मैंने पूरे Google क्लाउड से एक वेब सर्वर पाया जो सामग्री परोसता था और अपने सर्वर में से एक को इंगित करते हुए लगातार डोमेन नाम को विकृत करता था, जहां उस नाम वाला लोगो दुर्घटना से हुआ, और ग्राहकों ने इसे ले लिया।

स्लाइड से पता चलता है कि मोबाइल डिवाइस की स्क्रीन पर Google खोज पृष्ठ का लोगो किस प्रकार ऑक्युपी लोगो द्वारा प्रतिस्थापित किया जाता है, जो हॉल में एक प्रशंसनीय हंसी का कारण बनता है।

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

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



मुझे अगली स्लाइड में एक घंटे की आवृत्ति के साथ दिखाए गए अनुरोध प्राप्त हुए। वे परिचित नहीं दिखते थे, वे सभी Google फीडफेटचर क्लाइंट का उपयोग करते थे, वे सभी एक ही नेटवर्क पर उपकरणों से आते थे, और सभी अनुरोध XML फ़ाइलों से संबंधित थे। इसलिए मैंने थोड़ा सा आस-पास अफवाह फैला दी और पाया कि फीडफ़ेटचर वह तंत्र है जो Google iGoogle के लिए अद्यतन सामग्री पर कब्जा करने के लिए उपयोग करता है, और स्रोत आईपी पते बेल्जियम में स्थित थे।



ये अनुरोध Google के स्वयं के सर्वर से संबंधित हैं, जिनका उपयोग विभिन्न विजेट्स के लिए अद्यतन सामग्री प्राप्त करने के लिए किया जाता है जो कि iGoogle होम पेज, एक व्यक्तिगत इंटरनेट पोर्टल को निजीकृत करते हैं।

प्रत्येक विजेट एक XML फ़ाइल है जो सामग्री को परिभाषित करती है, और Google ने मुझे यह सामग्री मेरे प्रस्तुति सर्वरों (तालियाँ और श्रोता हँसी) को प्रदान करने के लिए कहा है।



इसलिए, मैंने सोचा कि अगर Google गलती से मुझसे ऐसी सामग्री चाहता है जो अपने उपयोगकर्ताओं को प्रदान कर सके, तो वह इसे प्राप्त करेगा। मैंने XML फाइलें ले लीं जिनके बारे में Google ने मुझसे पूछा और उन्हें भागों में विभाजित किया। जैसा कि आप देख सकते हैं, दो खंड हैं: एक शीर्षक जो मॉड्यूल का वर्णन करता है, और HTML सीएसएस और जावास्क्रिप्ट कोड में पैक किए गए डेटा का एक सी ब्लॉक जो विजेट बनाता है।



इसलिए मैंने बस बैकग्राउंड इमेज का लिंक बदल दिया, gstatic.com का पता grtatic.com पर बदल दिया, और बाकी को अपरिवर्तित छोड़ दिया, एक्सएमएल फाइलों को उस लाइन में डाल दिया जहां से फीडफेटेकर उन्हें मिला, और थोड़ा इंतजार किया।



उसके तुरंत बाद, फीडफेटचर ने मुझसे XML फाइलें मांगीं, जिसके बाद मैंने तुरंत इस पृष्ठभूमि छवि के लिए कई Google आईपी पतों से अनुरोध प्राप्त करना शुरू कर दिया।



इसलिए, मैंने अपने द्वारा संशोधित XML फ़ाइलों को हटा दिया और अनुरोधों को रोकने तक इंतजार किया, लेकिन लगातार 35 दिनों तक, 61 डिवाइस हर दिन मुझसे इस छवि के बारे में पूछते रहे। और अधिक दिलचस्प बात यह है कि इन उपकरणों में से प्रत्येक यूके में एक वर्जिन मीडिया क्लाइंट था।



इसलिए इस Google XML फ़ाइल ने 61 लोगों की सेवा की, और पिछले एक साल में, 500 अद्वितीय फीडफेटचर आईपी ने मुझे 15,000 बार इन मॉड्यूल प्रदान करने के लिए कहा है। इसलिए मैं अपने उपयोगकर्ताओं को पृष्ठभूमि की छवि को बदलने की तुलना में अधिक हानिकारक कुछ प्रदान कर सकता था।

यहां कुछ और ट्रिक्स हैं जो आप Google के साथ कर सकते हैं। यदि आपको पता नहीं है, तो Postini Google की हालिया स्पैम सुरक्षा ईमेल, वेब सुरक्षा और ईमेल संग्रहण सेवा है।



यह सेवा आपको अपने DNS रिकॉर्ड को अपने डोमेन में MX रिकॉर्ड इंगित करने और psmtp.com से पहले 4 MX वर्णों को बदलकर अपना डोमेन बनाने की अनुमति देती है। यहां सबसे दिलचस्प बात यह है कि डोमेन इतना छोटा है कि आप आसानी से नाम के सभी संभावित संस्करणों को "उलटा" बिट्स के साथ पंजीकृत कर सकते हैं। एक और दिलचस्प बात यह है कि बहुत सी कंपनियां एक ही डोमेन के लिए अपने एमएक्स रिकॉर्ड का संकेत देती हैं और किसी ने भी नहीं सोचा था कि यह एक बुरा विचार है।

इसलिए, मैंने इस डोमेन के लिए केवल तीन संभावित बिट स्क्वाटिंग को पंजीकृत किया, और psmtp.com का रोजगार इतना बड़ा हो गया कि अगली 4 स्लाइड्स उन अनुरोधों को दिखाती हैं जो मुझे सिर्फ एक महीने में प्राप्त हुए।





इसलिए यदि आप Postini मेल का उपयोग करते हैं, तो आपका अनुरोध किसी समय मेरे सर्वर पर आ जाएगा। मुझे नहीं लगता कि कोई भी कह सकता है कि Google इंटरनेट सुरक्षा के बारे में गंभीर नहीं है। लेकिन अगर कोई सोचता है कि स्मृति की त्रुटियों का कारण बनने वाली अतिवृद्धि किन समस्याओं का कारण बन सकती है, तो वह इस तरह की चीजों की क्षतिपूर्ति की संभावना पर विचार करने का प्रश्न उठा सकेगा। इसलिए, अपने डोमेन नामों को इतना छोटा न होने दें, क्योंकि यह आपके व्यवसाय को नकारात्मक रूप से प्रभावित करता है, जैसे कि पोस्टिनी, खासकर यदि आपका डोमेन लोकप्रिय है।

मैं दृढ़ता से सलाह देता हूं कि लोग एक आंतरिक डोमेन नाम प्रबंधन नीति लागू करें जो उन्हें नाम विकृति त्रुटियों को ठीक करने की अनुमति देता है और स्पष्ट रूप से समझता है कि ऐसी चीजें आपको कैसे प्रभावित कर सकती हैं। यदि आपके पास gstatic.com है और 95 डिग्री के तापमान पर डेटा सेंटर संचालित हो रहा है, तो आप संभवतः यह सुनिश्चित करना चाहते हैं कि किसी भी बिट स्क्वाटिंग की गलती क्लाइंट को दुर्भावनापूर्ण बाहरी नेटवर्क पर नहीं जाने देगी।

वैसे, मेरे द्वारा जांच किए गए सभी डोमेन के बीच, एकमात्र कंपनी जिसने मेरे स्वयं के नाम के सभी संभावित विकृतियों को पंजीकृत किया था, याहू था।

प्रस्तुति के अगले भाग में, मैं DNS के व्यवहार को प्रदर्शित करने जा रहा हूं, जिसे बहुत से लोग, जैसा कि यह बताते हैं, पूरी तरह से समझ में नहीं आता है।



ईमानदारी से, Microsoft ने दस्तावेज़ बनाने का बहुत खराब काम किया, खासकर जब से DNS का व्यवहार अक्सर बदलता रहता है। यह अंत उपयोगकर्ताओं द्वारा क्या हो रहा है, इसकी गलतफहमी की ओर जाता है, खासकर जब से ऐसा व्यवहार अक्सर विरोधाभासी होता है।

इसलिए, मैं यह कहकर शुरू करूंगा कि हर किसी को यह समझना चाहिए कि डीएनएस को क्वेरी करते समय उपकरणों को कैसे व्यवहार करना चाहिए और उनसे क्या उम्मीद करनी चाहिए। फिर मैं समझाऊंगा कि DNS प्रत्यय खोज पथों का उपयोग करते समय यह व्यवहार कैसे अप्रत्याशित हो जाता है, यह सब कैसे अपर्याप्त प्रलेखन को प्रभावित करता है, और मैं उन सभी पाठों के संक्षिप्त अवलोकन के साथ समाप्त हो जाऊंगा जिन्हें इस सब से सीखा जा सकता है। लेकिन सबसे पहले, मैं यह प्रदर्शित करूंगा कि एक एंड-यूज़र के लिए यह कितना खतरनाक हो सकता है कि यह गलत हो कि DNS के साथ क्या हो रहा है।

इसलिए, जब आप अपने ब्राउज़र के एड्रेस बार में www.google.com टाइप करते हैं, तो आपका कंप्यूटर स्थानीय DNS सर्वर को एक अनुरोध भेजता है, और आपको जिस चीज़ की ज़रूरत होती है, उसे खोजने और अनुरोध को वापस करने का काम अब उसे सौंपा जाता है। स्थानीय सर्वर .com सर्वर तक पहुँच के लिए रूट सर्वर को कॉल करता है, और रूट सर्वर इसे .com सर्वर पर भेजता है। वह जाँचता है कि क्या स्थानीय सर्वर google.com के अनुरोधों के लिए अधिकृत है और इसे सर्वर ns.google.com पर भेजता है। अंत में, स्थानीय सर्वर को आपके द्वारा आवश्यक संसाधन के आईपी पते के साथ एक प्रतिक्रिया मिलती है और इसे आपके पास भेजा जाता है।



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

उदाहरण के लिए, आपका डिवाइस www.google.com पर उत्तर खोजने की कोशिश कर रहा है, लेकिन पूरी प्रक्रिया, जिसमें हमें 8 स्लाइड्स के रूप में लिया गया है, केवल तभी होगा जब आप ब्राउज़र के क्वेरी बार में यह पता टाइप करते हैं - www.google .com । यह पूरी तरह से योग्य डोमेन नाम है जो रूट डीएनएस के साथ जुड़ा हुआ है। बहुत से लोग मानते हैं कि पूरी तरह से योग्य डोमेन नाम एक अवधि के साथ समाप्त होता है, जो सच नहीं है। पूर्ण नाम के अंत में एक डॉट की उपस्थिति अभी भी मान ली गई है, और इस वजह से, परेशानी होती है। आइए नाम के 4 रूपों को मुद्रित करने का प्रयास करें:

www.google.com
google.com
www
www.google.com ।

जिनमें से प्रत्येक DNS व्यवहार के संबंध में भिन्न व्यवहार करता है। यह सब अनुकूलन योग्य है, लेकिन आमतौर पर कोई भी ऐसा नहीं करता है।

आइए देखें कि ऐसी स्थितियों में वास्तव में क्या होता है। डीएनएस क्वेरी भेजने का निर्णय लेने से पहले ग्राहक के निर्णय लेने को प्रभावित करने वाले कई कारक हैं। इनमें से दो प्रत्यय खोज पथ और DNS विचलन हैं।



दोनों के पास कई अनुकूलन पैरामीटर हैं जो उनके व्यवहार को प्रभावित करते हैं, और विंडोज के विभिन्न संस्करणों और अलग-अलग सर्विस पैक में अलग-अलग व्यवहार करते हैं।

इस तरह से अधिकांश लोग खोज पथ प्रत्यय का उपयोग करेंगे। यदि आपकी कंपनी को foo कहा जाता है और आप डोमेन foo.com के मालिक हैं, और सक्रिय निर्देशिका का नाम ad.foo.com है, तो आप खोज पथ प्रत्यय ad.foo.com या foo.com के प्रत्यय का उपयोग कर सकते हैं और इसे सिस्टम असेंबली के क्लाइंट भाग में या "पुश" कर सकते हैं। समूह नीति।

यदि आपका कोई ग्राहक संक्षिप्त नाम www को हल करने की कोशिश करता है, तो विंडोज एक्सपी का डिफ़ॉल्ट व्यवहार इस तरह होगा। पहले वह www.ad.foo.com पथ के साथ DNS क्वेरी भेजेगा , फिर पथ www.foo.com के साथ और अंत में एक NetBIOS क्वेरी का अनुसरण करेगा - बस www।

www.phx , www.phx , , www.phx.ad.foo.com , www.phx.foo.com . 15 , NetBIOS, www.phx .



Windows, XP sp.3, DNS — www.phx NetBIOS — www.phx , , .



, , , , , . , , Microsoft DNS.

XP , Microsoft XP, DNS Windows DNS . , www, Windows , , , DHCP Active Directory. www.phx.ad.foo.com , , www.ad.foo.com , www.foo.com , , www.com .



18:30

DEFCON 21. DNS . भाग २


, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 करोड़) 10GB DDR4 240GB SSD 1Gbps दिसंबर तक मुफ्त में जब छह महीने की अवधि के लिए भुगतान करते हैं, तो आप यहां ऑर्डर कर सकते हैं ।

डेल R730xd 2 बार सस्ता? केवल हमारे पास 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps नीदरलैंड और यूएसए में $ 249 से 100 टीवी है ! इन्फ्रास्ट्रक्चर Bldg बनाने के तरीके के बारे में पढ़ें । एक पेन के लिए 9,000 यूरो की लागत वाले डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?