Как настроить кастомный домен с TLS за 5 минут (с помощью Elido)

Настройка кастомного домена с HTTPS требует двух DNS-записей и около трех минут ожидания распространения. Остальное время обычно тратится на понимание того, что означают эти записи, зачем нужны обе и что происходит после их добавления. Этот пост - практическая версия: пять конкретных шагов, точный вызов API и объяснение механизма работы сертификатов, чтобы вы знали, что делать, если что-то пойдет не так.

Почему TLS важен именно для коротких ссылок#

Короткая ссылка без HTTPS - это уязвимость в тех аспектах, в которых обычный URL без HTTPS ею не является.

Ответ с редиректом - 301 или 302 с заголовком Location - это и есть вся полезная нагрузка. Если первоначальный HTTP-запрос передается по открытому протоколу HTTP, любой участник сетевого пути может прочитать целевой URL до того, как клиент перейдет по нему. Это означает, что адрес вашей кампании, партнерская ссылка или ссылка на внутренний инструмент видны любому сетевому наблюдателю на первом же этапе. Современные браузеры начали выводить предупреждения безопасности для коротких ссылок HTTP именно из-за этого паттерна раскрытия данных.

QR-коды усугубляют проблему. Человек, сканирующий код в физическом пространстве, не имеет предварительных доверительных отношений с этим URL - код является единственным сигналом доверия. Предупреждение браузера при первой загрузке - худшая из возможных точек трения: вы уже оплатили тираж, размещение на мероприятии или наружную рекламу, и предупреждение системы безопасности при сканировании - это то, что с наибольшей вероятностью отпугнет заинтересованного человека. Действующий сертификаты TLS под вашим собственным доменом - это самый дешевый сигнал доверия, который вы можете купить для кампании на базе QR-кодов.

На s.elido.me или b.elido.me сертификат TLS принадлежит Elido. Замок настоящий, но домен не ваш, а значит, брендовое доверие достается платформе, а не вам. Кастомный домен на базе go.acme.com ставит ваше имя в сертификат.

Подробнее об основах DNS и TLS в программном посте: Custom domain short links: DNS, TLS, and what runs at the edge.

---

Step 1: Pick the hostname#

Наиболее распространенный выбор - короткий поддомен вашего основного домена: go.example.com, links.example.com или s.example.com. Чем короче, тем лучше - префикс поддомена будет появляться в каждой отправляемой вами ссылке.

Два ограничения, о которых стоит знать перед принятием решения:

Только поддомен, если ваш DNS-провайдер не поддерживает записи ALIAS. RFC 1034 §3.6.2 запрещает записи CNAME в корне зоны (apex, example.com). Если вы хотите, чтобы редирект шел с голого корня домена, ваш DNS-провайдер должен поддерживать записи ALIAS или ANAME (ALIAS в Route 53, CNAME flattening в Cloudflare, ALIAS в DNSimple). Это нестандартные расширения, которые «сглаживают» поиск перед публикацией. Проверьте документацию вашего провайдера; название функции варьируется, и не каждый провайдер ее предлагает.

Выберите поддомен, который вы не используете для чего-либо еще. Поддомен links.example.com, перенаправляющий через Elido, не должен иметь записи A, указывающей на ваш веб-сервер, или существующей записи CNAME. DNS-записи для одного и того же имени должны быть согласованы.

Для большинства команд подходят go.example.com или links.example.com. Выберите подходящий вариант, запишите его и переходите к шагу 2.

---

Step 2: Register the domain in Elido#

Откройте Settings → Custom Domains → Add Domain в панели управления, введите ваше имя хоста и нажмите Add. В ответ вы получите значения двух DNS-записей: токен верификации и цель CNAME. Вы используете их оба на шаге 3.

Если вы автоматизируете это - настраиваете новое рабочее пространство клиента, запускаете это как часть пайплайна развертывания или управляете этим через Terraform provider - вызов API выглядит так:

curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/domains \
  -H "Authorization: Bearer $ELIDO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "hostname": "go.example.com",
    "is_wildcard": false
  }'

Тело ответа включает verification_token (случайную шестнадцатеричную строку) и instructions, содержащие точные значения DNS-записей:

{
  "domain": {
    "id": 42,
    "hostname": "go.example.com",
    "status": "pending_verification"
  },
  "instructions": {
    "txt_record": "_elido-verify.go.example.com TXT \"verify=<token>\"",
    "cname_record": "go.example.com CNAME edge.elido.me"
  }
}

Кастомные домены доступны на paid plans. Тариф Business - это точка входа для кастомных доменов; агентствам, управляющим несколькими доменами клиентов в рамках одной организации, следует изучить модель рабочих пространств на agency solutions page.

---

Step 3: Add the two DNS records#

Перейдите в панель управления вашего DNS-провайдера и добавьте обе записи из объекта instructions. Вам нужны обе - CNAME направляет трафик на edge Elido; запись TXT доказывает, что вы владеете доменом, прежде чем Elido согласится его обслуживать.

Для обычного поддомена:

go.example.com              CNAME  edge.elido.me.
_elido-verify.go.example.com  TXT    "verify=<your-token>"

Для wildcard-домена (тариф Business, покрывает *.go.example.com):

*.go.example.com            CNAME  edge.elido.me.
_elido-verify.go.example.com  TXT    "verify=<your-token>"

Префикс _elido-verify - это стандартное соглашение для DNS-проверки - оно размещает подтверждение владения в поддомене имени хоста, проходящего проверку, чтобы запись TXT не конфликтовала с CNAME.

Несколько заметок по конкретным провайдерам:

• Cloudflare: Добавьте обе записи. Оставьте переключатель проксирования CNAME в положении off (серый облако, DNS-only). Режим HTTP-прокси Cloudflare удаляет исходное имя хоста до того, как оно достигнет edge Elido, что ломает проверку авторизации CaddyAsk. Режим DNS-only передает запрос без изменений.
• AWS Route 53: Используйте запись ALIAS, если вам нужен корень домена (apex); для поддоменов подходит обычный CNAME. Route 53 не поддерживает CNAME в корне зоны, но поддерживает ALIAS для внешних целей.
• GoDaddy / Namecheap / большинство регистраторов: Стандартные CNAME и TXT - никаких специальных настроек.

Установите TTL для обеих записей на 300 секунд (5 минут), если ваш провайдер это позволяет. TTL по умолчанию для многих зон составляет 3600 секунд; меньший TTL означает более быстрое подтверждение распространения и более быстрое восстановление, если вам понадобится изменить записи позже.

---

Step 4: Wait for verification#

Как только записи будут на месте, domain-manager начнет опрашивать их автоматически, используя публичный резолвер Google (8.8.8.8) через короткие интервалы. Вам не нужно нажимать «Verify now».

Сервис проверяет два условия, прежде чем пометить домен как активный:

1. _elido-verify.go.example.com возвращает запись TXT, значение которой равно verify=<token> - это подтверждает, что вы управляете DNS-зоной.
2. go.example.com разрешается через CNAME в edge.elido.me - это подтверждает, что трафик дойдет до edge Elido.

Когда обе проверки проходят успешно, status меняется с pending_verification на verified. Вы можете проверить это сами:

curl https://api.elido.app/v1/workspaces/{workspace_id}/domains/42 \
  -H "Authorization: Bearer $ELIDO_API_TOKEN"

Следите за полем status. Типичное время распространения для записей с TTL 300с составляет менее 5 минут. Записи с TTL по умолчанию 3600с могут обновляться до часа, если вы находитесь в регионе, где резолверы агрессивно кэшируют данные.

Если верификация затянулась, проверьте правильность публикации записей:

dig TXT _elido-verify.go.example.com +short
dig CNAME go.example.com +short

Запрос TXT должен вернуть "verify=<your-token>". Запрос CNAME должен вернуть edge.elido.me. (точка в конце - это нормально).

---

Step 5: The first request issues the certificate automatically#

Как только domain-manager пометит домен как проверенный и зарегистрирует его в Caddy, ваша часть работы выполнена. TLS настраивается без каких-либо дополнительных действий.

Механизм работы - Caddy on-demand TLS (ADR-0012): вместо предварительного выпуска сертификатов для каждого проверенного домена Caddy выпускает сертификат при первом рукопожатии TLS для нового имени хоста. Перед попыткой выпуска ACME Caddy вызывает эндпоинт CaddyAsk сервиса domain-manager - обычный HTTP-запрос GET ?domain=go.example.com. Если domain-manager возвращает 200 (домен находится в статусе проверенного или активного), Caddy продолжает работу. Если возвращается 404, рукопожатие TLS завершается ошибкой, и запрос на сертификат никогда не отправляется. Этот барьер является последней линией защиты от ошибочного выпуска сертификатов для неизвестных имен хостов.

Когда Caddy приступает к работе, процесс ACME (RFC 8555) запускает проверку HTTP-01:

1. Caddy запрашивает новый заказ у Let's Encrypt.
2. Let's Encrypt отвечает токеном проверки: разместите его по адресу http://go.example.com/.well-known/acme-challenge/<token>.
3. Caddy помещает токен в свой обработчик HTTP в памяти.
4. Let's Encrypt запрашивает токен по протоколу HTTP и подтверждает его.
5. Сертификат выпускается, сохраняется в кэше сертификатов Caddy, и исходный HTTPS-запрос обслуживается.

Шаги 1–5 добавляют примерно 2–3 секунды задержки к самому первому запросу к только что верифицированному домену. Каждый последующий запрос использует кэшированный сертификат без каких-либо задержек. Caddy автоматически обрабатывает продление до истечения срока действия.

Elido выпускает сертификаты ECDSA P-256 для всех кастомных доменов. Подписи P-256 компактнее и быстрее проверяются, чем RSA-2048, что важно на уровне edge, где рукопожатия TLS находятся на критическом пути.

---

Common pitfalls#

Записи CAA блокируют Let's Encrypt. Записи Certification Authority Authorization (CAA) указывают, каким центрам сертификации разрешено выпускать сертификаты для домена. Если в вашей DNS-зоне есть запись example.com CAA 0 issue "digicert.com", Let's Encrypt откажется выпускать сертификат для go.example.com, так как он наследует политику CAA корня домена. Решение: добавьте go.example.com CAA 0 issue "letsencrypt.org" или удалите ограничение в корне, если это позволяет ваша политика безопасности. Эндпоинт статуса domain-manager возвращает ошибки CAA в теле ответа об ошибке.

Включено проксирование Cloudflare. См. шаг 3 - CNAME должен быть в режиме DNS-only (серое облако). Режим «оранжевого облака» (проксируемый) переписывает имя хоста в запросе, что приводит к сбою авторизации CaddyAsk.

CNAME flattening в корне (apex). CNAME flattening в Cloudflare работает для большинства случаев, но имеет один нюанс: DNS-ответ от серверов имен Cloudflare - это запись A (разрешенный IP), а не CNAME. Проверка верификации Elido использует LookupCNAME, которая проходит успешно, когда серверы имен провайдера возвращают синтезированный ответ CNAME. Если flattening вашего DNS-провайдера выдает только финальную запись A и не выдает CNAME, проверка CNAME не пройдет. На практике flattening Cloudflare включает CNAME в цепочку ответов для записей, не являющихся корневыми; в корне это зависит от реализации провайдера. Протестируйте с помощью dig CNAME go.example.com через стандартный резолвер, прежде чем делать вывод о наличии ошибки.

Wildcard TLS - это HTTP-01, а не DNS-01. Elido не выпускает wildcard-сертификаты (*.go.example.com) через стандартный автоматизированный процесс - согласно RFC 8555 §8.4, wildcard-сертификаты требуют проверки DNS-01, что подразумевает доступ на запись в DNS-зону. Elido не управляет вашей DNS-зоной. Функция wildcard-домена на тарифе Business означает, что один CNAME покрывает маршрутизацию для всех поддоменов, но каждое имя хоста (client1.go.example.com, client2.go.example.com) получает свой собственный сертификат, выпущенный через HTTP-01 при первом запросе, а не один общий wildcard-сертификат. Операционный результат тот же: поддомены работают автоматически. Хранилище сертификатов растет пропорционально.

Удаление CNAME после верификации. Если ваша команда по работе с DNS удалит CNAME во время миграции или очистки, периодическая проверка работоспособности domain-manager обнаружит отсутствие записи и переведет домен в статус degraded. Вы получите уведомление; есть льготный период до приостановки работы домена. Восстановите CNAME, и проверка работоспособности автоматически вернет домен в статус активного.

---

How this differs from Bitly and Rebrandly#

Настройка кастомного домена в Bitly требует загрузки TLS-сертификата или использования их управляемого процесса выпуска сертификатов, который на старых тарифных планах включает этап ручного запроса. Уровень автоматизации зависит от вашего тарифного плана Bitly; корпоративные аккаунты получают более автоматизированный путь.

Процесс настройки в Rebrandly отполирован - их мастер онбординга предоставляет инструкции по CNAME для конкретных провайдеров и проверяет распространение прямо в браузере. Базовый механизм TLS основан на CloudFront: Rebrandly использует функцию кастомных доменов AWS CloudFront, что означает, что центр сертификации и жизненный цикл сертификатов управляются AWS ACM. Это работает хорошо, но означает, что трафик вашего кастомного домена по умолчанию направляется через инфраструктуру AWS в регионе US-East, что важно, если вы оцениваете соответствие требованиям ЕС по хранению данных (см. Elido vs Rebrandly для полного сравнения по резиденству данных).

Подход Elido - Caddy on-demand TLS с барьером авторизации domain-manager - сохраняет полный жизненный цикл сертификатов внутри системы, работает идентично для self-hosted развертываний и не создает зависимости от каких-либо сторонних CDN для управления сертификатами. Стоимость задержки при первом запросе (2–3 секунды для проверки ACME) является компромиссом; последующие запросы не несут никаких накладных расходов.

---

Как только верификация завершится, создайте ссылку на своем кастомном домене, передав domain_id в вызове создания ссылки, или выберите его в селекторе доменов в панели управления или мобильном приложении. Ссылка сразу же станет доступна по адресу https://go.example.com/<slug> с действующим сертификатом.

Дополнительное чтение: Custom domain short links: DNS, TLS, and what runs at the edge охватывает всю архитектуру, включая механику кэширования на edge, лимиты запросов и режимы отказов в продакшене. Полное руководство по настройке домена, включая рекомендации по CAA и справочник API, находится по адресу /docs/guides/custom-domains.

---

Мариус Фосс занимается DevRel + edge infra в Elido. Он отвечает за сервисы edge-redirect и domain-manager.

Related on the blog#

• Hitting p95 < 15ms for redirects from FRA, ASH, and SGP
• Set up branded short links: pick a domain, ship in an afternoon
• Deep links for mobile apps without an SDK
• EU data residency for marketing tools: what your DPO actually asks