يمثل نظام اسم المجال (DNS) البنية التحتية الأساسية للعنونة عبر شبكة الإنترنت، حيث يتولى تحويل الأسماء المقروءة إلى عناوين بروتوكول الإنترنت (IP). ولعقود طويلة، ظل بروتوكول حزم بيانات المستخدم (UDP) عبر المنفذ 53 هو وسيلة النقل السائدة لطلبات الاستعلام. ورغم أن بروتوكول UDP يقلل زمن الاستجابة عبر إلغاء الحاجة للمصافحة الثلاثية، إلا أن طبيعته غير المتصلة تنطوي على ثغرة هيكلية حرجة: انتحال عنوان IP المصدري. ويستغل المهاجمون خوادم التحليل التكرارية والخوادم الموثوقة لتوليد هجمات حجب الخدمة الموزعة (DDoS) الانعكاسية ذات التضخيم العالي وتسميم ذاكرة التخزين المؤقت خارج المسار. ولهذا وضعت مواصفات RFC 7873 ومحدثتها القياسية RFC 9018 آلية تشفير خفيفة عديمة الحالة ضمن امتدادات EDNS(0) لإثبات صحة المعاملات المتبادلة بين العملاء وخوادم الأسماء.

استعلام UDP تقليدي غير موثق (معرض لانتحال العنوان المصدري):
المهاجم (ينتحل عنوان الضحية) ──── طلب الاستعلام ───> خادم DNS
الضحية المستهدفة <───── استجابة مضخمة ومنعكسة ───── خادم DNS

معاملة محمية بملفات تعريف ارتباط DNS (RFC 7873 / RFC 9018):
العميل ────── طلب استعلام + كعكة العميل (8 بايت) ────> خادم DNS
العميل <── استجابة + كعكة العميل + كعكة الخادم ───── خادم DNS
(تأكيد الهوية المتبادلة وإسقاط الحزم المزورة خارج المسار تلقائياً)

أزمة تضخيم بروتوكول UDP: ثغرات نظام اسم المجال التقليدي

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

النقل عديم الحالة وانتحال عناوين بروتوكول الإنترنت المصدرية

يخلق التباين الحجمي بين استعلام DNS الصغير والاستجابة المشفرة الضخمة معاملات تضخيم هائلة في حركة المرور. فطلب استعلام متواضع بحجم 64 بايت يطلب سجلات ANY أو مجموعات توقيعات DNSSEC (مثل RRSIG و DNSKEY) أو سجلات TXT الطويلة، قد يسفر عن استجابات يتجاوز حجمها 3000 بايت. وعندما تتوانى شبكات التزويد عن تطبيق التحقق من العناوين المصدرية (BCP 38 / RFC 2827)، يستغل المهاجمون آلاف الخوادم المفتوحة لتوجيه طوفان من البيانات يستهلك النطاق الترددي للضحية.

كما أن غياب التحقق من المصدر يسهل عمليات تسميم ذاكرة التخزين المؤقت (DNS Cache Poisoning). فمن خلال التنبؤ برقم المعاملة (Transaction ID) ومنفذ المصدر، يستطيع المهاجم حقن سجلات مزورة في ذاكرة الخادم قبل وصول الرد الرسمي من الخادم المعتمد. ورغم أن DNSSEC يضمن سلامة محتوى السجلات، إلا أنه لا يتحقق من هوية مرسل الاستعلام ولا يحمي البنية التحتية من الاستغلال في هجمات التضخيم.

تكاليف ومحدودية تقييد معدل الاستجابة RRL

للحد من هجمات الانعكاس، اتجه مشغلو الخوادم إلى تفعيل آلية تقييد معدل الاستجابة (Response Rate Limiting أو RRL). تقوم هذه الآلية بتتبع أحجام الطلبات وفق بادئة عنوان IP الخاص بالعميل (/24 لبروتوكول IPv4 أو /56 لبروتوكول IPv6)، وتقوم بإسقاط أو تقليص (عبر ضبط علامة TC=1) الاستجابات التي تتجاوز الحدود المسموحة.

ورغم نجاح RRL في تخفيف إجمالي حركة المرور الضارة، إلا أنه يحمل سلبيات تشغيلية معقدة:

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

توفر ملفات تعريف ارتباط DNS حلاً جذرياً لهذه المعضلة عبر إثبات إمكانية الوصول ثنائية الاتجاه دون إلزام الخادم بالاحتفاظ بجداول حالات معقدة لكل عميل.

معمارية RFC 7873: المصافحة المزدوجة لملفات تعريف الارتباط عبر EDNS(0)

تحدد مواصفة RFC 7873 إطاراً لنقل رموز التحقق المشفرة مدمجة داخل آليات توسيع نظام اسم المجال (EDNS(0), RFC 6891) تحت رمز الخيار Option Code 10.

+-------------------------------+-------------------------------+
|       OPTION-CODE (10)        |     OPTION-LENGTH (16-40)     |
+-------------------------------+-------------------------------+
|                    Client Cookie (8 بايت)                     |
+---------------------------------------------------------------+
|                    Server Cookie (8-32 بايت)                  |
+---------------------------------------------------------------+

يعتمد البروتوكول على عملية تبادل ثنائية المراحل بين عميل DNS (محلل فرعي أو تكراري) وخادم DNS (خادم تكراري أو موثوق).

ملف تعريف ارتباط العميل: توليد رمز مؤقت شبه عشوائي

يمثل ملف تعريف ارتباط العميل رمزاً شبه عشوائي بطول 8 بايت ينشئه العميل بنفسه. ويشترط في هذا الرمز ألا يكون قابلاً للتنبؤ من قبل الأطراف المتلصصة، مع إمكانية إعادة احتسابه من العميل لنفس الخادم خلال نافذة زمنية محددة:

$$\text{Client Cookie} = \text{PRF-64}(\text{Client IP}, \text{Server IP}, \text{Client Secret})$$

يحتوي المفتاح السري للعميل على 128 بت من الإنتروبيا المشفرة المحفوظة في الذاكرة المؤقتة. وتؤدي عملية تدوير المفتاح المنتظمة (عادة كل 24 ساعة) إلى إبطال الرموز السابقة دون الحاجة لتسجيلها على أقراص التخزين. ويمنع ربط عنواني العميل والخادم إعادة استخدام الرمز نحو وجهات أخرى.

ملف تعريف ارتباط الخادم: رمز تشفيري عديم الحالة

عندما يتلقى خادم الأسماء استعلاماً يحتوي على كعكة العميل، ينفذ الإجراءات التالية:

  1. الاستعلام الأولي: يرسل العميل كعكته الخاصة بطول 8 بايت فقط، ويكون طول الخيار 8.
  2. الاحتساب في الخادم: يدرك الخادم أنها بداية اتصال، فيقوم بحساب كعكة خادم مشتقة من كعكة العميل وعنوان IP الخاص به والمفتاح السري الداخلي للخادم.
  3. الرد بالكعكتين: يدرج الخادم كعكة العميل الأصلية مع كعكة الخادم المولدة حديثاً (بطول يتراوح بين 8 و 32 بايت) في سجل EDNS(0) OPT ضمن الاستجابة.
  4. التخزين في العميل: يطابق العميل الكعكة المسترجعة مع رمزه الأصلي، ثم يخزن كعكة الخادم في ذاكرته المحلية مرتبطة بعنوان الخادم.
  5. الاستعلامات اللاحقة: ترسل كافة الطلبات التالية كلا الرمزين معاً (بطول إجمالي 16 إلى 40 بايت)، حيث يتحقق الخادم فوراً عبر إعادة احتساب التجزئة التشفيرية.

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

مواصفات ملف تعريف ارتباط الخادم المتوافق وفق RFC 9018

تركت مواصفة RFC 7873 السابقة التنسيق الداخلي لكعكة الخادم لاختيار المطورين. وفي بيئات شبكات أنيكاست متعددة الأنظمة التي تشغل برمجيات متباينة (مثل BIND و NSD و Knot DNS و PowerDNS)، عجزت الخوادم عن التعرف على الرموز المولدة من برمجيات أخرى.

جاءت وثيقة RFC 9018 لتعالج هذا التباين وتحدد بنية موحدة وثابتة لكعكة الخادم بطول 16 بايت.

+---------------+---------------+-------------------------------+
| Version (0x01)|       Reserved (0x000000)                     |
+---------------+---------------+-------------------------------+
|                      Timestamp (4 بايت)                       |
+---------------------------------------------------------------+
|                      Hash (8 بايت)                            |
+---------------------------------------------------------------+

وتتكون الحقول من التالي:

  • Version (1 بايت): محدد إصدار الخوارزمية، وثابت عند القيمة 0x01.
  • Reserved (3 بايت): حقل محجوز، يرسل بالقيمة 0x000000 ويتجاهله المستقبل.
  • Timestamp (4 بايت): عدد صحيح غير سالب بطول 32 بت يسجل الوقت بنظام ثواني يونكس.
  • Hash (8 بايت): رمز تحقق تشفيري مقتطع بطول 64 بت.

بنية خوارزمية SipHash-2-4 وتجزئة 64 بت المقتطعة

تفرض RFC 9018 استخدام خوارزمية SipHash-2-4 لحساب حقل Hash البالغ 8 بايت. تتميز هذه الخوارزمية بسرعة المعالجة الفائقة للمدخلات القصيرة، ومقاومة هجمات تصادم التجزئة، والكفاءة العالية على معالجات 64 بت.

يتم احتساب التجزئة وفق الصيغة التالية:

$$\text{Hash} = \text{SipHash-2-4}(\text{Server Secret}, \text{Client Cookie} ,|, \text{Version} ,|, \text{Reserved} ,|, \text{Timestamp} ,|, \text{Client IP})$$

ويقوم الخادم بفحص شرطين متتاليين:

  1. صلاحية الختم الزمني: التأكد من أن $|T_{\text{الحالي}} - T_{\text{الكعكة}}| \le 3600 \text{ ثانية}$. وتغطي هذه النافذة البالغة ساعة واحدة تأخيرات النقل وتفاوت الساعات مع تقليص فرص هجمات إعادة الإرسال.
  2. التحقق من صحة التجزئة: يعيد الخادم احتساب SipHash-2-4 بالمفتاح النشط ومطابقة القيمة بطول 64 بت في زمن ثابت لمنع الهجمات الزمنية.

تعتبر الطلبات المجازة موثوقة بالكامل، مما يعفيها من قيود RRL ويتيح إرسال الردود الكاملة وصولاً إلى حجم مخزن EDNS المتفق عليه.

إدارة هياكل خوادم أنيكاست وتناوب المفاتيح السرية

تعتمد البنية التحتية لخدمات DNS الحديثة على تقنية BGP Anycast لنشر عنوان IP موحد عبر مئات نقاط التواجد الجغرافية (PoP). وقد تؤدي تغيرات التوجيه إلى وصول حزم متتالية من نفس العميل إلى خوادم فعلية مختلفة.

ولضمان استمرارية التحقق دون انقطاع، يجب أن تتشارك كافة خوادم المجموعة نفس المفاتيح السرية. ويتبع المشغلون نظاماً بمفتاحين متماثلين:

  • المفتاح الأساسي ($K_{\text{active}}$): لتوليد كعكات الخادم في الردود الصادرة ومطابقة الطلبات الواردة.
  • المفتاح السابق ($K_{\text{previous}}$): يُحتفظ به خلال فترة التبديل (بين 2 و 24 ساعة) لقبول الرموز المنشأة بواسطة الجيل السابق من المفاتيح.

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

التعامل مع خطأ BADCOOKIE وآلية التوافق العكسي

إذا استقبل الخادم طلباً يحمل كعكة خادم منتهية الصلاحية أو غير مطابقة، تبدأ خطة الاستعادة المحددة في RFC 7873:

  1. منع التضخيم: يرفض الخادم إرسال سجلات الاستجابة الكاملة.
  2. إشعار بالخطأ: يرسل رداً فارغاً يحمل رمز الحالة RCODE=9 (BADCOOKIE) مع الاحتفاظ بمعرف المعاملة الأصلي.
  3. تقديم كعكة محدثة: يرفق الخادم في سجل EDNS(0) OPT كعكة العميل مع كعكة خادم جديدة وصالحة.
  4. إعادة المحاولة: يستقبل العميل رمز الخطأ، ويحدث بيانات الذاكرة لديه، ويعيد إرسال طلبه الأصلي على الفور.

وإذا قامت جدران الحماية الوسيطة بإزالة حقول EDNS(0)، يكتشف العميل غياب الكعكات في الردود ويعود تلقائياً لنمط استعلامات DNS التقليدي لضمان استمرار الاتصال.

التكامل مع RiceGuard: بنية نظام اسم المجال بانعدام الثقة وتأمين حركة المرور

يدمج محرك الشبكات المتطور RiceGuard في تطبيق VPNRice معايير ملفات تعريف ارتباط DNS في كافة طبقات الاتصال من أجهزة العملاء وحتى الخوادم التكرارية، مؤسساً بيئة خالية من الثقة المسبقة (Zero-Trust).

بنية DNS بانعدام الثقة في منظومة RiceGuard:
جهاز العميل (تطبيق VPNRice)
  │
  ├── نفق مشفر عبر WireGuard / IPsec (ChaCha20-Poly1305 / AES-256-GCM)
  ▼
عقدة الدخول الطرفية لأنيكاست RiceGuard
  │  - فحص إلزامي لملفات تعريف ارتباط RFC 9018 على حزم UDP
  │  - تصفية محاولات التضخيم المزورة قبل وصولها للأنظمة الداخلية
  │  - مزامنة مفاتيح SipHash-2-4 عبر كافة نقاط الشبكة العالمية
  ▼
محرك التحليل التكراري المحصن
  │  - إرسال كعكات العميل تلقائياً نحو خوادم الجذر ونطاقات المستوى الأعلى
  │  - التحقق الصارم من كعكات الخادم في الردود التكرارية الخارجية
  │  - تطبيق الفحص المشفر لسلسلة تواقيع DNSSEC
  ▼
البنية التحتية الموثوقة لشبكة الإنترنت
  1. عزل مشفر داخل النفق: تمر استعلامات المستخدمين عبر أنفاق WireGuard أو IPsec مباشرة نحو خوادم أنيكاست التابعة لـ RiceGuard، مما يحميها من التجسس عبر شبكات Wi-Fi ومزودي الخدمة.
  2. حماية أطراف الشبكة: تطبق الواجهات العامة تحققاً دقيقاً من كعكات RFC 9018 على حركة مرور UDP، ويتم تحجيم الحزم المزورة أو مواجهتها بتحدي BADCOOKIE لمنع استغلال الخوادم في الهجمات.
  3. أمان الاستعلامات الخارجية: عند البحث عن النطاقات عبر خوادم الجذر والنطاقات العلوية، تدرج خوادم RiceGuard كعكات العميل وتتحقق من الردود، مما يحمي الذاكرة من التسميم حتى للنطاقات غير الموقعة بـ DNSSEC.

إن التوافق بين التشفير النفقي ومصادقة حزم DNS عبر ملفات تعريف الارتباط يضمن معاملات آمنة ومستقرة عبر مختلف مسارات الشبكة.

التحقق التشغيلي: اختبار ملفات تعريف ارتباط DNS باستخدام Dig

يستطيع مهندسو الشبكات فحص جاهزية الخوادم لدعم ملفات تعريف ارتباط DNS عبر أداة dig المتاحة في حزم BIND الحديثة.

تنفيذ استعلام متكامل مع التفاوض

تدعم الإصدارات الحديثة من أداة dig تفاوض الكعكات بصورة تلقائية:

# استعلام خادم أنيكاست مع تفعيل خيار الكعكات
dig @1.1.1.1 vpnrice.com +cookie

ويظهر الرمز ضمن قسم OPT PSEUDOSECTION في نتائج الاستعلام:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 5a8e2b109c3d4f8a 01000000672c8410d9f82e14a7c3b901 (good)
;; QUESTION SECTION:
;vpnrice.com.			IN	A

;; ANSWER SECTION:
vpnrice.com.		300	IN	A	104.21.48.12

تفاصيل البيانات الظاهرة:

  • 5a8e2b109c3d4f8a: كعكة العميل بطول 8 بايت المولدة محلياً.
  • 01000000672c8410d9f82e14a7c3b901: كعكة الخادم بطول 16 بايت المتوافقة مع RFC 9018:
    • الإصدار: 01
    • الحقل المحجوز: 000000
    • الختم الزمني: 672c8410 (بالنظام الست عشري لثواني يونكس)
    • التجزئة: d9f82e14a7c3b901 (ناتج SipHash-2-4)
  • وتؤكد العبارة (good) نجاح التحقق التشفيري ومطابقته للشروط.

اختبار سيناريو الخطأ وتجديد الرمز

لاختبار استجابة الخادم عند استقبال رمز غير صحيح، يمكن إرسال كعكة تالفة عمداً:

# إرسال كعكة خادم غير صحيحة بطول 16 بايت
dig @1.1.1.1 vpnrice.com +cookie=5a8e2b109c3d4f8a0100000000000000ffffffffffffffff

يقوم الخادم المتوافق مع معيار RFC 9018 بإرجاع الحالة status: BADCOOKIE مع إخلاء قسم الإجابة، ويزود العميل بكعكة خادم صالحة وجديدة ضمن خيار OPT لتمكينه من إعادة المحاولة بنجاح.

تنجح ملفات تعريف ارتباط DNS في التوفيق بين سرعة النقل عبر UDP ومتطلبات التحقق الأمني الصارم. ويسهم اعتماد RFC 7873 و RFC 9018 عبر الخوادم التكرارية والموثوقة في القضاء على مخاطر هجمات التضخيم الانعكاسية عند طبقة النقل مع المحافظة على سرعة معالجة الاستعلامات في أجزاء من الميلي ثانية.

لتأمين حركة مرور بياناتك والاستفادة من شبكة خوادم أنيكاست المحصنة بأحدث بروتوكولات التحقق الرقمي، يمكنك تحميل VPNRice.