Последнее обновление: | Вся документация
CAA – тип записи DNS, с помощью которого владелец сайта может определить Центры сертификации (CAs) для выпуска сертификатов, содержащих конкретные доменные имена. Она была стандартизирована в 2013 году в RFC 6844, чтобы позволить Центру сертификации “уменьшить риск непреднамеренного ошибочного выпуска сертификата”. По умолчанию каждый публичный Центр сертификации имеет право выпускать сертификаты для любого доменного имени в общедоступном DNS при условии, что контроль над этим доменным именем подтвержден. Это означает, что возможный баг в одном из множества проверочных процессов Центров сертификации потенциально может затронуть каждое доменное имя. CAA позволяет владельцам доменов уменьшить этот риск.
Использование CAA
Если вам не нужна CAA, можно ничего не делать (но см. ошибки CAA ниже). Если же вы хотели бы использовать CAA, чтобы ограничить число Центров сертификации, имеющих право выпуска сертификатов для вашего домена, нужно использовать провайдера DNS, который поддерживает настройку записей CAA. Список таких провайдеров можно найти на странице SSLMate’s CAA. Если ваш провайдер нашелся в списке, можно использовать генератор записей SSLMate’s CAA для создания набора записей CAA, перечисляющих центры сертификации, которые вы хотели бы разрешить.
Идентифицирующее доменное имя Let’s Encrypt’s для CAA – letsencrypt.org.
Это официально задокументировано в нашем Положении о практике сертификации (CPS), секция 4.2.1.
Где разместить запись
Можно разместить запись CAA на главном домене или на поддомене любого уровня.
Например, если ваше доменное имя www.community.example.com, вы можете
разместить записи CAA либо для полного имени, либо для community.example.com,
либо для example.com. Центры сертификации будут проверять любую версию
слева направо и остановятся, как только обнаружат любую запись CAA.
Так, к примеру, запись CAA для community.example.com будет приоритетнее,
чем запись для example.com. Большинство использующих записи CAA
устанавливают их для зарегистрированного домена верхнего уровня (example.com),
чтобы они действовали на все поддомены. Также обратите внимание, что
записи CAA для поддоменов приоритетнее, чем записи для родительского домена,
независимо от того, носят ли они разрешительный или запретительный характер.
Таким образом, поддомен может не иметь ограничения, которое установлено
для родительского домена.
Валидация CAA придерживается правил CNAMEs, как и другие DNS-запросы. Если
www.community.example.com – CNAME для web1.example.net, то Центр
сертификации сперва запросит записи CAA для www.community.example.com,
далее, обнаружив CNAME вместо записи CAA для этого доменного имени,
запросит CAA для web1.example.net. Обратите внимание, что если доменное
имя имеет запись CNAME, оно не может иметь никаких других записей,
согласно стандартам DNS.
CAA RFC определяет дополнительное поведение, называемое “tree-climbing”, которое требует, чтобы Центры сертификации также проверяли родительские домены для результата разрешения CNAME. Это дополнительное поведение было позже удалено в исправлении, поэтому Let’s Encrypt и другие Центры сертификации не реализовали его.
Ошибки CAA
С тех пор как Let’s Encrypt стал проверять записи CAA, прежде чем выпустить любой сертификат, иногда появляются ошибки даже для доменов, не имеющих никаких записей CAA. При появлении ошибки невозможно определить, разрешен ли выпуск для затронутого домена, поскольку могут существовать записи CAA, запрещающие выпуск, которые не видны из-за ошибки.
Если вы получаете ошибки, связанные с CAA, сделайте еще несколько попыток, используя наше тестовое окружение, чтобы определить, является ли ошибка временной или постоянной. Если она постоянна, вам нужно обратиться с запросом в службу поддержки вашего DNS-провайдера или сменить провайдера. Если вы не знаете, кто ваш DNS-провайдер, выясните это у провайдера вашего хостинга.
Некоторые провайдеры DNS, которые не знакомы с CAA, первоначально отвечают на сообщения о проблемах: «Мы не поддерживаем записи CAA». Вашему DNS-провайдеру не нужно специально поддерживать записи CAA; он только должен возвращать ответ NOERROR для неизвестных типов запросов (включая CAA). Возврат других кодов операций, включая NOTIMP для нераспознанных типов запросов, является нарушением RFC 1035 и подлежит исправлению.
SERVFAIL
Одной из самых распространенных ошибок, с которыми сталкиваются пользователи, является SERVFAIL. Чаще всего это указывает на ошибку проверки DNSSEC. Если вы получили ошибку SERVFAIL, первым делом используйте отладчик DNSSEC, например, dnsviz.net. Если это не помогло, возможно, ваши серверы имен генерируют неправильные подписи только тогда, когда ответ пуст. And CAA responses are most commonly empty. А ответы CAA чаще всего пусты. Например, PowerDNS имел эту ошибку в версии 4.0.3 и ниже.
Если у вас не включен DNSSEC и вы получили SERVFAIL, вторая наиболее вероятная причина заключается в том, что ваш полномочный сервер имен возвратил NOTIMP, что, как описано выше, является нарушением RFC 1035; вместо этого он должен вернуть NOERROR с пустым ответом. В таком случае отправьте сообщение об ошибке или запрос в службу поддержки вашему провайдеру DNS.
Наконец, ошибки SERVFAIL могут быть вызваны перебоями в работе ваших полномочных серверов имен. Проверьте записи NS для ваших серверов имен и убедитесь, что каждый сервер доступен.
Таймаут
Иногда запросы CAA заканчиваются таймаутом. То есть полномочный сервер имен не отвечает даже после множества попыток. Чаще всего это происходит, если перед вашим сервером имен неправильно настроен файервол, который отвергает запросы DNS с неизвестным типом. Подайте заявку в службу поддержки вашего DNS-провайдера и спросите об их настройках файервола.