سرویس RDAP چیست؟ (سرویس جایگزین Whois)
سرویس RDAP یک پروتکل مدرن برای دسترسی به داده‌های ثبت دامنه، آدرس‌های IP و شماره‌های AS است که جایگزین WHOIS شده است. این پروتکل توسط IETF توسعه یافته و قابلیت‌هایی مانند امنیت بهتر، پشتیبانی از احراز هویت، ساختار داده‌های استاندارد مبتنی بر JSON و امکان فیلترگذاری اطلاعات بر اساس سیاست‌های حریم خصوصی را ارائه می‌دهد. RDAP نسبت به WHOIS انعطاف‌پذیرتر بوده و برای مدیریت بهینه داده‌های ثبت اینترنتی طراحی شده است.
پروتکل RDAP چیست؟
سرویس RDAP مخفف Registration Data Access است و مفهوم آن از یک کارگروه در IETF گرفته شده است. پس از یک مرحله پروژه تقریبا چهار ساله، اولین نسخه از پروفایل پروتکل (1.0) در 26 جولای 2016 ظاهر شد که ویژگی‌ها و کاربردهای آن در درخواست‌های مختلف برای نظرات (RFC 7480-7484 و RFC 8056) مشخص شده است. RDAP امکان دسترسی به اطلاعات بیشتر در مورد منابع اولیه اینترنتی از جمله
- نام‌های دامنه
- آدرس‌های IP
- شماره‌های سیستم خودمختار (ASN)
به همین دلیل، جایگزین Whois مبنایی را برای ارسال کوئری‌ها به ثبت دامنه‌های مختلف فراهم می‌کند که شامل ارائه دیتابیس خود با، به عنوان مثال، جزئیات تماس برای صاحبان دامنه، جزئیات تماس برای هر سرپرست (Admin C)، یا حتی آدرس Name Server مورد استفاده، از جمله آدرس مدیر است.
چرا سرویس RDAP توسعه یافت؟
در سال 1982 IETF پروتکل Whois را با هدف داشتن یک سرویس درخواست برای چیزی که در آن زمان ARPANET نامیده می‌شد منتشر کرد. این واقعیت که پس از گذشت ربع قرن، اکنون برای پرسش‌های آنلاین مورد استفاده قرار می‌گیرد، چیزی است که خاری در چشم بسیاری از کارشناسان بوده است. امروزه انتقاد اصلی به Whois این است که دیگر الزامات فنی اینترنت را برآورده نمی‌کند.
یکی از مشکلات اصلی این است که پروتکل Whois قادر به کار با کدنویسی نیست و بنابراین هیچ پشتیبانی از متن غیر لاتین ارائه نمی‌دهد. یکی دیگر از نقاط ضعف اصلی این است که دسترسی به داده‌های دامنه از طریق یک اتصال امن انجام و تنظیم نشده است. حتی کاربران ناشناس (anonymous) نیز دسترسی کامل دارند و می‌توانند آدرس ایمیل و پستی را دریافت کنند.
پروژه‌هایی مانند افزونه Whois++ یا IRIS (سرویس اطلاعات رجیستری اینترنتی) Denic Protocol توانستند برخی پیشرفت‌ها را ارائه دهند، اما نتوانستند خود را به عنوان جایگزینی قدرتمندی برای Whois معرفی کنند. پس از مدت‌ها و بحث‌های فراوان در جامعه ICANN، در سپتامبر 2011، کمیته مشورتی امنیت و ثبات (SSAC) با گزارش امنیتی SAC 501 خود فشار قاطعی را برای زنده کردن کارگروه RDAP انجام داد.
در ژانویه 2023، ICANN یک رای گیری جهانی برای تصمیم گیری در مورد جایگزینی رسمی WHOIS با RDAP آغاز کرد. تعداد آرای لازم به دست آمد و تصمیم به اجرای رسمی تغییر به RDAP گرفته شد. از ژانویه 2025، رجیستری‌های DNS و ثبت‌کننده‌ها دیگر نیازی به پشتیبانی از WHOIS ندارند.
RDAP چگونه کار می‌کند؟
برای پیاده سازی سرویس RDAP، مهم است که ابتدا نحوه عملکرد پروتکل را در سمت کلاینت و سرور درک کنید. برای این کار، بهتر است نگاهی به RFCهای 7480 تا 7484 بیندازید، جایی که پیاده‌سازی مینیمال پروتکل به تفصیل شرح داده شده است. علاوه بر این، RFC های بیشتری وجود دارد که در آنها پسوندهای پروتکل RDAP توضیح داده شده است. در بخش بعدی، به طور تقریبی توضیح می‌دهیم که پروتکل چگونه از طریق HTTPS همانطور که در RFC 7840 توضیح داده شده است، کار می‌کند.
وظایف کلاینت:
پیاده سازی RDAP در سمت کلاینت اصلا پیچیده نیست. RDAP بر اساس HTTP ساخته شده، بنابراین از روش‌های HTTP موجود برای انتقال داده‌ها استفاده می‌کند. کلاینت‌ها می‌توانند با استفاده از متدهای GET و HEAD درخواست‌هایی را به سرور ارسال کنند. هر دو درخواست GET و HEAD باید شامل یک هدر Accept باشند که مشخص می‌کند کدام نوع از فایل‌های JSON توسط کلاینت پذیرفته می‌شود.
وظایف سرور:
پیاده سازی در سمت سرور کمی پیچیده‌تر است، زیرا سرور باید چند مورد خاص را پوشش دهد. در صورت موفقیت آمیز بودن درخواست، سرور باید داده‌های درخواستی را در قالب درخواستی با کد وضعیت HTTP 200 (OK) برگرداند. در درخواست‌های GET، سرور باید با داده‌های مالک درخواست‌شده پاسخ دهد و در درخواست‌های HEAD باید نشان دهد که آیا داده‌های موجود برای این دامنه را دارد یا خیر.
اگر می‌داند داده‌های درخواستی کجاست، اما خودش آن را ندارد، باید با یکی از کدهای وضعیت 301، 302، 303 یا 307 پاسخ دهد. URL که در آن داده‌ها را می‌توان یافت، سپس در زیر هدر HTTP لوکیشن (Location) ارسال می‌شود.
اگر سرور نمی‌تواند درخواست را پردازش کند زیرا داده‌های درخواستی در دسترس نیستند، باید با کد وضعیت 404 (Not Found) پاسخ دهد. اگر داده‌های درخواستی وجود دارد، اما سرور به دلایل دیگری نمی‌خواهد پاسخ دهد، باید با یک کد وضعیت مناسب از محدوده 400 پاسخ دهد. درخواست‌هایی که حاوی خطا هستند و نمی‌توانند به عنوان درخواست RDAP درک شوند باید با کد وضعیت 400 (Bad Request) پاسخ داده شوند. در این حالت، اطلاعات اضافی را می‌توان در بدنه موجودیت HTTP ارسال کرد.
برای اطلاعات دقیق تر در مورد فرآیند و همچنین امکانات امنیتی و گسترش پروتکل می توانید به RFCهای زیر مراجعه کنید.
- RFC 7840: HTTP Usage
- RFC 7841: Security Services
- RFC 7842: Query Format
- RFC 7843: JSON Responses
- RFC 7844: Finding the Authoritative Registration Data
چه چیزی RDAP را متفاوت می‌کند؟
از بسیاری جهات، RDAP یک نسخه بهبود یافته از Whois است. کار گروهIEFT بر روی نقاط ضعف پروتکل قدیمی تمرکز کرده است، به این معنی که به شدت روی مواردی مانند امنیت، ساختار و بین المللی سازی پروتکل کوئری جدید تمرکز کرده است. در نتیجه، چندین ویژگی جدید ظاهر شد، از جمله:
- معنایی درخواست و پاسخ ساختاریافته (از جمله پیام‌های خطای استاندارد)
- دسترسی ایمن به جزئیات تماس درخواستی (به عنوان مثال از طریق HTTPS)
- قابلیت گسترش (به عنوان مثال افزودن عناصر خروجی)
- مکانیسم Bootstrapping (پشتیبانی شده توسط جستجوی یک سرور DNS معتبر مناسب)
- ارسال استاندارد کوئری‌ها
- مبتنی بر وب (HTTP) و سازگار با REST
- ترجمه آسان داده‌های خروجی
- امکان اعطای دسترسی متفاوت (differentiated access) به اطلاعات تماس
در بسیاری از جنبه‌ها، سرویس RDAP ثابت کرده است که بسیار انعطاف‌پذیرتر از نسخه قبلی خود است. در حالی که Whois، به عنوان یک پروتکل مبتنی بر متن، به TCP و پورت TCP خاص (43) متکی است، RDAP از HTTP استاندارد وب یا حتی HTTPS استفاده می‌کند. تمام داده‌ها در قالب JSON استاندارد و قابل خواندن توسط ماشین تحویل داده می‌شوند. این بدان معنی است که از یک طرف، RDAP آزادی بیشتری را در هنگام درخواست داده‌ها فراهم می‌کند، در حالی که برنامه‌نویسی سرویس‌های کوئری را که می‌توانند با مقامات مختلف ثبت ارتباط برقرار کنند، در حالی که داده‌های درخواستی را به زبان‌های مختلف خروجی می‌دهند، آسان‌تر می‌کند.
جمع‌بندی
بدون شک یکی از مهمترین توابع جدیدی که در سرویس RDAP پیاده سازی شده است، امکان ارائه حقوق دسترسی مختلف برای گروه‌های کاربری فردی است که به ثبت کننده اجازه می‌دهد تا با جزئیات تنظیم کند که چه کسی می‌تواند چه اطلاعاتی را ببیند. تا دسترس کاربران ناشناس محدود شده در حالی که کاربران مجاز می‌توانند کل مجموعه داده را مشاهده کنند. این جنبه ای است که در آن بسیاری از مردم نیاز به الزامات شفاف سازی حیاتی را می‌بینند.
اولویت حفاظت از داده‌های کاربر و اعتماد به اپراتور وب‌سایت است که دامنه‌ای را که با آن ارائه می‌شود ثبت می‌کند. و به هیچ وجه نباید این اعتماد توسط فناوری جدید درخواست RDAP به خطر بیفتد. در پایان سال 2016، تعدادی از رجیستری ها علیه دوره اجرایی تحمیل شده توسط ICANN تجدید نظر کردند و این بدان معناست که این سازمان تصمیم گرفته است برای RDAP قراردادهایی با ثبت کنندگان و ارائه دهندگان دامنه منعقد کند.