Поддомены и wildcard DNS: как создавать имена без неожиданных совпадений

Поддомен помогает дать отдельный адрес части проекта: docs.example.com для документации, api.example.com для API, status.example.com для страницы состояния. Его обычно не покупают — владелец создаёт DNS-запись внутри уже зарегистрированного домена.

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

Поддомен — имя внутри вашего домена

После регистрации example.com владелец управляет именами ниже него. Метка слева создаёт следующий уровень: docs.example.com. Можно добавить и более глубокое имя, например eu.api.example.com, но длинную структуру труднее поддерживать и объяснять пользователям.

Поддомен уместен, если часть проекта отличается по назначению или инфраструктуре. Документация может размещаться на статической платформе, а основной сайт — на CMS. DNS направит каждое имя на свою площадку.

Для обычного раздела одного сайта каталог часто проще: example.com/docs сохраняет общую авторизацию, аналитику и навигацию. Выбирайте поддомен не ради декоративной точки, а когда нужна реальная техническая или организационная граница.

Явная запись описывает конкретное имя

Создание поддомена начинается с записи A, AAAA или CNAME. Возможная схема:

Имя	Тип	Назначение
docs	CNAME	платформа документации
api	A и AAAA	сервер приложения
status	CNAME	внешний сервис статуса

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

Явные записи удобны для аудита: видно, какие сервисы существуют и куда ведут. Удалив сервис, можно удалить ровно его имя, не затрагивая остальные.

Wildcard отвечает за отсутствующие имена

Wildcard в DNS обозначается меткой *, например *.example.com. Он позволяет синтезировать ответ для подходящего имени, которое иначе не найдено в DNS-дереве. Так client1.example.com и client2.example.com могут получить одинаковый адрес без отдельной записи для каждого клиента.

У wildcard есть важные границы:

• он не создаёт запись для самого example.com;
• явная структура DNS может остановить поиск wildcard;
• запись *.example.com не следует считать автоматическим ответом для любой глубины;
• типы данных остаются обычными: wildcard A возвращает адрес, wildcard CNAME — каноническое имя;
• DNS не создаёт приложение, пользователя или сертификат для получившегося имени.

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

Существующее имя может изменить результат

Представьте wildcard *.example.com, который ведёт на основной сервер. Если в зоне появляется отдельное имя shop.example.com с собственными данными, запросы внутри этой ветви уже рассматриваются относительно существующего узла. Wildcard выше не обязан заполнять каждую отсутствующую запись под ним.

Это объясняет ситуацию, когда random.example.com работает, а api.shop.example.com неожиданно не находится. Не исправляйте её добавлением ещё более широкого wildcard вслепую. Нарисуйте фактическую иерархию и создайте запись на нужном уровне.

Отдельно учитывайте отрицательный кеш. Если имя недавно возвращало NXDOMAIN, исправленный ответ может появиться у конкретного резолвера позже. Механика описана в статье о TTL и DNS-кеше.

Когда wildcard действительно полезен

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

Wildcard может упростить DNS, но расширяет набор адресов, ведущих на сервер. Это влияет на журналы, кеши, cookie и поисковую индексацию. Сервер не должен отдавать одинаковую успешную страницу для бесконечного числа случайных поддоменов. Неизвестное имя лучше отклонить или вернуть понятный ответ об отсутствии ресурса.

Для небольшого сайта со списком из пяти служб явные записи понятнее и безопаснее в эксплуатации. Экономия нескольких строк не компенсирует неочевидное поведение.

Wildcard DNS и wildcard-сертификат — разные вещи

DNS-запись помогает найти IP или другое имя. TLS-сертификат подтверждает имя при HTTPS. Сертификат для *.example.com обычно покрывает один уровень поддоменов, например shop.example.com, но не сам example.com и не a.b.example.com. Точные имена нужно проверить в сертификате.

Центр сертификации проверяет право управлять доменом. Для wildcard-сертификатов автоматизация часто использует DNS-проверку, что требует защищённого доступа к API DNS-провайдера. Не выдавайте ключ с правом менять всю зону, если сервис поддерживает более узкое разрешение.

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

Проверьте каждую границу до публикации

Составьте список ожидаемых имён и отдельно — примеров, которые не должны работать. Проверьте корень домена, явные поддомены, случайное имя под wildcard и имя на уровень глубже. Для каждого сравните DNS-ответ, сертификат и HTTP-ответ сайта.

Если wildcard приводит случайные адреса на основной сайт, настройте обработку неизвестного Host и не включайте такие URL в карту сайта. Для публичных страниц выберите один адрес и используйте явные ссылки.

Типы записей разобраны в статье об A, AAAA и CNAME. Если часть проекта должна управлять собственной зоной, используйте делегирование через NS, а не только запись адреса.

Источники

• RFC 4592: The Role of Wildcards in the Domain Name System
• RFC 1034: Domain Names — Concepts and Facilities
• RFC 6125: Service Identity in TLS