مزايا الأمان

مقدمة: تهديدات أمان نظام أسماء النطاقات وإجراءات التخفيف

نظرًا للتصميم المفتوح والتوزيع لنظام أسماء النطاقات، واستخدامه لبروتوكول المستخدم لمخطّط البيانات (UDP)، يكون نظام أسماء النطاقات عرضة لأشكال مختلفة من الهجمات. تشكّل برامج تعيين نظام أسماء النطاقات المتكررة أو العامة، أو "الاقتباس" عرضة للخطر على وجه الخصوص، لأنها لا تقيّد حِزم البيانات الواردة بمجموعة من عناوين IP المصدر المسموح بها. في الغالب، لدينا نوعان من الهجمات الشائعة:

• هجمات الانتحال تؤدي إلى تسمم ذاكرة التخزين المؤقت لنظام أسماء النطاقات هناك أنواع مختلفة من انتحال نظام أسماء النطاقات وتزويره يزخر بالمحتوى الذي يهدف إلى إعادة توجيه المستخدمين من مواقع إلكترونية شرعية إلى مواقع إلكترونية ضارة. ويشمل ذلك ما يُعرف باسم هجمات Kaminsky، التي يتحكم فيها المهاجمون في منطقة موثوق بها لنظام أسماء النطاقات بالكامل.
• هجمات رفض الخدمة (DoS). قد يشغّل المهاجمون هجمات حجب الخدمة (DDoS) ضد برامج التعيين نفسها، أو تمكّنهم من اختراق هجمات إيقاف الخدمة (DoS) على الأنظمة الأخرى. تُعرف الهجمات التي تستخدم خوادم نظام أسماء النطاقات لبدء هجمات DoS على أنظمة أخرى من خلال الاستفادة من حجم سجلّ نظام أسماء النطاقات/الاستجابة الكبير باسم هجمات التضخيم.

وفي ما يلي مناقشة لكل فئة من الهجمات.

هجمات تسمم ذاكرة التخزين المؤقت

هناك العديد من هجمات انتحال نظام أسماء النطاقات التي يمكن أن تؤدي إلى تسمم ذاكرة التخزين المؤقت، ولكن السيناريو العام هو كما يلي:

1. يرسل المهاجم إلى برنامج تعيين نظام أسماء نطاقات مستهدف طلبات بحث متعددة لاسم نطاق يدرك أن الخادم غير موثوق به، ومن غير المحتمل أن يكون في ذاكرة التخزين المؤقت للخادم.
2. ترسل أداة التعيين طلبات إلى خوادم الأسماء الأخرى (التي يمكن أن يتوقعها المهاجم أيضًا).
3. في هذه الأثناء، يملأ المهاجم خادم الضحايا باستجابات زائفة يبدو أنها تنشأ من خادم الأسماء المفوّض. تحتوي الردود على سجلات تحلّل النطاق المطلوب في النهاية إلى عناوين IP التي يتحكم فيها المهاجم. قد تحتوي السجلات على سجلّات للاسم الذي تم حلّه، أو أسوأ من ذلك، قد تفوّض تفويضًا إلى خادم أسماء يمتلكه المهاجم لكي يتمكّن من التحكّم في منطقة بأكملها.
4. إذا كانت إحدى الردود المزيفة تتطابق مع طلب برنامج التعيين (على سبيل المثال، حسب اسم طلب البحث والنوع والمعرّف ومنفذ مصدر برنامج التعيين) وتلقّتها قبل رد من خادم الأسماء الحقيقي، تقبل أداة الحلّ الرد المزيّف وتخزّنه مؤقتًا وتتجاهل الاستجابة الحقيقية.
5. يتم الرد على طلبات البحث المستقبلية للنطاق أو المنطقة المخترَقة باستخدام درجات دقة نظام أسماء النطاقات المزيفة من ذاكرة التخزين المؤقت. إذا حدَّد المهاجم مدة طويلة جدًا للاستجابة المُزيَّفة، ستظل السجلّات المزيفة في ذاكرة التخزين المؤقت لأطول فترة ممكنة بدون إعادة تحميلها.

للحصول على مقدمة ممتازة عن هجمات Kaminsky، يمكنك الاطّلاع على دليل توضيحي حول الثغرة الأمنية في نظام أسماء النطاقات Kaminsky.

هجمات تضخيم الإجراءات وتضخيمها

تخضع برامج تعيين نظام أسماء النطاقات لتهديدات DoS المعتادة التي تصيب أي نظام شبكة. ومع ذلك، فإن هجمات التضخيم هي مصدر قلق خاص لأن برامج تعيين نظام أسماء النطاقات هي أهداف جذابة للمهاجمين الذين يستغلون برامج التعيين. إن برامج التعيين التي تتوافق مع EDNS0 (آليات الإضافة لنظام أسماء النطاقات) تكون عرضة للثغرة الأمنية بشكل خاص بسبب حجم الحزمة الأكبر الذي يمكنها عرضها.

في سيناريو التضخيم، تتم متابعة الهجوم على النحو التالي:

1. يرسل المهاجم طلبات بحث عن نظام أسماء النطاقات للضحية باستخدام عنوان IP مصدري مزور. قد يتم إرسال طلبات البحث من نظام واحد أو من شبكة من الأنظمة تستخدم عنوان IP المزيف نفسه. تُستخدَم طلبات البحث في السجلّات التي يعرفها المهاجم، ما يؤدي إلى الحصول على ردود أكبر بكثير تصل إلى عدة عشرات¹ حجم طلبات البحث الأصلية (بعبارة أخرى، الاسم الهجومي ";;ampamp"quot;؟؟).
2. يرسل خادم الضحية الردود الكبيرة إلى عنوان IP المصدر الذي تم تمريره في الطلبات المزيَّفة، مما يؤدي إلى إرباك النظام ويتسبب في حدوث حالة DoS.

التخفيفات

والحلّ العادي على مستوى النظام في الثغرات الأمنية لنظام أسماء النطاقات هو DNSSEC. ومع ذلك، فإن برامج تعيين نظام أسماء النطاقات المفتوحة يجب أن تتخذ بشكل مستقل بعض الإجراءات للتخفيف من التهديدات المعروفة، وذلك إلى أن يتم تنفيذها بشكل عام. تم اقتراح العديد من الأساليب، راجِع IETF RFC 5452: إجراءات لجعل نظام أسماء النطاقات أكثر مرونة مقارنة بالإجابات المزيفة للحصول على نظرة عامة على معظمها. في نظام أسماء النطاقات العام من Google، طبّقنا الأساليب التالية، وننصحك بما يلي:

• تأمين الرمز من تجاوز الفراغات، وخاصةً الرمز المسؤول عن تحليل رسائل نظام أسماء النطاقات وتسلسلها.
• توفير المتطلبات اللازمة لموارد الجهاز للحماية من هجمات DoS المباشرة على برامج التعيين نفسها. وبما أنّ عناوين IP تصعب على المهاجمين تزييفها، فإنه من المستحيل حظر طلبات البحث استنادًا إلى عنوان IP أو الشبكة الفرعية، والطريقة الوحيدة للتعامل مع هذه الهجمات هي ببساطة استيعاب التحميل.
• تنفيذ التحقّق من الصحة الأساسية لحِزم الاستجابة ومصداقية خادم الأسماء، للحماية من تسمم ذاكرة التخزين المؤقت البسيطة وتُعد هذه آليات عادية وعمليات تحقق من حيث السلامة يجب أن ينفذها أي برنامج تعيين للتخزين المؤقت متوافق مع المعايير.
• إضافة التحقّق إلى طلب الرسائل للحدّ من احتمالية حدوث هجمات أكثر تعقيدًا من الانتحال/ذاكرة التخزين المؤقت، مثل هجمات "كامينسكي" هناك العديد من الأساليب المقترحة لإضافة إنتروبيا. يمكنك الاطّلاع أدناه على نظرة عامة على مزايا كل تقنية من هذه الأساليب والقيود المفروضة عليها وتحدياتها، وسنناقش كيفية تنفيذها في نظام أسماء النطاقات العام من Google.
• إزالة طلبات البحث المكرّرة لمكافحة احتمالات الهجمات
• طلبات تقييد المُعدَّل لمنع هجمات حجب الخدمة (DoS) وهجمات التضخيم.
• مراقبة الخدمة لعناوين IP للعميل باستخدام أكبر معدل نقل بيانات وخوض أعلى نسبة حجم للاستجابة إلى الطلب.

ملحقات أمان نظام أسماء النطاقات (DNSSEC)

يتم تحديد معيار "ملحقات أمان اسم النطاق" (DNSSEC) في عدة معايير لRFC IETF: 4033 و4034 و4035 و5155.

برامج التعيين التي تنفّذ هجمات التسمم في ذاكرة التخزين المؤقت المضادة لـ DNSSEC عن طريق التحقّق من صحة الردود الواردة من خوادم الأسماء وتحتفظ كل منطقة بنظام أسماء النطاقات بمجموعة من مفاتيح التشفير الخاصة/المتاحة لكل سجلّ لنظام أسماء النطاقات. ويتم إنشاء وتوقيع توقيع رقمي فريد باستخدام المفتاح الخاص. وتتم بعد ذلك مصادقة المفتاح العام المقابل من خلال سلسلة من الثقة بواسطة المفاتيح التي تنتمي إلى المناطق الرئيسية. ترفض برامج التعيين المتوافقة مع DNSSEC الاستجابات التي لا تحتوي على التوقيعات الصحيحة. تمنع ملحقات أمان نظام أسماء النطاقات (DNSSEC) فعالية العبث بها، لأنه من الناحية العملية، يستحيل تقريبًا تزييف التوقيعات بدون الوصول إلى المفاتيح الخاصة.

اعتبارًا من كانون الثاني (يناير) 2013، أصبح "نظام أسماء النطاقات العام" من Google متوافقًا بالكامل مع ملحقات أمان نظام أسماء النطاقات (DNSSEC). نقبل الرسائل بتنسيق DNSSEC وإعادة توجيهها ونتحقّق من الردود للمصادقة الصحيحة. ونشجّع بقوة برامج التعيين الأخرى على القيام بنفس الإجراء.

ونخزّن أيضًا ردود NSEC مؤقتًا على النحو المحدّد في IETF RFC 8198: الاستخدام القوي لذاكرة التخزين المؤقت التي تم التحقق من صحتها باستخدام DNSSEC. ويمكن أن يؤدي ذلك إلى تقليل طلبات NXDOMAIN إلى خوادم الأسماء التي تنفِّذ DNSSEC واستخدام NSEC للإجابات السلبية.

عمليات النقل المشفّرة من جهة العميل

يتيح "نظام أسماء النطاقات العام من Google" استخدام بروتوكولات النقل المشفّرة، ونظام أسماء النطاقات عبر HTTPS ونظام أسماء النطاقات عبر طبقة النقل الآمنة. تمنع هذه البروتوكولات العبث والتنصت والانتحال وتحسين الخصوصية والأمان بشكل كبير بين العميل ونظام أسماء النطاقات العام من Google. كما أنها تُكمِّل ملحقات أمان نظام أسماء النطاقات (DNSSEC) لتقديم عمليات بحث نظام أسماء النطاقات الشاملة التي تمت مصادقتها.

تنفيذ التحقّق من الصلاحية الأساسية

قد يرجع سبب تلف ذاكرة التخزين المؤقت لنظام أسماء النطاقات إلى عدم التطابق، وليس بالضرورة، ضارًا بين الطلبات والاستجابات (على سبيل المثال، بسبب خادم أسماء تم ضبطه بشكل غير صحيح، وخطأ في برنامج نظام أسماء النطاقات، وما إلى ذلك). وعلى الأقل، يجب أن تضع برامج تعيين نظام أسماء النطاقات عمليات تحقق للتحقق من مصداقية خوادم الأسماء ومدى صلتها بموضوع البحث. ننصحك (وتنفيذ) كل الإجراءات الدفاعية التالية:

• لا تكرِّر وحدة التكرار في الطلبات الصادرة، وتتبَّع دائمًا سلاسل التفويض صراحةً. ويضمن إيقاف وحدة التكرار المتكررة أن برنامج الحلّ الذي تستخدمه في وضع "it;iterative" بحيث يمكنك إجراء طلب بحث لكل خادم أسماء في سلسلة التفويض بشكل صريح، بدلاً من السماح لخادم أسماء آخر بتنفيذ طلبات البحث هذه نيابةً عنك.
• رفض رسائل الاستجابة المريبة راجِع القسم أدناه للاطّلاع على تفاصيل حول ما نعتبره "مشبوه&quot.
• لا تعرض سجلّات A للعملاء استنادًا إلى السجلّات الملتصقة التي تمّ تخزينها في الطلبات السابقة. على سبيل المثال، إذا تلقّيت طلب بحث عميل عن ns1.example.com، عليك إعادة حل العنوان، بدلاً من إرسال سجلّ A استنادًا إلى السجلّات الملتصقة المخزّنة مؤقتًا التي يتمّ عرضها من خادم أسماء نطاق .com.

رفض الردود التي لا تستوفي المعايير المطلوبة

يرفض نظام أسماء النطاقات العام من Google جميع ما يلي:

• الردود غير القابلة للتحليل أو التشويه.
• الردود التي لا تتطابق فيها الحقول الرئيسية مع الحقول المقابلة في الطلب ويشمل ذلك رقم تعريف الطلب أو عنوان IP المصدر أو منفذ المصدر أو عنوان IP المقصود أو اسم طلب البحث. يمكنك الاطّلاع على RFC 5452، الفقرة 3 للحصول على وصف كامل لسلوكيات نظام أسماء النطاقات.
• السجلات التي لا صلة لها بالطلب.
• سجلات الإجابة التي لا يمكننا إعادة إنشاء سلسلة CNAME لها.
• السجلات (في الإجابة أو المرجع أو الأقسام الإضافية) التي لا يُعدّ خادم الأسماء المقابل لها جديرًا بالثقة. نحدّد "مصداقية"خادم الأسماء حسب مكانه في سلسلة التفويض لنطاق معيّن. يخزّن نظام أسماء النطاقات العام من Google معلومات تفويض سلسلة البيانات مؤقتًا، ونتحقّق من كل استجابة واردة مقابل المعلومات المخزّنة مؤقتًا لتحديد مصداقية خادم الأسماء عند الاستجابة لطلب معيّن.

إضافة إنتروبيا إلى الطلبات

وعند فرض برنامج تعيين فحصًا أساسيًا للسلامة، على أحد المهاجمين ملء برنامج تعيين الضحايا باستجابات لمطابقة معرّف طلب البحث ومنفذ UDP (من الطلب) وعنوان IP (للاستجابة) واسم طلب البحث الأصلي قبل خادم الأسماء الشرعي.

ومع ذلك، يصعب تحقيق ذلك، لأنّ الحقل الذي يحدّد بشكل فريد معرّف طلب البحث يبلغ طوله 16 بت فقط (أي أنّه من المفترض أن يكون عدد النقاط الصحيح 1/65,536). وتكون الحقول الأخرى محدودة أيضًا في النطاق، ما يجعل إجمالي عدد التركيبات الفريدة عددًا قليلاً نسبيًا. يمكنك الاطّلاع على RFC 5452، الفقرة 7 لمعرفة حساب التركيبات المعنية.

لذلك، يكون التحدي هو إضافة أكبر قدر ممكن من الأحرف العادية إلى حزمة الطلب، ضمن التنسيق العادي لرسالة نظام أسماء النطاقات، بحيث يصبح من الصعب على المهاجمين مطابقة مجموعة صالحة من الحقول بنجاح خلال فترة الفرصة. وننصح بتنفيذ جميع الأساليب التي تمت مناقشتها في الأقسام التالية وتنفيذها.

لقد قدّمنا مراجعة معدّلة للأساليب المذكورة هنا في مؤتمر DNS OARC 38 في تموز (يوليو) 2022. يتضمّن العرض التقديمي أيضًا اقتراحات لمشغّلات خوادم الأسماء.

توزيع منافذ المصدر عشوائيًا

كخطوة أساسية، لا تسمح مطلقًا لحِزم الطلبات الصادرة باستخدام منفذ UDP المنفذ 53 التلقائي، أو باستخدام خوارزمية يمكن التنبؤ بها لتخصيص منافذ متعددة (مثل الزيادة البسيطة). استخدِم مجموعة واسعة من المنافذ بين 1024 و65535 على النحو المسموح به في نظامك، واستخدِم أداة إنشاء أرقام عشوائية موثوق بها لتخصيص المنافذ. على سبيل المثال، يستخدم نظام أسماء النطاقات العام من Google 15 بت تقريبًا، للسماح بنحو 32,000 رقم منفذ مختلف.

يُرجى ملاحظة أنّه في حال نشر خوادمك بجدار ناري أو موازنة حمل أو أجهزة أخرى تنفّذ ترجمة عنوان الشبكة (NAT)، قد تعمل تلك الأجهزة على إعادة توزيع المنافذ على حزم البيانات الصادرة بشكل عشوائي. احرِص على إعداد أجهزة Natal لإيقاف إزالة التوزيع العشوائي للمنفذ.

اختيار عشوائي لخوادم الأسماء

بعض برامج التعيين، عند إرسال الطلبات إلى الجذر أو نطاق المستوى الأعلى أو خوادم أسماء أخرى، اختَر عنوان IP لخادم الأسماء بناءً على أقصر مسافة (وقت الاستجابة). ننصحك باختيار عناوين IP المقصودة بشكل عشوائي لإضافة بروتوكول إنتروبيا إلى الطلبات الصادرة. في نظام أسماء النطاقات العام من Google، نختار خادم أسماء عشوائيًا بين خوادم الأسماء التي تم ضبطها لكل منطقة، نفضّل إلى حد ما خوادم الأسماء السريعة والموثوقة.

إذا كنت قلقًا بشأن وقت الاستجابة، يمكنك استخدام تحديد أوقات الإرسال (RTT)، والذي يتألف من توزيع عشوائي ضمن نطاق عناوين أقل من الحد الأدنى المحدّد لوقت الاستجابة (مثل 30 ملي ثانية و300 ملي ثانية، وما إلى ذلك).

ملفات تعريف الارتباط الخاصة بنظام أسماء النطاقات

يحدد RFC 7873 خيار EDNS0 لإضافة ملفات تعريف ارتباط 64 بت إلى رسائل نظام أسماء النطاقات. يتضمن ملف تعريف ارتباط دعم نظام أسماء النطاقات ملف تعريف ارتباط عشوائي بتنسيق 64 بت، فضلاً عن ملف تعريف ارتباط خادم (إذا كان معروفًا) اختياريًا في طلب. وإذا وجد خادم داعم أن خيار ملف تعريف الارتباط صالحًا في طلب، يعكس ملف تعريف ارتباط العميل وملف تعريف ارتباط الخادم الصحيح في الاستجابة. يمكن للعميل الداعم بعد ذلك التحقق من استجابة الاستجابة من الخادم المتوقع عن طريق التحقق من ملف تعريف ارتباط العميل في الاستجابة.

إذا كان خادم الأسماء لا يتوافق مع ملفات تعريف الارتباط الخاصة بنظام أسماء النطاقات، يمكن استخدام الخيارين التاليين لإضافة المستخدم.

توزيع حالة الأحرف عشوائيًا في أسماء طلبات البحث

تتطلب معايير نظام أسماء النطاقات أن تتعامل خوادم الأسماء مع الأسماء التي لا تتأثر بحالة الأحرف. على سبيل المثال، يجب أن يتطابق الاسمان example.com وEXAMPLE.COM مع عنوان IP نفسه². بالإضافة إلى ذلك، يضيف جميع، باستثناء عدد قليل من خوادم الأسماء، الاسم نفسه في الردّ، كما ظهر في الطلب، مع الحفاظ على الحالة الأصلية.

وبالتالي، هناك طريقة أخرى لإضافة إنتروبيا إلى الطلبات وهي تغيّر حالة الأحرف في أسماء النطاقات التي يتم الاستعلام عنها. ويُعرف هذا الأسلوب، الذي يُعرف أيضًا بـ "0x20&quot؛ لأنّه يتم استخدام وحدة البت 0x20 لضبط حالة أحرف US-ASCII، وتم اقتراحها أولاً في مسودة الإنترنت ضمن مجموعة مهندسي شبكة الإنترنت (IETF). استخدام Bitx0020 في تصنيفات نظام أسماء النطاقات لتحسين هوية المعاملة. باستخدام هذا الأسلوب، يجب ألا تتطابق استجابة خادم الأسماء مع اسم طلب البحث فقط، بل تتطابق مع حالة كل حرف في سلسلة الاسم، على سبيل المثال، wWw.eXaMpLe.CoM أو WwW.ExamPLe.COm. قد يؤدي هذا إلى إضافة قدر قليل أو عدم توفّر مجمع إلى طلبات البحث لنطاقات المستوى الأعلى والجذر، ولكنه فعّال لمعظم أسماء المضيفين.

من أهم التحديات التي اكتشفناها عند تنفيذ هذا الأسلوب أنّ بعض خوادم الأسماء لا تتّبع سلوك الاستجابة المتوقّع:

• تستجيب بعض خوادم الأسماء بحساسية كاملة لحالة الأحرف: تعرض النتائج نفسها بشكل صحيح بغض النظر عن حالة الطلب، ولكن لا تتطابق الاستجابة مع حالة الاسم نفسها في الطلب.
• وتستجيب خوادم الأسماء الأخرى بحساسية كاملة لحالة الأحرف (بسبب مخالفة معايير نظام أسماء النطاقات): تتعامل هذه الأنظمة مع الأسماء المكافئة بشكل مختلف بناءً على حالة الطلب، أو عدم الرد على الإطلاق أو عرض استجابات NXDOMAIN غير الصحيحة التي تتطابق تمامًا مع حالة الاسم الوارد في الطلب.
• تعمل بعض خوادم الأسماء بشكل صحيح باستثناء طلبات البحث عن الموجّه (PTR) في منطقة arpa.

بالنسبة إلى هذين النوعين من خوادم الأسماء، يؤدي تغيير حالة اسم طلب البحث إلى ظهور نتائج غير مرغوب فيها: بالنسبة إلى المجموعة الأولى، لا يمكن تمييز الاستجابة من رد مزور، أما بالنسبة إلى المجموعة الثانية، فقد تكون الاستجابة (إن وجدت) غير صحيحة على الإطلاق.

الحل الحالي لهذه المشكلة هو استخدام التوزيع العشوائي لحالات الأحرف فقط لخوادم الأسماء التي نعرف أنها تطبق المعايير بشكلٍ صحيح. وندرج أيضًا النطاقات الفرعية للاستثناء المناسب لكل منها، استنادًا إلى تحليل سجلاتنا. إذا كان الردّ الذي يبدو صادرًا من تلك الخوادم لا يتضمّن الحالة الصحيحة، نرفض الاستجابة. وتعالج خوادم الأسماء المفعّلة أكثر من% 70 من عدد الزيارات الصادرة.

طلبات التصنيف غير السابقة معلّقة على أسماء طلبات البحث

وإذا لم تتمكّن أداة الحلّ من حلّ اسم من ذاكرة التخزين المؤقت مباشرةً، أو إذا تعذّر عليها بشكل مباشر طلب البحث عن خادم أسماء موثوق به، يجب أن تتّبع هذه الإحالات إحالات من خادم أسماء جذر أو نطاق مستوى أعلى (TLD). في معظم الحالات، تؤدي الطلبات إلى خوادم أسماء الجذر أو TLD إلى إحالة إلى خادم أسماء آخر، بدلاً من محاولة تحليل الاسم إلى عنوان IP. بالنسبة إلى هذه الطلبات، يجب أن يكون من الآمن إرفاق تصنيف عشوائي باسم طلب البحث لزيادة انتزاع الطلب، مع عدم المخاطرة بتعذّر حل الاسم غير الموجود. وهذا يعني أن إرسال طلب إلى خادم أسماء إحالة لاسم يحمل بادئة غير متطابقة، مثل entriih-f10r3.www.google.com، يجب أن يؤدي إلى النتيجة نفسها مثل طلب www.google.com.

على الرغم من أنه من الناحية العملية، تمثل هذه الطلبات أقل من 3% من الطلبات الصادرة، على افتراض أن الزيارات العادية (لأن معظم طلبات البحث يمكن الإجابة عنها مباشرةً من ذاكرة التخزين المؤقت أو عن طريق طلب بحث واحد)، فإن هذه هي أنواع الطلبات التي يحاول المهاجم فرض حلّها. ولذلك، يمكن أن يكون هذا الأسلوب فعّالاً جدًا في منع استغلال أنماط Kaminsky.

يتطلّب تنفيذ هذا الأسلوب استخدام التصنيفات غير المخصّصة فقط للطلبات التي تضمن أن تؤدي إلى إحالات، أي الردود التي لا تحتوي على سجلّات في قسم الإجابات. ومع ذلك، واجهنا العديد من التحديات عند محاولة تحديد مجموعة هذه الطلبات:

• بعض خوادم أسماء نطاقات المستوى الأعلى التي يتم ترميزها حسب البلد (ccTLD) موثوق بها فعليًا لنطاقات المستوى الأعلى (2LDs) الأخرى من المستوى الثاني. وعلى الرغم من أنّ هذه النطاقات تحمل تصنيفَين، فإنّ نطاقات المستوى الأعلى هي 2LD، تمامًا مثل نطاقات المستوى الأعلى التي يتم التعامل معها، ولهذا السبب غالبًا ما يتم التعامل معها من خلال خوادم أسماء نطاقات المستوى الأعلى التي يتم ترميزها حسب البلد (ccTLD). على سبيل المثال، خوادم الأسماء .uk موثوقة أيضًا للمنطقتَين mod.uk وnic.uk، وبالتالي، أسماء المضيفين المضمّنة في هذه المناطق، مثل www.nic.uk وwww.mod.uk وما إلى ذلك. وبعبارة أخرى، لن تؤدي الطلبات إلى خوادم أسماء نطاقات المستوى الأعلى التي يتم ترميزها حسب البلد إلى حلّ أسماء المضيفين هذه إلى الإحالات، ولكن في الإجابات الموثوق بها؛ حيث ستؤدي إضافة تصنيفات غير تابعة لأسماء المضيفين هذه إلى أن تكون الأسماء غير قابلة للتحليل.
• في بعض الأحيان، تعرض خوادم الأسماء في المستوى الأعلى العامة (gTLDs) استجابات غير موثوقة لخوادم الأسماء. وهذا يعني أنّ هناك بعض أسماء مضيفات أسماء الخوادم التي تقع في منطقة نطاق مستوى أعلى عام (gTLD) بدلاً من منطقة نطاقها. سيعرض نطاق عام في المستوى الأعلى إجابة غير موثوقة لأسماء المضيفين هؤلاء، باستخدام أي سجلّ ملتصق يحتوي عليه في قاعدة البيانات الخاصة به، بدلاً من عرض إحالة. على سبيل المثال، كان خادم الأسماء ns3.indexonlineserver.com متوفّرًا في منطقة .COM gTLD وليس في منطقة indexonlineserver.com. عندما أصدرنا طلبًا إلى خادم gTLD للنطاق n3.indexonlineserver.com، حصلنا على عنوان IP له، بدلاً من إحالة. ولكن إذا كنّا قد أضفنا تصنيفًا غير يسبق التصنيف، تلقّينا إحالة إلى indexonlineserver.com، والتي تعذّر علينا بعد ذلك حلّ اسم المضيف. لذلك، لا يمكننا إلحاق تصنيفات "noce" لخوادم الأسماء التي تتطلّب دقة من خادم gTLD.
• تتغير سلطات المناطق وأسماء المضيفين بمرور الوقت. يمكن أن يؤدي ذلك إلى تطابق اسم المضيف غير المُضاف في سابقًا الذي كان من الممكن أن يكون قابلاً للتحليل في حال تغيير سلسلة التفويض.

ولمعالجة هذه التحديات، أعددنا استثناءات لأسماء المضيفات التي لا يمكننا إلحاق تصنيفات غير تابعة لها. هذه هي أسماء المضيفين التي تعرض خوادم أسماء نطاق المستوى الأعلى لها استجابات بدون إحالة، وفقًا لسجلات الخوادم. ونراجع قائمة الاستثناءات باستمرار للتأكّد من بقائها صالحة بمرور الوقت.

إزالة طلبات البحث المكررة

تكون أدوات حل نظام أسماء النطاقات عرضة لهجوم "و" تاريخ الميلاد، وما يُطلق عليها اسم "المفاجآت الحسابية" و"تاريخ الميلاد" التي لا تتطلّب احتمالية التطابق معها عددًا كبيرًا من الإدخالات. ولا تشكّل هجمات عيد الميلاد إغماء خادم الضحية ليس فقط من خلال ردود زائفة، بل أيضًا في طلبات البحث الأولية، مع الاعتماد على برنامج الحلّ لإصدار طلبات متعددة للحصول على حلّ واحد للاسم. وكلما زاد عدد الطلبات الصادرة، زادت احتمالية مطابقة المهاجم لأحد هذه الطلبات التي تتضمن ردًا مزورًا، حيث يحتاج المهاجم إلى الحصول على طلب 300 طلب أثناء الطيران لضمان نجاح الاستجابة المطابقة بنسبة 700 طلب و700 طلب لنجاحه بنسبة 100% تقريبًا.

للحماية من استراتيجية الهجوم هذه، يجب أن تتأكّد من تجاهل كل طلبات البحث المكرّرة من قائمة الانتظار الصادرة. على سبيل المثال، لا يتيح نظام أسماء النطاقات العام من Google مطلقًا أكثر من طلب معلّق واحد لاسم الطلب نفسه ونوع طلب البحث وعنوان IP المقصود نفسه.

طلبات تقييد المُعدَّل

يؤدي منع هجمات رفض الخدمة إلى فرض تحديات متعددة على برامج تعيين نظام أسماء النطاقات المتكررة والمفتوحة:

• تُعدّ أدوات التعيين المتكرّر المفتوحة أهدافًا جذابة لإطلاق هجمات التضخيم. فهي خوادم عالية القدرة وذات موثوقية عالية ويمكن أن ينتج عنها ردود أكبر من خادم الأسماء النموذجي، خاصةً إذا كان بإمكان المهاجم إدخال استجابة كبيرة في ذاكرة التخزين المؤقت. على أي مطوّر برامج في خدمة نظام أسماء النطاقات المفتوحة تجنّب استخدام خوادمه من أجل إطلاق هجمات على أنظمة أخرى.
• قد يصعب اكتشاف هجمات التضخيم أثناء حدوثها. يمكن للمهاجمين شن هجوم من خلال آلاف من برامج التعيين المفتوحة، بحيث لا يرى كل برنامج الحل سوى جزء صغير من حجم طلبات البحث الإجمالية، ولا يمكنه استخراج إشارة واضحة إلى أنه تم اختراقه.
• يجب حظر الزيارات الضارة إلى أي مستخدم أو انقطاع في خدمة نظام أسماء النطاقات. يُعدّ نظام أسماء النطاقات خدمة أساسية للشبكة، لذا لا يُعدّ إغلاق الخوادم لقطع الهجمات أحد الخيارات، ولا يُرفض الخدمة لأي عنوان IP عميل لفترة طويلة جدًا. يجب أن تتمكن برامج التعيين من حظر الهجوم بسرعة فور بدئه، واستعادة الخدمة التشغيلية بالكامل فور انتهاء الهجوم.

إنّ أفضل منهج في مكافحة هجمات DoS هو فرض آلية للحدّ من المعدّل أو التقييد. يستخدم نظام أسماء النطاقات العام من Google نوعَين من معدّل التحكّم:

• التحكّم في معدّل الطلبات الصادرة إلى خوادم الأسماء الأخرى لحماية خوادم أسماء نظام أسماء النطاقات الأخرى من هجمات إيقاف الخدمة (DoS) التي يمكن تشغيلها من خوادم برنامج التعيين، يفرض نظام أسماء النطاقات العام من Google (QPS) قيودًا على QPS في الطلبات الصادرة من كل مجموعة عرض لكل عنوان IP لخادم الأسماء.

• التحكم في معدل الردود الصادرة على العملاء لحماية أي أنظمة أخرى من التضخيم وهجمات Dos الموزَّعة التقليدية (botnet) التي يمكن إطلاقها من خوادم برامج التعيين، ينفذ "نظام أسماء النطاقات العام من Google" نوعَين من المعدلات يحدّ من طلبات العميل:

  • للحماية من الهجمات التقليدية المستندة إلى الحجم، يفرض كل خادم بروتوكول QPS لكل عميل وعنوان IP لمتوسط معدل نقل البيانات.
  • للحماية من هجمات التضخيم، التي يتم فيها استغلال الردود الكبيرة على طلبات البحث الصغيرة، يفرض كل خادم عامل تضخيم متوسط لكل عميل. متوسط التضخيم هو نسبة قابلة للضبط لحجم الاستجابة لطلبات البحث، ويتم تحديدها من خلال أنماط الزيارات السابقة التي تمت ملاحظتها في سجلات الخادم.

  إذا تجاوزت طلبات بحث نظام أسماء النطاقات من عنوان IP مصدر واحد الحد الأقصى لمعدّل نقل البيانات في الثانية، سيتم تجاهل طلبات البحث الزائدة. إذا تجاوزت طلبات بحث نظام أسماء النطاقات عبر بروتوكول UDP من عنوان IP مصدر واحد متوسط معدل نقل البيانات أو حد التضخيم بشكل ثابت (ستستمر الاستجابة الكبيرة من وقت لآخر)، قد يتم تجاهل طلبات البحث أو إرسال رد صغير فقط. قد تتمثل الاستجابات الصغيرة في استجابة خطأ أو رد فارغ مع مجموعة بت الاقتطاع (حتى تتم إعادة محاولة معظم طلبات البحث المشروعة من خلال TCP ونجاحها). لن تُعيد جميع الأنظمة أو البرامج المحاولة من خلال بروتوكول TCP، وقد يتم حظر نظام أسماء النطاقات عبر بروتوكول TCP من خلال الجدران النارية من جهة العميل، لذا قد لا تعمل بعض التطبيقات بشكل صحيح عند اقتطاع الردود. ومع ذلك، يسمح الاقتطاع للبرامج المتوافقة مع RFC أن تعمل بشكل صحيح في معظم الحالات.