RDRS في 2026: الدليل العربي العميق للوصول إلى بيانات تسجيل النطاقات غير العامة بعد عصر WHOIS

2026-09-16

تقرير معمق يشرح خدمة RDRS التابعة لـICANN، علاقتها بـRDAP وبيانات التسجيل غير العامة، وكيف يتعامل معها المختصون بالعلامات والأمن والجهات ذات المصلحة المشروعة في 2026.

أصبح الوصول إلى بيانات تسجيل أسماء النطاقات في 2026 ملفاً أكثر تعقيداً من الصورة التقليدية التي عرفها مستخدمو الإنترنت في عصر WHOIS المفتوح. فالمشهد الحالي يقوم على فصل واضح بين البيانات العامة التي يمكن الحصول عليها عبر خدمات التسجيل الحديثة، وبين البيانات غير العامة التي قد تتطلب سبباً مشروعاً وإجراءات منظمة قبل أن يقرر المسجل الإفصاح عنها. في قلب هذا التحول توجد خدمة Registration Data Request Service المعروفة اختصاراً باسم RDRS، وهي خدمة أنشأتها ICANN لتقديم مسار موحد ومنظم لإرسال طلبات الوصول إلى بيانات تسجيل gTLD غير العامة إلى المسجلين المشاركين. أهمية الخدمة لا تنبع من كونها قاعدة بيانات تكشف المعلومات، بل من كونها طبقة إجرائية تساعد الأطراف ذات المصلحة المشروعة على تقديم طلباتها بصيغة موحدة وقابلة للتتبع.

لفهم RDRS يجب أولاً التمييز بين ثلاثة أشياء كثيراً ما تختلط في النقاشات العربية: RDAP، وRDRS، وبيانات التسجيل نفسها. RDAP هو بروتوكول حديث أصبح المصدر الأساسي لتقديم معلومات تسجيل نطاقات gTLD بدلاً من WHOIS التقليدي، ويوفر بنية منظمة وقابلة للمعالجة آلياً مع دعم أفضل للتدويل والوصول الآمن. أما RDRS فليس بديلاً عن RDAP ولا محرك بحث عام عن مالكي النطاقات، بل قناة لطلب معلومات غير متاحة للعامة عندما تكون هناك مصلحة مشروعة. لهذا تبدأ ICANN إرشادات طالب البيانات بفكرة بسيطة: افحص أولاً ما إذا كانت المعلومات متاحة بالفعل عبر أداة Lookup المبنية على RDAP، ثم انتقل إلى RDRS إذا كانت البيانات المطلوبة غير عامة وكان لديك أساس مناسب للطلب.

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

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

في 2026 اكتسبت الخدمة أهمية إضافية بعد قرار مجلس ICANN استمرار تشغيل RDRS لمدة تصل إلى عامين إضافيين بعد نهاية المرحلة التجريبية في نوفمبر 2025، بينما يستمر العمل المجتمعي والسياساتي على الحل طويل الأجل للوصول والإفصاح. هذا التطور يوضح أن RDRS ليس مجرد تجربة انتهت، بل أصبح جسراً عملياً بين النظام الحالي والنقاش الأوسع حول System for Standardized Access/Disclosure أو SSAD. بالنسبة للسوق، هذا يعني أن المؤسسات التي تبني إجراءات داخلية للتحقيق في النطاقات ينبغي ألا تتعامل مع RDRS كأداة مؤقتة لا تستحق الاستثمار في فهمها، بل كجزء من منظومة الوصول الحالية التي قد تؤثر خبرتها التشغيلية وبيانات استخدامها في تصميم الحلول المستقبلية.

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

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

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

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

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

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

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

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

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

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

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

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

تصفح جميع مقالات مرصد النطاقات