تلقى متصفح Chromium، وهو الأصل المزدهر مفتوح المصدر لـ Google Chrome وMicrosoft Edge الجديد، اهتمامًا سلبيًا كبيرًا لميزة تم تصميمها بحسن نية: فهي تتحقق مما إذا كان مزود خدمة الإنترنت الخاص بالمستخدم "يسرق" نتائج استعلام المجال غير الموجودة .
، الذي ينشئ استعلامات زائفة عن "نطاقات" عشوائية من غير المرجح وجودها إحصائيًا، هو المسؤول عن ما يقرب من نصف إجمالي حركة المرور التي تستقبلها خوادم DNS الجذرية في جميع أنحاء العالم. كتب مهندس Verisign Matt Thomas مقالًا مطولاً على مدونة APNIC التي تصف المشكلة وتقيم حجمها.
كيف يتم عادةً تنفيذ تحليل DNS
هذه الخوادم هي أعلى سلطة يجب عليك الاتصال بها لحل .com، و.net، وما إلى ذلك، حتى تخبرك بأن frglxrtmpuf ليس نطاق المستوى الأعلى (TLD).
DNS، أو نظام اسم المجال، هو نظام يمكن لأجهزة الكمبيوتر من خلاله تحويل أسماء النطاقات التي لا يمكن تذكرها مثل arstechnica.com إلى عناوين IP أقل سهولة في الاستخدام مثل 3.128.236.93. بدون DNS، لن يكون الإنترنت موجودًا بطريقة يمكن للبشر استخدامها، مما يعني أن التحميل غير الضروري على البنية التحتية ذات المستوى الأعلى يمثل مشكلة حقيقية.
يمكن أن يتطلب تحميل صفحة ويب حديثة واحدة عددًا لا يصدق من عمليات البحث عن نظام أسماء النطاقات (DNS). على سبيل المثال، عندما قمنا بتحليل الصفحة الرئيسية لـ ESPN، أحصينا 93 اسم نطاق منفصل، تتراوح من a.espncdn.com إلى z.motads.com. كل منهم ضروري لتحميل الصفحة بالكامل!
لاستيعاب هذا النوع من عبء العمل لمحرك البحث الذي يحتاج إلى خدمة العالم بأسره، تم تصميم DNS كتسلسل هرمي متعدد المستويات. في الجزء العلوي من هذا الهرم توجد خوادم الجذر - كل نطاق من المستوى الأعلى، مثل .com، لديه عائلة خاصة به من الخوادم التي تمثل أعلى سلطة لكل نطاق أسفلها. خطوة واحدة للأعلى هؤلاء الخوادم هي خوادم الجذر نفسها، من a.root-servers.net إلى m.root-servers.net.
كم مرة يحدث هذا؟
بفضل التسلسل الهرمي للتخزين المؤقت متعدد المستويات للبنية التحتية لنظام DNS، تصل نسبة صغيرة جدًا من استعلامات DNS في العالم إلى خوادم الجذر. يحصل معظم الأشخاص على معلومات محلل DNS الخاصة بهم مباشرة من مزود خدمة الإنترنت الخاص بهم. عندما يحتاج جهاز المستخدم إلى معرفة كيفية الوصول إلى موقع ويب معين، يتم إرسال الطلب أولاً إلى خادم DNS الذي يديره هذا الموفر المحلي. إذا كان خادم DNS المحلي لا يعرف الإجابة، فإنه يعيد توجيه الطلب إلى "معيدي التوجيه" الخاصين به (إذا تم تحديده).
إذا لم يكن لدى خادم DNS الخاص بالموفر المحلي ولا "خوادم إعادة التوجيه" المحددة في تكوينها استجابة مخزنة مؤقتًا، فسيتم رفع الطلب مباشرة إلى خادم المجال المعتمد فوق الذي تحاول تحويله. متى домен.com وهذا يعني أن الطلب يتم إرساله إلى الخوادم المعتمدة للمجال نفسه com، والتي تقع في gtld-servers.net.
نظام gtld-servers، الذي تم تقديم الطلب إليه، يستجيب بقائمة من خوادم الأسماء الموثوقة للنطاق domain.com، بالإضافة إلى سجل ارتباط واحد على الأقل يحتوي على عنوان IP لأحد خوادم الأسماء هذه. بعد ذلك، تنتقل الاستجابات إلى أسفل السلسلة - يقوم كل معيد توجيه بتمرير هذه الاستجابات إلى الخادم الذي طلبها، حتى تصل الاستجابة أخيرًا إلى خادم الموفر المحلي وجهاز الكمبيوتر الخاص بالمستخدم. جميعهم يقومون بتخزين هذه الاستجابة مؤقتًا حتى لا يزعجوا الأنظمة ذات المستوى الأعلى دون داعٍ.
في معظم الحالات، يسجل خادم الأسماء لـ domain.com سيتم بالفعل تخزينها مؤقتًا على أحد معيدي التوجيه، لذلك لن يتم إزعاج خوادم الجذر. ومع ذلك، فإننا نتحدث حاليًا عن نوع عنوان URL الذي نعرفه - وهو الذي يتم تحويله إلى موقع ويب عادي. طلبات Chrome في المستوى فوق هذا، على خطوة العناقيد نفسها root-servers.net.
التحقق من سرقة Chromium وNXDomain
يتحقق Chromium من السؤال "هل يخدعني خادم DNS هذا؟" يمثل ما يقرب من نصف إجمالي حركة المرور التي تصل إلى مجموعة خوادم DNS الجذرية الخاصة بشركة Verisign.
يريد متصفح Chromium، والمشروع الأصلي لـ Google Chrome، وMicrosoft Edge الجديد، وعدد لا يحصى من المتصفحات الأقل شهرة، أن يوفر للمستخدمين سهولة البحث في مربع واحد، يسمى أحيانًا "Omnibox". بمعنى آخر، يقوم المستخدم بإدخال كل من عناوين URL الحقيقية واستعلامات محرك البحث في نفس حقل النص أعلى نافذة المتصفح. من خلال اتخاذ خطوة أخرى نحو التبسيط، فهي أيضًا لا تجبر المستخدم على إدخال جزء من عنوان URL به http:// أو https://.
وبقدر سهولة هذا الأسلوب، يتطلب هذا الأسلوب من المتصفح أن يفهم ما ينبغي اعتباره عنوان URL وما ينبغي اعتباره استعلام بحث. يكون هذا واضحًا جدًا في معظم الحالات - على سبيل المثال، لا يمكن أن تكون السلسلة التي تحتوي على مسافات عنوان URL. لكن الأمور يمكن أن تصبح أكثر تعقيدًا عندما تفكر في شبكات الإنترانت، وهي شبكات خاصة يمكنها أيضًا استخدام نطاقات المستوى الأعلى الخاصة لحل مواقع الويب الحقيقية.
إذا قام أحد المستخدمين على الشبكة الداخلية لشركته بكتابة كلمة "تسويق" وكان لدى شبكة الإنترانت الخاصة بالشركة موقع ويب داخلي يحمل نفس الاسم، فسيعرض Chromium مربع معلومات يسأل المستخدم عما إذا كان يريد البحث عن "تسويق" أو الانتقال إلى https://marketing. قد لا يكون هذا هو الحال، ولكن العديد من مزودي خدمة الإنترنت وموفري خدمة الواي فاي العامة "يختطفون" كل عنوان URL به خطأ إملائي، ويعيدون توجيه المستخدم إلى صفحة مليئة بالشعارات.
جيل عشوائي
لم يرغب مطورو Chromium في أن يرى المستخدمون على الشبكات العادية مربع معلومات يسألهم عما يقصدونه في كل مرة يبحثون فيها عن كلمة واحدة، لذلك أجروا اختبارًا: عندما يقومون بتشغيل متصفح أو تغيير الشبكات، يقوم Chromium بإجراء عمليات بحث DNS على ثلاثة المستوى الأعلى لـ "المجالات" التي يتم إنشاؤها عشوائيًا، يتراوح طوله من سبعة إلى خمسة عشر حرفًا. إذا عاد أي اثنين من هذه الطلبات بنفس عنوان IP، فسيفترض Chromium أن الشبكة المحلية "تختطف" الأخطاء NXDOMAIN، والتي يجب أن يتلقاها، لذلك يعتبر المتصفح أن جميع الاستعلامات المكونة من كلمة واحدة التي تم إدخالها هي محاولات بحث حتى إشعار آخر.
لسوء الحظ، في الشبكات التي لا سرقة نتائج استعلامات DNS، عادةً ما ترتفع هذه العمليات الثلاث إلى القمة، وصولاً إلى خوادم الأسماء الجذرية نفسها: لا يعرف الخادم المحلي كيفية حلها qwajuixk، لذا يعيد توجيه هذا الطلب إلى معيد التوجيه الخاص به، والذي يفعل الشيء نفسه، حتى النهاية a.root-servers.net أو لن يضطر أحد "إخوته" إلى قول "آسف، لكن هذا ليس مجالًا".
نظرًا لوجود ما يقرب من 1,67*10^21 من أسماء النطاقات المزيفة المحتملة التي يتراوح طولها من سبعة إلى خمسة عشر حرفًا، فإن الأكثر شيوعًا هو كل ومن هذه الاختبارات التي يتم إجراؤها على الشبكة "الصادقة"، يصل إلى خادم الجذر. هذا يصل إلى حد كبير نصف من إجمالي الحمل على DNS الجذر، وفقًا لإحصائيات ذلك الجزء من المجموعات root-servers.net، المملوكة لشركة Verisign.
التاريخ يعيد نفسه
ليست هذه هي المرة الأولى التي يتم فيها إنشاء مشروع بأفضل النوايا أو كاد أن يغمر موردًا عامًا بحركة مرور غير ضرورية - وهذا يذكرنا على الفور بالتاريخ الطويل والمحزن لخادم D-Link وخادم NTP (بروتوكول وقت الشبكة) الخاص بـ Poul-Henning Kamp في منتصف العقد الأول من القرن الحادي والعشرين.
في عام 2005، تلقى مطور FreeBSD Poul-Henning، الذي كان يمتلك أيضًا خادم Stratum 1 Network Time Protocol الوحيد في الدنمارك، فاتورة كبيرة وغير متوقعة مقابل حركة المرور المنقولة. باختصار، كان السبب هو أن مطوري D-Link كتبوا عناوين خوادم Stratum 1 NTP، بما في ذلك خادم Kampa، في البرامج الثابتة لخط المحولات وأجهزة التوجيه ونقاط الوصول الخاصة بالشركة. أدى هذا على الفور إلى زيادة حركة مرور خادم Kampa تسعة أضعاف، مما دفع بورصة الإنترنت الدنماركية (نقطة تبادل الإنترنت الدنماركية) إلى تغيير تعريفتها من "مجاني" إلى "9 دولار سنويًا".
لم تكن المشكلة في وجود عدد كبير جدًا من أجهزة توجيه D-Link، بل في أنها كانت "خارج الخط". كما هو الحال مع DNS، يجب أن يعمل NTP في شكل هرمي - حيث تقوم خوادم الطبقة 0 بتمرير المعلومات إلى خوادم الطبقة 1، والتي تقوم بتمرير المعلومات إلى خوادم الطبقة 2، وهكذا أسفل التسلسل الهرمي. سيرسل جهاز التوجيه أو المحول أو نقطة الوصول المنزلية النموذجية مثل جهاز D-Link الذي تمت برمجته باستخدام عناوين خادم NTP طلبات إلى خادم Stratum 2 أو Stratum 3.
ربما قام مشروع Chromium، بنوايا حسنة، بتكرار مشكلة NTP في مشكلة DNS، مما أدى إلى تحميل خوادم الجذر للإنترنت بطلبات لم يكن من المفترض أن تتعامل معها مطلقًا.
هناك أمل في التوصل إلى حل سريع
مشروع Chromium مفتوح المصدر ، الأمر الذي يتطلب تعطيل Intranet Redirect Detector بشكل افتراضي لحل هذه المشكلة. يجب أن ننسب الفضل إلى مشروع Chromium: تم العثور على الخطأ قبلكيف جلب مات توماس من Verisign الكثير من الاهتمام من خلاله على مدونة APNIC. تم اكتشاف الخطأ في يونيو، لكنه ظل منسيًا حتى مشاركة توماس؛ وبعد الصيام، بدأ يخضع للمراقبة الدقيقة.
ومن المأمول أن يتم حل المشكلة قريبًا، ولن تضطر خوادم DNS الجذرية بعد الآن إلى الرد على ما يقدر بنحو 60 مليار استفسار زائف كل يوم.
كإعلان
خوادم ملحمية - هو أو Linux مع معالجات عائلة AMD EPYC القوية ومحركات Intel NVMe فائقة السرعة. اسرع للطلب!
المصدر: www.habr.com