Файлы DNS-зон: структура, доступ и практическое применение

Файл DNS-зоны — это самое близкое к переписи населения, что есть в доменной индустрии: для конкретного домена верхнего уровня он показывает, что зарегистрировано и как делегировано. Отсюда логично начинать любое исследование доменов — но от сырого файла зоны до списка, с которым можно работать, дистанция большая. В этой статье разбираем, что на самом деле лежит внутри файла, чем отличается доступ к gTLD и ccTLD и что нужно сделать с данными, прежде чем они станут пригодны для SEO, инвестиций или холодных рассылок.

Анатомия файла DNS-зоны

Файл DNS-зоны — это обычный текстовый файл, описывающий зону DNS. Он сопоставляет доменные имена с IP-адресами и другими ресурсами, задавая маршрутизацию трафика домена. На уровне TLD такие файлы огромны: зона .com охватывает 157 775 115 доменов, а средний по размеру ccTLD может содержать пару сотен тысяч. Любой подход к разбору нужно проектировать под размер конкретной зоны — то, что работает для небольшого ccTLD в таблице, на .com не выживет.

SOA-записи: метаданные зоны

Каждый файл зоны начинается с записи Start of Authority (SOA). В ней хранятся метаданные зоны: основной сервер имён, e-mail администратора в нотации DNS, серийный номер и временные параметры. Значение refresh — как часто вторичный сервер должен проверять обновления на первичном — обычно лежит в диапазоне от часа до 24 часов. Практическую пользу приносит серийный номер: он увеличивается при каждом изменении, что даёт дешёвый способ убедиться, что перед вами более свежая копия зоны, чем та, что уже есть.

NS-записи: делегирование полномочий

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

A- и AAAA-записи: связка с IP-адресом

A-записи (IPv4) и AAAA-записи (IPv6) связывают домен или поддомен с IP-адресом. Они живут уже в собственной зоне домена, которую обслуживают серверы имён, назначенные делегированием TLD, — поэтому получить их можно только резолвингом каждого домена, а не чтением файла TLD. Именно на этом шаге появляются данные о хостинг-провайдере и географии, и обходится он заметно дороже, чем разбор самого файла зоны.

MX-записи: привратники почты

Записи почтовых серверов (MX) определяют, какие серверы обрабатывают почту домена и в каком порядке приоритета. На практике это же и самые быстро меняющиеся записи: домен может сменить почтового провайдера без каких-либо других заметных изменений. Тем, кто планирует по доменным данным работу с e-mail, стоит перепроверять актуальность MX прямо перед использованием, а не полагаться на запись, снятую несколько недель назад.

Где брать файлы зон: разрыв между gTLD и ccTLD

Получение данных зон — процесс неоднородный. Доступ сильно различается между общими доменами верхнего уровня (gTLD) и национальными (ccTLD).

Файлы зон gTLD: относительно доступны

Для gTLD вроде .com, .net, .org, .xyz и .app доступ регулируется сервисом ICANN — Centralized Zone Data Service (CZDS). Реестры, работающие по договорам с ICANN, обязаны предоставлять файлы зон одобренным заявителям, которые подают заявку по каждому TLD отдельно и принимают условия использования. Одобрение выдаёт каждый реестр самостоятельно, в нём могут отказать или отозвать его, а файлы публикуются ежедневно. Схема рабочая, но административно затратная: на каждый TLD — отдельная заявка, и доступ нужно поддерживать.

Файлы зон ccTLD: проблема добычи данных

Файлы зон ccTLD получить заметно сложнее, чем gTLD. Реестры ccTLD работают вне договоров ICANN по gTLD и устанавливают собственные правила. Одни отдают данные зон исследователям по соглашению, другие не публикуют ничего вовсе, и юрисдикции с жёстким отношением к приватности регулярно попадают во вторую группу: DENIC для .de и AFNIC для .fr ограничивают массовый доступ к зоне, а не публикуют её открыто. Там, где реестр ничего не публикует, покрытие приходится собирать из других источников: пассивный DNS, логи Certificate Transparency, данные краулинга и агрегированные коммерческие датасеты. Поэтому по-настоящему глобальная база доменов никогда не строится на одном конвейере.

Проблема шума в свежезарегистрированных доменах

Списки свежезарегистрированных доменов, получаемые из ежедневных диффов файлов зон, полезны, но зашумлены. Заметная доля новых регистраций любого дня — это паркинг, PPC-заглушки, защитные регистрации и массовые регистрации, на которых никогда не появится настоящий сайт. Работать с сырым диффом означает работать в основном именно с ними.

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

Одна оговорка, которую стоит проговорить: агрессивная фильтрация по серверам имён даёт вполне заметный процент ложных срабатываний. Малый бизнес и личные проекты часто стартуют на самом дешёвом доступном хостинге, и его серверы имён неотличимы от массовых регистраций без ценности. Фильтр только по серверам имён выбросит и легитимные домены, поэтому его лучше использовать как один сигнал из нескольких, а не как жёсткое отсечение.

Свежие списки против устаревших дампов с маркетплейсов

Для работы со свежезарегистрированными доменами свежесть важнее объёма. Причина механическая, а не статистическая: ценность новой регистрации как лида в том, что владелец прямо сейчас настраивает домен и активно принимает решения по хостингу, дизайну и маркетингу. Список возрастом 30 или 60 дней это окно уже упустил — многие домены из него либо уже собраны, либо уже заброшены, либо уже помечены.

Массовые списки, которые дёшево продают на общих маркетплейсах, обычно собирают один раз и перепродают многократно: даты регистрации в них размазаны по месяцам, а с получателями уже кто-то связывался. Небольшой список, сформированный из актуального диффа зоны и отфильтрованный до тех TLD и платформ, которые вам реально нужны, — актив другого качества, даже если строка в нём стоит дороже.

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

1. Проверяйте MX-записи прямо перед использованием. Данные MX устаревают быстрее почти всего остального в доменной записи. Перепроверяйте их перед кампанией, а не доверяйте снимку, сделанному раньше. Сложность: средняя.
2. Фильтруйте новые регистрации более чем по одному сигналу. Комбинируйте детект паркинговых серверов имён, шаблоны регистраторов и базовую HTTP-проверку. Любой из них по отдельности даёт либо слишком много шума, либо слишком много ложных отсечений. Сложность: высокая.
3. Для рассылок ставьте свежесть выше объёма. Актуальный узкий список, формируемый еженедельно или ежедневно, работает лучше большого устаревшего дампа. Сложность: от низкой до средней.
4. Не рассчитывайте на единый формат файла. Файлы зон различаются у разных реестров типами записей, оформлением комментариев и кодировкой. Пишите парсер так, чтобы на неожиданных данных он падал явно, а не тихо терял записи. Сложность: средняя.
5. Покупайте агрегированные данные там, где прямой доступ закрыт. Если реестр ничего не публикует, договариваться о доступе почти никогда не окупается по времени. Каталог WebTrackly покрывает 716 зон TLD в виде готовых CSV для скачивания. Сложность: низкая.

Часто задаваемые вопросы

Как часто обновляются файлы DNS-зон?

Частота обновления зависит от TLD. Крупные gTLD вроде .com и .net публикуются ежедневно, обычно ранним утром по UTC. Часть ccTLD публикуется раз в неделю, реже или не публикуется вовсе. Файлы WebTrackly формируются в момент покупки из источника, обновляемого ежедневно, поэтому скачанный файл отражает текущее состояние, а не хранимый экспорт.

Можно ли получить полный список всех доменов из файла зоны?

Файл зоны TLD содержит делегированные домены, зарегистрированные в этом TLD, так что для одного расширения — в принципе да. Сложность начинается при попытке сделать то же самое по всем TLD: доступ к gTLD идёт через CZDS от ICANN с отдельной заявкой на каждый реестр, а многие ccTLD публичного доступа не дают вообще. Каталог зон WebTrackly покрывает 716 зон, а датасет всех зарегистрированных доменов содержит 272 614 863 строки.

Чем файл DNS-зоны отличается от базы WHOIS?

Файл DNS-зоны перечисляет доменные имена и записи их делегирования, описывая маршрутизацию трафика. База WHOIS хранит регистрационные метаданные — регистратора, даты регистрации и истечения и, если они не скрыты, сведения о владельце. Это ответы на разные вопросы. Пакеты WebTrackly покрывают зоны и технологии; в них домены, а не персональные контактные данные.

Насколько данные о свежезарегистрированных доменах полезны для лидогенерации?

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