Распространение DNS: 3 секунды Cloudflare против вашего TTL
Коротко (проверено 2026-11-03): Cloudflare на этой неделе написал, что вдвое сократил время от изменения DNS-записи до момента, когда система сборки её записала: медиана упала примерно с 7,7 до примерно 3,3 секунды, а памяти на эту работу стало нужно на 85% меньше. Это хорошая инженерия, но это не то ожидание, которое вы видите при переезде сайта на новый сервер. Ваше ожидание задают значения, которые вы выбираете или хотя бы можете прочитать: TTL записи, значение негативного кеша в SOA и, если вы меняете серверы имён, двухдневный TTL в реестре .com. Мы написали небольшой скрипт, который читает их все для любой зоны, запустили его на нашей зоне и на зоне Cloudflare и превратили результат в план переключения.
Источник. "We halved DNS build delay and cut memory use by 85%" (блог Cloudflare, опубликовано 2026-11-02), обсуждение на Hacker News, 173 балла на 2026-11-03. Их цифры приведены так, как опубликованы; ответы DNS ниже мы запросили сами.
Что изменил Cloudflare
Изменение через API или панель попадает в базу данных, затем в Kafka, затем в Zone Builder, который превращает зону в ключи и записывает только разницу в Quicksilver, хранилище ключ-значение, которое доставляет её в каждый дата-центр Cloudflare. "Задержка сборки" - это только первая часть: от изменения до окончания записи в Zone Builder. Распространение сюда не входит. Число изменений записей выросло примерно с 250 в секунду в 2022 году до примерно 700, а в некоторых зонах больше 20 миллионов записей, так что перестраивать всю зону ради одной записи стало дорого. Новый планировщик выбирает самую маленькую безопасную сборку; в 24-часовой выборке 92,95% сборок обошлись без полной перестройки.
| Показатель (Cloudflare, опубликовано 2026-11-02) | До | После |
|---|---|---|
| Медиана задержки сборки | около 7,7 с | около 3,3 с |
| Самый большой всплеск p99 | 14,6 мин | 1,21 мин |
| Средняя рабочая память | 49 GiB | 7 GiB |
| Доля полных сборок зоны | 11,88% | 7,04% |
На новой, более точной гистограмме p99 в основном лежит между 10 и 14 секундами. Для клиента полезен именно хвост: изменение, которое в плохую минуту занимало четверть часа, теперь занимает около минуты.
Слои, которых вы на самом деле ждёте
Резолвер посетителя не спрашивает Cloudflare или другого провайдера при каждом запросе. Он хранит ответ на время TTL записи и только потом спрашивает снова. Поэтому секунды провайдера прибавляются к минутам или дням, о которых решают в другом месте:
| Слой | Кто задаёт | Что мы увидели или нашли |
|---|---|---|
| Сборка у провайдера | DNS-провайдер | Cloudflare медиана ~3,3 с, p99 10-14 с |
| TTL записи | вы | 300 с www.cloudflare.com, 1800 с dcxv.com |
| Негативный кеш (имени не было) | минимум SOA, RFC 2308 | 300 с cloudflare.com, 3600 с dcxv.com |
| Делегирование серверов имён | реестр .com | 172800 с (2 дня) для обеих зон |
| Serve-stale во время сбоя | резолвер, RFC 8767 | рекомендовано 1-3 дня, с TTL 30 с |
Строки с TTL взяты из нашего запуска ниже; строка serve-stale - рекомендация RFC, а не измерение. Документация Cloudflare говорит, что у проксируемой записи фиксированный Auto = 300 с, а запись только DNS можно задать от 60 с (30 с на Enterprise) до 1 дня (документация Cloudflare о TTL, проверено 2026-11-03).
Проверьте зону сами: dnscut.js
Скрипт спрашивает сервер TLD о TTL делегирования, каждый авторитетный сервер - о серийном номере SOA и самой записи, а три публичных резолвера - что они держат сейчас и сколько ещё будут держать. Нужны только встроенный в Bun node:dns и dig для одного запроса без рекурсии. Сохраните его как dnscut.js:
// dnscut.js - how long until a DNS change is visible everywhere
// usage: bun dnscut.js <zone> [name] e.g. bun dnscut.js example.com www.example.com
import { Resolver } from 'node:dns/promises'
const zone = process.argv[2] ?? 'example.com'
const name = process.argv[3] ?? zone
const PUBLIC = { Cloudflare: '1.1.1.1', Google: '8.8.8.8', Quad9: '9.9.9.9' }
const sys = new Resolver()
const at = ip => {
const r = new Resolver({ timeout: 3000, tries: 2 })
r.setServers([ip])
return r
}
// 1. parent (TLD) delegation: how long resolvers may keep the old name servers
const tld = zone.split('.').pop()
const tldNs = (await sys.resolveNs(tld)).sort()[0]
const tldIp = (await sys.resolve4(tldNs))[0]
const dig = Bun.spawnSync(['dig', '+norec', '+noall', '+authority', 'NS', zone, '@' + tldIp])
const deleg = dig.stdout.toString().split('\n').find(l => /\sNS\s/.test(l))
console.log(`Zone ${zone}, name ${name}`)
console.log(`Delegation at .${tld} (${tldNs}): NS TTL ${deleg?.split(/\s+/)[1] ?? '?'} s`)
// 2. every authoritative server: same SOA serial, same answer?
const serials = new Set()
let ttl = 0
let neg = 0
for (const n of (await sys.resolveNs(zone)).sort()) {
try {
const r = at((await sys.resolve4(n))[0])
const soa = await r.resolveSoa(zone)
const a = await r.resolve4(name, { ttl: true })
serials.add(soa.serial)
ttl = Math.max(ttl, ...a.map(x => x.ttl))
neg = soa.minttl // RFC 2308: negative answers are cached for min(SOA TTL, SOA MINIMUM)
console.log(` ${n.padEnd(24)} serial ${soa.serial} A ${a.map(x => x.address).join(',')} TTL ${a[0].ttl}`)
} catch (e) {
console.log(` ${n.padEnd(24)} ERROR ${e.code}`)
}
}
console.log(serials.size === 1 ? 'Authoritative servers agree.' : `Authoritative servers DISAGREE: ${[...serials].join(' / ')}`)
// 3. public resolvers: what they hold now and how long they may keep it
let left = 0
for (const [label, ip] of Object.entries(PUBLIC)) {
try {
const a = await at(ip).resolve4(name, { ttl: true })
left = Math.max(left, ...a.map(x => x.ttl))
console.log(` ${label.padEnd(10)} ${a.map(x => x.address).join(',')} TTL left ${a[0].ttl} s`)
} catch (e) {
console.log(` ${label.padEnd(10)} ERROR ${e.code}`)
}
}
console.log(`Record TTL ${ttl} s: after a change, caches may serve the old answer for up to ${ttl} s (these three: ${left} s).`)
console.log(`SOA minimum ${neg} s: a resolver that saw NXDOMAIN for a new name may keep it that long.`)
bun dnscut.js dcxv.com
bun dnscut.js cloudflare.com www.cloudflare.com
Результат, запущено на облачном сервере DCXV с Bun 1.4.4 и dig 9.20.24 2026-11-03 (сначала наша зона, затем зона Cloudflare):
Zone dcxv.com, name dcxv.com
Delegation at .com (a.gtld-servers.net): NS TTL 172800 s
ns1.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
ns2.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
ns3.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
ns4.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
ns5.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
ns6.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
Authoritative servers agree.
Cloudflare 217.28.140.182 TTL left 1800 s
Google 217.28.140.182 TTL left 1800 s
Quad9 217.28.140.182 TTL left 1800 s
Record TTL 1800 s: after a change, caches may serve the old answer for up to 1800 s (these three: 1800 s).
SOA minimum 3600 s: a resolver that saw NXDOMAIN for a new name may keep it that long.
Zone cloudflare.com, name www.cloudflare.com
Delegation at .com (a.gtld-servers.net): NS TTL 172800 s
ns3.cloudflare.com serial 2418847198 A 104.16.124.96,104.16.123.96 TTL 300
ns4.cloudflare.com serial 2418847198 A 104.16.123.96,104.16.124.96 TTL 300
ns5.cloudflare.com serial 2418847198 A 104.16.124.96,104.16.123.96 TTL 300
ns6.cloudflare.com serial 2418847198 A 104.16.124.96,104.16.123.96 TTL 300
ns7.cloudflare.com serial 2418847198 A 104.16.124.96,104.16.123.96 TTL 300
Authoritative servers agree.
Cloudflare 104.16.124.96,104.16.123.96 TTL left 242 s
Google 104.16.124.96,104.16.123.96 TTL left 300 s
Quad9 104.16.123.96,104.16.124.96 TTL left 181 s
Record TTL 300 s: after a change, caches may serve the old answer for up to 300 s (these three: 300 s).
SOA minimum 300 s: a resolver that saw NXDOMAIN for a new name may keep it that long.
Четыре вывода из результата
- Одинаковые серийные номера значат, что провайдер закончил. Один и тот же серийный номер SOA на каждом сервере имён означает, что изменение ушло от провайдера; дальше - кеши. Anycast-серверы могут отличаться в зависимости от места, так что это верно для точки, откуда вы спрашиваете. Если номера разные, ждите или открывайте тикет: никакой трюк с TTL не поможет.
- Резолверы отсчитывают, а не обновляются раньше. У Quad9 для www.cloudflare.com оставалось 181 с, у резолвера Cloudflare - 242 с. Изменение в этот момент дошло бы до их пользователей через три-четыре минуты, как бы быстро ни шла сборка. Для dcxv.com такое ожидание может длиться 30 минут, потому что у нашей A-записи TTL 1800 с.
- Новое имя может появиться позже изменённого. Если кто-то искал имя до его создания, резолвер может хранить ответ "такого имени нет" до минимума SOA: 3600 с в нашей зоне. Создавайте новые имена хостов до того, как о них объявлять.
- Смена серверов имён - другой масштаб. Делегирование в .com несёт 172800 с, то есть два дня. Перенос DNS к другому провайдеру означает, что оба провайдера как минимум столько обслуживают одинаковые зоны.
План переключения на новый сервер или новый блок IPv4
- За один старый TTL до переключения: понизьте A- и AAAA-записи до 300 с. Полный чеклист - в статье как перенести сайт на облачный сервер.
- Во время переключения: измените записи, запускайте
dnscut.js, пока серийные номера не совпадут, а затем смотрите, как TTL резолверов отсчитывают до нового адреса. Держите старый сервер включённым, пока его логи не затихнут. - Если меняются серверы имён: сначала соберите новую зону, переключите NS у регистратора и оставьте старого провайдера с теми же записями ещё минимум на два дня.
- Новые адреса: если вместе с переездом приходит только что купленный или арендованный блок, проверьте обратный DNS и геолокацию до прихода трафика; см. как исправить геолокацию IPv4 после трансфера и наш IPv4-брокеридж.
- Через неделю: снова поднимите TTL (1800-3600 с - обычное значение), чтобы короткий сбой провайдера не опустошил все кеши за несколько минут.
Спланируйте переезд вместе с нами
Наши дата-центры Tier III в Праге и Ковилье предлагают облачные серверы и выделенные серверы. Запустите облачный сервер, выполните dnscut.js для своей зоны за день до переезда и пришлите результат на sales@dcxv.com: мы поможем спланировать переключение.
