TLS для власного домену коротких посилань за 5 хвилин

Налаштування власного домену з HTTPS потребує одного запису TXT, одного запису CNAME і короткого очікування. Ви додаєте hostname в Elido, копіюєте два DNS-значення, які він дає, і TLS-сертифікат видається автоматично, коли хтось уперше відкриє посилання на цьому домені. Повільна частина - поширення DNS, яким ви керуєте через TTL. Ця стаття проходить п'ять кроків, а потім пояснює механізм, щоб ви знали, куди дивитися, коли якийсь крок застрягає.

Усе нижче перевірено за поточним кодом і дашбордом Elido станом на 2026-10-09. Де пов'язана функція ще не збудована, стаття про це каже.

Чому TLS важливий на короткому посиланні

Коротке посилання - це редирект, і відповідь редиректу є всім корисним навантаженням. 301 або 302 із заголовком Location несе ваш URL призначення. Якщо перший запит іде по звичайному HTTP, будь-хто на мережевому шляху може прочитати це призначення, перш ніж браузер за ним піде.

QR-коди роблять це гіршим. Людина, що сканує код на вітрині чи плакаті, не має попередніх стосунків з URL, тож адресний рядок - єдиний сигнал довіри, який вона отримує. Попередження браузера при скануванні - найгірше можливе перше враження, а за тираж ви вже заплатили.

На спільних коротких доменах Elido сертифікат належить Elido, тож замок справжній, але ім'я на ньому не ваше. На go.acme.com ім'я ваше. Основи DNS і TLS, що за цим стоять, дивіться в ключовій статті про короткі посилання на власному домені.

Крок 1: оберіть hostname

Оберіть короткий піддомен, який ви контролюєте і не використовуєте ні для чого іншого: go.example.com, links.example.com чи подібний. Префікс з'являється в кожному посиланні, яке ви надсилаєте, тож коротший краще.

Використовуйте піддомен, а не голий корінь. RFC 1034, розділ 3.6.2 каже, що ім'я з CNAME не може містити інших даних, а корінь зони завжди містить записи SOA і NS, тож CNAME там не дозволений. Деякі DNS-провайдери імітують його через ALIAS або сплощені записи, але ті відповідають IP-адресами замість CNAME. Верифікація Elido питає саме про CNAME, тож сплощений корінь не пройде.

При реєстрації імені діють ще два правила. Hostname має бути повним доменним іменем у нижньому регістрі, а імена під elido.me або elido.app зарезервовані.

Крок 2: додайте домен в Elido

Відкрийте Domains на бічній панелі дашборда, введіть hostname і натисніть Add domain. Позначте прапорець wildcard, лише якщо хочете, щоб працював кожен піддомен цього імені, як у *.go.example.com. Зазвичай це не потрібно. Після цього Elido показує два DNS-записи з кнопкою копіювання біля кожного.

Той самий крок через 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}'

Виклик потребує ролі, що може керувати доменами. Новий домен повертається зі статусом pending, verify_token та об'єктом instructions із точними значеннями записів:

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

Власні домени потребують платного плану. Спробуйте зареєструвати домен на безкоштовному робочому просторі, понад кількість доменів вашого плану або на призупиненій чи скасованій підписці - і API відповість 402. Цей код я б обробляв першим у будь-якому скрипті онбордингу, бо саме на нього клієнт натрапляє в перший же день. Дублікат hostname отримує 409. Агенціям із багатьма клієнтськими доменами варто прочитати сторінку рішень для агенцій про модель робочих просторів.

Крок 3: опублікуйте два DNS-записи

Додайте обидва записи в свого DNS-провайдера точно так, як показано:

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

CNAME спрямовує трафік на Elido. Запис TXT доводить, що зона ваша. Потрібні обидва, а значення TXT має точно збігатися з токеном.

Для wildcard-реєстрації CNAME стає *.go.example.com, а запис TXT лишається на _elido-verify.go.example.com, на батьківському імені без зірочки.

Задайте TTL 300 секунд для обох записів, якщо провайдер дозволяє. У багатьох зонах типове значення 3600 секунд, і довгий TTL перетворює п'ятихвилинну справу на годинну.

Одна примітка щодо провайдера важливіша за решту. Якщо ви користуєтеся Cloudflare, залиште CNAME у режимі DNS-only. Документація Cloudflare каже, що запис із проксуванням відповідає власними IP-адресами Cloudflare замість вмісту запису (дата звернення 2026-10-09). Тож ім'я з проксуванням ніколи не поверне CNAME, який шукає Elido, і верифікація не пройде.

Крок 4: дочекайтеся верифікації

Нічого натискати не потрібно. Фоновий воркер усередині API Elido перевіряє кожен домен в очікуванні за таймером, типово кожні 30 секунд, через публічний резолвер Google 8.8.8.8. Він пропускає домен, лише коли виконано обидві умови:

1. Запис TXT на _elido-verify.<hostname> містить точно verify=<token>.
2. Hostname має CNAME, що резолвиться на edge-ціль Elido.

Коли обидві умови виконано, статус змінюється на verified. Опитуйте його самі, якщо скриптуєте налаштування:

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

Щоб не чекати наступного такту, надішліть POST .../domains/42/verify. Він повертає 202 і переносить домен на початок черги. Домен, що залишається в очікуванні 24 години, позначається failed з причиною «verification timeout», а той самий виклик verify повертає домен у failed назад у pending, щоб ви могли повторити після виправлення DNS.

Якщо застрягло, запитайте записи так само, як це робить перевірка:

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

Перша команда має вивести "verify=<your-token>". Друга - edge.elido.me., разом із кінцевою крапкою.

Крок 5: перший запит видає сертифікат

Щойно статус стає verified, вам більше нічого робити. Elido не видає сертифікати наперед. TLS-шар видає його на вимогу, коли браузер уперше відкриває TLS-з'єднання для вашого hostname.

Перш ніж просити що-небудь у Let's Encrypt, edge викликає перевірку авторизації в API Elido. Відповідь «так» лише якщо hostname у стані verified або active, або якщо він підпадає під верифіковану wildcard-реєстрацію. Будь-яка інша відповідь, зокрема невідоме ім'я, відхиляє handshake, і сертифікат не запитується. Саме ця перевірка не дозволяє стороннім спрямувати мільйон hostname на Elido й вичерпати ліміти центру сертифікації.

Коли перевірка пройдена, видача використовує виклик HTTP-01 з RFC 8555: центр сертифікації запитує токен на /.well-known/acme-challenge/ вашого hostname по звичайному HTTP, edge відповідає, і сертифікат видається та кешується. Перший відвідувач на мить чекає на це. Наступні запити використовують кешований сертифікат.

Практична звичка: відкрийте https://go.example.com самі одразу після верифікації, щоб сертифікат існував до того, як першим запитом стане клієнт або скан QR.

Передайте id домену як domain_id, коли створюєте посилання. Посилання працює на https://go.example.com/<slug> одразу. Сторінка Domains також показує кліки за 30 днів на кожен hostname. Повний довідник, зокрема настанови щодо CAA, - у посібнику з власних доменів, а огляд продукту - на сторінці функції власних доменів.

Що означають значення статусу

У поточній збірці здоровий домен залишається в verified. Значення active існує в моделі даних і у фільтрі дашборда, шлюз сертифікатів приймає обидва, але поки що ніщо не переводить домен у нього.

Типові підводні камені

Записи CAA, що виключають Let's Encrypt. Запис CAA обмежує, які центри можуть видавати сертифікати для імені, і успадковується піддоменами (дата звернення 2026-10-09). Якщо у вашій зоні є example.com CAA 0 issue "digicert.com", видачу для go.example.com буде відхилено. Додайте go.example.com CAA 0 issue "letsencrypt.org" або розширте запис на вершині.

Проксі чи CDN перед CNAME. Помаранчева хмарка Cloudflare - найчастіший випадок, розглянутий у кроці 3. Будь-який шар, що відповідає на DNS чи HTTP замість вас, ламає і перевірку CNAME, і виклик HTTP-01.

Wildcard - це не wildcard-сертифікати. Згідно з документацією Let's Encrypt щодо типів викликів, HTTP-01 не може видавати wildcard-сертифікати, а DNS-01 потребує доступу на запис до вашої зони (дата звернення 2026-10-09). Тож wildcard-реєстрація покриває маршрутизацію для кожного піддомену, але client1.go.example.com і client2.go.example.com отримують власні сертифікати при першому використанні. Let's Encrypt обмежує нові сертифікати на зареєстрований домен до 50 кожні 7 днів (дата звернення 2026-10-09), тож підключення сотень нових піддоменів за один тиждень потребує планування.

Пізніше видалення CNAME. Сьогодні DNS-перевірка виконується лише поки домен в очікуванні. Щойно домен верифіковано, Elido його не перевіряє повторно, тож видалений CNAME проявляється як збійні редиректи та збійне оновлення сертифікатів, а не як зміна статусу чи сповіщення. Моніторте запис на своєму боці. Періодична перевірка здоров'я зі станом деградації та пільговим періодом запланована, але не збудована.

---

Marius Voß - DevRel + edge infra в Elido. Він відповідає за шлях редиректу та потік власних доменів.

Читайте також у блозі

• Короткі посилання на власному домені: DNS, TLS і що працює на edge
• Налаштування брендованих коротких посилань: оберіть домен і запустіться за вечір
• Як тримати p95 редиректів нижче 15 мс
• Elido проти Rebrandly
• Чи шкодять скорочувачі URL SEO?