ما هو RDAP؟
RDAP (بروتوكول الوصول إلى بيانات التسجيل) هو بروتوكول حديث، موحّد وفق معايير IETF، للوصول إلى بيانات تسجيل أسماء النطاقات. وقد طُوّر ليكون خلفًا لـ WHOIS، إذ يوفّر RDAP استجابات منظّمة وقابلة للقراءة آليًا بصيغة JSON، مما يسهّل بدرجة كبيرة على المطورين دمج وظائف البحث عن النطاقات في تطبيقاتهم.
لماذا يهم RDAP المطورين؟
إذا سبق لك محاولة تحليل بيانات WHOIS، فأنت تعرف مدى صعوبة ذلك. فكل مسجّل نطاقات ينسّق استجاباته بطريقة مختلفة، ويستخدم أسماء حقول غير متسقة، ويعيد نصًا عاديًا غير منظّم يتطلب أنماطًا معقدة من التعبيرات النمطية لاستخراج المعلومات المفيدة. يحل RDAP هذه المشكلات من خلال مخطط JSON موحّد يعمل بصورة متسقة على جميع الخوادم المتوافقة مع RDAP.
المزايا التقنية الرئيسية
استجابات JSON منظّمة: تستخدم استجابات RDAP نموذج بيانات JSON الموحّد المحدد في RFC 9083. يمنح ذلك العملاء بنية متسقة لتحليلها، مع أن الخدمة قد تحذف بعض الحقول أو تحجبها وفقًا لسياسة الوصول الخاصة بها. بنية RESTful: يستخدم RDAP أساليب HTTP ورموز الحالة القياسية. يعيد طلب GET معلومات النطاق عندما يعثر الخادم على كائن مطابق. وتعني استجابة 404 أن الكائن الذي جرى الاستعلام عنه لم يُعثر عليه في تلك الخدمة، لكنها لا تثبت بمفردها أن النطاق قابل للتسجيل. HTTPS افتراضيًا: بخلاف WHOIS الذي ينقل البيانات بنص عادي عبر المنفذ 43، يستخدم RDAP بروتوكول HTTPS، مما يضمن اتصالًا مشفّرًا بين تطبيقك وخادم RDAP. دعم التدويل: يتعامل RDAP بصورة صحيحة مع IDN (أسماء النطاقات الدولية) وأحرف Unicode، وهو أمر أساسي للتطبيقات العالمية.كيف يعمل RDAP؟
عند الاستعلام عن نطاق من خلال RDAP، تتبع العملية الخطوات التالية:
1. اكتشاف Bootstrap: يستعلم عميلك من سجل IANA RDAP Bootstrap للعثور على خادم RDAP الموثوق المسؤول عن TLD
2. طلب HTTP: يُرسل طلب GET إلى عنوان URL لخادم RDAP (مثل https://rdap.verisign.com/com/v1/domain/example.com)
3. استجابة JSON: يعيد الخادم كائن JSON منظّمًا يحتوي على بيانات التسجيل ورموز الحالة والأحداث
مثال على بنية استجابة RDAP
{
"objectClassName": "domain",
"handle": "example.com",
"ldhName": "example.com",
"status": ["client transfer prohibited"],
"events": [
{"eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z"},
{"eventAction": "expiration", "eventDate": "2025-08-13T04:00:00Z"}
]
}
مقارنة بين RDAP و WHOIS
| الميزة | RDAP | WHOIS |
|---|---|---|
| تنسيق البيانات | JSON منظّم | نص غير منظّم |
| النقل | HTTPS (مشفّر) | نص عادي (المنفذ 43) |
| التوحيد القياسي | RFC 9082 و RFC 9083 | غير متسق |
| دعم IDN | أصلي | محدود |
| نوع الاستعلام | HTTP بأسلوب RESTful | بروتوكول مخصص |
تنفيذ RDAP في تطبيقاتك
بالنسبة إلى المطورين الذين يبنون أدوات النطاقات، يُعد RDAP النهج الموصى به. تستخدم معظم أدوات التحقق الحديثة من إتاحة النطاقات، ومنها DomScan، RDAP مصدرًا أساسيًا لبياناتها لأنه يوفّر:
- أدلة على الإتاحة: تعني استجابة 404 أن خادم RDAP الذي جرى الاستعلام عنه لم يعثر على كائن مطابق. لكنها لا تثبت بمفردها أن النطاق متاح للتسجيل
- بيانات وصفية غنية: الوصول إلى تواريخ التسجيل وتواريخ الانتهاء ورموز الحالة
- تحليل متسق: قاعدة برمجية واحدة تتعامل مع جميع TLDs
حالة اعتماد RDAP
بالنسبة إلى gTLDs، تقول ICANN إن RDAP أصبح المصدر الحاسم لمعلومات التسجيل في 28 يناير 2025، ولم تعد سجلات gTLDs ومسجّلوها مطالبين عمومًا بتوفير خدمات WHOIS، مع استثناءات تشمل .com و .name و .post. تختلف سياسات ccTLDs واعتماد RDAP من نطاق إلى آخر. يوفّر ملف IANA Bootstrap الموجود على https://data.iana.org/rdap/dns.json تعيينات خوادم RDAP الحالية لجميع TLDs المدعومة.
أفضل الممارسات
عند تنفيذ استعلامات RDAP، خزّن الاستجابات مؤقتًا بطريقة مناسبة لمراعاة حدود المعدل، ونفّذ آلية IANA Bootstrap لاكتشاف الخوادم، وتعامل مع استجابات عدم العثور وإعادة التوجيه والأخطاء المرتبطة بالسياسات بشكل منفصل. إن استجابة عدم العثور دليل على الخدمة التي جرى الاستعلام عنها، وليست إثباتًا لقابلية التسجيل.