اول محل واقعی مدیریت DNS را پیدا کنید
ثبت‌کنندهٔ دامنه، سرویس DNS، میزبان وب و سرویس ایمیل ممکن است چهار مجموعهٔ متفاوت باشند. اگر دامنه به سرویس دیگری واگذار شده باشد، ویرایش Zone در پنل هاست اثری ندارد. پیش از انتقال، خروجی رکوردهای موجود و نام‌سرورهای ثبت‌شده در پنل دامنه را نگه دارید؛ رکوردهای ایمیل و تأیید سرویس‌ها هم باید حفظ شوند.
dig NS example.com +short
dig @AUTHORITATIVE-NAMESERVER example.com A
dig @AUTHORITATIVE-NAMESERVER example.com AAAAجای نام‌سرور نمونه، یکی از نام‌های پاسخ دستور اول را قرار دهید. اگر پاسخ‌ها متفاوت‌اند، هر نام‌سرور معتبر را جداگانه بررسی کنید. این دستورها فقط وضعیت را می‌خوانند و رکوردی تغییر نمی‌دهند.
رکوردهای وب، www و IPv6
- رکورد A نام را به IPv4 وصل می‌کند. آدرس واقعی میزبان را وارد کنید؛ 192.0.2.10 در این راهنما صرفاً آدرس مخصوص مستندات است.
- رکورد AAAA برای IPv6 است. تنها وقتی آن را منتشر کنید که همان سایت با HTTPS روی آن آدرس کار کند. AAAA قدیمی می‌تواند بخشی از کاربران را دچار خطا کند، حتی اگر IPv4 سالم باشد.
- CNAME نامی مثل www را به نام دیگری ارجاع می‌دهد. CNAME معمولی با رکوردهای دیگر در همان نام هم‌زمان نمی‌شود؛ ریشهٔ دامنه نیز به SOA و NS نیاز دارد. قابلیت‌هایی مثل flattening یا ALIAS در بعضی سرویس‌ها رفتار جداگانه دارند و باید طبق مستندات همان سرویس تنظیم شوند.
رفتار پنل‌ها دربارهٔ نقطهٔ آخر نام مقصد متفاوت است. پاسخ نهایی را بررسی کنید تا مقصدی مثل www.example.com.example.com ساخته نشده باشد. DNS به‌تنهایی www را به ریشهٔ دامنه ریدایرکت نمی‌کند؛ میزبان اصلی، گواهی HTTPS و انتقال آدرس باید در وب‌سرور تنظیم شوند.
ایمیل را مستقل از انتقال وب نگه دارید
MX سرور دریافت ایمیل را مشخص می‌کند؛ مقصدش نام میزبان دارای رکورد آدرس است، نه IP مستقیم. عدد پایین‌تر اولویت بیشتری دارد. واردکردن MX پیش از A سایت ذاتاً ایمیل را خراب نمی‌کند؛ این دو رکورد مستقل‌اند. اگر سرویس ایمیل عوض نمی‌شود، MX و TXT موردنیاز همان سرویس را حفظ کنید.
برای SPF و DKIM مقدار دقیق سرویس‌دهندهٔ ایمیل را بگیرید. DMARC به هم‌راستایی SPF یا DKIM با دامنهٔ From قابل‌مشاهده نیاز دارد؛ موفق‌بودن احراز هویت یک دامنهٔ نامرتبط کافی نیست. پیش از اعمال سیاست سخت‌گیرانه، فرستنده‌های مجاز و گزارش‌ها را بررسی کنید. رکوردهای TXT موجود را برای ساده‌کردن ظاهر Zone حذف نکنید.
پیش از تغییر DNS، میزبان جدید را آزمایش کنید
curl --resolve example.com:443:192.0.2.10 -sS -D - -o /dev/null https://example.com/دامنه و IP نمونه را با مقادیر واقعی جایگزین کنید. این آزمون نام میزبان و نام TLS درست را به IP انتخاب‌شده می‌فرستد و DNS عمومی را تغییر نمی‌دهد. بررسی گواهی را فعال نگه دارید. بازکردن IP مستقیم، آزمون قابل‌اعتمادی برای Virtual Host و گواهی دامنه نیست. وضعیت پاسخ، انتقال‌ها و نمایش سایت را هم کنترل کنید.
اگر بعضی کاربران هنوز میزبان قبلی را می‌بینند
dig example.com A
dig example.com AAAA
dig example.com MX
dig @AUTHORITATIVE-NAMESERVER example.com Aپاسخ نام‌سرور معتبر را با Resolver کاربر مقایسه کنید و وضعیت پاسخ، نوع رکورد و TTL باقی‌مانده را کنار هم ببینید. NXDOMAIN با NOERROR بدون پاسخِ نوع درخواستی فرق دارد. SERVFAIL می‌تواند از مشکل واگذاری یا DNSSEC و علت‌های دیگر باشد؛ پیش از حدس‌زدن زنجیره را بررسی کنید. موفقیت A به‌تنهایی سالم‌بودن ایمیل و IPv6 را ثابت نمی‌کند.
زمان قطعی و یکسانی برای انتشار تغییرات وجود ندارد. پاسخ مثبت قدیمی تا TTL قبلی و پاسخ منفی نیز ممکن است در کش بماند. کم‌کردن TTL هنگام انتقال، عمر نسخه‌ای را که قبلاً کش شده کوتاه نمی‌کند. این کار را از قبل برنامه‌ریزی کنید و میزبان قبلی را در دورهٔ گذار در دسترس نگه دارید.
ثبت نتیجه و مسیر بازگشت
رکوردهای قبل و بعد، زمان تغییر، پاسخ نام‌سرورها، آزمون HTTPS و ارسال و دریافت ایمیل را ثبت کنید. اگر آزمون شکست خورد، رکوردهای مربوط را از نسخهٔ ذخیره‌شده برگردانید؛ بازگشت هم تحت‌تأثیر کش است. بعد از درست‌شدن DNS، با راهنمای عیب‌یابی کندی سایت زمان پاسخ را بررسی کنید و آن را از کش HTTP جدا بسنجید.
منابع: انواع رکورد DNS، کش پاسخ منفی و هم‌راستایی DMARC.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!