Брендоване коротке посилання - це, по суті, два елементи інфраструктури, з’єднані разом: DNS-запис, який повідомляє інтернету, що ваш піддомен знаходиться тут, і TLS-сертифікат, який підтверджує легітимність HTTPS-з’єднання. Жоден із них не є складним сам по собі. Цікаве питання полягає в тому, що працює на межі (edge) після розв’язання перенаправлення - як платформа, що обслуговує тисячі власних доменів клієнтів, випускає сертифікати за запитом, уникає лімітів Let's Encrypt, дотримується бюджету затримки p95 менше 15 мс і плавно відновлюється, коли команда DNS клієнта видаляє свій CNAME посеред кампанії.
Саме про це цей допис.
TL;DR#
- Верифікація DNS - це челендж
CNAMEабоTXT; випуск TLS відбувається за запитом через ACME, що запускається під час першого запиту на нове ім’я хоста. - Let's Encrypt встановлює ліміт у 50 сертифікатів на зареєстрований домен на тиждень - це означає, що при масштабуванні вам потрібен окремий зареєстрований домен для кожного клієнта, а не піддомени одного
elido.me. - Сертифікати ECDSA P-256 суттєво швидші за RSA-2048 на рівні TLS-handshake; Elido випускає P-256 для кожного власного домену.
- Три речі регулярно ламають налаштування власних доменів у продакшені: затримка розповсюдження DNS, застарілі записи CAA та видалення клієнтами власного
CNAME. Кожна з них має конкретний шлях відновлення.
Дві частини сервісу скорочення посилань на власних доменах#
Короткі посилання на власних доменах вимагають двох речей від вас, власника домену, і двох речей від платформи.
Від вас: зміна DNS (запис CNAME або ALIAS, що вказує ваш піддомен на edge платформи) та підтвердження власності (зазвичай запис DNS TXT або челендж CNAME, який дозволяє платформі переконатися, що ви контролюєте домен, перш ніж вона погодиться його обслуговувати).
Від платформи: правило маршрутизації, яке розпізнає ваше ім’я хоста і знає, з якого робочого простору обслуговувати посилання, та TLS-сертифікат, виданий для вашого імені хоста, щоб браузери показували зелений замок замість попередження.
Elido обробляє останні дві частини за допомогою сервісу під назвою наш сервіс валідації доменів, який відповідає за верифікацію DNS, випуск сертифікатів та оновлення таблиці маршрутизації. Він взаємодіє з наш edge для TLS та з наш API для мапування робочих просторів. Бінарний файл на edge - той самий, що має бюджет затримки sub-10ms у регіоні (p50) - нічого не знає про випуск сертифікатів; усе це відбувається до шляху запиту.
Процес верифікації простий. Ви додаєте CNAME зі свого піддомену на b.elido.me (рівень Business), потім додаєте запис TXT, наприклад _elido-verify.acme.example.com = "ws_abc123", щоб довести, що ви володієте доменом. наш сервіс валідації доменів опитує запис TXT, підтверджує його, позначає домен як верифікований і реєструє його в наш edge. Перший HTTPS-запит до acme.example.com запускає випуск TLS за запитом - про це трохи згодом.
DNS: CNAME проти ALIAS проти A#
Тип DNS-запису, який ви можете використовувати, залежить від того, який піддомен ви делегуєте.
CNAME працює для будь-якого піддомену, що не є apex. links.example.com CNAME b.elido.me. - це канонічне налаштування. RFC 1034 §3.6.2 забороняє записи CNAME в apex зони (голий example.com), оскільки вони конфліктують із записами SOA та NS, які мають там існувати. Майже кожен реєстратор та провайдер DNS дотримується цього правила.
ALIAS / ANAME - це нестандартне розширення, яке впроваджують кілька провайдерів DNS (Route 53 ALIAS, Cloudflare CNAME flattening, DNSimple ALIAS), щоб вирішити саме проблему apex. Синтаксично вони поводяться як CNAME, але за лаштунками розв’язуються в записи A/AAAA, тому сервери імен провайдера DNS «сплющують» пошук перед його публікацією. Якщо вам обов’язково потрібно, щоб example.com (не www.example.com) перенаправляв, ALIAS - ваш єдиний варіант, сумісний зі специфікацією DNS. Перевірте документацію свого провайдера DNS - вони не є взаємозамінними, і назва функції може відрізнятися.
Запис A, що вказує безпосередньо на IP Elido, - це крайній захід. IP-адреси можуть змінюватися, коли ми додаємо POP або змінюємо адресу edge-кластера, і ми не вважаємо IP-адреси edge стабільним API-інтерфейсом. Якщо ви використовуєте запис A сьогодні, перейдіть на CNAME або ALIAS.
Ще одна річ, яку часто пропускають оператори: перенаправлення з apex часто конфліктують із DNS для електронної пошти. Записи MX, _dmarc, _domainkey та SPF TXT - усі вони знаходяться в apex або під ним. ALIAS в apex не конфліктує з ними - це різні типи записів - але деякі реалізації ALIAS у провайдерів DNS мають недокументовані обмеження щодо співіснування записів в apex. Протестуйте це, перш ніж запускати кампанію.
TLS: ACME, ліміти запитів та патерн випуску за запитом#
Кожен власний домен отримує власний сертифікат. Ми не використовуємо wildcard-сертифікати для доменів клієнтів, оскільки вони вимагають челенджу DNS-01 згідно з RFC 8555 §8.4, що означало б, що нам потрібно контролювати DNS-зону кожного домену клієнта - а ми цього не робимо. Челенджі HTTP-01 простіші (вони вимагають лише доступності по HTTP) і покривають сертифікати для окремих імен хостів. Ми використовуємо HTTP-01 для кожного власного домену.
Центром сертифікації є Let's Encrypt. Їхні ліміти запитів - це основне операційне обмеження, яке вам потрібно розуміти: 50 сертифікатів на зареєстрований домен на тиждень, де «зареєстрований домен» - це eTLD+1 (частина відразу над публічним суфіксом - example.com для links.example.com). Повторне оновлення сертифікатів не враховується в цей ліміт, але кожен новий домен - так.
Це має важливий наслідок для мультитенантних платформ. Якщо ви дозволите всім своїм користувачам створювати власні домени на базі *.yourbrand.com, ваш бюджет у 50 сертифікатів на тиждень буде спільним для всіх цих піддоменів yourbrand.com. При будь-якому значущому масштабі ви досягнете ліміту. Правильна архітектура - і та, яку Elido використовує для піддоменів власних рівнів, - полягає в тому, щоб кожен верифікований власний домен клієнта був піддоменом їхнього власного зареєстрованого домену (links.example.com), щоб ліміт запитів застосовувався до кожного клієнта окремо, а не до платформи в цілому.
Випуск TLS за запитом - це те, як наш edge справляється з обсягом. Замість того, щоб попередньо випускати сертифікати для кожного верифікованого домену до появи будь-якого трафіку, наш edge випускає сертифікат під час першого запиту до цього імені хоста. наш edge's on-demand 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-handshake#
Після випуску сертифіката вартість кожного запиту складається з TLS-handshake та логіки перенаправлення.
Повний TLS 1.3 handshake - це 1 RTT. Від європейського клієнта до нашого POP у регіоні ЄС це приблизно 10–20 мс залежно від міста. Відновлення сесії TLS 1.3 (тікети або ідентифікатори сесій) скорочує наступні з’єднання до 0-RTT або 0.5-RTT для даних - клієнт може надсилати дані програми в першому пакеті. Для коротких посилань, де HTTP-запит крихітний, а відповідь - це 302 із заголовком Location, відновлені сесії здаються майже миттєвими з точки зору клієнта.
Алгоритм сертифіката має значення. Сертифікати ECDSA P-256 мають підпис розміром близько 70 байт; сертифікати RSA-2048 мають підпис приблизно 256 байт плюс значно більший публічний ключ. На повільному мобільному з’єднанні різниця в байтах незначна, але вартість процесора для перевірки підпису RSA - ні: перевірка підпису RSA-2048 займає приблизно в 30–50 разів більше циклів процесора, ніж перевірка підпису ECDSA P-256 при еквівалентному рівні безпеки. Для edge, що обслуговує тисячі одночасних з’єднань, ця різниця в ресурсах процесора підсумовується. Elido випускає P-256 для всіх сертифікатів власних доменів. Аналіз Cloudflare щодо ECDSA проти RSA у продакшені приходить до того ж висновку, і його варто прочитати, якщо ви керуєте власним термінуванням TLS.
Після handshake саме перенаправлення потрапляє на «гарячий» шлях: пошук у LRU-кеші всередині процесу (L1), перехід до in-memory кеш (L2), якщо не знайдено, і перехід до наш API через gRPC як останній засіб. При попаданні в кеш L1 - що становить переважну більшість трафіку після того, як посилання стає «прогрітим», - перенаправлення виконується менш ніж за 5 мс p50, від початку до кінця на edge, не враховуючи handshake. Бюджет p95 у 15 мс враховує попадання в L2 та невелику частку «холодного» трафіку. Дивіться глибоке занурення в розумні посилання для ознайомлення з повною архітектурою кешу та механікою інвалідації.
Що ламається в продакшені#
Налаштування власних доменів виходять з ладу передбачуваними способами. Ось три, які ми бачимо найчастіше, і що робити в кожному випадку.
Затримка розповсюдження DNS. Ви додаєте CNAME, верифікуєте в панелі керування, але посилання все одно не відкривається у деяких користувачів. Значення DNS TTL для багатьох зон, керованих реєстраторами, за замовчуванням становить 3600 секунд - ціла година потенційної неактуальності. Статус домену в панелі керування відображає, чи бачить наш сервіс валідації доменів правильну відповідь DNS із регіону ЄС. Якщо він показує «верифіковано», але користувачі в Азійсько-Тихоокеанському регіоні все ще отримують стару відповідь, вони потрапляють на резолвер, який закешував попередню відповідь. Тут немає короткого шляху; потрібно чекати, поки 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 apex. Помилка в ACME-відповіді - urn:ietf:params:acme:error:caa; рішення полягає в тому, щоб додати links.example.com CAA 0 issue "letsencrypt.org" (або видалити обмеження CAA в apex, якщо це відповідає вашій політиці безпеки). Кінцева точка статусу наш сервіс валідації доменів повертає помилки CAA у своєму тілі помилки, щоб ви могли діагностувати це, не переглядаючи логи наш edge.
Клієнт видаляє CNAME посеред кампанії. Це найнеприємніше. Адміністратор DNS на стороні клієнта видаляє або змінює CNAME - можливо, в рамках міграції домену, можливо, випадково - і кожне перенаправлення з цього власного домену починає видавати помилку, бо наш edge більше не може його обслуговувати, або, що ще гірше, оновлення TLS-сертифіката тихо провалюється протягом наступного 60-денного вікна оновлення, і сертифікат стає недійсним. наш сервіс валідації доменів в Elido запускає періодичну перевірку стану DNS для всіх верифікованих доменів і позначає домен як degraded, коли CNAME більше не вказує на очікувану ціль. Власник робочого простору отримує сповіщення; є 7-денний пільговий період, перш ніж домен буде переведено в статус suspended. Протягом пільгового періоду запити продовжують обслуговуватися за останнім дійсним сертифікатом. Відновлення: відновіть CNAME, дочекайтеся розповсюдження, і статус домену автоматично повернеться до активного під час наступного циклу перевірки стану (запускається кожні 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 для глибоких посилань у мобільних додатках на власному домені.
Маріус Фосс - DevRel + edge infra в Elido. Він відповідає за сервіси наш edge-сервіс та наш сервіс валідації доменів.
Схожі дописи в блозі#
- Досягнення p95 < 15 мс для перенаправлень із регіон ЄС, US East та Азійсько-Тихоокеанський регіон
- Налаштування брендованих коротких посилань: виберіть домен, запустіть за півдня
- Глибокі посилання для мобільних додатків без SDK
- Резидентність даних у ЄС для маркетингових інструментів: про що насправді запитує ваш DPO
Спробуйте Elido
Вставте URL - отримайте коротке посилання
Без реєстрації. Посилання живе 30 днів. Зареєструйтесь, щоб зберегти назавжди.
Безкоштовно, без реєстрації · 2 на день