سرور و گواهی را برای نام میزبان مورد نظر آماده کنید، برنامه را پیش از تغییر DNS عمومی آزمایش نمایید و محیط قدیمی را در طول انتقال در دسترس نگه دارید. رکوردهای معتبر، پاسخ‌های کش‌شده و TLS را به‌طور مستقل بررسی کنید. یک به‌روزرسانی صرف DNS اثبات نمی‌کند که برنامه و گواهی صحیح ارائه می‌شوند.
نام‌ها و وابستگی‌ها را فهرست کنید
هر نام میزبانی که سایت استفاده می‌کند را فهرست کنید، از جمله دامنه اصلی، نام‌های مستعار، نقاط پایانی API و بازگشت‌های برنامه. ثبت کنید چه کسی کنترل ثبت و DNS معتبر را دارد. میزبانی یک برنامه به‌طور خودکار دامنه آن را ثبت نمی‌کند یا کنترل رکوردهای آن را به اپراتور سرور نمی‌دهد. دسترسی به محیط موجود را تا زمان اعتبارسنجی محیط جدید حفظ کنید.
همچنین رکوردهای ایمیل و تأیید شخص ثالثی را که انتقال باید حفظ کند شناسایی کنید. مهاجرت یک وب‌سایت نباید به‌سادگی کل یک ناحیه DNS را جایگزین کند. یک برنامه تغییر در سطح رکورد با آدرس‌های مورد نظر و یک مقدار بازگشت بسازید. اعتبارنامه‌ها را به‌صورت خصوصی ذخیره کنید؛ راهنما به مسئولان و رویه‌ها نیاز دارد، نه رمزهای عبور واقعی یا توکن‌های API.
مسیریابی نام میزبان را روی سرور جدید آماده کنید
ماشینی که اتصال دریافت می‌کند باید برنامه مورد نظر را برای نام میزبان خود ارائه دهد. وب‌سرور یا پنل میزبانی را بر همین اساس پیکربندی کنید، با ریشه اسناد عمومی جدا از پیکربندی خصوصی و اعتبارنامه‌ها. همه نام‌ها و تغییرمسیرهای مورد نیاز را آزمایش کنید، نه فقط یک صفحه خوش‌آمد عمومی که از طریق آدرس سرور قابل دسترسی است.
از یک روش آزمایش کنترل‌شده استفاده کنید که نام میزبان مورد نظر را پیش از تغییر عمومی به نقطه پایانی جدید می‌فرستد. ورود، بارگذاری‌ها و پیوندهای تولیدشده توسط برنامه را در صورت لزوم بررسی کنید. کارهایی را که می‌توانند اقدامات تولیدی را در طول آزمایش تکرار کنند غیرفعال کنید. آزمایش باید رفتار برنامه را اثبات کند بدون ارسال ایمیل واقعی، دریافت پرداخت یا تغییر ناخواسته پایگاه داده فعال قدیمی.
یک روش اعتبارسنجی گواهی انتخاب کنید
صدور گواهی نیازمند اثبات کنترل برای نام‌های درخواستی است. Let's Encrypt روش‌های اعتبارسنجی HTTP-01 و DNS-01 را در میان روش‌های خود مستند می‌کند. اعتبارسنجی HTTP به ارائه صحیح چالش مورد نیاز بستگی دارد؛ اعتبارسنجی DNS از یک رکورد DNS مشخص استفاده می‌کند و می‌تواند از صدور wildcard پشتیبانی کند. روشی را انتخاب کنید که با استقرار واقعی سازگار باشد و بتوان آن را به‌طور ایمن نگهداری کرد.
در صورت امکان، اعتبارنامه‌های اعتبارسنجی را محدود نگه دارید. خودکارسازی DNS به‌ویژه حساس است زیرا اعتبارنامه‌های گسترده DNS می‌توانند بیش از یک وب‌سایت را تحت تأثیر قرار دهند. تمدید گواهی و نحوه رسیدن فایل‌های تمدیدشده به فرآیند ارائه را برنامه‌ریزی کنید. صدور موفق اولیه مفید است، اما یک سایت همچنین به فرآیند تمدید کارآمد و پایش گواهی‌ای که واقعاً ارائه می‌دهد نیاز دارد.
پیش از تغییر DNS، بازه کش را برنامه‌ریزی کنید
رکوردهای DNS یک مدت زنده‌ماندن دارند که حل‌کننده‌ها هنگام کش کردن پاسخ‌ها از آن استفاده می‌کنند. تغییر یک رکورد به‌طور لحظه‌ای هر نتیجه کش‌شده را جایگزین نمی‌کند. اگر انتقال از TTL کوتاه‌تر سود می‌برد، تنظیم را به‌اندازه کافی زود برنامه‌ریزی کنید تا پاسخ‌های قبلاً کش‌شده بتوانند منقضی شوند. هر دو محیط قدیمی و جدید را قادر به مدیریت انتقالی که طراحی کرده‌اید نگه دارید.
این توالی نمونه، آماده‌سازی را از تغییر عمومی جدا می‌کند. زمان‌بندی آن باید با دامنه، رفتار حل‌کننده و برنامه سازگار شود. این یک برنامه انتشار جهانی نیست. مهاجرتی که شامل نوشتن‌های فعال است نیز به یک تغییر داده مخصوص برنامه نیاز دارد، زیرا در غیر این صورت دو وب‌سرور فعال می‌توانند تغییرات را در مجموعه‌داده‌های متفاوتی بپذیرند.
| مرحله | اقدام | شرط پیش از ادامه |
|---|---|---|
| آماده‌سازی | فهرست‌برداری رکوردها و پیکربندی نقطه پایانی جدید | برنامه برای نام‌های مورد نظر کار می‌کند |
| گواهی | صدور و نصب گواهی | زنجیره صحیح و نام میزبان معتبر |
| انتقال | فقط رکوردهای DNS برنامه‌ریزی‌شده را به‌روزرسانی کنید | تغییر داده و بازگشت تعریف شده‌اند |
| مشاهده | نتایج معتبر و کلاینت را بررسی کنید | سفرهای کاربر از طریق نقطه پایانی جدید موفق می‌شوند |
| تکمیل | پس از اعتبارسنجی، سرویس قدیمی را بازنشسته کنید | ترافیک باقی‌مانده و نیازهای بازیابی بررسی شدند |
DNS و TLS را جداگانه بررسی کنید
ابتدا رکورد معتبر را بررسی کنید، سپس پاسخ‌های کلاینت‌ها یا حل‌کننده‌های درگیر در انتقال را مقایسه نمایید. یک مقدار معتبر صحیح و یک مقدار کش‌شده قدیمی می‌توانند همزمان وجود داشته باشند. نقطه پایانی‌ای که مرورگر به آن می‌رسد را بررسی کنید، نه اینکه فرض کنید هر اتصال از قبل از آدرس جدید استفاده می‌کند. مشاهدات را با برچسب زمانی نگه دارید تا انتقال قابل درک باشد.
برای TLS، نام میزبان مورد نظر، اعتبار گواهی و زنجیره را از طریق یک اتصال واقعی کلاینت بررسی کنید. هر نام مستعار و مسیر تغییرمسیر مورد نیاز را بازرسی نمایید. مستندات TLS موزیلا احراز هویت سرور و نگرانی‌های محتوای ترکیبی را توضیح می‌دهد: صفحه و زیرمنابع آن باید به‌صورت ایمن ارائه شوند. یک گواهی روی یک نام میزبان به‌طور خودکار نام میزبان دیگری را پوشش نمی‌دهد.
بازگشت را نیز به یک تصمیم داده تبدیل کنید
بازگشت DNS می‌تواند ترافیک را تغییر مسیر دهد، اما نوشتن‌های انجام‌شده روی برنامه جدید را معکوس نمی‌کند. پیش از تغییر، تعریف کنید که با آن داده‌ها چگونه برخورد خواهید کرد. برای یک انتشار ایستا، بازگشت ممکن است ساده باشد؛ برای سرویسی که بارگذاری‌ها یا سفارش‌ها را می‌پذیرد، وضعیت برنامه به یک مسئول مشخص و رویه تطبیق نیاز دارد.
تصور کنید یک سایت انتشاراتی کوچک با نظرات را مهاجرت می‌دهید. می‌توانید یک بازه نگهداری یا یک انتقال کنترل‌شده فقط‌خواندنی را در حین کپی داده‌های نهایی آماده کنید. رویه بازگشایی را آزمایش کنید و استقرار قدیمی را آماده نگه دارید. رویکردی را انتخاب کنید که با برنامه سازگار است، نه اینکه از تغییر DNS به‌عنوان جایگزینی برای برنامه‌ریزی سازگاری استفاده کنید.
پس از تغییر، سایت را مشاهده کنید
پس از دریافت ترافیک توسط نقطه پایانی جدید، سفرهای واقعی کاربر، نرخ خطا، ارائه گواهی و وظایف پس‌زمینه را بررسی کنید. تأیید نمایید که پشتیبان‌گیری‌ها اکنون برنامه و داده مورد نظر را پوشش می‌دهند. پیش از بازنشستگی، دسترسی سرور قدیمی را بررسی کنید و اعتبارنامه‌های منسوخ را زمانی که نیازهای بازیابی و بازگشت حل شدند حذف نمایید. پیکربندی نهایی DNS و گواهی را ثبت کنید.
هنگام انتخاب میزبانی وب یا محاسبات SwissOctet، مسئولیت‌های واقعی دامنه، گواهی و مدیریت را برای پیکربندی تأیید کنید. کاتالوگ یک مقصد میزبانی و منابع ارائه می‌دهد؛ اثبات نمی‌کند که دامنه شما قبلاً متصل شده یا تمدید گواهی پیکربندی شده است. این مراحل را در برنامه استقرار مشخص و قابل بررسی نگه دارید.
چک‌لیست عملی شما.
- هر نام میزبان را فهرست کنید و رکوردهای DNS نامرتبط را حفظ نمایید.
- مسیریابی نام میزبان را پیش از تغییر عمومی آزمایش کنید.
- یک چالش گواهی مناسب انتخاب و خودکارسازی کنید.
- تغییرات TTL و انتقال داده را برنامه‌ریزی کنید.
- DNS و TLS را از طریق بررسی‌های جداگانه تأیید کنید.
- دسترسی بازگشت را حفظ کنید و پیش از بازگرداندن، نوشتن‌های جدید را حل‌وفصل نمایید.
جزئیاتی که اهمیت دارند.
آیا تغییر یک رکورد A، HTTPS را فعال می‌کند؟+
خیر. DNS یک نقطه پایانی را انتخاب می‌کند؛ آن نقطه پایانی هنوز به مسیریابی نام میزبان صحیح و یک گواهی معتبر نصب‌شده نیاز دارد.
اگر مشکلی پیش بیاید، آیا می‌توانم فقط رکورد DNS را بازگردانم؟+
ترافیک می‌تواند تغییر مسیر داده شود، اما نوشتن‌های برنامه نیازمند رسیدگی جداگانه هستند. پیش از مهاجرت یک برنامه بازگشت داده یا تطبیق تعریف کنید.
آیا گواهی wildcard همیشه ضروری است؟+
خیر. نام‌های گواهی و اعتبارسنجی را بر اساس نام‌های میزبان واقعی انتخاب کنید. یک wildcard پوشش و الزامات اعتبارسنجی خاصی دارد؛ این یک میانبر جهانی مهاجرت نیست.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- Let's Encrypt: انواع چالش letsencrypt.org
- IETF RFC 1034: مفاهیم و امکانات DNS datatracker.ietf.org
- موزیلا MDN: امنیت لایه انتقال developer.mozilla.org
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.