Domain IP Lookup

Записи, которые встретятся почти в каждой зоне

AИмя хоста → адрес IPv4
AAAAИмя хоста → адрес IPv6
CNAMEИмя хоста → другое имя хоста
MXДомен → почтовые серверы по приоритету
TXTДомен → произвольный текст: SPF, DKIM, верификация
NSДомен → серверы имён, отвечающие за него
Безопасность

Что такое CAA-запись: кто может выпускать сертификаты

4 мин чтения

CAA-запись, сокращение от Certification Authority Authorization, — это DNS-запись, позволяющая владельцу домена указать, каким центрам сертификации разрешено выпускать публичные TLS-сертификаты для имён в этом домене. Центры сертификации проверяют политику CAA при выпуске там, где этого требуют соответствующие правила. Запись не шифрует трафик, не устанавливает сертификат и не гарантирует безопасность сайта. Это дополнительный контроль выпуска: способ сделать предполагаемых эмитентов сертификатов домена видимыми в DNS и снизить вероятность того, что непредусмотренный центр выпустит сертификат, хотя политика владельца домена этого не разрешает.

Что содержит политика CAA

Записи CAA используют флаги, тег свойства и значение. Распространённое свойство issue называет центр, которому разрешено выпускать сертификаты, а issuewild применяется к wildcard-сертификатам. Свойство iodef может указывать адрес для отчётов о нарушениях политики, где это поддерживается. Реальный синтаксис записи включает задокументированный идентификатор выпускающего центра, и идентификаторы — это не взаимозаменяемые названия брендов; используйте точное значение, которое публикует поставщик сертификатов. Домен может опубликовать более одного разрешённого эмитента. При наличии политики эмитенту, которого нет в списке, может быть запрещено выпускать сертификаты с учётом применимых правил обработки DNS и центров сертификации.

СвойствоОбщее назначение
issueРазрешить центр сертификации для обычных сертификатов
issuewildЗадать политику выпуска wildcard-сертификатов
iodefУказать адрес для отчётов о проблемах политики
ФлагУправляет критической обработкой свойства

Политика CAA следует связям между DNS-именами. Имя без собственных данных CAA может унаследовать ближайшую подходящую политику выше в иерархии домена, а CNAME может влиять на то, где находятся применимые данные, согласно правилам DNS. Поэтому важно проверять точное имя, для которого запрашивается сертификат, а не только корневой домен. Выпуск wildcard-сертификатов тоже заслуживает отдельного внимания: политика, разрешающая центр для обычных имён, может не передавать тот же замысел для wildcard-сертификатов, если присутствует issuewild. Прежде чем полагаться на конкретное толкование, проверьте актуальные стандарты и инструкции центра сертификации.

Планируйте изменения до публикации ограничения

Ограничительная CAA-запись может заблокировать законное продление сертификата, если в ней нет центра, который использует ваша хостинг-платформа или автоматизация сертификатов. Прежде чем добавлять её, составьте перечень всех служб, получающих сертификаты для домена, включая поддомены, управляемый хостинг, конечные точки CDN и тестовые системы, использующие публично доверенные сертификаты. Спросите у каждого провайдера его официальный идентификатор CAA и любые требуемые записи. Затем опубликуйте записи и публично запросите их, чтобы подтвердить значения. Согласуйте изменения с графиками продления и следите за следующим выпуском или продлением, а не считайте, что синтаксически корректная запись означает правильную настройку каждой интеграции.

  • Используйте точные значения CAA из актуальной документации центра сертификации.
  • Проверяйте и корневое имя, и конкретный поддомен, для которого выпускается сертификат.
  • Учитывайте политику для wildcard-сертификатов отдельно.
  • Не удаляйте действующего эмитента, пока вся автоматизация сертификатов не перенесена.
  • Перепроверяйте данные CAA после смены DNS-провайдера или миграции платформы сертификатов.

Чего CAA не решает

CAA — один из уровней управления выпуском сертификатов, а не замена защите DNS-аккаунтов, обеспечению безопасности регистрации домена, продлению сертификатов или правильной настройке HTTPS. Она сама по себе не отзывает существующий сертификат и не может предотвратить любую возможную компрометацию домена или аккаунта. Запись также не говорит браузеру, действителен ли сертификат, который сейчас отдаёт сайт: браузеры проверяют сертификат, предъявленный при соединении. Если сертификат отсутствует или неверен, проверяйте и работающую конечную точку TLS, и политику DNS.

При диагностике сбоя выпуска изучите ответ DNS, проверьте идентификатор эмитента и выясните, унаследовало или переопределило ли запрошенное имя хоста политику. Сравните опубликованные данные с актуальными требованиями поставщика сертификатов. Общий словарь DNS, используемый в CAA, описан в статье типы DNS-записей. CAA — ценная запись, если её ответственный за эксплуатацию понимает путь продления, но неосторожное ограничение может вызвать сбой именно тогда, когда подходит срок автоматического сертификата. Считайте её конфигурацией, требующей сопровождения на протяжении жизненного цикла, а не разовой галочкой по безопасности.

Держите политику CAA согласованной с автоматизацией сертификатов

Выпуск сертификатов могут автоматизировать сразу несколько служб: хостинг-провайдер может выпускать сертификат основного сайта, CDN — продлевать краевой сертификат, а отдельная платформа — обслуживать клиентский портал. Прежде чем ограничивать CAA, составьте простой перечень имён сертификатов, эмитентов, использования wildcard и ответственных за продление. Пересматривайте его при каждой смене инфраструктуры или владельца домена. Если продление не удалось после обновления политики, проверьте фактическое имя хоста, унаследованную политику и идентификатор эмитента, прежде чем полностью снимать ограничение. Опубликуйте аккуратно очерченное исправление и убедитесь, что провайдер может завершить продление. Такой подход сохраняет ценность безопасности авторизованного выпуска и позволяет избежать аварии, когда все владельцы служб пытаются добавить широкие разрешения, не зная, какой поток сертификатов заблокирован.

Нужно проверить публичные DNS-адреса домена? Воспользуйтесь инструментом Domain IP Lookup.

Читайте также

Рекурсивный DNS-запрос: шаг за шагом

Браузер

нужен example.com

Резолвер

ваш провайдер / 1.1.1.1

Корень + TLD

кто отвечает за .com?

Авторитетный

настоящий ответ

Каждый шаг цепочки — тоже DNS-запрос, и его ответ потом кэшируется

Безопасность

DNSSEC: как проверяется подлинность DNS-ответов

Что делают подписи DNSSEC, записи DS и DNSKEY, как работает проверка и почему ошибки настройки приводят к ответам SERVFAIL.

4 мин чтения

У каждого диапазона IPv4 есть эквивалент в IPv6

Loopback127.0.0.0/8 в IPv4 — ::1 в IPv6
Приватные10.0.0.0/8 и др. в IPv4 — fc00::/7 в IPv6
Link-local169.254.0.0/16 в IPv4 — fe80::/10 в IPv6
Безопасность

Особенности безопасности IPv6, которые нельзя игнорировать

С точки зрения безопасности IPv6 — это не просто «IPv4 с большим числом адресов»: некоторые его отличия действительно меняют модель угроз.

3 мин чтения

Выигрыш в гонке с поддельным ответом

Атакующий

опережает настоящий ответ

Поддельный ответ

приходит первым

Кэш резолвера

отравлен для всех его пользователей

Безопасность

DNS-спуфинг и отравление кеша: практический обзор

Подделка DNS-ответов для перенаправления трафика — один из старейших сетевых приёмов и причина появления DNSSEC и современных защит резолверов.

3 мин чтения