انتقال دامنه بین رجیسترارها؛ چک‌لیست امن و بدون قطعی

یک فروشگاه ایرانی می‌خواست فقط «شرکت ثبت‌کننده دامنه» را عوض کند؛ اما هم‌زمان نام‌سرورها، ایمیل مدیر دامنه و اطلاعات مالک را هم تغییر داد. انتقال معطل شد، DNSSEC خطا داد و ایمیل‌های سفارش به مقصد نرسید. مشکل از خود انتقال نبود؛ چند تغییر پرریسک بدون مرز، مالک و راه بازگشت در یک پنجره اجرا شده بود.

انتقال دامنه اگر درست طراحی شود، معمولاً نباید URL، محتوای سایت یا رکوردهای DNS را تغییر دهد. بااین‌حال سرویس DNS، حریم خصوصی، تمدید خودکار یا ایمیل ممکن است به رجیسترار فعلی وابسته باشد. این راهنما برای مالک کسب‌وکار، مدیر فنی و مسئول عملیات است تا انتقال بین رجیسترارها را مانند یک تغییر کنترل‌شده اجرا کنند: با Inventory، کنترل دسترسی، شواهد، آزمون و برنامه واکنش به حادثه.

اول مسئله را درست نام‌گذاری کنید

در فارسی همه تغییرهای مرتبط با دامنه گاهی «انتقال دامنه» نامیده می‌شوند، اما مسیر و ریسک آن‌ها یکسان نیست:

اگر هدفتان هنوز روشن نیست، ابتدا نقش دامنه، رجیستری، رجیسترار، DNS و هاست را در راهنمای انتخاب و ثبت دامنه تفکیک کنید. عوض‌کردن فروشنده هاست الزاماً انتقال رجیسترار نمی‌خواهد و عوض‌کردن رجیسترار نیز الزاماً به تغییر Nameserver نیاز ندارد.

دامنه یک دارایی عملیاتی است، نه یک خرید سالانه

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

شرکتی که دامنه را با ایمیل همان دامنه بازیابی می‌کند، یک حلقه خطر ساخته است: اگر DNS یا ایمیل دچار اختلال شود، کانال بازیابی نیز از دست می‌رود. یک ایمیل امن و مستقل برای Recovery، همراه با MFA و ثبت تغییرها، این ریسک را کم می‌کند.

دامنه‌های عمومی و .ir یک فرایند واحد ندارند

سیاست انتقال ICANN عمدتاً برای دامنه‌های عمومی یا gTLD مانند .com، .net و .org و رجیسترارهای معتبر ICANN کاربرد دارد. دامنه کشوری .ir زیر قواعد و سامانه IRNIC اداره می‌شود. ازاین‌رو کد انتقال، قفل ۶۰روزه یا Formهای gTLD را نباید خودکار به .ir تعمیم داد.

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

این مقاله سیاست جاری منتشرشده در تاریخ ۲۱ مرداد ۱۴۰۵ / ۱۲ اوت ۲۰۲۶ را مبنا می‌گیرد. هیئت ICANN در ژوئن ۲۰۲۶ توصیه‌هایی برای بازنگری سیاست انتقال تصویب کرده است، اما تصویب توصیه با اجرایی‌شدن متن جدید یکی نیست. هنگام اجرا، نسخه جاری Transfer Policy رسمی ICANN و شرایط همان پسوند و رجیسترار را دوباره کنترل کنید.

قرارداد موفقیت انتقال را پیش از شروع بنویسید

«دامنه منتقل شد» معیار کافی نیست. قرارداد موفقیت باید وضعیت کسب‌وکار پس از انتقال را تعریف کند:

• رجیسترار جدید در RDAP دیده شود و دامنه در حساب سازمانی درست قرار بگیرد.
• قفل انتقال دوباره فعال، MFA و مسیرهای Recovery آزموده و تمدید خودکار تنظیم شوند.
• Nameserverها، رکوردهای حیاتی و امضای DNSSEC بدون تغییر ناخواسته باقی بمانند.
• وب، TLS، ایمیل ورودی و خروجی، API، پنل و زیردامنه‌های مهم از چند شبکه کار کنند.
• هیچ تغییر URL، Canonical یا افت خزیدن ناشی از انتقال رجیسترار رخ ندهد.

Guardrailها را نیز بنویسید: قطعی DNS صفر، از دست رفتن ایمیل صفر، عدم انتشار Auth-Code، نبود تغییر مالکیت ناخواسته و داشتن شواهد قابل ممیزی.

Inventory پیش از انتقال؛ چیزی را حدس نزنید

یک برگه واحد برای دامنه بسازید و هر مقدار را با زمان و منبع ثبت کنید. حداقل این موارد لازم‌اند:

اگر Zone فقط در سرویس DNS رجیسترار فعلی میزبانی می‌شود، انتقال ممکن است پایان همان سرویس یا تغییر شرایطش را رقم بزند. قبل از هر Unlock، امکان ادامه سرویس یا مهاجرت مستقل DNS را کتبی روشن کنید.

وضعیت دامنه را با RDAP و EPP بخوانید

از ICANN Lookup یا RDAP رجیستری برای دیدن رجیسترار، تاریخ‌ها و Status استفاده کنید. clientTransferProhibited معمولاً قفل قابل‌کنترل رجیسترار است؛ serverTransferProhibited از سمت Registry اعمال می‌شود و ممکن است مسئله حقوقی، حفاظتی یا عملیاتی جداگانه‌ای داشته باشد. pendingTransfer یعنی درخواست انتقال در جریان است، نه اینکه سایت باید از دسترس خارج شود.

redemptionPeriod یا pendingDelete یک انتقال عادی نیست. ابتدا چرخه انقضا و بازیابی را با رجیسترار حل کنید. معنی دقیق Statusها در فهرست رسمی EPP Status Code آمده است؛ ترجمه آزاد یک داشبورد فروشنده را منبع تصمیم نگیرید.

قفل ۶۰روزه را با یک قانون ساده اشتباه نگیرید

در gTLDها معمولاً انتقال بین رجیسترارها در ۶۰ روز نخست ثبت اولیه یا ۶۰ روز پس از انتقال قبلی مجاز نیست. تغییر Registrant نیز می‌تواند قفل ۶۰روزه ایجاد کند و در بعضی شرایط امکان Opt-out مطابق سیاست و سازوکار رجیسترار مطرح است. جزئیات را از سیاست جاری و پیام دقیق رجیسترار بخوانید؛ «۶۰ روز از آخرین ویرایش هر فیلد» گزاره‌ای بیش از حد ساده است.

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

زمان انقضا و تمدید را محافظه‌کارانه مدیریت کنید

انتقال را به روزهای پایانی اعتبار موکول نکنید. سیاست، چرخه تمدید و رفتار هزینه‌ای هر TLD و رجیسترار می‌تواند متفاوت باشد؛ همچنین یک تمدید نزدیک انتقال ممکن است در صورتحساب یا تاریخ نهایی نیازمند تطبیق باشد. بنابراین ادعای «هر انتقال حتماً یک سال اضافه می‌کند» را مبنای بودجه نگذارید.

پیش از شروع، تاریخ انقضا، آخرین تمدید، وضعیت Grace/Redemption، فاکتور و شرایط بازپرداخت هر دو طرف را ثبت کنید. پس از پایان نیز تاریخ نهایی را با انتظار مالی تطبیق دهید.

رجیسترار مقصد را با Hard Gate انتخاب کنید

برای gTLD، اعتبار رجیسترار نزد ICANN و پشتیبانی از همان TLD شرط نخست است؛ قیمت پایین نمی‌تواند فقدان صلاحیت، Export یا امنیت را جبران کند. سپس این Gateها را بررسی کنید:

• امکان مالکیت حساب سازمانی، MFA قوی، نقش‌بندی و Audit log؛
• نمایش شفاف قفل، Auth-Code، تاریخ انقضا، Nameserver و DNSSEC؛
• پشتیبانی اضطراری قابل احراز و فرایند مقابله با Domain hijacking؛
• روش پرداخت و تمدید عملی برای شخصیت حقوقی شما، بدون فرض دسترسی پایدار؛
• خروج کامل: انتقال مجدد، Export داده و نبود مانع قراردادی پنهان؛
• شرایط Reseller، Privacy، DNS، ایمیل و سرویس‌های Bundle شده.

قیمت ثبت سال اول را با هزینه تمدید، نرخ ارز، مالیات، Privacy، DNS، Registry lock، پشتیبانی و زمان عملیات جمع کنید. چارچوب گسترده‌تر هزینه در راهنمای TCO دامنه و هاست آمده است.

امنیت حساب را قبل از بازکردن قفل بالا ببرید

پنجره‌ای که دامنه Unlocked و Auth-Code صادر شده است، سطح حمله بالاتری دارد. پیش از آن رمز یکتا، MFA مقاوم، Recovery مستقل، حذف کاربران قدیمی، محدودکردن API tokenها و کنترل امنیت ایمیل تأیید را انجام دهید. اگر Registry Lock برای دامنه حیاتی دارید، فرایند برداشتن و فعال‌سازی دوباره آن را جداگانه با افراد مجاز هماهنگ کنید.

Auth-Code یا EPP Code یک Secret انتقال است. آن را در ایمیل گروهی، پیام‌رسان، Ticket عمومی یا فایل پروژه نگذارید. Secret باید فقط در خزانه امن، با دسترسی حداقلی و عمر کوتاه نگهداری شود و پس از پایان انتقال از مسیرهای اشتراک پاک شود.

Runbook انتقال gTLD بین دو رجیسترار

1. دامنه و طرف‌ها را تأیید کنید: نام دقیق، Registry، رجیسترار فعلی و مقصد معتبر، مالک رکورد و اختیار مجری.
2. پیش‌شرط‌ها را بسنجید: RDAP/EPP، قفل‌های ۶۰روزه، انقضا، اختلاف حقوقی یا مالی و فعال‌بودن کانال تأیید.
3. Freeze تغییر ایجاد کنید: هم‌زمان مالک، DNS، هاست، ایمیل و Certificate را تغییر ندهید.
4. شواهد پایه بگیرید: Zone، DS، NS، HTTP/TLS، ایمیل، تاریخ‌ها، کاربران و صورتحساب.
5. قفل انتقال را در پنجره مصوب بردارید: فقط Status مرتبط را تغییر دهید؛ سایر حفاظت‌ها را بی‌دلیل خاموش نکنید.
6. AuthInfo را امن دریافت کنید: طبق سیاست جاری، رجیسترار باید راه ساخت کد را فراهم کند یا آن را حداکثر ظرف پنج روز تقویمی ارائه دهد. ICANN صادرکننده کد نیست.
7. در مقصد درخواست را آغاز کنید: دامنه و کد را با بازبینی چهارضشمی وارد و Intent انتقال را از مسیر معتبر تأیید کنید.
8. وضعیت را پایش کنید: پیام‌های هر دو رجیسترار، RDAP/EPP و دلیل هر Reject را ثبت کنید؛ روی عدد ثابت «۵ تا ۷ روز» حساب نکنید.
9. پس از Completion ایمن‌سازی کنید: قفل، MFA، Owner/Role، Recovery، Auto-renew و پرداخت را کنترل کنید.
10. تطبیق فنی و مالی انجام دهید: DNS/DNSSEC، وب، ایمیل، TLS، تاریخ انقضا، فاکتور و سرویس‌های Bundle شده را با Baseline مقایسه کنید.

راهنمای رسمی AuthInfo Code در ICANN و FAQ دارنده دامنه باید بر متن‌های قدیمی یا دستورالعمل یک فروشنده مقدم باشند.

دلیل رد انتقال باید مشخص و قابل پیگیری باشد

رجیسترار نمی‌تواند هر مانعی را با عبارت مبهم «سیاست داخلی» توجیه کند. در سیاست ICANN دلایل مجاز یا الزامی مشخصی مانند قفل معتبر، ۶۰ روز نخست ثبت/انتقال، اختلاف هویت یا اختیار، اعتراض صریح دارنده، UDRP/URS/TDRP، حکم دادگاه و وضعیت‌های معین آمده‌اند. متن دقیق Reject، زمان، Status و بند استنادی را بخواهید.

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

DNS در انتقال رجیسترار چه می‌شود؟

رجیسترار، Registry و DNS provider نقش‌های جدا دارند. اگر Nameserverها و سرویس DNS همان‌طور باقی بمانند، Resolution نیز باید ادامه یابد. ریسک وقتی ایجاد می‌شود که DNS فعلی یک سرویس Bundle رجیسترار مبدأ باشد، Glue/Child nameserver مدیریت شود یا مقصد تنظیمات Nameserver را بازنویسی کند.

قبل و بعد، خروجی مرجع را مقایسه کنید:

Domain: example.com
Authoritative NS: ns1.example-dns.net, ns2.example-dns.net
Critical records: A/AAAA, CNAME, MX, TXT, CAA, SRV
Delegation: parent NS + glue
DNSSEC: DS at parent + DNSKEY/RRSIG in zone
Checks: authoritative query + public resolvers + Iranian networks

کپی‌کردن دستی چند رکورد مشهور کافی نیست؛ رکوردهای Verification، DKIM selector، ACME challenge، API، CDN و سرویس‌های قدیمی معمولاً جا می‌مانند.

DNSSEC را کورکورانه خاموش نکنید

DNSSEC یک زنجیره اعتماد میان DS در Parent و کلیدهای Zone می‌سازد. اگر Zone همان است اما DS حذف یا عوض شود، حفاظت کم می‌شود؛ اگر کلید عوض شود ولی DS قدیمی بماند، دامنه برای Resolverهای validating ممکن است نامعتبر و عملاً قطع شود.

مالک DNSSEC، محل مدیریت DS، وضعیت Signing و روش Rollback را قبل از انتقال مشخص کنید. نتیجه را با Resolver اعتبارسنج بسنجید، نه فقط مرورگری که Cache دارد. برای گواهی و تمدید خودکار نیز راهنمای SSL/TLS و ACME را کنار Runbook قرار دهید؛ انتقال رجیسترار به‌تنهایی گواهی را عوض نمی‌کند، اما اختلال DNS می‌تواند تمدید را خراب کند.

ایمیل؛ آسیب پنهان انتقال دامنه

MX فقط بخشی از سامانه ایمیل است. SPF، DKIM، DMARC، Return-Path، Bounce domain، رکوردهای Autodiscover و Verification را نیز بررسی کنید. اگر Forwarding یا Mailbox رایگان با رجیسترار مبدأ دارید، انتقال ممکن است قرارداد آن را پایان دهد حتی وقتی MX ظاهراً ثابت است.

پس از انتقال، از یک دامنه بیرونی ایمیل ورودی بفرستید، پاسخ خروجی را دریافت کنید و Headerهای احراز هویت را کنترل کنید. ایمیل بازنشانی رمز، سفارش و فاکتور را نیز جدا بیازمایید. برای مرزبندی رضایت و Deliverability بازاریابی، راهنمای ایمیل و چرخه عمر مکمل این آزمون فنی است.

وب، CDN و TLS را از چند نقطه آزمایش کنید

یک پاسخ ۲۰۰ از لپ‌تاپ مدیر کافی نیست. صفحه اصلی، Checkout/Login، API، فایل ایستا، نسخه www/non-www و زیردامنه‌های حیاتی را از اینترنت ثابت و موبایل ایران و در صورت امکان یک نقطه بیرونی آزمایش کنید. Status، زنجیره Redirect، Certificate/SNI، Header امنیتی و زمان Resolution را ثبت کنید.

اگر CDN یا WAF مالکیت دامنه را با TXT/CNAME تأیید می‌کند، حذف رکورد می‌تواند در آینده Revalidation یا تمدید TLS را مختل کند. «الان باز می‌شود» با «پس از انقضای Cache یا Certificate هم سالم می‌ماند» برابر نیست.

انتقال .ir را از پورتال رسمی IRNIC هدایت کنید

برای .ir ابتدا در پرتال رسمی IRNIC بررسی کنید دقیقاً کدام عمل را می‌خواهید: انتقال مالکیت میان شناسه‌های نیک، تغییر رابط‌های اداری/فنی/مالی، تغییر کارگزار یا فقط تغییر Nameserver. این‌ها یک چیز نیستند و رابط کاربری یا مدارک ممکن است در گذر زمان تغییر کند.

در انتقال مالکیت، شناسه‌های تأییدشده طرفین، اهلیت پسوند، مدارک هویتی/سازمانی، تأییدها و هزینه‌های جاری را فقط از پورتال و قرارداد رسمی روز اجرا بگیرید. از بازنشر عدد ثابت، نام دکمه قدیمی یا دورزدن احراز هویت پرهیز کنید. رسیدها، شناسه درخواست و زمان تأیید هر طرف را در پرونده دامنه نگه دارید.

تغییر کارگزار .ir لزوماً تغییر مالکیت نیست

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

این تفکیک برای اختلاف‌های آینده حیاتی است: فاکتور خرید از یک فروشنده به‌تنهایی جای ثبت صحیح دارنده و اختیارهای رسمی را نمی‌گیرد.

چرا انتقال را با مهاجرت هاست هم‌زمان نکنیم؟

اگر هم‌زمان Registrar، Nameserver و Origin عوض شوند، منشأ خطا مبهم می‌شود: آیا مشکل از Delegation، Zone ناقص، Cache، فایروال Origin یا نرم‌افزار جدید است؟ با تغییرهای کوچک و قابل مشاهده، Blast radius و زمان تشخیص کاهش می‌یابد.

ترتیب پیشنهادی برای پروژه‌ای که هر دو را لازم دارد این است: تثبیت و انتقال Registrar با DNS ثابت؛ مشاهده یک دوره مناسب؛ سپس مهاجرت DNS/هاست با Runbook مستقل. نیاز اضطراری می‌تواند ترتیب دیگری بسازد، اما باید دلیل و ریسک پذیرفته‌شده ثبت شود.

SEO در انتقال رجیسترار چه انتظاری دارد؟

انتقال رجیسترار به‌خودی‌خود تغییر SEO نیست: URL، محتوای HTML، Status، Canonical، robots.txt، Sitemap و Structured data باید ثابت بمانند. بنابراین ساخت Redirect جدید یا ارسال Change of Address بی‌معنا و حتی زیان‌بار است.

افت Crawl یا رتبه پس از انتقال معمولاً نشانه یک تغییر جانبی است: DNS timeout، خطای TLS، WAF، حذف www، تغییر Redirect، از دست‌رفتن Subdomain یا پاسخ متفاوت برای Bot. لاگ، Uptime و Search Console را پیش و پس از پنجره مقایسه کنید. اگر واقعاً نام دامنه عوض می‌شود، آن پروژه را از این Runbook جدا کنید.

برنامه D-۱۴ تا D+۷

Go/No-Go؛ چه زمانی انتقال را شروع نکنیم؟

No-Go بدهید اگر مالک یا اختیار تأیید روشن نیست؛ دامنه در Redemption/Dispute است؛ کانال ایمیل تأیید دردسترس نیست؛ Auth-Code باید در کانال ناامن ردوبدل شود؛ DNS رجیسترار فعلی Export یا قرارداد ادامه ندارد؛ تیم قادر به آزمون ایمیل/DNSSEC نیست؛ یا انتقال با Release حساس دیگری هم‌زمان شده است.

«مدیر می‌خواهد امروز تمام شود» کنترل ریسک نیست. زمان جدید، هزینه‌ای کمتر از بازیابی دامنه، سفارش‌های ازدست‌رفته و بی‌اعتمادی مشتری دارد.

Rollback در انتقال دامنه چه معنایی دارد؟

انتقال رجیسترار دکمه Undo فوری ندارد. پیش از تأیید نهایی می‌توان فرایند را مطابق سیاست متوقف یا مشکل را رفع کرد؛ پس از Completion، بازگشت ممکن است دوباره مشمول قفل، سیاست و اختلاف بین طرف‌ها شود. بنابراین Rollback واقعی بیشتر به حفظ سرویس مربوط است: DNS فعلی را پایدار نگه دارید، تغییرهای هم‌زمان را متوقف کنید و کانال‌های اضطراری هر دو رجیسترار را آماده داشته باشید.

برای هر مرحله یک «آخرین نقطه توقف امن» تعریف کنید. اگر Baseline DNS ناقص است، Code صادر نکنید؛ اگر تأیید هویت مقصد نامعتبر است، Authorization ندهید؛ اگر پس از Completion سرویس Bundle قطع شد، Zone/Email از پیش آماده را طبق Runbook مستقل فعال کنید.

اگر انتقال غیرمجاز رخ داد، دقیقه‌ها مهم‌اند

1. فوراً با رجیسترار قبلی و جدید از کانال رسمی تماس بگیرید و شماره پرونده بگیرید.
2. حساب رجیسترار، ایمیل، Password manager و Recoveryهای مرتبط را امن و Session/Tokenهای مشکوک را لغو کنید.
3. RDAP، ایمیل‌ها، Header، Audit log، IP، زمان، فاکتور و تغییر DNS را بدون دست‌کاری حفظ کنید.
4. از رجیسترار قبلی بخواهید ادعای انتقال غیرمجاز و مسیر TDRP/Registry را بررسی کند.
5. اگر پاسخ مناسب نیست، راهنمای انتقال غیرمجاز ICANN و فرم شکایت Compliance را دنبال کنید.

ICANN مستقیماً Auth-Code صادر نمی‌کند و اختیار عمومی برای بازگرداندن هر دامنه به هر مدعی ندارد؛ نقش قراردادی و فرایند اختلاف را با پلیس، دادگاه یا رجیسترار اشتباه نگیرید. برای .ir نیز مسیر رسمی IRNIC و الزامات حقوقی مرتبط را دنبال کنید.

انتقال گروهی را مرحله‌ای اجرا کنید

برای Portfolio، ابتدا دامنه‌ها را بر اساس اهمیت دسته‌بندی کنید: دامنه پرداخت و ایمیل سازمانی Critical، دامنه کمپین مهم و دامنه پارک‌شده کم‌خطرتر است. یک دامنه نماینده اما غیرحیاتی را Canary کنید و تنها پس از تکمیل چرخه فنی، مالی و پشتیبانی Batch بعدی را آغاز کنید.

محدودیت تعداد، Rate، Expiry نزدیک، TLDهای متفاوت و Owners مختلف را در صف جدا نگه دارید. یک Auth-Code مشترک، فایل بدون رمز یا انتقال صدها دامنه در یک روز، Blast radius را غیرضروری بزرگ می‌کند.

داشبورد انتقال؛ Status بدون مالک بی‌فایده است

domain | tld | criticality | owner | current_registrar | target_registrar
expiry | epp_status | dns_provider | dnssec | mail_provider
request_id | initiated_at | current_state | blocker | next_action | action_owner
baseline_hash | completed_at | relocked_at | verified_at | evidence_link

هر Blocker باید Next action، Owner و Deadline داشته باشد. داشبوردی که فقط «Pending» نشان می‌دهد، تیم را از تأخیر مجاز، Reject و حادثه واقعی آگاه نمی‌کند.

آزمون پذیرش پس از انتقال

• RDAP رجیسترار و Status مورد انتظار را نشان می‌دهد؛ دامنه دوباره Locked است.
• Owner، نقش‌ها، MFA، Recovery و Support PIN درست و حداقلی‌اند.
• تاریخ انقضا، Auto-renew، روش پرداخت، ارز و فاکتور تطبیق شده‌اند.
• Parent delegation، Nameserverهای authoritative، Zone و DNSSEC با Baseline سازگارند.
• HTTP/HTTPS، Redirect، Certificate، CDN/WAF، API و زیردامنه‌ها از چند شبکه سالم‌اند.
• MX/SPF/DKIM/DMARC و ارسال/دریافت واقعی، Reset password و پیام تراکنشی کار می‌کنند.
• Privacy، Registry lock، DNS یا ایمیل Bundle شده وضعیت و مالک مشخص دارند.
• شواهد، Secret cleanup، Incident note و تصمیم تحویل به عملیات ثبت شده‌اند.

شاخص‌ها؛ سرعت انتقال تنها KPI نیست

Lead time را بسنجید، اما آن را با نرخ انتقال بدون Incident، تعداد Reject به تفکیک علت، زمان Relock، درصد دامنه‌های دارای Owner/MFA/Recovery معتبر، اختلاف تاریخ انقضا، خطای DNS/DNSSEC/Email و زمان حل پرونده همراه کنید. انتقال سریع با Auth-Code لو‌رفته یا Auto-renew خاموش، موفقیت نیست.

برای Portfolio، Coverage مهم‌تر از میانگین است: چند درصد دامنه‌های Critical آزمون واقعی ایمیل و DNSSEC دارند؟ چند دامنه با ایمیل شخصی کارمند سابق ثبت شده‌اند؟ این Gapها Backlog امنیتی می‌سازند.

اشتباه‌های رایج و اصلاح عملی آن‌ها

• اشتباه: انتقال Registrar را با تغییر DNS یکی می‌دانیم. اصلاح: دو Change request و دو Runbook جدا.
• اشتباه: هم‌زمان اطلاعات مالک را ویرایش می‌کنیم. اصلاح: اثر Change of Registrant و قفل احتمالی را پیش از پنجره بررسی کنید.
• اشتباه: Code را برای «تسریع» در چت می‌فرستیم. اصلاح: Vault، دسترسی حداقلی و پاک‌سازی پس از مصرف.
• اشتباه: فقط صفحه اصلی را باز می‌کنیم. اصلاح: DNSSEC، ایمیل، TLS، API و زیردامنه‌ها را از چند شبکه تست کنید.
• اشتباه: ارزان‌ترین رجیسترار را انتخاب می‌کنیم. اصلاح: Hard gate امنیت، Eligibility، Support، Renewal و Exit قبل از TCO.
• اشتباه: فرایند .com را برای .ir کپی می‌کنیم. اصلاح: عمل دقیق و قواعد روز IRNIC را مبنا قرار دهید.
• اشتباه: پس از Completion پروژه را می‌بندیم. اصلاح: Relock، MFA، Auto-renew و تطبیق فنی/مالی دروازه تحویل‌اند.

نمونه تصمیم برای یک فروشگاه ایرانی

فروشگاه «الف» دامنه .com، DNS روی سرویس رجیسترار مبدأ، ایمیل تراکنشی مستقل و DNSSEC فعال دارد. مقصد از نظر قیمت مناسب است اما Import خودکار Zone ندارد. تیم تصمیم می‌گیرد ابتدا DNS را از وابستگی Bundle خارج کند، Zone و DS را با Runbook مستقل تثبیت و یک هفته پایش کند؛ سپس انتقال Registrar را با Nameserver ثابت انجام دهد.

برای دامنه .ir همان برند، تیم فقط رابط مالی را تغییر می‌دهد و مالکیت در شناسه سازمانی IRNIC ثابت می‌ماند. این دو Ticket با نام «انتقال» شروع شده بودند، اما پس از تفکیک، یکی پروژه gTLD و دیگری تغییر رابط شد. نتیجه مهم همین است: عملیات درست از نام‌گذاری درست آغاز می‌شود.

برنامه ۳۰روزه برای تیمی که Runbook ندارد

روز ۱ تا ۷: Inventory و مالکیت

همه دامنه‌ها، Owner، Registry/Registrar، انقضا، DNS، Email، DNSSEC، MFA و Recovery را ثبت کنید. دامنه‌های Critical و شکاف‌های مالکیتی را علامت بزنید.

روز ۸ تا ۱۴: Contract و آزمون

Hard gate رجیسترار، Success/Guardrail، Baseline Queryها، Incident channel، Secret handling و Go/No-Go را تعریف کنید. یک دامنه کم‌خطر را برای تمرین انتخاب کنید.

روز ۱۵ تا ۲۱: Canary

انتقال را با Freeze و شواهد اجرا، EPP/RDAP را پایش و پذیرش DNS/Email/TLS/Finance را کامل کنید. هر ابهام رابط یا پشتیبانی را به Runbook برگردانید.

روز ۲۲ تا ۳۰: مقیاس کنترل‌شده

دامنه‌ها را Batch کنید، Dashboard و SLA اقدام بسازید و فقط پس از موفقیت Canary دامنه‌های مهم‌تر را منتقل کنید. بازبینی فصلی Owner، MFA، Expiry و Recovery را به عملیات دائمی تبدیل کنید.

موضوعات مکملی که به مقاله مستقل نیاز دارند

• ابزار Inventory و کنترل انقضای Portfolio دامنه با RDAP و هشدار چندمالک؛
• آزمایشگاه DNSSEC برای انتقال Registrar، مهاجرت DNS و Rollback امن DS؛
• Runbook واکنش به Domain hijacking برای کسب‌وکار ایرانی با شواهد، نقش‌ها و تمرین Tabletop؛
• راهنمای عملی تفاوت مالک، رابط و کارگزار در IRNIC با Snapshot تاریخ‌دار؛
• Vendor scorecard رجیسترار شامل امنیت، Renewal، Support، TCO و Exit.

پرسش‌های متداول انتقال دامنه

آیا با انتقال دامنه سایت قطع می‌شود؟

انتقال رجیسترار به‌تنهایی نباید سایت را قطع کند. قطعی معمولاً از تغییر یا پایان سرویس DNS، Zone ناقص، DNSSEC ناسازگار، TLS یا سرویس Bundle شده می‌آید. Nameserver و وابستگی‌ها را پیش و پس از انتقال مقایسه کنید.

انتقال دامنه چقدر طول می‌کشد؟

عدد ثابت جهانی وجود ندارد. وضعیت دامنه، TLD، تأییدها، اقدام رجیسترارها و Rejectهای معتبر زمان را تعیین می‌کنند. برای AuthInfo در سیاست جاری gTLD، رجیسترار باید امکان ساخت بدهد یا کد را حداکثر ظرف پنج روز تقویمی ارائه کند؛ این با زمان پایان کل انتقال یکی نیست.

آیا انتقال دامنه همیشه یک سال به اعتبار اضافه می‌کند؟

نه به‌عنوان یک وعده همگانی. اثر انتقال بر مدت اعتبار، هزینه و محدودیت تمدید به TLD، Registry و قرارداد رجیسترار وابسته است. تاریخ و فاکتور را قبل و بعد تطبیق دهید.

برای انتقال دامنه .ir کد EPP لازم است؟

فرایند gTLD را به .ir تعمیم ندهید. در پورتال رسمی IRNIC ابتدا مشخص کنید انتقال مالکیت، تغییر رابط/کارگزار یا تغییر DNS می‌خواهید و الزامات جاری همان عمل را دنبال کنید.

اگر رجیسترار انتقال را رد کرد چه کنیم؟

دلیل دقیق، Status، زمان و بند سیاست را کتبی بگیرید؛ قفل، ۶۰ روز، هویت، انقضا یا اختلاف را رفع و از رجیسترار مقصد کمک بخواهید. اگر رد با سیاست جاری ICANN سازگار نیست، پرونده مستند را از مسیر رسمی شکایت انتقال پیگیری کنید.

جمع‌بندی

انتقال امن دامنه با گرفتن یک کد شروع نمی‌شود؛ با تفکیک Registrar از Owner، DNS، Hosting و URL آغاز می‌شود. Inventory قابل اثبات، حساب سازمانی و MFA، Freeze تغییر، کنترل EPP/RDAP، نگهداری امن Auth-Code، آزمون DNSSEC/Email/TLS و Relock اجزای یک انتقال قابل اتکا هستند.

برای gTLD سیاست جاری ICANN و شرایط همان Registry/Registrar را ملاک بگیرید؛ برای .ir پورتال و قواعد جاری IRNIC را. اگر تیم بتواند پیش از اجرا بگوید چه چیزی ثابت می‌ماند، چه کسی تصمیم می‌گیرد، کجا توقف می‌کند و چگونه سلامت سرویس را ثابت می‌کند، انتقال از یک قمار اداری به یک Change کنترل‌شده تبدیل می‌شود.