DNS रिकॉर्ड तुलना — दो DNS ज़ोन या रिज़ॉल्वर की तुलना

DNS रिकॉर्ड क्या है?

DNS रिकॉर्ड (resource record) ज़ोन की एक एंट्री है: owner नाम, A, MX या TXT जैसा टाइप, सेकंड में TTL और उस टाइप का डेटा। एक ही नाम और टाइप के रिकॉर्ड मिलकर RRset बनाते हैं जिसे रिज़ॉल्वर ज़ोन के authoritative सर्वर से लाकर TTL तक कैश करते हैं — इसीलिए कोई बदलाव कैश की मियाद ख़त्म होने पर ही दिखता है।

DNS रिकॉर्ड तुलना कैसे इस्तेमाल करें

साइड A में डोमेन नाम लिखें या रिकॉर्ड पेस्ट करें (जैसे मौजूदा DNS प्रोवाइडर से एक्सपोर्ट किया ज़ोन)।
साइड B में वही करें जिससे तुलना करनी है — नए प्रोवाइडर का ज़ोन, दूसरा रिज़ॉल्वर या कोई दूसरा नाम।
लुकअप के लिए रिकॉर्ड टाइप और हर तरफ़ का रिज़ॉल्वर चुनें; सिर्फ़ डेटा मिलाना हो तो «owner नाम अनदेखा करें» चुनें।
«तुलना करें» दबाएँ और सिर्फ़ A या सिर्फ़ B वाली पंक्तियाँ निपटाएँ; «क्या मिलाया गया» पैनल बताता है कि हर तरफ़ कैसे पढ़ी गई।

DNS रिकॉर्ड तुलना की खूबियाँ

हर तरफ़ लाइव लुकअप (हर तरफ़ के लिए अलग Cloudflare या Google) या पेस्ट किए रिकॉर्ड — दोनों को मिला भी सकते हैं
dig की answer लाइनें, ज़ोन-फ़ाइल लाइनें ($ORIGIN, $TTL, @, कोष्ठक, इंडेंट की हुई continuation लाइनें) और सादा dig +short आउटपुट पढ़ता है
क्रम से स्वतंत्र तुलना, जो अक्षरों के केस, आख़िरी डॉट, स्पेसिंग और TXT स्ट्रिंग के बँटवारे को नज़रअंदाज़ करती है
हर रिकॉर्ड की एक टेबल — सिर्फ़ A में, सिर्फ़ B में या दोनों में — CSV में डाउनलोड करने लायक
TTL के फ़र्क़ असली फ़र्क़ से अलग, दोनों वैल्यू के साथ
दोनों तरफ़ पेस्ट हो तो तुलना पूरी तरह आपके ब्राउज़र में होती है; कुछ भी कहीं नहीं भेजा जाता

इनपुट और आउटपुट

इनपुट

साइड A और साइड B — हर एक या तो एक डोमेन नाम (लुकअप) या पेस्ट किए रिकॉर्ड (dig आउटपुट, ज़ोन-फ़ाइल लाइनें या dig +short आउटपुट)।
लुकअप के लिए रिकॉर्ड टाइप — डोमेन नाम वाली हर तरफ़ के लिए पूछा जाने वाला टाइप (डिफ़ॉल्ट A); एक तरफ़ लुकअप हो तो पेस्ट वाली तरफ़ सिर्फ़ उसी टाइप और CNAME के लिए मिलाई जाती है।
साइड A / साइड B का रिज़ॉल्वर — Cloudflare 1.1.1.1 या Google Public DNS, ताकि एक ही नाम दो रिज़ॉल्वर पर मिलाया जा सके।
owner नाम अनदेखा करें — सिर्फ़ टाइप और डेटा मिलाएँ; जब नाम मेल खा ही नहीं सकते तो अपने-आप लागू होता है।

आउटपुट

सारांश — नतीजा (= या ≠), कितने रिकॉर्ड सिर्फ़ A में, सिर्फ़ B में और दोनों में, और कितने साझा रिकॉर्ड सिर्फ़ TTL में अलग हैं।
रिकॉर्ड — हर अलग रिकॉर्ड का टाइप, नाम, डेटा, दोनों तरफ़ मौजूदगी और दोनों TTL।
निष्कर्ष — तुलना का फ़ैसला, TTL के फ़र्क़, अलग रखे गए रिकॉर्ड और owner नाम क्यों अनदेखे हुए।
क्या मिलाया गया — हर तरफ़ कैसे पढ़ी गई: लुकअप और उसका रिस्पॉन्स कोड, या पेस्ट किए रिकॉर्ड की संख्या और न पढ़ी जा सकी लाइनें।

DNS रिकॉर्ड तुलना का उदाहरण

माइग्रेशन से पहले एक ही ज़ोन के दो एक्सपोर्ट

इनपुट:

Side A: example.com. 3600 IN MX 10 mail1.example.net. · example.com. 3600 IN MX 20 mail2.example.net. · example.com. 300 IN TXT "v=spf1 include:_spf.example.net -all"
Side B: the same, with MX 20 at TTL 1800 and the SPF ending in ~all

आउटपुट:

Result: ≠ · Only in A: 1 · Only in B: 1 · In both: 2 · TTL differences: 1
TXT "v=spf1 include:_spf.example.net -all"   in A only
TXT "v=spf1 include:_spf.example.net ~all"   in B only
Findings: 1 record only on side A (TXT), 1 only on side B (TXT), 2 in common. 1 record on both sides with a different TTL: MX 20 mail2.example.net (3600 s vs 1800 s).

DNS रिकॉर्ड तुलना के नतीजे कैसे पढ़ें

"=": दोनों तरफ़ एक जैसे रिकॉर्ड हैं। दो लुकअप में सिर्फ़ TTL का फ़र्क़ कैश की उम्र है; दो ज़ोन फ़ाइलों में यह असली कॉन्फ़िगरेशन का फ़र्क़ है।

"सिर्फ़ A में" वाली पंक्तियाँ वे रिकॉर्ड हैं जो साइड B में नहीं (जैसे नए प्रोवाइडर पर बनाने हैं); "सिर्फ़ B में" वाली वे जो साइड A में नहीं (हटाने हैं, या पुरानी तरफ़ जोड़ने हैं)।

quoted TXT वैल्यू के अंदर का फ़र्क़ — जैसे SPF में -all बनाम ~all — असली पॉलिसी बदलाव है, फ़ॉर्मेटिंग नहीं।

जिन लाइनों के साथ "not understood" लिखा आए, वे तुलना में शामिल नहीं हुईं; उन्हें जाँचें, क्योंकि छूटी लाइन किसी ग़ायब रिकॉर्ड को छिपा सकती है।

DNS रिकॉर्ड तुलना कब इस्तेमाल करें

Nameserver बदलने से पहले: नए DNS प्रोवाइडर का ज़ोन पुराने से रिकॉर्ड-दर-रिकॉर्ड मिलाना।
बदलाव के दौरान एक ही नाम के लिए Cloudflare और Google रिज़ॉल्वर क्या लौटाते हैं, यह मिलाना।
जाँचना कि staging होस्ट और उसका production जोड़ीदार (www बनाम www-staging) एक जैसे रिकॉर्ड रखते हैं।
Pull request में ज़ोन-फ़ाइल बदलाव को लाइव स्थिति से मिलाकर रिव्यू करना।

समस्या निवारण

रिकॉर्ड एक जैसे हैं फिर भी सब अलग दिखता है: किसी तरफ़ relative नाम हो सकते हैं; पेस्ट किए टेक्स्ट में $ORIGIN लाइन जोड़ें या «owner नाम अनदेखा करें» चुनें।
लाइनों के साथ "not understood": हर लाइन में owner/TTL/class और डेटा के बीच रिकॉर्ड टाइप (A, MX, TXT…) होना चाहिए; dig +short आउटपुट तभी माना जाता है जब किसी लाइन में टाइप न हो।
जिस तरफ़ को लुकअप समझा था वह पेस्ट टेक्स्ट की तरह पढ़ी गई: लुकअप वाली तरफ़ में सिर्फ़ एक डोमेन नाम होना चाहिए, और कुछ नहीं।
दूसरे टाइप के रिकॉर्ड ग़ायब हो जाते हैं: एक तरफ़ लुकअप हो तो सिर्फ़ चुना टाइप (और CNAME) मिलाया जाता है; पूरे ज़ोन मिलाने हों तो दोनों तरफ़ पेस्ट करें।

DNS रिकॉर्ड तुलना के बारे में अक्सर पूछे जाने वाले सवाल

हर तरफ़ क्या डाल सकते हैं?

या तो एक डोमेन नाम, जो उस तरफ़ के लिए चुने रिकॉर्ड टाइप और रिज़ॉल्वर से लाइव लुकअप होता है, या पेस्ट किए रिकॉर्ड: dig की answer लाइनें, ज़ोन-फ़ाइल लाइनें ($ORIGIN, $TTL, @ और कोष्ठक के साथ) या सादा dig +short आउटपुट, जिसे चुने गए रिकॉर्ड टाइप का माना जाता है।

कौन-से फ़र्क़ नज़रअंदाज़ होते हैं?

क्रम, होस्ट नामों में अक्षरों का केस, आख़िरी डॉट, quotes के बाहर की स्पेसिंग, IPv6 एड्रेस लिखने का तरीक़ा और लंबे TXT रिकॉर्ड का स्ट्रिंग में बँटवारा। quotes के अंदर का हिस्सा हूबहू मिलाया जाता है, और TTL अलग दिखाए जाते हैं क्योंकि वे आमतौर पर बदलाव नहीं, कैश की उम्र बताते हैं।

क्या पेस्ट किए रिकॉर्ड किसी सर्वर को भेजे जाते हैं?

नहीं। दोनों तरफ़ पेस्ट हो तो तुलना पूरी तरह आपके ब्राउज़र में चलती है। सिर्फ़ डोमेन नाम वाली तरफ़ से लुकअप होता है, और तब भी सिर्फ़ वह नाम और रिकॉर्ड टाइप Mutqan सर्वर के ज़रिए चुने रिज़ॉल्वर को जाता है।

nameserver बदलने से पहले पुराने और नए DNS प्रोवाइडर की तुलना कैसे करूँ?

नए प्रोवाइडर का ज़ोन एक्सपोर्ट एक तरफ़ पेस्ट करें और लाइव डोमेन नाम दूसरी तरफ़ रखें — लुकअप हर रन में एक रिकॉर्ड टाइप मिलाता है — या पूरे ज़ोन मिलाने के लिए दोनों प्रोवाइडर के एक्सपोर्ट पेस्ट करें। जो रिकॉर्ड सिर्फ़ A या सिर्फ़ B में हैं, वही आपको बनाने या हटाने हैं।

owner नाम क्यों अनदेखे किए गए?

जब दोनों तरफ़ अलग-अलग नाम लुकअप हों, या एक तरफ़ लुकअप और दूसरी तरफ़ पेस्ट किया टेक्स्ट हो, तो owner नाम मेल नहीं खा सकते, इसलिए सिर्फ़ टाइप और डेटा मिलाए जाते हैं। दो पेस्ट किए सेट के लिए भी ऐसा करना हो तो «owner नाम अनदेखा करें» चुनें।

तकनीकी नोट्स

तुलना से पहले रिकॉर्ड डेटा normalize किया जाता है: एड्रेस अपने canonical रूप में (RFC 5952 या dotted), होस्ट नाम छोटे अक्षरों में और आख़िरी डॉट के बिना, TXT की character-strings RFC 7208 §3.3 की तरह जोड़ी और unescape की जाती हैं, CAA टैग का केस एक जैसा किया जाता है। quoted स्ट्रिंग के अंदर कुछ नहीं बदलता, इसलिए "-all" और "~all" अलग ही रहते हैं।

पेस्ट किया टेक्स्ट RFC 1035 §5 के master-file फ़ॉर्मेट पर चलता है: owner, वैकल्पिक TTL और class, टाइप, डेटा; $ORIGIN relative नाम पूरे करता है (NS, CNAME, MX, SRV और SOA डेटा के अंदर भी), $TTL डिफ़ॉल्ट TTL देता है, और कोष्ठक SOA जैसे कई लाइनों वाले रिकॉर्ड जोड़ते हैं। लुकअप वाली तरफ़ रिज़ॉल्वर से एक RRset लौटाती है, CNAME चेन समेत।

सीमाएँ और कार्यप्रणाली

लुकअप वाली तरफ़ Cloudflare एज से एक पब्लिक रिज़ॉल्वर के ज़रिए एक नाम का एक रिकॉर्ड टाइप पूछती है; यह कैश किया नज़रिया है, authoritative ज़ोन नहीं (उसके लिए Nameserver Checker)।

पार्सर आम master-file सिंटैक्स समझता है; $INCLUDE, $GENERATE और 1h जैसी TTL इकाइयाँ expand नहीं होतीं, और सिर्फ़ पहली 5,000 लाइनें पढ़ी जाती हैं।

लुकअप से लौटे DNSSEC सिग्नेचर (RRSIG) तुलना से बाहर रखे जाते हैं।

सुरक्षा और गोपनीयता

पेस्ट किए रिकॉर्ड आपके ब्राउज़र में पार्स होते हैं और कभी नहीं भेजे जाते। डोमेन नाम वाली तरफ़ सिर्फ़ वह नाम और रिकॉर्ड टाइप Mutqan सर्वर से उस तरफ़ के चुने रिज़ॉल्वर को भेजती है; कुछ भी स्टोर नहीं होता।

संदर्भ

RFC 1035: Domain Names - Implementation and SpecificationIETFDNS संदेश का फ़ॉर्मेट, रिकॉर्ड टाइप और रिस्पॉन्स कोड (NOERROR, NXDOMAIN, SERVFAIL, REFUSED) जिन्हें हर रिज़ॉल्वर आज भी इस्तेमाल करता है।
RFC 1034: Domain names - concepts and facilitiesIETFDNS का मॉडल: नाम-स्थान एक ट्री के रूप में, ज़ोन और delegation, authoritative सर्वर और रिज़ॉल्वर, और रिज़ॉल्वर referral व alias कैसे फ़ॉलो करता है।
RFC 2181: Clarifications to the DNS SpecificationIETF · 1997ऐसे नियम जो मूल DNS RFC में खुले छोड़े गए थे: एक RRset का एक ही TTL, TTL की सीमाएँ, और यह कि MX व NS का target alias (CNAME) नहीं हो सकता।