Усунення проблем із верифікацією DNS

Коли ви додаєте власний домен, Elido опитує DNS кожні 30 секунд у пошуках записів, які ми просили вас створити. Зазвичай верифікація завершується протягом 60 секунд. Якщо це займає більше часу, скористайтеся цим чеклістом — він охоплює найпоширеніші помилки.

Переконайтеся, що записи існують за межами вашої мережі#

Першим кроком перевірте, чи видно записи публічно, а не лише у вашого реєстратора.

dig links.acme.com CNAME +short
# expected: <something>.elido.me.

Для apex-домену:

dig acme.link A +short
# expected: 2 A records (Hetzner FRA + OVH FRA)

dig acme.link AAAA +short
# expected: IPv6 from one of those PoPs

Якщо dig нічого не повертає, зміни ще не розповсюдилися у реєстратора — або, що буває частіше, запис було збережено з друкарською помилкою.

Типові помилки при написанні#

Порівняйте значення запису з точним значенням, яке Elido показав вам у розділі Settings → Domains → [домен] → DNS records. Найпоширеніші помилки:

Крапка в кінці. Деякі реєстратори вимагають <target>.elido.me. (з крапкою в кінці); деякі додають її автоматично. Якщо вставити <target>.elido.me. у реєстратора, який додає її сам, вийде <target>.elido.me.. — це невірно. Спробуйте без крапки в кінці.
Hostname замість FQDN у полі Name. Для links.acme.com деякі реєстратори очікують links у полі Name, а не links.acme.com. Якщо ви ввели повне FQDN, ви фактично створили links.acme.com.acme.com.
Невірний тип запису. Для піддомену потрібен CNAME. Для apex-домену потрібен A (або ALIAS). Якщо ваш реєстратор не підтримує apex CNAME flattening, перейдіть на A-записи — ми надаємо обидва варіанти в панелі інструкцій DNS.

Apex-домени (кореневі зони)#

Згідно зі специфікацією DNS, записи CNAME заборонені в apex. Якщо ви використовуєте acme.link (а не links.acme.com), у вас є три варіанти:

Використовуйте два A-записи, які ми надаємо. Працює скрізь.
Використовуйте ALIAS / ANAME, якщо ваш реєстратор це підтримує (Cloudflare, DNSimple, easyDNS). Він автоматично перетворюється на потрібні A-записи.
Замість цього оберіть піддомен. go.acme.com або links.acme.link — це простіше і краще для CDN, ніж використання apex-домену.

Проксі Cloudflare (помаранчева хмара)#

Якщо ваш домен знаходиться за проксі Cloudflare (увімкнена помаранчева хмара), верифікація DNS все одно працюватиме, але випуск TLS-сертифіката не вдасться. Cloudflare сам термінує TLS, тому наш Caddy ніколи не «бачить» відвідувача і не може випустити сертифікат.

Вимкніть помаранчеву хмару (off, DNS only / сіра хмара). Cloudflare працюватиме лише як авторитарний DNS; ми беремо на себе проксіювання.

Якщо вам дійсно потрібен рівень захисту від DDoS від Cloudflare, використовуйте Cloudflare Origin CA certificate та завантажте його в Elido у розділі Settings → Domains → [домен] → Custom certificate.

Записи CAA#

Якщо ваш домен має записи CAA, вони повинні дозволяти Let's Encrypt:

dig acme.link CAA +short
# if the result has any lines, letsencrypt.org must be one of them

Якщо ви бачите 0 issue "letsencrypt.org" у виводі, все гаразд. Якщо ви бачите записи CAA лише для інших центрів сертифікації (CA), додайте запис для Let's Encrypt:

acme.link.    CAA  0 issue "letsencrypt.org"

Невідповідність DNSSEC#

Якщо у вашого реєстратора увімкнено DNSSEC, але записи DS було опубліковано некоректно, публічні резолвери повертатимуть SERVFAIL замість ваших записів. Запустіть:

dig +trace links.acme.com

Якщо трасування закінчується на SERVFAIL, виправте DNSSEC у вашого реєстратора, перш ніж продовжувати — зазвичай це робиться шляхом вимкнення DNSSEC, очікування протягом години та повторного ввімкнення з правильними записами DS.

Періодичність опитування верифікації#

Ми опитуємо DNS кожні 30 секунд протягом першої години після додавання домену, потім кожні 5 хвилин протягом наступних 24 годин, і далі щогодини. Ви можете натиснути Verify now у будь-який час, щоб ініціювати негайну перевірку.

Якщо ваш домен залишається в статусі Pending протягом 24 годин, а dig ззовні вашої мережі показує правильні записи, натисніть Verify now один раз — іноді наш кешований негативний результат з етапу ранньої пропагації може зберігатися.

Як виглядає статус «верифіковано, але немає TLS»#

Якщо DNS верифіковано, але домен показує «TLS pending» більше ніж 10 хвилин, у Caddy виникли проблеми з Let's Encrypt. Можливі причини:

Записи CAA (див. вище).
Обмеження частоти запитів (Rate-limiting) від Let's Encrypt (50 сертифікатів на тиждень на зареєстрований домен). Це трапляється лише при дуже масових розгортаннях.
Виклик TLS-ALPN блокується вищестоящим фаєрволом. Відкрийте порт 443 для наших ingress IP-адрес (перелічених на нашій сторінці довіри).

Усунення несправностей#

Верифікація працює з мого ноутбука, але не з панелі керування. Ваш ноутбук використовує локальний DNS-резолвер; наш верифікатор використовує публічні резолвери (1.1.1.1, 8.8.8.8). Якщо оновлення ще не розповсюдилося глобально у реєстратора, публічні резолвери можуть ще не бачити запис. Використовуйте dig @1.1.1.1 links.acme.com, щоб підтвердити те, що бачимо ми.

Записи виглядають правильними, але Verify продовжує видавати помилку. Знизьте TTL записів до 300 секунд і зачекайте 10 хвилин. Високі значення TTL роблять негативне кешування тривалим.

Apex CNAME flattening було увімкнено, але верифікація не вдалася. Cloudflare робить flattening під час запиту, але лише для запитів через резолвери Cloudflare. Публічні резолвери бачать CNAME і відхиляють його. Перейдіть на A-записи явно.