SaaS-проект: как грамотно подключать домены клиентов, DNS и SSL

Для небольшого SaaS-проекта вопрос доменов клиентов кажется чем‑то второстепенным: «пусть ставят CNAME — и поехали». Но как только приходит первый крупный клиент с отделом безопасности, выясняется, что нужны разные варианты подключения, понятная схема DNS, автоматическая выдача SSL и внятные гарантии, что никто не сможет перехватить трафик.

В этом разборе посмотрим на задачу системно: какие модели работы с доменами бывают у SaaS, как выстроить DNS-архитектуру, что учесть при выпуске и продлении SSL‑сертификатов и какие компромиссы вы будете предлагать клиентам.

Типовые сценарии подключения домена к SaaS

Когда вы говорите клиенту «подключите домен к нашему сервису», за этим может стоять несколько технически разных моделей. От этого зависит и UX для клиента, и зона ответственности, и возможности автоматизации.

1. CNAME на ваш домен

Классический для SaaS вариант: клиент создаёт у себя запись вида:

shop.example.com.  3600  CNAME  client123.saasvendor.com.

Что это даёт:

• Минимум трения: клиент не трогает NS и не переносит домен.
• Всю инфраструктуру (балансировщики, IP‑адреса, сертификаты) контролируете вы.
• Можно относительно безболезненно мигрировать инфраструктуру, меняя A/AAAA у себя, не трогая DNS клиента.

Ограничения:

• CNAME нельзя ставить в корень домена (apex) в классическом DNS. То есть example.com → CNAME технически некорректен (хотя некоторые провайдеры реализуют «ALIAS/ANAME» как надстройку).
• Зависимость от вашей цепочки DNS и сертификатов: любая ошибка на вашей стороне ломает и все подключенные домены клиентов.

2. Подключение через A/AAAA (вы даёте IP)

Чаще этот вариант просят более «контролирующие» клиенты: они хотят явный A/AAAA на ваш балансировщик:

shop.example.com.  300  A     203.0.113.10
shop.example.com.  300  AAAA  2001:db8::10

Плюсы:

• Работает и для поддоменов, и для apex (корня домена).
• Меньше «магии» для сетевых админов клиента — они видят конкретный IP.

Минусы:

• Жёсткая привязка к IP: при миграции/балансировке нужно синхронно менять DNS у клиентов, а они не всегда делают это быстро.
• Нужно тщательно думать о TTL: слишком большой — больно мигрировать, слишком маленький — лишняя нагрузка на DNS и кэши.

3. NS‑делегация поддомена на ваш DNS

Компромиссный вариант, популярный в продвинутых SaaS. Клиент делегирует отдельный поддомен на ваши NS:

saas.example.com.  3600  NS  ns1.saasvendor.net.
saas.example.com.  3600  NS  ns2.saasvendor.net.

Дальше уже вы внутри своей зоны saas.example.com создаёте нужные A/AAAA, CNAME, TXT и так далее.

Преимущества:

• Клиент контролирует только «рамку» (делегацию), всё внутри — ваша зона ответственности.
• Можно автоматизировать всё, что связано с DNS (ACME DNS‑01, служебные записи, валидация почты и т.п.).
• В случае переноса домена клиента к другому регистратору достаточно перенести делегацию NS — внутренняя структура не меняется.

Недостатки:

• Не подходит для корня домена, только для поддоменов (например, saas.example.com).
• Клиенту приходится доверить вам часть управления DNS, что не всегда подходит крупным организациям с жёсткими регламентами.

4. Полный перенос домена под ваше управление

Радикальный вариант: клиент передаёт домен под управление аккаунта у регистратора, которым управляете вы, или даёт вам полноценный доступ к своему DNS‑аккаунту. На практике это чаще работает для white-label решений, когда SaaS создаёт и администрирует домены клиентам «под ключ».

Плюсы:

• Максимальная автоматизация: вы можете сами создавать/править любые записи.
• Единообразие: все домены клиентов живут по одной схеме TTL, записей, DNSSEC‑политике.

Минусы:

• Большой уровень доверия: не все клиенты на это готовы.
• Нужно продумать юридическую часть: кто владелец домена, кто отвечает за продление и т.п.

Архитектура DNS для SaaS: на что обратить внимание

Разобравшись с моделями подключения, нужно спроектировать саму архитектуру DNS‑зон, чтобы не упереться в ограничения по масштабированию и безопасности.

Разделение зон: служебный домен vs клиентские

Минимальный набор для SaaS‑проекта обычно включает:

• основной домен сервиса, где живёт публичный сайт и API;
• служебный домен для внутренних целей, оркестрации, ACME‑challenge и пр.;
• паттерн для клиентских поддоменов (например, client-id.saasvendor.com).

Важная идея: не смешивайте служебные записи и записи клиентов в одной зоне, если планируете масштабируемый и безопасный DNS. Лучше иметь, например:

• saasvendor.com — маркетинг, лендинг, документация;
• core.saasvendor.com — ваши внутренние сервисы, балансировщики, API;
• clients.saasvendor.com — пространство для мэппинга клиентских доменов.

Так проще задавать разные политики TTL и DNSSEC, разделять зоны между командами и инфраструктурой и не засорять основную зону экспериментами.

TTL: баланс между гибкостью и стабильностью

TTL напрямую влияет на то, как быстро изменится реальное поведение после правки записи. Для SaaS полезно выделить три класса:

• Динамические записи (балансировщики, A/AAAA, SRV) — TTL 60–300 секунд: удобно при миграциях и авариях.
• Относительно стабильные (CNAME клиентов, NS‑делегации поддоменов) — TTL 3600–14400: меньше нагрузка на DNS, реже кэш‑баги.
• Редко меняющиеся (TXT для SPF/DKIM/ACME DNS‑01, политики) — TTL 3600–86400.

Ключевой момент: там, где вы отдаёте клиенту инструкцию «создайте запись», старайтесь сразу рекомендовать разумный TTL, чтобы потом не мучиться с многочасовыми кэшами.

DNSSEC: когда и как включать

Если ваш SaaS серьёзно относится к безопасности, рано или поздно встанет вопрос DNSSEC. Здесь важно понимать, что для вашего домена и служебной зоны включать DNSSEC очень желательно — это снижает риск подмены записей по пути.

Для клиентских доменов вы не всегда влияете на политику. Если вы используете валидацию через ACME DNS‑01 или NS‑делегацию, убедитесь, что ваш DNS‑провайдер корректно работает с DNSSEC. При работе с wildcard SSL через DNS‑01 и включённым у клиента DNSSEC внимательно проверяйте цепочку ключей и DS‑записей, иначе валидация может ломаться именно у клиентов с валидирующими резолверами.

Хорошая практика — документировать поддерживаемые схемы DNS и чётко указывать, как DNSSEC влияет на подключение домена и выпуск сертификата.

Если вы только планируете поддержку собственных доменов клиентов, заранее продумайте, как это будет сочетаться с вашей политикой по регистрации доменов: часть клиентов предпочтёт, чтобы домен и SaaS-сервис обслуживал один и тот же провайдер.

SSL для SaaS: какая модель подойдёт вашему сервису

Если домены клиентов работают по HTTP, у вас проблемы — и с безопасностью, и с современными браузерными требованиями. Для SaaS сейчас де-факто стандарт — обязательный HTTPS с HSTS, а для этого нужна продуманная схема SSL‑сертификации.

Ключевые требования к SSL в SaaS

На уровне требований почти любой SaaS хочет:

• полностью автоматический выпуск и продление сертификатов для доменов клиентов;
• поддержку и обычных, и wildcard‑доменов (для мультисубдоменных сценариев);
• минимальную ручную работу со стороны клиентов;
• внятную ошибку и fallback, если сертификат по какой‑то причине выпустить не удалось.

Основной инструмент сегодня — протокол ACME (Let’s Encrypt и коммерческие ACME‑провайдеры). Важно не только «прикрутить certbot», а встроить ACME‑процесс в вашу модель DNS и в жизненный цикл доменов клиента.

Выбор типа проверки: HTTP‑01 vs DNS‑01

ACME даёт несколько способов доказывать владение доменом. Для SaaS практический выбор — HTTP‑01 или DNS‑01.

HTTP‑01 для клиентских доменов

Сценарий: CA делает HTTP‑запрос к http://client-domain/.well-known/acme-challenge/... и проверяет, что именно ваш сервер отвечает правильным токеном.

Преимущества:

• Простая реализация в случае CNAME на ваш домен или A/AAAA на ваш балансировщик.
• Не требует доступа к DNS клиента.

Ограничения:

• Не работает, если домен ещё не указывает на вашу инфраструктуру (часто на этапе предварительной настройки).
• Не выдаёт wildcard‑сертификаты: *.example.com через HTTP‑01 получить нельзя.

DNS‑01 и NS‑делегация поддомена

DNS‑01 проверяет наличие TXT‑записи в зоне домена. Для SaaS это открывает две сильные возможности:

• выдача wildcard‑сертификатов для клиентских доменов;
• выпуск сертификатов даже до того, как клиент полностью переключил трафик на вашу инфраструктуру (если даёт вам управлять поддоменом).

Типовой рабочий паттерн:

1. Клиент делегирует поддомен, например saas.example.com, на ваши NS.
2. Вы через API вашего DNS‑провайдера создаёте TXT для ACME‑валидации.
3. Выпускаете wildcard *.saas.example.com и, при необходимости, отдельные именные сертификаты.

Слабое место — необходимость договориться с клиентом о делегации поддомена. Это усложняет продажи, но даёт сильный плюс по автоматизации и безопасности.

Управление ключами и сертификатами

Технически важно не только получить сертификат, но и безопасно хранить приватные ключи, грамотно обновлять, релоудить веб‑сервер и при этом не устроить даунтайм.

Типовой стек для SaaS:

• централизованный ACME‑клиент (или внутренняя служба), которая знает о доменах клиентов и может создавать/обновлять сертификаты;
• хранилище сертификатов и ключей (файловая система с ограничениями доступа, хранилище секретов, иногда — HSM у крупных проектов);
• интеграция с веб‑серверами/балансировщиками (Nginx/HAProxy/Envoy) для бесшовной загрузки новых сертификатов.

С точки зрения операционной модели хорошие практики:

• не использовать один огромный SAN‑сертификат на тысячи доменов клиентов: при компрометации придётся перевыпускать всё;
• делить сертификаты хотя бы по крупным клиентам, арендаторам или доменным зонам;
• иметь мониторинг сроков действия SSL и алерты задолго до истечения (особенно, если часть сертификатов всё же выпускается вручную).

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

Безопасность и риски: шаринг инфраструктуры и изоляция клиентов

SaaS по определению мультиарендный: десятки или сотни доменов живут на одних и тех же IP и часто на одних и тех же балансировщиках. Это порождает специфические риски.

Риски шаринга IP и TLS

Когда на одном IP живут десятки доменов клиентов, могут всплывать:

• Побочные эффекты блокировок. Если один домен попадает в чёрные списки (антиспам, государственные блоклисты, корпоративные фильтры), IP могут начать блокировать целиком, задевая и других клиентов.
• Перехват трафика через неверную SNI‑конфигурацию. Ошибка в конфиге TLS (не тот сертификат на не тот SNI) приводит к смешению трафика между клиентами.

Снизить риски помогает:

• разумное шардирование IP: крупным клиентам можно выделять отдельные IP‑пулы или хотя бы отдельные frontend‑пулы (например, на выделенном VDS);
• автоматическое тестирование конфигов на стенде и dry run перед выкатыванием;
• строгая политика по аллокации TLS‑сертификатов и их привязке к конкретным конфигам.

Изоляция арендаторов на уровне DNS и SSL

Изоляцию часто воспринимают как «историю про базы данных и контейнеры», но в DNS/SSL тоже есть свои принципы:

• не смешивайте записи разных крупных клиентов в одной «сырой» зоне без разделения; лучше иметь предсказуемый шаблон, вроде tenant-id.clients.saasvendor.com;
• не добавляйте домены клиентов в один общий wildcard, если по бизнесу важно их чётко разделять;
• по возможности логируйте и аудитируйте операции с доменами: кто и когда добавил или изменил запись, выпустил сертификат и т.д.

Из практики хорошо работает модель, где у каждого арендатора есть своё представление в базе данных (или сервисе управления конфигурацией), а DNS/SSL‑слой является просто отражением этого состояния. Тогда ручные правки в зонах и конфигах сведены к минимуму, а любые изменения идут через «контролируемый фронт» (панель, API).

Онбординг доменов клиентов: UX, который не ломает технику

Технически все перечисленные схемы можно реализовать. Но если SaaS предоставляет только одну сложную для клиента модель, вы потеряете часть сделок. Поэтому важно продумать онбординг.

Типичный путь клиента

Для нового клиента картина выглядит так:

1. Он настраивает продукт и хочет «подключить красивый домен».
2. Сервис предлагает ему 1–2 варианта: «самый простой» и «расширенный».
3. Клиенту показывают инструкцию: какие записи создать и где.
4. Сервис периодически проверяет DNS и после успеха пробует выпустить SSL.

Задача инфраструктуры — сделать так, чтобы инструкция была максимально короткой и не требовала знаний DNS‑внутренностей, все сложные детали (TTL, DNSSEC, ACME‑валидация) решались на вашей стороне, а пользователь видел понятный статус: «ожидание DNS», «выпускаем сертификат», «готово».

Контроль и диагностика DNS на вашей стороне

Полезный компонент SaaS‑платформы — внутренний «DNS‑чекер», который:

• регулярно запрашивает записи у авторитетных NS клиента (а не только через локальный резолвер);
• умно учитывает TTL (не спамит запросами каждую секунду, если TTL высокий);
• хорошо показывает пользователю различие между «мы ещё не видим запись» и «запись видим, но она неправильная».

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

Чеклист для инженера SaaS: DNS и SSL

Чтобы не утонуть в деталях, полезно иметь короткий чеклист, закрывающий основные риски.

По DNS

• Определены и задокументированы поддерживаемые модели подключения домена: CNAME, A/AAAA, NS‑делегация, полный перенос.
• Для каждой модели есть понятная инструкция для клиента (с примерами и рекомендуемыми TTL).
• Служебная DNS‑архитектура разделена: основной домен, служебная зона, зона клиентов.
• Продумана стратегия TTL: для динамических записей короткий, для стабильных — выше.
• Продуман вопрос DNSSEC: где он включён, как влияет на ACME‑валидации.

По SSL

• Есть единый сервис или модуль, отвечающий за выпуск и продление сертификатов (ACME‑клиент).
• Определены типы проверок (HTTP‑01, DNS‑01) и сценарии использования.
• Хранилище сертификатов и ключей защищено, понятны права доступа и ротация.
• Интеграция с веб‑серверами/балансировщиками делает релоад конфигов без даунтайма.
• Есть мониторинг сроков действия сертификатов и алерты.

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

• Есть стратегия шардирования IP‑адресов и TLS‑фронтендов для крупных клиентов.
• Настроен аудит операций с доменами и сертификатами в административной панели.
• Продумана реакция на инциденты: компрометацию ключа, ошибочную выдачу сертификата, блокировку IP.

Если вы заранее спроектируете DNS и SSL как часть архитектуры SaaS, а не как «последний штрих перед запуском», это сэкономит месяцы поддержки и массу нервов инженерам. Хорошо продуманная модель доменов клиентов — это не только удобство для пользователей, но и важная часть безопасности и надёжности всего сервиса.