क्रोमियमको एक विशेषताले रूट DNS सर्भरहरूमा ठूलो भार सिर्जना गर्दछ

क्रोमियम ब्राउजर, गुगल क्रोम र नयाँ माइक्रोसफ्ट एजको समृद्ध खुला स्रोत अभिभावक, राम्रो उद्देश्यका साथ अभिप्रेरित सुविधाको लागि महत्त्वपूर्ण नकारात्मक ध्यान प्राप्त गरेको छ: यसले प्रयोगकर्ताको ISP गैर-अस्तित्वपूर्ण डोमेन क्वेरी परिणामहरू "चोरी" गरिरहेको छ कि छैन भनेर जाँच गर्दछ। ।

इन्ट्रानेट रिडिरेक्ट डिटेक्टर, जसले सांख्यिकीय रूपमा अवस्थित हुन नसक्ने अनियमित "डोमेनहरू" को लागि नक्कली प्रश्नहरू सिर्जना गर्दछ, विश्वव्यापी रूट DNS सर्भरहरू द्वारा प्राप्त कुल ट्राफिकको लगभग आधाको लागि जिम्मेवार छ। भेरिसाइन इन्जिनियर म्याट थोमसले लामो लेखे पोस्ट APNIC ब्लगमा समस्या वर्णन गर्दै र यसको स्केल मूल्याङ्कन गर्दै।

कसरी DNS रिजोलुसन सामान्यतया प्रदर्शन गरिन्छ

यी सर्भरहरू तपाईंले .com, .net, इत्यादि समाधान गर्नका लागि सम्पर्क गर्नु पर्ने सर्वोच्च अख्तियार हो जसले गर्दा तिनीहरूले तपाईंलाई frglxrtmpuf शीर्ष-स्तर डोमेन (TLD) होइन भनी बताउनेछन्।

DNS, वा डोमेन नाम प्रणाली, एउटा प्रणाली हो जसद्वारा कम्प्युटरहरूले 3.128.236.93 जस्ता धेरै कम प्रयोगकर्ता-अनुकूल IP ठेगानाहरूमा arstechnica.com जस्ता यादगार डोमेन नामहरू समाधान गर्न सक्छन्। DNS बिना, इन्टरनेट मानवहरूले प्रयोग गर्न सक्ने तरिकामा अवस्थित हुँदैन, यसको मतलब माथिल्लो-स्तरको पूर्वाधारमा अनावश्यक लोड वास्तविक समस्या हो।

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

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

यो कति पटक हुन्छ?

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

यदि न त स्थानीय प्रदायकको DNS सर्भर न त यसको कन्फिगरेसनमा निर्दिष्ट गरिएको "फर्वार्डिङ सर्भरहरू" सँग क्यास प्रतिक्रिया छ भने, अनुरोध सीधै आधिकारिक डोमेन सर्भरमा उठाइन्छ। उच्च जसलाई तपाईले रूपान्तरण गर्न खोज्दै हुनुहुन्छ। कहिले домен.com यसको मतलब यो हो कि अनुरोध डोमेनको आधिकारिक सर्भरहरूमा पठाइन्छ com, जुन मा अवस्थित छन् gtld-servers.net.

सिस्टम gtld-servers, जसमा अनुरोध गरिएको थियो, डोमेन domain.com को लागि आधिकारिक नाम सर्भरहरूको सूचीको साथ प्रतिक्रिया दिन्छ, साथै कम्तिमा एउटा लिङ्क रेकर्ड समावेश गर्दछ जसमा एउटा यस्तो नाम सर्भरको IP ठेगाना समावेश छ। त्यसपछि, प्रतिक्रियाहरू चेन तल जान्छन् - प्रत्येक फर्वार्डरले तिनीहरूलाई अनुरोध गरेको सर्भरमा यी प्रतिक्रियाहरू पास गर्दछ, जबसम्म प्रतिक्रिया अन्ततः स्थानीय प्रदायकको सर्भर र प्रयोगकर्ताको कम्प्युटरमा पुग्दैन। ती सबैले यो प्रतिक्रियालाई क्यास गर्छन् ताकि उच्च-स्तर प्रणालीहरूलाई अनावश्यक रूपमा बाधा नपरोस्।

धेरै जसो अवस्थामा, नाम सर्भरको लागि रेकर्ड domain.com यी फर्वार्डरहरू मध्ये एकमा पहिले नै क्यास गरिनेछ, त्यसैले रूट सर्भरहरू बाधा पर्ने छैनन्। यद्यपि, अहिलेको लागि हामी परिचित URL को प्रकारको बारेमा कुरा गर्दैछौं - जुन नियमित वेबसाइटमा रूपान्तरण हुन्छ। Chrome अनुरोधहरू स्तरमा छन् उच्च यो, क्लस्टरहरू आफैंको चरणमा root-servers.net.

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

Chromium जाँच गर्दछ "के यो DNS सर्भरले मलाई मूर्ख बनाइरहेको छ?" Verisign को रूट DNS सर्भरहरूको क्लस्टरमा पुग्ने सबै ट्राफिकको लगभग आधाको लागि खाता।

क्रोमियम ब्राउजर, गुगल क्रोमको मूल परियोजना, नयाँ माइक्रोसफ्ट एज, र अनगिन्ती कम ज्ञात ब्राउजरहरू, प्रयोगकर्ताहरूलाई एकल बाकसमा खोजी गर्न सजिलो प्रदान गर्न चाहन्छ, कहिलेकाहीँ "ओम्निबक्स" भनिन्छ। अन्य शब्दहरूमा, प्रयोगकर्ताले ब्राउजर विन्डोको शीर्षमा एउटै पाठ क्षेत्रमा वास्तविक URL र खोज इन्जिन क्वेरीहरू दुवै प्रविष्ट गर्दछ। सरलीकरण तर्फ अर्को कदम चाल्दै, यसले प्रयोगकर्तालाई URL को अंश प्रविष्ट गर्न बाध्य पार्दैन http:// वा https://.

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

यदि कुनै प्रयोगकर्ताले आफ्नो कम्पनीको इन्ट्रानेटमा "मार्केटिंग" टाइप गर्छ र कम्पनीको इन्ट्रानेटमा उही नामको आन्तरिक वेबसाइट छ भने, क्रोमियमले प्रयोगकर्तालाई "मार्केटिंग" खोज्न चाहनुहुन्छ वा जान चाहनुहुन्छ भनेर सोध्ने जानकारी बाकस देखाउँछ। https://marketing। यो मामला नहुन सक्छ, तर धेरै ISP र सार्वजनिक Wi-Fi प्रदायकहरूले प्रत्येक गलत हिज्जे URL "हाइज्याक" गर्छन्, प्रयोगकर्तालाई केही ब्यानर भरिएको पृष्ठमा रिडिरेक्ट गर्दै।

अनियमित पुस्ता

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

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

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

ईतिहास आफै दोहोरिन्छ

यो पहिलो पटक होइन कि एक राम्रो इरादा संग बनाईएको परियोजना हो असफल वा अनावश्यक ट्राफिकको साथ लगभग सार्वजनिक स्रोत बाढी - यसले तुरुन्तै हामीलाई D-Link र Poul-Henning Kamp को NTP (नेटवर्क टाइम प्रोटोकल) सर्भरको 2000 को मध्यमा लामो र दुखद इतिहासको सम्झना गराउँदछ।

2005 मा, FreeBSD विकासकर्ता Poul-Henning, जसले डेनमार्कको एकमात्र स्ट्र्याटम 1 नेटवर्क टाइम प्रोटोकल सर्भरको पनि स्वामित्व लिएका थिए, ट्रान्समिटेड ट्राफिकको लागि अप्रत्याशित र ठूलो बिल प्राप्त गरे। छोटकरीमा, कारण यो थियो कि D-Link विकासकर्ताहरूले स्ट्र्याटम 1 NTP सर्भरहरू, काम्पा सर्भर सहित, कम्पनीको स्विच, राउटरहरू र पहुँच बिन्दुहरूको फर्मवेयरमा ठेगानाहरू लेखेका थिए। यसले तुरुन्तै काम्पाको सर्भर ट्राफिक नौ गुणा बढायो, जसले गर्दा डेनिस इन्टरनेट एक्सचेन्ज (डेनमार्कको इन्टरनेट एक्सचेन्ज पोइन्ट) ले आफ्नो शुल्क "नि:शुल्क" बाट "$ 9 प्रति वर्ष" मा परिवर्तन गर्यो।

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

क्रोमियम परियोजनाले, सम्भवतः सबै भन्दा राम्रो उद्देश्यका साथ, DNS समस्यामा NTP समस्याको नक्कल गर्‍यो, इन्टरनेटको रूट सर्भरहरूलाई अनुरोधहरूको साथ लोड गर्दै तिनीहरूले कहिल्यै ह्यान्डल गर्न खोजेका थिएनन्।

छिट्टै समाधानको आशा छ

क्रोमियम परियोजनामा ​​खुला स्रोत छ बग, जसलाई यो समस्या समाधान गर्न पूर्वनिर्धारित रूपमा इन्ट्रानेट रिडिरेक्ट डिटेक्टर असक्षम गर्न आवश्यक छ। हामीले क्रोमियम परियोजनालाई क्रेडिट दिनै पर्छ: बग फेला पर्यो त्यो भन्दा पहिलेकसरी Verisign's Matt Thomas ले उहाँलाई आफ्नो साथ धेरै ध्यान ल्याए उपवास APNIC ब्लगमा। यो बग जुनमा फेला परेको थियो, तर थोमसको पोस्ट सम्म बिर्सिएको थियो; उपवास बसेपछि उनी नजिकको निगरानीमा हुन थाले ।

यो आशा छ कि समस्या चाँडै समाधान हुनेछ, र रूट DNS सर्भरहरूले हरेक दिन अनुमानित 60 बिलियन बोगस प्रश्नहरूको जवाफ दिनु पर्दैन।

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

एपिक सर्भरहरू हो विन्डोजमा VPS वा शक्तिशाली AMD EPYC परिवार प्रोसेसर र धेरै छिटो Intel NVMe ड्राइभहरूको साथ लिनक्स। अर्डर गर्न हतार गर्नुहोस्!

स्रोत: www.habr.com