नेटवर्क

DNS चेकर गाइड: रिकॉर्ड, TTL और समस्या समाधान

ToolMellow · 6 अक्टूबर 2026 को अपडेट किया गया

DNS लुकअप में किसी खास नाम के लिए एक खास प्रकार का रिकॉर्ड रिज़ॉल्वर से माँगा जाता है। ToolMellow का DNS चेकर लौटाए गए पते, उपनाम, मेल रूट या टेक्स्ट रिकॉर्ड देखने, चुने गए प्रोवाइडरों के उत्तर की तुलना करने और समय सहित परिणाम सहेजने में मदद करता है। शुरुआत में अपने काम के लिए सही DNS नाम और रिकॉर्ड प्रकार चुनें।

यह टूल उपलब्ध ToolMellow क्वेरी स्थानों से Cloudflare और Google Public DNS को अनुरोध भेजता है। परिणाम उन्हीं अनुरोधों का विवरण देते हैं; उनसे यह साबित नहीं होता कि हर उपयोगकर्ता, डिवाइस या रिज़ॉल्वर को वही उत्तर मिलता है। इस गाइड में नियंत्रणों का उपयोग, परिणाम पढ़ने का तरीका और अपेक्षित मान न मिलने पर जाँच के कदम दिए गए हैं। नीचे के सभी नाम, पते और रिकॉर्ड मान केवल उदाहरण हैं, लाइव माप नहीं।

DNS चेकर

DNS लुकअप कैसे करें

DNS चेकर खोलें और कनेक्शन का कॉन्फ़िगरेशन लोड होने दें। www.example.com जैसा नाम दर्ज करें, रिकॉर्ड प्रकार चुनें, एक या दोनों प्रोवाइडर चुनें और उपलब्ध क्वेरी स्थान चुनें। अनुरोध भेजने के लिए “DNS जाँचें” दबाएँ। पेज खोलने या नाम बदलने से उसके रिकॉर्ड अपने आप नहीं खोजे जाते।

लौटाए गए मान समझने से पहले प्रोवाइडर, स्थान, स्थिति और टाइमस्टैम्प पढ़ें। जरूरी मान पता हो तो वैकल्पिक अपेक्षित-मान फ़ील्ड में उसे दर्ज करें और सटीक या “शामिल है” वाला मिलान चुनें। “DNS रिपोर्ट डाउनलोड करें” वर्तमान परिणाम को dns-results.json में सहेजता है; बदलाव से पहले और बाद की तुलना के लिए यह फ़ाइल रखें।

हर जाँच में एक DNS नाम और एक रिकॉर्ड प्रकार होता है। दोनों पता परिवारों की जाँच के लिए A और AAAA अलग-अलग चलाएँ।
डिफ़ॉल्ट रूप से A, दोनों प्रोवाइडर और मुख्य ToolMellow स्थान चुना होता है। उपलब्ध स्थान सेवा के वर्तमान कॉन्फ़िगरेशन से आते हैं।
नाम, रिकॉर्ड प्रकार, प्रोवाइडर या स्थान बदलने से पिछला परिणाम मिट जाता है। अपेक्षित मान या मिलान का तरीका बदलने से वर्तमान परिणाम की तुलना स्थानीय रूप से फिर होती है।

अपने काम के अनुसार DNS रिकॉर्ड प्रकार चुनें

DNS रिकॉर्ड अलग-अलग सवालों के उत्तर देते हैं। A लुकअप किसी डोमेन के सभी रिकॉर्ड नहीं माँगता, और MX लुकअप परीक्षण ईमेल नहीं भेजता। चयन सूची में नौ प्रकार हैं। अपेक्षित-मान मिलान नीचे दिए गए आठ फ़ॉरवर्ड-क्वेरी प्रकारों के लिए उपलब्ध है; PTR परिणाम देख और डाउनलोड कर सकते हैं, लेकिन उसके अपेक्षित मान की तुलना उपलब्ध नहीं है।

अपने काम के अनुसार DNS रिकॉर्ड प्रकार चुनें
प्रकार	उसमें क्या होता है	व्यावहारिक अर्थ
A	IPv4 पते का डेटा	दिए गए नाम का लौटाया गया IPv4 पता जाँचें; इससे उस पते पर चल रही वेबसाइट की जाँच नहीं होती।
AAAA	IPv6 पते का डेटा	IPv6 को A से अलग जाँचें; IPv4 गंतव्य का काम करना IPv6 के काम करने का प्रमाण नहीं है।
CNAME	उपनाम का लक्ष्य नाम	उपनाम और लौटाए गए टेक्स्ट की लिखावट देखें। DNS उपनाम अपने आप HTTP रीडायरेक्ट नहीं बनाता।
MX	मेल एक्सचेंजर का प्राथमिकता मान और लक्ष्य नाम	प्राथमिकता मान और होस्टनाम दोनों पढ़ें। रिकॉर्ड मौजूद होना सफल मेल डिलीवरी का प्रमाण नहीं है।
TXT	DNS में रखा गया टेक्स्ट	प्रोवाइडर के बताए सटीक रिकॉर्ड नाम पर सत्यापन या ईमेल संबंधी डेटा देखें।
NS	नेमसर्वरों के नाम	लौटाए गए नेमसर्वर नाम देखें; ये लुकअप के लिए चुने गए रिकर्सिव प्रोवाइडर से अलग हैं।
SOA	ज़ोन का प्राधिकृत मेटाडेटा	ज़ोन जानकारी और नकारात्मक उत्तर का संदर्भ देखें; क्वेरी टाइमस्टैम्प रिकॉर्ड बदलने का समय नहीं है।
CAA	प्रमाणपत्र प्राधिकरणों की अनुमति का डेटा	प्रकाशित अनुमति डेटा देखें; यह प्रमाणपत्र या HTTPS की वैधता जाँच नहीं है।
PTR	रिवर्स DNS का नाम पॉइंटर	पूरा रिवर्स-DNS रिकॉर्ड नाम दर्ज करें। यहाँ सीधे IP इनपुट और अपेक्षित-मान मिलान समर्थित नहीं हैं।

RFC 1035: DNS कार्यान्वयन और रिकॉर्ड प्रारूप RFC 3596: IPv6 के लिए DNS विस्तार RFC 8659: प्रमाणपत्र प्राधिकरण अनुमति

TXT नामों और अंतरराष्ट्रीय डोमेन सहित सही DNS नाम दर्ज करें

जिस DNS नाम के तहत रिकॉर्ड है, वही दर्ज करें; URL स्कीम, पथ, ईमेल पता या पोर्ट न जोड़ें। मूल डोमेन और उसका www नाम अलग इनपुट हैं। प्रोवाइडर के सत्यापन निर्देश किसी सबडोमेन या अंडरस्कोर से शुरू होने वाले नाम की माँग कर सकते हैं; मूल डोमेन पर TXT खोजने से अन्य नामों के TXT अपने आप नहीं मिलते।

चेकर शुरुआत और अंत के खाली स्थान हटाता है, समर्थित Unicode डॉट रूपों को पहचानता है, अंतिम रूट डॉट हटाता है, Node के domainToASCII से समर्थित अंतरराष्ट्रीय नामों को ASCII में बदलता है और क्वेरी नाम को लोअरकेस में बदलता है। कम से कम दो लेबल चाहिए। रूपांतरण के बाद हर लेबल में अधिकतम 63 ASCII वर्ण और पूरे नाम में अधिकतम 253 ASCII वर्ण हो सकते हैं। सामान्य लेबल में अक्षर, अंक और बीच में हाइफ़न स्वीकार हैं। समर्थित अंडरस्कोर-प्रारंभिक सेवा लेबल स्वीकार हैं, लेकिन सामान्य लेबल के बीच मनमाने अंडरस्कोर नहीं।

TXT नामों और अंतरराष्ट्रीय डोमेन सहित सही DNS नाम दर्ज करें
उदाहरण इनपुट	उपयोग	इनपुट की जानकारी
`example.com`	मूल डोमेन के रिकॉर्ड	जरूरी प्रकार चुनें; इससे सभी प्रकार या सबडोमेन की सूची नहीं मिलती।
`www.example.com.`	www नाम के रिकॉर्ड	अंतिम रूट डॉट स्वीकार होता है और सामान्यीकृत क्वेरी से हटा दिया जाता है।
`_dmarc.example.com`	DMARC संबंधी TXT परिणाम	TXT चुनें। अकेला यह लुकअप पूरी DMARC नीति खोज या संदेश पहचानकर्ताओं के संरेखण का मूल्यांकन नहीं करता।
`selector._domainkey.example.com`	DKIM संबंधी TXT परिणाम	selector की जगह अपनी मेल सेवा का दिया हुआ सेलेक्टर रखें।
`bücher.example`	अंतरराष्ट्रीय नाम का इनपुट	समर्थित IDN को ASCII-संगत क्वेरी नाम में बदला जाता है; परिणाम में सामान्यीकृत नाम देखें।
`10.113.0.203.in-addr.arpa`	PTR रिकॉर्ड नाम का इनपुट	इस रिवर्स-DNS उदाहरण में IPv4 के चार भाग उल्टे क्रम में हैं; अपेक्षित-मान तुलना उपलब्ध नहीं है।
`https://example.com/path`, `203.0.113.10`, `*.example.com`	अस्वीकार किए जाने वाले इनपुट	इनकी जगह DNS नाम इस्तेमाल करें। सीधे IP पते के लिए अलग IP लुकअप या रिवर्स-DNS टूल चुनें।

RFC 5891: अंतरराष्ट्रीय डोमेन नाम Node.js: URL domainToASCII रूपांतरण RFC 1035: DNS कार्यान्वयन और रिकॉर्ड प्रारूप RFC 6376: DKIM हस्ताक्षर और सेलेक्टर से कुंजी खोज RFC 9989: DMARC नीति खोज और संरेखण

रिकर्सिव प्रोवाइडर और प्राधिकृत नेमसर्वर की भूमिकाएँ अलग हैं

प्राधिकृत नेमसर्वर किसी DNS ज़ोन का डेटा प्रकाशित करता है। रिकर्सिव रिज़ॉल्वर क्लाइंट की ओर से उत्तर प्राप्त करता है और कैश की गई जानकारी दोबारा उपयोग कर सकता है। Google Public DNS या Cloudflare चुनने का अर्थ है कि इस परिणाम के लिए वह रिकर्सिव सेवा इस्तेमाल होगी; इससे यह नहीं माना जा सकता कि वही सेवा आपका ज़ोन होस्ट करती है या आपके डोमेन का प्राधिकृत नेमसर्वर है।

ToolMellow अपने सर्वर या कॉन्फ़िगर किए गए प्रोब से प्रोवाइडर के तय HTTPS एंडपॉइंट को अनुरोध भेजता है और JSON उत्तर पढ़ता है। प्रोवाइडर का यह JSON प्रारूप DNS over HTTPS के लिए मानकीकृत DNS बाइनरी संदेश प्रारूप से अलग है। लुकअप आपके डिवाइस की DNS सेटिंग नहीं बदलता, आपके दर्ज किए किसी मनचाहे नेमसर्वर को सीधे नहीं पूछता और रूट से हर डेलिगेशन को ट्रेस नहीं करता।

RFC 1034: डोमेन नाम, रिज़ॉल्यूशन और कैश RFC 8484: HTTPS पर DNS क्वेरी Google Public DNS: DNS over HTTPS का JSON API Cloudflare 1.1.1.1: JSON DNS over HTTPS अनुरोध

रिकॉर्ड नाम, TTL और क्वेरी विवरण साथ पढ़ें

उत्तर की हर पंक्ति में रिकॉर्ड का नाम, प्रकार, लौटाया गया TTL सेकंड में और टेक्स्ट डेटा होता है। मान के साथ उसका नाम भी पढ़ें: रिकर्सिव उत्तर में उपनामों की श्रृंखला और उपनाम के लक्ष्य का पता शामिल हो सकता है। साथ आया CNAME या अन्य प्रकार, आपके माँगे हुए रिकॉर्ड प्रकार का विकल्प नहीं है। नकारात्मक या रेफ़रल उत्तर का संदर्भ समझने के लिए “प्राधिकरण रिकॉर्ड” खोलें।

हर प्रोवाइडर और स्थान के परिणाम में क्वेरी का टाइमस्टैम्प और बीता समय होता है। टाइमस्टैम्प इस क्वेरी का है, डोमेन व्यवस्थापक ने DNS कब बदला उसका नहीं। अवधि में अनुरोध का मार्ग तथा HTTP और प्रसंस्करण का समय शामिल है; यह आपके अपने कनेक्शन पर केवल DNS की गति का मानक परीक्षण नहीं है। अनुरोध विफल होने से रिकॉर्ड या फ़्लैग न मिलें तो उन्हें अनुपलब्ध मानें, अनुमान से मान न भरें।

RFC 1035: DNS कार्यान्वयन और रिकॉर्ड प्रारूप RFC 2308: DNS क्वेरी की नकारात्मक कैशिंग

DNS में डेटा न मिलने और अनुरोध विफल होने का अंतर समझें

एक वैध नकारात्मक उत्तर और अधूरा रह गया अनुरोध अलग तरह की आगे की जाँच माँगते हैं। ToolMellow में सकारात्मक NOERROR वर्गीकरण का अर्थ है कि माँगे गए प्रकार का उत्तर मौजूद है। अन्य सफल DNS उत्तरों का वर्गीकरण SOA, CNAME या NS संदर्भ से होता है। नीचे की तालिका दिखने वाली स्थिति समझाती है, ताकि हर खाली उत्तर को अनुपस्थित डोमेन न मानें।

कटा हुआ उत्तर अधूरा है, भले उसके किसी हिस्से में अपेक्षित टेक्स्ट मिले। कटे हुए उत्तर और परिचालन विफलता पर टूल अपेक्षित-मान तुलना को अनिर्णायक बताता है। एक प्रोवाइडर सफल और दूसरा विफल हो सकता है; दोनों परिणाम रखें, विफलता को रिकॉर्ड न होने का प्रमाण न मानें।

DNS में डेटा न मिलने और अनुरोध विफल होने का अंतर समझें
स्थिति या परिस्थिति	इस चेकर में अर्थ	आगे की उपयोगी जाँच
NOERROR	सफल उत्तर में माँगे गए प्रकार का रिकॉर्ड मौजूद है	संबंधित मान, उसका नाम और TTL देखें; DNS सफलता गंतव्य सेवा की जाँच नहीं करती।
NXDOMAIN	रिज़ॉल्वर बताता है कि क्वेरी किया गया DNS नाम मौजूद नहीं है	वर्तनी और इच्छित रिकॉर्ड नाम जाँचें। यह डोमेन पंजीकरण उपलब्धता की जाँच नहीं है।
NODATA	माँगे गए प्रकार का उत्तर नहीं है; सफल उत्तर के Authority भाग में SOA है	देखें कि उस नाम पर यह प्रकार होना चाहिए या नहीं। AAAA न होना पूरे डोमेन के न होने के समान नहीं है।
ALIAS_ONLY	SOA जाँच के बाद CNAME मिलता है, लेकिन माँगे गए प्रकार का उत्तर नहीं	उपनाम और उसका लक्ष्य जाँचें; केवल CNAME वाला A उत्तर अपेक्षित A मान नहीं देता।
REFERRAL	पहले के वर्गीकरण कदमों के बाद माँगा गया उत्तर नहीं, लेकिन Authority में NS मिलता है	प्राधिकरण रिकॉर्ड देखें; यह माँगे गए रिकॉर्ड का पूरा उत्तर नहीं है।
EMPTY_ANSWER	माँगा गया उत्तर नहीं और SOA, CNAME या NS संदर्भ भी पहचाना नहीं गया	उत्तर का विवरण रखें; इसे अपनी ओर से NXDOMAIN न कहें।
SERVFAIL या REFUSED	DNS सर्वर विफलता या इनकार बताता है	प्रोवाइडर और डोमेन कॉन्फ़िगरेशन जाँचें; अकेली स्थिति किसी एक खास कारण की पहचान नहीं करती।
HTTP त्रुटि, टाइमआउट, गलत प्रारूप या प्रोब विफलता	क्वेरी विश्वसनीय रूप से पूरी नहीं हो सकी	कनेक्शन की जानकारी देखें और उचित समय पर जानबूझकर दोबारा कोशिश करें; रिकॉर्ड की अनुपस्थिति अभी साबित नहीं है।
कटा हुआ / TC	प्रोवाइडर अधूरा उत्तर बताता है	तुलना को अनिर्णायक मानें और अधूरे उत्तर का फ़्लैग रखें।

RFC 2308: DNS क्वेरी की नकारात्मक कैशिंग Google Public DNS: DNS over HTTPS का JSON API Cloudflare 1.1.1.1: JSON DNS over HTTPS अनुरोध

रिकॉर्ड बदलने के बाद DNS TTL का अर्थ

TTL कैश की अवधि सेकंड में बताता है। रिकर्सिव रिज़ॉल्वर कैश की गई जानकारी की बाकी अवधि लौटा सकता है, इसलिए बाकी डेटा समान होने पर भी दो उत्तरों में TTL अलग हो सकता है। लौटाया गया अंक इस बात की उलटी गिनती नहीं है कि दुनिया के हर रिज़ॉल्वर पर आपका नया मान कब दिखेगा।

सकारात्मक उत्तर, नकारात्मक उत्तर और डेलिगेशन जानकारी का कैश इतिहास अलग हो सकता है। अब TTL कम करने से पहले से कैश की गई कॉपी की तय अवधि पीछे से कम नहीं होती। कुछ रिज़ॉल्वर तय लचीलापन नीतियों के तहत पुराने, अवधि पार कर चुके डेटा का भी उपयोग कर सकते हैं। इसलिए नया लुकअप एक और परिणाम देता है, हर कैश के नया होने का प्रमाण नहीं।

नियोजित बदलाव के लिए DNS होस्टिंग सेवा से सही रिकॉर्ड नाम और मान की पुष्टि करें, पुराने और नए परिणाम रखें और उपयोगी अंतराल पर संबंधित जाँच दोहराएँ। सत्यापन की योजना में होस्टिंग सेवा के बदलाव निर्देश और पहले के कैश का संदर्भ शामिल करें। हर DNS बदलाव को एक समान 24 या 48 घंटे की अवधि से नहीं समझाया जा सकता।

RFC 2181, खंड 8: टाइम टू लिव RFC 2308: DNS क्वेरी की नकारात्मक कैशिंग RFC 8767: पुराने DNS डेटा से उत्तर देना

दो प्रोवाइडरों की सहमति वैश्विक DNS प्रसार क्यों नहीं साबित करती

Google और Cloudflare अलग कैश परिणाम या अलग रिज़ॉल्यूशन व्यवहार के कारण अलग उत्तर दे सकते हैं। स्थान के अनुसार बदलने वाले प्राधिकृत उत्तर भी असर डाल सकते हैं। पहले दर्ज समय पर समान सामान्यीकृत नाम और प्रकार की तुलना करें, फिर स्थिति, रिकॉर्ड नाम, मान और TTL देखें। असहमति अपने आप यह नहीं बताती कि सही उत्तर कौन सा है।

हर जाँच में अधिकतम चार कॉन्फ़िगर किए गए क्वेरी स्थान चुन सकते हैं, लेकिन केवल इंटरफ़ेस में दिख रहे स्थान उपलब्ध हैं। एक स्थान दिखे तो दोनों प्रोवाइडरों की क्वेरी उसी स्थान से जाती है। क्षेत्र-सत्यापन फ़्लैग false हो तो घोषित क्षेत्र को स्वतंत्र रूप से पुष्ट भौगोलिक स्थान नहीं मान सकते। प्रोवाइडरों की संख्या या चयन सीमा से विश्वव्यापी प्रोब नेटवर्क का अनुमान न लगाएँ।

सहमति केवल इन परिणामों के बीच की सहमति बताती है। आपके डिवाइस, किसी दूसरे नेटवर्क या निजी कॉर्पोरेट रिज़ॉल्वर पर अलग उत्तर हो सकता है, खासकर स्थानीय कैश या अलग नेटवर्कों को अलग DNS दृश्य देने वाले split-horizon DNS में। उन अतिरिक्त दृष्टिकोणों की जरूरत हो तो उपयुक्त दायरे की बहु-स्थान सेवा या अपने नेटवर्क के निदान इस्तेमाल करें।

RFC 1034: डोमेन नाम, रिज़ॉल्यूशन और कैश RFC 8767: पुराने DNS डेटा से उत्तर देना

अपेक्षित मान का सटीक या “शामिल है” वाला शाब्दिक मिलान करें

अपेक्षित-मान तुलना Answer भाग में माँगे गए और तुलना के लिए समर्थित प्रकार के मान देखती है। सटीक मिलान में पूरा लौटा टेक्स्ट अपेक्षित टेक्स्ट के समान होना चाहिए; “शामिल है” मिलान में अपेक्षित उप-पाठ लौटे टेक्स्ट के भीतर होना चाहिए। दोनों बड़े और छोटे अक्षरों में फर्क करते हैं। एक मान मिल जाए तो उस प्रोवाइडर और स्थान का परिणाम मेल दिखाता है, भले दूसरे मान अलग हों। इससे पूरी रिकॉर्ड सूची इच्छित कॉन्फ़िगरेशन के समान साबित नहीं होती।

तुलना खाली स्थान नहीं हटाती, उद्धरण या अंतिम डॉट नहीं हटाती, IPv6 की लिखावट एक जैसी नहीं करती और DNS नीति का व्याकरण नहीं समझती। रेगुलर एक्सप्रेशन समर्थित नहीं हैं। प्रोटोकॉल स्तर पर DNS होस्टनाम तुलना बड़े-छोटे अक्षरों को समान मान सकती है, लेकिन यह स्ट्रिंग तुलना उनमें फर्क करती है। अक्षरशः बराबरी चाहिए तो लौटे मान की वास्तविक लिखावट इस्तेमाल करें, और छोटे उप-पाठ को प्रमाण मानने से पहले पूरा डेटा देखें।

माँगा गया मान न होने पर NXDOMAIN और NODATA उत्तर सामान्यतः अलग दिखाते हैं; ये वैध नकारात्मक परिणाम हैं, अनुरोध विफलता नहीं।
विफल या कटे हुए परिणाम अनिर्णायक हैं। खाली अपेक्षित टेक्स्ट, 4,096 JavaScript स्ट्रिंग इकाइयों से लंबा टेक्स्ट और PTR तुलना भी उपलब्ध नहीं हैं।
अपेक्षित टेक्स्ट इस टैब और डाउनलोड की गई रिपोर्ट में रहता है। इसे DNS क्वेरी के साथ नहीं भेजा जाता। अकेला टेक्स्ट मिलान DNSSEC सत्यापन या डोमेन स्वामित्व साबित नहीं करता।

अपेक्षित मान का सटीक या “शामिल है” वाला शाब्दिक मिलान करें
लौटे डेटा का उदाहरण	अपेक्षित टेक्स्ट	तुलना से सीख
A: `203.0.113.10`	`203.0.113.10`	सटीक मिलान इस मान से मेल खाता है; अन्य A उत्तरों में दूसरे पते हो सकते हैं।
CNAME: `target.example.com.`	`target.example.com`	अंतिम डॉट के कारण सटीक मिलान अलग है; “शामिल है” मिलान उप-पाठ खोज लेता है।
MX: `10 mail.example.com.`	`mail.example.com`	प्राथमिकता मान और अंतिम डॉट के कारण सटीक मिलान अलग है; “शामिल है” केवल एक अंश जाँचता है।
TXT: `"verification=sample-token"`	`verification=sample-token`	लौटे टेक्स्ट में उद्धरण शामिल होने पर सटीक मिलान अलग है; “शामिल है” अंश खोज सकता है।
CNAME: `Target.example.com.`	`target.example.com.`	अपरकेस और लोअरकेस का अंतर शाब्दिक सटीक मिलान को अलग बनाता है, भले DNS नाम समानता के अलग नियम हों।
TXT: `"part-one" "part-two"`	`part-onepart-two`	यह सहायक उद्धरण वाले हिस्सों को जोड़ता नहीं और पूरी नीति का अर्थ नहीं निकालता।

RFC 4343: DNS में बड़े-छोटे अक्षरों की समानता

DNSSEC प्रमाणित-डेटा फ़्लैग को उसके स्रोत के साथ पढ़ें

“प्रमाणित” संकेत चुने गए रिकर्सिव रिज़ॉल्वर के AD फ़्लैग से आता है। वह रिज़ॉल्वर डेटा के प्रमाणित होने का दावा करता है; ToolMellow स्वतंत्र रूप से DNSSEC हस्ताक्षर या ट्रस्ट चेन की पुष्टि नहीं करता। इस दावे पर भरोसा करने के लिए रिज़ॉल्वर और उत्तर लाने वाले संचार चैनल पर भरोसा भी जरूरी है।

“अप्रमाणित” का अर्थ है कि प्रोवाइडर ने AD दावा नहीं किया। बिना हस्ताक्षर का डेटा भी ऐसा परिणाम दे सकता है, इसलिए अकेला फ़्लैग डोमेन को खराब या दुर्भावनापूर्ण साबित नहीं करता। SERVFAIL पर भी जाँच जरूरी है; उसे अपने आप DNSSEC समस्या न मानें। यह चेकर प्रोवाइडर पर जाँच सक्षम रखकर DNSSEC संबंधी उत्तर डेटा माँगता है, लेकिन पूरी DNSSEC ऑडिट या ब्राउज़र DNS-लीक जाँच नहीं करता।

RFC 4035: DNSSEC और प्रमाणित-डेटा दावा Google Public DNS: DNS over HTTPS का JSON API Cloudflare 1.1.1.1: JSON DNS over HTTPS अनुरोध

होस्टिंग और HTTPS की जाँच से पहले वेबसाइट DNS देखें

साइट पुराने गंतव्य पर जा रही हो तो वही सटीक होस्टनाम जाँचें जिसे आगंतुक इस्तेमाल करते हैं। A और AAAA अलग-अलग मिलाएँ, और www जैसे उपनाम के लिए CNAME देखें। मूल डोमेन और www का कॉन्फ़िगरेशन एक जैसा न मानें। परिणाम को होस्टिंग सेवा के बताए अपेक्षित रिकॉर्ड से मिलाएँ, जिसमें जरूरी उपनाम लक्ष्य भी शामिल हो।

सही दिखने वाला DNS मान वेबसाइट की समस्या जाँच का एक हिस्सा है। HTTP रीडायरेक्ट, वर्चुअल-होस्ट रूटिंग, प्रमाणपत्र की वैधता और अनुप्रयोग के उत्तर की अलग जाँच चाहिए। CNAME DNS का उपनाम है, जबकि आगंतुक को दूसरे URL पर भेजना HTTP व्यवहार है। CAA डेटा प्रमाणपत्र प्राधिकरण की अनुमति से जुड़ा है; उसका मौजूद होना साबित नहीं करता कि वर्तमान साइट वैध प्रमाणपत्र देती है।

RFC 1035: DNS कार्यान्वयन और रिकॉर्ड प्रारूप RFC 8659: प्रमाणपत्र प्राधिकरण अनुमति

सही नाम पर TXT सत्यापन, SPF, DKIM और DMARC खोजें

डोमेन सत्यापन के लिए सेवा के निर्देश से रिकॉर्ड नाम कॉपी करें और TXT चुनें। प्रदर्शित उद्धरण और टेक्स्ट के हिस्सों को ध्यान में रखकर पूरा लौटा रिकॉर्ड आवश्यक टोकन से मिलाएँ। उत्तर में टोकन मिलना उपयोगी प्रमाण है, लेकिन सत्यापन माँगने वाली सेवा अपनी स्वामित्व-जाँच प्रक्रिया लागू करती है।

SPF नीति संबंधित मेल डोमेन पर TXT इस्तेमाल करती है। DKIM कुंजी लुकअप सेलेक्टर वाले नाम पर होता है, जैसे selector._domainkey.example.com; सेलेक्टर अनुमान से न चुनें, मेल सेवा से लें। DMARC संबंधी जाँच अक्सर _dmarc.example.com के TXT से शुरू होती है। आधुनिक DMARC नीति खोज और पहचानकर्ताओं के संरेखण में अन्य नियम भी हैं, जिन्हें अकेला TXT परिणाम नहीं जाँचता।

MX रिकॉर्ड मेल रूटिंग बताते हैं, जबकि इन TXT आधारित प्रणालियों की भूमिकाएँ अलग हैं। यह चेकर सभी SPF include नहीं खोजता, हस्ताक्षर वाले संदेश की पुष्टि नहीं करता, पूरी DMARC नीति खोज नहीं जाँचता, DMARC रिपोर्ट का विश्लेषण नहीं करता और डिलीवरी का परीक्षण नहीं करता। रिकॉर्ड मौजूद होना या उप-पाठ मिलना इन जाँचों का विकल्प नहीं है।

RFC 7208, खंड 3.1: TXT रिकॉर्ड में SPF नीति RFC 6376: DKIM हस्ताक्षर और सेलेक्टर से कुंजी खोज RFC 9989: DMARC नीति खोज और संरेखण

क्वेरी की गोपनीयता समझें और उपयोगी DNS रिपोर्ट साझा करें

आपका क्वेरी नाम और प्रकार ToolMellow के ब्रोकर या चुने गए प्रोब से चुने गए सार्वजनिक रिज़ॉल्वर को जाता है। रिज़ॉल्वर को प्रोब का नेटवर्क पता दिखता है; ToolMellow आगंतुक के क्लाइंट-IP हेडर उसे आगे नहीं भेजता। होस्टिंग को सामान्य अनुरोध मेटाडेटा फिर भी मिलता है। HTTPS पूरे काम को अनाम नहीं बनाता और शून्य-लॉग नीति साबित नहीं करता; नाम स्वयं भी संवेदनशील हो सकता है।

अपेक्षित टेक्स्ट की तुलना स्थानीय रूप से होती है और वह dns-results.json में expectedComparison के रूप में शामिल हो सकता है। रिपोर्ट साझा करने से पहले क्वेरी नाम, लौटा डेटा और अपेक्षित टेक्स्ट, खासकर सत्यापन टोकन जाँचें। संबंधित परिणाम जरूरी प्राप्तकर्ता को भेजें; हर निर्यातित मान को सार्वजनिक पोस्ट के लिए उपयुक्त न मानें।

सहायता माँगते समय सटीक नाम और प्रकार, इच्छित कॉन्फ़िगरेशन, प्रोवाइडर और स्थान, क्वेरी का समय, स्थिति, संबंधित Answer और Authority डेटा तथा किसी परिणाम के कटे या विफल होने की जानकारी दें। डाउनलोड रिपोर्ट एक समय का स्नैपशॉट है; टूल सर्वर पर पिछले DNS रिकॉर्डों का इतिहास नहीं रखता और पूरा DNS ज़ोन निर्यात नहीं करता।

गायब या अनपेक्षित DNS उत्तर की चरणबद्ध जाँच करें

पहले सामान्यीकृत रिकॉर्ड नाम और चुने गए प्रकार को DNS होस्ट के निर्देशों से मिलाएँ। फिर नकारात्मक DNS उत्तर और विफल अनुरोध का अंतर देखें, उपनाम तथा Authority विवरण पढ़ें और दोनों प्रोवाइडरों के परिणाम मिलाएँ। अपेक्षित मान दिया हो तो कॉन्फ़िगरेशन में अंतर का निष्कर्ष निकालने से पहले पूरा लौटा टेक्स्ट और तुलना का तरीका जाँचें।

बदलाव के बाद रिपोर्ट सहेजें और सोच-समझकर आगे की जाँच करें। टूल लुकअप अपने आप दोहराता नहीं, और बार-बार अनुरोध सभी कैश खाली नहीं करते। कॉन्फ़िगरेशन समस्या पर विकल्प मिले तो “कनेक्शन फिर आज़माएँ” इस्तेमाल करें, दर सीमा के संकेत मानें और उचित समय पर नई DNS जाँच भेजें। “रद्द करें” लंबित क्लाइंट कार्य रोकता है और ऊपर की सेवाओं तक रद्द करने का संकेत भेजता है, लेकिन पहले से भेजी क्वेरी वापस नहीं ले सकता।

पते से शुरू कर रहे हों तो अलग IP लुकअप या रिवर्स-DNS टूल इस्तेमाल करें। किसी डिवाइस के इस्तेमाल किए रिज़ॉल्वर मार्ग की जाँच के लिए स्थानीय ऑपरेटिंग सिस्टम के DNS निदान उपयोग करें। यह चेकर हर सबडोमेन की सूची नहीं बनाता, SRV, DS, DNSKEY या ANY नहीं चुनता, ज़ोन ट्रांसफ़र नहीं करता और पंजीकरण उपलब्धता नहीं जाँचता। सफल उत्तर का व्यापक अर्थ निकालने से पहले निदान को अपने सवाल के अनुसार चुनें।

अक्सर पूछे जाने वाले प्रश्न

किसी डोमेन के सभी DNS रिकॉर्ड कैसे जाँचें?

अपने काम के लिए जरूरी रिकॉर्ड नाम और समर्थित प्रकार अलग-अलग जाँचें। ToolMellow हर अनुरोध में एक नाम और एक प्रकार लेता है; यह सभी सबडोमेन की सूची, ज़ोन ट्रांसफ़र या हर रिकॉर्ड की पूरी सूची नहीं देता।

Google और Cloudflare अलग DNS परिणाम क्यों दिखाते हैं?

उनका कैश इतिहास और रिज़ॉल्यूशन व्यवहार अलग हो सकता है, और प्राधिकृत उत्तर स्थान पर निर्भर हो सकते हैं। समान सामान्यीकृत नाम और प्रकार, समय, स्थिति, रिकॉर्ड नाम, मान और TTL मिलाएँ। अकेली असहमति सही उत्तर नहीं पहचानती।

क्या TTL से DNS प्रसार पूरा होने का समय पता चलता है?

नहीं। लौटा TTL देखे गए डेटा की कैश अवधि बताता है। सकारात्मक और नकारात्मक कैश, डेलिगेशन और पुराने उत्तर देने की नीतियाँ अन्य परिणामों पर असर डाल सकती हैं। यह वैश्विक पूर्णता का समय नहीं बताता।

NXDOMAIN और NODATA में क्या अंतर है?

NXDOMAIN बताता है कि क्वेरी किया नाम मौजूद नहीं है। NODATA में माँगे गए प्रकार का उत्तर नहीं होता; चेकर सफल उत्तर में SOA Authority देखकर इसे पहचानता है। किसी नाम पर A रिकॉर्ड हो सकते हैं, जबकि AAAA डेटा न मिले।

TXT या CNAME रिकॉर्ड का सटीक मिलान क्यों विफल होता है?

यह सहायक पूरे लौटे टेक्स्ट की तुलना बड़े और छोटे अक्षरों का फर्क रखकर करता है। उद्धरण, खाली स्थान, अंतिम डॉट, MX प्राथमिकता टेक्स्ट और अलग लिखावट असर डाल सकते हैं। पूरा मान देखें; “शामिल है” केवल उप-पाठ जाँचता है, पूरे रिकॉर्ड या नीति की पुष्टि नहीं।

क्या मिलान से हर DNS रिकॉर्ड सही साबित होता है?

नहीं। माँगे गए समर्थित प्रकार का एक Answer मान मिल जाए तो उस प्रोवाइडर और स्थान का परिणाम मेल दिखाता है। अन्य मान अलग हो सकते हैं। शाब्दिक मिलान स्वामित्व, DNSSEC सत्यापन, मेल डिलीवरी या विश्वव्यापी सहमति साबित नहीं करता।

क्या PTR खोजने के लिए सीधे IP पता डाल सकता हूँ?

सीधे पते के लिए अलग IP लुकअप या रिवर्स-DNS टूल इस्तेमाल करें। इस DNS चेकर में पूरा रिवर्स-DNS रिकॉर्ड नाम चाहिए, जैसे उदाहरण 10.113.0.203.in-addr.arpa। PTR की अपेक्षित-मान तुलना उपलब्ध नहीं है।

SPF, DKIM और DMARC रिकॉर्ड कैसे जाँचें?

संबंधित SPF डोमेन, _domainkey के तहत प्रोवाइडर के दिए DKIM सेलेक्टर नाम या उचित _dmarc नाम पर TXT चुनें। ये लुकअप प्रकाशित टेक्स्ट देखते हैं; वे सभी SPF निर्भरताएँ, संदेश का DKIM हस्ताक्षर या पूरी DMARC नीति की खोज और संरेखण नहीं जाँचते।

क्या “अप्रमाणित” से मेरा डोमेन असुरक्षित साबित होता है?

“अप्रमाणित” का मतलब चुने गए प्रोवाइडर ने AD फ़्लैग का दावा नहीं किया। बिना हस्ताक्षर के डेटा पर भी ऐसा हो सकता है। ToolMellow DNSSEC को स्वतंत्र रूप से सत्यापित नहीं करता, और अकेला संकेत असुरक्षित डोमेन का प्रमाण नहीं है।

क्या यह चेकर मेरे डिवाइस के DNS सर्वर का परीक्षण करता है?

यह ToolMellow के उपलब्ध स्थानों से चुने गए सार्वजनिक प्रोवाइडरों को पूछता है। वह मार्ग आपके डिवाइस, ब्राउज़र या निजी नेटवर्क के रिज़ॉल्वर और कैश से अलग हो सकता है। इस प्रश्न के लिए स्थानीय निदान इस्तेमाल करें।

क्या दो प्रोवाइडरों की सहमति वैश्विक प्रसार साबित करती है?

यह केवल पूरी हुई इन क्वेरी के परिणामों की सहमति साबित करती है। एक दिख रहे स्थान से दो प्रोवाइडरों को पूछना विश्वव्यापी प्रोब नेटवर्क नहीं है। उपलब्ध स्थान और क्षेत्र की पुष्टि संबंधी जानकारी रिपोर्ट का दायरा तय करती है।

क्या मेरा अपेक्षित मान DNS प्रोवाइडरों को भेजा जाता है?

नहीं। अपेक्षित टेक्स्ट ब्राउज़र टैब में रहता है और डाउनलोड रिपोर्ट में आ सकता है। वास्तविक DNS नाम और प्रकार सेवा के जरिए चुने गए रिज़ॉल्वर तक जाते हैं। साझा करने से पहले सत्यापन टोकन और अन्य रिपोर्ट डेटा जाँचें।