dxdt.blog: занимательный интернет-журнал

Благодаря влиянию ACME и Let’s Encrypt, сейчас стала очень популярной схема подтверждения права управления доменом (DCV) через DNS, но при помощи размещения CNAME-записей. Речь про запрос TLS-сертификатов средствами автоматизации – скриптами (acme.sh, certbot и др.). Напомню, что DCV здесь состоит в проверке размещения TXT-записи с кодом подтверждения под заданным именем в DNS-зоне (это метод DNS-01). ACME использует специальный префикс: _acme-challenge.

Однако CNAME – это не TXT-запись, а способ перераспределить проверку в другую DNS-зону (см. детали ниже). Вообще, протокол ACME в данном сценарии не требует ни использования, ни даже поддержки CNAME. Но такая поддержка массово используется, и её сейчас принято обосновывать тем, что можно, мол, “не предоставлять доступ к исходной зоне скриптам автоматизации”. Использование CNAME – вообще плохая практика, а особенно плохая практика – это использование CNAME в процессе DCV. Что, конечно, не мешает массовому распространению. Вообще, с подобным использованием CNAME, – то есть, в DCV, – связана пара занятных технических моментов, о которых забывают.

Момент первый: постоянно путают синоним (алиас) и основное имя в CNAME. Дело в том, что CNAME – это Canonical NAME (каноническое имя), и каноническим является именно значение записи, а не имя-носитель. Имя-носитель – это и есть алиас, что бы там ни писали в инструкциях к средствам автоматизации ACME. Если для example.com в CNAME-записи указано 1.2.3mega-blah-blah.example.net, то вот это вот 1.2.3mega-blah-blah.example.net и есть основное имя. При использовании в ACME предлагается настроить CNAME для префикса _acme-challenge. Например, _acme-challenge.example.com в 1.2.3mega-blah-blah.example.net. Но и тут алиасом, в терминах DNS, будет _acme-challenge.example.com, префикс не влияет на отношение значений записей. Такова семантика CNAME.

Соответственно, получается, что проверка проводится для другого имени, не для того, которое указано в ACME-аккаунте при запросе DCV. Сертификат, в итоге, выпускается для одного имени, а проверка – фактически пройдена для совсем другого: для той зоны, которая назначена канонической при помощи CNAME. Дело в том, что CNAME-запись, при интерпретации резолвером, должна приводить к перезапуску процесса рекурсивного опроса для канонического имени, то есть, для значения из CNAME. Да, может показаться, что это технические придирки: всё равно же CNAME-запись должна быть размещена в исходной зоне, совпадающей с именем из DCV. Но нет, не так тут всё просто: CNAME может показывать на совсем другую зону, контроль над которой позволяет проходить DCV и выпускать сертификаты для прочих имён, в том числе, алиасов может быть много – это каноническое имя, по определению, одно. Если домен канонического имени (того, куда указывает CNAME) будет утрачен, переделегирован-перехвачен, или ещё что-то, то это административное изменение прямо коснётся авторизации TLS-сертификата для исходной зоны-алиаса. Происходит подмена самой сути DCV.

Естественно, можно рассуждать иначе: если утрачено каноническое имя, то нужно удалить CNAME-запись в алиасе; тем более, что так как сертификаты сейчас “короткие”, утрата канонического имени обнаружится быстро. Это верно. Более того, имея контроль над исходной зоной (в которой CNAME) – можно будет попробовать отозвать сертификаты для этой зоны, если такие были выпущены при помощи подхвата CNAME. (Один из штатных способов отзыва сертификата в ACME – прохождение DCV для имён из сертификата; но нужно предъявить сам сертификат, и должно всё сойтись по составу имён – то есть, если в подставном сертификате указана ещё какая-то зона, то могут быть проблемы с отзывом.) Однако это всё только теоретические рассуждения, в стиле “как должно быть”, а на практике, как говорится: ну, на практике-то – и про CNAME-зоны забывают, и про обновление имён, и про отзыв.

Момент второй: реальный доступ к зоне. Из первого момента, с каноническим именем, легко выводится этот второй: да, использование CNAME предлагают в качестве решения проблемы “расползания реквизитов доступа”. Мол, не хочется давать скриптам ACME доступ к редактированию нашей важной доменной зоны, поэтому пропишем CNAME и дадим доступ в другую зону, не такую важную. Но, как бы, смысл DCV – проверка права управления доменной зоной, а тут – это право управления прямо предлагают не выдавать, а подменить саму зону средствами DNS. Опять же, такая трактовка – не “перегиб”: дело в том, что управление зоной должно, если по-хорошему, подтверждаться при каждом выпуске сертификата (ну, хорошо, с некоторым интервалом по времени действия успешной проверки), а CNAME, направленная на каноническое имя – это долгий и универсальный вариант, не привязанный к выпуску сертификата вовсе. Для чего, собственно, использование CNAME и затевается. Опять противоречие.

Кстати, тут полезно вспомнить, что есть и суперновая версия DNS-проверки в ACME – с “постоянной” привязкой ACME-аккаунта к имени: вот где совсем не место CNAME (но черновик RFC пока что их не запрещает явно).

CNAME-записи – одни из самых сложных по поведению в DNS, а их использование – источник неожиданных проблем. В случае DCV, семантика и принципы интерпретации CNAME вообще противоречат основной логике проверки права управления через DNS. Что касается других решений: во-первых, ACME-префикс можно делегировать на отдельные NS, без всяких CNAME; во-вторых, для размещения TXT-записей вовсе не обязательно передавать полные права управления DNS-зоной каким-то скриптам. Это всё решения на стороне, заказывающей DCV. Но самое правильное, конечно, это не следовать CNAME при проверке DCV на стороне систем УЦ.

Адрес записки: https://dxdt.blog/2026/04/15/17977/