CAA रिकॉर्ड चेकर

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

चेकर होस्ट नाम के CAA रिकॉर्ड देखता है, और न मिलें तो RFC 8659 के अनुसार सर्टिफ़िकेट अथॉरिटी (CA) की तरह एक-एक करके हर पैरेंट डोमेन पर। यह बताता है कि किस नाम का CAA सेट लागू होता है, कौन-सी CA सामान्य और wildcard सर्टिफ़िकेट जारी कर सकती हैं, उल्लंघन रिपोर्ट के लिए iodef पता क्या है, और accounturi व validationmethods (RFC 8657) जैसे पैरामीटर।

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

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

CAA रिकॉर्ड (RFC 8659) बताता है कि कौन-सी सर्टिफ़िकेट अथॉरिटी किसी डोमेन के लिए सर्टिफ़िकेट जारी कर सकती हैं: सामान्य सर्टिफ़िकेट के लिए issue, wildcard के लिए issuewild, और उल्लंघन की रिपोर्ट कहाँ भेजें इसके लिए iodef। पब्लिक रूप से trusted CA को जारी करने से पहले इसे जाँचना होता है: वे नाम देखते हैं, फिर उसके पैरेंट डोमेन तक चढ़ते हैं, और सबसे नज़दीकी CAA सेट लागू होता है; कहीं भी न हो तो कोई भी CA जारी कर सकता है।

CAA रिकॉर्ड चेकर कैसे इस्तेमाल करें

  1. वह नाम लिखें जिसके लिए सर्टिफ़िकेट चाहिए — www.example.com, या wildcard *.example.com के लिए example.com।
  2. चाहें तो किसी CA का CAA डोमेन लिखें, जैसे letsencrypt.org, ताकि उसकी जाँच हो।
  3. «CAA जाँचें» दबाएँ और पढ़ें कि किस नाम का CAA सेट लागू है और कौन जारी कर सकता है।
  4. निष्कर्ष पढ़ें; नीति बदलनी हो तो दिखाए गए नाम पर CAA रिकॉर्ड बदलें और दोबारा जाँचें।

CAA रिकॉर्ड चेकर की खूबियाँ

  • RFC 8659 वाली CAA चढ़ाई आपके लिए: पहले नाम, फिर हर पैरेंट डोमेन, जब तक CAA सेट न मिले
  • किस नाम का CAA सेट लागू है, और उसका हर रिकॉर्ड: फ़्लैग, प्रॉपर्टी, वैल्यू और उसका मतलब
  • सामान्य सर्टिफ़िकेट कौन जारी कर सकता है और wildcard कौन — RFC के मुताबिक़ issuewild को issue पर प्राथमिकता के साथ
  • किसी एक CA की वैकल्पिक जाँच: CAA के लिए वह जो डोमेन बताती है (letsencrypt.org, pki.goog, digicert.com…) लिखें और देखें कि वह जारी कर सकती है या नहीं
  • जारी करना रोकने वाली सेटिंग पर चेतावनी: issue ";", ग़लत वैल्यू और critical चिह्नित अनजानी प्रॉपर्टी
  • accounturi और validationmethods पैरामीटर (RFC 8657) और iodef रिपोर्ट पते, जैसे पब्लिश हुए
  • विफल लुकअप चढ़ाई रोक देता है और नतीजा «अज्ञात» दिखता है, कभी «CAA नहीं» नहीं — और रास्ते में अनुरोध-सीमा या timeout को वैसा ही बताया जाता है, आपके DNS की ख़राबी नहीं

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

इनपुट

  • डोमेन या होस्ट नाम — वह नाम जो सर्टिफ़िकेट में होगा; wildcard (*.example.com) के लिए चढ़ाई example.com से शुरू होती है, और आगे का "*." अपने-आप हट जाता है।
  • जाँचने वाली सर्टिफ़िकेट अथॉरिटी (वैकल्पिक) — CA का वह CAA डोमेन जो वह ख़ुद बताती है, जैसे letsencrypt.org, pki.goog, sectigo.com या digicert.com।

आउटपुट

  • सारांश — किस नाम का CAA सेट लागू है, और कितनी CA सामान्य व wildcard सर्टिफ़िकेट जारी कर सकती हैं, या «कोई भी CA»।
  • जाँचे गए नाम — चढ़ाई का हर नाम अपने नतीजे के साथ: CAA रिकॉर्ड मिले, CAA रिकॉर्ड नहीं, बिना रिकॉर्ड वाला alias, NXDOMAIN या विफल लुकअप।
  • लागू CAA रिकॉर्ड — हर रिकॉर्ड अपने flags, property, वैल्यू और मतलब के साथ।
  • कौन जारी कर सकता है — सर्टिफ़िकेट और wildcard के लिए अनुमत CA डोमेन, और iodef पते।
  • निष्कर्ष और आगे क्या करें — सरल भाषा में मूल्यांकन, जिसमें आपकी जाँची CA का जवाब भी है।

CAA रिकॉर्ड चेकर का उदाहरण

पैरेंट के CAA सेट से ढका सबडोमेन (docs.github.com, अक्टूबर 2026)

इनपुट:

docs.github.com

आउटपुट:

लागू CAA सेट: github.com (पैरेंट डोमेन पर मिला) · सर्टिफ़िकेट: 4 · wildcard सर्टिफ़िकेट: 3
जाँचे गए नाम: docs.github.com — कोई CAA रिकॉर्ड नहीं · github.com — CAA रिकॉर्ड मिले
कौन जारी कर सकता है — सर्टिफ़िकेट: digicert.com, globalsign.com, letsencrypt.org, sectigo.com · wildcard सर्टिफ़िकेट: digicert.com, letsencrypt.org, sectigo.com · उल्लंघन रिपोर्ट (iodef): —
निष्कर्ष: नाम के अपने CAA रिकॉर्ड नहीं हैं; पैरेंट डोमेन पर पब्लिश हुआ सेट उस पर लागू होता है — github.com

CAA रिकॉर्ड चेकर के नतीजे कैसे पढ़ें

«कोई भी CA»: कोई CAA सेट लागू नहीं, या सेट में न issue है न issuewild; CAA जारी करने पर रोक नहीं लगाता, और आपका डोमेन validate करने वाली कोई भी पब्लिक रूप से trusted CA जारी कर सकती है।

CA की सूची: सिर्फ़ यही CA इस नाम के लिए जारी कर सकती हैं। सूची से बाहर की CA को मना करना होगा — उस CA को भी जिस पर आपका CDN या होस्टिंग प्रोवाइडर निर्भर है।

«कोई CA नहीं»: सेट जारी करना रोकता है — सामान्य सर्टिफ़िकेट के लिए issue ";", wildcard के लिए issuewild ";", या कोई critical प्रॉपर्टी जिसे CA नहीं समझती।

पैरेंट डोमेन पर मिला: नाम के अपने रिकॉर्ड नहीं, इसलिए वह पैरेंट का सेट अपनाता है। नाम पर रिकॉर्ड तभी जोड़ें जब उसे अलग नीति चाहिए।

«अज्ञात — एक लुकअप विफल»: चढ़ाई के किसी नाम पर रिज़ॉल्वर ने SERVFAIL, REFUSED या कोई और ग़लती लौटाई। यही ग़लती पाने वाली CA जारी करने से मना कर सकती है, इसलिए पहले DNS ठीक करें।

«अज्ञात — जाँच पूरी नहीं हुई» या «अज्ञात — चढ़ाई बीच में रुक गई»: कोई लुकअप अनुरोध-सीमा, timeout या नेटवर्क की ग़लती से रुक गया, या नाम में 20 से ज़्यादा स्तर हैं। ज़ोन के बारे में कोई नतीजा नहीं निकाला जाता; दोबारा जाँचें, या पेज पर बताया अगला पैरेंट डोमेन जाँचें।

CAA रिकॉर्ड चेकर कब इस्तेमाल करें

  • पता करना कि किसी CA ने CAA ग़लती के साथ सर्टिफ़िकेट जारी या रिन्यू करने से क्यों मना किया।
  • नए प्रोवाइडर — CDN, होस्टिंग प्लेटफ़ॉर्म, managed सर्टिफ़िकेट सेवा — पर जाने से पहले देखना कि उसे अनुमति है।
  • जारी करना सिर्फ़ उन CA तक सीमित करना जिन्हें आप इस्तेमाल करते हैं, और wildcard सिर्फ़ वहाँ जहाँ ज़रूरत है।
  • दूसरी टीमों या वेंडरों के चलाए सबडोमेन की समीक्षा, जो अपना CAA पब्लिश न करें तो पैरेंट का अपनाते हैं।

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

  • डोमेन में CA का नाम होते हुए भी CAA ग़लती: CA का बताया सटीक CAA डोमेन जाँचें (जैसे Google Trust Services का pki.goog है), और देखें कि नाम wildcard तो नहीं, जिस पर issue की जगह issuewild लागू होता है।
  • नाम किसी प्रोवाइडर का alias (CNAME) है: CAA जवाब alias target से आता है, और चढ़ाई आपके पैरेंट डोमेन तक तभी जाती है जब उस target पर कोई CAA रिकॉर्ड न हो। target पर सख़्त सेट उसका मालिक ही बदल सकता है।
  • «अज्ञात — एक लुकअप विफल»: authoritative सर्वरों ने CAA क्वेरी का जवाब ग़लती से दिया। कुछ पुराने DNS सर्वर CAA टाइप ठुकरा देते हैं; Nameserver Checker से उन्हें जाँचें और DNS सॉफ़्टवेयर अपडेट करें या प्रोवाइडर बदलें।
  • अनुरोध-सीमा वाला संदेश: चढ़ाई का हर नाम DNS टूल्स के आपके हिस्से से एक DNS क्वेरी है; दिखाए गए सेकंड रुककर फिर कोशिश करें। चढ़ाई के बीच सीमा आ जाए तो नतीजा «अज्ञात — जाँच पूरी नहीं हुई» दिखता है।

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

अगर डोमेन पर कोई CAA रिकॉर्ड न हो तो क्या होता है?

CAA वैकल्पिक है। अगर न नाम पर और न किसी पैरेंट डोमेन पर CAA रिकॉर्ड है, तो कोई भी पब्लिक रूप से trusted CA उसके लिए सर्टिफ़िकेट जारी कर सकती है, बशर्ते डोमेन validation सफल हो।

क्या example.com का CAA रिकॉर्ड www.example.com पर भी लागू होता है?

हाँ, जब तक www.example.com के अपने CAA रिकॉर्ड न हों। CA पहले नाम देखती है और फिर एक-एक लेबल हटाकर पैरेंट डोमेन तक चढ़ती है; जो पहला CAA सेट मिले वही लागू होता है, और चेकर बताता है कि वह किस नाम पर मिला।

issue और issuewild में क्या फ़र्क़ है?

issue उन CA के नाम देता है जो उस नाम के लिए सर्टिफ़िकेट जारी कर सकती हैं; issuewild उनके जो wildcard सर्टिफ़िकेट (*.example.com) जारी कर सकती हैं। issuewild रिकॉर्ड न हो तो wildcard पर भी issue लागू होता है। ";" वैल्यू किसी भी CA को अनुमति नहीं देती।

CAA में किसी CA को अनुमति कैसे दें?

उस डोमेन के साथ रिकॉर्ड जोड़ें जो वह CA, CAA के लिए बताती है, जैसे Let's Encrypt के लिए 0 issue "letsencrypt.org" या Google Trust Services के लिए 0 issue "pki.goog"। जिस-जिस CA का इस्तेमाल करते हैं, हर एक का issue रिकॉर्ड रखें, और याद रखें कि आपका CDN या होस्टिंग प्रोवाइडर अपनी CA से सर्टिफ़िकेट जारी करवा सकता है।

क्या CAA रिकॉर्ड पहले से जारी सर्टिफ़िकेट पर असर डालता है?

नहीं। CA, CAA सिर्फ़ जारी करते समय जाँचती हैं; पहले जारी हुए सर्टिफ़िकेट अपनी मियाद या रद्द होने तक मान्य रहते हैं। CAA ऐसी CA को भी नहीं रोक सकता जो नियम न माने, इसीलिए iodef पता और Certificate Transparency की निगरानी काम आती है।

तकनीकी नोट्स

CAA रिकॉर्ड (RFC 8659) में एक flags बाइट, एक property टैग और एक वैल्यू होती है। issue उस CA का नाम देता है जो नाम और उसके सबडोमेन के लिए सर्टिफ़िकेट जारी कर सकती है, सेमीकोलन के बाद वैकल्पिक पैरामीटर के साथ; issuewild यही wildcard सर्टिफ़िकेट के लिए करता है और मौजूद हो तो उनके लिए issue पर प्राथमिकता रखता है; iodef रिपोर्ट के लिए mailto: या https: पता देता है। अनुमतियाँ रिकॉर्ड के पार जुड़ती हैं, issue में ";" किसी CA का नाम नहीं देता, और ग़लत वैल्यू ख़ाली मानी जाती है।

जारी करने से पहले CA नाम के लिए CAA क्वेरी करती है — उसका रिज़ॉल्वर किसी भी लुकअप की तरह CNAME फ़ॉलो करता है — और जवाब ख़ाली रहे तो बारी-बारी हर पैरेंट डोमेन के लिए; पहला ग़ैर-ख़ाली सेट लागू होता है। जिस सेट में न issue हो न issuewild, वह जारी करने पर रोक नहीं लगाता, और critical फ़्लैग (128) वाली अनजानी प्रॉपर्टी उसे रोक देती है। CA/Browser Forum की Baseline Requirements सितंबर 2017 से हर पब्लिक रूप से trusted CA पर यह जाँच अनिवार्य करती हैं।

चेकर यही चढ़ाई हर नाम के लिए एक पब्लिक DNS क्वेरी से करता है, जो Cloudflare एज पर चल रहे Mutqan सर्वर से जाती है, ज़्यादा से ज़्यादा 20 नामों तक; टॉप-लेवल डोमेन ख़ुद क्वेरी नहीं होता, और जो चढ़ाई रिकॉर्ड मिले बिना 20 नामों पर रुक जाए उसका नतीजा अज्ञात बताया जाता है। जिस CA की आप जाँच करते हैं, उसका मिलान issue और issuewild वैल्यू से आपके ब्राउज़र में होता है।

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

चढ़ाई टॉप-लेवल डोमेन से पहले रुकती है, क्योंकि com जैसे एक लेबल वाले नाम यहाँ क्वेरी नहीं हो सकते। TLD आम तौर पर CAA रिकॉर्ड पब्लिश नहीं करते, पर यह जाँच इसे साबित नहीं करती।

ज़्यादा से ज़्यादा 20 नाम जाँचे जाते हैं — आम नाम इस सीमा से बहुत नीचे रहते हैं। इससे गहरा नाम, जिसके इन 20 नामों में कोई रिकॉर्ड न मिले, अज्ञात बताया जाता है, कभी «कोई भी CA जारी कर सकती है» नहीं।

रिकॉर्ड Cloudflare के पब्लिक रिज़ॉल्वर से पढ़े जाते हैं। CA अपने रिज़ॉल्वर इस्तेमाल करती है, अक्सर DNSSEC validation के साथ, और बदलाव के बाद कुछ समय तक अलग जवाब देख सकती है।

CAA सिर्फ़ जारी करते समय देखा जाता है: चेकर नहीं बता सकता कि मौजूदा सर्टिफ़िकेट किसी अनुमत CA से आए या नहीं। यह Certificate Transparency Lookup दिखाता है।

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

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

संदर्भ