आप एक नया सबडोमेन बनाते हैं। प्रबंधन इंटरफ़ेस में रिकॉर्ड दिखता है, एक सहकर्मी साइट खोल पा रहा है, लेकिन आपका कंप्यूटर अब भी NXDOMAIN दिखाता है। क्या बदलाव विफल हो गया है? ज़रूरी नहीं। रिज़ॉल्वर यह भी याद रख सकता है कि कोई नाम पहले मौजूद नहीं था। सहेजा गया यह नकारात्मक उत्तर अपने आप में एक अलग स्थिति है।
Cloudflare की DNS समस्या-निवारण गाइड, जिसे 21 अक्टूबर 2026 को अपडेट किया गया, ठीक इसी मामले का वर्णन करती है। यह एक मौजूदा तकनीकी व्याख्या है, किसी नए DNS उत्पाद का लॉन्च नहीं। यह अंतर करना उपयोगी है, क्योंकि रोज़मर्रा के शब्द “कैश” के पीछे कई बिल्कुल अलग भंडार छिप जाते हैं: DNS उत्तर, ब्राउज़र की सामग्री और कैश की गई वेब फ़ाइलें।
हो सकता है कि नाम के पहले मौजूद न होने की जानकारी अब भी सहेजी हुई हो
रिकर्सिव रिज़ॉल्वर आपकी ओर से नाम खोजता है। अगर उसे पहले कोई नकारात्मक उत्तर मिला है, तो वह सीमित समय तक उस उत्तर का दोबारा उपयोग कर सकता है। अगर इस बीच ऑथोरिटेटिव नेमसर्वर पर रिकॉर्ड बना दिया जाता है, तो ज़रूरी नहीं कि रिज़ॉल्वर को उसी क्षण इसका पता चल जाए।
आपने अभी जो A रिकॉर्ड बनाया है, उसका नया TTL इस मौजूदा नकारात्मक स्थिति की अवधि को पीछे जाकर छोटा नहीं करता। नेगेटिव कैशिंग में ज़ोन की SOA जानकारी की भूमिका होती है। RFC2308 के अनुसार प्रारंभिक मान SOA TTL और SOA.MINIMUM में से छोटा मान होता है। किसी सहेजे गए उत्तर के लिए वास्तव में बचा हुआ समय इससे भी अलग बात है।
हमारे अपने उदाहरण में केवल काल्पनिक संख्याएँ हैं: मान लीजिए कोई नकारात्मक प्रविष्टि शुरू में 300 सेकंड के लिए मान्य है। 120 सेकंड बाद वास्तविक DNS रिकॉर्ड बनाया जाता है। तब किसी रिज़ॉल्वर के पुराने उत्तर के 180 सेकंड अब भी बचे हो सकते हैं। यह केवल समय के संबंध को समझाता है; यह Cloudflare या आपके डोमेन के लिए मापी गई अवधि नहीं है।
दो रीड-ओनली क्वेरी से स्रोत और कैश को अलग-अलग परखा जा सकता है
पहला प्रश्न है: ज़िम्मेदार ऑथोरिटेटिव नेमसर्वर क्या जवाब देता है? दूसरा प्रश्न: आपका डिवाइस वास्तव में जिस रिकर्सिव रिज़ॉल्वर का उपयोग करता है, वह क्या जवाब देता है? अलग-अलग उत्तरों से गड़बड़ी का दायरा छोटा किया जा सकता है। लेकिन इनसे नेगेटिव कैशिंग अपने आप सिद्ध नहीं होती; टाइपिंग की गलतियों या गलत डेलिगेशन की आशंका को भी खारिज करना होगा।
dig @YOUR-AUTHORITATIVE-NAMESERVER neu.example.com A
dig @YOUR-RECURSIVE-RESOLVER neu.example.com A
dig @YOUR-RECURSIVE-RESOLVER neu.example.com A +noall +authorityप्लेसहोल्डर की जगह वे सर्वर लिखें जिनकी आपने वास्तव में पहचान की है। कमांड केवल रीड-ओनली टेम्पलेट हैं और इन्हें यहाँ चलाया नहीं गया है। रिस्पॉन्स कोड, नाम, रिकॉर्ड का प्रकार और, जहाँ मौजूद हों, SOA विवरण एक साथ देखें। मिलती-जुलती वर्तनी वाले किसी होस्ट का उत्तर तुलना के लिए उपयुक्त नहीं होगा।
समय और उपयोग किया गया रिज़ॉल्वर भी नोट करें। वरना हो सकता है कि आप अनजाने में अलग-अलग रास्तों की तुलना कर रहे हों। स्थानीय DNS कैश साफ़ करने से किसी अपस्ट्रीम रिज़ॉल्वर में सहेजा गया उत्तर अपने आप नहीं हटता। ठीक इसी कारण ब्राउज़र को रीस्टार्ट करने से वह स्थिति शायद प्रभावित न हो जिसे आप देख रहे हैं।
DNS और CDN अलग-अलग प्रश्नों के उत्तर देते हैं
DNS किसी नाम को रिज़ॉल्व करने में मदद करता है। इसके विपरीत, CDN कैश कुछ HTTP सामग्री को तैयार रखता है। कैश की गई छवियों या स्टाइलशीट को पर्ज करने से किसी DNS रिज़ॉल्वर को यह पता नहीं चलता कि पहले अज्ञात कोई नाम अब मौजूद है। ऐसे में यह कदम उस परत से मेल ही नहीं खाता जहाँ समस्या है।
Cloudflare की Cache से जुड़ी शुरुआती गाइड, जिसे पिछली बार 12 अक्टूबर 2026 को अपडेट किया गया, प्रॉक्सी किए गए और केवल-DNS होस्ट के अंतर का भी वर्णन करती है: केवल-DNS होस्ट की सामग्री सिर्फ़ इसलिए Cloudflare कैश से होकर नहीं गुज़रती कि उसका DNS वहाँ प्रबंधित होता है। इसलिए मौजूदा DNS रिकॉर्ड इस बात का प्रमाण नहीं है कि सामग्री सक्रिय रूप से कैश की जा रही है।
DomainStudio से वास्तविक उत्तर तक
आप KENJTEC DomainStudio aiमें अपने DNS रिकॉर्ड को प्रकार, लक्ष्य और TTL के साथ प्रबंधित कर सकते हैं। लागू किए गए तरीके में ज़ोन प्रबंधन के लिए Cloudflare का उपयोग होता है। बदलाव के बाद भी आपको रिज़ॉल्यूशन का आकलन वास्तविक DNS उत्तरों के आधार पर ही करना चाहिए; “सहेजा गया” और “हर रिज़ॉल्वर पर पहले से दिखाई दे रहा है” दो अलग-अलग बातें हैं।
इसलिए इंतज़ार के समय की जगह सफलता का कोई आम वादा नहीं किया जा सकता। पहले वर्तनी, ज़िम्मेदार नेमसर्वर और ऑथोरिटेटिव उत्तर की जाँच करें। उसके बाद ही बचा हुआ कैश समय एक उपयोगी व्याख्या बनता है। इससे “DNS में बस समय लगता है” जैसी बात एक ऐसे निदान में बदल जाती है जिसे परखा जा सकता है और जिसमें हर अवलोकन सही तकनीकी परत से जुड़ा होता है।
स्रोत और स्थिति
25 अक्टूबर 2026 तक का शोध और दस्तावेज़ीकरण। DNS से जुड़ी सामान्य समस्याएँ · Cache के साथ शुरुआत करें · RFC2308 — DNS क्वेरी की नेगेटिव कैशिंग।
