سرویس RDAP چیست و چرا جایگزین WHOIS شد؟ + آموزش عملی استعلام دامنه و IP

استعلام دامنه گرفته‌اید اما نام یا ایمیل صاحب آن را نمی‌بینید؟ شاید بپرسید rdap چیست و چرا به‌جای WHOIS از آن استفاده می‌شود. RDAP اطلاعات ثبت دامنه، IP و ASN را ساختاریافته نمایش می‌دهد، اما تمام اطلاعات مالک لزوماً عمومی نیست. اگر می‌خواهید بدانید RDAP چیست، چه تفاوتی با هویز دارد و چگونه استعلام بگیرید، در ادامه همراه ما باشید.

معرفی سرویس RDAP و کاربردهای آن

برای توضیح اینکه rdap چیست، ابتدا باید نام کامل آن را بشناسیم که عبارت است از: Registration Data Access Protocol. این سرویس برای دریافت داده‌های ثبت دامنه، شبکه‌های IPv4 و IPv6 و شمارۀ سیستم خودمختار یا ASN به کار می‌رود. پروتکل RDAP با مشخص‌کردن شیوۀ ارسال درخواست و ساختار پاسخ، به برنامه‌ها کمک می‌کند اطلاعات مورد نیازشان را از فیلدهای مشخص بخوانند؛ در نتیجه، پردازش داده‌ها به قالب متنی هر ارائه‌دهنده وابسته نخواهد بود.

البته اطلاعات ثبت، لزوماً هویت واقعی استفاده‌کننده نهایی را نشان نمی‌دهند؛ برای مثال، رکورد یک بلوک IP ممکن است نام شرکت ارائه‌دهنده را برگرداند، درحالی‌که مشترک از خدمات همان شرکت استفاده می‌کند. برای درک کاربرد این سرویس باید تفاوت آن با DNS را هم در نظر گرفت: RDAP داده‌های ثبت را می‌خواند و تبدیل نام سایت به نشانی مقصد، وظیفۀ آن نیست.

توسعه توسط IETF و الزام اجرای ICANN

کارگروه مهندسی اینترنت، IETF، مجموعۀ اولیۀ استانداردهای RDAP را در مارس ۲۰۱۵ منتشر کرد و پس از آن، ابلاغیۀ رسمی ICANN در سال ۲۰۱۹، رجیستری‌ها و رجیسترارهای gTLD را موظف کرد این سرویس را حداکثر تا ۲۶ اوت همان سال راه‌اندازی کنند. این دو گروه نقش متفاوتی در ثبت دامنه دارند: رجیستری پایگاه اصلی یک پسوند را مدیریت می‌کند، درحالی‌که رجیسترار خدمات ثبت را به متقاضی ارائه می‌دهد.

در ادامۀ این روند، طبق اطلاعیه ICANN در ژانویه ۲۰۲۵، از ۲۸ ژانویۀ آن سال RDAP مرجع ارائۀ اطلاعات ثبت gTLDها شد؛ بااین‌حال، پایان الزام WHOIS را نباید به معنی خاموش‌شدن جهانی آن دانست. صفحۀ مرجع ICANN برای این الزام، استثناهای com. و name. و post. را ذکر می‌کند و وضعیت پسوندهای کشوری یا ccTLD و منابع IP/ASN نیز مستقل از این تغییر است.

اگرچه استانداردهای اولیه RFC 7480 تا 7484 نقطۀ شروع RDAP بودند، اما برای پیاده‌سازی آن باید به نسخه‌های به‌روز اسناد مراجعه کنید؛ زیرا RFC 9082 جایگزین 7482، RFC 9083 جایگزین 7483 و RFC 9224 جایگزین 7484 شده‌اند.

دلایل مهاجرت از WHOIS به rdap چیست

برای درک اینکه rdap چیست و چرا مطرح شد، باید محدودیت‌های هویز را شناخت. هویز سال‌ها برای استعلام اطلاعات ثبت دامنه‌ها استفاده می‌شد، اما با گسترش تبادل داده میان نرم‌افزارها، محدودیت‌های طراحی ساده آن بیشتر به چشم آمد. پروتکل whois پاسخ را به‌صورت متن برمی‌گرداند و چون قالب پاسخ و سازوکارهای امنیتی یکپارچه‌ای ندارد، خواندن و پردازش نتیجه نزد ارائه‌دهندگان مختلف می‌تواند متفاوت باشد. برای شناخت دقیق‌تر این محدودیت‌ها می‌توان به RFC 3912 مراجعه کرد؛ 4 مورد زیر نشان می‌دهند که چرا تفاوت RDAP با هویز، فراتر از تغییر ظاهر پاسخ است:

1. قالب متن بین ارائه‌دهندگان متفاوت است و استخراج خودکار تاریخ‌ها یا اطلاعات تماس را دشوار می‌کند.
2. روشی استاندارد برای اعلام کدگذاری متن ندارد و این مشکل با نبود مطلق امکان نمایش زبان‌های دیگر یکسان نیست.
3. سازوکار ذاتی برای محرمانگی، کنترل دسترسی و حفاظت از تمامیت داده فراهم نمی‌کند.
4. اتصال سنتی آن بر پروتکل TCP و پورت ۴۳ استوار است؛ RDAP از امکانات درخواست و پاسخ وب استفاده می‌کند.

تفاوت WHOIS و RDAP چیست؟

تفاوت whois و rdap به ظاهر خروجی محدود نمی‌شود. در RDAP، شیوۀ دسترسی، کدگذاری داده و امکان تعیین مجوز نیز تغییر کرده است. برای ارزیابی این تفاوت‌ها، باید قابلیت‌های پیش‌بینی‌شده در پروتکل را در کنار سیاست و نحوۀ اجرای آن نزد هر ارائه‌دهنده بررسی کرد، چون پشتیبانی از یک قابلیت به معنی اجرای یکسان آن در همه سرویس‌ها نیست.

جدول زیر تفاوت‌های اصلی را در یک نگاه نشان می‌دهد. فقط هنگام مقایسه بخش‌های امنیت و حریم خصوصی، در نظر داشته باشید که وجود یک قابلیت به‌تنهایی اجرای درست آن را تضمین نمی‌کند.

ویژگی	WHOIS سنتی	RDAP
ارتباط	TCP روی پورت ۴۳	وب مبتنی بر HTTP؛ پشتیبانی الزامی از HTTPS
قالب پاسخ	متن با قالب‌های متفاوت	JSON ساختاریافته
دسترسی	فاقد سازوکار ذاتی یکپارچه	امکان احراز هویت و تعیین مجوز
حریم خصوصی	وابسته به سیاست انتشار	دسترسی تفکیک‌شده؛ انطباق حقوقی خودکار نیست
چندزبانی	کدگذاری یکپارچه تعریف نشده	پشتیبانی استاندارد از UTF-8 و نام‌های بین‌المللی
مدیریت خطا	پیام متنی وابسته به سرویس	کد HTTP و امکان بدنۀ خطای JSON

سازوکار پروتکل RDAP در درخواست و پاسخ

برای فهم فنی اینکه rdap چیست، باید به سازوکار درخواست آن نگاه کنیم. RDAP از الگوی RESTful استفاده می‌کند؛ به این معنی که هر منبع نشانی مشخصی دارد و کلاینت برای خواندن اطلاعات آن معمولاً درخواست GET می‌فرستد. RFC 7480 نحوۀ استفاده از HTTP را توضیح می‌دهد و پشتیبانی کلاینت و سرویس‌دهنده از HTTPS را الزامی می‌داند، بنابراین برای محافظت از ارتباط هنگام استعلام باید نشانی HTTPS سرویس را به کار ببرید.

پیش از ارسال درخواست، لازم است سرور پاسخ‌گوی معتبر را پیدا کنید تا استعلام به سرویس مسئول همان منبع برسد. رجیستری‌های Bootstrap در IANA برای همین منظور، نشانی سرویس مرتبط با پسوند دامنه، محدودۀ IP یا ASN را معرفی می‌کنند؛ فرایندی که در RFC 9224 توضیح داده شده و شما را از تکیه بر یک نشانی حدسی برای تمام منابع بی‌نیاز می‌کند.

مزایای خروجی ساختاریافته JSON در RDAP

مزیت ساختار JSON این است که برنامه می‌تواند هر داده را از فیلد مشخص آن بخواند؛ برای نمونه، در RFC 9083، فیلد objectClassName نوع شیء، status وضعیت و events رویدادها را توصیف می‌کنند. این نظم، نیاز به تحلیل قالب‌های متنی متفاوت را کاهش می‌دهد، اما مسئولیت بررسی پاسخ را از برنامه نمی‌گیرد. به این معنا که فیلد غایب یا پاسخ نامعتبر همچنان باید مدیریت شود و استفاده از JSON به‌خودی‌خود تضمین‌کنندۀ امنیت نیست.

مفهوم کدهای وضعیت و خطای 404

برای خواندن نتیجۀ استعلام، ابتدا کد وضعیت را بررسی کنید: درخواست موفق معمولاً با ۲۰۰ برمی‌گردد، درحالی‌که ۴۰۰ به درخواست نامعتبر، ۴۰۱ به نبود اعتبارنامه معتبر و ۴۰۳ به رد دسترسی اشاره دارد. اگر کد 404 دریافت کردید، منبع درخواست‌شده در آن سرویس یافت نشده است؛ بااین‌حال، از این پاسخ نمی‌توان نتیجه گرفت که نام دامنه برای خرید آزاد است، چون ممکن است نام مورد نظر رزروشده باشد.

در مقابل، دریافت کد ۴۲۹ یعنی باید تعداد درخواست‌ها را کاهش دهید و اگر پاسخ شامل Retry-After بود، زمان انتظار اعلام‌شده را رعایت کنید. بخش محدودیت نرخ در RFC 7480 همین رفتار را برای کلاینت توصیه می‌کند، بنابراین تکرار سریع درخواست به رفع این خطا کمکی نمی‌کند.

چه اطلاعاتی را می‌توان از سرویس RDAP گرفت؟

هنگام بررسی اینکه RDAP چیست، نوع منبع اهمیت زیادی دارد؛ به این دلیل که اطلاعاتی که در پاسخ می‌بینید به نوع منبع و سیاست انتشار سرویس بستگی دارد. برای مثال، رکورد دامنه، شبکۀ IP و ASN فیلدهای یکسانی ندارند. به همین دلیل، اگر فیلدی در نتیجه وجود نداشت، ابتدا نوع رکورد و توضیحات پاسخ را بررسی کنید و نبود آن را فوراً به خطای سرویس نسبت ندهید.

در تفسیر همین اطلاعات، توجه به نقش اشخاص و شرکت‌ها نیز ضروری است؛ نام رجیسترار یا شرکت ثبت‌کننده، لزوماً نام شخص یا سازمانی نیست که صاحب‌امتیاز دامنه است. تفکیک این دو نقش کمک می‌کند مشخصات ارائه‌دهندۀ خدمات را با اطلاعات مالک دامنه اشتباه نگیرید.

اطلاعات ثبت، انقضا و وضعیت دامنه

در استعلام دامنه ممکن است نام رجیسترار، وضعیت انتقال، نام‌سرورها و رویدادهای ثبت یا انقضا را ببینید، اما نباید انتظار داشت تمام جزئیات در هر پاسخ موجود باشند. برای درک اینکه rdap چیست، باید تفاوت اطلاعات ثبت عمومی و اطلاعات تماس غیرعمومی را هم شناخت. برای مثال، تاریخ تمدید همیشه به‌صورت فیلدی مستقل منتشر نمی‌شود و نام یا ایمیل صاحب‌امتیاز نیز ممکن است غیرعمومی باشد؛ راهنمای ICANN Lookup به شما کمک می‌کند بخش‌های مختلف نتیجه را با توجه به همین محدودیت‌ها بخوانید.

استعلام دامنه‌های ‎.ir و تفاوت آن با دامنه‌های بین‌المللی

در مورد پسوند کشوری ‎.ir شرایط متفاوت است. مطابق رکورد رسمی IANA، برای ‎.ir در حال حاضر نشانی پایه RDAP معرفی نشده است؛ بنابراین نباید انتظار داشت استعلام آن دقیقاً مانند دامنه‌های ‎.com از طریق RDAP انجام شود. همچنین برای بررسی اطلاعات ثبت ‎.ir از سامانه رسمی ایرنیک در nic.ir و سرویس WHOIS آن در whois.nic.ir استفاده کنید. نبود سرویس RDAP معرفی‌شده برای این پسوند به معنای ثبت‌نشدن دامنه نیست. برای آدرس‌های IP تخصیص‌یافته در ایران نیز مرجع منطقه‌ای مربوط RIPE NCC است و اطلاعات ثبت شبکه و ASN را می‌توان از پایگاه آن پیگیری کرد.

بلوک‌های IP و شمارۀ سیستم خودمختار

رجیستری‌های منطقه‌ای اینترنت یا RIRها، اطلاعات تخصیص منابع شماره‌ای را نگهداری می‌کنند و طبق مستندات ARIN، می‌توان از RDAP برای خواندن داده‌های ثبت شبکه‌ها و ASN استفاده کرد. اگر پرسش شما این است که آدرس آی پی من چیست، ابتدا IP عمومی اتصال را پیدا کنید و سپس از سرویس مسئول آن محدوده استعلام بگیرید؛ البته نتیجۀ این استعلام را نباید نشانی دقیق محل زندگی کاربر تلقی کرد.

نقش کنترل دسترسی در RDAP چیست؟

یکی از بخش‌های مهم پاسخ به پرسش RDAP چیست، کنترل دسترسی به اطلاعات ثبت است. کنترل دسترسی تفکیک‌شده به سرویس‌دهنده امکان می‌دهد متناسب با هویت، مجوز و سیاست خود، اطلاعات متفاوتی را به کاربران نشان دهد. RFC 7481 این قابلیت را توضیح می‌دهد، اما چون نحوۀ اجرای آن در تمام سرویس‌ها یکسان نیست، صرف ورود به حساب یا احراز هویت به معنی دریافت مجوز مشاهدۀ تمام اطلاعات تماس نخواهد بود.

علاوه بر مجوز دسترسی، قوانین حفاظت از داده مانند GDPR، مقررات محلی و سیاست‌های انتشار نیز بر اطلاعات قابل‌نمایش اثر می‌گذارند؛ بنابراین استفاده از RDAP به‌تنهایی انطباق حقوقی ایجاد نمی‌کند. طبق راهنمای ICANN، برای پیگیری داده‌های غیرعمومی می‌توان به RDRS نزد رجیسترارهای مشارکت‌کننده یا فرایند افشای خود رجیسترار مراجعه کرد، اما بررسی و پذیرش درخواست همچنان به ضوابط مربوط بستگی دارد.

با توجه به این محدودیت‌ها، نمایش‌ندادن نام، تلفن یا ایمیل الزاماً نشانه خرابی RDAP نیست و بهتر است ابتدا توضیحات پاسخ را بخوانید و اگر برای پیگیری قانونی به این اطلاعات نیاز دارید، مسیر درخواست داده‌های غیرعمومی را بررسی کنید.

روش استعلام با RDAP چیست؟

برای اینکه در عمل ببینید RDAP چیست، هنگام استعلام معمولی کافی است ICANN Lookup را در مرورگر باز کنید و نام دامنه را وارد کنید؛ سپس در نتیجه، وضعیت‌ها، تاریخ‌ها و نام رجیسترار را بررسی کنید تا تصویر روشن‌تری از اطلاعات ثبت آن به دست آورید.

نتیجه‌ای که در این ابزار می‌بینید، نمایش خوانای پاسخ سرویس است و برای مشاهدۀ آن به نصب نرم‌افزار جداگانه‌ای نیاز ندارید. بااین‌حال، دامنۀ پوشش و اطلاعات قابل‌نمایش به سرویس‌های پاسخ‌گو وابسته است؛ اگر جزئیاتی در نتیجه نبود، آن را با توجه به محدودیت‌های انتشار بررسی کنید.

اگر به‌جای ابزار مرورگری، درخواست مستقیم می‌فرستید، ابتدا فایل Bootstrap دامنه در IANA را بررسی کنید و URL پایۀ سرویس مربوط را بردارید. سپس مسیر مناسب را به آن اضافه کنید: طبق RFC 9082، مسیر دامنه /domain/، مسیر IP برابر /ip/ و مسیر ASN برابر /autnum/ است. این روش برای Lookup یا بررسی یک شناسۀ مشخص به کار می‌رود؛ Search نیز به جست‌وجوی الگویی اشاره دارد و نباید پشتیبانی از آن را در همه سرویس‌ها فرض کرد.

گام استعلام IP یا ASN: اگر به‌جای دامنه، یک نشانی IP یا شمارۀ AS دارید، ابتدا مرجع مسئول آن را از Bootstrap مربوط در IANA بیابید. برای منابع ثبت‌شده در محدودۀ RIPE NCC، از سرویس رسمی RIPE Database استفاده کنید. نمونه دستور استعلام IP از مستندات خود RIPE NCC:

curl -LsS "https://rdap.db.ripe.net/ip/2001:67c:2e8:9::c100:14e6"

برای ASN نیز مسیر /autnum/ را به نشانی پایه سرویس مسئول اضافه کنید. برای نمونه در سامانۀ RIPE NCC الگوی درخواست به صورت https://rdap.db.ripe.net/autnum/AS_NUMBER است که باید AS_NUMBER را با شمارۀ واقعی و قابل‌استعلام جایگزین کنید. مالکیت یا محل استفاده IP را صرفاً از روی موقعیت جغرافیایی نتیجه قطعی نگیرید.

 

نمونۀ زیر، درخواست HTTP به سرویس RDAP دامنه‌های «‎«.com است که نشانی و مسیر آن واقعی‌اند:

GET /com/v1/domain/mobinhost.com HTTP/1.1

Host: rdap.verisign.com

Accept: application/rdap+json

برای بررسی یک نمونۀ واقعی، دامنۀ مبین‌هاست (mobinhost.com) را از سرویس RDAP رجیستری ‎.com استعلام می‌گیریم. نشانی زیر متعلق به سرویس Verisign است و با افزودن نام دامنه، درخواست به رکورد ثبت آن ارسال می‌شود. دامنۀ mobinhost.com در این آموزش صرفاً یک نمونه واقعی است و برای استعلام دامنۀ خودتان، نام mobinhost.com را در انتهای نشانی با نام دامنه موردنظر جایگزین کنید. توجه داشته باشید که این نشانی مخصوص پسوند ‎.com است و برای پسوندهای دیگر باید ابتدا سرویس RDAP مرتبط را پیدا کنید:

curl -L -sS -i -H "Accept: application/rdap+json" "https://rdap.verisign.com/com/v1/domain/mobinhost.com"

آموزش استعلام واقعی دامنه با curl در ویندوز

در ویندوز ۱۰ و ۱۱، کلیدهای Win + R را بزنید و با واردکردن cmd یا powershell، پنجرۀ Command Prompt یا PowerShell را باز کنید. در این آموزش، نمونۀ واقعی در Command Prompt ویندوز اجرا شده است. دستور زیر را بدون حذف علامت نقل‌قول پایانی و به‌صورت یک خط کامل وارد کنید. با افزودن گزینۀ ‎-i، سرآیندهای HTTP هم کنار پاسخ نشان داده می‌شوند:

curl.exe -L -sS -i -H "Accept: application/rdap+json" "https://rdap.verisign.com/com/v1/domain/mobinhost.com"

[محل تصویر ۱: اسکرین‌شات واقعی اجرای دستور در Command Prompt ویندوز، همراه با فرمان کامل و سرآیند HTTP/1.1 200 OK]

در آزمایش انجام‌شده روی دامنه mobinhost.com در ۱۶ آبان ۱۴۰۵ (۷ نوامبر ۲۰۲۶)، سرویس پاسخ HTTP/1.1 200 OK را همراه با Content-Type: application/rdap+json برگرداند. کد ۲۰۰ نشان می‌دهد درخواست با موفقیت پاسخ داده شده و نوع محتوا مشخص می‌کند که بدنۀ نتیجه، دادۀ RDAP در قالب JSON است. این نتیجه مربوط به زمان انجام استعلام است و ممکن است جزئیات رکورد در آینده تغییر کنند.

در خروجی، مقدار objectClassName برابر domain و مقدار ldhName برابر MOBINHOST.COM است. فیلد handle شناسۀ رکورد دامنه در رجیستری را نشان می‌دهد. در بخش entities، نقش registrar به شرکت Hosting Concepts B.V. d/b/a Registrar.eu اختصاص دارد. این نام، ثبت‌کنندۀ دامنه است و لزوماً نام مالک آن نیست. بنابراین، نبود ایمیل یا نام صاحب‌امتیاز در این پاسخ، به معنای ناموفق‌بودن استعلام نیست.

[محل تصویر ۲: اسکرین‌شات واقعی بخش JSON، شامل objectClassName، handle، ldhName و در صورت امکان رویدادهای registration و expiration]

برای خواندن تاریخ‌ها، بخش events را بررسی کنید. در پاسخ ثبت‌شده، registration برابر 2011-10-10T11:40:28Z و expiration برابر 2032-10-10T11:40:28Z است. حرف Z نیز به زمان UTC اشاره دارد. عبارت client transfer prohibited در بخش status نیز نشان می‌دهد انتقال دامنه در وضعیت فعلی با محدودیت ثبت‌شده روبه‌رو است، نه اینکه دامنۀ منقضی شده باشد. اگر به‌جای این نتیجه خطای DNS مانند Could not resolve host دیدید، ابتدا اینترنت و تنظیمات DNS را بررسی کنید.

در این دستور، هدر Accept قالب RDAP JSON را درخواست می‌کند و گزینه‌های ‎-L، ‎-sS و ‎-i به‌ترتیب دنبال‌کردن تغییر مسیر، نمایش خطا بدون نوار پیشرفت و نمایش هدرهای پاسخ را بر عهده دارند. برای بررسی صحت نتیجه، فقط به کد ۲۰۰ بسنده نکنید و نام دامنه در ldhName، نوع رکورد و رویدادهای ثبت را هم بخوانید. خروجی رجیستری ممکن است تمام اطلاعات تماس صاحب‌امتیاز را شامل نشود و برای جزئیات بیشتر، لینک سرویس رجیسترار در فیلد links نیز قابل بررسی است.

نمونه زیر بخشی انتخاب‌شده از پاسخ واقعی RDAP برای mobinhost.com در ۷ نوامبر ۲۰۲۶ است. برای کوتاه‌ماندن نمونه، سایر فیلدهای پاسخ حذف شده‌اند؛ بنابراین این قطعه، خروجی کامل سرویس نیست:

{

  "objectClassName": "domain",

  "handle": "1681392074_DOMAIN_COM-VRSN",

  "ldhName": "MOBINHOST.COM"

}

جمع‌بندی

اکنون که دیدیم rdap چیست، می‌توان کاربرد آن را در دسترسی منظم به اطلاعات ثبت منابع اینترنتی خلاصه کرد: وبمسترها پاسخ خواناتری برای بررسی اطلاعات دارند و توسعه‌دهندگان می‌توانند داده‌ها را از فیلدهای مشخص پردازش کنند. البته ارزش این ساختار زمانی روشن می‌شود که نتیجه را با توجه به مرجع پاسخ و محدودیت انتشار اطلاعات تفسیر کنیم.

برای استفادۀ درست از نتیجۀ استعلام، ابتدا سرویس مسئول منبع را پیدا کنید و سپس وضعیت‌ها و توضیحات همان پاسخ را بخوانید؛ به‌ویژه، اطلاعات منتشرنشده را با نبود رکورد یکی نگیرید. اگر هدف شما خرید یا انتقال دامنه است، این بررسی را با تطبیق نتیجه با شرایط ثبت نزد ارائه‌دهنده کامل کنید تا تصمیم شما تنها بر یک فیلد یا کد وضعیت تکیه نداشته باشد.

سوالات متداول

آیا RDAP به‌طور کامل جایگزین WHOIS شده است؟

دلیل مخفی‌بودن ایمیل صاحب دامنه در RDAP چیست؟

تفاوت خروجی WHOIS و RDAP چیست؟

آیا RDAP برای استفاده به نصب نرم‌افزار نیاز دارد؟