# Runbook перемикання домену, DNS і TLS для нового сервера | SwissOctet Insights https://swissoctet.com/uk/insights/dns-tls-cutover-runbook/ SwissOctet / Аналітика / Веб і onion Веб і onion Прикладний · 4 хв читання Runbook перемикання домену, DNS і TLS для нового сервера Підготуйте маршрутизацію імен хостів, сертифікати та відкат разом, щоб міграція змінила сервер, не порушивши ідентичність сайту чи захищені з'єднання. Автор: SwissOctet Editorial Зберегти посібник Копіювати посилання НА ЦІЙ СТОРІНЦІ 01 Інвентаризуйте імена та залежності 02 Підготуйте маршрутизацію імен хостів на новому сервері 03 Виберіть метод перевірки сертифіката 04 Сплануйте вікно кешу перед зміною DNS 05 Перевірте DNS і TLS окремо 06 Зробіть відкат також рішенням щодо даних 07 Спостерігайте за сайтом після перемикання Ваш практичний контрольний список Джерела та додаткове читання Назад до бібліотеки ПРЯМА ВІДПОВІДЬ Підготуйте сервер і сертифікат для передбаченого імені хоста, перевірте застосунок перед зміною публічного DNS і залишайте старе середовище доступним під час переходу. Перевіряйте авторитетні записи, кешовані відповіді та TLS незалежно. Саме лише оновлення DNS не підтверджує, що обслуговується правильний застосунок і сертифікат. 01 Інвентаризуйте імена та залежності Перелічіть усі імена хостів, які використовує сайт, зокрема основний домен, псевдоніми, кінцеві точки API та зворотні виклики застосунку. Запишіть, хто контролює реєстрацію та авторитетний DNS. Розміщення застосунку не реєструє автоматично його домен і не дає оператору сервера контролю над його записами. Зберігайте доступ до наявного середовища, доки нове не буде перевірено. Також визначте записи електронної пошти та сторонньої перевірки, які має зберегти переміщення. Міграція вебсайту не повинна бездумно замінювати всю зону DNS. Складіть план змін на рівні записів із передбаченими адресами та значенням для відкату. Зберігайте облікові дані приватно; runbook потребує власників і процедур, а не фактичних паролів чи токенів API. 02 Підготуйте маршрутизацію імен хостів на новому сервері Машина, яка приймає з'єднання, повинна обслуговувати передбачений застосунок для свого імені хоста. Налаштуйте вебсервер або панель хостингу відповідно, відокремивши публічний корінь документів від приватної конфігурації та облікових даних. Перевірте всі потрібні імена та перенаправлення, а не лише загальну вітальну сторінку, доступну за адресою сервера. Використовуйте контрольований метод тестування, який надсилає передбачене ім'я хоста на нову кінцеву точку до публічної зміни. Перевірте вхід, завантаження та згенеровані застосунком посилання, де це застосовно. Вимкніть завдання, які під час тестування могли б дублювати виробничі дії. Тест має довести поведінку застосунку без надсилання справжньої пошти, проведення платежів чи ненавмисної зміни старої робочої бази даних. 03 Виберіть метод перевірки сертифіката Видача сертифіката вимагає підтвердження контролю для запитаних імен. Let's Encrypt документує HTTP-01 та DNS-01 серед своїх методів перевірки. Перевірка HTTP залежить від правильного обслуговування потрібного виклику; перевірка DNS використовує вказаний запис DNS і може підтримувати видачу wildcard-сертифіката. Виберіть метод, який відповідає фактичному розгортанню і який можна безпечно підтримувати. За можливості обмежуйте облікові дані для перевірки вузькою сферою. Автоматизація DNS особливо чутлива, оскільки широкі облікові дані DNS можуть впливати на більш ніж один вебсайт. Сплануйте поновлення сертифіката та те, як оновлені файли потрапляють до процесу обслуговування. Успішна перша видача корисна, але сайту також потрібен робочий процес поновлення та моніторинг сертифіката, який він фактично надає. 04 Сплануйте вікно кешу перед зміною DNS Записи DNS мають час життя, який використовують резолвери під час кешування відповідей. Зміна запису не замінює миттєво кожен кешований результат. Якщо переходу сприяє коротший TTL, сплануйте коригування достатньо завчасно, щоб раніше кешовані відповіді могли завершитися. Залишайте і старе, і нове середовища здатними обробити спроєктований вами перехід. Ця ілюстративна послідовність відокремлює підготовку від публічного перемикання. Її час потрібно адаптувати до домену, поведінки резолверів і застосунку. Це не універсальний графік поширення. Міграція з активними записами також потребує перемикання даних, специфічного для застосунку, бо інакше два працюючі вебсервери можуть приймати зміни в різні набори даних. Етап Дія Умова перед продовженням Підготовка Інвентаризуйте записи та налаштуйте нову кінцеву точку Застосунок працює для передбачених імен Сертифікат Видайте та встановіть сертифікат Правильний ланцюжок і ім'я хоста проходять перевірку Перехід Оновіть лише заплановані записи DNS Перемикання даних і відкат визначено Спостереження Перевірте авторитетні результати та результати клієнтів Користувацькі сценарії успішні через нову кінцеву точку Завершення Виведіть стару послугу з експлуатації після перевірки Залишковий трафік і потреби відновлення переглянуто 05 Перевірте DNS і TLS окремо Спочатку перевірте авторитетний запис, потім порівняйте відповіді від клієнтів або резолверів, задіяних у переході. Правильне авторитетне значення та старіше кешоване значення можуть співіснувати. Перевірте кінцеву точку, до якої потрапляє браузер, а не припускайте, що кожне з'єднання вже використовує нову адресу. Зберігайте спостереження з часовими мітками, щоб перехід було зрозуміло. Для TLS перевірте передбачене ім'я хоста, чинність сертифіката та ланцюжок через фактичне клієнтське з'єднання. Перевірте кожен потрібний псевдонім і шлях перенаправлення. Документація Mozilla TLS пояснює автентифікацію сервера та проблеми змішаного вмісту: сторінка та її підресурси мають доставлятися безпечно. Сертифікат для одного імені хоста не покриває автоматично іншу кінцеву точку застосунку. 06 Зробіть відкат також рішенням щодо даних Відкат DNS може перенаправити трафік, але він не скасовує записи, зроблені в новому застосунку. Визначте, як ви оброблятимете ці дані до перемикання. Для статичної публікації відкат може бути простим; для послуги, що приймає завантаження чи замовлення, стан застосунку потребує чіткого власника та процедури узгодження. Уявіть міграцію невеликого видавничого сайту з коментарями. Ви можете підготувати інтервал обслуговування або контрольований перехід лише для читання, поки копіюються остаточні дані. Перевірте процедуру повторного відкриття та тримайте старе розгортання готовим. Виберіть підхід, що відповідає застосунку, а не використовуйте зміну DNS як заміну плануванню узгодженості. 07 Спостерігайте за сайтом після перемикання Перевірте реальні користувацькі сценарії, рівні помилок, надання сертифіката та фонові завдання після того, як нова кінцева точка почне отримувати трафік. Підтвердьте, що резервні копії тепер охоплюють передбачений застосунок і дані. Перегляньте доступ до старого сервера перед виведенням з експлуатації та видаліть застарілі облікові дані, коли потреби відновлення й відкату буде вирішено. Запишіть фінальну конфігурацію DNS і сертифіката. Вибираючи вебхостинг або обчислювальні ресурси SwissOctet, підтвердьте фактичні обов'язки щодо домену, сертифіката й адміністрування для цієї конфігурації. Каталог надає місце хостингу та ресурси; він не підтверджує, що ваш домен уже підключено або що поновлення сертифіката налаштовано. Зробіть ці кроки конкретними й перевірюваними в плані розгортання. ПЕРЕТВОРІТЬ ЦЕ НА ДІЮ Ваш практичний контрольний список. ✓ Інвентаризуйте кожне ім'я хоста та збережіть не пов'язані записи DNS. ✓ Перевірте маршрутизацію імен хостів перед публічним перемиканням. ✓ Виберіть і автоматизуйте відповідний виклик сертифіката. ✓ Сплануйте зміни TTL і перехід даних. ✓ Перевірте DNS і TLS окремими перевірками. ✓ Збережіть доступ для відкату та вирішіть питання нових записів перед поверненням. Завантажити контрольний список ПОШИРЕНІ ЗАПИТАННЯ Деталі, які мають значення. Чи активує зміна A-запису HTTPS? + Ні. DNS вибирає кінцеву точку; ця кінцева точка все одно потребує правильної маршрутизації імені хоста та чинного встановленого сертифіката. Чи можна повернути лише запис DNS, якщо щось зламається? + Трафік можна перенаправити, але записи застосунку потребують окремої обробки. Визначте план відкату даних або узгодження перед міграцією. Чи завжди потрібен wildcard-сертифікат? + Ні. Вибирайте імена сертифікатів і перевірку відповідно до фактичних імен хостів. Wildcard-сертифікат має конкретні вимоги до покриття й перевірки; це не універсальний ярлик для міграції. ОСНОВНІ ДЖЕРЕЛА Перейдіть до джерела. Ці джерела підкріплюють технічні концепції в цьому посібнику. Дотримуйтеся поточної документації перед зміною робочої системи. Let's Encrypt: типи викликів letsencrypt.org IETF RFC 1034: концепції та засоби DNS datatracker.ietf.org Mozilla MDN: Transport Layer Security developer.mozilla.org Редакційне керівництво від SwissOctet. Приклади є ілюстративними. Специфікації послуг, доступні опції та договірні умови потрібно перевіряти окремо. ПОЄДНАЙТЕ ЗНАННЯ Пов'язана інфраструктура. Canvas Web Швейцарія Vector VPS Швейцарія Pulse NVMe Швейцарія ЗБЕРІГАЙТЕ НИТКУ Ваші наступні польові нотатки. Дослідити всі посібники ПОЛЬОВА НОТАТКА / 01 + Хмара та VPS Основа Як вибрати VPS, не вгадуючи Перетворіть ідею застосунку на корисний бюджет ресурсів, а потім порівняйте CPU, пам'ять, сховище та передачу разом. 4 хв читання Читати посібник ПОЛЬОВА НОТАТКА / 02 + Веб і onion Основа Вебхостинг або VPS: виберіть роботу, яку хочете взяти на себе Порівнюйте вимоги застосунку, контроль і обов'язки з обслуговування, а не вважайте VPS автоматичним наступним кроком для кожного вебсайту. 6 хв читання Читати посібник ПОЛЬОВА НОТАТКА / 03 + Веб і onion Прикладний Публікуйте onion-сервіс, не забуваючи про застосунок Сплануйте законну onion-публікацію з контрольованим відкриттям бекенду, ретельним переглядом вмісту, відновленням ключів сервісу та явною моделлю доступу аудиторії. 4 хв читання Читати посібник