Wildcard DNS-запись (*.example.com) позволяет направить любой поддомен на один и тот же IP-адрес или hostname. Это необходимо для WordPress Multisite, SaaS-приложений, где каждый пользователь получает свой поддомен.

Типичный сценарий — платформа вроде интернет-магазинов на своём движке, где у каждого клиента адрес вида клиент.platform.com. Без wildcard пришлось бы создавать отдельную A-запись на каждого нового клиента вручную; с wildcard достаточно один раз настроить DNS и дальше маршрутизацию по имени поддомена делает уже приложение на сервере, а не DNS-зона.

Создание wildcard записи

В cPanel → Zone Editor

Добавьте A-запись:

Имя (Name): *
Тип: A
Значение: 192.168.1.100 (ваш IP)

В Cloudflare

Type: A
Name: *
Content: 192.168.1.100
Proxy status: DNS only (серая иконка) или Proxied

✅ Wildcard запись работает только для одного уровня: *.example.com не покрывает sub.sub.example.com.

Не все DNS-панели одинаково принимают символ * в поле имени. Базовые бесплатные панели некоторых регистраторов ограничивают набор допустимых записей и просто не показывают wildcard как опцию — в этом случае зону переносят на DNS-провайдера с полной поддержкой, например на панель хостинга или на Cloudflare, вместо того чтобы искать обходной путь.

Wildcard SSL-сертификат

Для HTTPS на всех поддоменах нужен wildcard SSL:

# Certbot wildcard через DNS-01 challenge
certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d "*.example.com" \
  -d "example.com"

# Автоматически через acme.sh + Cloudflare API
acme.sh --issue \
  --dns dns_cf \
  -d "*.example.com" \
  -d "example.com"

⚠️ Let's Encrypt wildcard сертификаты требуют DNS-01 challenge — нужен API доступ к DNS-провайдеру для автопродления.

Сертификаты Let's Encrypt живут всего 90 дней, поэтому ручной запуск --manual из примера выше подходит только для разовой проверки. В продакшене DNS-01 challenge настраивают через плагин конкретного DNS-провайдера (dns_cf для Cloudflare, аналогичные — для других), чтобы acme.sh или certbot могли сами добавлять и удалять TXT-запись для подтверждения при каждом автопродлении без участия человека.

Применение в WordPress Multisite

# В /etc/apache2/sites-available/multisite.conf
ServerName example.com
ServerAlias *.example.com

# Или в Nginx
server {
    server_name ~^(.+)\.example\.com$;
    set $subdomain $1;
}

Проверка wildcard записи

# Должны резолвиться одинаково:
dig anything.example.com A
dig test123.example.com A
dig myapp.example.com A

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

Частые ошибки wildcard-записей

Поведение	Причина	Решение
Разные поддомены резолвятся по-разному, хотя wildcard создан	Существует отдельная явная запись для конкретного поддомена, например blog.example.com A ...	Проверить полный список записей зоны на конфликт с wildcard — явная запись всегда приоритетнее
sub.sub.example.com не резолвится	Wildcard покрывает только один уровень вложенности согласно RFC 1034	Создать отдельный wildcard *.sub.example.com или явную запись для этого имени
Let's Encrypt: Invalid response ... urn:ietf:params:acme:error:dns	Использован HTTP-01 challenge вместо обязательного для wildcard DNS-01	Переключиться на DNS-01, как в примере certbot/acme.sh выше
MX-запись не работает через wildcard	Стандарт не рекомендует полагаться на wildcard для MX, многие почтовые системы игнорируют такие ответы	Создать явную MX-запись для конкретного поддомена почты

Wildcard и явные записи: приоритет

Ситуация	Какая запись выигрывает	Причина
Есть wildcard *.example.com A и точная запись blog.example.com A	точная запись	DNS всегда предпочитает более специфичное совпадение имени
Есть wildcard *.example.com и CNAME на sub.example.com	CNAME	тот же принцип специфичности имени
Есть wildcard верхнего уровня, но не для *.sub.example.com	ни один — NXDOMAIN, если нет явной записи	wildcard не наследуется на более глубокий уровень вложенности

Когда wildcard не подходит

Нужен явный список разрешённых поддоменов для приложения с проверкой прав доступа — wildcard в DNS не заменяет проверку авторизации на уровне приложения
Часть поддоменов должна указывать на разные IP или сервисы — тогда нужны отдельные A/CNAME-записи, wildcard перекроет их только как fallback для неучтённых имён
Нужна привязка поддомена к почте (MX) — используйте отдельную MX-запись, не полагайтесь на wildcard, см. настройку MX для почты
SSL нужен только для 2–3 конкретных поддоменов — обычный SAN-сертификат на нужные имена проще в выпуске, чем wildcard с обязательным DNS-01, см. ACME DNS challenge для SSL