← Все продукты

DNS

Cloudflare предоставляет авторитативный DNS, обслуживаемый через сеть anycast, с поддержкой подписи DNSSEC, CNAME flattening и управления проксированием для каждой записи отдельно. На этой странице описаны путь разрешения запросов, модель записей, процедура DNSSEC, ограничения и доступность по тарифным планам.

Управление документом

Дана
Технический писатель, Integrity Czech Republic s.r.o.

Обзор

Авторитетный DNS отвечает на запросы к зоне. От него зависит любое соединение с доменом, включая веб-трафик, почту и трафик между устройствами. Если авторитетный DNS выходит из строя, домен становится недоступен независимо от состояния серверов за ним.

Cloudflare обслуживает авторитативный DNS через сеть anycast. По данным Cloudflare, сеть работает в 348 городах (https://www.cloudflare.com/network/, дата обращения 2026-08-28).

Опубликованные рейтинги производительности резолверов составляют сторонние организации по собственным выборкам и методикам измерений. На этой странице не приводится ни одного рейтинга или медианного значения времени отклика, поскольку такие цифры имеют смысл только вместе с названием теста, датой измерения и точками наблюдения. Если время отклика важно для вашей задачи, измеряйте его на собственной выборке клиентов.

Cloudflare DNS также служит точкой подключения ко всей остальной платформе. Запись может находиться в статусе DNS only, тогда Cloudflare возвращает адрес, который вы указали, либо в статусе Proxied, тогда Cloudflare возвращает собственные адреса, и трафик этого хоста проходит через сеть Cloudflare.

Архитектура

Серверы имён Cloudflare используют общий набор IP-адресов, анонсируемых через anycast из дата-центров Cloudflare. Резолвер, который обращается к этим адресам, направляется на ближайшую анонсирующую точку, а если точка становится недоступной, запросы перенаправляются в другое место за счёт обычного поведения BGP, а не за счёт механизма отказоустойчивости DNS.

Данные зоны, изменённые в панели управления или через API, распространяются на инфраструктуру обслуживания. При планировании важно различать два понятия, которые часто путают между собой:

• Изменение авторитетного ответа. Ответ, который Cloudflare возвращает на новый запрос, меняется вскоре после применения изменения.
• Изменение, видимое для резолвера. Нижестоящие рекурсивные резолверы продолжают отдавать предыдущий ответ, пока TTL записи в их кэше не истечёт. Некоторые резолверы и клиентские стеки хранят ответы дольше срока TTL.

Поэтому время, за которое изменение становится видимым всем клиентам, ограничивается предыдущим значением TTL, а не скоростью обновления на авторитетном сервере. Переключение нужно планировать с учётом TTL, действовавшего до изменения.

Варианты настройки зоны отличаются друг от друга. Полная настройка делает Cloudflare авторитативным сервером благодаря делегированию серверов имён через регистратора. Частичная настройка (CNAME) сохраняет авторитативность за другим провайдером и делегирует Cloudflare отдельные хосты. Вторичный DNS позволяет Cloudflare выступать вторичным сервером для внешнего основного сервера или наоборот, используя передачу зоны.

Возможности

Модель настройки

Зона содержит записи, и у каждой есть тип, имя, содержимое, TTL, а для адресных записей и записей CNAME также статус проксирования. Когда запись проксируется, её TTL управляется Cloudflare, а возвращаемое содержимое представляет собой адрес Cloudflare, а не настроенный адрес источника.

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

Основные настройки, влияющие на поведение резолвинга:

• TTL. Настраивается для каждой DNS-only записи отдельно. Этот параметр определяет, как долго резолверы могут кэшировать ответ и, соответственно, сколько времени требуется, чтобы изменение стало видно везде.
• Статус прокси. Определяет, обслуживается ли имя хоста через сеть Cloudflare. Почтовые записи и другие записи не HTTP сервисов должны оставаться DNS-only.
• CNAME flattening. Настраивается только для apex или для всех CNAME записей в зоне.
• DNSSEC. Включается для каждой зоны отдельно, создаёт значения DS записи, которые нужно опубликовать у регистратора.

Управлять записями можно через панель управления, API, провайдер Terraform, а также импорт и экспорт файла зоны. Если зоны управляются как код, храните файл зоны в системе контроля версий, чтобы переключение можно было проверить по diff и при необходимости откатить.

Лимиты и ограничения

• Скорость появления изменения ограничена значением TTL, действовавшим до изменения, а также поведением кеширования у нижестоящих резолверов и клиентских стеков. Быстрое обновление авторитетного ответа на стороне Cloudflare этот предел не сокращает.
• Количество записей на зону и количество зон на аккаунт ограничено и зависит от тарифного плана. Актуальные значения см. на https://developers.cloudflare.com/dns/manage-dns-records/ (получено 2026-08-28) перед импортом крупной зоны.
• Список поддерживаемых типов записей обширен, но не универсален. Для нестандартных типов сверяйтесь с https://developers.cloudflare.com/dns/manage-dns-records/ (получено 2026-08-28) перед миграцией.
• Проксируемые записи возвращают адреса Cloudflare. Любая внешняя система, которая проверяет исходный адрес по DNS или подключается к имени хоста через порт, отличный от HTTP, должна использовать запись типа DNS-only.
• Для DNSSEC требуется запись DS у регистратора. Cloudflare добавляет запись DS автоматически только для доменов на Cloudflare Registrar и для .ch и .cz доменов верхнего уровня; для других регистраторов оператор должен опубликовать его (https://developers.cloudflare.com/dns/dnssec/, дата обращения 2026-08-28).
• Вторичный DNS и мультипровайдерные конфигурации доступны только на тарифе Enterprise.
• Переключение при отказе с проверкой работоспособности не входит в DNS. Для этого нужен отдельно оплачиваемый продукт Load Balancing.
• Срок хранения аналитики и журнала аудита зависит от тарифного плана.

Доступность по планам

Развёртывание

Предварительные требования.

• Экспортируйте текущую зону у существующего провайдера и зафиксируйте все записи, включая те, что были созданы третьими сторонами для подтверждения домена, аутентификации почты и выпуска сертификатов.
• Зафиксируйте текущие значения TTL, поскольку от них зависит окно переключения.
• Полностью определите конфигурацию почты: MX, SPF, селекторы DKIM, DMARC и любые записи проверки, специфичные для провайдера.
• Определите имена узлов, которые должны оставаться в режиме DNS only, включая почтовые серверы, конечные точки VPN и сервисы на портах, отличных от HTTP.
• Проверьте, включён ли сейчас DNSSEC у регистратора домена.
• Убедитесь, что у вас есть доступ к регистратору и возможность изменить серверы имён и записи DS в течение запланированного окна.

Поэтапная проверка. Импортируйте зону в Cloudflare, не меняя делегирование. Запрашивайте серверы имён Cloudflare напрямую по каждой записи и сравнивайте ответы с текущими продакшн ответами, запись за записью. Устраните расхождения, прежде чем продолжить. Там, где возможна частичная настройка (CNAME), используйте её, чтобы сначала проверить часть имён хостов под продакшн трафиком.

Настройка.

1. Осознанно настраивайте статус прокси для каждой записи. Записи почты и служб, работающих не по HTTP, оставляйте в режиме DNS only.
2. Снизьте TTL у текущего провайдера до небольшого значения, как минимум за один интервал прежнего TTL до момента переключения, чтобы старые значения успели устареть в кэшах резолверов к моменту смены делегирования.
3. Задокументируйте план отката: прежний набор серверов имён, экспортированный файл зоны и действия у регистратора, необходимые для их восстановления.
4. Убедитесь, что DNSSEC отключён у регистратора и что запись DS больше не публикуется в родительской зоне.

Переключение. Смените серверы имён у регистратора в согласованном временном окне. Сохраняйте зону предыдущего провайдера заполненной и работающей в течение прежнего TTL плюс запас времени, чтобы резолверы, которые всё ещё используют старое делегирование, получали корректные ответы.

Верификация.

• Опросите новые серверы имён и несколько публичных резолверов для каждой важной записи и сравните результаты с ожидаемыми значениями.
• Отправьте и получите тестовое письмо, затем проверьте результаты оценки SPF, DKIM и DMARC в заголовках сообщения.
• Убедитесь, что процессы выпуска и продления сертификатов, зависящие от проверки DNS, по-прежнему завершаются успешно.
• Убедитесь, что записи для верификации домена сторонними сервисами по-прежнему разрешаются.
• Включайте DNSSEC в Cloudflare и публикуйте у регистратора сформированную запись DS только после того, как убедитесь в корректности разрешения имён. Перед закрытием изменения проверьте, что цепочка доверия проходит проверку без ошибок.

Откат. Восстановите прежние серверы имён у регистратора. Если DNSSEC уже был включён в Cloudflare, удалите DS запись у регистратора и дождитесь, пока она очистится в родительской зоне, прежде чем восстанавливать прежнее делегирование, иначе проверяющие резолверы завершатся ошибкой. Поскольку откат тоже ограничен сроком TTL, держите значения TTL низкими, пока миграция не будет подтверждена как стабильная.

Вопросы эксплуатации

По возможности управляйте записями как кодом. Изменения DNS оказывают серьёзное влияние: их легко внести, но сложно проверить постфактум. Зона под контролем версий с проверяемым diff устраняет целый класс инцидентов.

Включите ведение журнала аудита и оповещения об изменениях записей, а также ограничьте круг лиц, способных менять серверы имён и записи DS у регистратора. Доступ на уровне регистратора обладает наивысшими привилегиями в домене и часто остаётся вне процесса изменений, принятого для остальной инфраструктуры.

Настраивайте TTL осознанно. Длинный TTL повышает устойчивость к проблемам плоскости управления, но замедляет любые плановые изменения. Короткий TTL ускоряет изменения, однако увеличивает объём запросов и сокращает промежуток времени, в течение которого устаревший кешированный ответ защищает вас во время сбоя.

Отслеживайте разрешение имён извне, с нескольких сетей, а не полагайтесь только на внутренние проверки, и отдельно отслеживайте статус проверки DNSSEC, поскольку проблема с подписью или ключом выглядит как полный отказ для валидирующих резолверов, тогда как невалидирующие резолверы продолжают работать.

Сценарии сбоев, которые стоит предусмотреть: запись DS, оставшаяся после смены провайдера; просроченная подпись DNSSEC; проксированная запись на почтовом хосте; скрипт автоматизации, который пересоздаёт запись с неверным статусом прокси.

Известные особенности

• Для большинства регистраторов настройка DNSSEC выполняется не за один шаг. Cloudflare генерирует значения записи DS, но их публикация у регистратора остаётся задачей администратора, за исключением доменов Cloudflare Registrar и .ch и .cz доменов.
• Перед сменой серверов имён необходимо отключить DNSSEC и удалить запись DS, а после смены включить DNSSEC снова.
• DNSSEC защищает клиентов, чьи резолверы выполняют проверку. Клиенты с резолверами без проверки не получают от него никакой защиты, поэтому DNSSEC снижает, но не устраняет риск получения поддельных ответов.
• Быстрое обновление данных на авторитетных серверах не сокращает время кэширования на стороне резолверов, ограниченное TTL. Планируйте переключение с учётом прежнего значения TTL.
• Anycast устраняет зависимость от единственной точки обработки запросов, но ошибка в плоскости управления или конфигурации остается общим сценарием отказа. Учитывайте это с помощью проверки изменений и внешнего мониторинга, а не полагайтесь на то, что архитектура сама исключает такой риск.
• Проксирование записи меняет ответ, который получает каждый клиент. Системы, которые ожидают исходный адрес, включая некоторые конфигурации мониторинга и списков разрешений, перестанут работать.
• Поддержка типов записей широкая, но не исчерпывающая. Перед миграцией проверяйте редкие типы отдельно.

Совместимость

Переключатель прокси это точка подключения для CDN, WAF, защиты от DDoS, Bot Management и маршрутов Workers. Чтобы эти продукты применялись к трафику имени хоста, оно должно быть проксируемым.

Cloudflare Load Balancing работает поверх DNS и обеспечивает маршрутизацию с учётом проверок работоспособности. Он настраивается отдельно и может использовать в качестве конечных точек как проксируемые, так и DNS only хосты.

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

Email Security, Email Routing и сторонние почтовые платформы полагаются на MX-записи в режиме DNS-only и на TXT-записи для SPF, DKIM и DMARC. Эти записи не зависят от статуса прокси и не должны проксироваться.

При использовании Cloudflare Registrar обработка DNSSEC меняется: DS-записи отправляются автоматически.

Часто задаваемые вопросы

Сколько времени занимает распространение изменения записи до всех клиентов? До значения TTL, которое действовало до изменения, плюс дополнительное время кэширования нижестоящими резолверами и клиентскими стеками. Снизьте TTL заранее перед запланированным изменением.

Обязательно ли использовать CDN и продукты безопасности при переносе DNS в Cloudflare? Нет. Записи можно установить как DNS-only, и в этом случае Cloudflare выступает только как авторитетный DNS. Проксирование можно включить позже для каждого имени хоста отдельно.

Что требуется для включения DNSSEC? Включите DNSSEC для зоны в Cloudflare, а затем опубликуйте сгенерированную DS запись у регистратора. Cloudflare добавляет DS запись автоматически только для доменов Cloudflare Registrar и для .ch и .cz доменов.

Источники

• https://developers.cloudflare.com/dns/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/dns/dnssec/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/dns/zone-setups/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/dns/cname-flattening/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/dns/manage-dns-records/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/dns/proxy-status/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/load-balancing/, дата обращения 2026-08-28.
• https://www.cloudflare.com/network/, дата обращения 2026-08-28.

Снимок контента: 2026-08-28.

История изменений