DNSSEC चेकर

सर्वर सहायता नया DNS और डोमेन

चेकर root ज़ोन से डोमेन तक DNSSEC की chain of trust फ़ॉलो करता है: हर पैरेंट पर DS रिकॉर्ड, हर ज़ोन का DNSKEY सेट key tag और KSK/ZSK भूमिका के साथ, और सिग्नेचर (RRSIG) लौटे या नहीं। validating रिज़ॉल्वर से जाँच चालू और बंद, दोनों तरह पूछा जाता है, ताकि टूटा (bogus) ज़ोन बिना साइन वाले से अलग पहचाना जा सके, और हर कड़ी secure, insecure, bogus या unknown बताई जाती है।

गोपनीयता: आप जो नाम खोजते हैं वह Mutqan सर्वर से नतीजों में बताए गए सार्वजनिक DNS रिज़ॉल्वर को भेजा जाता है। कुछ भी स्टोर नहीं होता।

DNSSEC क्या है?

DNSSEC (RFC 4033–4035) DNS रिकॉर्ड में सिग्नेचर जोड़ता है ताकि validating रिज़ॉल्वर साबित कर सके कि जवाब ज़ोन से बिना बदले आया है। भरोसा एक चेन में नीचे आता है: root ज़ोन की कुंजी हर TLD की DS रिकॉर्ड के ज़रिए गवाही देती है, TLD हर डोमेन की, और इसी तरह आगे; जिस ज़ोन का पैरेंट पर DS नहीं वह insecure (unsigned) है, और जिसकी चेन validate नहीं होती वह bogus है और validating रिज़ॉल्वर पर resolve होना बंद कर देता है।

सुरक्षा नोट: टूटी DNSSEC चेन (bogus) validating रिज़ॉल्वर इस्तेमाल करने वालों के लिए पूरा डोमेन बंद कर देती है; कुंजियाँ या DNS प्रोवाइडर सिर्फ़ योजनाबद्ध rollover के साथ बदलें।

DNSSEC चेकर कैसे इस्तेमाल करें

  1. डोमेन या होस्ट नाम लिखें, जैसे example.com या www.example.com।
  2. «DNSSEC जाँचें» दबाएँ। Mutqan सर्वर Cloudflare के validating रिज़ॉल्वर से चेन फ़ॉलो करता है।
  3. परिणाम और AD फ़्लैग पढ़ें, फिर चेन टेबल root से नीचे की ओर देखें: पहली कड़ी जो secure नहीं, वहीं सुरक्षा रुकती या टूटती है।
  4. अगला क़दम अपनाएँ: रजिस्ट्रार पर DS पब्लिश करें, टूटी चेन ठीक करें, या कुंजी rollover की योजना बनाएँ।

DNSSEC चेकर की खूबियाँ

  • root ज़ोन से TLD होते हुए डोमेन तक chain of trust, हर ज़ोन की एक पंक्ति
  • हर पैरेंट पर DS रिकॉर्ड और हर ज़ोन का DNSKEY सेट, key tag, एल्गोरिदम और KSK/ZSK भूमिका के साथ
  • हर कड़ी secure, insecure, bogus या unknown के रूप में, कारण सरल भाषा में
  • रिज़ॉल्वर से जाँच चालू और बंद करके पूछना, ताकि bogus को unsigned से और nameserver की विफलता से अलग किया जा सके
  • नाम के लिए रिज़ॉल्वर का AD फ़्लैग — वही जवाब जो validating रिज़ॉल्वर आपके यूज़र को देता है
  • वे signing एल्गोरिदम जिन्हें RFC 8624 signing के लिए MUST NOT या NOT RECOMMENDED बताता है (RSA/SHA-1, RSA/SHA-512, DSA, GOST), SHA-1 वाले DS digest, और REVOKE फ़्लैग वाली कुंजियों की सूचना
  • विफल क्वेरी उस स्तर के लिए unknown दिखती है, कभी signed या unsigned नहीं

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

इनपुट

  • डोमेन नाम — डोमेन या होस्ट नाम, नाम या URL के रूप में; internationalised नाम भी चलते हैं। IP एड्रेस स्वीकार नहीं होते, क्योंकि DNSSEC नामों को बचाता है।
  • टूल द्वारा तय — रिज़ॉल्वर (Cloudflare 1.1.1.1), क्वेरी (नाम के लिए A, हर ज़ोन के लिए DS और DNSKEY, root का DNSKEY) और DNSSEC फ़्लैग (DO चालू, CD चालू और बंद); सेट करने को और कुछ नहीं।

आउटपुट

  • सारांश — परिणाम, जवाब प्रमाणित हुआ या नहीं (AD फ़्लैग), चेन में ज़ोन की संख्या और की गई DNS क्वेरी।
  • chain of trust — root से हर ज़ोन की एक पंक्ति: स्थिति, पैरेंट पर DS रिकॉर्ड (key tag, एल्गोरिदम, digest टाइप), DNSKEY रिकॉर्ड (भूमिका, key tag, एल्गोरिदम), सिग्नेचर लौटे या नहीं, और एक नोट।
  • निष्कर्ष — रिज़ॉल्वर के जवाब क्या दिखाते हैं, हटाए जा रहे एल्गोरिदम और digest, रद्द हो रही कुंजियाँ, और वे स्तर जो जाँचे नहीं जा सके।
  • आगे क्या करें — परिणाम से निकलने वाला अगला क़दम।

DNSSEC चेकर का उदाहरण

signed TLD के नीचे ECDSA P-256 से साइन डोमेन (cloudflare.com, अक्टूबर 2026)

इनपुट:

cloudflare.com

आउटपुट:

परिणाम: साइन और validated (रिज़ॉल्वर ने जवाब प्रमाणित किया) · प्रमाणित (AD फ़्लैग): हाँ · चेन में ज़ोन: 3 · DNS क्वेरी: 7
chain of trust:
root ज़ोन (.) — secure: trust anchor — root ज़ोन की कुंजियाँ (trust anchor)।
com — secure: साइन है और पैरेंट से जुड़ा है — DS 19718 · ECDSAP256SHA256 · SHA-256 — DNSKEY …, KSK 19718 (ECDSAP256SHA256)
cloudflare.com — secure: साइन है और पैरेंट से जुड़ा है — DS 2371 · ECDSAP256SHA256 · SHA-256 — DNSKEY ZSK 34505 (ECDSAP256SHA256), KSK 2371 (ECDSAP256SHA256)
निष्कर्ष: रिज़ॉल्वर ने इस नाम का जवाब validate किया (AD फ़्लैग लगा) — cloudflare.com

DNSSEC चेकर के नतीजे कैसे पढ़ें

«साइन और validated»: root से हर कड़ी secure है और रिज़ॉल्वर ने AD फ़्लैग लगाया; validating रिज़ॉल्वर के यूज़र को इस नाम के प्रमाणित जवाब मिलते हैं।

«साइन नहीं (insecure)»: चेन में कहीं DS रिकॉर्ड नहीं — अक्सर डोमेन पर ही। जवाब बिना प्रमाणीकरण के माने जाते हैं; ज़्यादातर डोमेन इसी हाल में हैं और यह ग़लती नहीं है।

«ज़ोन साइन हैं, जवाब प्रमाणित नहीं»: दिखाया गया हर ज़ोन साइन है और जुड़ा है, फिर भी रिज़ॉल्वर ने इस नाम का जवाब प्रमाणित नहीं किया — अक्सर इसलिए कि नाम CNAME के ज़रिए बिना DNSSEC वाले ज़ोन की ओर जाता है। यूज़र को वह जवाब बिना प्रमाणीकरण के मिलता है।

«टूटा हुआ (bogus)»: DS मौजूद है पर उसके नीचे की कुंजियाँ या सिग्नेचर validate नहीं होते। validating रिज़ॉल्वर — 1.1.1.1, 8.8.8.8, 9.9.9.9 और कई ISP रिज़ॉल्वर — SERVFAIL देते हैं, और उनके यूज़र के लिए नाम resolve होना बंद हो जाता है।

«लुकअप विफल»: नाम जाँच चालू और बंद, दोनों में fail होता है, जो DNSSEC नहीं बल्कि nameserver की ओर इशारा करता है।

«DNSKEY पब्लिश है पर पैरेंट पर DS नहीं»: ज़ोन साइन है, पर जब तक रजिस्ट्रार पर DS पब्लिश न हो, कोई उसके सिग्नेचर verify नहीं कर सकता।

DNSSEC चेकर कब इस्तेमाल करें

  • साइनिंग चालू करने और रजिस्ट्रार पर DS पब्लिश करने के बाद पक्का करना कि DNSSEC काम कर रहा है।
  • ऐसे डोमेन की जाँच जो अचानक 1.1.1.1 या 8.8.8.8 पर resolve होना बंद हो गया पर बाक़ी जगह चलता है।
  • दूसरे DNS प्रोवाइडर या रजिस्ट्रार पर ले जाने से पहले डोमेन जाँचना, जब पुराना DS उसे तोड़ सकता है।
  • यह ऑडिट करना कि आपके कौन-से डोमेन साइन हैं और किन एल्गोरिदम से।

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

  • DNS प्रोवाइडर बदलते ही «टूटा हुआ (bogus)»: रजिस्ट्रार के पास अब भी पुराने प्रोवाइडर की कुंजी का DS है। उसे नए प्रोवाइडर के DS से बदलें, या नया ज़ोन साइन होने तक हटा दें; पुराना DS कैश से निकलते ही रिज़ॉल्वर ठीक हो जाते हैं।
  • «DNSKEY पब्लिश है पर पैरेंट पर DS नहीं»: DS (या रजिस्ट्रार माँगे तो DNSKEY) अपने DNS प्रोवाइडर से रजिस्ट्रार की DNSSEC सेटिंग में कॉपी करें।
  • «कोई DNSKEY पैरेंट के DS के key tag और एल्गोरिदम से मेल नहीं खाती»: रजिस्ट्रार का DS किसी पुरानी या दूसरी कुंजी का है। मौजूदा KSK का DS पब्लिश करें।
  • परिणाम «तय नहीं हो सका»: किसी स्तर की क्वेरी विफल हुई या समय पर नहीं आई। दोबारा जाँचें; जो स्तर बार-बार विफल हो, उसके nameserver DNSSEC क्वेरी का ठीक जवाब नहीं देते।
  • अनुरोध-सीमा वाला संदेश: एक DNSSEC जाँच में 7 से 11 DNS क्वेरी लगती हैं, जो बाक़ी DNS टूल्स के साथ साझा बजट से जाती हैं; दिखाए गए सेकंड रुकें।

DNSSEC चेकर के बारे में अक्सर पूछे जाने वाले सवाल

DNSSEC में insecure और bogus में क्या फ़र्क़ है?

insecure का मतलब है कि ज़ोन साइन नहीं है या पैरेंट से जुड़ा नहीं (DS रिकॉर्ड नहीं): रिज़ॉल्वर उसके जवाब बिना प्रमाणीकरण के मान लेते हैं। bogus का मतलब है कि ज़ोन साइन होने का दावा करता है पर चेन validate नहीं होती; तब 1.1.1.1, 8.8.8.8 और Quad9 जैसे validating रिज़ॉल्वर SERVFAIL देते हैं और उनके यूज़र के लिए डोमेन resolve होना बंद हो जाता है।

मेरा डोमेन साइन है फिर भी insecure क्यों दिखता है?

ज़ोन साइन करने से DNSKEY और RRSIG रिकॉर्ड पब्लिश होते हैं, पर chain of trust तभी शुरू होती है जब key-signing key का DS रिकॉर्ड पैरेंट ज़ोन में पब्लिश हो। ज़्यादातर रजिस्ट्रार के कंट्रोल पैनल में DS जोड़ना (या DNSSEC चालू करना) पड़ता है; तब तक चेकर «DNSKEY पब्लिश है पर पैरेंट पर DS नहीं» दिखाता है।

चेकर कैसे तय करता है कि ज़ोन secure है?

यह DNSSEC माँगते हुए Cloudflare के validating रिज़ॉल्वर से पूछता है: AD फ़्लैग बताता है कि रिज़ॉल्वर ने जवाब validate किया, और DS व DNSKEY रिकॉर्ड दिखाते हैं कि हर स्तर पर पैरेंट के DS से मेल खाती कुंजी मौजूद है। जाँच बंद करके की गई दूसरी क्वेरी bogus ज़ोन को nameserver की विफलता से अलग करती है। टूल रिज़ॉल्वर का फ़ैसला बताता है; सिग्नेचर ख़ुद verify नहीं करता।

साइन किए डोमेन को दूसरे DNS प्रोवाइडर पर ले जाने से पहले क्या करें?

कुंजी बदलने की योजना बनाएँ: या तो रजिस्ट्रार से DS हटाएँ और बदलने से पहले उसका TTL ख़त्म होने दें, या नया प्रोवाइडर ट्रांसफ़र के दौरान आपकी कुंजियाँ भी पब्लिश करे (multi-signer rollover)। पुराना DS पैरेंट पर छोड़कर nameserver बदलने से डोमेन bogus हो जाता है।

DNSSEC चेकर कौन-से नाम जाँचता है?

root ज़ोन, टॉप-लेवल डोमेन और आपके लिखे नाम तक हर स्तर, ज़्यादा से ज़्यादा चार ज़ोन स्तर; ज़्यादा गहरे नामों में बीच के स्तर छोड़ दिए जाते हैं और रिपोर्ट उनकी गिनती बताती है। जो स्तर अलग ज़ोन नहीं, उन्हें ऊपर वाला ज़ोन ढकता है और वे एक नोट के साथ छोड़ दिए जाते हैं।

तकनीकी नोट्स

DNSSEC (RFC 4033, 4034 और 4035) ज़ोन के हर रिकॉर्ड सेट को RRSIG रिकॉर्ड से साइन करता है, जो DNSKEY रिकॉर्ड में पब्लिश ज़ोन की कुंजियों से बनते हैं: आम तौर पर एक key-signing key (KSK, फ़्लैग 257) जो कुंजी सेट साइन करती है, और एक zone-signing key (ZSK, फ़्लैग 256) जो बाक़ी सब। पैरेंट ज़ोन DS रिकॉर्ड से child की गवाही देता है, जो child की KSK का digest है; root ज़ोन की कुंजियाँ trust anchor हैं जहाँ से validating रिज़ॉल्वर शुरू करते हैं, इसलिए भरोसा root → TLD → डोमेन की ओर बहता है।

चेकर DNSSEC माँगते हुए Cloudflare के validating रिज़ॉल्वर से नाम पूछता है: AD फ़्लैग बताता है कि रिज़ॉल्वर ने जवाब validate किया। root, TLD और नाम तक हर स्तर (ज़्यादा से ज़्यादा चार ज़ोन स्तर) के लिए यह DS और DNSKEY रिकॉर्ड लाता है और जाँचता है कि कोई कुंजी DS के key tag और एल्गोरिदम से मेल खाती है। जाँच बंद (CD बिट, RFC 6840) वाली दूसरी क्वेरी bogus ज़ोन — जो सिर्फ़ जाँच चालू होने पर fail होता है — को nameserver विफलता से, जो दोनों तरह fail होती है, और unsigned ज़ोन से, जो दोनों तरह बिना AD के एक-सा जवाब देता है, अलग करती है।

सिग्नेचर रिज़ॉल्वर verify करता है, टूल नहीं; पेज रिज़ॉल्वर का फ़ैसला और उसके पीछे के रिकॉर्ड बताता है। जो स्तर अलग ज़ोन नहीं, वे एक नोट के साथ छूट जाते हैं, और चार स्तर से गहरे नामों में बीच के स्तर छोड़कर गिने जाते हैं।

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

validation Cloudflare की है: टूल रिज़ॉल्वर का AD फ़्लैग और SERVFAIL व्यवहार बताता है, सिग्नेचर ख़ुद verify नहीं करता। पुराने कैश वाला कोई दूसरा रिज़ॉल्वर कुछ देर के लिए अलग नतीजा दे सकता है।

ज़्यादा से ज़्यादा चार ज़ोन स्तर जाँचे जाते हैं; गहरे नामों में बीच के स्तर छूट जाते हैं, और उनकी कोई दिक़्क़त सिर्फ़ अंतिम परिणाम में दिखती है।

सिर्फ़ नाम की A क्वेरी validate होती है; उसी नाम के किसी दूसरे रिकॉर्ड टाइप (MX, TXT…) पर टूटा सिग्नेचर यहाँ नहीं दिखेगा।

जाँच आपके नेटवर्क से नहीं, Cloudflare एज पर चल रहे Mutqan सर्वर से होती है, इसलिए यह नहीं दिखाती कि आपका अपना रिज़ॉल्वर DNSSEC validate करता है या नहीं।

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

आपका लिखा नाम Mutqan सर्वर तक जाता है, जो HTTPS पर Cloudflare के पब्लिक DNS से उस नाम और उसके ऊपर के ज़ोन के DS और DNSKEY रिकॉर्ड पूछता है। कुछ भी स्टोर नहीं होता।

संदर्भ

  • RFC 4033: DNS Security Introduction and RequirementsIETF · 2005DNSSEC क्या बचाता है और क्या नहीं, trust anchor से शुरू होने वाली chain of trust, और secure, insecure व bogus जवाबों का मतलब।
  • RFC 4034: Resource Records for the DNS Security ExtensionsIETF · 2005DNSKEY, RRSIG, DS और NSEC रिकॉर्ड, key tag की गणना, और वे फ़्लैग जो key-signing key को पहचानते हैं।
  • RFC 4035: Protocol Modifications for the DNS Security ExtensionsIETF · 2005रिज़ॉल्वर सिग्नेचर कैसे माँगते और जाँचते हैं: DO बिट, प्रमाणित जवाब बताने वाला AD फ़्लैग, और जाँच बंद करने वाला CD बिट।