TTK: Новая страница: «= Миграция DNS без простоя = Миграция DNS - это процесс переноса DNS записей на новые серверы или изменение конфигурации без прерывания работы сайта и сервисов. == Когда требуется миграция DNS == * Смена хостинг-провайдера * Переход на новые DNS серверы * Изменени...»

2026-01-27T16:31:50Z

Новая страница: «= Миграция DNS без простоя = Миграция DNS - это процесс переноса DNS записей на новые серверы или изменение конфигурации без прерывания работы сайта и сервисов. == Когда требуется миграция DNS == * Смена хостинг-провайдера * Переход на новые DNS серверы * Изменени...»

Новая страница

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

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

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

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

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

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

{{Важно|Правильная подготовка - ключ к миграции без простоя!}}

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

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

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

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

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

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

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

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

'''Команда для экспорта зоны:'''
<syntaxhighlight lang="bash">
# Через 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
</syntaxhighlight>

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

{| class="wikitable"
|-
! Имя !! Тип !! Значение !! 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: Подготовка нового сервера ===

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

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

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

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

'''Windows (C:\Windows\System32\drivers\etc\hosts):'''
<pre>
192.0.2.100 example.com
192.0.2.100 www.example.com
</pre>

'''Linux/Mac (/etc/hosts):'''
<pre>
192.0.2.100 example.com
192.0.2.100 www.example.com
</pre>

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

{{Совет|Используйте режим инкогнито для тестирования, чтобы избежать кэша браузера.}}

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

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

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

'''Что сохранить:'''
# Экспорт DNS зоны (полный)
# Конфигурация веб-сервера
# Базы данных
# Файлы сайта
# SSL сертификаты
# Email данные
# Документация текущей настройки

<syntaxhighlight lang="bash">
# Резервная копия 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
</syntaxhighlight>

== Снижение TTL ==

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

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

TTL (Time To Live) определяет, как долго DNS запись кэшируется.
* '''Высокий TTL''' (14400 = 4 часа): изменения распространяются медленно
* '''Низкий TTL''' (300 = 5 минут): изменения распространяются быстро

=== Снижение TTL в cPanel ===

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

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

{{Важно|Не меняйте NS записи на этом этапе!}}

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

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

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

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

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

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

'''Что меняется:'''
* A запись домена
* A запись www

'''Что остается:'''
* MX записи (почта на старом месте)
* Другие поддомены

'''Последовательность:'''
# Убедитесь, что новый сервер готов
# Измените A запись для основного домена:
<pre>
example.com. 300 IN A 192.0.2.100 ; новый IP
</pre>
# Измените A запись для www:
<pre>
www.example.com. 300 IN A 192.0.2.100 ; новый IP
</pre>
# Проверьте доступность сайта
# Мониторьте логи на ОБОИХ серверах

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

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

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

'''День 2: Перенос почты (если все ОК)'''
# Настройте почту на новом сервере
# Создайте email аккаунты
# Переместите письма (опционально)
# Измените MX записи:
<pre>
example.com. 300 IN MX 0 mail.newserver.com.
</pre>
# Обновите mail A запись:
<pre>
mail.example.com. 300 IN A 192.0.2.100
</pre>

{{Предупреждение|НЕ меняйте почту и сайт одновременно! Это усложняет диагностику проблем.}}

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

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

'''Фаза 1: Тестовые поддомены'''
<pre>
test.example.com. 300 IN A 192.0.2.100
dev.example.com. 300 IN A 192.0.2.100
</pre>
Мониторинг: 2-4 часа

'''Фаза 2: Некритичные поддомены'''
<pre>
blog.example.com. 300 IN A 192.0.2.100
cdn.example.com. 300 IN A 192.0.2.100
</pre>
Мониторинг: 24 часа

'''Фаза 3: Основной домен'''
<pre>
example.com. 300 IN A 192.0.2.100
www.example.com. 300 IN A 192.0.2.100
</pre>
Мониторинг: 48 часов

'''Фаза 4: Критичные сервисы'''
<pre>
api.example.com. 300 IN A 192.0.2.100
app.example.com. 300 IN A 192.0.2.100
</pre>
Мониторинг: 72 часа

'''Фаза 5: Почта'''
<pre>
example.com. 300 IN MX 0 mail.example.com.
mail.example.com. 300 IN A 192.0.2.100
</pre>

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

==== В cPanel Zone Editor ====

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

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

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

<syntaxhighlight lang="bash">
# Проверка через разные 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
</syntaxhighlight>

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

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

==== Подготовка ====

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

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

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

'''Было:'''
<pre>
ns1.old-hosting.com
ns2.old-hosting.com
</pre>

'''Стало:'''
<pre>
ns1.new-hosting.com
ns2.new-hosting.com
</pre>

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

{{Важно|Изменение NS серверов распространяется 24-48 часов!}}

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

В течение 24-48 часов:
* Некоторые пользователи видят старый сервер
* Другие видят новый сервер
* Оба сервера должны работать параллельно
* Синхронизируйте изменения на обоих

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

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

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

* [https://www.whatsmydns.net/ WhatsMyDNS.net] - глобальная проверка
* [https://dnschecker.org/ DNS Checker] - проверка по странам
* [https://mxtoolbox.com/SuperTool.aspx MXToolbox] - комплексная проверка

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

<syntaxhighlight lang="bash">
# Мониторинг каждые 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
</syntaxhighlight>

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

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

<syntaxhighlight lang="bash">
# Проверка 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"
</syntaxhighlight>

==== Uptime мониторинг ====

Используйте сервисы:
* UptimeRobot (бесплатный)
* Pingdom
* StatusCake
* Site24x7

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

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

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

<syntaxhighlight lang="bash">
# Проверка MX
dig example.com MX +short

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

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

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

# Отправьте тестовое письмо на ваш домен
# Проверьте, что письмо получено
# Отправьте письмо с вашего домена
# Проверьте логи доставки

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

<syntaxhighlight lang="bash">
# SPF
dig example.com TXT +short | grep spf

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

# DMARC
dig _dmarc.example.com TXT +short
</syntaxhighlight>

=== Анализ логов ===

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

Следите за уменьшением трафика:
<syntaxhighlight lang="bash">
# 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
</syntaxhighlight>

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

Следите за увеличением трафика:
<syntaxhighlight lang="bash">
# Мониторинг в реальном времени
tail -f /var/log/apache2/access.log

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

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

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

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

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

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

'''Решение:'''
# Это нормально в первые 24 часа
# Оба сервера должны работать
# Подождите полного распространения
# Пользователи могут очистить DNS кэш:
<syntaxhighlight lang="bash">
# Windows
ipconfig /flushdns

# macOS
sudo killall -HUP mDNSResponder

# Linux
sudo systemd-resolve --flush-caches
</syntaxhighlight>

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

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

'''Решение:'''
<syntaxhighlight lang="bash">
# Проверить статус веб-сервера
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
</syntaxhighlight>

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

'''Причины:'''
* Сертификат не установлен на новом сервере
* Сертификат выдан для другого домена
* Истек срок действия

'''Решение:'''
# Установите SSL на новом сервере ДО миграции
# Используйте Let's Encrypt для автоматической установки
# Проверьте сертификат:
<syntaxhighlight lang="bash">
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -dates
</syntaxhighlight>

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

'''Причины:'''
* MX записи еще не обновились
* SMTP сервер не настроен
* Firewall блокирует порт 25

'''Решение:'''
# Проверьте MX записи глобально
# Убедитесь, что оба почтовых сервера работают
# Проверьте порты:
<syntaxhighlight lang="bash">
telnet mail.example.com 25
telnet mail.example.com 587
telnet mail.example.com 993
</syntaxhighlight>

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

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

'''Решение:'''
# Обновите ВСЕХ партнеров о новом IP заранее
# Сохраняйте старый IP в whitelist какое-то время
# Проверьте CORS headers на новом сервере

== План отката ==

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

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

# В cPanel Zone Editor
# Верните СТАРЫЕ IP адреса:
<pre>
example.com. 300 IN A 192.0.2.1 ; старый IP
www.example.com. 300 IN A 192.0.2.1 ; старый IP
</pre>
# Распространение: 5-30 минут (благодаря низкому TTL)

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

Если меняли nameservers:
# Вернитесь в панель регистратора
# Верните старые NS серверы
# Распространение: 24-48 часов

{{Предупреждение|Откат NS серверов занимает столько же времени, сколько прямая миграция!}}

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

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

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

=== Первые 24 часа ===

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

=== 24-48 часов ===

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

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

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

=== Через 7 дней ===

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

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

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

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

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

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

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

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

'''Требования:'''
* Бюджет на дополнительную инфраструктуру
* Load balancer
* Несколько серверов

'''Подход:'''
# Настройте load balancer с обоими серверами
# DNS указывает на load balancer
# Постепенно переносите трафик (10%, 25%, 50%, 100%)
# При проблемах мгновенно возвращайте на старый

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

'''Автоматизация через API:'''
<syntaxhighlight lang="bash">
#!/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
</syntaxhighlight>

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

'''Преимущества:'''
* Cloudflare кэширует контент
* Минимальный простой
* Легкий откат

'''Процесс:'''
# Добавьте домен в Cloudflare
# Cloudflare сканирует DNS
# Измените NS на Cloudflare
# После распространения меняйте IP в Cloudflare
# 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''' - автоматический перенос

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

# '''Планируйте заранее''' - минимум за неделю
# '''Тестируйте все''' - никогда не меняйте DNS без тестирования
# '''Снижайте TTL''' - всегда за 48-72 часа
# '''Мониторьте активно''' - первые 48 часов критичны
# '''Держите старый сервер''' - минимум неделю после миграции
# '''Документируйте''' - записывайте каждое изменение
# '''Готовьте откат''' - план Б должен быть всегда
# '''Уведомляйте пользователей''' - если возможны проблемы
# '''Делайте поэтапно''' - не меняйте все сразу
# '''Учитесь на ошибках''' - проводите post-mortem

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

# '''Не снижен TTL заранее''' → долгое распространение
# '''Забыли про поддомены''' → часть сервисов не работает
# '''Не протестирован новый сервер''' → errors после миграции
# '''Изменены NS без готовности новой зоны''' → полный простой
# '''Почта и сайт мигрированы одновременно''' → сложная диагностика
# '''Нет плана отката''' → паника при проблемах
# '''Деактивирован старый сервер слишком рано''' → нет возможности отката
# '''Не уведомлены партнеры об изменении IP''' → broken интеграции

== См. также ==

* [[DNS зоны в cPanel|Подробно о DNS записях]]
* [[Управление доменами в cPanel|Управление доменами]]
* [[Резервные копии cPanel|Создание резервных копий]]
* [[Устранение проблем DNS|Troubleshooting DNS]]

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

* [https://www.whatsmydns.net/ WhatsMyDNS - Global DNS Propagation Checker]
* [https://mxtoolbox.com/ MXToolbox - DNS & Email Tools]
* [https://www.cloudflare.com/learning/dns/dns-migration/ Cloudflare DNS Migration Guide]
* [https://aws.amazon.com/premiumsupport/knowledge-center/migrate-dns-domain-route-53/ AWS Route 53 Migration Guide]

---

''Последнее обновление: {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}}''

[[Категория:DNS]]
[[Категория:Миграция]]
[[Категория:Руководства пользователя]]
[[Категория:CPanel]]
[[Категория:Хостинг]]

Миграция DNS без простоя - История изменений