Останнє оновлення: | Переглянути всю документацію
Примітка: Англійська версія була оновлена з моменту перекладу () Переглянути англійською
CAA - це тип запису DNS, який дає змогу власникам сайтів визначати, які центри сертифікації (CAs) мають право видавати сертифікати, що містять їх доменні імена. Він був стандартизований у 2013 році RFC 6844 для того, щоб дозволити CA “зменшити ризик ненавмисної помилки видачі сертифіката”. За замовчуванням кожному публічному центру сертифікації (CA) дозволяється видавати сертифікати для будь-якого доменного імені в загальнодоступному DNS, за умови, що вони підтверджують контроль над цим доменним іменем. Це означає, що якщо є помилка в одному з багатьох процесів перевірки публічних CAs, то може постраждати кожне доменне ім’я. CAA надає власникам домену можливість зменшити цей ризик.
Використання CAA
Якщо ви не дбаєте про CAA, то вам, як правило, не потрібно нічого робити (але дивіться нижче на помилки CAA). Якщо ви хочете використовувати CAA, щоб обмежити сертифікати авторизації, яким дозволено видавати сертифікати для вашого домену, вам потрібно буде використовувати DNS-провайдера, який підтримує налаштування записів CAA. Список таких провайдерів можна знайти на SSLMate’s CAA сторінці. Якщо ваш провайдер є у списку, ви можете скористатися Генератором Записів SSLMate’s CAA для створення набору записів CAA із переліком центрів сертифікації (CAs), які ви хочете дозволити.
Зашифруймо ідентифікаційне доменне ім’я для 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, ЦС спочатку дасть запит на записи 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, для невизнаних 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-провайдера і запитайте, чи налаштовано у нього такий брандмауер.