मान लें कि किसी डोमेन के सर्वर का पता बदल दिया गया है, लेकिन घर पर नई साइट खुलती है और फ़ोन पुराने सर्वर से जुड़ता है। दोनों उपकरणों में एक ही नाम लिखने पर भी, यदि वे अलग DNS कैश से होकर गुज़रें तो कुछ समय तक परिणाम अलग हो सकते हैं। पेज दोबारा प्राप्त करने वाला HTTP कैश और कनेक्शन का पता खोजने वाला DNS कैश अलग चीज़ों की जाँच माँगते हैं।
इस लेख में काल्पनिक पुस्तकालय होस्ट www.library.example के ज़रिये नाम समाधान और कैश का संबंध देखेंगे। उदाहरण का नाम और समय-सारणी समझाने के लिए बनाए गए हैं; किसी वास्तविक सेवा के उत्तर नहीं मापे गए। उद्देश्य DNS से पता मिलने की प्रक्रिया, बदलाव देर से दिखने का कारण और नाम समाधान के बाद होने वाली विफलता को अलग करना है।
1. DNS में एक नाम के लिए कई प्रकार के उत्तर होते हैं
DNS किसी डोमेन नाम से जुड़ी जानकारी अलग प्रकार के रिकॉर्ड में देता है। A, IPv4 का पता और AAAA, IPv6 का पता दर्शाता है; एक नाम के कई पते भी हो सकते हैं। CNAME दूसरे नाम की ओर इशारा करने वाला उपनाम है, MX मेल प्राप्त करने वाला सर्वर और NS संबंधित ज़ोन का प्रामाणिक नाम सर्वर बताता है। इसलिए एक ही नाम पूछने पर भी माँगे गए रिकॉर्ड का प्रकार बदलने से उत्तर बदल जाता है।
Cloudflare का DNS रिकॉर्ड विवरण बताता है कि CNAME का मान IP पता नहीं, दूसरा नाम होता है। पता चाहिए तो उस नाम का समाधान आगे जारी रह सकता है। साथ ही https://www.library.example/books में DNS के लिए होस्ट नाम www.library.example है। /books पथ या पेज की सामग्री DNS में दर्ज नहीं की जाती। CNAME लगाने से ब्राउज़र के पता-पट्टी को बदलने वाला HTTP पुनर्निर्देशन अपने आप नहीं बनता।
2. पुनरावर्ती रिज़ॉल्वर प्रामाणिक सर्वर तक कैसे पहुँचता है
उपकरण का नाम समाधान तंत्र सामान्यतः तय किए गए पुनरावर्ती रिज़ॉल्वर से उत्तर माँगता है। ज़रूरी जानकारी कैश में हो तो रिज़ॉल्वर उसका उपयोग करता है, नहीं हो तो दूसरे DNS सर्वर से पूछकर अंतिम उत्तर या त्रुटि लौटाता है। DNS शब्दावली मानक RFC 9499 इस तरह दूसरे की ओर से समाधान करने की भूमिका को अपने ज़ोन की जानकारी रखने वाले प्रामाणिक सर्वर से अलग करता है। उत्तर का स्रोत समझते समय देखना चाहिए कि सर्वर किस भूमिका में उत्तर दे रहा है।
कैश और बीच के अग्रेषक के बिना सरल प्रवाह में रिज़ॉल्वर को मूल सर्वर से शीर्ष-स्तरीय डोमेन के सर्वर का मार्गदर्शन मिलता है, और वहाँ से लक्ष्य ज़ोन के प्रामाणिक सर्वर का। अंत में प्रामाणिक सर्वर से वांछित रिकॉर्ड या उपनाम मिलता है। ऐसा नहीं है कि एक मूल सर्वर सभी वेबसाइटों के IP पते रखता है। व्यवहार में पहले से सहेजे गए प्रत्यायोजन से शुरुआत या दूसरे रिज़ॉल्वर को अग्रेषण हो सकता है, इसलिए हर बार साइट देखने पर पूरा क्रम दोहराना आवश्यक नहीं है।
3. TTL कैश में बचा समय है, पूरी दुनिया की घड़ी नहीं
रिकॉर्ड का TTL सेकंड में भेजी जाने वाली कैश आयु की जानकारी है। सामान्य कैश उत्तर में, संग्रहण के दौरान बचा समय घटता जाता है। उदाहरणतः रिज़ॉल्वर ने 10:00 पर TTL 300 सेकंड वाला पता सहेजा, तो उसी प्रति से 10:02 पर उत्तर देते समय बचा TTL लगभग 180 सेकंड होगा। नीचे की काल्पनिक समय-सारणी एक ऐसे रिज़ॉल्वर को मानती है जो दोबारा प्रश्न, अग्रिम नवीनीकरण या पुराने उत्तर देने का काम नहीं करता।
| काल्पनिक समय | प्रामाणिक सर्वर का पता | इस रिज़ॉल्वर का व्यवहार |
|---|---|---|
| 10:00 | पुराना पता | पुराने पते को TTL 300 सेकंड के साथ सहेजता है |
| 10:01 | नया पता कर दिया गया | सहेजी गई प्रति में अभी 240 सेकंड बाकी हैं |
| 10:03 | नया पता | शेष 120 सेकंड तक पुराना पता फिर उपयोग कर सकता है |
| 10:05 के बाद पहला प्रश्न | नया पता | मानते हैं कि समाप्त प्रति के बजाय फिर पूछकर नया पता मिलता है |
दूसरे रिज़ॉल्वर ने यह रिकॉर्ड बाद में सहेजा हो सकता है, या अभी देखा ही न हो। उनके नवीनीकरण समय अलग होने से एक TTL दुनिया के सभी उपयोगकर्ताओं के एक साथ बदलने का क्षण तय नहीं करता। कैश आयु पूरी होने से पहले भी जानकारी हटा सकता है, और वेब पेज ताज़ा करने से साझा रिज़ॉल्वर की प्रति नहीं मिटती। TTL, DNS उत्तर दोबारा उपयोग करने को समझने का संकेत है, पूरे वेब कनेक्शन या स्क्रीन अद्यतन की समय-सीमा नहीं।
4. TTL कब घटाएँ और ‘नहीं है’ उत्तर का कैश
जो कैश पहले पुराने पते को TTL 3,600 सेकंड के साथ ले गया, उसे अभी TTL 60 सेकंड करने की जानकारी तुरंत नहीं मिलती। नियोजित पता परिवर्तन में पहले TTL बदलें और पुराने लंबे जीवन वाले उत्तर बचने का समय ध्यान में रखें। कम TTL बदलाव अधिक बार जँचवा सकता है, पर प्रश्नों का बोझ और प्रामाणिक सर्वर पर निर्भरता भी बढ़ाता है। हर सेवा के लिए एक छोटा अंक लगाने के बजाय परिवर्तन योजना और विफलता से निपटने की तैयारी साथ देखें।
नाम मौजूद न होने का NXDOMAIN और नाम होने पर माँगे गए प्रकार का रिकॉर्ड न होने का NODATA भी कैश हो सकता है। नकारात्मक कैश मानक RFC 2308 नकारात्मक उत्तर की कैश आयु के लिए प्रामाणिक सर्वर के SOA रिकॉर्ड के TTL और SOA के MINIMUM मान में छोटे को लेने का नियम देता है। इसलिए पहले अनुपस्थित होस्ट जोड़ने के तुरंत बाद भी पुराना ‘नहीं है’ उत्तर बच सकता है। केवल नए A रिकॉर्ड का TTL देखकर उस उत्तर की आयु भी वही मान लें तो कारण छूट सकता है।
5. समान नाम, प्रकार और सर्वर तय करके जाँचें
जाँच में पूछे गए ठीक नाम, A या AAAA जैसा प्रकार, प्रश्न किए गए DNS सर्वर और समय को साथ लिखें। dig स्थापित हो तो dig example.com A की तरह नाम और प्रकार दे सकते हैं। वास्तविक समस्या की जाँच में example.com को अपने जाँचे जाने वाले होस्ट से बदलें। यह कमांड प्रक्रिया का उदाहरण है; इस लेख में इसे वास्तव में चलाया या उत्तर का समय मापा नहीं गया।
उत्तर की स्थिति के साथ ANSWER में नाम, प्रकार, मान और TTL देखें। उसी रिज़ॉल्वर से वही प्रश्न फिर पूछकर TTL घटने की जाँच करें, लेकिन मान बढ़े तो तुरंत त्रुटि न मानें। अग्रिम नवीनीकरण हुआ हो सकता है या कई कैश नोड में दूसरे ने उत्तर दिया हो। A और AAAA को मिलाने के बजाय अलग लिखने से पता चलता है कि किस पता परिवार में अंतर है।
संचालक अपने पुनरावर्ती रिज़ॉल्वर और प्रबंधित ज़ोन के प्रामाणिक सर्वर के उत्तर समान नाम व प्रकार के लिए मिला सकता है। अंतर होने पर क्रम से कैश का बचा समय, प्रामाणिक सर्वरों के डेटा की संगति और प्रत्यायोजन सेटिंग देखें। एक सार्वजनिक रिज़ॉल्वर का उत्तर सभी उपयोगकर्ताओं की स्थिति नहीं बताता। कंपनी नेटवर्क का आंतरिक DNS या ब्राउज़र की अलग DNS सेटिंग प्रश्न का मार्ग बदल सकती है, इसलिए तुलना में कनेक्शन का परिवेश भी दर्ज करें।
6. DNS त्रुटि, कनेक्शन त्रुटि और अपवाद अलग पढ़ें
NXDOMAIN नाम न होने का उत्तर है, और NODATA माँगे गए रिकॉर्ड प्रकार के न होने का मामला है। इसके विपरीत SERVFAIL सर्वर का प्रश्न संसाधित न कर पाना है, जबकि समय-समाप्ति का अर्थ तय प्रतीक्षा में उत्तर न मिलने का अवलोकन है। इन सबको ‘डोमेन मिट गया’ न समझें। पहले दर्ज करें कि उत्तर कोड आया या नहीं और किस सर्वर से पूछा था, तभी अगली जाँच तय की जा सकती है।
TTL गुज़रने के बाद पुराना उत्तर दिखना हमेशा नियम उल्लंघन नहीं है। RFC 8767 का serve-stale तरीका प्रामाणिक सर्वर से नवीनीकरण न हो सकने की अपवाद स्थिति में पुरानी जानकारी से उपलब्धता बढ़ाने का तरीका बताता है। इसका अर्थ सभी रिज़ॉल्वर का समान सेटिंग से इसे उपयोग करना नहीं है। इसलिए एक TTL से परिवर्तन लागू होने का समय तय करने के बजाय इस्तेमाल किए गए रिज़ॉल्वर का वास्तविक व्यवहार जाँचें।
अंततः पता सही मिलना भी वेबसाइट खुलने की गारंटी नहीं है। उस पते तक का नेटवर्क, TLS प्रमाणपत्र, वेब सर्वर और अनुप्रयोग अलग चरण हैं। DNS का उत्तर अपेक्षित पता हो लेकिन पेज न खुले, तो अगले कनेक्शन चरण पर जाँच ले जाएँ। नाम समाधान और वेब उत्तर अलग दर्ज करने से पेज कैश मिटाने या DNS सेटिंग अनियमित ढंग से बदलने से पहले विफलता का स्थान अधिक सही ढंग से सीमित किया जा सकता है।