الخلاصة

  • يضيف DNS Cookies إلى DNS فوق UDP إشارة خفيفة لا تتطلب حالة منفصلة لكل عميل في الخادم. تربط القيمة الصحيحة تبادلاً سابقاً بـ Client Cookie وعنوان IP ربطاً ضعيفاً؛ ولا تعرّف شخصاً أو مؤسسة، ولا تصادق بيانات DNS، ولا تشفّر السؤال، ولا تمنع مراقباً على المسار.
  • تحدد RFC 9018 في الإصدار الأول Server Cookie بطول 16 بايت وSipHash-2-4 وطابعاً زمنياً وسراً قابلاً للإعداد. في anycast تصبح مشاركة السر وتدويره بين العقد سطحاً للسلطة التشغيلية.
  • يجب أن يصل الدليل بين bytes الخام، وسبب التحقق، والعقدة، وحقبة السر، وBADCOOKIE، والدفاع الذي خُفف فعلاً، وحجم الإجابة، ونتيجة إعادة المحاولة. كلمة valid نتيجة وليست سلسلة إثبات.

عميل «معروف» لا نعرف هويته

تتعرض خدمة DNS موثوقة موزعة عبر anycast لموجة طلبات UDP تسأل عن إجابة موقعة كبيرة. تقيد الخدمة الطلبات الآتية من مصادر تراها للمرة الأولى حتى لا تضخم حزمًا بعناوين مزورة. يعود resolver حقيقي حاملاً Client Cookie الذي اختاره وServer Cookie الذي تلقاه سابقاً. ينجح التحقق، فتسمح السياسة بإجابة أكمل.

قد تسمي لوحة التشغيل ذلك «عميلاً معروفاً». لكن عنوان CGNAT الواحد قد يخدم مشتركاً آخر بعد دقائق. وقد ينسخ مراقب على المسار الخيار كاملاً. وربما ما زالت عقدة anycast تقبل حقبة سر تقاعدت في بقية المواقع. صلاحية bytes في موضع ما لا تعني ثبات الفاعل خلفها.

السؤال الدقيق هو: هل استطاعت جهة عند عنوان المصدر الظاهر أن تتلقى حديثاً قيمة خادم مرتبطة بهذا Client Cookie ضمن نافذة الوقت والسر المقبولة؟ لا يجيب عن اسم الجهة أو سلامة resolver أو غرض السؤال أو استحقاقه لكل موارد الخدمة.

المتحقق يقدم واقعة واحدة. أما rate limiter وسياسة حجم الإجابة ونظام مكافحة الإساءة فتقرر مقدار السلطة التي تمنحها لتلك الواقعة.

جزآن بوظيفتين غير متساويتين

تخصص IANA الرمز 10 في خيارات EDNS لـ COOKIE. عند الاتصال الأول، تحمل رسالة RFC 7873 Client Cookie بطول ثمانية بايت فقط. يعيده الخادم ويضيف Server Cookie. تحمل الرسالة اللاحقة الاثنين، فيتحقق الخادم من دون جدول حالة دائم لكل عميل.

Client Cookie ليس وثيقة هوية. توصي RFC 9018 بـ 64 بتاً من entropy، وبقيمة مختلفة لكل IP خادم، وتغييرها عند تغير IP العميل، وعدم استمرارها بعد إعادة تشغيل البرنامج. يتعرف العميل إلى اختياره؛ ولا يستخرج الخادم منه اسماً أو حساباً.

طول Server Cookie في version 1 هو 16 بايت، فيصبح طول الخيار الكامل 24 بايت بالضبط. يحسب SipHash-2-4 فوق Client Cookie والإصدار والحقل المحجوز والطابع الزمني وIP العميل بمفتاح Server Secret. يصعب على مهاجم خارج المسار اختراع MAC حديث لأنه لم ير الرد الأول.

يوفر غياب الحالة ذاكرة أثناء الهجوم، لكنه يركز المسؤولية في السر والساعة والتحليل الدقيق. قبول طول ملتبس، أو ترك clock drift، أو توزيع المفتاح على نطاق أوسع من اللازم يغير الضمان من دون أن يغير حالة enabled الظاهرة.

الضمان الضعيف لا يستحق امتيازاً قوياً

يمكن للقيمة الصحيحة أن تميز كثيراً من العملاء الذين تلقوا رداً عن floods لا تفعل إلا تزوير المصدر. قد تسمح الخدمة ببضعة bytes إضافية أو حصة مؤقتة أعلى. ينبغي أن ينتهي الاستنتاج هنا.

يرى المراقب on-path الرمز ويمكنه إعادة استخدامه ضمن صلاحيته. لا يوفر DNS Cookies سرية، ولا يوقع RRsets. DNSSEC يجيب عن أصالة البيانات، وtransaction entropy يساعد في مطابقة الإجابات، والنقل المشفر يقدم خصائص أخرى. لا يجوز دمجها في ضوء أخضر واحد بعنوان «DNS آمن».

لذلك لا يغير cookie إلا الدفاع المرتبط مباشرة بالتزوير off-path. لا يفتح recursion، ولا يتجاوز ACL، ولا يلغي DNSSEC validation، ولا يرفع كل سقوف المعدل، ولا يهزم حظر incident. يمكن لـ resolver مخترق أن يرسل cookies صحيحة تماماً.

وعنوان IP ليس شخصاً. يجمع NAT مستخدمين، وتنقل mobility نقطة الخروج، ويعاد توزيع العناوين. الربط بالعنوان مفيد لنموذج التهديد، لكنه لا يخلق هوية اجتماعية أو مؤسسية.

Anycast يحول السر إلى عهدة مشتركة

قد تصل طلبات متتابعة إلى IP anycast نفسه عبر مدن وآلات مختلفة. يجب أن تتحقق العقدة الثانية من القيمة التي صنعتها الأولى. لهذا توحد RFC 9018 البناء وتفرض قابلية إعداد Server Secret.

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

عبارة «وصل الإعداد» لا تثبت convergence في التشغيل. تحتاج كل عقدة إلى معرف حقبة غير سري، وحالات learned وgenerating وaccepting، وقياس لصحة الساعة. يجب أن يقتصر السر على أصغر مجموعة تحتاج interoperation، وألا يربط عناوين أو بيئات أو عملاء مستقلين.

BADCOOKIE مسار استرداد لا حكم اتهام

قد تكون القيمة غير صالحة بسبب انتهاء الوقت، أو تغير IP أو Client Cookie، أو حقبة مجهولة، أو تنسيق مشوه، أو تزوير. يعيد BADCOOKIE قيمة جديدة ويسمح بمحاولة محدودة عندما يتطابق Client Cookie. الحلقة غير المنتهية تصبح حملاً إضافياً.

التوزيع مهم. فشل يتركز في موقع واحد يرجح drift في السر؛ ارتفاع لدى شبكة متنقلة قد يعكس NAT؛ أطوال غير قانونية في جميع المواقع قد تشير إلى استهداف parser. يجب حفظ تصنيف التحقق قبل إسناد النية.

تُقاس أول مقابلة، وvalid، وexpired، وmalformed، وunknown epoch، وBADCOOKIE، وretry الناجح، والتخلي، وTCP fallback. إسقاط التزوير مع منع resolution مشروع ليس نجاحاً.

المشترك قليل والتنفيذ محلي

تظهر Minimum Initial Specification لدى Heng Lu بوضوح: codepoint والطول والخوارزمية والزمن والاسترداد هي الطبقة المشتركة. أما response budget وسياسة DDoS وعهدة المفاتيح وتوقيت الاعتماد فتبقى محلية.

يسمح Localized Future Decision للخادم برفض امتياز إضافي رغم cookie صالح أثناء الضغط، ويسمح للعميل بالتعامل مع خادم لا يعتمد الخيار. ويعني Voluntary Adoption أن نشر RFC لا يصنع السلوك: التنفيذ والاختبار والحزم هي الواقع.

سجل IANA تنسيق رمزي؛ والخيار حالة protocol؛ وفرع السياسة الذي يكبر الإجابة سلطة قابلة للتنفيذ؛ والbytes المرسلة نتيجة. تتطلب running-code primacy قياس هذه الطبقات، ولا تجعل كل ما نفذه البرنامج مشروعاً.

المصادر