Cloudflare 2 ноября 2026 года рассказала об изменениях в системе подготовки DNS-записей: медианная задержка обработки сократилась с 7,7 до 3,3 секунды, а пиковое потребление оперативной памяти уменьшилось на 85%. Новый механизм реже пересобирает DNS-зону целиком и быстрее передаёт изменения во внутреннюю систему распространения данных Quicksilver. Речь идёт о работе инфраструктуры Cloudflare; время обновления кэша DNS у провайдеров и на устройствах пользователей в эти показатели не входит.
Почему изменение одной настройки заставляло Cloudflare обрабатывать миллионы DNS-записей
DNS-зона хранит записи и настройки домена: например, адрес сервера в записи A, имя целевого узла в CNAME и служебные сведения, необходимые DNS-серверам. Когда владелец сайта меняет запись или параметр зоны, Cloudflare должна подготовить обновлённые данные для своих авторитетных DNS-серверов — тех, которые отвечают за информацию о домене.
Эту задачу выполняет компонент Zone Builder. Раньше некоторые изменения настроек запускали полную пересборку зоны. Система считывала все записи из базы данных, преобразовывала их в нужный формат, сравнивала с уже опубликованными данными и записывала отличия. Даже если в результате менялось всего несколько значений, обработать приходилось весь набор.
Для небольших доменов такой подход практически незаметен. Но, по данным Cloudflare, отдельные зоны сейчас содержат более 20 миллионов записей. В 2022 году Zone Builder получал около 250 изменений DNS-записей в секунду, а к ноябрю 2026 года — уже около 700, плюс примерно 100 событий другого типа, включая изменения настроек зон. Полные пересборки крупных зон потребляли много памяти и задерживали обработку других событий.
Zone Builder теперь выбирает минимальный объём работы
Cloudflare добавила планировщик, который определяет, какие именно DNS-данные могли измениться. Для обычного обновления записи A, AAAA, TXT или CNAME чаще всего достаточно пересобрать записи конкретного DNS-имени. Изменение серверов имён или wildcard-записи может потребовать обновления записей вместе с общими метаданными зоны.
Есть и более сложные случаи. Например, переключение Universal SSL способно затронуть служебные записи CAA в корне домена, которые сообщают центрам сертификации, кому разрешено выпускать сертификаты. Теперь для такого события система может обновить корневые записи и метаданные, сохранив остальные данные зоны без повторной обработки.
Принцип безопасности остался строгим: результат выборочной сборки должен в точности совпадать с результатом полной. Если система не может надёжно определить затронутые данные, она выбирает полную пересборку. При первой публикации зоны также требуется обработать все её записи.
Единый планировщик уменьшил очереди и расход памяти
До оптимизации изменения отдельных записей и полные пересборки обслуживали разные планировщики. Теперь единый планировщик объединяет ещё не обработанные изменения одной зоны в одну задачу. Например, если почти одновременно изменились запись www.example.com и wildcard-запись *.example.com, система может подготовить обе вместе с необходимыми метаданными.
Это уменьшило число дорогих операций и помогло устранить задержки в очередях Kafka, через которые проходят события об изменениях. Раньше длительная сборка крупной зоны могла задержать подтверждение последующих сообщений той же очереди. После оптимизации обработка событий стала равномернее, без выраженных периодов отставания и последующего наверстывания.
Параллельно Cloudflare сократила защитные интервалы между сборками и ожидание обновления реплик базы данных. Последнее стало возможным благодаря проверке, которая отклоняет чтение из отстающей реплики: Zone Builder не должен строить новую конфигурацию на основе устаревшего состояния.
Насколько ускорилась DNS-инфраструктура Cloudflare
В техническом отчёте компания приводит результаты измерений до и после изменений:
| Показатель | Раньше | После оптимизации |
| Медианная задержка от изменения DNS до записи данных в Quicksilver | 7,7 с | 3,3 с |
| Среднее потребление оперативной памяти Zone Builder | 49 ГиБ | 7 ГиБ |
| Пиковое потребление оперативной памяти | 79 ГиБ | 12 ГиБ |
| Наибольший зафиксированный всплеск задержки p99 в сравнении планировщиков за 24 часа | 14,6 мин | 1,21 мин |
За сутки наблюдений 92,95% операций не требовали полной пересборки DNS-зоны. На полные сборки пришлось около 7,04%; их количество, по оценке Cloudflare, сократилось примерно на 40% относительно прежней схемы. Потребление памяти в среднем снизилось примерно на 86%, в пиках — на 85%.
Последняя строка таблицы относится к сравнению старого рабочего планировщика с новым на зеркальной системе за одинаковый 24-часовой период. Она описывает наиболее сильные задержки в этом тесте и не является обещанием такого времени для каждой DNS-зоны. Показатели 7,7 и 3,3 секунды включают разные типы изменений и тарифы Cloudflare.
Что ускорение DNS означает для владельцев сайтов
Представим, что администратор меняет DNS-запись, чтобы направить домен на другой сервер. Cloudflare теперь в среднем быстрее заканчивает внутреннюю подготовку нового состояния и записывает его в Quicksilver — распределённое хранилище, откуда конфигурация доставляется в сеть компании. Для доменов с большим количеством записей особенно заметно сокращение лишней работы, связанной с изменениями настроек зоны.
Но время 3,3 секунды заканчивается на этапе записи в Quicksilver. Дальнейшее распространение по сети Cloudflare в эту метрику не включено. Кроме того, DNS-резолвер интернет-провайдера или браузер может продолжать использовать закэшированную старую запись до истечения её TTL — срока хранения в кэше. Поэтому фактический переход посетителей на новый адрес сайта иногда занимает дольше нескольких секунд даже после завершения обработки на стороне Cloudflare.
Оптимизация относится к серверной инфраструктуре Cloudflare. Компания не объявляла об отдельной настройке, которую владельцам доменов нужно включить для получения описанного эффекта.
Полные сборки DNS-зон сохранятся для отдельных событий
Cloudflare оставила полную обработку там, где без неё нельзя гарантировать корректность данных: при первой публикации зоны, изменениях, которые могут затронуть произвольные записи, и событиях без достаточной информации о причине изменения. Для особо крупных зон предусмотрен отдельный компромисс: если полный объём данных не помещается в память, система обрабатывает известные затронутые имена и метаданные, а редкие исключения могут потребовать ручного вмешательства инженеров.
В 2022 году Cloudflare рассчитывала со временем отказаться от полных сборок полностью. В отчёте от 2 ноября 2026 года компания признаёт, что они по-прежнему нужны для некоторых сценариев. Доля таких операций теперь невелика, а наиболее тяжёлые изменения крупных зон обрабатываются выборочно.
