الخلاصة

  • سجلت APNIC حادثة أثرت في RDAP من الساعة 15:45 يوم 27 يناير 2026 حتى 09:45 يوم 28 يناير، بتوقيت UTC+10، أي لمدة 18 ساعة.
  • قالت APNIC إن تغييراً غير مقصود في إعداد Cloudflare فرض فحصاً أشد لسلامة المتصفح، فحجب قرابة 10% من الطلبات التي لم تطابق سلاسل User-Agent فيها الأنماط الشائعة للمتصفحات.
  • حماية خدمة عامة من الحجب والروبوتات المسيئة واجب مشروع؛ أما التشابه مع المتصفح فليس دليلاً على هوية المشغّل أو تفويضه أو سلامة غرضه.
  • أعادت أربعة طلبات منخفضة الوتيرة في سبتمبر، بأربعة أنماط مختلفة من User-Agent، نسخة JSON ذاتها. هذا قياس آني محدود، لا إثبات شامل للإصلاح ولا إعادة بناء للحادثة.
  • يمكن لسجل خدمة صغير أن يفصل فئة العميل عن قرار الحافة ووصول الطلب إلى المصدر ونوع الاستجابة وخط زمني للتغيير والتراجع، من دون كشف قاعدة الحماية.

حين تصبح بطاقة البرنامج تصريح مرور

يعرّف معيار RFC 9110 حقل User-Agent بأنه معلومات عن البرنامج الذي أنشأ الطلب. قد يذكر اسم منتج وإصداره وتعليقات إضافية، ويُستفاد منه في التوافق وتشخيص الأعطال وتكييف الردود. لكن البرنامج نفسه هو من يكتب هذه المعلومات.

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

لهذا يمكن أن يكون User-Agent إشارة ضعيفة ضمن قرار أوسع، لكنه لا يصلح وحده تفويضاً. حين يحصل على سلطة الحجب الكامل، يتعلم مطوّرو البرامج أن الصراحة مكلفة: تسمية الأداة باسمها تقلل فرصة الوصول، أما استعارة اسم متصفح فترفعها. والروبوت المسيء يتعلم الدرس نفسه بسهولة.

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

حادثة APNIC مهمة لأنها تكشف هذه النقطة من خلال أثر تشغيلي ملموس، لا من خلال افتراض نظري.

ما ثبّتته APNIC عن الساعات الثماني عشرة

تذكر صفحة الإعلان الرسمي أن البداية كانت يوم الثلاثاء 27 يناير 2026 عند 15:45، والنهاية يوم الأربعاء 28 يناير عند 09:45، بتوقيت UTC+10. الخدمة المتأثرة هي RDAP، والمدة 18 ساعة.

تنسب APNIC الحادثة إلى تغيير في إعدادها على Cloudflare أدى، من دون قصد، إلى تنفيذ فحوص أشد لسلامة المتصفح. وخلال تلك المدة، حُجب نحو 10% من طلبات RDAP التي تضمنت سلاسل User-Agent لا تطابق السلاسل الشائعة للمتصفحات.

ينبغي ألا يتغير اسم المقام. النسبة تخص الطلبات، لا المستخدمين ولا المؤسسات ولا أدوات البرمجيات. قد يرسل عميل واحد آلاف الطلبات، وقد تعيد الأداة المحجوبة المحاولة، وقد تشترك أدوات عدة في مكتبة واحدة. لا يوفر الإعلان عدداً للعملاء الفريدين أو المشغلين المتأثرين أو القرارات التي تأخرت.

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

المعلومة التي تبقى كافية للتحليل هي أن جزءاً من الطلبات صُنّف قبل أن ينتج تطبيق RDAP استجابته المعتادة. قد لا يراها سجل المصدر قط. وقد تنجح مراقبة تتظاهر دائماً بأنها متصفح، بينما تفشل برمجيات صريحة. صحة المصدر وإتاحة المسار ليستا القياس نفسه.

أقوى دفاع عن APNIC يبدأ من الحافة

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

شرحت APNIC في 2020 بنية جديدة تستقبل فيها Cloudflare الطلبات الموجهة إلى rdap.apnic.net وخدمات RDAP لدى سجلات الإنترنت الوطنية، وتوفر موازنة الأحمال والحماية من حجب الخدمة، ثم تمرر الطلبات إلى بنية في Google Cloud. إذن قرار الحافة ليس طبقة خارج الخدمة من منظور القارئ؛ إنه أول سطح تنفيذي لها.

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

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

RDAP ليس صفحة ويب أضيف إليها JSON

قدمت APNIC البروتوكول في 2021 على أنه JSON عبر HTTP أو HTTPS، سهل التحليل آلياً، ويمكن لعميل واحد معالجة معظم ردود RDAP. وتفيد ذاكرة HTTP المؤقتة في تقليل الطلبات المتكررة. القيمة المقصودة هنا هي أن تعمل البرمجيات مباشرة، لا أن تعيد تمثيل واجهة بشرية.

يحدد RFC 9082 أنماط REST موحدة للاستعلام عن النطاقات وخوادم الأسماء والكيانات وشبكات IP والأنظمة المستقلة. ويحدد RFC 7480 طريقة استخدام HTTP. تطبيقات المتصفح عملاء صالحون، وتوجد أحكام للوصول بين الأصول، لكنها ليست الشكل الوحيد أو الأعلى مرتبة.

أداة سطر أوامر أو مكتبة أو نظام جرد أو منصة معالجة إساءة قد ترسل اسماً واضحاً ومحدوداً. عدم تشابهها مع Safari أو Chrome ليس خطأ بروتوكولياً. قد يكون أكثر صدقاً وفائدة للدعم من سلسلة طويلة مستعارة.

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

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

الفصل بين الحد من المعدل وتحدي الروبوت

يعترف RFC 7481 بأن الإتاحة وحجب الخدمة قضايا أمنية، ويسمح بتقييد عميل واحد واستخدام مصادقة HTTP عند الحاجة. ويوصي RFC 7480 بالحالة 429 عند الحد من المعدل؛ على العميل خفض وتيرته واحترام Retry-After إذا ورد.

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

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

قد تعيد صفحة تحدي HTML رمزاً يبدو ناجحاً، لكنها ليست application/rdap+json. وإذا سقط الطلب قبل المصدر فلن يظهر في عداد نجاح التطبيق أو فشله. لهذا لا يكفي قياس اتصال المنفذ أو الرمز وحده؛ يجب التحقق من نوع المحتوى ومن موضع القرار.

عينة سبتمبر الجيدة لا تتسع وحدها

في 5 سبتمبر 2026 عند 20:34 بالتوقيت العالمي، أُرسلت أربعة طلبات GET منخفضة الوتيرة إلى https://rdap.apnic.net/ip/202.12.29.0، وكلها تطلب application/rdap+json. لم يرسل الأول User-Agent صريحاً. استخدم الثاني User-Agent آلياً يصرّح بالغرض منه، والثالث curl/8.7.1، والرابع سلسلة شبيهة بـMozilla/Safari.

عادت الطلبات الأربعة بالحالة HTTP 200 ونوع المحتوى application/rdap+json. بلغ كل جسم 3,857 بايت، وتطابقت بصمته في الحالات كلها: d6983abd9266f7ac6d6a23b8b5cf67c186aae673a64030fc04e4e457837bb853. وبينت الترويسات وجود Cloudflare في المسار.

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

قيمة الاختبار تظهر حين يُعاد بانتظام وتُحفظ فروقه زمنياً. مرة ناجحة تقول إن اللحظة سليمة؛ سلسلة موثقة تقول متى تغير العقد التشغيلي.

سجل يشرح النتيجة من دون كشف القاعدة

لا تحتاج APNIC إلى نشر تعبيرات WAF أو العتبات أو قوائم السمعة. يمكنها أن تنشر ما يحتاجه مستخدم البروتوكول: هل تصل فئات العملاء المدعومة إلى نتيجة RDAP عبر المسار الفعلي؟

الحد الأدنى أربع عينات تملكها المؤسسة: من دون User-Agent، وأتمتة باسم واضح، وعميل سطر أوامر شائع، ومتصفح. لكل فئة، يُسجّل حكم الحافة ووصول الطلب إلى المصدر بصورة منفصلة، ثم فئة الحالة ونوع المحتوى والزمن ودلالة إعادة المحاولة حين يكون السبب حداً للمعدل.

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

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

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

حدود الادعاء

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

كذلك لا تثبت الحادثة أن APNIC أو Cloudflare تجاهل معياراً. تحدد RFCs سلوك البروتوكول ودلالات نافعة، أما ضوابط الأمن فتحتاج إلى حكم محلي. ما اعترفت به APNIC هو أثر إعداد غير مقصود. والسؤال القابل للإجابة هو: هل توجد الآن وسيلة تثبت أن الأثر سيُرى إذا عاد؟

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

المصادر

  1. APNIC، إعلان الخدمة في 28 يناير 2026
  2. مدونة APNIC، بنية جديدة لتقديم RDAP
  3. مدونة APNIC، هل أصبح RDAP جاهزاً ليحل محل whois؟
  4. مدونة APNIC، إتاحة خدمات السجل في الربع الثاني من 2025
  5. مدونة APNIC، تحديث الأمانة للربع الأول من 2026
  6. وثائق Cloudflare، Browser Integrity Check
  7. RFC 7480، استخدام HTTP في RDAP
  8. RFC 7481، خدمات الأمان في RDAP
  9. RFC 9082، صيغة استعلامات RDAP
  10. RFC 9110، دلالات HTTP