होम › गाइड

DNSBL return codes की व्याख्या: 127.0.0.2, 127.255.255.x और NXDOMAIN

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

अगर DNSBL lookup 127.0.0.0/8 में कोई पता लौटाता है, तो IP या domain सूचीबद्ध है; NXDOMAIN जवाब का मतलब है कि वह सूचीबद्ध नहीं है। इसके आगे, सटीक संख्या हर सूची के लिए अलग होती है, कुछ 127.x जवाब listings नहीं बल्कि error codes होते हैं, और SERVFAIL या timeout listing की स्थिति के बारे में कुछ भी नहीं बताते।

यह गाइड RFC 5782 में दर्ज परंपराओं और उन return codes को समझाती है जिन्हें Spamhaus, SpamCop और UCEPROTECT अपने पेजों पर बताते हैं। यह नवंबर 2026 तक के उन्हीं आधिकारिक पेजों पर आधारित है। सूचियाँ अपना data और policies बदलती रहती हैं, इसलिए किसी परिणाम पर कार्रवाई करने से पहले operator का documentation देखें। अगर आपको blocklists के काम करने के तरीके की पृष्ठभूमि चाहिए, तो DNSBL (RBL) क्या है से शुरुआत करें।

बुनियादी बातें: return codes के बारे में RFC 5782 क्या कहता है

फ़रवरी 2010 में प्रकाशित RFC 5782 बताता है कि DNS blacklists और whitelists से query कैसे की जाती है और उनके जवाब कैसे दिखते हैं। यह एक Informational document है, Standards Track specification नहीं: यह आम प्रथा को दर्ज करता है, और मान तय करने का विवरण हर सूची के operator पर छोड़ दिया गया है।

lookup कैसे बनाया जाता है

IPv4 के लिए आप octets का क्रम उल्टा करते हैं और सूची का zone जोड़ते हैं। 192.0.2.99 को bl.example.com पर जाँचने के लिए:

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

IPv6 के लिए पता उल्टे क्रम में 32 hex nibbles के रूप में लिखा जाता है, उसके बाद zone आता है। domain-आधारित सूचियाँ सीधे domain name के बाद zone name लेती हैं; RFC बताता है कि name-आधारित सूचियाँ IP-आधारित सूचियों की तुलना में बहुत कम आम हैं।

A record: सूचीबद्ध है या नहीं

• सूचीबद्ध: सूची एक A record लौटाती है। RFC कहता है कि अनचाहे network ट्रैफ़िक को रोकने के लिए सभी A मान 127.0.0.0/8 में होने चाहिए, और यह कि मान परंपरा के अनुसार 127.0.0.2 होता है।
• सूचीबद्ध नहीं: उस पते के लिए कोई भी record नहीं होना चाहिए। DNS की भाषा में जवाब NXDOMAIN होता है, यानी वह नाम मौजूद नहीं है।
• A record के मान को IP पते के रूप में इस्तेमाल नहीं करना चाहिए। 127.0.0.2 एक संकेत (flag) है, connect करने लायक कोई server नहीं।

TXT record: कारण और एक URL

RFC के अनुसार, DNSBLs को यह बताने वाला TXT record प्रकाशित करना चाहिए कि कोई entry क्यों सूचीबद्ध है, और उस कारण में अक्सर अधिक जानकारी वाला URL होता है। Client software को A record जाँचना ज़रूरी है और वह TXT record भी जाँच सकता है। TXT का पाठ अक्सर SMTP error message में इस्तेमाल होता है, इसलिए bounce संदेश में उसी से लिया गया lookup या removal URL हो सकता है।

सूचियाँ अलग-अलग संख्याएँ क्यों लौटाती हैं: sublists और bit masks

127.0.0.2 के अलावा कोई मान आमतौर पर बताता है कि zone कई sublists को जोड़ता है। RFC 5782 इन्हें दर्शाने के तीन तरीके बताता है: subdomains, कई A records, और bit-encoded मान।

• कई A records: हर sublist का अपना मान होता है, और पता जिस-जिस sublist में है, सूची हर एक के लिए एक A record लौटाती है।
• Bit masks: हर sublist को एक bit दिया जाता है, और जवाब match होने वाली सभी sublists के bits का logical OR होता है। RFC के उदाहरण में, 127.0.0.2 और 127.0.0.4 sublists पर मौजूद पता 127.0.0.6 लौटाता है।

मुख्य बात यह है कि RFC खुद कहता है कि sublist के नामों को मानों से जोड़ने की कोई व्यापक रूप से इस्तेमाल होने वाली परंपरा नहीं है। एक ही संख्या का अलग-अलग सूचियों पर अलग मतलब हो सकता है। return code को हमेशा उसे देने वाले zone के साथ, उसी सूची के अपने documentation के अनुसार पढ़ें। RFC यह भी कहता है कि client software को लौटे मानों पर bit masks और value range tests लागू करने में सक्षम होना चाहिए।

Spamhaus ZEN कई जवाबों वाली शैली का अच्छा उदाहरण है। इसका documentation कहता है कि एक query आमतौर पर एक ही DNS response में कई अलग जवाब देती है, IP जिस dataset में सूचीबद्ध है उसके लिए एक-एक, और हर dataset का return code अलग होता है। एक साथ दो या तीन codes दिखना सामान्य है।

प्रमुख blocklists के return codes

नीचे की तालिका में वे return codes हैं जिन्हें operators अपने आधिकारिक पेजों पर बताते हैं।

• Spamhaus: ZEN, SBL, CSS, XBL और PBL को जोड़ता है और केवल IP पतों को कवर करता है; domains की जाँच DBL पर होती है। DBL 127.0.1.0/24 का और Zero Reputation Domains सूची 127.0.2.0/24 का उपयोग करती है। क्योंकि DBL IP query का जवाब हमेशा 127.0.1.255 से देता है, इसलिए इसका उपयोग IPs जाँचने के लिए नहीं किया जा सकता। Spamhaus की हर सूची का अर्थ और removal का अनुरोध कैसे करें, इसके लिए हमारी Spamhaus removal गाइड देखें।
• SpamCop: आधिकारिक FAQ सूचीबद्ध IP बताने वाले response के रूप में 127.0.0.2 देता है। यह भी सलाह देता है कि मेल को सीधे reject करने के बजाय उपयोगकर्ताओं को filter किए गए मेल तक पहुँच दी जाए, उदाहरण के लिए उसे tag करके या अलग folder में ले जाकर। Removal हमारी SpamCop delisting गाइड में बताया गया है।
• UCEPROTECT: DNS usage पेज तीनों zone names बताता है, लेकिन return values का वर्णन नहीं करता। यह कहता है कि DNS तरीका असल में केवल छोटे से मध्यम मेल servers के लिए उपयोगी है, और प्रतिदिन 100,000 से अधिक requests वाले systems के लिए rsync सुझाता है। levels की व्याख्या हमारी UCEPROTECT Level 2 और 3 गाइड में है।
• Barracuda: इसके return values यहाँ शामिल नहीं हैं। Barracuda Central के अपने पेज देखें।

127.255.255.x और public resolvers: ऐसे जवाब जो listings नहीं हैं

Spamhaus 127.255.255.0/24 को error codes के लिए आरक्षित रखता है। ये किसी भी zone के लिए लौटाए जा सकते हैं, और आधिकारिक FAQ कहता है कि इनका मतलब यह नहीं लेना चाहिए कि query की गई चीज़ सूचीबद्ध है।

public resolver के परिणाम भरोसेमंद क्यों नहीं हैं

Spamhaus का FAQ कहता है कि बड़े public resolvers के ज़रिए query करने पर ज़्यादातर मामलों में आपको not-listed (NXDOMAIN) जवाब मिलता है। दूसरे शब्दों में, सूचीबद्ध IP भी साफ़ दिख सकता है। वही FAQ उल्टी समस्या, जिसमें लगता है कि सूची पूरे internet को ब्लॉक कर रही है, का सबसे आम कारण Amazon, Quad9, Google, Cloudflare या किसी दूसरे public resolver का उपयोग बताता है।

कुछ resolvers NXDOMAIN जवाबों को बदल भी देते हैं और मौजूद न होने वाले नामों के लिए IP पता लौटाते हैं। मेल server इसे गलती से listing समझ सकता है। FAQ सुझाव देता है कि मेल server को 127.0.0.0/8 से बाहर के हर response को नज़रअंदाज़ करने का निर्देश दें, अपना resolver चलाएँ, या अपने ISP या DNS provider से संपर्क करें। आप वास्तव में कौन-सा resolver इस्तेमाल कर रहे हैं, यह देखने के लिए FAQ यह जाँच देता है:

dig txt whoami.fastly.net

अगर आप अपने मेल server पर DNSBL filtering चलाते हैं, तो यह भी सुनिश्चित करें कि 127.255.255.x जवाब दिखने पर वह मेल reject न करे। Spamhaus इसे misconfiguration बताता है।

NXDOMAIN बनाम SERVFAIL बनाम timeout

हर DNS response में एक response code (RCODE) होता है, जो RFC 1035 में परिभाषित है। DNSBL परिणाम पढ़ते समय RCODE को A record के मान से अलग रखें।

RFC 5782 यह नहीं बताता कि विफल होने वाली या जवाब न देने वाली सूची को clients कैसे संभालें। SERVFAIL या timeout को सूचीबद्ध या सूचीबद्ध नहीं, किसी भी रूप में पढ़ना गलती है। बाद में फिर कोशिश करें या किसी दूसरे रास्ते से query करें।

सूची काम कर रही है या नहीं, यह test entries से जाँचें

RFC 5782 माँगता है कि IPv4 सूचियों में 127.0.0.2 की entry हो और 127.0.0.1 की न हो। IPv6 सूचियाँ ::FFFF:7F00:2 (सूचीबद्ध) और ::FFFF:7F00:1 (सूचीबद्ध नहीं) का उपयोग करती हैं, और domain सूचियाँ आरक्षित नाम TEST (सूचीबद्ध) और INVALID (सूचीबद्ध नहीं) का।

dig +short 2.0.0.127.zen.spamhaus.org A
dig +short 1.0.0.127.zen.spamhaus.org A

अगर पहली query listing code (127.255.255.x के अलावा कोई 127.x मान) लौटाती है और दूसरी कुछ नहीं लौटाती, तो उस सूची पर lookups काम कर रहे हैं। अगर पहली 127.255.255.x लौटाती है, तो आपके query के रास्ते को अस्वीकार किया जा रहा है। RFC कहता है कि clients को समय-समय पर test entries जाँचनी चाहिए और सही test entries के बिना किसी सूची का उपयोग नहीं करना चाहिए। यह भी बताता है कि सूची बंद करने वाले operators ने कभी-कभी हर entry हटा दी है, या ऐसा wildcard लगा दिया है जो हर पते को सूचीबद्ध कर देता है। अगर 127.0.0.1 भी सूचीबद्ध के रूप में लौटता है, तो सूची या अपने query के रास्ते पर संदेह करें, अपने IP पर नहीं।

अपना परिणाम पढ़ने का व्यावहारिक तरीका

1. सही IP या domain चुनें। bounce संदेश में दिया IP, या message headers की Received पंक्तियों से भेजने वाले server का IP इस्तेमाल करें।
2. कई सूचियाँ एक साथ जाँचें। हमारा blacklist checker प्रमुख सूचियों को एक बार में जाँचता है।
3. हर code को उसके zone के साथ पढ़ें। 127.0.0.0/8 में listing code (127.255.255.x के अलावा) का मतलब है सूचीबद्ध; देखें कि उस सूची पर उस मान का क्या अर्थ है। 127.255.255.x जवाब, SERVFAIL या timeout का मतलब है कि स्थिति अभी अज्ञात है।
4. TXT record और operator का lookup पेज देखें। कई सूचियाँ कारण या URL लौटाती हैं। operator के अपने lookup पेज को आधिकारिक परिणाम मानें।
5. कारण ठीक करें, फिर उस सूची की removal प्रक्रिया का पालन करें। delist करना है या नहीं और कब, यह हर operator तय करता है। अगर कारण बना रहता है, तो listing आमतौर पर लौट आती है।

मेल bounce होने पर troubleshooting के पूरे रास्ते के लिए blacklist के कारण ब्लॉक हुआ ईमेल देखें। अगर आपको परिणाम समझने या कारण खोजने में मदद चाहिए, तो आप delisting के बारे में हमसे पूछ सकते हैं।

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

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

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

• RFC 5782: DNS Blacklists and Whitelists
• RFC 1035: Domain Names - Implementation and Specification (RCODE)
• Spamhaus FAQ: DNSBL Usage (return codes and public resolvers)
• Spamhaus: ZEN Blocklist
• Spamhaus: Domain Blocklist (DBL)
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?
• UCEPROTECT: Using DNS Lookups

संबंधित गाइड

सभी गाइड →