Wildcard DNS: как работает запись *.example.com и когда она нужна

Wildcard DNS — это подстановочная DNS-запись, которая позволяет отвечать на запросы к множеству имён внутри зоны без создания каждой записи вручную. Чаще всего её записывают как *.example.com: звёздочка означает «подставь любое подходящее имя». На первый взгляд всё просто: добавили одну A-запись — и client1.example.com, demo.example.com, anything.example.com ведут на один IP. Но в реальной эксплуатации wildcard subdomain быстро упирается в правила DNS, TLS-сертификаты, настройки веб-сервера, кэширование и безопасность.

Эта статья — обзор с практическим уклоном. Разберём, что именно делает wildcard DNS, чего он не делает, почему *.example.com не всегда ведёт себя как «любой поддомен на любой глубине», как он связан с ACME wildcard-сертификатами и какие проверки стоит выполнить перед включением в продакшене.

Что такое wildcard DNS

Wildcard DNS-запись — это запись, у которой крайняя левая метка имени равна звёздочке. В зоне example.com типичный вариант выглядит так:

*.example.com. 300 IN A 203.0.113.10

Такая запись говорит авторитетному DNS-серверу: если запрошенное имя подходит под условия wildcard и для него нет более конкретной записи, можно синтезировать ответ на основе *.example.com. Слово «синтезировать» здесь важно: в зоне физически не появляется запись demo.example.com, сервер просто отвечает так, будто она есть.

Wildcard может быть не только A-записью. На практике встречаются A, AAAA, CNAME, TXT, MX и другие типы. Например, можно направить все поддомены на IPv4 и IPv6-адреса приложения:

*.example.com. 300 IN A 203.0.113.10
*.example.com. 300 IN AAAA 2001:db8::10

Или сделать wildcard CNAME на имя балансировщика, если архитектура завязана на внешний endpoint:

*.example.com. 300 IN CNAME edge.example.net.

Важное ограничение: CNAME нельзя смешивать с другими типами записей на том же имени. Если *.example.com — CNAME, то рядом с ним не должно быть A, AAAA, TXT или MX для этого же wildcard-имени. Это не прихоть панели управления, а базовое правило DNS.

Как DNS выбирает wildcard-ответ

Главная ловушка wildcard DNS — ожидание, что звёздочка работает как регулярное выражение «что угодно и где угодно». DNS устроен иначе. Wildcard участвует в ответе только тогда, когда для запрошенного имени нет более конкретного существующего имени в зоне.

Самый простой случай:

*.example.com. 300 IN A 203.0.113.10

Если пользователь запрашивает shop.example.com, а в зоне нет явной записи shop.example.com, DNS-сервер может вернуть 203.0.113.10. Если же явная запись существует, она побеждает wildcard:

shop.example.com. 300 IN A 203.0.113.20

Теперь shop.example.com будет указывать на 203.0.113.20, а не на wildcard-адрес. Это удобно: можно держать общую запись для большинства поддоменов и исключения для отдельных проектов.

Сложнее с несколькими уровнями. Многие считают, что *.example.com соответствует только одному уровню, например a.example.com, но не a.b.example.com. Для DNS это не совсем так: если промежуточное имя b.example.com вообще не существует в зоне, wildcard на уровне *.example.com может быть источником синтезированного ответа и для a.b.example.com. Но как только b.example.com появляется как существующее имя — с A-записью, NS-делегацией, TXT-записью или даже как пустой промежуточный узел из-за записей ниже, — wildcard *.example.com перестаёт закрывать имена под этой веткой. Для a.b.example.com тогда нужна отдельная запись *.b.example.com.

Практическое правило: wildcard не заменяет проектирование DNS-дерева. Если у вас есть отдельные ветки вроде dev.example.com, stage.example.com, clients.example.com, планируйте wildcard для каждой ветки отдельно.

Что wildcard DNS не делает

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

Типичная ошибка: администратор добавляет *.example.com в DNS, проверяет dig, видит правильный IP, но сайт всё равно открывает страницу по умолчанию или отдаёт TLS-ошибку. Это нормально: DNS доставил клиента до сервера, а дальше запрос обрабатывают SNI, TLS-сертификат, Nginx или Apache, маршрутизация приложения и правила авторизации.

Для веба обычно нужны три слоя:

• DNS-запись *.example.com, которая ведёт wildcard subdomain на нужный адрес или CNAME.

• TLS-сертификат, покрывающий нужные имена, например *.example.com и отдельно example.com, если нужен корневой домен.

• Веб-сервер или приложение, которые принимают произвольный Host и безопасно выбирают нужного арендатора, сайт или окружение.

Если пропустить третий пункт, wildcard может открыть неприятный класс ошибок: любые случайные поддомены начнут вести на ваш сервер, а приложение будет показывать не ту витрину, не тот tenant или отладочную страницу.

Где wildcard subdomain действительно полезен

Wildcard DNS особенно хорош там, где имена создаются динамически или их слишком много для ручного сопровождения. Самый понятный пример — SaaS-платформа: каждому клиенту выдаётся адрес вида company.example.com. Добавлять A-запись на каждого клиента можно, но это лишняя операция, потенциальная задержка из-за TTL и ещё одна точка отказа в автоматизации. Wildcard позволяет принимать новые имена сразу, а решение «кто такой company» переносится в базу приложения.

Вторая популярная история — preview-окружения. CI/CD может поднимать стенды для pull request или feature-ветки с адресами pr-184.preview.example.com и feature-login.preview.example.com. Для этого удобно создать *.preview.example.com и направить его на ingress, reverse proxy или балансировщик. Если такой контур живёт на отдельной машине, удобно вынести его на VDS, чтобы не смешивать тестовые окружения с основным сайтом.

Третий сценарий — multisite CMS и платформы конструкторов сайтов. Например, сеть сайтов может использовать поддомены для отдельных проектов, языков, регионов или пользователей. Wildcard DNS упрощает входящий трафик, но логику сопоставления поддомена с сайтом всё равно надо держать в приложении и базе данных.

Четвёртый сценарий — ловушка для опечаток и временные редиректы. Иногда wildcard направляют на страницу с пояснением или на канонический домен. Это может помочь пользователю, который набрал wwww.example.com вместо www.example.com. Но такой подход нужно применять аккуратно: поисковые системы, аналитика и безопасность не любят бесконечное множество «валидных» имён без понятной структуры.

Где wildcard лучше не использовать

Wildcard DNS не стоит включать «на всякий случай». Чем больше имён начинает резолвиться, тем шире поверхность ошибок. Если у вас обычный корпоративный сайт с двумя поддоменами www и mail, wildcard чаще создаст больше вопросов, чем пользы.

Особенно осторожно стоит относиться к wildcard в почтовой инфраструктуре. Wildcard MX может привести к неожиданному приёму почты на любые поддомены, увеличению спама и сложной диагностике доставляемости. Для почты лучше явно описывать домены, которые действительно принимают сообщения, а SPF, DKIM и DMARC держать предсказуемыми.

Ещё один риск — маскировка ошибок. Без wildcard опечатка в DNS быстро проявляется как NXDOMAIN: имя не существует. С wildcard многие ошибки становятся «успешными» на уровне DNS, но ломаются выше: не тот виртуальный хост, не тот сертификат, неправильный tenant. В мониторинге это может выглядеть как HTTP 404, 421, 500 или TLS alert вместо понятной DNS-ошибки.

Wildcard DNS и SSL: почему сертификат сам не появится

Для HTTPS одного wildcard DNS недостаточно. Браузер проверяет сертификат по имени, которое указал пользователь. Если открыт demo.example.com, сертификат должен покрывать demo.example.com. Wildcard-сертификат *.example.com обычно покрывает один уровень поддоменов: demo.example.com, shop.example.com, api.example.com. Но он не покрывает сам example.com и не покрывает глубокие имена вроде a.b.example.com. Для корневого домена его добавляют отдельным SAN-именем, а для глубоких уровней нужен другой wildcard, например *.b.example.com.

Отдельная тема — ACME wildcard. В ACME-клиентах wildcard-сертификаты обычно выпускаются через DNS-01 challenge. Это значит, что центр сертификации попросит создать TXT-запись вида:

_acme-challenge.example.com. 300 IN TXT token-value

Для выпуска сертификата на *.example.com TXT-запись размещается не как _acme-challenge.*.example.com, а как _acme-challenge.example.com. Если в сертификате одновременно есть example.com и *.example.com, ACME-клиент может создать одну или несколько TXT-записей на одном имени _acme-challenge.example.com. Это нормальная ситуация: DNS должен поддерживать несколько TXT-значений для одного owner name.

Также проверьте CAA, если используете его в зоне. Для wildcard-сертификатов существует отдельный параметр issuewild. Если CAA запрещает wildcard-выпуск или разрешает только другой центр сертификации, автоматизация будет падать не на веб-сервере, а на этапе проверки домена. Если хотите отдельно разобрать автоматизацию выпуска и продления, полезно посмотреть материал про wildcard SSL через DNS-01.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Как добавить wildcard DNS в панели или зоне

В большинстве DNS-панелей запись создаётся одинаково: в поле имени указывают * или *.example.com, выбирают тип A, AAAA или CNAME и задают значение. Если панель просит «имя» относительно зоны, обычно достаточно *. Если просит FQDN, используйте *.example.com. Точка в конце зависит от интерфейса: в zone-файлах она важна, а панели часто добавляют её сами.

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

Пример для zone-файла BIND-подобного формата:

*.example.com. 300 IN A 203.0.113.10

Для отдельной ветки preview:

*.preview.example.com. 300 IN CNAME ingress.example.com.

Для IPv6:

*.example.com. 300 IN AAAA 2001:db8::10

TTL лучше выбирать осознанно. Для динамичных preview-окружений удобно 60–300 секунд. Для стабильной SaaS-платформы можно 300–1800 секунд. Очень маленький TTL не гарантирует мгновенного переключения у всех клиентов, но увеличивает нагрузку на авторитетные DNS-серверы и резолверы. Очень большой TTL усложнит аварийный переезд.

Как проверить wildcard DNS

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

Если dig не установлен

На большинстве серверов dig уже есть. Если команды нет, установите пакет с DNS-утилитами для своего семейства ОС.

Debian и Ubuntu:

sudo apt update
sudo apt install dnsutils

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux и Fedora:

sudo dnf install bind-utils

FreeBSD:

sudo pkg install bind-tools

Набор базовых проверок

Проверка A-записи:

dig +short random-test-123.example.com A

Проверка IPv6:

dig +short random-test-123.example.com AAAA

Проверка, какой сервер отвечает авторитетно:

dig random-test-123.example.com A +norecurse

Проверка через конкретный авторитетный NS:

dig @ns1.example.com random-test-123.example.com A

Если есть явное исключение, сравните ответы:

dig +short shop.example.com A
dig +short typo-shop.example.com A

Для диагностики HTTPS полезно отдельно проверить DNS, TLS и HTTP Host. DNS может быть правильным, но сертификат — нет. Или сертификат покрывает имя, но reverse proxy отправляет запрос в дефолтный backend.

curl -I https://random-test-123.example.com

Если wildcard DNS только что добавлен, учитывайте отрицательное кэширование. До появления записи некоторые резолверы могли получить NXDOMAIN и держать его в кэше согласно SOA-параметрам зоны. Из-за этого один резолвер уже видит новый wildcard, а другой ещё отвечает, что имени нет.

Настройки веб-сервера: default vhost и Host allowlist

DNS-запись приведёт трафик на сервер, но не решит, какой сайт показывать. Поэтому для wildcard-доменов особенно важен безопасный default vhost: он должен обрабатывать неизвестные имена нейтрально, не раскрывать внутренние адреса и не отправлять пользователя в случайный tenant.

Минимальный пример для Nginx: неизвестные Host получают код 421. Рабочие имена при этом обрабатываются отдельными server-блоками или приложением за reverse proxy.

server {
    listen 80 default_server;
    server_name _;
    return 421;
}

Для Apache идею можно реализовать первым виртуальным хостом, который не содержит рабочий сайт и отдаёт безопасный ответ или статическую страницу ошибки:

<VirtualHost *:80>
    ServerName invalid-host.local
    DocumentRoot /var/www/empty
    Redirect 404 /
</VirtualHost>

На уровне приложения желательно иметь allowlist доменов: например, таблицу разрешённых tenant-имён или регулярное правило только для ожидаемой ветки *.clients.example.com. Неизвестный Host не должен автоматически считаться валидным клиентским доменом.

Безопасность: что проверить перед включением

Wildcard DNS меняет модель доверия к поддоменам. Раньше существовали только имена, которые вы явно создали. После включения wildcard любой случайный или специально подобранный поддомен начинает вести в вашу инфраструктуру. Это не обязательно плохо, но требует дисциплины.

Первое — настройте default vhost. Он не должен показывать админку, debug-страницу, список файлов, внутренние hostname или чужой tenant. Хорошая практика — отдавать нейтральную страницу 404 или 421 для неизвестных Host, а приложение должно принимать только имена, которые есть в базе разрешённых доменов.

Второе — следите за cookie scope. Если приложение ставит cookie на .example.com, она будет отправляться на все поддомены. Это удобно для SSO, но опасно для мультиарендности: один скомпрометированный поддомен может повлиять на соседние сценарии. Для SaaS часто безопаснее изолировать клиентские зоны, не смешивать пользовательский контент и административные интерфейсы под одним cookie-доменом.

Третье — не забывайте про subdomain takeover, даже если wildcard «закрывает» несуществующие имена. Риск обычно связан не с самой wildcard-записью, а с забытыми CNAME, делегациями NS, внешними платформами и объектами, которые удалили на стороне провайдера, но оставили в DNS. Wildcard может замаскировать часть симптомов, поэтому периодический аудит явных записей всё равно нужен.

Четвёртое — ограничьте доверие к Host-заголовку. Приложение не должно строить ссылки сброса пароля, OAuth redirect URI, CORS-правила или абсолютные URL только из входящего Host без проверки. Wildcard повышает вероятность того, что неожиданный Host окажется технически «валидным».

Нюансы с DNSSEC, делегированием и пустыми именами

Если зона подписана DNSSEC, wildcard продолжает работать, но ответы сопровождаются доказательствами существования или несуществования имён. Для администратора это означает две вещи: во-первых, ошибки в wildcard-зоне могут проявляться как SERVFAIL у валидирующих резолверов; во-вторых, при диагностике нужно смотреть не только A или CNAME, но и DNSSEC-цепочку, DS-записи и корректность подписи.

Делегирование подзоны меняет поведение wildcard. Если вы делегировали dev.example.com на другие NS, запись *.example.com в родительской зоне не управляет именами внутри dev.example.com. Там нужно настраивать wildcard уже в зоне dev.example.com, например *.dev.example.com. Подробнее о таком разделении зон — в инструкции по делегированию поддомена на отдельные NS.

Иногда wildcard неожиданно не отвечает из-за существования промежуточного имени. Например, у вас есть запись preview.example.com, и вы ожидаете, что *.example.com покроет abc.preview.example.com. Но наличие preview.example.com меняет поиск wildcard-источника. В такой архитектуре правильнее явно создать *.preview.example.com.

Практический чек-лист

• Определите область действия: нужен ли wildcard на всём example.com или только на ветке вроде *.preview.example.com.

• Выберите тип записи: A/AAAA для прямого указания адресов, CNAME для привязки к балансировщику или внешнему имени.

• Проверьте явные исключения: www, mail, api, admin, технические поддомены и делегированные зоны.

• Настройте TLS: wildcard-сертификат для *.example.com, отдельное имя для example.com, дополнительные wildcard для глубоких веток.

• Проверьте ACME DNS-01: доступ к API DNS, несколько TXT на _acme-challenge.example.com, CAA и автоматическое продление.

• Настройте default vhost и allowlist Host в приложении, чтобы неизвестные поддомены не попадали в рабочие tenant-ы.

• Подберите TTL под сценарий: ниже для миграций и preview, выше для стабильной продакшен-зоны.

• Проверьте ответы через авторитетные NS и несколько резолверов, учитывая отрицательный кэш.

Итоги

Wildcard DNS — мощный инструмент, но не универсальная кнопка «включить все поддомены». Запись *.example.com помогает строить SaaS, preview-окружения, multisite-платформы и гибкую маршрутизацию, однако требует аккуратной настройки DNS-веток, TLS, веб-сервера и приложения.

Если сформулировать коротко: wildcard отвечает только за разрешение имён и только по правилам DNS. Явные записи имеют приоритет, делегированные подзоны живут отдельно, сертификаты выпускаются отдельно, а безопасность начинается с проверки Host и правильного default vhost. Перед внедрением полезно протестировать несколько сценариев через dig и curl, а не ограничиваться одним красивым ответом на test.example.com.