Останнє оновлення: | Переглянути всю документацію
CAA - це тип запису DNS, який дозволяє власникам сайтів визначати, які сертифікати авторизації (CAs) мають право видавати сертифікати, що містять їх доменні імена. Він був стандартизований у 2013 році RFC 6844 для того, щоб дозволити CA “зменшити ризик ненавмисної помилки видачі сертифіката”. За замовчуванням кожному публічному центру сертифікації (CA) дозволяється видавати сертифікати для будь-якого доменного імені в загальнодоступному DNS, за умови, що вони підтверджують контроль над цим доменним іменем. Це означає, що якщо є помилка в одному з багатьох процесів перевірки публічних CAs, то може постраждати кожне доменне ім’я. CAA надає власникам домену можливість зменшити цей ризик.
Використання CAA
Якщо ви не дбаєте про CAA, то вам, як правило, нічого не потрібно робити (але дивіться нижче на помилки CAA). Якщо ви хочете використовувати CAA, щоб обмежити сертифікати авторизації, яким дозволено видавати сертифікати для вашого домену, вам потрібно буде використовувати DNS-провайдера, який буде підтримувати встановлення записів CAA. Список таких постачальників можна знайти на SSLMate’s CAA сторінці. Якщо ваш провайдер є у списку, ви можете скористатися Генератором Записів SSLMate’s CAA для створення набору записів CAA із переліком CA, які ви хочете дозволити.
Давайте зашифруємо ідентифікаційне доменне ім’я для CAA letsencrypt.org. Це офіційно задокументовано у нашій заяві про практику сертифікації (CPS), section 4.2.1.
Де поставити запис
Ви можете встановити записи CAA у своєму основному домені або у будь-якому дочірньому піддомені будь-якої глибини. Наприклад, якщо у вас є www.community.example.com, ви можете встановити записи CAA для повного імені або для community.example.com або для example.com. Центри сертифікації (CAs) перевірятимуть кожну версію зліва направо і зупинятимуться, як тільки побачать будь-який запис CAA. Так, наприклад, запис CAA на community.example.com матиме пріоритет над записом на example.com. Більшість людей, які додають записи CAA, хочуть додати їх до зареєстрованого домену (example.com), щоб вони застосовувалися до всіх піддоменів. Також зверніть увагу, що записи CAA для піддоменів мають пріоритет над їхніми батьківськими доменами, незалежно від того, чи є вони більш дозволеними чи обмеженими. Таким чином, піддомен може послабити обмеження, встановлене батьківським доменом.
Підтвердження CAA відповідає CNAMEs, як і всі інші DNS-запити. Якщо www.community.example.com є CNAME для web1.example.net, CA спочатку дасть запит на записи CAA для www.community.example.com то побачивши, що для цього доменного імені існує CNAME замість записів CAA, то буде давати запит на запис CAA для web1.example.net. Зауважте, що якщо доменне ім’я має запис CNAME, то він забороняє мати будь-які інші записи відповідно до стандартів DNS.
CAA RFC визначає додаткову поведінку під назвою “підйом по деревах”, яка вимагає від CA також перевіряти батьківські домени на результат розолюції CNAME. Пізніше ця додаткова поведінка була видалена помилкою, тому Let’s Encrypt та інші CA не реалізують її.
CAA помилки
З того моменту, як Let’s Encrypt перевіряє записи CAA, перед кожним виданим нами сертифікатом, іноді ми отримуємо помилки навіть для доменів, у яких не встановлено жодних записів CAA. Коли ми отримуємо помилку, то неможливо визначити, чи нам дозволено видавати для відповідного домену, оскільки можуть бути присутні записи CAA, які забороняють видачу, але не відображаються через помилку.
Якщо ви отримуєте помилки, пов’язані з CAA, спробуйте ще кілька разів порівняти з нашим середовищем постановки, щоб перевірити, чи є вони тимчасовими чи постійними. Якщо вони постійні, вам потрібно буде подати запит про підтримку своєму DNS-провайдеру або змінити його. Якщо ви не впевнені, хто ваш DNS-провайдер, то запитайте у свого хостинг-провайдера.
Деякі DNS-провайдери, які не знайомі з CAA, на повідомлення про проблеми відповідають: “Ми не підтримуємо записи CAA”. DNS-провайдеру не потрібно якось особливо підтримувати записи CAA; йому потрібно лише відреагувати на NOERROR відповіді на невідомі типи запитів (включаючи CAA). Повернення інших кодів операцій, включаючи NOTIMP, для невизнаних q-типів є порушенням RFC 1035 і його потрібно виправити.
SERVFAIL
Однією з найпоширеніших помилок, з якими стикаються люди є SERVFAIL. Найчастіше це свідчить про помилку перевірки DNSSEC. Якщо ви отримуєте помилку SERVFAIL, першим кроком має стати використання налагоджувача DNSSEC, такого як dnsviz.net. Якщо це не спрацює, можливо, ваші сервери імен генерують неправильні підписи лише тоді, коли відповідь порожня. А відповіді CAA зазвичай порожні. Наприклад, у PowerDNS була ця помилка у версії 4.0.3 і нижчих.
Якщо у вас немає увімкненого DNSSEC і ви отримуєте SERVFAIL, друга найімовірніша причина - це те, що ваш авторитетний сервер імен повернув NOTIMP, що, як описано вище, є порушенням RFC 1035; замість цього він повинен повернути NOERROR з порожньою відповіддю. У цьому випадку відправте помилку чи заяву підтримки вашому DNS-провайдеру.
І нарешті, SERVFAIL може бути спричинена перебоями на ваших авторитетних серверах імен. Перевірте записи NS для ваших серверів імен та переконайтесь, що кожен сервер доступний.
Час очікування
Іноді CAA запитує час очікування. Тобто авторитетний сервер імен ніколи не дасть відповіді, навіть після кількох повторів. Найчастіше це трапляється, коли перед ним на вашому сервері імен є неправильно налаштований брандмауер, який видаляє DNS-запити з невідомими q-типами. Подайте заявку в службу підтримки своєму DNS-провайдеру і запитайте їх, чи налаштовано такий брандмауер.