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"

⚠️ Wildcard сертифікати Let's Encrypt вимагають 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