Propagacja DNS: 3 sekundy Cloudflare kontra Twój TTL
W skrócie (sprawdzono 2026-11-03): Cloudflare napisał w tym tygodniu, że o połowę skrócił czas od zmiany rekordu DNS do chwili, w której system budowania go zapisał: mediana spadła z około 7,7 do około 3,3 sekundy, a pamięć potrzebna do tej pracy zmalała o 85%. To dobra inżynieria, ale nie jest to czas oczekiwania, który widzisz, przenosząc stronę na nowy serwer. Twoje oczekiwanie wyznaczają wartości, które sam wybierasz albo przynajmniej możesz odczytać: TTL rekordu, wartość cache negatywnego w SOA i, jeśli zmieniasz serwery nazw, dwudniowy TTL w rejestrze .com. Napisaliśmy mały skrypt, który odczytuje je wszystkie dla dowolnej strefy, uruchomiliśmy go na naszej strefie i na strefie Cloudflare, a z wyniku zrobiliśmy plan przełączenia.
Źródło. "We halved DNS build delay and cut memory use by 85%" (blog Cloudflare, opublikowano 2026-11-02), dyskusja na Hacker News, 173 punkty do 2026-11-03. Ich liczby podajemy tak, jak je opublikowano; odpowiedzi DNS poniżej pobraliśmy sami.
Co zmienił Cloudflare
Zmiana przez API lub panel trafia do bazy danych, potem do Kafki, a potem do Zone Buildera, który zamienia strefę na klucze i zapisuje tylko różnicę w Quicksilver, magazynie klucz-wartość, który rozwozi ją do każdego centrum danych Cloudflare. "Opóźnienie budowania" to tylko pierwsza część: od zmiany do zakończenia zapisu przez Zone Builder. Dystrybucja nie jest wliczona. Liczba zmian rekordów wzrosła z około 250 na sekundę w 2022 roku do około 700, a niektóre strefy mają ponad 20 milionów rekordów, więc przebudowa całej strefy dla jednego rekordu stała się droga. Nowy planista wybiera teraz najmniejszą bezpieczną budowę; w 24-godzinnej próbce 92,95% budowań obyło się bez pełnej przebudowy.
| Wskaźnik (Cloudflare, opublikowano 2026-11-02) | Przed | Po |
|---|---|---|
| Mediana opóźnienia budowania | ok. 7,7 s | ok. 3,3 s |
| Największy skok p99 | 14,6 min | 1,21 min |
| Średnia pamięć robocza | 49 GiB | 7 GiB |
| Udział pełnych budowań strefy | 11,88% | 7,04% |
Na nowym, dokładniejszym histogramie p99 leży zwykle między 10 a 14 sekundami. Dla klienta liczy się ogon: zmiana, która w złej minucie trwała kwadrans, teraz trwa około minuty.
Warstwy, na które naprawdę czekasz
Resolver odwiedzającego nie pyta Cloudflare ani innego dostawcy przy każdym zapytaniu. Trzyma odpowiedź przez TTL rekordu i dopiero potem pyta ponownie. Sekundy dostawcy dodają się więc do minut lub dni, o których decyduje się gdzie indziej:
| Warstwa | Kto ją ustala | Co zobaczyliśmy lub znaleźliśmy |
|---|---|---|
| Budowanie u dostawcy | dostawca DNS | Cloudflare mediana ~3,3 s, p99 10-14 s |
| TTL rekordu | Ty | 300 s www.cloudflare.com, 1800 s dcxv.com |
| Cache negatywny (nazwy nie było) | minimum SOA, RFC 2308 | 300 s cloudflare.com, 3600 s dcxv.com |
| Delegacja serwerów nazw | rejestr .com | 172800 s (2 dni) dla obu stref |
| Serve-stale podczas awarii | resolver, RFC 8767 | zalecane 1-3 dni, z TTL 30 s |
Wiersze z TTL pochodzą z naszego uruchomienia poniżej; wiersz serve-stale to zalecenie RFC, nie pomiar. Dokumentacja Cloudflare mówi, że rekord proxy ma stałe Auto = 300 s, a rekord tylko DNS można ustawić od 60 s (30 s w Enterprise) do 1 dnia (dokumentacja TTL Cloudflare, sprawdzono 2026-11-03).
Sprawdź strefę sam: dnscut.js
Skrypt pyta serwer TLD o TTL delegacji, każdy serwer autorytatywny o numer seryjny SOA i rekord, a trzy publiczne resolvery o to, co trzymają teraz i jak długo jeszcze. Potrzebuje tylko wbudowanego w Bun node:dns i dig do jednego zapytania bez rekursji. Zapisz go jako 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
Wynik, uruchomione na serwerze DCXV Cloud z Bun 1.4.4 i dig 9.20.24 dnia 2026-11-03 (najpierw nasza strefa, potem strefa 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.
Cztery rzeczy, które mówi wynik
- Równe numery seryjne oznaczają, że dostawca skończył. Ten sam numer seryjny SOA na każdym serwerze nazw oznacza, że zmiana wyszła od dostawcy; reszta to cache. Serwery anycast mogą się różnić zależnie od miejsca, więc dotyczy to punktu, z którego pytasz. Jeśli numery się różnią, poczekaj albo otwórz zgłoszenie: żadna sztuczka z TTL nie pomoże.
- Resolvery odliczają, nie odświeżają wcześniej. Quad9 miał dla www.cloudflare.com jeszcze 181 s, resolver Cloudflare 242 s. Zmiana w tej chwili dotarłaby do ich użytkowników trzy do czterech minut później, niezależnie od szybkości budowania. Dla dcxv.com to samo czekanie może trwać 30 minut, bo nasz rekord A ma TTL 1800 s.
- Nowa nazwa może pojawić się później niż zmieniona. Jeśli ktoś szukał nazwy, zanim powstała, jego resolver może trzymać odpowiedź "nie ma takiej nazwy" do minimum SOA: 3600 s w naszej strefie. Twórz nowe nazwy hostów, zanim je ogłosisz.
- Zmiana serwerów nazw to inna skala. Delegacja w .com ma 172800 s, czyli dwa dni. Przeniesienie DNS do innego dostawcy oznacza, że obaj dostawcy co najmniej tak długo serwują identyczne strefy.
Plan przełączenia na nowy serwer lub nowy blok IPv4
- Jeden stary TTL wcześniej: obniż rekordy A i AAAA do 300 s. Pełna lista kontrolna jest w jak przenieść stronę na serwer cloud.
- Przy przełączeniu: zmień rekordy, uruchamiaj
dnscut.js, aż numery seryjne się zgodzą, a potem patrz, jak TTL resolverów odlicza do nowego adresu. Trzymaj stary serwer odpowiadający, dopóki jego logi nie ucichną. - Jeśli zmieniają się serwery nazw: najpierw zbuduj nową strefę, przełącz NS u rejestratora i zostaw starego dostawcę z tymi samymi rekordami na co najmniej dwa dni.
- Nowe adresy: jeśli z przeprowadzką przychodzi świeżo kupiony lub dzierżawiony blok, sprawdź reverse DNS i geolokalizację, zanim przyjdzie ruch; zobacz poprawianie geolokalizacji IPv4 po transferze i nasze pośrednictwo IPv4.
- Po tygodniu: podnieś TTL z powrotem (1800-3600 s to typowa wartość), żeby krótka awaria dostawcy nie opróżniła wszystkich cache w kilka minut.
Zaplanuj przeprowadzkę z nami
Nasze centra danych Tier III w Pradze i Covilhã utrzymują serwery cloud i serwery dedykowane. Uruchom serwer cloud, wykonaj dnscut.js dla swojej strefy dzień przed przeprowadzką i wyślij wynik na sales@dcxv.com: pomożemy zaplanować przełączenie.
