क्रोमियम की एक विशेषता रूट DNS सर्वर पर भारी भार पैदा करती है

क्रोमियम ब्राउज़र, Google Chrome और नए Microsoft Edge के संपन्न ओपन-सोर्स पेरेंट को एक ऐसे फीचर के लिए महत्वपूर्ण नकारात्मक ध्यान मिला है जिसका उद्देश्य अच्छे इरादे से था: यह जाँचता है कि क्या उपयोगकर्ता का ISP गैर-मौजूद डोमेन क्वेरी परिणामों को "चोरी" कर रहा है .

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

DNS रिज़ॉल्यूशन आमतौर पर कैसे निष्पादित किया जाता है

ये सर्वर सर्वोच्च प्राधिकारी हैं जिनसे आपको .com, .net, आदि को हल करने के लिए संपर्क करना चाहिए ताकि वे आपको बताएं कि frglxrtmpuf एक शीर्ष-स्तरीय डोमेन (TLD) नहीं है।

DNS, या डोमेन नाम सिस्टम, एक ऐसी प्रणाली है जिसके द्वारा कंप्यूटर arstechnica.com जैसे यादगार डोमेन नामों को 3.128.236.93 जैसे बहुत कम उपयोगकर्ता-अनुकूल आईपी पते में हल कर सकते हैं। DNS के बिना, इंटरनेट उस तरह से मौजूद नहीं होगा जिसका उपयोग मनुष्य कर सके, जिसका अर्थ है कि ऊपरी स्तर के बुनियादी ढांचे पर अनावश्यक भार एक वास्तविक समस्या है।

किसी एक आधुनिक वेब पेज को लोड करने के लिए अविश्वसनीय संख्या में DNS लुकअप की आवश्यकता हो सकती है। उदाहरण के लिए, जब हमने ईएसपीएन के होमपेज का विश्लेषण किया, तो हमने a.espncdn.com से लेकर z.motads.com तक 93 अलग-अलग डोमेन नाम गिने। पेज को पूरी तरह से लोड करने के लिए ये सभी आवश्यक हैं!

एक खोज इंजन के लिए इस प्रकार के कार्यभार को समायोजित करने के लिए जिसे पूरी दुनिया की सेवा करने की आवश्यकता है, DNS को एक बहु-स्तरीय पदानुक्रम के रूप में डिज़ाइन किया गया है। इस पिरामिड के शीर्ष पर रूट सर्वर हैं - प्रत्येक शीर्ष-स्तरीय डोमेन, जैसे कि .com, के पास सर्वरों का अपना परिवार है जो उनके नीचे प्रत्येक डोमेन के लिए सर्वोच्च प्राधिकरण हैं। एक कदम ऊपर इनमें से सर्वर स्वयं रूट सर्वर हैं a.root-servers.net से m.root-servers.net.

किस नियमित अंतराल पर यह घटित होता है?

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

यदि न तो स्थानीय प्रदाता के DNS सर्वर और न ही इसके कॉन्फ़िगरेशन में निर्दिष्ट "फ़ॉरवर्डिंग सर्वर" के पास कैश्ड प्रतिक्रिया है, तो अनुरोध सीधे आधिकारिक डोमेन सर्वर पर भेजा जाता है ऊपर जिसे आप परिवर्तित करने का प्रयास कर रहे हैं। कब домен.com इसका मतलब यह होगा कि अनुरोध डोमेन के आधिकारिक सर्वर को ही भेजा जाता है com, जो स्थित हैं gtld-servers.net.

प्रणाली gtld-servers, जिसके लिए अनुरोध किया गया था, डोमेन Domain.com के लिए आधिकारिक नाम सर्वरों की एक सूची के साथ-साथ ऐसे एक नाम सर्वर के आईपी पते वाले कम से कम एक लिंक रिकॉर्ड के साथ प्रतिक्रिया करता है। इसके बाद, प्रतिक्रियाएँ श्रृंखला में नीचे की ओर बढ़ती हैं - प्रत्येक फारवर्डर इन प्रतिक्रियाओं को उस सर्वर तक भेजता है जिसने उनसे अनुरोध किया था, जब तक कि प्रतिक्रिया अंततः स्थानीय प्रदाता के सर्वर और उपयोगकर्ता के कंप्यूटर तक नहीं पहुंच जाती। वे सभी इस प्रतिक्रिया को कैश करते हैं ताकि उच्च-स्तरीय सिस्टम को अनावश्यक रूप से परेशान न किया जा सके।

ज्यादातर मामलों में, नाम सर्वर रिकॉर्ड करता है डोमेन.कॉम इनमें से किसी एक फ़ॉरवर्डर पर पहले से ही कैश किया जाएगा, इसलिए रूट सर्वर परेशान नहीं होंगे। हालाँकि, अभी हम उस URL के प्रकार के बारे में बात कर रहे हैं जिससे हम परिचित हैं - वह जो एक नियमित वेबसाइट में परिवर्तित हो जाता है। Chrome अनुरोध स्तर पर हैं ऊपर यह, स्वयं समूहों के कदम पर root-servers.net.

क्रोमियम और NXDomain चोरी की जाँच करें

क्रोमियम जाँचता है कि "क्या यह DNS सर्वर मुझे बेवकूफ़ बना रहा है?" वेरीसाइन के रूट डीएनएस सर्वर के क्लस्टर तक पहुंचने वाले सभी ट्रैफ़िक का लगभग आधा हिस्सा इसी का है।

क्रोमियम ब्राउज़र, Google Chrome का मूल प्रोजेक्ट, नया Microsoft Edge और अनगिनत कम-ज्ञात ब्राउज़र, उपयोगकर्ताओं को एक ही बॉक्स में खोज की आसानी प्रदान करना चाहता है, जिसे कभी-कभी "ऑम्निबॉक्स" भी कहा जाता है। दूसरे शब्दों में, उपयोगकर्ता वास्तविक यूआरएल और खोज इंजन क्वेरी दोनों को ब्राउज़र विंडो के शीर्ष पर एक ही टेक्स्ट फ़ील्ड में दर्ज करता है। सरलीकरण की दिशा में एक और कदम उठाते हुए, यह उपयोगकर्ता को यूआरएल का हिस्सा दर्ज करने के लिए मजबूर नहीं करता है http:// या https://.

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

यदि कोई उपयोगकर्ता अपनी कंपनी के इंट्रानेट पर "मार्केटिंग" टाइप करता है और कंपनी के इंट्रानेट पर उसी नाम से एक आंतरिक वेबसाइट है, तो क्रोमियम एक सूचना बॉक्स प्रदर्शित करता है जो उपयोगकर्ता से पूछता है कि क्या वे "मार्केटिंग" खोजना चाहते हैं या यहां जाना चाहते हैं https://marketing. यह मामला नहीं हो सकता है, लेकिन कई आईएसपी और सार्वजनिक वाई-फाई प्रदाता प्रत्येक गलत वर्तनी वाले यूआरएल को "हाइजैक" कर लेते हैं, और उपयोगकर्ता को कुछ बैनर-भरे पेज पर रीडायरेक्ट कर देते हैं।

यादृच्छिक पीढ़ी

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

दुर्भाग्य से, नेटवर्क में वह नहीं DNS क्वेरीज़ के परिणाम चुराएं, ये तीन ऑपरेशन आम तौर पर बहुत ऊपर तक बढ़ते हैं, रूट नाम सर्वर तक स्वयं: स्थानीय सर्वर को पता नहीं है कि कैसे हल किया जाए qwajuixk, इसलिए इस अनुरोध को अपने फारवर्डर को अग्रेषित करता है, जो अंततः ऐसा ही करता है a.root-servers.net या उसके किसी "भाई" को यह कहने के लिए बाध्य नहीं किया जाएगा कि "क्षमा करें, लेकिन यह कोई डोमेन नहीं है।"

चूंकि लगभग 1,67*10^21 संभावित नकली डोमेन नाम हैं जिनकी लंबाई सात से पंद्रह अक्षरों तक है, सबसे आम प्रत्येक "ईमानदार" नेटवर्क पर किए गए इन परीक्षणों से, यह रूट सर्वर तक पहुंच जाता है। यह इतना ही होता है आधा क्लस्टर के उस हिस्से के आँकड़ों के अनुसार, रूट डीएनएस पर कुल लोड से root-servers.net, जो वेरीसाइन के स्वामित्व में हैं।

इतिहास खुद को दोहराता है

यह पहली बार नहीं है कि कोई प्रोजेक्ट अच्छे इरादों के साथ बनाया गया है असफल या सार्वजनिक संसाधन को लगभग अनावश्यक ट्रैफ़िक से भर दिया - इसने हमें तुरंत 2000 के दशक के मध्य में डी-लिंक और पॉल-हेनिंग काम्प के एनटीपी (नेटवर्क टाइम प्रोटोकॉल) सर्वर के लंबे और दुखद इतिहास की याद दिला दी।

2005 में, FreeBSD डेवलपर पॉल-हेनिंग, जिनके पास डेनमार्क का एकमात्र स्ट्रैटम 1 नेटवर्क टाइम प्रोटोकॉल सर्वर भी था, को प्रेषित ट्रैफ़िक के लिए एक अप्रत्याशित और बड़ा बिल प्राप्त हुआ। संक्षेप में, इसका कारण यह था कि डी-लिंक डेवलपर्स ने कंपनी के स्विच, राउटर और एक्सेस पॉइंट के फर्मवेयर में कंपा सर्वर सहित स्ट्रैटम 1 एनटीपी सर्वर के पते लिखे थे। इससे कम्पा का सर्वर ट्रैफिक तुरंत नौ गुना बढ़ गया, जिससे डेनिश इंटरनेट एक्सचेंज (डेनमार्क का इंटरनेट एक्सचेंज प्वाइंट) को अपना टैरिफ "फ्री" से "$9 प्रति वर्ष" में बदलना पड़ा।

समस्या यह नहीं थी कि बहुत सारे डी-लिंक राउटर थे, बल्कि समस्या यह थी कि वे "लाइन से बाहर" थे। DNS की तरह, NTP को एक पदानुक्रमित रूप में काम करना चाहिए - स्ट्रैटम 0 सर्वर स्ट्रैटम 1 सर्वर को जानकारी भेजते हैं, जो स्ट्रैटम 2 सर्वर को जानकारी भेजते हैं, और इसी तरह पदानुक्रम के नीचे। एक सामान्य होम राउटर, स्विच, या एक्सेस प्वाइंट जैसे डी-लिंक को एनटीपी सर्वर पते के साथ प्रोग्राम किया गया था जो स्ट्रैटम 2 या स्ट्रैटम 3 सर्वर को अनुरोध भेजेगा।

क्रोमियम परियोजना ने, शायद सबसे अच्छे इरादों के साथ, डीएनएस समस्या में एनटीपी समस्या को दोहराया, इंटरनेट के रूट सर्वर पर उन अनुरोधों को लोड किया जिन्हें उन्हें संभालना ही नहीं था।

जल्द समाधान की उम्मीद है

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

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

विज्ञापन के अधिकार पर

महाकाव्य सर्वर - क्या विंडोज़ पर वी.पी.एस या शक्तिशाली AMD EPYC परिवार प्रोसेसर और बहुत तेज़ Intel NVMe ड्राइव के साथ Linux। ऑर्डर करने के लिए जल्दी करें!

स्रोत: www.habr.com