Брендированная короткая ссылка - это, по сути, две части инфраструктуры, соединенные вместе: запись DNS, которая сообщает интернету, где находится ваш поддомен, и сертификат TLS, подтверждающий легитимность HTTPS-соединения. По отдельности в них нет ничего сложного. Интересный вопрос заключается в том, что происходит на грани (edge) после разрешения перенаправления - как платформа, обслуживающая тысячи пользовательских доменов, выпускает сертификаты по запросу, избегает ограничений Let's Encrypt, укладывается в 15 мс p95 задержки и изящно восстанавливается, когда команда DNS клиента случайно удаляет CNAME в середине кампании.
Именно об этом пойдет речь в данном посте.
TL;DR#
- Верификация DNS выполняется через проверку CNAME или TXT; выпуск TLS происходит через ACME по запросу, инициируясь при первом обращении к новому хосту.
- Let's Encrypt ограничивает выпуск 50 сертификатами на зарегистрированный домен в неделю - это значит, что при масштабировании вам нужен отдельный зарегистрированный домен для каждого клиента, а не поддомены одного
elido.me. - Сертификаты ECDSA P-256 существенно быстрее RSA-2048 на уровне TLS-рукопожатия; Elido выпускает P-256 для каждого собственного домена.
- Три вещи регулярно ломают настройки собственных доменов в продакшене: задержка распространения DNS, просроченные записи CAA и удаление CNAME клиентами. Для каждого случая есть конкретный путь восстановления.
Две составляющие сервиса коротких ссылок на собственном домене#
Короткие ссылки на собственных доменах требуют двух вещей от вас, как владельца домена, и двух вещей от платформы.
От вас: изменение DNS (запись CNAME или ALIAS, указывающая ваш поддомен на грань платформы) и подтверждение владения (обычно запись DNS TXT или проверка CNAME, которая позволяет платформе убедиться, что вы контролируете домен, прежде чем она согласится его обслуживать).
От платформы: правило маршрутизации, которое распознает ваше имя хоста и знает, из какого рабочего пространства (workspace) обслуживать ссылки, и сертификат TLS, выданный для вашего имени хоста, чтобы браузеры видели зеленый замок вместо предупреждения.
Elido берет на себя последние две задачи через сервис проверки доменов, который отвечает за верификацию DNS, выпуск сертификатов и обновление таблицы маршрутизации. Он управляет автоматическим TLS по запросу и сопоставлением рабочих пространств. Edge-сервис - тот самый, у которого бюджет задержки в регионе составляет менее 10 мс - ничего не знает о выпуске сертификатов; все это происходит до пути запроса.
Процесс верификации прост. Вы добавляете CNAME от вашего поддомена к b.elido.me (тариф Business), затем добавляете запись TXT вида _elido-verify.acme.example.com = "ws_abc123", чтобы доказать владение доменом. Сервис проверки доменов опрашивает запись TXT, подтверждает ее, помечает домен как верифицированный и регистрирует его для TLS. Первый HTTPS-запрос к acme.example.com инициирует выпуск TLS по запросу - подробнее об этом чуть позже.
DNS: CNAME против ALIAS против A#
Тип DNS-записи, которую вы можете использовать, зависит от того, какой поддомен вы делегируете.
CNAME подходит для любого поддомена, не являющегося апексом (корнем). links.example.com CNAME b.elido.me. - это каноническая настройка. RFC 1034 §3.6.2 запрещает записи CNAME в апексе зоны (просто example.com), потому что они конфликтуют с записями SOA и NS, которые должны там присутствовать. Почти каждый регистратор и DNS-провайдер соблюдают это правило.
ALIAS / ANAME - это нестандартное расширение, которое реализуют несколько DNS-провайдеров (Route 53 ALIAS, Cloudflare CNAME flattening, DNSimple ALIAS) для решения проблемы апекса. Синтаксически они ведут себя как CNAME, но преобразуются в записи A/AAAA «за кулисами», поэтому серверы имен DNS-провайдера «сглаживают» поиск перед публикацией. Если вам обязательно нужно, чтобы example.com (не www.example.com) перенаправлял запросы, ALIAS - ваш единственный вариант, совместимый со спецификацией DNS. Проверьте документацию вашего DNS-провайдера - они не являются взаимозаменяемыми, и название функции может варьироваться.
Запись A, указывающая напрямую на IP Elido - это крайний случай. IP-адреса могут измениться при добавлении новой точки присутствия (POP) или переадресации кластера грани, и мы не рассматриваем IP грани как стабильный API. Если вы используете запись A сегодня, перейдите на CNAME или ALIAS.
Еще одна вещь, которую упускают операторы: перенаправления с апекса часто конфликтуют с почтовым DNS. Записи MX, _dmarc, _domainkey и TXT-записи SPF живут в апексе или под ним. ALIAS в апексе не конфликтует с ними - это разные типы записей - но реализации ALIAS у некоторых DNS-провайдеров имеют недокументированные ограничения на сосуществование записей в апексе. Протестируйте это перед запуском рекламной кампании.
TLS: ACME, лимиты и модель выпуска по запросу#
Каждый собственный домен получает свой сертификат. Мы не используем wildcard-сертификаты для доменов клиентов, так как они требуют проверки DNS-01 согласно RFC 8555 §8.4, а это означало бы, что нам нужно контролировать DNS-зону каждого домена клиента - чего мы не делаем. Проверки HTTP-01 проще (требуют только доступности по HTTP) и покрывают сертификаты для конкретных хостов. Мы используем HTTP-01 для каждого собственного домена.
Центр сертификации - Let's Encrypt. Их ограничения (rate limits) - основной операционный фактор, который вам нужно понимать: 50 сертификатов на зарегистрированный домен в неделю, где «зарегистрированный домен» - это eTLD+1 (example.com для links.example.com). Обновление дубликатов сертификатов не учитывается в этом лимите, но каждый новый домен - учитывается.
Это имеет важное значение для многопользовательских платформ. Если вы позволите всем своим пользователям создавать собственные домены в рамках *.yourbrand.com, ваш бюджет в 50 сертификатов в неделю будет распределяться между всеми этими поддоменами yourbrand.com. При любом значимом масштабе вы достигнете лимита. Правильная архитектура - и та, которую Elido использует для своих собственных поддоменов уровней - заключается в том, чтобы каждый верифицированный собственный домен клиента был поддоменом его собственного зарегистрированного домена (links.example.com), тогда лимит будет применяться к каждому клиенту отдельно, а не ко всей платформе.
Выпуск TLS по запросу (On-demand TLS) - так edge справляется с объемом. Вместо того чтобы заранее выпускать сертификаты для каждого верифицированного домена до появления трафика, сертификат выпускается при первом запросе к этому имени хоста. Автоматический TLS по запросу запрашивает у вышестоящей конечной точки (в нашем случае - сервиса проверки доменов), разрешено ли это имя хоста, перед попыткой выпуска. Если возвращается 200 (домен верифицирован), edge продолжает проверку ACME HTTP-01, получает сертификат, кэширует его и обслуживает запрос. Если имя хоста неизвестно, edge возвращает TLS-оповещение, и соединение разрывается еще до запроса сертификата.
Процесс ACME согласно RFC 8555:
- Edge запрашивает новый заказ у сервера ACME (Let's Encrypt).
- Let's Encrypt отвечает проверкой HTTP-01: «разместите токен по адресу
http://acme.example.com/.well-known/acme-challenge/<token>». - Edge размещает токен в своем обработчике HTTP в памяти и уведомляет Let's Encrypt.
- Let's Encrypt извлекает токен по обычному HTTP (порт 80), проверяет его и выпускает сертификат.
- Edge сохраняет сертификат в своем слое хранения и обслуживает исходный HTTPS-запрос.
Шаги 1–5 добавляют задержку к самому первому запросу с недавно верифицированного домена, обычно 1–3 секунды. Каждый последующий запрос использует закэшированный сертификат без заметных накладных расходов.
Производительность: математика TLS-рукопожатия#
Как только сертификат выдан, стоимость каждого запроса складывается из TLS-рукопожатия и логики перенаправления.
Полное рукопожатие TLS 1.3 занимает 1 RTT. Для европейского клиента до нашей точки присутствия (POP) в регионе ЕС это примерно 10–20 мс в зависимости от города. Возобновление сеанса TLS 1.3 (билеты или идентификаторы сеансов) сводит последующие соединения к 0-RTT или 0.5-RTT для данных - клиент может отправить данные приложения в первом пакете. Для коротких ссылок, где HTTP-запрос крошечный, а ответ - 302 с заголовком Location, возобновленные сеансы кажутся почти мгновенными с точки зрения клиента.
Алгоритм сертификата имеет значение. Сертификаты ECDSA P-256 имеют подпись размером около 70 байт; сертификаты RSA-2048 несут подпись около 256 байт плюс гораздо больший открытый ключ. На медленном мобильном соединении разница в байтах незначительна, но стоимость проверки подписи для CPU - нет: проверка подписи RSA-2048 требует примерно в 30–50 раз больше циклов процессора, чем проверка подписи ECDSA P-256 при эквивалентном уровне безопасности. Для грани, обслуживающей тысячи одновременных соединений, эта разница в нагрузке на CPU накапливается. Elido выпускает P-256 для всех сертификатов собственных доменов. Анализ Cloudflare ECDSA против RSA в продакшене приходит к тому же выводу, и его стоит прочитать, если вы сами управляете терминацией TLS.
После рукопожатия само перенаправление попадает в «горячий путь»: поиск в LRU-кэше внутри процесса (L1), переход к Redis (L2), если запись не найдена, и обращение к api-core через gRPC как к последней инстанции. При попадании в кэш L1 - что составляет подавляющее большинство трафика, как только ссылка «прогрета» - перенаправление разрешается менее чем за 5 мс p50 от начала до конца на грани, исключая рукопожатие. Бюджет 15 мс p95 учитывает попадания в L2 и небольшую долю «холодного» трафика. См. глубокое погружение в умные ссылки для изучения полной архитектуры кэширования и механики инвалидации.
Что ломается в продакшене#
Настройки собственных доменов дают сбои предсказуемым образом. Вот три случая, которые мы видим чаще всего, и что делать в каждом из них.
Задержка распространения DNS. Вы добавляете CNAME, верифицируете в панели управления, а ссылка все равно не открывается у некоторых пользователей. Значения TTL DNS для многих зон, управляемых регистраторами, по умолчанию составляют 3600 секунд - это час потенциальной неактуальности данных. Статус домена в панели управления отражает то, видит ли сервис проверки доменов правильный ответ DNS из региона ЕС. Если там указано «verified», но другие пользователи все еще получают старый ответ, значит, они попадают на резолвер, который закэшировал предыдущий результат. Здесь нет коротких путей; нужно ждать истечения TTL. Решение на будущее - снизить TTL до 300–600 секунд перед внесением изменений, а затем восстановить его.
Просроченные или неверные записи CAA. Certification Authority Authorization (CAA) - это записи, сообщающие центрам сертификации, кому разрешено выпускать сертификаты для домена. Если ваш администратор DNS ранее добавил example.com CAA 0 issue "digicert.com", Let's Encrypt откажется выпускать сертификат для links.example.com, потому что links.example.com наследует политику CAA апекса. В ответе ACME будет ошибка urn:ietf:params:acme:error:caa; решение - добавить links.example.com CAA 0 issue "letsencrypt.org" (или снять ограничение CAA в апексе, если это соответствует вашей политике безопасности). Конечная точка статуса сервиса проверки доменов возвращает ошибки CAA в теле ошибки, так что вы можете диагностировать это, не копаясь в edge-логах.
Клиент удаляет CNAME в середине кампании. Это самый болезненный случай. Администратор DNS на стороне клиента удаляет или изменяет CNAME - возможно, в рамках миграции домена или случайно - и каждое перенаправление с этого собственного домена начинает давать сбой, потому что edge больше не может его обслуживать. Хуже того, продление TLS-сертификата в течение следующего 60-дневного окна завершается неудачей, и срок действия сертификата истекает. Сервис проверки доменов в Elido периодически проверяет состояние DNS всех верифицированных доменов и помечает домен как degraded, когда CNAME больше не указывает на ожидаемую цель. Владелец рабочего пространства получает уведомление; есть 7-дневный льготный период, прежде чем домен будет переведен в статус suspended. В течение льготного периода запросы продолжают обслуживаться с использованием последнего валидного сертификата. Восстановление: верните CNAME, дождитесь распространения, и статус домена автоматически вернется в «active» при следующем цикле проверки состояния (запускается каждые 15 минут).
Краткое руководство#
Вот как выглядит настройка от начала до конца, начиная с чистого листа.
Шаг 1: Добавьте записи DNS. В панели управления вашего DNS-провайдера:
acme.example.com CNAME b.elido.me.
_elido-verify.acme.example.com TXT "ws_01HXK4..."
Значение ws_01HXK4... - это токен верификации вашего рабочего пространства, который отображается в панели управления в разделе Settings → Custom Domains → Add Domain.
Шаг 2: Зарегистрируйте домен через API. Вы также можете сделать это в панели управления, но если вы автоматизируете многопользовательскую настройку - например, агентство подключает нового клиента - 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": "acme.example.com",
"tier": "business"
}'
Ответ содержит verification_token и status со значением pending_verification. Опрашивайте GET /v1/workspaces/{id}/domains/{domain_id} или следите за панелью управления, пока status не перейдет в verified.
Шаг 3: Первый запрос инициирует выпуск сертификата. После верификации любой HTTPS-запрос к acme.example.com инициирует выпуск TLS по запросу, если сертификат еще не закэширован. Этот первый запрос может занять 2–3 секунды, пока завершается обмен ACME. Каждый последующий запрос занимает менее 15 мс p95.
Шаг 4: Создавайте ссылки на собственном домене. Передавайте domain_id при создании ссылок:
curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/links \
-H "Authorization: Bearer $ELIDO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"domain_id": 17,
"slug": "spring-launch",
"destination_url": "https://example.com/landing/spring"
}'
Ссылка начинает работать по адресу https://acme.example.com/spring-launch немедленно. Если вы управляете этой настройкой как инфраструктурой через код, см. пост о провайдере Terraform - elido_custom_domain является источником данных, который вы можете связать с ресурсами elido_link.
Когда не стоит использовать собственный домен#
Не каждая ситуация выигрывает от использования собственного домена, а его добавление сопряжено с затратами на настройку с обеих сторон.
Внутренние инструменты и ссылки для стейджинга. Если на короткую ссылку нажимают только сотрудники вашей компании - внутренние документы, указатели на среду стейджинга, ресурсы в Slack - собственный домен добавляет накладные расходы на управление DNS при нулевой выгоде для бренда. Используйте рабочее пространство на f.elido.me или s.elido.me и двигайтесь дальше.
Одноразовые ссылки для кампаний со сроком жизни 48 часов. Одно только окно распространения DNS может занять час. Если ваша кампания запускается завтра, а записи DNS еще не готовы, собственный домен - это риск. Используйте поддомен платформы, запустите кампанию и добавьте использование собственного домена в план для следующей.
Корпоративные клиенты с SSO, которые еще не утвердили делегирование поддомена. В компаниях со зрелым подходом к ИТ-безопасности делегирование поддомена стороннему SaaS-сервису требует проверки безопасности - иногда официальной оценки рисков. Проверка может занять недели. Если процесс закупки уже находится в длинной очереди на утверждение, не блокируйте сделку из-за настройки собственного домена. Начните с домена платформы; предложите перейти на собственный домен в рамках онбординга после продажи. Elido поддерживает миграцию доменов без поломки существующих ссылок, а на странице решений для агентств можно найти больше информации о white-label конфигурации, которая делает этот переход чистым.
Собственные домены доступны на тарифных планах Business и Enterprise. Уровни Free и Pro используют поддомены, предоставляемые платформой. Если вы оцениваете эту функцию, панель управления позволяет добавить один верифицированный домен на тарифе Pro в качестве ознакомления - проверьте текущее сравнение планов на странице цен для уточнения лимита.
Полное руководство по настройке, включая рекомендации по записям CAA, справочник API для всех конечных точек домена и схему ответа проверки состояния домена, находится по адресу /docs/guides/custom-domains. Страница функций собственных доменов охватывает интеграцию Apple App Site Association и поток Universal Link / App Link для глубоких ссылок в мобильные приложения на собственном домене.
Мариус Фосс (Marius Voß) - DevRel + инфраструктура грани в Elido. Он отвечает за сервисы edge-redirect и domain-manager.
Похожие статьи в блоге#
Попробуйте Elido
Вставьте URL - получите короткую ссылку
Без регистрации. Ссылка живёт 30 дней. Зарегистрируйтесь, чтобы оставить её навсегда.
Бесплатно, без регистрации · 2 в день