Мониторинг сайтов · 6 мин · обновлено 2026-10-01

Wildcard DNS не работает для поддомена: что перекрывает звёздочку

Пошаговая диагностика wildcard DNS: как найти точное имя, границу зоны или тип записи, из-за которого звёздочка не используется.

Wildcard-запись срабатывает не как регулярное выражение, а только в определённой точке дерева DNS. Если для запрошенного имени уже существует более точный узел, промежуточное имя или делегированная дочерняя зона, авторитетный сервер не возвращается к более общей записи *.example.com.

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

Как wildcard DNS выбирается для запроса

Допустим, в зоне есть запись:

*.example.com.  A  192.0.2.10

Когда сервер получает запрос к несуществующему имени, он ищет ближайшего существующего предка — в стандарте это называется *closest encloser*. Затем он проверяет wildcard непосредственно под этим узлом. Если нужной звёздочки там нет, поиск не продолжается по другим wildcard-записям.

Из этого следует важный нюанс: *.example.com не обязательно ограничен одним уровнем имени. Он может дать ответ и для a.b.example.com, пока b.example.com не существует. Но как только b.example.com становится существующим узлом, для имён внутри этой ветки уже нужен *.b.example.com.

Звёздочка также не покрывает само имя зоны. Запись *.example.com не создаёт ответ для example.com — для него нужна отдельная запись.

Какие имена перекрывают звёздочку

1. Точная запись с тем же именем

Точное совпадение всегда имеет приоритет. Если существует shop.example.com, запрос к нему не будет синтезирован из *.example.com.

Это верно даже тогда, когда у точного имени нет запрошенного типа. Например, у shop.example.com есть только TXT, а клиент спрашивает A. Сервер может вернуть успешный ответ без A-записи, но не подставит A из wildcard. Сначала проверяется существование имени, а уже затем тип записи.

2. Существующий промежуточный узел

Имя может существовать неявно. Если в зоне есть api.dev.example.com, то dev.example.com уже является узлом дерева DNS, даже если у него нет собственной A- или CNAME-записи.

Тогда для www.dev.example.com ближайшим существующим предком станет dev.example.com. Общая запись *.example.com не поможет: потребуется *.dev.example.com либо точная запись www.dev.example.com.

3. Делегирование поддомена

Запись NS для sub.example.com создаёт границу зоны. Запросы ниже неё обслуживают авторитетные серверы дочерней зоны, поэтому wildcard родительской зоны через эту границу не действует.

Если anything.sub.example.com должен открываться по wildcard, запись нужно создавать у оператора зоны sub.example.com. Удалять делегирование ради срабатывания общей звёздочки нельзя, если оно используется осознанно.

4. Точный CNAME или другой тип ответа

Точный CNAME направит запрос по своей цепочке и также получит приоритет над общей звёздочкой. Если wildcard содержит только A, запрос AAAA не превратится в A-ответ: типы записей нужно проверять отдельно.

Это частая причина ситуации «в браузере работает, а проверка не проходит»: один клиент использует IPv4, другой сначала запрашивает IPv6, а конфигурация для A и AAAA различается.

Порядок диагностики

Шаг 1. Зафиксируйте полное имя и тип

Запишите проблемный QNAME целиком, например www.dev.example.com, и тип запроса: A, AAAA, CNAME, MX или другой. Формулировки «не работает поддомен» недостаточно: разные типы для одного имени могут давать разные результаты.

Посмотрите сам ответ, а не только сообщение браузера. NXDOMAIN означает, что имя не найдено; NOERROR с пустой секцией ответа обычно указывает, что имя существует, но запрошенного типа нет. Referral с NS показывает переход в дочернюю зону, а SERVFAIL требует отдельной проверки доступности серверов и DNSSEC.

Шаг 2. Найдите авторитетные NS

Сначала получите NS зоны, затем опросите каждый сервер напрямую без рекурсивного резолвера:

dig NS example.com
dig @ns1.example.net www.dev.example.com A +norecurse
dig @ns2.example.net www.dev.example.com A +norecurse

Подставьте реальные имена серверов из первого ответа. Если ответы NS различаются, сначала устраните рассинхронизацию зоны. Полезный порядок такой проверки описан в материале как сравнить ответы авторитетных DNS-серверов.

Шаг 3. Проверьте точное имя и каждого предка

Ищите записи для самого QNAME, затем для dev.example.com и example.com. В панели DNS проверьте не только A и CNAME, но также TXT, MX, NS и служебные записи: любой существующий узел влияет на выбор wildcard.

Особенно внимательно проверьте имена, которые появились как родители более глубоких записей. Пустой промежуточный узел может не отображаться отдельной строкой в панели, хотя для алгоритма DNS он существует.

Шаг 4. Найдите границу зоны

Запросите NS у подозрительного поддомена и выполните трассировку:

dig NS sub.example.com
dig +trace www.sub.example.com A

Если цепочка передаёт управление другим авторитетным серверам, проверяйте wildcard уже в дочерней зоне. Изменения в родительской зоне не исправят её содержимое.

Шаг 5. Проверьте нужный wildcard и тип записи

Для ветки dev.example.com проверьте именно *.dev.example.com, а не только *.example.com. Сверьте тип, значение и отсутствие конфликтующей точной записи. Если используется CNAME, отдельно проверьте конечное имя и его A/AAAA-ответы.

Шаг 6. Только после исправления учитывайте кэш

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

Как исправить конфигурацию без побочных эффектов

Если точное имя должно отличаться от остальных, исправьте его собственную запись и оставьте wildcard как есть.
Если целая ветка должна наследовать общий адрес, добавьте wildcard на нужном уровне, например *.dev.example.com, и отдельно настройте само dev.example.com.
Если поддомен делегирован, вносите изменения в дочерней зоне у её авторитетного DNS-провайдера.
Не удаляйте NS, MX, TXT для подтверждения домена или другие рабочие записи только ради wildcard. Сначала определите назначение каждой записи.
После изменения проверьте не один случай, а точное имя, новое несуществующее имя в той же ветке и имя за пределами ветки.

Одна успешная проверка с компьютера не доказывает, что все авторитетные серверы уже согласованы. Web-Puls помогает регулярно наблюдать доступность публичного URL и заметить внешний эффект DNS-ошибки, но не заменяет разбор структуры зоны.

Если авторитетные NS отвечают одинаково, а нужное имя всё равно не открывается, отправьте заявку на профессиональную диагностику. Укажите домен, точный QNAME и QTYPE, время с часовым поясом, ответы авторитетных серверов и недавние изменения; не передавайте пароли регистратора, API-токены и закрытый экспорт зоны.