Миграция DNS без простоя

Миграция DNS без простоя

Миграция DNS - это процесс переноса DNS записей на новые серверы или изменение конфигурации без прерывания работы сайта и сервисов.

Когда требуется миграция DNS

• Смена хостинг-провайдера
• Переход на новые DNS серверы
• Изменение IP адресов серверов
• Переезд на новый сервер
• Смена регистратора домена
• Реорганизация инфраструктуры
• Переход на управляемый DNS (Cloudflare, Route53)

Риски при миграции

Неправильная миграция может привести к:

• Недоступности сайта (часы или дни)
• Потере входящих email
• Разрыву API интеграций
• Проблемам с SSL сертификатами
• Потере трафика и продаж
• Повреждению SEO рейтинга

Принципы миграции без простоя

1. Параллельная работа - старые и новые серверы работают одновременно
2. Постепенный переход - DNS меняется постепенно, не мгновенно
3. Низкий TTL - ускоряет распространение изменений
4. Проверка на каждом этапе - тестирование перед переключением
5. Готовность к откату - возможность вернуться назад

Временная шкала миграции

Этап	Время	Действия
Подготовка	За 7 дней	Аудит, планирование, резервное копирование
Снижение TTL	За 48-72 часа	Уменьшить TTL до 300-600 секунд
Настройка нового сервера	За 24-48 часов	Развертывание, тестирование
Миграция	День X	Изменение DNS записей
Мониторинг	24-48 часов	Проверка доступности, логи
Восстановление TTL	Через 48-72 часа	Поднять TTL обратно
Деактивация старого	Через 7 дней	Отключение старого сервера

Подготовка к миграции

Этап 1: Аудит текущей конфигурации

Инвентаризация DNS записей

1. Экспортируйте все DNS записи
2. Документируйте каждую запись и её назначение
3. Проверьте зависимости между записями

Команда для экспорта зоны:

# Через dig
dig example.com AXFR > zone_backup.txt

# Или dig ANY для всех записей
dig example.com ANY +noall +answer > dns_records.txt

# Детальный экспорт с TTL
dig example.com ANY +noall +answer +nottlid > dns_full.txt

Создание инвентарной таблицы

Имя	Тип	Значение	TTL	Назначение	Приоритет
@	A	192.0.2.1	14400	Основной сайт	Критичный
www	A	192.0.2.1	14400	WWW алиас	Критичный
mail	A	192.0.2.2	14400	Почтовый сервер	Критичный
@	MX	mail.example.com	14400	Входящая почта	Критичный
ftp	CNAME	@	14400	FTP доступ	Низкий

Проверка зависимостей

Что проверить:

• SSL сертификаты и их зависимость от DNS
• Email сервисы (SMTP, IMAP, POP3)
• API endpoints
• CDN конфигурация
• Поддомены и их использование
• Сторонние сервисы (платежные шлюзы и т.д.)

Этап 2: Планирование миграции

Определение стратегии

Стратегия 1: Параллельный запуск (рекомендуется)

• Новый сервер настраивается и тестируется
• DNS переключается на новый сервер
• Старый сервер остается доступным
• Подходит для большинства сценариев

Стратегия 2: Постепенная миграция

• Поддомены переносятся по одному
• Сначала тестовые, затем продакшн
• Подходит для сложных инфраструктур

Стратегия 3: Blue-Green Deployment

• Две идентичные среды
• Мгновенное переключение DNS
• Легкий откат
• Подходит для критичных систем

Выбор времени миграции

Лучшее время:

• Низкий трафик (ночь, выходные)
• Вне peak season
• Не перед важными событиями
• С учетом часовых поясов аудитории

Худшее время:

• Black Friday, праздники
• В разгар рабочего дня
• Перед дедлайнами
• Во время рекламных кампаний

Этап 3: Подготовка нового сервера

Настройка окружения

1. Установите веб-сервер, PHP, базу данных
2. Скопируйте файлы сайта
3. Импортируйте базы данных
4. Настройте конфигурацию
5. Установите SSL сертификаты

Тестирование через файл hosts

Протестируйте новый сервер БЕЗ изменения DNS:

Windows (C:\Windows\System32\drivers\etc\hosts):

192.0.2.100  example.com
192.0.2.100  www.example.com

Linux/Mac (/etc/hosts):

192.0.2.100  example.com
192.0.2.100  www.example.com

Откройте сайт в браузере и проверьте:

• Главная страница загружается
• Все функции работают
• Формы отправляются
• База данных доступна
• SSL сертификат корректный

Проверочный список для нового сервера

- [ ] Веб-сервер настроен и запущен - [ ] Все файлы скопированы - [ ] База данных импортирована - [ ] Конфигурационные файлы обновлены - [ ] SSL сертификат установлен - [ ] Email настроен - [ ] Cron задачи перенесены - [ ] Протестировано через hosts файл - [ ] Резервная копия создана - [ ] План отката готов

Этап 4: Резервное копирование

Что сохранить:

1. Экспорт DNS зоны (полный)
2. Конфигурация веб-сервера
3. Базы данных
4. Файлы сайта
5. SSL сертификаты
6. Email данные
7. Документация текущей настройки

# Резервная копия DNS через Zone Editor
# или экспорт через cPanel Backup

# Резервная копия файлов
tar -czf website_backup_$(date +%Y%m%d).tar.gz /home/username/public_html/

# Резервная копия базы данных
mysqldump -u user -p database > db_backup_$(date +%Y%m%d).sql

Снижение TTL

За 48-72 часа до миграции:

Почему важен низкий TTL

TTL (Time To Live) определяет, как долго DNS запись кэшируется.

• Высокий TTL (14400 = 4 часа): изменения распространяются медленно
• Низкий TTL (300 = 5 минут): изменения распространяются быстро

Снижение TTL в cPanel

1. Перейдите в Zone Editor → Manage
2. Для КАЖДОЙ записи, которую будете менять:
   1. Нажмите Edit
   2. Измените TTL на 300 или 600
   3. Сохраните
3. Подождите СТАРЫЙ TTL (например, 4 часа) перед миграцией

Какие записи изменить:

• A записи для домена и поддоменов
• AAAA записи (если используются)
• CNAME записи
• MX записи (если переносите почту)

Проверка распространения нового TTL

# Проверить текущий TTL
dig example.com | grep "IN.*A"

# Должно показать новый TTL (300 или 600)
# Если показывает старый - подождите еще

Процесс миграции

Стратегия переноса по типам записей

Сценарий 1: Простой перенос веб-сайта

Что меняется:

• A запись домена
• A запись www

Что остается:

• MX записи (почта на старом месте)
• Другие поддомены

Последовательность:

1. Убедитесь, что новый сервер готов
2. Измените A запись для основного домена:

example.com.  300  IN  A  192.0.2.100  ; новый IP

1. Измените A запись для www:

www.example.com.  300  IN  A  192.0.2.100  ; новый IP

1. Проверьте доступность сайта
2. Мониторьте логи на ОБОИХ серверах

Сценарий 2: Перенос сайта и почты

Очередность (рекомендуется):

День 1: Перенос веб-сайта

1. Измените A записи для веб-сайта
2. Проверьте работу сайта
3. Мониторинг 24 часа

День 2: Перенос почты (если все ОК)

1. Настройте почту на новом сервере
2. Создайте email аккаунты
3. Переместите письма (опционально)
4. Измените MX записи:

example.com.  300  IN  MX  0  mail.newserver.com.

1. Обновите mail A запись:

mail.example.com.  300  IN  A  192.0.2.100

Сценарий 3: Полная миграция инфраструктуры

Поэтапный подход:

Фаза 1: Тестовые поддомены

test.example.com.  300  IN  A  192.0.2.100
dev.example.com.   300  IN  A  192.0.2.100

Мониторинг: 2-4 часа

Фаза 2: Некритичные поддомены

blog.example.com.  300  IN  A  192.0.2.100
cdn.example.com.   300  IN  A  192.0.2.100

Мониторинг: 24 часа

Фаза 3: Основной домен

example.com.       300  IN  A  192.0.2.100
www.example.com.   300  IN  A  192.0.2.100

Мониторинг: 48 часов

Фаза 4: Критичные сервисы

api.example.com.   300  IN  A  192.0.2.100
app.example.com.   300  IN  A  192.0.2.100

Мониторинг: 72 часа

Фаза 5: Почта

example.com.       300  IN  MX  0  mail.example.com.
mail.example.com.  300  IN  A  192.0.2.100

Изменение DNS записей

В cPanel Zone Editor

1. Перейдите в Zone Editor → Manage
2. Для каждой A записи:
   1. Нажмите Edit
   2. Измените Address на новый IP
   3. TTL оставьте 300/600
   4. Нажмите Save
3. Повторите для всех записей согласно плану

Проверка изменений

Немедленно после изменения проверьте:

# Проверка через разные DNS серверы
dig @8.8.8.8 example.com +short
dig @1.1.1.1 example.com +short
dig @ns1.your-hosting.com example.com +short

# Все должны вернуть НОВЫЙ IP

Смена DNS серверов (Name Servers)

Если переходите на другие DNS серверы:

Подготовка

1. На НОВЫХ DNS серверах создайте полную копию зоны
2. Проверьте, что все записи присутствуют
3. Дважды проверьте критичные записи (A, MX, TXT)

Изменение у регистратора

1. Войдите в панель регистратора домена
2. Найдите раздел Nameservers / DNS
3. Измените на новые NS:

Было:

ns1.old-hosting.com
ns2.old-hosting.com

Стало:

ns1.new-hosting.com
ns2.new-hosting.com

1. Сохраните изменения

Период перехода

В течение 24-48 часов:

• Некоторые пользователи видят старый сервер
• Другие видят новый сервер
• Оба сервера должны работать параллельно
• Синхронизируйте изменения на обоих

Мониторинг миграции

Проверка DNS распространения

Онлайн инструменты

• WhatsMyDNS.net - глобальная проверка
• DNS Checker - проверка по странам
• MXToolbox - комплексная проверка

Командная строка

# Мониторинг каждые 5 минут
watch -n 300 'dig example.com +short'

# Проверка с разных DNS серверов
for ns in 8.8.8.8 1.1.1.1 208.67.222.222; do
  echo "DNS: $ns"
  dig @$ns example.com +short
done

# Проверка всех типов записей
dig example.com ANY +noall +answer

Мониторинг доступности сайта

Проверка веб-сервера

# Проверка HTTP ответа
curl -I https://example.com

# Должен вернуть 200 OK

# Проверка времени ответа
curl -o /dev/null -s -w '%{time_total}\n' https://example.com

# Проверка конкретной страницы
curl -s https://example.com/test-page | grep "expected content"

Uptime мониторинг

Используйте сервисы:

• UptimeRobot (бесплатный)
• Pingdom
• StatusCake
• Site24x7

Настройте алерты на:

• Недоступность (HTTP 5xx)
• Медленный ответ (>3 секунды)
• Изменение контента

Мониторинг почты

Проверка MX записей

# Проверка MX
dig example.com MX +short

# Проверка почтового сервера
dig mail.example.com A +short

# Тест SMTP соединения
telnet mail.example.com 25
# или
nc -zv mail.example.com 25

Проверка доставки

1. Отправьте тестовое письмо на ваш домен
2. Проверьте, что письмо получено
3. Отправьте письмо с вашего домена
4. Проверьте логи доставки

Проверка SPF/DKIM/DMARC

# SPF
dig example.com TXT +short | grep spf

# DKIM
dig default._domainkey.example.com TXT +short

# DMARC
dig _dmarc.example.com TXT +short

Анализ логов

На старом сервере

Следите за уменьшением трафика:

# Apache/Nginx access log
tail -f /var/log/apache2/access.log
tail -f /var/log/nginx/access.log

# Подсчет запросов
tail -1000 /var/log/apache2/access.log | wc -l

На новом сервере

Следите за увеличением трафика:

# Мониторинг в реальном времени
tail -f /var/log/apache2/access.log

# Проверка ошибок
tail -f /var/log/apache2/error.log | grep -i error

Метрики для отслеживания

Метрика	Норма	Действие при отклонении
HTTP 5xx ошибки	<1%	Проверить логи, откатить при >5%
Время ответа	<2 сек	Оптимизировать, проверить ресурсы
Email bounce rate	<5%	Проверить MX, SMTP конфигурацию
DNS резолв время	<100ms	Проверить DNS серверы
SSL ошибки	0	Переустановить сертификат

Решение проблем во время миграции

Проблема: Часть пользователей видит старый сайт

Причина: DNS кэш, медленное распространение

Решение:

1. Это нормально в первые 24 часа
2. Оба сервера должны работать
3. Подождите полного распространения
4. Пользователи могут очистить DNS кэш:

# Windows
ipconfig /flushdns

# macOS
sudo killall -HUP mDNSResponder

# Linux
sudo systemd-resolve --flush-caches

Проблема: Сайт не открывается (502/504)

Причины:

• Веб-сервер не запущен на новом сервере
• Firewall блокирует порт 80/443
• PHP-FPM не работает
• База данных недоступна

Решение:

# Проверить статус веб-сервера
sudo systemctl status apache2
sudo systemctl status nginx

# Проверить порты
sudo netstat -tulpn | grep :80
sudo netstat -tulpn | grep :443

# Проверить логи
tail -50 /var/log/apache2/error.log
tail -50 /var/log/nginx/error.log

Проблема: SSL ошибки

Причины:

• Сертификат не установлен на новом сервере
• Сертификат выдан для другого домена
• Истек срок действия

Решение:

1. Установите SSL на новом сервере ДО миграции
2. Используйте Let's Encrypt для автоматической установки
3. Проверьте сертификат:

openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -dates

Проблема: Почта не доставляется

Причины:

• MX записи еще не обновились
• SMTP сервер не настроен
• Firewall блокирует порт 25

Решение:

1. Проверьте MX записи глобально
2. Убедитесь, что оба почтовых сервера работают
3. Проверьте порты:

telnet mail.example.com 25
telnet mail.example.com 587
telnet mail.example.com 993

Проблема: API интеграции не работают

Причины:

• Поддомен api. не обновлен
• Изменился IP, партнеры не обновили whitelist
• CORS настройки неправильные

Решение:

1. Обновите ВСЕХ партнеров о новом IP заранее
2. Сохраняйте старый IP в whitelist какое-то время
3. Проверьте CORS headers на новом сервере

План отката

Когда откатывать:

• Критичные ошибки >5% запросов
• Полная недоступность сервиса
• Потеря данных
• Невозможность исправить быстро

Откат DNS записей

1. В cPanel Zone Editor
2. Верните СТАРЫЕ IP адреса:

example.com.  300  IN  A  192.0.2.1  ; старый IP
www.example.com.  300  IN  A  192.0.2.1  ; старый IP

1. Распространение: 5-30 минут (благодаря низкому TTL)

Откат NS серверов

Если меняли nameservers:

1. Вернитесь в панель регистратора
2. Верните старые NS серверы
3. Распространение: 24-48 часов

Временное решение

Пока DNS откатывается:

1. Используйте hosts файл для себя
2. Настройте локальный DNS сервер
3. Уведомите пользователей о проблемах

После миграции

Первые 24 часа

- [ ] Мониторинг каждые 2 часа - [ ] Проверка метрик (uptime, response time) - [ ] Проверка логов ошибок - [ ] Тестирование функционала - [ ] Проверка email доставки - [ ] Мониторинг DNS распространения

24-48 часов

- [ ] Ежедневный мониторинг - [ ] Проверка аналитики (трафик не упал?) - [ ] Проверка конверсии - [ ] Сравнение с предыдущим периодом

Через 48-72 часа

Восстановление TTL:

1. Если все стабильно работает
2. Поднимите TTL обратно до 14400 (4 часа) или 86400 (1 день)
3. Это снизит нагрузку на DNS серверы

Через 7 дней

Деактивация старого сервера: - [ ] Убедитесь, что трафик на старом сервере = 0 - [ ] Сделайте финальную резервную копию - [ ] Деактивируйте старый сервер - [ ] Или сохраните как резервный

Чеклист миграции

За 7 дней

- [ ] Аудит DNS записей - [ ] Создание плана миграции - [ ] Резервное копирование всего - [ ] Настройка нового сервера - [ ] Тестирование через hosts

За 48-72 часа

- [ ] Снижение TTL до 300-600 секунд - [ ] Финальное тестирование нового сервера - [ ] Уведомление команды о миграции - [ ] Подготовка плана отката

День миграции

- [ ] Проверка готовности нового сервера - [ ] Изменение DNS записей по плану - [ ] Запуск мониторинга - [ ] Проверка доступности с разных точек - [ ] Мониторинг логов обоих серверов

После миграции

- [ ] Мониторинг 24-48 часов - [ ] Проверка всех сервисов - [ ] Анализ метрик - [ ] Восстановление TTL (через 48-72 часа) - [ ] Деактивация старого сервера (через 7 дней) - [ ] Документирование новой конфигурации - [ ] Post-mortem анализ (если были проблемы)

Специальные сценарии

Миграция с нулевым простоем (Enterprise)

Требования:

• Бюджет на дополнительную инфраструктуру
• Load balancer
• Несколько серверов

Подход:

1. Настройте load balancer с обоими серверами
2. DNS указывает на load balancer
3. Постепенно переносите трафик (10%, 25%, 50%, 100%)
4. При проблемах мгновенно возвращайте на старый

Миграция большого количества доменов

Автоматизация через API:

#!/bin/bash
# Пример скрипта массового обновления через cPanel API

DOMAINS=("example1.com" "example2.com" "example3.com")
NEW_IP="192.0.2.100"

for domain in "${DOMAINS[@]}"; do
    # Обновление через UAPI
    uapi --user=username DNS edit_zone \
        zone="$domain" \
        line=1 \
        type=A \
        address="$NEW_IP"
    
    echo "Updated $domain"
    sleep 2
done

Миграция с CDN (Cloudflare)

Преимущества:

• Cloudflare кэширует контент
• Минимальный простой
• Легкий откат

Процесс:

1. Добавьте домен в Cloudflare
2. Cloudflare сканирует DNS
3. Измените NS на Cloudflare
4. После распространения меняйте IP в Cloudflare
5. Instant update (без ожидания DNS)

Инструменты для миграции

DNS инструменты

• dig - проверка DNS
• nslookup - простая проверка
• host - быстрая проверка
• WhatsMyDNS.net - глобальная проверка
• MXToolbox - комплексная проверка

Мониторинг

• UptimeRobot - uptime мониторинг
• Pingdom - performance мониторинг
• New Relic - APM мониторинг
• DataDog - инфраструктурный мониторинг

Миграция данных

• rsync - синхронизация файлов
• mysqldump - экспорт БД
• wp-cli - миграция WordPress
• cPanel Transfer Tool - автоматический перенос

Лучшие практики

1. Планируйте заранее - минимум за неделю
2. Тестируйте все - никогда не меняйте DNS без тестирования
3. Снижайте TTL - всегда за 48-72 часа
4. Мониторьте активно - первые 48 часов критичны
5. Держите старый сервер - минимум неделю после миграции
6. Документируйте - записывайте каждое изменение
7. Готовьте откат - план Б должен быть всегда
8. Уведомляйте пользователей - если возможны проблемы
9. Делайте поэтапно - не меняйте все сразу
10. Учитесь на ошибках - проводите post-mortem

Частые ошибки

1. Не снижен TTL заранее → долгое распространение
2. Забыли про поддомены → часть сервисов не работает
3. Не протестирован новый сервер → errors после миграции
4. Изменены NS без готовности новой зоны → полный простой
5. Почта и сайт мигрированы одновременно → сложная диагностика
6. Нет плана отката → паника при проблемах
7. Деактивирован старый сервер слишком рано → нет возможности отката
8. Не уведомлены партнеры об изменении IP → broken интеграции

См. также

• Подробно о DNS записях
• Управление доменами
• Создание резервных копий
• Troubleshooting DNS

Внешние ссылки

• WhatsMyDNS - Global DNS Propagation Checker
• MXToolbox - DNS & Email Tools
• Cloudflare DNS Migration Guide
• AWS Route 53 Migration Guide

---

Последнее обновление: 30 январь 2026