Файл зоны DNS: записи, имена и TTL

Файл зоны DNS — это текстовое представление DNS-записей зоны, например example.com. Он описывает имена и связанные с ними данные: адреса, псевдонимы, почтовые серверы, серверы имён и текстовые политики. Многие управляемые провайдеры прячут сам файл за веб-интерфейсом, но экспорт и импорт всё равно опираются на понятия файла зоны. Понимать формат полезно при переносе к другому провайдеру, аудитах и диагностике: запись может быть синтаксически корректной, но привязанной не к тому имени или истолкованной по неожиданному значению по умолчанию. Тщательная проверка должна учитывать и содержимое каждой записи, и контекст зоны, в котором она находится.

Из чего состоит ресурсная запись

Ресурсная запись обычно включает имя владельца, необязательный TTL, класс (чаще всего IN для интернет-данных), тип записи и данные, специфичные для этого типа. Строка записи A содержит адрес IPv4, строка MX — приоритет и имя почтового сервера, строка CNAME — каноническое целевое имя. В файлах зон можно использовать относительные имена, где владелец трактуется относительно базового имени зоны (origin), и специальные символы вроде @ для обозначения корня зоны. Завершающая точка может отмечать полное доменное имя. При импорте путаница между относительными и абсолютными именами способна случайно создать повторяющийся суффикс домена.

Корень зоны (zone apex) — это само имя зоны без поддоменов, например example.com; в файле зоны его часто обозначают символом @. Именно здесь находятся записи SOA и NS зоны. Записи A и AAAA в корне публикуют адреса, а владельцы вроде www или mail — это отдельные имена поддоменов. Провайдеры иногда предлагают функции ALIAS или flattening, которые выглядят как адрес в корне, а на деле следуют за именем хоста; это особенность конкретного провайдера, а не обычная запись CNAME в корне. При переносе проверьте, как провайдер-получатель сопоставляет такие функции, прежде чем копировать их буквально.

Проверяйте зону как полную карту сервисов

Не воспринимайте экспорт DNS только как конфигурацию сайта. Доставка почты может зависеть от MX и TXT-записей SPF, DKIM и DMARC. Подтверждение владения для аналитики, поисковых сервисов, систем сертификатов и SaaS-платформ может опираться на записи TXT или CNAME. Для обнаружения сервисов может использоваться SRV, а у делегированных поддоменов бывают собственные записи NS. Старая запись, которая выглядит незнакомой, всё ещё может обеспечивать рабочую зависимость в продакшене. Прежде чем что-либо удалять, выясните, кто её владелец и зачем она нужна. Если происхождение записи неизвестно, сверьте её с документацией приложений и спросите ответственную команду, а не считайте, что имя хоста, которое выглядит неиспользуемым, можно безопасно удалить.

• Экспортируйте всю зону перед переносом к другому провайдеру или чисткой.
• Внимательно проверяйте имена корня и поддоменов, включая правила относительных имён.
• Сохраняйте записи почты, верификации и делегированных поддоменов.
• Проверьте TTL и особенности провайдера: flattening и прокси-функции.
• После импорта запросите авторитативные серверы имён и сравните критичные записи.

Безопасный импорт и проверка

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

Значения самых распространённых записей разобраны в статье обзор типов DNS-записей. О стороне серверов имён при переносе читайте в статье что делает NS-запись. Файл зоны — это компактная опись конфигурации, и польза от него максимальна, когда команды сохраняют контекст рядом с сырыми строками. Добавляйте заметки о том, почему существуют необычные записи, кто ими владеет и какие сервисы от них зависят. Такой небольшой объём документации может уберечь от ситуации, когда последующая чистка молча удалит что-то важное.

Сохраняйте замысел, а не только экспортированные строки

Сырой экспорт зоны — полезная резервная копия, но он редко объясняет, зачем существует запись и какая команда от неё зависит. Добавьте рядом с файлом реестр, в котором указаны владелец приложения, поставщик, дата продления или проверки и можно ли безопасно менять значение. Этот контекст особенно важен для TXT-записей: они могут выглядеть как произвольные токены, но подтверждать владение доменом или разрешать отправку почтовым системам. При аудите отличайте активные записи от устаревших, оставленных на время перехода. После импорта у нового провайдера сравнивайте и данные, и поведение: прокси-переключатели, flattening и настройки проверки, специфичные для провайдера, могут не отражаться как обычные строки файла зоны. Зона — это рабочая конфигурация, поэтому сохранение её замысла делает последующие изменения безопаснее.