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

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 становится авторитативным сервером: у регистратора зона делегируется на серверы имён Cloudflare. При частичной настройке (CNAME) авторитативным остаётся другой провайдер, а Cloudflare получает отдельные имена хостов. Вторичный DNS позволяет Cloudflare работать вторичным сервером при внешнем основном (или наоборот) с помощью передачи зоны.

Возможности

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

Зона содержит записи; у каждой есть тип, имя, содержимое, TTL, а у адресных записей и записей CNAME ещё и статус проксирования. Если запись проксируется, её TTL задаёт Cloudflare, а в ответе возвращается адрес Cloudflare, а не указанный адрес origin-сервера.

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

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

• TTL. Настраивается для каждой записи DNS-only отдельно. Определяет, как долго резолверы могут кешировать ответ и, соответственно, сколько времени нужно, чтобы изменение стало видно везде.
• Статус прокси. Определяет, обслуживается ли имя хоста через сеть Cloudflare. Почтовые записи и записи других сервисов, работающих не по HTTP, должны оставаться в режиме DNS-only.
• CNAME flattening. Включается либо только для корня зоны (apex), либо для всех CNAME-записей зоны.
• DNSSEC. Включается для каждой зоны отдельно; Cloudflare создаёт значения 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 адрес вашего origin-сервера или подключается к имени хоста на порту, отличном от 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 устраняет зависимость от единственной точки обработки запросов, но ошибка в плоскости управления или в конфигурации затрагивает все точки сразу. Закладывайте это в проект: проверяйте изменения и ведите внешний мониторинг, а не рассчитывайте, что архитектура сама исключает такой риск.
• Проксирование записи меняет ответ, который получает каждый клиент. Системы, которые ожидают адрес origin-сервера, включая некоторые конфигурации мониторинга и списков разрешений, перестанут работать.
• Поддержка типов записей широкая, но не исчерпывающая. Перед миграцией проверяйте редкие типы отдельно.

Взаимодействие с другими продуктами

Через переключатель прокси к имени хоста подключаются 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, 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.

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