होम › गाइड

DNSBL (RBL) क्या है? DNS blacklist कैसे काम करती है

प्रकाशित 2026-11-03 ／ अपडेट 2026-11-03 ／ लेखक Yuki Nakazawa

DNSBL (DNS-based blacklist, जिसे DNS blocklist या RBL भी कहते हैं) IP पतों या domain names की एक सूची है जिन्हें सूची का operator spam या abuse का स्रोत मानता है, और जिसे इस तरह प्रकाशित किया जाता है कि कोई भी साधारण DNS lookup से उसे जाँच सके। मेल servers जुड़ने वाले हर sender को एक या अधिक DNSBLs में देखते हैं और फिर संदेश reject करते हैं, स्वीकार करते हैं, या परिणाम को spam score में जोड़ते हैं।

यह गाइड बताती है कि DNSBL lookup कैसे काम करता है (उल्टे IP पते, A और TXT records, IPv6 nibble format), IP-आधारित और domain-आधारित सूचियों में क्या अंतर है, receivers जवाबों का वास्तव में कैसे उपयोग करते हैं, blacklists और whitelists में क्या फ़र्क है, पते सूचीबद्ध क्यों होते हैं, और ईमेल deliver न होने पर listing की भूमिका कहाँ आती है। यह नवंबर 2026 तक के RFC 5782 और प्रमुख सूची operators के आधिकारिक documentation पर आधारित है।

DNSBL और RBL का अर्थ

RFC 5782, "DNS Blacklists and Whitelists," ऐसे DNS zone के लिए व्यापक शब्द DNSxL का उपयोग करता है जिसके records किसी सूची के hosts की पहचान करते हैं। blacklist एक DNSBL है; whitelist एक DNSWL है। दोनों एक ही तरह बनती हैं। फ़र्क केवल उस अर्थ में है जो receiver किसी match को देता है।

RBL का पूरा नाम Real-time Blackhole List है। RFC के अनुसार, इस तरह की पहली सूची 1997 में शुरू हुई और इसी नाम से जानी गई। सख़्ती से कहें तो RBL उस मूल सूची और उसकी उत्तराधिकारी सूची को कहते हैं, और RFC बताता है कि यह शब्द संयुक्त राज्य अमेरिका में एक registered service mark है। लेकिन रोज़मर्रा के उपयोग में "RBL" और "DNSBL" लगभग एक-दूसरे की जगह इस्तेमाल होते हैं, इसलिए "RBL क्या है" और "DNSBL क्या है" असल में एक ही सवाल है।

RFC 5782 एक Informational document है, Internet standard नहीं। इसे IRTF Anti-Spam Research Group ने तैयार किया है और यह DNS blacklists और whitelists के बीच interoperability बेहतर करने वाली प्रथाओं पर उस समूह की सहमति को दर्शाता है। यह पते जोड़ने या हटाने की policies का वर्णन या सिफ़ारिश नहीं करता; RFC की अपेक्षा है कि यह विषय एक अलग document में आए। व्यवहार में हर operator अपनी listing और delisting policy खुद तय करता है।

DNSBL lookup कैसे काम करता है

DNSBL lookup एक सामान्य DNS query है, इसलिए manual जाँच के लिए किसी खास software की ज़रूरत नहीं: जो भी चीज़ किसी नाम को resolve कर सकती है, वह सूची से query कर सकती है। फिर भी सूची के operators usage शर्तें तय कर सकते हैं। उदाहरण के लिए, Spamhaus के public servers केवल कम मात्रा वाले non-commercial उपयोग के लिए मुफ़्त हैं, और public resolvers के ज़रिए की गई queries का भरोसेमंद जवाब नहीं मिलता (नीचे देखें)।

IPv4: पते को उल्टा करें और zone जोड़ें

IPv4 पते के लिए चारों octets को उल्टे क्रम में लिखें और सूची का zone name जोड़ दें। यह संरचना reverse DNS से ली गई है। RFC 5782 का उदाहरण 192.0.2.99 को bad.example.com पर मौजूद सूची से इस lookup के ज़रिए जाँचता है:

99.2.0.192.bad.example.com

A record बताता है "सूचीबद्ध है," TXT record बताता है क्यों

• A record. हर सूचीबद्ध entry का A record होना ज़रूरी है। परंपरा के अनुसार इसका मान 127.0.0.2 होता है। यह मान एक संकेत है, पता नहीं, और इसे पते के रूप में इस्तेमाल नहीं किया जाना चाहिए; सूचियाँ 127.0.0.0/8 range का उपयोग करती हैं ताकि गलती से इस्तेमाल हुआ मान अनचाहा network ट्रैफ़िक पैदा न करे।
• सूचीबद्ध नहीं. अगर पता सूची में नहीं है, तो उसके लिए कोई record नहीं होता, इसलिए query सामान्यतः NXDOMAIN लौटाती है।
• TXT record. DNSBL को listing का कारण बताने वाला TXT record प्रकाशित करना चाहिए। Clients को A record जाँचना ज़रूरी है और वे TXT record भी जाँच सकते हैं।
• अलग sublists के लिए अलग मान. संयुक्त सूची यह दिखाने के लिए कि कौन-सी sublist match हुई, अलग-अलग 127.0.0.x मान लौटा सकती है, या एक साथ कई A records। अर्थ हर सूची के लिए अलग होता है, इसलिए हमेशा operator का documentation पढ़ें। आम codes के लिए हमारी DNSBL response codes गाइड देखें।

terminal से (यहाँ zone एक placeholder है):

dig +short 99.2.0.192.bad.example.com A
dig +short 99.2.0.192.bad.example.com TXT

Test entries

RFC 5782 माँगता है कि IPv4 सूचियों में 127.0.0.2 की entry हो और 127.0.0.1 की entry न हो। Clients से अपेक्षा है कि किसी zone पर भरोसा करने से पहले वे इन test entries को जाँचें, और जो zone इनका गलत जवाब देता है उसका उपयोग न करें।

IPv6: nibble format

IPv6 पते को पूरा 32 hexadecimal अंकों में लिखा जाता है, फिर एक-एक अंक (एक nibble) करके उल्टा किया जाता है, हर अंक के बीच एक बिंदु के साथ, और उसके बाद सूची का zone आता है। ugly.example.com पर 2001:db8:1:2:3:4:567:89ab के लिए RFC का उदाहरण:

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ugly.example.com

IPv6 सूचियों में test entry ::FFFF:7F00:2 (IPv4-mapped पते के रूप में 127.0.0.2) होनी चाहिए और ::FFFF:7F00:1 नहीं होनी चाहिए। हर सूची IPv6 का समर्थन नहीं करती, इसलिए IPv6 lookup पर भरोसा करने से पहले operator का documentation देखें।

IP-आधारित और domain-आधारित सूचियाँ

सूचियों में क्या होता है, इसके आधार पर वे मोटे तौर पर दो तरह की होती हैं।

RFC 5782 के domain उदाहरण में invalid.edu को doms.example.net से invalid.edu.doms.example.net lookup करके जाँचा जाता है। domain-आधारित सूचियों को कभी-कभी RHSBL (right-hand-side blacklist) भी कहा जाता है। इनकी test entries आरक्षित नामों का उपयोग करती हैं: सूची में TEST होना चाहिए और INVALID नहीं होना चाहिए।

Spamhaus Domain Blocklist (dbl.spamhaus.org) एक व्यापक रूप से इस्तेमाल होने वाला उदाहरण है, और इसका documentation कुछ व्यावहारिक बातें बताता है:

• यह केवल domains के लिए है। इससे IP पते के साथ query करने पर हमेशा "listed" code लौटता है, इसलिए इसे सामान्य IP DNSBL के रूप में configure नहीं करना चाहिए। IP lookups के लिए Spamhaus ZEN (zen.spamhaus.org) की सलाह देता है।
• आप पूरे hostname से query कर सकते हैं; अगर host का domain सूचीबद्ध है तो match होगा।
• SMTP session के दौरान इसे HELO string और MAIL FROM domain से जाँचा जाता है। संदेश स्वीकार होने के बाद इसे headers और body के domains, जैसे URLs और संपर्क पतों, से जाँचा जाता है।

व्यावहारिक नतीजा: साफ़ sending IP delivery की गारंटी नहीं है। सूचीबद्ध sending domain, या संदेश में link किया गया कोई सूचीबद्ध domain, फिर भी block का कारण बन सकता है।

receiving servers DNSBLs का उपयोग कैसे करते हैं

RFC 5782 सामान्य व्यवस्था का वर्णन करता है। मेल server हर आने वाले SMTP connection पर configure किए गए DNSxLs के एक सेट को जाँचता है। blacklist hit होने पर वह connection reject करता है; whitelist hit होने पर स्वीकार करता है। वैकल्पिक रूप से, परिणाम एक scoring function में जाते हैं जो उन्हें दूसरे संकेतों के साथ तौलता है। संदेश मिलने के बाद चलने वाले filters आमतौर पर जाँचने के लिए IPs को Received header fields से या body के URIs से निकालते हैं।

Reject करें या score दें?

यह चुनाव receiver का है। SpamCop का अपना FAQ अपनी सूची को एक आक्रामक tool कहता है और मेल को सीधे reject करने के बजाय संदिग्ध spam को tag या divert करने, या सूची को score के एक कारक के रूप में इस्तेमाल करने की सलाह देता है। वह rejection settings को ऐसे administrators के लिए जानकारी बताता है जो ज़्यादा सूक्ष्म तरीका इस्तेमाल नहीं कर सकते।

receivers को किन खतरों की चेतावनी दी जाती है

• आप निर्णय किसी और को सौंप रहे हैं। DNSxL का उपयोग करने का मतलब है अपने server के प्रबंधन का कुछ हिस्सा सूची के operator को सौंपना। RFC कहता है कि आपको सुनिश्चित करना चाहिए कि सूची की policies आपकी अपनी policies से मेल खाती हों।
• बंद हो चुकी सूचियाँ. सूची बंद करने वाला operator ऐसा wildcard लगा सकता है जो हर पते को सूचीबद्ध कर दे। ऊपर बताई गई test entries से client को इसका पता चलता है।
• Caching. Servers परिणाम cache कर सकते हैं, लेकिन उन्हें TTLs का पालन करना होगा और expire हुए records हटाने होंगे।
• Public resolvers. Spamhaus का FAQ कहता है कि Google Public DNS के ज़रिए की गई queries ज़्यादातर मामलों में "not listed" लौटाएँगी, जिससे असली listings छूट जाती हैं। 127.255.255.x के codes errors हैं, जैसे ब्लॉक किए गए public resolver के ज़रिए query पर 127.255.255.254, और इन्हें "listed" नहीं पढ़ना चाहिए। Spamhaus बताता है कि कुछ servers इसी वजह से गलती से सारा मेल reject कर देते हैं, और अपना resolver चलाने की सलाह देता है।

यही एक कारण है कि जाँच करने वाले दो tools एक ही पते के बारे में अलग-अलग परिणाम दे सकते हैं: वे अलग-अलग resolvers के ज़रिए पूछ रहे हो सकते हैं।

Blacklists बनाम whitelists (DNSBL बनाम DNSWL)

DNSBL और DNSWL से query एक ही तरह की जाती है, लेकिन match का मतलब उल्टा होता है। RFC 5782 के अनुसार, network managers आमतौर पर ट्रैफ़िक ब्लॉक करने के लिए DNSBLs और ट्रैफ़िक को प्राथमिकता से स्वीकार करने के लिए DNSWLs का उपयोग करते हैं। एक ही सूची एक संदर्भ में blacklist और दूसरे में whitelist का काम भी कर सकती है।

dnswl.org (list.dnswl.org) whitelist का एक उदाहरण है। इसका documentation कहता है कि जवाब 127.0.x.y के रूप में आते हैं, जहाँ x एक category है और y 0 (none) से 3 (high) तक का trust level। यह सुझाव देता है कि सूचीबद्ध hosts को greylisting और blacklist जाँच से छूट दी जाए, medium और high trust वाले hosts को spam filtering से छूट दी जाए, और virus scanning कभी न छोड़ी जाए। whitelist entry कितनी छूट देती है, यह फिर भी receiver का फ़ैसला है।

IP या domain के सूचीबद्ध होने के आम कारण

हर operator अपने मानदंड खुद तय करता है, और कई सटीक कारणों को गोपनीय रखते हैं। नीचे दिए कारण operators के प्रकाशित documentation से लिए गए हैं।

• Spam reports और spam traps. SpamCop Blocking List में वे IPs होते हैं जिन्होंने ऐसा मेल भेजा जिसकी SpamCop उपयोगकर्ताओं ने रिपोर्ट की, और spam traps (spammers द्वारा जुटाए या बनाए गए पते) पर गए मेल को ज़्यादा महत्व दिया जाता है। इसका FAQ कहता है कि आगे कोई रिपोर्ट न आने पर listing केवल 24 घंटे रहती है, और रिपोर्ट रुकने पर पते अपने-आप हटा दिए जाते हैं।
• संक्रमित या compromised devices. Spamhaus XBL ऐसे सबूतों पर IPs को अपने-आप सूचीबद्ध करता है जैसे malware, device के ज़रिए तीसरे पक्ष का ट्रैफ़िक relay करने वाले "free VPN" apps, brute-force हमलों में भागीदारी, या चुराए गए credentials से मेल relay करने की कोशिश। अगर कारण बना रहता है, तो अगली बार connect होने पर IP फिर से सूचीबद्ध हो जाता है।
• गलत configuration और सूचियों का खराब रखरखाव. Spamhaus CSS ऐसे HELO names का उल्लेख करता है जो forward DNS से मेल नहीं खाते, compromised websites और CMS installs, असुरक्षित setups, और खराब तरीके से रखी गई mailing lists। यह कहता है कि removal से पहले कारण की पहचान करके उसे ठीक करना ज़रूरी है।
• Policy listings. Spamhaus PBL ऐसे address space को कवर करता है, अक्सर residential broadband, जिससे सीधे मेल नहीं भेजा जाना चाहिए। Spamhaus कहता है कि PBL listing end user के किसी काम का नतीजा नहीं है; ऐसी ranges से मेल authenticated SMTP server के ज़रिए भेजे जाने की अपेक्षा है।
• साझा infrastructure. shared hosting पर किसी दूसरे ग्राहक का मेल भेजना आपके इस्तेमाल किए जा रहे IP को प्रभावित कर सकता है। देखें shared hosting का IP blacklist होने पर क्या करें।

ईमेल deliver न होने पर DNSBLs की भूमिका

DNSBL listing मेल deliver न होने का एक संभावित कारण है, अकेला कारण नहीं। गलत पते, भरे हुए mailboxes, प्राप्तकर्ता की तरफ़ की समस्याएँ और authentication की कमी भी bounces का कारण बन सकती हैं। जब कोई सूची शामिल होती है, तो bounce संदेश में अक्सर उसका नाम या lookup URL होता है।

1. bounce पढ़ें। पाठ में reply code और कोई भी सूची का नाम या URL नोट करें।
2. अपना sending IP और domain पहचानें। headers की Received पंक्तियों का उपयोग करें, या server चलाने वाले से पूछें।
3. प्रमुख सूचियाँ एक साथ जाँचें। blacklist checker का उपयोग करें, फिर हर hit की पुष्टि operator के अपने lookup पेज पर करें।
4. कारण ठीक करें। ऊपर बताए कारणों को एक-एक करके देखें। कारण ठीक होने से पहले किए गए अनुरोध आमतौर पर फिर से listing में खत्म होते हैं।
5. उस operator की प्रक्रिया का पालन करें। कुछ सूचियाँ अपने-आप expire होती हैं, कुछ removal अनुरोध लेती हैं, और कुछ केवल network के मालिक से अनुरोध स्वीकार करती हैं। delist करने का फ़ैसला हमेशा सूची के operator का होता है, और अनुरोध removal का वादा नहीं है।

receivers अपनी filtering भी चलाते हैं, इसलिए listing खत्म होते ही मेल फिर से चलने लगे, यह ज़रूरी नहीं। troubleshooting के पूरे क्रम के लिए ईमेल blacklist में: bounce कैसे पढ़ें देखें, और authentication के लिए SPF, DKIM और DMARC setup। अगर आप खुद कारण का पता नहीं लगा पा रहे, तो आप हमसे मदद माँग सकते हैं।

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

उपयोग किए गए आधिकारिक पेज

इस लेख के तथ्य प्रकाशन के समय नीचे दिए गए आधिकारिक पेजों से मिलाए गए थे। नीतियाँ और व्यवहार बिना सूचना के बदल सकते हैं, इसलिए किसी महत्वपूर्ण बात पर भरोसा करने से पहले आधिकारिक पेज देख लें।

• RFC 5782: DNS Blacklists and Whitelists
• Spamhaus FAQ: DNSBL Usage
• Spamhaus: Domain Blocklist (DBL)
• Spamhaus: Exploits Blocklist (XBL)
• Spamhaus: Combined Spam Sources (CSS)
• Spamhaus: Policy Blocklist (PBL)
• SpamCop FAQ: What is the SpamCop Blocking List (SCBL)?
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?
• dnswl.org: Return codes and recommended usage

संबंधित गाइड

सभी गाइड →