DNS strategy for multisite: subdomain vs subfolder and wildcard A/AAAA

Мультисайт (multisite) почти всегда упирается не в CMS, а в доменную стратегию: как пользователи попадают «в нужное место» через DNS, и как дальше трафик маршрутизируется на уровне фронтенда и приложения. Два базовых варианта — поддомены (subdomain) и подпапки (subfolder). А когда поддоменов много или они создаются динамически, всплывает третья тема: wildcard DNS и записи A/AAAA или CNAME.

Ниже — практичный разбор без воды: как это работает на уровне DNS, что проще админить, где подводные камни в SSL/IPv6 и почему «поставил wildcard и всё» иногда превращается в ночной инцидент.

Subdomain vs subfolder: что меняется на практике

С точки зрения пользователя разница выглядит просто:

• multisite subdomain: site1.example.com, site2.example.com;
• multisite subfolder: example.com/site1, example.com/site2.

Но для админа это две разные модели управления трафиком, сертификатами, кэшем, cookie и правилами маршрутизации.

Поддомены (subdomain): плюсы и минусы

Плюсы:

• Логическое разделение: проще разводить разные upstream/контейнеры/версии приложения и политики (лимиты, WAF, rate-limit).
• Проще делегировать ответственность: по поддоменам можно разделять команды, окружения, а иногда и DNS (NS-делегирование).
• Естественная модель для мультиарендности: «тенант = hostname» читаемо и прозрачно.

Минусы:

• Нужна дисциплина в DNS и SSL: либо wildcard-сертификат, либо автоматизация выпуска множества сертификатов.
• Сессии/куки: если надо шарить авторизацию между поддоменами, придётся аккуратно работать с доменными cookie и помнить про риски.
• Wildcard DNS увеличивает «радиус поражения»: неожиданные имена начнут резолвиться и стучаться к вам.

Подпапки (subfolder): плюсы и минусы

Плюсы:

• Один хостнейм, проще SSL: обычно достаточно одного сертификата на домен.
• DNS почти не усложняется — нет «зоопарка» записей и wildcard.
• Единый входной фронтенд (кэш, балансировка, правила безопасности) часто проще сопровождать.

Минусы:

• Маршрутизация становится задачей L7: нужны чёткие правила по путям, переписываниям и исключениям (статика, API, админка).
• Сложнее «разъехаться» на разные приложения: конфликт путей, редиректов и базовых URL.
• Некоторые продукты и интеграции ожидают отдельный hostname под «сайт», а не path.

Практическое правило: если нужен мультиарендный мультисайт (клиенты, изоляция, разные стеки, отдельные политики) — чаще выигрывают поддомены. Если это один продукт с витринами/разделами и общими правилами — подпапки обычно дешевле в сопровождении.

Wildcard DNS: что это и когда он реально нужен

Wildcard DNS — запись, которая матчится на «любой поддомен», например *.example.com. Её используют, когда:

• поддомены создаются динамически (например, tenant123.example.com появляется по событию в приложении);
• поддоменов слишком много, и руками заводить каждый невозможно;
• нужно быстро направить «все имена» на один входной прокси, а дальше разрулить на уровне L7.

Важно: wildcard — это про DNS-резолвинг, а не про «автоматическую раздачу сайта». DNS лишь возвращает IP (или имя через CNAME), а дальше всё решают веб-сервер, сертификат и логика приложения.

Wildcard A/AAAA vs wildcard CNAME

Есть два распространённых подхода:

• wildcard A/AAAA: *.example.com указывает на IPv4/IPv6 адреса;
• wildcard CNAME: *.example.com указывает на другое имя (например, на gateway.example.net), а уже оно резолвится в A/AAAA.

С точки зрения эксплуатации разница обычно такая:

• A/AAAA проще и предсказуемее, когда вы точно знаете IP фронта и управляете им сами.
• CNAME удобнее, когда точка входа может меняться (переезд, смена балансировщика), и вы хотите обновлять адреса в одном месте, не трогая всю зону.

Ограничение CNAME, о которое чаще всего спотыкаются: нельзя одновременно иметь CNAME и другие записи на том же имени. Для wildcard это обычно не проблема, а вот для корня домена (apex, example.com) — типовая ловушка.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

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

AAAA record и dual-stack: почему IPv6 ломает «всё работало вчера»

AAAA — это запись DNS для IPv6. Если вы публикуете и A, и AAAA, клиент выберет один из протоколов по своей логике (часто по Happy Eyeballs). И вот где начинаются реальные инциденты:

• На IPv4 всё проксируется/балансируется правильно, а на IPv6 другой firewall, другой listener или вообще нет маршрута.
• Вы добавили wildcard AAAA, но TLS на IPv6 не настроен (или цепочка сертификатов/виртуальные хосты обслуживаются иначе), и часть пользователей ловит ошибки сертификата.
• Вы используете прокси/CDN, который по IPv6 отдаёт другой edge/регион, а приложение привязано к IP-allowlist.

Практика: если включаете AAAA (особенно wildcard), убедитесь, что входной фронтенд одинаково обслуживает IPv4 и IPv6: порты, сертификаты, healthcheck, rate-limit, гео-правила, WAF, upstream.

Для HTTPS важно заранее решить, как вы закрываете TLS: один wildcard-сертификат, либо выпуск на каждый hostname (в том числе при динамических тенантах). Если нужен управляемый выпуск и понятная цепочка доверия, смотрите в сторону SSL-сертификаты и автоматизации их обновления.

Domain strategy для multisite: что выбрать под задачу

Чтобы не гадать, используйте «матрицу выбора» от операционных рисков, а не от вкуса или привычек.

Когда выбирать multisite subdomain

• Нужна изоляция тенантов (разные лимиты, кэш, правила, иногда разные версии приложения).
• Планируете часть сайтов переносить/делегировать без трогания остальных.
• Ожидаете подключение кастомных доменов клиентов (тогда поддомены становятся естественным дефолтом).
• Есть автоматизация SSL (wildcard-сертификат или выпуск/привязка по API).

Когда выбирать multisite subfolder

• Это один продукт/сайт, а «мультисайт» по сути — разделы (витрины, языки, каталоги).
• Важна простота DNS и минимизация сущностей (один хостнейм, один сертификат).
• Критично держать единый входной контур (кэш/балансировка/правила безопасности) без ветвления по hostname.

Типовые схемы DNS для поддоменов и wildcard

Ниже примеры в условном zonefile-формате как концепт, без привязки к конкретной панели. Учитывайте, что точный синтаксис зависит от DNS-хостинга.

Схема 1: фиксированный набор поддоменов (без wildcard)

; site1.example.com
site1  A     203.0.113.10
site1  AAAA  2001:db8::10

; site2.example.com
site2  A     203.0.113.10
site2  AAAA  2001:db8::10

Подходит, когда поддоменов мало и они статичны. Плюс — минимальный «радиус поражения» при ошибке.

Схема 2: wildcard A/AAAA для динамических тенантов

; any-tenant.example.com
*  A     203.0.113.10
*  AAAA  2001:db8::10

Классический вариант для multisite на поддоменах, когда приложение по заголовку Host решает, какой тенант обслуживать.

Схема 3: wildcard CNAME на единый gateway

; any-tenant.example.com
*  CNAME  gateway.example.net.

gateway.example.net.  A     203.0.113.20
gateway.example.net.  AAAA  2001:db8::20

Удобно, если вы хотите менять IP «точки входа» централизованно. Минус — появляется дополнительный уровень резолвинга, и диагностика иногда сложнее из-за кешей и разной видимости у резолверов.

Подводные камни wildcard: безопасность, «левой» трафик и автопровижининг

Wildcard-запись делает так, что любой поддомен резолвится. Это ожидаемо для тенантов, но неожиданно для всего остального.

«Липовые» поддомены и мусор в логах

С wildcard вы начнёте видеть запросы на случайные имена. Это нормальная реальность интернета: сканеры, опечатки, старые ссылки. Проблема начинается, если приложение пытается «создать тенанта на лету» или отдаёт одинаковый контент на все неизвестные хосты.

Что сделать заранее:

• На уровне приложения держите whitelist/таблицу разрешённых тенантов и возвращайте 404/410 для неизвестных.
• На фронтенде разделяйте default vhost и «тенантный» vhost, чтобы неизвестные имена не попадали в основной контур.
• Логируйте и агрегируйте Host: так проще быстро понять, что именно полилось и почему.

Wildcard и верификации/интеграции

Неприятный класс ошибок: внешняя система создаёт случайный поддомен для проверки владения, а ваш wildcard приводит её на веб-сервер, который отвечает «успешно», но не тем контентом. В итоге подтверждение домена/настройка интеграции ломаются неочевидно.

Решение то же: строгая обработка неизвестных Host и явные правила на фронтенде.

Диагностика: как быстро проверить, что DNS и IPv6 настроены правильно

Минимальный набор проверок до релиза (и после изменений) — резолвинг A/AAAA, проверка цепочки CNAME и поведение «неизвестного» поддомена.

Проверяем A/AAAA и CNAME

dig +short site1.example.com A
dig +short site1.example.com AAAA
dig +short random-tenant.example.com A
dig +short random-tenant.example.com AAAA
dig +short random-tenant.example.com CNAME

Если используете wildcard CNAME, убедитесь, что цепочка резолвинга не циклична и что конечные A/AAAA реально существуют.

Проверяем HTTP по IPv4 и IPv6 раздельно

curl -4 -I https://site1.example.com/
curl -6 -I https://site1.example.com/

Если по -6 ошибка, значит проблема обычно не в «DNS вообще», а в пути IPv6: маршрутизация, firewall, listener, TLS-настройки, прокси.

Рекомендации по внедрению без сюрпризов

• Начните с модели данных: что является «сайтом/тенантом» — hostname или path. DNS должен отражать это, а не наоборот.
• Если нужен wildcard — сразу закладывайте правила для неизвестных хостов и наблюдаемость (логи по Host, метрики по 4xx/5xx).
• Не публикуйте wildcard AAAA, пока не уверены, что IPv6 обслуживается симметрично IPv4.
• Если сомневаетесь между A/AAAA и CNAME: A/AAAA проще для «своего» фронта, CNAME удобнее для централизованного gateway.

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

Итог: короткий чек-лист выбора

• multisite subdomain выбирайте, когда важна изоляция и масштабирование по хостам; wildcard DNS почти неизбежен при динамических тенантах.
• multisite subfolder выбирайте, когда это единый продукт и вы хотите минимизировать сущности в DNS/SSL.
• wildcard DNS — мощно, но требует строгой обработки неизвестных хостов и аккуратности с IPv6.
• AAAA добавляйте только после проверки, что весь входной контур (LB, firewall, TLS) реально готов к dual-stack.
• CNAME удобен как «указатель на gateway», но помните про ограничения совместимости записей на одном имени.