منذ 1982 وWHOIS هو الطريقة الوحيدة لمعرفة من يملك نطاقاً. بعد 40 سنة، حلّ محله بروتوكول جديد وأكثر أماناً اسمه RDAP. سنشرح في هذا المقال الفرق، الأسباب، وما الذي تغيّر بعد قانون GDPR الأوروبي.
WHOIS: البروتوكول الذي بدأ كل شيء
تخيل الإنترنت في 1982: عدد قليل من الجامعات والمراكز البحثية. كان من الطبيعي أن تعرف من يملك أي نطاق. فجاء بروتوكول WHOIS بسيطاً جداً:
- تتصل بخادم WHOIS على المنفذ 43.
- ترسل اسم النطاق متبوعاً بـ
\r\n. - تستقبل نصاً حراً يحوي البيانات.
- تغلق الاتصال.
هذه البساطة كانت قوة وضعفاً في الوقت نفسه.
المشاكل الموروثة في WHOIS
- غير مشفر: أي أحد على الشبكة يستطيع اعتراض الاستعلام.
- نص حر بدون تنسيق: كل Registry يكتب البيانات بشكل مختلف، مما يصعّب تحليلها برمجياً.
- لا توجد آلية مصادقة: أي أحد يستطيع الاستعلام عن أي شيء.
- لغة إنجليزية فقط: لا دعم لـ Unicode في الاستعلامات.
- كشف بيانات شخصية: اسم وعنوان وهاتف المالك متاح للجميع.
زلزال GDPR في 2018
عندما دخل قانون GDPR الأوروبي حيز التنفيذ في مايو 2018، اصطدم بشكل مباشر مع WHOIS. القانون يفرض حماية البيانات الشخصية، بينما WHOIS يكشفها بشكل افتراضي.
كانت النتيجة فورية:
- معظم الـ Registrars بدأوا "حجب" (Redact) البيانات الشخصية.
- المعلومات أصبحت تظهر كـ
REDACTED FOR PRIVACYأوData Protected. - التحقيقات الأمنية والقانونية أصبحت أصعب.
- ICANN بدأت العمل على بديل: RDAP.
RDAP: البديل الحديث
RDAP (اختصار Registration Data Access Protocol) صُمم من الصفر لمعالجة كل عيوب WHOIS:
المميزات التقنية
- HTTPS: كل اتصال مشفر افتراضياً.
- JSON: بيانات منظمة قابلة للتحليل البرمجي بسهولة.
- دعم كامل لـ Unicode: النطاقات بالعربية، الصينية، إلخ.
- RESTful API: يستخدم HTTP standard methods (GET).
- Bootstrap System: آلية اكتشاف ذكية للخادم الصحيح.
- طبقة مصادقة: يمكن للجهات المخولة (الشرطة، المحاكم) الوصول لبيانات محجوبة.
مقارنة عملية: WHOIS vs RDAP
| المقارنة | WHOIS | RDAP |
|---|---|---|
| السنة | 1982 | 2015 (ICANN-mandated 2019) |
| المنفذ | 43 (TCP) | 443 (HTTPS) |
| التشفير | ❌ | ✅ |
| صيغة البيانات | نص حر | JSON منظم |
| دعم Unicode | محدود | كامل |
| اكتشاف الخادم | يدوي | تلقائي عبر IANA Bootstrap |
| المصادقة | ❌ | ✅ (للجهات المخولة) |
| مدعوم في | كل المسجلين | ~85% (يتزايد) |
كيف تعمل RDAP عملياً؟
عندما تستعلم عن دومين مثل example.com:
- طلب IANA Bootstrap: الأداة تسأل IANA: "أي خادم RDAP يدير
.com؟" - استلام الـ URL: IANA تجيب بـ
https://rdap.verisign.com/com/v1/ - الاستعلام: الأداة ترسل
GET https://rdap.verisign.com/com/v1/domain/example.com - JSON: الخادم يرجع JSON منظم بكل البيانات.
عند فحص أي دومين عبر Wep.tools، نمر بنفس الخطوات تلقائياً.
مثال على استجابة RDAP
{
"ldhName": "example.com",
"events": [
{ "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
{ "eventAction": "expiration", "eventDate": "2026-08-13T04:00:00Z" }
],
"entities": [
{ "roles": ["registrar"], "vcardArray": [...] }
],
"nameservers": [
{ "ldhName": "a.iana-servers.net" }
]
}متى تستخدم WHOIS ومتى RDAP؟
استخدم RDAP عندما:
- تتعامل مع gTLDs الحديثة (.com, .net, .org, .io, .dev, .app).
- تبني تطبيقاً برمجياً (JSON أسهل من تحليل النص).
- الأمان والخصوصية مهمان.
- تحتاج اكتشاف تلقائي للخادم.
استخدم WHOIS عندما:
- تتعامل مع ccTLDs قديمة لا تدعم RDAP بعد (.de, .ru, .jp).
- تحتاج بيانات ليست متاحة في RDAP.
- تختبر مباشرة بدون أدوات وسيطة.
كيف نستخدم في Wep.tools كلا البروتوكولين؟
أداتنا مصممة بـ 4-tier fallback لضمان دعم 100% من الامتدادات:
- نحاول RDAP أولاً (سريع، JSON).
- إذا فشل، نستخدم خريطة WHOIS مسبقة (100+ خادم).
- إذا لم يكن في الخريطة، نخمن النمط
whois.nic.{tld}. - إذا فشل، نسأل IANA Bootstrap.
هذا يضمن أن أي دومين شرعي يحصل على نتيجة، حتى لو الامتداد جديد جداً.
الخلاصة
RDAP ليس بديلاً تاماً لـ WHOIS بعد، لكنه المستقبل. الشركات الجادة في تطوير أدوات الدومينات يجب أن تدعم الاثنين.
أما من ناحية الخصوصية: GDPR كان نعمة. حماية بياناتك كمالك دومين أصبحت افتراضية في معظم الـ Registrars، وهذا تطور إيجابي.