DNS प्रसार समय: Cloudflare के 3 सेकंड बनाम आपका TTL
संक्षेप में (2026-11-03 को जाँचा गया): Cloudflare ने इस सप्ताह लिखा कि DNS रिकॉर्ड बदलने से लेकर उसके बिल्ड सिस्टम द्वारा उसे लिख दिए जाने तक का समय आधा हो गया है: मीडियन लगभग 7.7 से घटकर लगभग 3.3 सेकंड रह गया, और इस काम की मेमोरी 85% कम हो गई। यह अच्छी इंजीनियरिंग है, लेकिन यह वह इंतज़ार नहीं है जो आप साइट को नए सर्वर पर ले जाते समय देखते हैं। आपका इंतज़ार उन मानों से तय होता है जिन्हें आप चुनते हैं या कम से कम पढ़ सकते हैं: रिकॉर्ड का TTL, SOA में नेगेटिव कैश का मान और, अगर आप नेम सर्वर बदलते हैं, तो .com रजिस्ट्री का दो दिन का TTL। हमने एक छोटी स्क्रिप्ट लिखी जो किसी भी ज़ोन के लिए ये सब पढ़ती है, उसे अपने ज़ोन और Cloudflare के ज़ोन पर चलाया, और नतीजे से एक कटओवर योजना बनाई।
स्रोत. "We halved DNS build delay and cut memory use by 85%" (Cloudflare ब्लॉग, 2026-11-02 को प्रकाशित), Hacker News पर चर्चा, 2026-11-03 तक 173 पॉइंट। उनके आँकड़े वैसे ही दिए गए हैं जैसे प्रकाशित हुए; नीचे के DNS जवाब हमने खुद पूछे।
Cloudflare ने क्या बदला
API या डैशबोर्ड से किया गया बदलाव पहले डेटाबेस में, फिर Kafka में, फिर Zone Builder में जाता है, जो ज़ोन को कुंजियों में बदलता है और केवल अंतर को Quicksilver में लिखता है, वह की-वैल्यू स्टोर जो इसे Cloudflare के हर डेटा सेंटर तक ले जाता है। "बिल्ड देरी" केवल पहला हिस्सा है: बदलाव से लेकर Zone Builder के लिखना पूरा करने तक। वितरण इसमें शामिल नहीं है। रिकॉर्ड बदलाव 2022 में लगभग 250 प्रति सेकंड से बढ़कर लगभग 700 हो गए, और कुछ ज़ोन में 2 करोड़ से ज़्यादा रिकॉर्ड हैं, इसलिए एक रिकॉर्ड के लिए पूरा ज़ोन दोबारा बनाना महँगा हो गया। अब एक नया प्लानर सबसे छोटा सुरक्षित बिल्ड चुनता है; 24 घंटे के नमूने में 92.95% बिल्ड पूरे पुनर्निर्माण के बिना हुए।
| मीट्रिक (Cloudflare, 2026-11-02 को प्रकाशित) | पहले | बाद में |
|---|---|---|
| बिल्ड देरी का मीडियन | लगभग 7.7 s | लगभग 3.3 s |
| सबसे बड़ा p99 उछाल | 14.6 मिनट | 1.21 मिनट |
| औसत वर्किंग-सेट मेमोरी | 49 GiB | 7 GiB |
| पूरे ज़ोन बिल्ड का हिस्सा | 11.88% | 7.04% |
नए, ज़्यादा बारीक हिस्टोग्राम पर p99 ज़्यादातर 10 से 14 सेकंड के बीच रहता है। ग्राहक के लिए काम की बात पूँछ है: जो बदलाव किसी बुरे मिनट में पंद्रह मिनट लेता था, अब लगभग एक मिनट लेता है।
वे परतें जिनका आप वास्तव में इंतज़ार करते हैं
विज़िटर का रिज़ॉल्वर हर अनुरोध पर Cloudflare या किसी और प्रदाता से नहीं पूछता। वह जवाब को रिकॉर्ड के TTL तक रखता है और उसके बाद ही दोबारा पूछता है। इसलिए प्रदाता के सेकंड उन मिनटों या दिनों में जुड़ते हैं जो कहीं और तय होते हैं:
| परत | कौन तय करता है | हमने क्या देखा या पाया |
|---|---|---|
| प्रदाता पर बिल्ड | DNS प्रदाता | Cloudflare मीडियन ~3.3 s, p99 10-14 s |
| रिकॉर्ड TTL | आप | 300 s www.cloudflare.com, 1800 s dcxv.com |
| नेगेटिव कैश (नाम मौजूद नहीं था) | SOA न्यूनतम, RFC 2308 | 300 s cloudflare.com, 3600 s dcxv.com |
| नेम सर्वर डेलिगेशन | .com रजिस्ट्री | दोनों ज़ोन के लिए 172800 s (2 दिन) |
| आउटेज के दौरान serve-stale | रिज़ॉल्वर, RFC 8767 | 1-3 दिन सुझाए गए, TTL 30 s के साथ |
TTL वाली पंक्तियाँ नीचे के हमारे रन से हैं; serve-stale वाली पंक्ति RFC का सुझाव है, माप नहीं। Cloudflare के दस्तावेज़ कहते हैं कि प्रॉक्सी रिकॉर्ड का TTL स्थिर Auto = 300 s है, और केवल-DNS रिकॉर्ड 60 s (Enterprise पर 30 s) से 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 Cloud सर्वर पर 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 s बचे थे और Cloudflare के रिज़ॉल्वर के पास 242 s। उस पल किया गया बदलाव उनके उपयोगकर्ताओं तक तीन-चार मिनट बाद पहुँचता, बिल्ड कितना भी तेज़ हो। dcxv.com पर यही इंतज़ार 30 मिनट तक हो सकता है, क्योंकि हमारे A रिकॉर्ड का TTL 1800 s है।
- नया नाम बदले हुए नाम से धीमा हो सकता है। अगर किसी ने नाम को बनने से पहले खोजा, तो उसका रिज़ॉल्वर "ऐसा नाम नहीं है" जवाब SOA न्यूनतम तक रख सकता है: हमारे ज़ोन में 3600 s। नए होस्ट नाम घोषणा से पहले बनाएँ।
- नेम सर्वर बदलना अलग पैमाना है। .com डेलिगेशन में 172800 s, यानी दो दिन हैं। DNS को दूसरे प्रदाता पर ले जाने का मतलब है कि दोनों प्रदाता कम से कम इतने समय तक एक जैसे ज़ोन परोसें।
नए सर्वर या नए IPv4 ब्लॉक के लिए कटओवर योजना
- एक पुराने TTL पहले: A और AAAA रिकॉर्ड को 300 s पर लाएँ। पूरी चेकलिस्ट क्लाउड सर्वर पर माइग्रेट कैसे करें में है।
- स्विच के समय: रिकॉर्ड बदलें, सीरियल मिलने तक
dnscut.jsचलाएँ, फिर रिज़ॉल्वर के TTL को नए पते तक उलटी गिनती करते देखें। पुराने सर्वर को तब तक चालू रखें जब तक उसके लॉग शांत न हो जाएँ। - अगर नेम सर्वर बदलते हैं: पहले नया ज़ोन बनाएँ, रजिस्ट्रार पर NS बदलें, और पुराने प्रदाता को उसके बाद कम से कम दो दिन वही रिकॉर्ड परोसने दें।
- नए पते: अगर बदलाव के साथ नया खरीदा या लीज़ पर लिया ब्लॉक आता है, तो ट्रैफ़िक आने से पहले रिवर्स DNS और जियोलोकेशन जाँचें; देखें ट्रांसफ़र के बाद IPv4 जियोलोकेशन ठीक करना और हमारी IPv4 ब्रोकरेज।
- एक सप्ताह बाद: TTL फिर बढ़ाएँ (1800-3600 s आम है), ताकि प्रदाता का छोटा आउटेज कुछ ही मिनटों में सारे कैश खाली न कर दे।
हमारे साथ माइग्रेशन की योजना बनाएँ
प्राग और कोविल्हा में हमारे Tier III डेटा सेंटर क्लाउड सर्वर और डेडिकेटेड सर्वर चलाते हैं। एक क्लाउड सर्वर शुरू करें, माइग्रेशन से एक दिन पहले अपने ज़ोन पर dnscut.js चलाएँ और आउटपुट sales@dcxv.com पर भेजें: हम स्विच की योजना बनाने में मदद करेंगे।
