DNS लुकअप टूल
Cloudflare के DNS-over-HTTPS के माध्यम से किसी भी डोमेन के DNS रिकॉर्ड्स को क्वेरी करें।
DNS रिकॉर्ड प्रकार समझाए गए
A · डोमेन को IPv4 पते से जोड़ता है
AAAA · डोमेन को IPv6 पते से जोड़ता है
CNAME · दूसरे डोमेन की ओर इशारा करने वाला उपनाम
MX · मेल सर्वर (प्राथमिकता के साथ)
TXT · मनमाना टेक्स्ट (SPF, DKIM, डोमेन सत्यापन)
NS · डोमेन के लिए अधिकृत नेम सर्वर
SOA · Start of Authority, प्राथमिक नेम सर्वर जानकारी
PTR · रिवर्स DNS, IP को डोमेन से जोड़ता है
यह कैसे काम करता है
- एक डोमेन दर्ज करें: फ़ील्ड में डोमेन नाम (सबडोमेन सहित) दर्ज करें।
- रिकॉर्ड प्रकार चुनें: पूछने के लिए DNS रिकॉर्ड प्रकार चुनें: A, AAAA, MX, CNAME, TXT।
- परिणाम देखें: सार्वजनिक DNS-over-HTTPS प्रदाता से परिणाम प्राप्त होते हैं और मानों के साथ प्रदर्शित होते हैं।
- निदान करें: ग़लत कॉन्फ़िगरेशन या देरी की पहचान के लिए रिकॉर्ड प्रकारों के बीच परिणामों की तुलना करें।
DNS लुकअप क्यों इस्तेमाल करें?
DNS समस्याएँ वेबसाइट डाउनटाइम, ईमेल डिलीवरी विफलता और कॉन्फ़िगरेशन समस्याओं के सबसे सामान्य कारणों में से एक हैं।
DNS रिकॉर्ड प्रकार
- A: डोमेन का IPv4 पता
- AAAA: डोमेन का IPv6 पता
- MX: ईमेल रूटिंग के लिए मेल सर्वर रिकॉर्ड
- CNAME: दूसरे डोमेन की ओर इशारा करने वाला कैनोनिकल नाम उपनाम
- TXT: SPF, DKIM, डोमेन सत्यापन के लिए टेक्स्ट रिकॉर्ड
- NS: डोमेन के लिए अधिकृत नेम सर्वर
DNS के 40 साल: RFC 882 से DNS over QUIC तक
डोमेन नेम सिस्टम को Paul Mockapetris ने USC/ISI में डिज़ाइन किया था और RFC 882 और RFC 883 (नवंबर 1983) में निर्दिष्ट किया गया, जिसने उस फ्लैट HOSTS.TXT फ़ाइल को बदल दिया जिसे ARPANET ने पीछे छोड़ दिया था। सिस्टम को RFC 1034 और RFC 1035 (नवंबर 1987) में सुधार और औपचारिक रूप दिया गया, ये दस्तावेज़ आज भी उद्धृत किए जाते हैं। Jon Postel ने मूल 13 रूट नेमसर्वरों के असाइनमेंट का समन्वय किया, जिन्हें a.root-servers.net से m.root-servers.net तक लेबल किया गया, यह संख्या क्षमता से नहीं बल्कि उस युग की 512-बाइट UDP पैकेट साइज़ सीमा द्वारा तय की गई थी। इस सदी में दो बड़े झटकों ने DNS को नया रूप दिया। जुलाई 2008 में, Dan Kaminsky ने एक कैश-पॉइज़निंग हमले का खुलासा किया जिसने हमलावरों को सेकंडों के भीतर रिज़ॉल्वर में जाली रिकॉर्ड डालने की अनुमति दी। उद्योग ने एक समन्वित पैच (सोर्स-पोर्ट रैंडमाइज़ेशन) और DNSSEC (RFC 4033-4035, मार्च 2005) में नवीनीकृत रुचि के साथ प्रतिक्रिया दी, जो रिकॉर्ड को क्रिप्टोग्राफिक रूप से हस्ताक्षरित करता है। दूसरा झटका गोपनीयता था: 35 साल तक प्रश्न सादे टेक्स्ट में UDP पोर्ट 53 पर यात्रा करते थे। DNS over TLS (DoT, RFC 7858, मई 2016) पोर्ट 853 पर TLS में प्रश्नों को लपेटता है। DNS over HTTPS (DoH, RFC 8484, अक्टूबर 2018) पोर्ट 443 पर HTTPS के माध्यम से प्रश्नों को टनल करता है, यहाँ तक कि इस तथ्य को भी छुपाते हुए कि DNS हो रहा है। DNS over QUIC (RFC 9250, मई 2022) नवीनतम है, उसी ट्रांसपोर्ट का उपयोग करते हुए जो HTTP/3 को संचालित करता है। सार्वजनिक रिज़ॉल्वर 1.1.1.1 (Cloudflare, 1 अप्रैल 2018 को लॉन्च), 8.8.8.8 (Google Public DNS, दिसंबर 2009), और 9.9.9.9 (Quad9, नवंबर 2017) सभी आज DoH और DoT का समर्थन करते हैं।
रिकॉर्ड प्रकारों की गहराई में
- A (RFC 1035). 32-बिट IPv4 पता। एक डोमेन में लोड संतुलन के लिए कई A रिकॉर्ड हो सकते हैं; रिज़ॉल्वर उनके बीच घूमते हैं (राउंड-रॉबिन DNS)।
- AAAA (RFC 3596, 2003). 128-बिट IPv6 पता। उच्चारित «क्वाड-A»। 2024 तक, Google के ट्रैफ़िक का लगभग 45% IPv6 है।
- CNAME (RFC 1035). उपनाम: «इस नाम का अनुसरण करें और इसके बजाय इसके रिकॉर्ड देखें»। एक ही नाम पर किसी अन्य रिकॉर्ड के साथ सह-अस्तित्व नहीं कर सकता। यही कारण है कि
example.comशीर्ष पर CNAME और MX या A दोनों नहीं हो सकते; आधुनिक विकल्प ALIAS या ANAME (विक्रेता-विशिष्ट) या HTTPS रिकॉर्ड (RFC 9460, 2023) का उपयोग करते हैं। - MX (RFC 1035, RFC 7505 «null MX» द्वारा अद्यतन)। प्राथमिकता मान वाला मेल एक्सचेंज सर्वर। कम प्राथमिकता को प्राथमिकता दी जाती है; बंधन यादृच्छिक होते हैं।
0 .(RFC 7505, जून 2015) स्पष्ट रूप से कहता है «यह डोमेन कोई मेल प्राप्त नहीं करता», गैर-मेलबॉक्स डोमेन पर स्पैम को रोकता है। - TXT (RFC 1035). मुक्त-रूप टेक्स्ट स्ट्रिंग। अब महत्वपूर्ण प्रमाणीकरण ले जाता है: SPF (RFC 7208, 2014), DKIM (RFC 6376, 2011), DMARC (RFC 7489, 2015), और Google Search Console, Microsoft 365, ACME (Let's Encrypt) DNS-01 चुनौतियों के लिए स्वामित्व सत्यापन।
- NS (RFC 1035). आधिकारिक नेमसर्वर के नाम। अतिरेक के लिए हमेशा कम से कम दो। मूल क्षेत्र में «ग्लू रिकॉर्ड» IP प्रदान करते हैं ताकि एक पुनरावर्ती रिज़ॉल्वर बिना परिपत्र लुकअप के नेमसर्वर तक पहुँच सके।
- SOA (RFC 1035). Start of Authority। प्रति क्षेत्र एकल रिकॉर्ड जो प्राथमिक नेमसर्वर, व्यवस्थापक ईमेल (पहले
.को@से बदलकर), सीरियल नंबर (परिवर्तनों पर वृद्धि), refresh, retry, expire, और न्यूनतम TTL को सूचीबद्ध करता है। - CAA (RFC 8659, 2019; मूल रूप से RFC 6844, 2013). Certificate Authority Authorisation। सूचीबद्ध करता है कि कौन से CA डोमेन के लिए प्रमाणपत्र जारी करने के लिए अधिकृत हैं। सितंबर 2017 से CA/Browser Forum बेसलाइन आवश्यकताओं द्वारा अनिवार्य जाँच।
- SRV (RFC 2782, 2000). सेवा स्थान: प्रोटोकॉल, प्राथमिकता, वज़न, पोर्ट, लक्ष्य होस्ट। Microsoft Active Directory, XMPP, SIP, Matrix संघ सभी सेवा खोज के लिए SRV रिकॉर्ड का उपयोग करते हैं।
- PTR (RFC 1035). रिवर्स DNS। एक IP को वापस एक डोमेन पर मैप करता है।
in-addr.arpa(IPv4) याip6.arpa(IPv6) क्षेत्रों में रहता है। कई मेल सर्वर ईमेल स्वीकार करने के लिए आवश्यक हैं; गुम PTR एक सामान्य स्पैम संकेत है। - DNSKEY / DS / RRSIG (RFC 4034-4035). DNSSEC पाइप। DNSKEY क्षेत्र की हस्ताक्षर कुंजी प्रकाशित करता है; मूल क्षेत्र में DS क्रिप्टोग्राफ़िक «यहाँ श्रृंखला में अगली कड़ी है» सूचक है; RRSIG प्रत्येक रिकॉर्ड सेट के लिए वास्तविक हस्ताक्षर ले जाता है।
DNS लुकअप वास्तव में कहाँ मदद करता है
- नए डोमेन पर ईमेल सेट करना। सत्यापित करें कि MX रिकॉर्ड सही प्रदाता (Google Workspace
aspmx.l.google.com, Microsoft 365example-com.mail.protection.outlook.com, Fastmail, ProtonMail) की ओर इशारा करते हैं। SPF (v=spf1 include:_spf.google.com ~all), DKIM (selector._domainkey), DMARC (_dmarcTXT) की जाँच करें। - डोमेन माइग्रेशन और प्रसार। रजिस्ट्रार पर नेमसर्वर अपडेट करने के बाद, यह पुष्टि करने के लिए पुराने और नए दोनों आधिकारिक सर्वरों को क्वेरी करें कि परिवर्तन वैश्विक रूप से प्रसारित हो गया है। विभिन्न रिज़ॉल्वर विभिन्न अवधि के लिए कैश करते हैं (TTL संकेत है, अनुबंध नहीं)।
- TLS / SSL प्रमाणपत्र समस्या निवारण। Let's Encrypt और समान द्वारा उपयोग किए जाने वाले ACME DNS-01 चुनौती के लिए
_acme-challenge.example.comपर TXT रिकॉर्ड रखने की आवश्यकता होती है। बर्बाद रेट-लिमिट प्रयासों से बचने के लिए प्रमाणपत्र जारी करने को ट्रिगर करने से पहले मान की जाँच करें। - सबडोमेन टेकओवर जोखिम का पता लगाना। एक अपंजीकृत सेवा (हटाई गई Heroku ऐप, मुक्त S3 बकेट) की ओर इशारा करता CNAME हमलावरों को इसे पंजीकृत करने और आपके सबडोमेन पर सामग्री परोसने की अनुमति देता है। त्वरित CNAME ऑडिट लटकते पॉइंटर्स को पकड़ता है।
- CDN और लोड-बैलेंसर सत्यापन। पुष्टि करें कि एक डोमेन तैनाती के बाद सही Cloudflare, Fastly, Akamai, CloudFront, या Vercel एंडपॉइंट पर CNAME करता है। पता लगाएँ कि स्टेजिंग गलती से उत्पादन की ओर कब इशारा करता है।
- भौगोलिक DNS तुलना। कुछ साइटें क्षेत्र (GeoDNS) के अनुसार विभिन्न A रिकॉर्ड परोसती हैं। विभिन्न DoH एंडपॉइंट (Cloudflare 1.1.1.1 बनाम Google 8.8.8.8) से क्वेरी करने से संकेत मिलता है कि फ्रैंकफर्ट बनाम मुंबई में एक उपयोगकर्ता साइट को कैसे देखता है।
- सुरक्षा और घटना प्रतिक्रिया। अप्रत्याशित NS रिकॉर्ड (रजिस्ट्रार अपहरण), संदिग्ध TXT रिकॉर्ड, या हाल ही में जोड़े गए MX रिकॉर्ड देखें। ट्रैक करने के लिए SOA सीरियल का उपयोग करें कि एक क्षेत्र अंतिम बार कब बदला।
DNS गलतियाँ जो साइट और ईमेल को तोड़ती हैं
- शीर्ष पर CNAME। RFC 1034
example.comपर CNAME डालने पर प्रतिबंध लगाता है (केवलwww.example.comजैसे सबडोमेन पर)। Cloudflare, Route 53, DNSimple CNAME फ़्लैटनिंग या ALIAS रिकॉर्ड के साथ इसके आसपास काम करते हैं; Vercel, Netlify HTTPS सेवा बाइंडिंग रिकॉर्ड (RFC 9460) का उपयोग करते हैं। एक बेसिक रजिस्ट्रार के DNS पैनल पर इसे आज़माना चुपचाप ईमेल को तोड़ देता है। - माइग्रेशन से पहले TTL कम करना भूलना। यदि आपके A रिकॉर्ड का TTL 86400 (24 घंटे) है और आप इसे स्विचओवर की सुबह बदलते हैं, तो दुनिया भर के रिज़ॉल्वर एक दिन तक पुराना IP देना जारी रखेंगे। परिवर्तन से कुछ दिन पहले TTL को 300 सेकंड तक छोड़ें।
- बहुत अधिक DNS लुकअप वाले SPF रिकॉर्ड। RFC 7208 SPF को प्रति मूल्यांकन 10 DNS लुकअप तक सीमित करता है। बहुत अधिक
include:निर्देशों को श्रृंखलाबद्ध करें और आपका SPF रिकॉर्डpermerrorके साथ विफल हो जाता है, जिसे DMARC एक विफलता मानता है। SPF Surveyor जैसे उपकरणों के साथ चपटा या समेकित करें। - सेवा हटाने के बाद लटकता CNAME। Heroku ऐप हटा दिया लेकिन
app.example.comCNAME अभी भीexample.herokuapp.comकी ओर इशारा कर रहा है? कोई भी उस ऐप नाम को पंजीकृत कर सकता है और आपके सबडोमेन पर उनकी सामग्री होस्ट कर सकता है। अनाथ CNAME का ऑडिट करें और हटाएँ। - कोई CAA रिकॉर्ड नहीं। CAA रिकॉर्ड के बिना, WebPKI में कोई भी CA (~50 दुनिया भर में) आपके डोमेन के लिए प्रमाणपत्र जारी कर सकता है। इसे एक या दो विश्वसनीय CA पर लॉक करें:
0 issue "letsencrypt.org"। सितंबर 2017 से अनिवार्य CA जाँच। - गुम प्रविष्टियों को छिपाने वाले वाइल्डकार्ड रिकॉर्ड। एक
*.example.comA रिकॉर्ड हर टाइपो सबडोमेन को हल करता है, वास्तविक कॉन्फ़िगरेशन गलतियों को छुपाता है। टाइपो पतों पर स्पैम से बचने के लिए स्पष्ट MX नियमों के साथ सावधानीपूर्वक संयोजन करें। - कटओवर के दौरान DNSSEC और अहस्ताक्षरित क्षेत्रों को मिलाना। नए नेमसर्वरों के हस्ताक्षरित रिकॉर्ड परोसने से पहले रजिस्ट्रार पर DNSSEC सक्षम करना हर सत्यापन रिज़ॉल्वर (Cloudflare 1.1.1.1, Quad9) के लिए SERVFAIL उत्पन्न करता है। हमेशा पहले हस्ताक्षर करें, फिर DS रिकॉर्ड प्रकाशित करें।
अधिक अक्सर पूछे जाने वाले प्रश्न
यह उपकरण कभी-कभी dig से अलग परिणाम क्यों लौटाता है?
दो मुख्य कारण। पहला, यह उपकरण Cloudflare के 1.1.1.1 रिज़ॉल्वर के माध्यम से DNS over HTTPS द्वारा क्वेरी करता है, जबकि आपके लैपटॉप पर dig कॉन्फ़िगर किए गए किसी भी रिज़ॉल्वर को क्वेरी करता है (अक्सर आपका ISP)। विभिन्न रिज़ॉल्वर विभिन्न अवधि के लिए कैश करते हैं और पुराना डेटा हो सकता है। दूसरा, EDNS Client Subnet (ECS, RFC 7871) आपके नेटवर्क के बारे में आधिकारिक सर्वरों को संकेत भेजता है, जो GeoDNS-अनुकूलित उत्तर लौटा सकते हैं; Cloudflare 1.1.1.1 गोपनीयता के लिए ECS को स्पष्ट रूप से हटाता है, इसलिए जियो-लक्ष्यीकरण आपको आपके वास्तविक स्थान के बजाय «Cloudflare से आ रहा» के रूप में देखता है। आवासीय ISP पर dig +short अक्सर GeoDNS-वैयक्तिकृत परिणाम देखेगा।
आधिकारिक और पुनरावर्ती रिज़ॉल्वर के बीच क्या अंतर है?
आधिकारिक रिज़ॉल्वर एक क्षेत्र की मास्टर कॉपी रखते हैं (Cloudflare DNS, Route 53, DigitalOcean DNS, आदि) और केवल उन डोमेन के लिए जवाब देते हैं जिनके लिए वे कॉन्फ़िगर किए गए हैं। पुनरावर्ती रिज़ॉल्वर (1.1.1.1, 8.8.8.8, आपका ISP) ग्राहकों से क्वेरी लेते हैं और उनकी ओर से DNS पेड़ पर चलते हैं: रूट → TLD → आधिकारिक। वे उत्तर TTL तक कैश करते हैं, जिसके कारण रिकॉर्ड परिवर्तन को «प्रसारित» होने में समय लग सकता है। यह उपकरण एक पुनरावर्ती रिज़ॉल्वर (Cloudflare 1.1.1.1) से बात करता है, इसलिए आप जो उत्तर देखते हैं वह कैश्ड दृश्य है जो उस पुनरावर्ती रिज़ॉल्वर के पास वर्तमान में है।
DNS प्रसार वास्तव में कितना समय लेता है?
«प्रसार» एक भ्रामक नाम है: DNS अद्यतन नहीं भेजता है, दुनिया भर के पुनरावर्ती रिज़ॉल्वर बस उनकी TTL समाप्त होने तक कैश्ड कॉपी रखते हैं। यदि आपके मौजूदा A रिकॉर्ड का TTL 300 सेकंड था, तो हर कैश 5 मिनट के भीतर ताज़ा हो जाएगा। यदि यह 86400 (24 घंटे, एक सामान्य डिफ़ॉल्ट) था, सबसे खराब मामला 24 घंटे है। कुछ खराब व्यवहार वाले रिज़ॉल्वर TTL को अनदेखा करते हैं और लंबे समय तक कैश करते हैं; कुछ अति-उत्साही ब्राउज़र और OS भी स्थानीय रूप से कैश करते हैं (Chrome का आंतरिक DNS कैश 1 मिनट तक चलता है)। नियोजित परिवर्तन से पहले TTL कम करें, फिर बाद में फिर से बढ़ाएँ।
क्या DNS over HTTPS वास्तव में «निजी» है?
यह आपके ISP और Wi-Fi पर पथ-पर्यवेक्षकों से प्रश्न छुपाता है, लेकिन आप जो रिज़ॉल्वर चुनते हैं वह अभी भी हर प्रश्न देख सकता है। विश्वास आपके ISP से उस व्यक्ति को स्थानांतरित होता है जो DoH एंडपॉइंट (Cloudflare, Google, Quad9, NextDNS) चलाता है। कुछ, जैसे Cloudflare 1.1.1.1, अपनी no-logs नीति के स्वतंत्र ऑडिट प्रकाशित करते हैं; अन्य नहीं। DoH भी उस IP पते को नहीं छुपाता जिससे आप अंततः जुड़ते हैं, आपके बाद के TLS हैंडशेक का SNI फ़ील्ड नेटवर्क पर्यवेक्षकों को गंतव्य डोमेन प्रकट करता है, जब तक ECH (Encrypted Client Hello, RFC 9180) सार्वभौमिक रूप से तैनात नहीं हो जाता। 2024 तक, ECH Cloudflare, Firefox, Chrome (फ्लैग के पीछे) द्वारा समर्थित है लेकिन अभी सर्वव्यापी नहीं है।
यदि यह «ब्राउज़र-आधारित» उपकरण है तो मुझे नेटवर्क कनेक्शन की आवश्यकता क्यों है?
UI पूरी तरह से आपके ब्राउज़र में चलता है (हमारे सर्वर पर कोई स्वामित्व कोड नहीं), लेकिन DNS लुकअप स्वयं परिभाषा के अनुसार एक नेटवर्क ऑपरेशन है: यह एक दूरस्थ आधिकारिक या पुनरावर्ती नेमसर्वर को क्वेरी करता है। यह उपकरण प्रति लुकअप एक HTTPS अनुरोध Cloudflare के सार्वजनिक 1.1.1.1 DoH एंडपॉइंट cloudflare-dns.com/dns-query पर भेजता है। आप जो डोमेन क्वेरी करते हैं वह Cloudflare को दिखाई देता है; कुछ और नहीं (कोई IP, कोई फिंगरप्रिंट) नहीं भेजा जाता।