होम › गाइड

Blacklist monitoring: scripts, API और webhook alerts

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

Blacklist monitoring का मतलब है अपने sending IPs और domains के लिए तय समय पर कई DNS blocklists (DNSBLs) से query करना, और alert केवल तब देना जब परिणाम बदले। listing को उसी समय पकड़ लेना, न कि तब जब ग्राहक bounce हुए मेल की शिकायत करें, आपको नुकसान फैलने से पहले कारण खोजने और removal का अनुरोध करने का समय देता है।

इसके दो व्यावहारिक तरीके हैं: खुद एक छोटी dig और cron script चलाएँ, या API और webhooks के ज़रिए जाँच किसी service को सौंप दें। दोनों ही स्थितियों में दो बातें तय करती हैं कि monitor सच बताता है या नहीं: public resolvers के ज़रिए भेजी गई queries को Spamhaus जैसी सूचियाँ अस्वीकार कर देती हैं और इनसे भ्रामक जवाब मिलते हैं, और error codes को कभी भी listings नहीं गिनना चाहिए।

यहाँ उद्धृत सूची operators के नियम नवंबर 2026 तक के उनके आधिकारिक पेजों पर आधारित हैं। नीतियाँ बदलती हैं, इसलिए किसी setup पर भरोसा करने से पहले उनकी पुष्टि करें। DNSBLs कैसे काम करती हैं, इसकी पृष्ठभूमि के लिए DNSBL (RBL) क्या है देखें।

तय करें कि किस पर नज़र रखनी है और कौन-सी सूचियाँ query करनी हैं

सबसे पहले उन चीज़ों को लिख लें जिन पर आपको वास्तव में नज़र रखनी है।

• Sending IP पते. ये वे पते हैं जिनसे आपका मेल server या email provider वास्तव में मेल भेजता है। आपकी website और आपका मेल अक्सर अलग-अलग मशीनों से जाते हैं, इसलिए अपने भेजे गए किसी संदेश के Received headers में पते की पुष्टि करें। अगर आप IPv6 पर मेल भेजते हैं, तो उन पतों की भी निगरानी करें।
• Domains. आपके From पते का domain और आपके संदेशों के links में दिखने वाले सभी domains। Domains की जाँच domain blocklists पर होती है, जो IP सूचियों से अलग हैं।

query का format RFC 5782 में परिभाषित है। IPv4 के लिए आप octets को उल्टा करके सूची का zone जोड़ते हैं, इसलिए किसी सूची पर 192.0.2.99 बन जाता है 99.2.0.192 और उसके बाद zone name। IPv6 के लिए पता उल्टे क्रम में 32 hex nibbles के रूप में लिखा जाता है। domain को सीधे zone के आगे जोड़ दिया जाता है। सूचीबद्ध entry एक A record लौटाती है, परंपरा के अनुसार 127.0.0.0/8 में; जो सूचीबद्ध नहीं है वह NXDOMAIN लौटाती है। RFC यह भी बताता है कि सूचियों को listing का कारण बताने वाला TXT record प्रकाशित करना चाहिए।

एक के बजाय कई सूचियों पर नज़र रखें, क्योंकि सभी receivers एक जैसी सूचियाँ इस्तेमाल नहीं करते। हर return code का अर्थ operator के हिसाब से बदलता है; आम codes के लिए हमारी DNSBL return codes गाइड देखें।

public resolvers गलत जवाब क्यों देते हैं

खुद बनाई गई monitoring में एक आम गलती है Google Public DNS (8.8.8.8) या Cloudflare (1.1.1.1) जैसे public resolver के ज़रिए queries भेजना। Spamhaus का आधिकारिक DNSBL usage FAQ बताता है कि तब क्या होता है:

• Spamhaus DNSBLs के मुफ़्त उपयोग की शर्त है कि उपयोग non-commercial हो और queries किसी public या open resolver से, या generic reverse DNS वाले IP से न आएँ।
• Google Public DNS जैसे मुफ़्त open resolvers के ज़रिए queries को ज़्यादातर मामलों में not-listed (NXDOMAIN) जवाब मिलेगा। दूसरे शब्दों में, सूचीबद्ध IP भी साफ़ दिख सकता है।
• public resolver के ज़रिए queries को 127.255.255.254 भी मिल सकता है। यह error code है, listing नहीं। इसी तरह 127.255.255.252 का मतलब है DNSBL नाम में typo, और 127.255.255.255 का मतलब है queries की अत्यधिक संख्या। Spamhaus कहता है कि इन codes का मतलब यह नहीं लेना चाहिए कि query की गई चीज़ सूचीबद्ध है।
• NXDOMAIN जवाबों को बदलने वाले resolvers इसके बजाय एक IP पता लौटाते हैं, इसलिए आपको कभी सही NXDOMAIN नहीं दिखता।

FAQ की सबसे बड़ी सलाह है अपना खुद का DNS resolver चलाएँ। जिन उपयोगकर्ताओं को public resolver पर ही रहना है, उनके लिए Spamhaus अपनी Data Query Service (DQS) बताता है; क्या मुफ़्त है, इसके लिए उसकी शर्तें देखें। आप वास्तव में कौन-सा resolver इस्तेमाल कर रहे हैं, यह देखने के लिए FAQ dig txt whoami.fastly.net सुझाता है।

RFC 5782 एक अंतर्निहित जाँच जोड़ता है: IPv4 सूची में 127.0.0.2 की entry होनी चाहिए और 127.0.0.1 नहीं होनी चाहिए, और clients को समय-समय पर इन test entries की जाँच करके पुष्टि करनी चाहिए कि सूची काम कर रही है। Spamhaus के उदाहरण में 2.0.0.127.zen.spamhaus.org 127.0.0.10, 127.0.0.4 और 127.0.0.2 लौटाता है, जबकि 1.0.0.127.zen.spamhaus.org NXDOMAIN लौटाता है। monitor को पहले यह जाँचना चाहिए और विफल होने पर उस run को खारिज कर देना चाहिए।

विकल्प 1: dig और cron script

यह एक छोटी script है जो एक IPv4 पते को Spamhaus ZEN और SpamCop (bl.spamcop.net, जिसके बारे में SpamCop का documentation कहता है कि सूचीबद्ध IP के लिए यह 127.0.0.2 जवाब देता है) पर जाँचती है। पता और zones अपने हिसाब से बदलें।

#!/bin/sh
# अपने खुद के recursive resolver से query करें (जैसे उसी host पर unbound), कभी public resolver से नहीं
RESOLVER=127.0.0.1
IP=192.0.2.10
ZONES="zen.spamhaus.org bl.spamcop.net"
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')

q() {
  out=$(dig +time=3 +tries=1 @"$RESOLVER" "$1" A) || { echo ERR; return; }
  case "$out" in
    *"status: NOERROR"*) a=$(printf '%s\n' "$out" | awk '$4=="A"{print $5}'); echo "${a:-NX}" ;;
    *"status: NXDOMAIN"*) echo NX ;;
    *) echo ERR ;;
  esac
}

for Z in $ZONES; do
  # अगर 127.0.0.2 test entry किसी listing code पर resolve नहीं होती, तो इस run पर भरोसा न करें
  case "$(q "2.0.0.127.$Z")" in
    127.255.255.*|NX|ERR) echo "$Z ERROR test-entry"; continue ;;
    127.*) ;;
    *) echo "$Z ERROR test-entry"; continue ;;
  esac
  A=$(q "$REV.$Z")
  case "$A" in
    NX)            echo "$Z CLEAN" ;;
    ERR)           echo "$Z ERROR no-answer" ;;
    127.255.255.*) echo "$Z ERROR $A" ;;
    127.*)         echo "$Z LISTED $A" ;;
    *)             echo "$Z ERROR unexpected $A" ;;
  esac
done

script क्या कर रही है:

• केवल NXDOMAIN status को साफ़ माना जाता है, 127.255.255.x एक error है, और कोई भी दूसरा 127.x एक listing है। 127.0.0.0/8 से बाहर की किसी भी चीज़ को विसंगति माना जाता है, जैसे जवाब बदलने वाला resolver।
• timeout होने पर dig non-zero के साथ exit करता है, जबकि SERVFAIL और REFUSED पर exit 0 होता है। इनमें से किसी को भी साफ़ नहीं माना जाता; script error दर्ज करती है।
• Return codes हर सूची के लिए अलग होते हैं। उदाहरण के लिए, कुछ सूचियाँ 127.0.0.1 का उपयोग यह बताने के लिए करती हैं कि query अस्वीकार हुई, इसलिए जोड़ी गई हर सूची का documentation पढ़ें और ज़रूरत हो तो case statement बढ़ाएँ।

फिर cron से हर run की तुलना पिछले run से करवाएँ और मेल केवल तब भेजें जब कुछ बदला हो:

# उदाहरण: हर घंटे चलाएँ, मेल केवल तब भेजें जब output पिछले run से अलग हो
0 * * * * /usr/local/bin/dnsbl-watch.sh > /var/tmp/dnsbl.now 2>&1; cmp -s /var/tmp/dnsbl.now /var/tmp/dnsbl.prev || mail -s "DNSBL status changed" you@example.com < /var/tmp/dnsbl.now; mv /var/tmp/dnsbl.now /var/tmp/dnsbl.prev

हर घंटे का अंतराल केवल एक उदाहरण है। Spamhaus कम मात्रा वाले, non-commercial उपयोग के लिए मुफ़्त पहुँच देता है, और जो clients उसकी query volume सीमा पार करते हैं उन्हें सशुल्क विकल्प चाहिए; निगरानी वाले IPs की संख्या बढ़ने पर हर सूची की शर्तें जाँचें। FAQ यह भी सलाह देता है कि commands को कुछ बार चलाकर पुष्टि करें कि परिणाम एक जैसे रहते हैं।

विकल्प 2: DNSBL Checker batch API और webhooks

अगर आप resolver और हर सूची के parsing नियम खुद नहीं संभालना चाहते, तो जाँच किसी service से करवा सकते हैं। नीचे इस साइट की v1 API है, केवल उतनी जितना server implementation वास्तव में करता है। reference /en/api-docs पर है और keys members पेज /account पर जारी होती हैं। Sign-up के लिए केवल ईमेल पता चाहिए, और आप ईमेल से भेजे गए link से log in करते हैं।

Authentication और सीमाएँ

• Keys dnsbl_ से शुरू होती हैं और जारी होने के तुरंत बाद केवल एक बार दिखाई जाती हैं; केवल hash संग्रहीत होता है। key दोबारा जारी करने पर पिछली key अमान्य हो जाती है।
• हर request में key को X-API-Key header में भेजें। केवल HTTPS; plain http:// को https:// पर redirect किया जाता है, इसलिए शुरुआत से ही https:// call करें।
• सीमाएँ हैं प्रतिदिन 1,000 checks (एक target एक गिना जाता है), प्रति batch 100 targets, और 50 monitor registrations। दैनिक सीमा पार होने पर आपको daily_limit_exceeded और resets_at timestamp के साथ 429 मिलता है।

Batch checks

domain names या IP पतों का targets array POST /api/v1/batch पर भेजें:

curl -X POST https://dnsblchecker.com/api/v1/batch \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"targets":["example.com"]}'

अगर किसी target की जाँच अभी बाकी है, तो response batch_id के साथ 202 होता है। status के done होने तक हर कुछ सेकंड में GET /api/v1/batch/{batch_id} poll करें (संक्षिप्त उदाहरण; संख्याएँ और सूची का नाम केवल उदाहरण हैं, असली परिणाम नहीं):

{
  "batch_id": 1, "status": "done", "created": "2026-11-03 09:10:41", "count": 1, "pending": 0,
  "results": [
    {
      "target": "example.com", "type": "domain",
      "status": "done", "verdict": "listed",
      "checked_at": "2026-11-03 09:12",
      "lists_checked": 80, "listed_count": 1, "error_count": 4,
      "listed_on": [
        { "list": "ZapBL RHSBL", "zone": "rhsbl.zapbl.net", "response": "127.0.0.2" }
      ]
    }
  ]
}

• अगर कम से कम एक सूची listing बताती है तो verdict listed होता है, वरना clean। जिन सूचियों का timeout हुआ, या जिन्होंने 127.255.255.x जैसे error code से जवाब दिया, उन्हें error_count में गिना जाता है और कभी listings के रूप में नहीं।
• अगर पिछले 30 दिनों का कोई संग्रहीत परिणाम मौजूद है, तो batch वही लौटाता है। तय समय की monitoring के लिए हमेशा checked_at देखें।
• गलत format वाले targets कारण के साथ rejected में वापस आते हैं और गिने नहीं जाते। अगर आप URL देते हैं, तो केवल host name इस्तेमाल होता है। 192.0.2.0/24 जैसी केवल documentation के लिए बनी ranges अस्वीकार की जाती हैं, इसलिए असली sending IP से test करें।

Webhook monitoring

POST /api/v1/monitors से एक target और एक callback_url register करें। इसके बाद हर registered target की जाँच दिन में एक बार cache का उपयोग किए बिना होती है (पहली जाँच register करने के लगभग एक दिन के भीतर होती है), और आपके URL पर JSON POST केवल पहली जाँच (monitor.initial) पर और तब भेजा जाता है जब verdict listed और clean के बीच बदलता है (monitor.status_changed)।

curl -X POST https://dnsblchecker.com/api/v1/monitors \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"target":"example.com","callback_url":"https://your-app.example/hooks/dnsbl"}'

• response में मौजूद signing_secret केवल एक बार दिखाया जाता है। हर delivery के साथ X-DNSBL-Signature: sha256=... header आता है, जो उस secret को key बनाकर raw body का HMAC-SHA256 है। इसे अपनी तरफ़ verify करें।
• callback_url port 443 पर https होना चाहिए और public IP पर resolve होना चाहिए; redirects follow नहीं किए जाते, और timeout 10 सेकंड है, इसलिए भारी काम को queue में डालें और जल्दी जवाब दें।
• अगर आपका endpoint 2xx के अलावा कुछ भी लौटाता है, या connection विफल होता है, तो delivery अगली दैनिक जाँच पर फिर से की जाती है। कारण GET /api/v1/monitors में last_delivery_error के रूप में दिखता है, और DELETE /api/v1/monitors/{monitor_id} किसी monitor को हटाता है।

import hmac, hashlib
expected = "sha256=" + hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
ok = hmac.compare_digest(expected, request.headers.get("X-DNSBL-Signature", ""))

alerts की रूपरेखा: आवृत्ति, कई सूचियाँ और झूठे alarm

monitor तभी उपयोगी है जब कुछ महीनों बाद भी लोग उसके alerts पढ़ते रहें। जो लगातार बजता रहता है, उसे जल्द ही अनदेखा कर दिया जाता है।

आवृत्ति

• query कितनी बार करनी है और सूचना कितनी बार देनी है, इन्हें अलग रखें। तय समय पर query करें, लेकिन सूचना केवल स्थिति बदलने पर दें। रोज़ का "सब ठीक है" संदेश उस एक alert को दबा देता है जो मायने रखता है।
• RFC 5782 कहता है कि सूची के TTLs से यह झलकना चाहिए कि सूची कितनी तेज़ी से बदलती है, और spam स्रोतों की सूचियाँ कुछ मिनटों के TTLs इस्तेमाल कर सकती हैं। अपना अंतराल यह जानते हुए चुनें कि कुछ listings जल्दी आती हैं और जल्दी expire हो जाती हैं।
• भारी querying किसी सूची की उपयोग शर्तों का उल्लंघन कर सकती है, या असली जवाबों की जगह आपको 127.255.255.255 (अत्यधिक queries) दिला सकती है।

कई सूचियाँ

• हर alert में सूची का नाम शामिल करें। सूचियों में फ़र्क होता है कि कितने receivers उनका उपयोग करते हैं, इसलिए आप अपने प्राप्तकर्ताओं के लिए सबसे ज़्यादा मायने रखने वाली सूचियों पर तुरंत alert दे सकते हैं और बाकी को एक digest में इकट्ठा कर सकते हैं।
• ऊपर वाला webhook केवल तब चलता है जब verdict listed और clean के बीच बदलता है। अगर कोई target पहले से सूचीबद्ध है और फिर दूसरी सूची में भी दिखता है, तो कोई event नहीं भेजा जाता। इस स्थिति को पकड़ने के लिए GET /api/v1/monitors में last_listed_count पर नज़र रखें, या batch चलाकर listed_on पढ़ें।

False positives और अस्थायी जवाब

• errors को listings से अलग दर्ज करें। Spamhaus operators को चेतावनी देता है कि उसके error codes के आधार पर मेल reject या filter न करें; monitoring पर भी यही तर्क लागू होता है। timeout या 127.255.255.x जवाब से कभी listing alert नहीं बनना चाहिए।
• किसी एक अजीब परिणाम पर प्रतिक्रिया से बचने के लिए लगातार दो एक जैसे परिणामों के बाद ही alert दें, या कुछ भेजने से पहले कुछ मिनट बाद फिर से query करें।
• अगर errors बने रहें, तो resolver में बदलाव या सूची की तरफ़ बदलाव का संदेह करें, और पहले test-entry का परिणाम देखें।
• Spamhaus PBL पर residential IP एक policy listing है, आरोप नहीं: इसका मतलब है कि उस पते से सीधे मेल नहीं भेजा जाना चाहिए। हर सूची के लिए तय करें कि alert किसे माना जाए (देखें Spamhaus removal)।

listing पकड़ी जाने पर क्या करें

1. इसकी पुष्टि करें। operator का अपना lookup पेज देखें और सूची का नाम, समय और दिखाया गया कोई भी कारण नोट करें।
2. पहले कारण ठीक करें। compromised accounts, दुरुपयोग किए गए web forms, संक्रमित मशीनें, सूचियों का खराब रखरखाव और मेल न खाते reverse DNS (PTR) या HELO names देखें। कारण बने रहते हुए removal का अनुरोध करने से आमतौर पर नई listing होती है।
3. उस सूची की removal प्रक्रिया का पालन करें। delist करने का फ़ैसला हर सूची के operator का होता है, और अनुरोध भेजना इस बात का वादा नहीं कि listing हटेगी। अगर IP आपके नियंत्रण में नहीं है, जैसे shared hosting में, तो अपने hosting provider या ISP से संपर्क करें।
4. monitor से परिणाम की पुष्टि होने दें। receivers अपने filters भी चलाते हैं, इसलिए verdict के clean होने के बाद भी delivery पर नज़र रखें।

किसी IP या domain को एक बार देखने के लिए blacklist checker का उपयोग करें। अगर कारण खोजना या अनुरोध संभालना आपके बस से बाहर हो, तो आप हमसे मदद माँग सकते हैं। मेल bounce होने पर troubleshooting के पूरे रास्ते के लिए blacklist के कारण ब्लॉक हुआ ईमेल देखें।

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

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

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

• RFC 5782: DNS Blacklists and Whitelists
• Spamhaus FAQ: DNSBL Usage
• Spamhaus: Using our public mirrors? Check your return codes now
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?

संबंधित गाइड

सभी गाइड →