DNS для SaaS: как работать с CNAME и корневыми доменами

Если ваш продукт — SaaS и вы хотите, чтобы клиенты заходили по своим доменам, а не по project.my-saas.tld, то самое сложное неожиданно оказывается не в коде, а в DNS. Оказывается, что «просто пропишите CNAME» не работает для корневых доменов, у клиентов стоит почта, свои записи, разные DNS‑провайдеры, а техподдержка тонет в одинаковых вопросах.

В этом тексте разберём практичные схемы подключения доменов к SaaS: через CNAME, A/AAAA, ALIAS/ANAME и комбинации записей, а также типичные грабли, на которые наступают разработчики и админы.

Модель: что такое «SaaS с кастомными доменами» в терминах DNS

Большинство SaaS‑сервисов, у которых есть «кастомный домен», реализуют примерно одну и ту же модель:

• Вы — владелец платформы, у вас есть основной домен, например my-saas.tld.
• Клиент создаёт ресурс: магазин, лендинг, блог, личный кабинет и т.п.
• Клиент хочет, чтобы ресурс открывался по своему домену, например shop.example.com или даже example.com.
• DNS‑зона домена клиента живёт у стороннего регистратора/хостера, которым вы не управляете.

Технически вам нужно две вещи:

1. Сделать так, чтобы HTTP(S)‑трафик с домена клиента попадал на вашу инфраструктуру.
2. На своей стороне маршрутизировать этот трафик к нужному аккаунту/ресурсу (по Host, SNI и т.п.).

Во второй части почти всегда помогает обычный обратный прокси (Nginx, Envoy, Caddy, HAProxy). Первая часть как раз и упирается в DNS и варианты с CNAME/A/AAAA/ALIAS.

Почему все любят CNAME и чем он удобен для SaaS

Для подключения поддоменов самого клиента (вида app.example.com) CNAME действительно почти идеален:

• Не нужно говорить клиенту конкретный IP вашего балансировщика; вы указываете своё имя, например edge.my-saas.tld.
• Вы можете менять инфраструктуру (IP, балансировщики, регионы), не заставляя всех клиентов менять DNS.
• Клиенты не ломают себе почту: MX/TXT/прочие записи продолжают жить в их зоне.

Типичная инструкция для клиента в этом случае выглядит так:

Тип: CNAME
Имя: app
Значение: edge.my-saas.tld.
TTL: 300–3600 (по ситуации)

Дальше вы на своём балансировщике принимаете HTTP(S)‑запросы, смотрите на заголовок Host и/или SNI, находите в базе соответствующий ресурс клиента и отдаёте его контент.

Если бы все пользовались только поддоменами, задача практически закрывалась бы одним этим паттерном. Но бизнес почти всегда хочет, чтобы открывался красивый корневой домен без «www» — и именно там начинаются нюансы.

Ограничение: почему нельзя повесить CNAME на корень зоны

DNS‑стандарт (RFC 1034/1035) накладывает важное ограничение: на одном и том же имени нельзя одновременно иметь CNAME и другие записи (кроме некоторых служебных типа DNSSEC). Корень зоны (example.com.) почти всегда содержит как минимум:

• NS — делегирование зоны;
• SOA — служебная запись зоны.

А значит, сделать так нельзя:

example.com.  IN  NS    ns1.provider.tld.
example.com.  IN  SOA   ns1.provider.tld. admin.example.com. (...)
example.com.  IN  CNAME edge.my-saas.tld.   ; так делать нельзя по стандарту

Многие DNS‑панели даже не позволят сохранить такую конфигурацию. Поэтому «дайте CNAME на корень домена» — плохой совет и заведомо неработающая инструкция.

Поддомены против корневого домена: что проще и что чаще используют

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

• app.example.com, store.example.com, blog.example.com и т.п. — через CNAME на ваш edge‑домен.
• Клиент сам, если хочет, может сделать редирект с example.com на нужный поддомен у себя (через свой веб‑сервер/конструктор/редирект‑сервис).

Но продуктово часто требуется именно работа с «голым» доменом: example.com. Это важно для маркетинга, печатной рекламы, email‑подписей и т.д. Тогда придётся выбирать один из паттернов, которые обходят ограничение CNAME.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Схема 1: клиент настраивает A/AAAA на ваши IP

Классический и до сих пор самый универсальный способ подключения корневого домена к SaaS — попросить клиента прописать записи A и, по возможности, AAAA на ваши адреса балансировщиков.

Тип: A
Имя: @
Значение: 203.0.113.10

Тип: AAAA
Имя: @
Значение: 2001:db8::10

Плюсы:

• Работает везде, не требует поддержки экзотических записей.
• Не конфликтует с MX/TXT: почта продолжает жить отдельно.
• Не нарушает стандарт DNS: это обычные A/AAAA.

Минусы:

• Каждый раз при смене ваших IP нужно уведомлять всех клиентов, чтобы они обновили записи.
• У многих мелких SaaS нет стабильных «вечных» IP; всё крутится за балансировщиками и CDN.
• Часть клиентов ставит низкий TTL (60–300 секунд), что увеличивает нагрузку на ваши DNS‑серверы и делает поведение менее предсказуемым.

Поэтому этот вариант — рабочий, но требует тщательно спроектированной IP‑адресации и планирования: IP‑адреса, которые вы отдаёте клиентам в инструкции, должны быть максимально стабильны годами.

Схема 2: ALIAS/ANAME — «CNAME для корня»

Многие современные DNS‑провайдеры придумали псевдо‑записи, которые на стороне сервера ведут себя как CNAME, но наружу отвечают как A/AAAA. Они называются по‑разному:

• ALIAS;
• ANAME;
• иногда «flattened CNAME» или «CNAME flattening» в маркетинге.

Идея:

Клиент в своей панели создаёт для корня зоны запись особого типа, указывающую на ваше доменное имя, а DNS‑провайдер сам резолвит это имя в IP и отвечает конечным клиентам как будто это обычные A/AAAA.

Конфигурация в панели клиента может выглядеть примерно так:

Тип: ALIAS (или ANAME)
Имя: @
Значение: edge.my-saas.tld.

Плюсы:

• Клиент всё так же ориентируется на ваше доменное имя, а не на IP.
• Вы свободно меняете свою инфраструктуру (IP, регионы, балансировку) — клиенты не трогают DNS.
• Не нарушается стандарт: с точки зрения внешнего мира корень зоны содержит A/AAAA, а не CNAME.

Минусы:

• Это нестандартные типы, их поддерживает далеко не каждый DNS‑провайдер.
• Поведение может отличаться между провайдерами (TTL, кеширование, лимиты запросов к вашему имени и т.п.).
• Вам придётся иметь разные инструкции для разных DNS‑провайдеров.

Если вы выбрали такую схему, полезно собрать справочник: как это называется и где искать в панелях популярных регистраторов.

Схема 3: только поддомены + редирект с корня у клиента

Компромиссный и довольно популярный вариант: вы официально поддерживаете только поддомены (через CNAME), а корневой домен клиент при желании перенаправляет на этот поддомен у себя.

Схема:

1. Клиент создаёт CNAME для app.example.com на ваше edge.my-saas.tld.
2. На своём существующем хостинге (или у провайдера редиректов) делает редирект https://example.com → https://app.example.com.

Плюсы:

• Вы не трогаете корневой домен; не нужно решать проблему CNAME vs SOA/NS.
• Минимум DNS‑взаимодействия — только CNAME.
• Почта, SPF, DKIM, DMARC живут отдельно, вы в них не вмешиваетесь.

Минусы:

• Нужна какая‑то инфраструктура (у клиента или у стороннего сервиса), которая сделает редирект с корня на поддомен.
• Маркетинг может быть недоволен: URL в браузере всё равно будет с поддоменом.
• Это не всегда удобно, если SaaS предполагает, что на домене только ваш сервис, без старого сайта/хостинга.

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

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Схема 4: вы становитесь DNS‑хостингом для домена клиента

Радикальный, но предельно контролируемый способ: попросить клиента делегировать домен (или подзону) на ваши NS и уже у себя организовать любые CNAME/A/AAAA/ALIAS для его ресурсов.

Варианты:

• Полная делегация домена: клиент в панели регистратора меняет NS на ваши.
• Делегация подзоны: например, клиент оставляет example.com у себя, но делегирует store.example.com на ваши NS.

Плюсы:

• Вы полностью контролируете DNS‑записи, можете автоматически создавать CNAME/A/AAAA/ALIAS для каждого ресурса клиента.
• Можно строить более умные схемы (геораспределение, failover, проверка владения через автоматические TXT‑записи и т.п.).
• Клиенту достаточно один раз сменить NS или создать пару NS‑записей.

Минусы:

• Не все клиенты готовы отдавать весь DNS своего домена SaaS‑платформе — это вопрос доверия.
• Вы становитесь ответственными за почту и другие сервисы клиента, если забираете к себе весь домен.
• Вам нужно поднимать и обслуживать собственную инфраструктуру DNS‑хостинга, чаще всего на надёжном VDS или выделенных серверах.

Обычно такая схема применяется либо для узких сценариев (делегирование только подзон, которыми вы пользуетесь), либо в крупных enterprise‑контрактах, когда SaaS фактически становится частью инфраструктуры клиента.

Какой паттерн выбрать для своего SaaS

На практике большинство команд выбирают гибрид:

• Официально и полноценно поддерживают поддомены клиентов через CNAME.
• Для корневого домена предлагают два варианта на выбор: A/AAAA на ваши IP или ALIAS/ANAME, если DNS‑провайдер клиента поддерживает.
• Дополнительно описывают вариант с редиректом клиента с example.com на app.example.com, если не хочется или нельзя менять A‑записи.

В документации удобно сделать явную матрицу вариантов:

• «Хочу app.example.com» → CNAME на edge.my-saas.tld.
• «Хочу example.com и DNS‑провайдер умеет ALIAS/ANAME» → ALIAS/ANAME на edge.my-saas.tld.
• «Хочу example.com, провайдер не умеет ALIAS/ANAME» → A/AAAA на IP, которые вы даёте, или редирект на поддомен.

Проверка владения доменом и безопасность

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

• TXT‑проверка: вы генерируете токен и просите добавить TXT‑запись.
• HTTP‑проверка: просите клиента выложить файл или заголовок по определённому пути на своём текущем сайте (подходит не всегда).

С DNS‑подключением SaaS почти всегда удобнее TXT‑подход:

1. Клиент в интерфейсе пишет желаемый домен.
2. Вы генерируете токен и просите добавить его в TXT‑запись, например:

Тип: TXT
Имя: _verify.your-saas.example.com
Значение: saas-verification=abc123

Дальше вы по cron или через worker периодически опрашиваете DNS и, как только запись появляется, помечаете домен как подтверждённый. После этого можно автоматически:

• создать сертификат (через HTTP‑01 или, при возможности автоматизации DNS, DNS‑01);
• включить выдачу контента по этому домену в балансировщике;
• при необходимости — обновить конфигурацию WAF, логирования и т.п.

Не стоит привязывать факт владения доменом только к CNAME/A‑записям на вашу сторону. Теоретически кто‑то может попытаться подвесить ваш домен к чужому SaaS, а вы «поверите» только из‑за того, что видите у себя трафик с этим Host.

DNS и SSL для SaaS: как связать домен, SNI и сертификаты

После того как домен «смотрит» на вашу инфраструктуру, встаёт вопрос TLS:

• Нужно получить сертификат на домен клиента.
• Нужно обслуживать его на балансировщике наравне с другими доменами.

Типичные варианты в контексте DNS:

• Если у вас CNAME/ALIAS/ANAME на свой домен, удобно использовать HTTP‑01: вы отвечаете по /.well-known/acme-challenge/ сами.
• Если клиент прописывает A/AAAA на ваш IP, это тоже не мешает HTTP‑01: трафик приходит к вам.
• DNS‑01 в чистом виде сложен, потому что TXT‑записи нужно менять на стороне клиента; его проще использовать, когда вы сами хостите DNS клиента или у вас есть API‑доступ к его DNS‑провайдеру.

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

В любом случае архитектура обычно такая:

1. Клиент настроил DNS и вы подтвердили владение доменом (TXT‑токен).
2. У вас есть процесс, который:

• проверяет резолв домена;
• инициирует выпуск сертификата (Let’s Encrypt или платный CA);
• добавляет сертификат в хранилище вашего балансировщика;
• обновляет конфигурацию (или использует динамическое хранилище сертификатов).

Важно: не пытайтесь жёстко завязывать момент выпуска сертификата на то, что DNS уже полностью «проскочил кеш». В реальном мире у части резолверов могут быть старые записи в кеше, но это не мешает большинству клиентов и ACME‑серверу дойти до вашей инфраструктуры. Достаточно убедиться, что с нескольких независимых резолверов домен резолвится корректно.

Типичные проблемы с DNS у SaaS и как их избежать

1. Клиент ломает свою почту, перенеся MX на вашу сторону

Классика: в попытке «передать всё SaaS‑платформе» клиент удаляет или меняет MX/SPF/DKIM — и почта перестаёт работать.

Что помогает:

• В документации подчёркивать: вы отвечаете только за веб‑трафик, а не за почту.
• Показывать пример настроек, в котором MX/TXT‑записей вы не касаетесь вообще.
• При возможности делать автоматический предчек DNS и предупреждать, что у клиента есть настроенная почта, которую не нужно трогать.

Подробно про связку DNS‑записей и почтовой инфраструктуры имеет смысл дополнительно разобрать в отдельном материале о DNS для SPF, DKIM и DMARC.

2. Слишком низкие TTL и медленный «прогрев» инфраструктуры

Часто SaaS в примерной инструкции советует TTL 60–300 секунд, чтобы «всё быстро обновлялось». На практике у клиента уже могут быть TTL 3600–86400, и смена NS или типа записи вступит в силу через часы.

Рекомендации:

• В документации честно писать: «После изменения DNS подождите до 24 часов, прежде чем считать, что что‑то пошло не так».
• Если нужно плановое переключение, заранее попросить клиента уменьшить TTL за 1–2 суток до миграции, затем поменять запись и после стабилизации вернуть TTL обратно.

3. Конфликтующие записи на том же имени

Классическая ошибка: на одном имени клиент одновременно пытается держать CNAME и A/MX/TXT. DNS‑панель иногда это блокирует, но не всегда.

Решение:

• Отдельно пояснять в документации: «Если вы создаёте CNAME для app.example.com, на этом имени не должно быть других записей (A/MX/TXT и т.п.)».
• Показывать корректные примеры: почта остаётся на example.com, CNAME — только на поддомене.

4. Случайный «угон» домена другим аккаунтом

Если вы не проверяете владение доменом, клиент A может попытаться добавить домен другого клиента B в свой аккаунт. Технически, если B уже направил DNS на вашу инфраструктуру, вы можете начать обслуживать его трафик для A — что недопустимо.

Минимальный набор защиты:

• Всегда требовать TXT‑подтверждение и не включать домен без него.
• Привязывать домен к одному аккаунту и не позволять другому его «перехватить», пока владелец явно не удалит его или не подтвердит перенос.

Практический чек‑лист для внедрения DNS в вашем SaaS

Наконец, сведём всё в компактный список шагов, с которым можно спланировать или перепроверить свою реализацию.

1. Определите поддерживаемые сценарии домена

• Поддомены клиентов через CNAME (обязательно).
• Корневой домен через A/AAAA (опционально).
• Корневой домен через ALIAS/ANAME (опционально, если хотите поддержать максимум провайдеров).
• Подзоны на ваших NS (опционально, если готовы строить свой DNS‑хостинг).

2. Спроектируйте свой edge‑домен и IP‑адреса

• Выберите домен, на который клиенты будут делать CNAME/ALIAS/ANAME, например edge.my-saas.tld.
• Обеспечьте ему устойчивую схему: несколько A/AAAA, отказоустойчивый DNS, мониторинг.
• Если поддерживаете A‑подключение для корневых доменов, выделите стабильные IP‑адреса.

3. Реализуйте проверку владения доменом

• Сделайте генерацию TXT‑токена и инструкцию по его добавлению.
• Напишите worker, который проверяет наличие TXT и подтверждает домен.
• Не включайте обслуживание домена в балансировщике до успешной проверки.

4. Свяжите DNS с выпуском сертификатов

• После подтверждения домена инициируйте выпуск сертификата.
• Прикрутите автоматическое продление и алерты на сбои выпуска.
• Используйте SNI‑based виртуальные хосты на балансировщике и корректные SSL-сертификаты для доменов клиентов.

5. Подготовьте человеческую документацию

• Скриншоты популярных DNS‑панелей с пошаговыми инструкциями.
• Готовые шаблоны: «Если ваш DNS‑провайдер поддерживает ALIAS — делайте так, если нет — вот инструкция с A/AAAA».
• FAQ по типичным проблемам: почта, TTL, конфликтующие записи, время ожидания.

Итоги

DNS для SaaS с кастомными доменами — не «магический CNAME», а набор аккуратно подобранных паттернов для разных ситуаций. Для поддоменов практически всегда хватит простого CNAME на ваш edge‑домен. Для корневых доменов придётся выбирать из трёх основных подходов: A/AAAA на ваши IP, ALIAS/ANAME у провайдера клиента или редирект с корня на поддомен.

Ключ к здоровой системе — чёткая архитектура (что вы поддерживаете и как), подтверждение владения доменом, связка DNS с автоматическим выпуском сертификатов и хорошая документация для клиентов. Тогда и поддержка не захлебнётся в однотипных тикетах, и у бизнеса будет рабочий, предсказуемый и масштабируемый механизм подключения доменов к SaaS.