क्रोमियमच्या वैशिष्ट्यांपैकी एक रूट DNS सर्व्हरवर मोठा भार निर्माण करतो

क्रोमियम ब्राउझर, गुगल क्रोम आणि नवीन मायक्रोसॉफ्ट एजचे समृद्ध ओपन-सोर्स पालक, चांगल्या हेतूने तयार केलेल्या वैशिष्ट्याकडे लक्षणीय नकारात्मक लक्ष वेधले गेले आहे: ते वापरकर्त्याचा ISP अस्तित्वात नसलेल्या डोमेन क्वेरी परिणामांची "चोरी" करत आहे की नाही हे तपासते. .

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

DNS रिझोल्यूशन सामान्यतः कसे केले जाते

.com, .net इ.चे निराकरण करण्यासाठी तुम्ही संपर्क साधण्यासाठी हे सर्व्हर सर्वोच्च अधिकारी आहेत जेणेकरून ते तुम्हाला सांगतील की frglxrtmpuf हे उच्च-स्तरीय डोमेन (TLD) नाही.

DNS, किंवा डोमेन नेम सिस्टम, ही एक प्रणाली आहे ज्याद्वारे संगणक arstechnica.com सारख्या संस्मरणीय डोमेन नावांचे निराकरण 3.128.236.93 सारख्या कमी वापरकर्ता-अनुकूल IP पत्त्यांमध्ये करू शकतात. 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.

Chromium आणि NXDomain चोरी तपासा

Chromium तपासते "हा DNS सर्व्हर मला फसवत आहे का?" Verisign च्या रूट DNS सर्व्हरच्या क्लस्टरपर्यंत पोहोचणाऱ्या सर्व ट्रॅफिकपैकी जवळपास निम्म्या ट्रॅफिकचा वाटा आहे.

Chromium ब्राउझर, Google Chrome चा मूळ प्रकल्प, नवीन Microsoft Edge, आणि असंख्य कमी-ज्ञात ब्राउझर, वापरकर्त्यांना एकाच बॉक्समध्ये शोधण्याची सोय प्रदान करू इच्छितो, ज्याला कधीकधी "ऑम्निबॉक्स" म्हटले जाते. दुसऱ्या शब्दांत, वापरकर्ता ब्राउझर विंडोच्या शीर्षस्थानी समान मजकूर फील्डमध्ये वास्तविक URL आणि शोध इंजिन क्वेरी दोन्ही प्रविष्ट करतो. सरलीकरणाच्या दिशेने आणखी एक पाऊल टाकत, ते वापरकर्त्याला URL चा भाग एंटर करण्यास भाग पाडत नाही http:// किंवा https://.

हे जितके सोयीस्कर आहे, या पद्धतीसाठी ब्राउझरला हे समजून घेणे आवश्यक आहे की URL काय मानले जावे आणि काय शोध क्वेरी मानले जावे. बहुतेक प्रकरणांमध्ये हे अगदी स्पष्ट आहे - उदाहरणार्थ, स्पेस असलेली स्ट्रिंग URL असू शकत नाही. परंतु जेव्हा तुम्ही इंट्रानेटचा विचार करता तेव्हा गोष्टी अधिक अवघड होऊ शकतात-खाजगी नेटवर्क जे वास्तविक वेबसाइटचे निराकरण करण्यासाठी खाजगी उच्च-स्तरीय डोमेन देखील वापरू शकतात.

जर त्यांच्या कंपनीच्या इंट्रानेटवरील वापरकर्त्याने "मार्केटिंग" टाइप केले आणि कंपनीच्या इंट्रानेटमध्ये त्याच नावाची अंतर्गत वेबसाइट असेल, तर Chromium वापरकर्त्याला "मार्केटिंग" शोधू इच्छित आहे की नाही हे विचारणारा माहिती बॉक्स प्रदर्शित करतो. https://marketing. असे होत नाही, परंतु अनेक ISP आणि सार्वजनिक वाय-फाय प्रदाते प्रत्येक चुकीच्या शब्दलेखन URL ला “हायजॅक” करतात, वापरकर्त्याला काही बॅनरने भरलेल्या पृष्ठावर पुनर्निर्देशित करतात.

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

Chromium विकसकांना नियमित नेटवर्कवरील वापरकर्त्यांनी प्रत्येक वेळी एकच शब्द शोधताना त्यांना काय म्हणायचे आहे हे विचारणारा माहिती बॉक्स दिसावा असे वाटत नव्हते, म्हणून त्यांनी एक चाचणी लागू केली: जेव्हा ते ब्राउझर लॉन्च करतात किंवा नेटवर्क बदलतात, तेव्हा Chromium तीन वर DNS लुकअप करते यादृच्छिकपणे व्युत्पन्न केलेले "डोमेन" शीर्ष स्तर, सात ते पंधरा वर्ण लांब. यापैकी कोणत्याही दोन विनंत्या एकाच IP पत्त्यासह परत आल्यास, क्रोमियम असे गृहीत धरतो की स्थानिक नेटवर्क त्रुटी "अपहृत" करत आहे. NXDOMAIN, जे त्याला प्राप्त झाले पाहिजे, म्हणून ब्राउझर पुढील सूचना मिळेपर्यंत प्रविष्ट केलेल्या सर्व एकल-शब्द क्वेरींना शोध प्रयत्न मानतो.

दुर्दैवाने, नेटवर्कमध्ये ते नाही डीएनएस क्वेरीचे परिणाम चोरणे, या तीन ऑपरेशन्स सहसा अगदी शीर्षस्थानी जातात, सर्व मार्ग स्वतः रूट नेम सर्व्हरवर जातात: स्थानिक सर्व्हरला कसे सोडवायचे हे माहित नसते qwajuixk, म्हणून ही विनंती त्याच्या फॉरवर्डरकडे पाठवते, जे शेवटपर्यंत असेच करते a.root-servers.net किंवा त्याच्या "भाऊ" पैकी एकाला "क्षमस्व, परंतु हे डोमेन नाही" असे म्हणण्यास भाग पाडले जाणार नाही.

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

इतिहासाची पुनरावृत्ती होते

सर्वोत्तम हेतूने प्रकल्प तयार करण्याची ही पहिलीच वेळ नाही अयशस्वी किंवा अनावश्यक ट्रॅफिकसह सार्वजनिक संसाधनात जवळजवळ पूर आला - यामुळे 2000 च्या दशकाच्या मध्यात D-Link आणि Poul-Henning Kamp च्या NTP (Network Time Protocol) सर्व्हरच्या दीर्घ आणि दुःखद इतिहासाची लगेच आठवण झाली.

2005 मध्ये, फ्रीबीएसडी डेव्हलपर पॉल-हेनिंग, ज्यांच्याकडे डेन्मार्कचा एकमेव स्ट्रॅटम 1 नेटवर्क टाईम प्रोटोकॉल सर्व्हर होता, त्यांना ट्रान्समिटेड ट्रॅफिकसाठी अनपेक्षित आणि मोठे बिल मिळाले. थोडक्यात, डी-लिंक डेव्हलपर्सनी कंपनीच्या स्विचेस, राउटर आणि ऍक्सेस पॉइंट्सच्या फर्मवेअरमध्ये कॅम्पा सर्व्हरसह स्ट्रॅटम 1 एनटीपी सर्व्हरचे पत्ते लिहिले होते. यामुळे कॅम्पाच्या सर्व्हरची रहदारी तात्काळ नऊ पटीने वाढली, ज्यामुळे डॅनिश इंटरनेट एक्सचेंज (डेनमार्कचा इंटरनेट एक्सचेंज पॉइंट) त्याचे दर "विनामूल्य" वरून "प्रति वर्ष $9" पर्यंत बदलले.

समस्या अशी नव्हती की तेथे बरेच डी-लिंक राउटर होते, परंतु ते "रेषाबाहेर" होते. DNS प्रमाणेच, NTP ने पदानुक्रमित स्वरूपात कार्य केले पाहिजे - स्ट्रॅटम 0 सर्व्हर स्ट्रॅटम 1 सर्व्हरला माहिती देतात, जे स्ट्रॅटम 2 सर्व्हरला माहिती देतात आणि त्याचप्रमाणे पदानुक्रम खाली करतात. एक सामान्य होम राउटर, स्विच किंवा ऍक्सेस पॉईंट जसे की D-Link ने NTP सर्व्हर पत्त्यांसह प्रोग्राम केलेला आहे तो स्ट्रॅटम 2 किंवा स्ट्रॅटम 3 सर्व्हरला विनंती पाठवेल.

Chromium प्रकल्पाने, कदाचित सर्वोत्तम हेतूने, DNS समस्येमध्ये NTP समस्येची प्रतिकृती बनवली आहे, इंटरनेटचे रूट सर्व्हर अशा विनंत्यांसह लोड करत आहे ज्यांना ते हाताळण्यासाठी कधीच नव्हते.

यावर लवकर तोडगा निघण्याची आशा आहे

Chromium प्रकल्पात एक मुक्त स्रोत आहे किडा, ज्यासाठी या समस्येचे निराकरण करण्यासाठी डीफॉल्टनुसार इंट्रानेट रीडायरेक्ट डिटेक्टर अक्षम करणे आवश्यक आहे. आम्ही Chromium प्रकल्पाला श्रेय दिले पाहिजे: दोष आढळला त्यापूर्वीVerisign च्या मॅट थॉमसने त्याच्याकडे कसे लक्ष वेधले उपवास APNIC ब्लॉगवर. बग जूनमध्ये शोधला गेला, परंतु थॉमसच्या पोस्टपर्यंत तो विसरला गेला; उपोषण केल्यावर त्याच्या जवळच्या देखरेखीखाली राहू लागला.

ही समस्या लवकरच सोडवली जाईल अशी आशा आहे आणि रूट DNS सर्व्हरना यापुढे दररोज अंदाजे 60 अब्ज बोगस प्रश्नांना प्रतिसाद द्यावा लागणार नाही.

जाहिरातींच्या अधिकारांवर

एपिक सर्व्हर - हे आहे Windows वर VPS किंवा शक्तिशाली AMD EPYC फॅमिली प्रोसेसर आणि अतिशय वेगवान Intel NVMe ड्राइव्हसह लिनक्स. ऑर्डर करण्यासाठी त्वरा करा!

स्त्रोत: www.habr.com