रिवर्स DNS लुकअप

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

किसी पब्लिक IP एड्रेस का PTR रिकॉर्ड in-addr.arpa या ip6.arpa में देखें, फिर लौटे हर नाम को forward (A या AAAA) resolve करके देखें कि वह उसी एड्रेस पर लौटता है या नहीं — यही forward-confirmed reverse DNS है जिसे मेल सर्वर जाँचते हैं। क्वेरी Cloudflare एज पर Mutqan सर्वर से Cloudflare या Google पब्लिक DNS को जाती हैं।

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

Reverse DNS क्या है?

Reverse DNS किसी IP एड्रेस को PTR रिकॉर्ड के ज़रिए वापस होस्ट नाम से जोड़ता है, जो in-addr.arpa (IPv4) या ip6.arpa (IPv6) के नीचे रखा जाता है। यह रिकॉर्ड डोमेन मालिक नहीं, एड्रेस ब्लॉक का धारक पब्लिश करता है, इसलिए उस पर तभी भरोसा किया जा सकता है जब दिया गया नाम forward में भी उसी एड्रेस पर resolve हो (forward-confirmed reverse DNS)।

रिवर्स DNS लुकअप कैसे इस्तेमाल करें

  1. एक पब्लिक IPv4 या IPv6 एड्रेस लिखें (IPv6 के चारों ओर ब्रैकेट हों तो भी चलेगा)।
  2. दोनों की तुलना करनी हो तो रिज़ॉल्वर के रूप में Cloudflare या Google चुनें।
  3. «PTR लुकअप करें» दबाएँ और PTR नाम व उसका TTL पढ़ें।
  4. "IP से मेल" कॉलम देखें: ✓ का मतलब नाम उसी एड्रेस पर लौटता है (forward-confirmed); ✗ का मतलब नहीं लौटता।

रिवर्स DNS लुकअप की खूबियाँ

  • IPv4 (in-addr.arpa) और IPv6 (ip6.arpa) एड्रेस के लिए PTR लुकअप — reverse नाम अपने-आप बनता है
  • Forward पुष्टि: हर PTR नाम resolve (A या AAAA) करके आपके दिए एड्रेस से मिलाया जाता है
  • PTR न हो तो साफ़ नतीजा: NXDOMAIN, खाली जवाब और रिज़ॉल्वर की विफलता अलग-अलग बताए जाते हैं
  • Classless reverse delegation (RFC 2317 के CNAME alias) पहचाना और समझाया जाता है
  • एक एड्रेस पर कई PTR नाम हों, या ISP के ऐसे generic नाम हों जिनमें एड्रेस ही लिखा हो, तो नोट
  • प्राइवेट, reserved और documentation एड्रेस लोकल रूप से समझाए जाते हैं और किसी रिज़ॉल्वर को नहीं भेजे जाते

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

इनपुट

  • IP एड्रेस — एक पब्लिक IPv4 या IPv6 एड्रेस; CIDR रेंज, होस्ट नाम और प्राइवेट एड्रेस स्वीकार नहीं।
  • रिज़ॉल्वर — Cloudflare 1.1.1.1 (डिफ़ॉल्ट) या Google Public DNS, PTR और forward दोनों लुकअप के लिए।

आउटपुट

  • सारांश — जिस reverse नाम पर क्वेरी हुई, रिस्पॉन्स कोड, PTR रिकॉर्ड की संख्या और कितने नाम forward-confirmed हुए।
  • PTR रिकॉर्ड — हर नाम उसके TTL के साथ, वह किन एड्रेस पर resolve होता है और क्या उनमें आपका दिया एड्रेस है।
  • निष्कर्ष — PTR नहीं, NODATA, classless delegation, विफल forward लुकअप, कई PTR और generic pool नाम।

रिवर्स DNS लुकअप का उदाहरण

Google Public DNS का PTR

इनपुट:

8.8.8.8

आउटपुट:

Reverse name: 8.8.8.8.in-addr.arpa · Response code: NOERROR · PTR records: 1 · Forward-confirmed: 1/1
dns.google   TTL 15331   forward A: 8.8.8.8, 8.8.4.4   ✓
Findings: Forward-confirmed: dns.google resolves back to 8.8.8.8 (FCrDNS).

रिवर्स DNS लुकअप के नतीजे कैसे पढ़ें

"IP से मेल" में ✓: PTR नाम वापस उसी एड्रेस पर resolve होता है — forward-confirmed reverse DNS, जिसकी उम्मीद मेल रिसीवर भेजने वाले सर्वर से करते हैं।

✗: नाम मौजूद है पर कहीं और इशारा करता है या उस फ़ैमिली का एड्रेस ही नहीं है। सर्वर बदलने के बाद PTR पुराना रह गया हो सकता है, या नाम का A/AAAA रिकॉर्ड कभी बना ही नहीं।

reverse नाम पर NXDOMAIN: कोई PTR पब्लिश नहीं है। मेल सर्वर हो तो एड्रेस वाले प्रोवाइडर से अपने सर्वर के नाम से मेल खाता PTR सेट करवाएँ।

ऐसा नाम जिसमें एड्रेस ही लिखा हो (जैसे 203-0-113-7.dsl.example.net) घरेलू और डायनेमिक रेंज में आम है; यह एड्रेस के बारे में पक्का कुछ नहीं बताता, पर रिसीवर उसे कम स्कोर दे सकते हैं।

रिवर्स DNS लुकअप कब इस्तेमाल करें

  • मेल सर्वर तैयार करना: पहला मेल भेजने से पहले जाँचना कि भेजने वाले IP का PTR सर्वर के नाम से मेल खाता है।
  • सर्वर लॉग पढ़ना: किसी अनजान क्लाइंट या crawler एड्रेस का नाम जानना और देखना कि वह नाम forward में पुष्ट होता है या नहीं।
  • साइट या VPS नए एड्रेस पर ले जाने के बाद: पक्का करना कि प्रोवाइडर ने reverse रिकॉर्ड अपडेट किया।
  • जाँचना कि सर्च इंजन होने का दावा करने वाला crawler सच में उस इंजन के डोमेन पर और वापस resolve होता है।

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

  • "यह एड्रेस प्राइवेट, reserved या पब्लिक इंटरनेट पर routable नहीं है": 10.x, 192.168.x या 127.0.0.1 जैसे एड्रेस का कोई पब्लिक reverse DNS नहीं होता; उनके लिए अपने नेटवर्क का DNS सर्वर पूछें।
  • प्रोवाइडर पर PTR सही है पर टूल पुराना नाम दिखाता है: रिज़ॉल्वर पिछला जवाब TTL ख़त्म होने तक रख सकता है — दोनों रिज़ॉल्वर मिलाएँ या दिखाए गए TTL तक रुकें।
  • किसी नाम के आगे "कोई A रिकॉर्ड नहीं" (या "कोई AAAA रिकॉर्ड नहीं"): PTR ऐसे होस्ट नाम पर है जिसका DNS में कोई एड्रेस नहीं। A/AAAA रिकॉर्ड बनाएँ या प्रोवाइडर से PTR बदलवाएँ। "लुकअप नहीं हुआ: पब्लिक होस्ट नाम नहीं" का मतलब है कि PTR किसी लोकल या अंदरूनी होस्ट (जैसे localhost) का नाम देता है, जो किसी पब्लिक एड्रेस के लिए कभी ठीक नहीं; "लुकअप विफल" का मतलब है कि रिज़ॉल्वर ने जवाब नहीं दिया, इसलिए फिर कोशिश करें।
  • सिर्फ़ CNAME लौटता है: reverse ज़ोन classless delegation इस्तेमाल करता है, और PTR alias के target पर होना चाहिए; उस target ज़ोन को संभालने वाले प्रोवाइडर को उसे पब्लिश करना होगा।

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

IP एड्रेस का PTR रिकॉर्ड कौन सेट करता है?

जिसके पास एड्रेस ब्लॉक है: आपका होस्टिंग प्रोवाइडर, क्लाउड प्लेटफ़ॉर्म या ISP। reverse ज़ोन एड्रेस के साथ delegate होते हैं, इसलिए आप अपने डोमेन के DNS में PTR नहीं जोड़ सकते; प्रोवाइडर से कहें, या उसके कंट्रोल पैनल में यह विकल्प हो तो वहाँ सेट करें।

Forward-confirmed reverse DNS (FCrDNS) क्या है?

एड्रेस का PTR नाम (IPv4 के लिए A, IPv6 के लिए AAAA) वापस उसी एड्रेस पर resolve हो। कई मेल सर्वर भेजने वालों से यह माँगते हैं, इसीलिए टूल हर मिले नाम का forward लुकअप भी करता है।

मेरे एड्रेस का PTR रिकॉर्ड क्यों नहीं है?

कई प्रोवाइडर तब तक कोई नाम नहीं डालते, या सिर्फ़ generic नाम डालते हैं, जब तक आप न कहें। ऐसे में टूल NXDOMAIN दिखाता है। 192.168.1.10 जैसे प्राइवेट एड्रेस सीधे मना कर दिए जाते हैं: पब्लिक DNS में उनके लिए कुछ नहीं होता।

क्या PTR नाम साबित करता है कि एड्रेस किसका है या कौन इस्तेमाल कर रहा है?

नहीं। reverse ज़ोन का मालिक वहाँ कोई भी नाम लिख सकता है, किसी और का डोमेन भी। सिर्फ़ मेल खाता forward लुकअप दिखाता है कि वह डोमेन भी उसी एड्रेस की ओर इशारा करता है।

तकनीकी नोट्स

IPv4 एड्रेस in-addr.arpa के नीचे ऑक्टेट-दर-ऑक्टेट उलटे लिखे जाते हैं (RFC 1035 §3.5), IPv6 एड्रेस ip6.arpa के नीचे nibble-दर-nibble (RFC 3596 §2.5)। वहाँ का PTR रिकॉर्ड एक होस्ट का नाम बताता है; फिर टूल उस होस्ट के A या AAAA रिकॉर्ड माँगता है — यही PTR/A का मेल है जिसे बनाए रखने को RFC 1912 §2.1 कहता है।

Reverse ज़ोन डोमेन नहीं, एड्रेस आवंटन के हिसाब से चलते हैं: क्षेत्रीय रजिस्ट्री उन्हें ब्लॉक वाले नेटवर्क को delegate करती है, जो आगे delegate कर सकता है — /24 से छोटे ब्लॉक के लिए CNAME रिकॉर्ड से (RFC 2317)। एक रन में ज़्यादा से ज़्यादा चार क्वेरी होती हैं: PTR और तीन तक forward लुकअप।

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

टूल वही बताता है जो पब्लिक रिज़ॉल्वर Cloudflare एज से लौटाता है; सिर्फ़ internal DNS सर्वर पर मौजूद reverse रिकॉर्ड यह नहीं देख सकता।

हर एड्रेस के ज़्यादा से ज़्यादा तीन PTR नाम forward जाँचे जाते हैं, और सिर्फ़ इनपुट वाली फ़ैमिली में (IPv4 के लिए A, IPv6 के लिए AAAA)।

PTR नाम reverse ज़ोन का मालिक लिखता है; यह पहचान या मालिकाना हक़ का सबूत नहीं है।

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

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

संदर्भ

  • RFC 1035: Domain Names - Implementation and SpecificationIETFDNS संदेश का फ़ॉर्मेट, रिकॉर्ड टाइप और रिस्पॉन्स कोड (NOERROR, NXDOMAIN, SERVFAIL, REFUSED) जिन्हें हर रिज़ॉल्वर आज भी इस्तेमाल करता है।
  • RFC 3596: DNS Extensions to Support IP Version 6IETF · 2003IPv6 एड्रेस का AAAA रिकॉर्ड और ip6.arpa ट्री, जिसमें reverse लुकअप के लिए IPv6 एड्रेस nibble-दर-nibble लिखा जाता है।
  • RFC 1912: Common DNS Operational and Configuration ErrorsIETF · 1996ज़ोन की आम ग़लतियाँ और उनसे बचाने वाली परंपराएँ: SOA serial नंबरिंग (YYYYMMDDnn), lame delegation, और ऐसे PTR रिकॉर्ड जो उसी होस्ट के A रिकॉर्ड से मेल खाएँ।