Что такое wildcard DNS?
Wildcard DNS использует запись с меткой *, чтобы отвечать за множество несуществующих имён одного уровня. Например, *.example.com может направлять разные поддомены на общий адрес, но не заменяет явные записи и не совпадает с apex домена.
Как работает wildcard DNS
Авторитетный сервер применяет wildcard только тогда, когда точное имя не существует в соответствующей ветви зоны. Явная запись имеет приоритет, а наличие промежуточной метки может остановить подстановку.
DNS Zone for example.com:
├── example.com A 192.0.2.1 (explicit)
├── www.example.com A 192.0.2.1 (explicit)
├── mail.example.com A 192.0.2.2 (explicit)
└── *.example.com A 192.0.2.10 (wildcard)
Query: random.example.com → 192.0.2.10 (matched by wildcard)
Query: www.example.com → 192.0.2.1 (explicit takes priority)
Синтаксис wildcard-записи
Звёздочка занимает целую крайнюю левую метку. Запись можно создавать для поддерживаемых типов, но её смысл определяется правилами DNS, а не шаблонами файловой системы или регулярными выражениями.
*.example.com. 3600 IN A 192.0.2.10
*.example.com. 3600 IN CNAME catch-all.example.com.
*.example.com. 3600 IN MX 10 mail.example.com.
Распространённые сценарии
Wildcard упрощает обслуживание динамических поддоменов, если приложение умеет безопасно проверять hostname. Он не должен автоматически предоставлять доступ или создавать ресурс для любого имени.
Мультитенантные SaaS-приложения
Один адрес может принимать customer1.example.com и другие tenant-имена. Приложение обязано сопоставлять Host с существующим клиентом и отклонять неизвестные значения, иначе возможны утечки и подмена контента.
*.myapp.com → Single server handles:
├── customer1.myapp.com
├── customer2.myapp.com
├── customername.myapp.com
└── (unlimited subdomains)
Среды разработки
Wildcard удобен для временных preview-адресов и тестовых окружений. Такие имена должны иметь ограниченный доступ, отдельные cookie и своевременно удаляться вместе с приложением и сертификатами.
Пользовательский контент
Платформа может выдавать каждому пользователю поддомен. Перед публикацией проверяйте допустимость имени, право на ресурс, модерацию, TLS, cookie, CORS и запрет зарезервированных меток.
Правила приоритета wildcard
Точная DNS-запись всегда предпочтительнее wildcard. Пустая ветвь, существующий узел другого типа и делегированный поддомен могут менять результат, поэтому проверяйте authoritative answer для каждого важного имени.
| Запись | Запрос test.example.com |
|---|---|
| test.example.com (явная) | ✓ Имеет приоритет |
| *.example.com (wildcard) | Используется при отсутствии явной записи |
Ограничения
Wildcard не покрывает сам apex, не является рекурсивным шаблоном для всех уровней и не доказывает существование приложения. Он может скрывать опечатки, усложнять инвентаризацию и создавать неожиданные ответы для случайных имён.
Пример настройки DNS
В файле зоны wildcard размещают рядом с явными записями и документируют его назначение. После изменения увеличивают SOA serial и проверяют ответы по UDP и TCP.
; Zone file
$ORIGIN example.com.
@ A 192.0.2.1 ; apex
www A 192.0.2.1 ; explicit www
* A 192.0.2.10 ; everything else
* MX 10 mail.example.com. ; wildcard mail
Рекомендации
Используйте wildcard только при реальной необходимости, сохраняйте список допустимых hostname в приложении и создавайте явные записи для критичных сервисов. Проверяйте TLS SAN, SNI, Host, cookie, CORS, DNSSEC и удаление внешних целей; неизвестный ответ не трактуйте как существующий tenant.