Делегирование DNS: регистратор и DNS-провайдер

Делегирование DNS — это способ передать полномочия за часть иерархии DNS-имён другому набору серверов имён. Регистратор домена обычно управляет делегированием серверов имён, передаваемым в реестр, а DNS-хостинг обслуживает записи зоны, на которые ссылается это делегирование. Это связанные, но разные зоны ответственности. Регистратор не обязательно хранит записи A, MX или TXT, а DNS-провайдер не может изменить родительское делегирование, если не управляет и настройками на стороне регистратора. Когда изменённые в панели записи не появляются публично, одной из первых вещей для проверки становится неверное или неожиданное делегирование.

Идём по цепочке полномочий от родителя к потомку

Рекурсивный резолвер начинает с доверенной информации о корне и следует по перенаправлениям (referral) через иерархию DNS. Корень указывает на домен верхнего уровня, например .com; TLD указывает на авторитативные серверы имён домена; те отдают записи домена или дальнейшие делегирования. Каждое перенаправление определяет, кто отвечает за следующую часть. Делегирование позволяет миллионам независимо управляемых зон сосуществовать, не требуя от одного глобального сервера хранить все записи. Оно же означает, что ошибка на одной передаче способна сделать недоступной вполне корректную зону.

1. Создайте и заполните целевую зону у нужного DNS-провайдера.
2. Уточните имена хостов авторитативных серверов имён, назначенных провайдером.
3. Задайте делегирование домена у регистратора или в родительской плоскости управления.
4. Проверьте публичные ответы NS и напрямую запросите авторитативные серверы.
5. После переключения проверьте ключевые записи сайта, почты и верификации.

Когда делегированный сервер имён находится внутри домена, который он обслуживает, в родительской зоне могут потребоваться glue-записи, чтобы резолверы могли узнать IP сервера, не спрашивая сам этот сервер. Провайдеры и регистраторы обычно ведут клиентов через эту настройку, но операторам собственных серверов имён нужно понимать такую зависимость. Опечатка, отсутствие glue-записей или несогласованное делегирование могут приводить к тайм-аутам и сбоям, даже если DNS-сервер работает. Стандартные имена серверов имён, которые предоставляют управляемые провайдеры, нередко избавляют клиентов от необходимости самим заниматься этой низкоуровневой деталью.

Почему неправильный провайдер может выглядеть правильным

В DNS-панели может отображаться полная зона, хотя этот провайдер не авторитативен для публичного домена. Возможно, домен всё ещё делегирован прежнему хостингу, обновление у регистратора не завершилось или поддомен делегирован отдельно. В таких случаях правка неактивной зоны не меняет ничего из того, что видят обычные публичные резолверы. Проверьте записи NS вне панели провайдера и сравните их с серверами имён, назначенными зоне. Если у поддомена есть собственное делегирование NS, записи этой ветки могут управляться независимо от родителя.

При переносе к другому провайдеру сохраняйте старую зону доступной, пока делегирование и кеши переходят на новое состояние. Заблаговременное уменьшение TTL записей помогает только после того, как старый TTL успел истечь. Копируйте почтовые записи, записи верификации и поддоменов, а не только адрес сайта. После смены делегирования запросите новые авторитативные серверы и сравните ответы с подготовленной зоной. Перенос завершён, когда ожидаемые имена корректно разрешаются у нужного авторитетного источника и зависимые сервисы проверены, а не когда форма у регистратора сообщила об успехе.

Дополнительно читайте: что такое NS-запись, серверы имён и делегирование доменов и как проверить DNS-миграцию. Публичная DNS-проверка показывает ответы, видимые резолверу, а запрос к авторитативному серверу помогает проверить саму зону. Разделение делегирования у регистратора и хостинга записей — ключ к тому, чтобы понять, где именно нужно вносить DNS-изменение.

Продумайте передачу делегирования

Для чистой передачи делегирования определите точные дату и время, когда отправляется изменение у регистратора, кто может его отменить и какие проверки через резолверы подтвердят завершение. На время перехода держите контакт с представителями и старого, и нового DNS-провайдера. Если домен использует собственные серверы имён или делегированные дочерние зоны, включите эти зависимости в регламент. Успешное обновление у регистратора не доказывает, что имя каждого сервера имён разрешается и что скопированы все записи сервисов. Проверьте данные NS, типичные ответы A и AAAA, цели MX и критичные политики TXT снаружи аккаунта. Так у команды появится чек-лист, охватывающий и полномочия, и сервисы, зависящие от делегированной зоны. После перехода отключайте прежнего провайдера, только когда команда подтвердила, что новый авторитетный источник отдаёт все ожидаемые записи, а окно отката закрылось. Сохраните дату, значения делегирования и результаты проверки в заявке на изменение, чтобы будущий администратор мог понять, какой DNS-сервис отвечает за домен.