Trang chủ › Hướng dẫn

Giám sát blacklist: script, API và cảnh báo qua webhook

Ngày đăng 2026-11-03 ／ Cập nhật 2026-11-03 ／ Tác giả Yuki Nakazawa

Giám sát danh sách đen nghĩa là định kỳ truy vấn nhiều danh sách chặn DNS (DNSBL) cho các IP và tên miền gửi thư của bạn, và chỉ phát cảnh báo khi kết quả thay đổi. Phát hiện việc bị liệt kê ngay khi nó xảy ra, thay vì khi khách hàng báo thư bị trả về, giúp bạn có thời gian tìm nguyên nhân và yêu cầu gỡ trước khi thiệt hại lan rộng.

Có hai cách thực tế để làm việc này: tự chạy một script nhỏ bằng dig và cron, hoặc giao việc kiểm tra cho một dịch vụ thông qua API và webhook. Dù chọn cách nào, có hai chi tiết quyết định việc công cụ giám sát có phản ánh đúng sự thật hay không: các truy vấn gửi qua resolver công cộng bị những danh sách như Spamhaus từ chối và cho ra câu trả lời gây hiểu nhầm, và mã lỗi tuyệt đối không được tính là mục liệt kê.

Các quy tắc của đơn vị vận hành danh sách được trích dẫn ở đây dựa trên trang chính thức của họ tính đến tháng 11 năm 2026. Chính sách có thể thay đổi, vì vậy hãy xác nhận trước khi dựa vào một cấu hình. Để tìm hiểu nền tảng về cách hoạt động của DNSBL, xem DNSBL (RBL) là gì.

Kiểm tra miễn phí xem tên miền hoặc địa chỉ IP của bạn có nằm trong khoảng 345 danh sách đen hay không.

Xác định đối tượng cần theo dõi và danh sách cần truy vấn

Hãy bắt đầu bằng việc ghi lại những đối tượng bạn thực sự cần theo dõi.

Định dạng truy vấn được định nghĩa trong RFC 5782. Với IPv4, bạn đảo ngược các octet và nối thêm vùng (zone) của danh sách, nên 192.0.2.99 trên một danh sách sẽ thành 99.2.0.192 theo sau là tên vùng. Với IPv6, địa chỉ được viết thành 32 nibble thập lục phân theo thứ tự ngược. Tên miền thì chỉ cần đặt phía trước vùng. Một mục bị liệt kê trả về bản ghi A, theo quy ước nằm trong 127.0.0.0/8; mục không bị liệt kê trả về NXDOMAIN. RFC cũng lưu ý rằng danh sách nên công bố bản ghi TXT giải thích lý do liệt kê.

Hãy theo dõi nhiều danh sách thay vì chỉ một, vì không phải bên nhận nào cũng dùng cùng các danh sách. Ý nghĩa của từng mã trả về khác nhau tùy đơn vị vận hành; hướng dẫn của chúng tôi về mã trả về DNSBL trình bày các mã thường gặp.

Vì sao resolver công cộng cho câu trả lời sai

Một lỗi phổ biến trong các hệ thống giám sát tự xây dựng là gửi truy vấn qua resolver công cộng như Google Public DNS (8.8.8.8) hoặc Cloudflare (1.1.1.1). Câu hỏi thường gặp chính thức về cách dùng DNSBL của Spamhaus giải thích điều gì xảy ra:

Khuyến nghị hàng đầu của trang câu hỏi thường gặp là tự vận hành resolver DNS riêng. Với người dùng buộc phải dùng resolver công cộng, Spamhaus giới thiệu Data Query Service (DQS); hãy xem điều khoản của dịch vụ này để biết phần nào miễn phí. Trang này gợi ý dùng dig txt whoami.fastly.net để xem bạn thực sự đang dùng resolver nào.

RFC 5782 bổ sung một bước tự kiểm tra có sẵn: danh sách IPv4 phải chứa mục cho 127.0.0.2 và không được chứa 127.0.0.1, và máy khách nên định kỳ kiểm tra các mục kiểm thử này để xác nhận danh sách đang hoạt động. Trong ví dụ của Spamhaus, 2.0.0.127.zen.spamhaus.org trả về 127.0.0.10, 127.0.0.4 và 127.0.0.2, còn 1.0.0.127.zen.spamhaus.org trả về NXDOMAIN. Công cụ giám sát nên kiểm tra điều này trước và bỏ qua lần chạy nếu kiểm tra thất bại.

Cách 1: script dig và cron

Dưới đây là một script tối giản kiểm tra một địa chỉ IPv4 trên Spamhaus ZEN và SpamCop (bl.spamcop.net, mà theo tài liệu của SpamCop sẽ trả về 127.0.0.2 cho IP bị liệt kê). Hãy thay địa chỉ và các vùng bằng của bạn.

#!/bin/sh
# Truy vấn qua resolver đệ quy của chính bạn (ví dụ unbound trên cùng máy), không bao giờ dùng resolver công cộng
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
  # Nếu mục kiểm thử 127.0.0.2 không phân giải ra mã liệt kê, đừng tin kết quả của lần chạy này
  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 này làm những việc sau:

Sau đó, để cron so sánh mỗi lần chạy với lần trước và chỉ gửi thư khi có thay đổi:

# Ví dụ: chạy mỗi giờ, chỉ gửi thư khi kết quả khác với lần chạy trước
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

Chu kỳ mỗi giờ chỉ là ví dụ. Spamhaus cung cấp quyền truy cập miễn phí cho mục đích phi thương mại với lưu lượng thấp, và các máy khách vượt ngưỡng lưu lượng truy vấn của họ cần dùng phương án trả phí; hãy kiểm tra điều khoản của từng danh sách khi số IP được giám sát tăng lên. Trang câu hỏi thường gặp cũng khuyên nên thử lệnh vài lần để xác nhận kết quả không đổi.

Cách 2: API hàng loạt và webhook của DNSBL Checker

Nếu bạn không muốn tự duy trì resolver và các quy tắc phân tích riêng cho từng danh sách, bạn có thể để một dịch vụ chạy việc kiểm tra. Dưới đây là API v1 của trang này, chỉ trong phạm vi những gì phần triển khai phía máy chủ thực sự làm. Tài liệu tham chiếu nằm tại /en/api-docs và khóa được cấp trên trang thành viên tại /account. Đăng ký chỉ cần địa chỉ email, và bạn đăng nhập bằng liên kết được gửi qua email.

Xác thực và giới hạn

Kiểm tra hàng loạt

Gửi một mảng targets gồm tên miền hoặc địa chỉ IP tới 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"]}'

Nếu còn đối tượng nào cần kiểm tra, phản hồi sẽ là 202 kèm batch_id. Gọi GET /api/v1/batch/{batch_id} vài giây một lần cho đến khi status là done (ví dụ rút gọn; các con số và tên danh sách chỉ để minh họa, không phải kết quả thật):

{
  "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" }
      ]
    }
  ]
}

Giám sát qua webhook

Đăng ký một target và một callback_url bằng POST /api/v1/monitors. Sau đó, mỗi đối tượng đã đăng ký được kiểm tra một lần mỗi ngày mà không dùng bộ nhớ đệm (lần kiểm tra đầu tiên chạy trong vòng khoảng một ngày sau khi đăng ký), và một yêu cầu POST dạng JSON chỉ được gửi tới URL của bạn ở lần kiểm tra đầu tiên (monitor.initial) và khi kết luận chuyển đổi giữa bị liệt kê và sạch (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"}'
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", ""))

Thiết kế cảnh báo: tần suất, nhiều danh sách và báo động giả

Công cụ giám sát chỉ hữu ích nếu sau vài tháng mọi người vẫn còn đọc cảnh báo của nó. Một công cụ báo liên tục sẽ sớm bị phớt lờ.

Tần suất

Nhiều danh sách

Dương tính giả và câu trả lời nhất thời

Cần làm gì khi phát hiện bị liệt kê

  1. Xác nhận lại. Kiểm tra trên trang tra cứu của chính đơn vị vận hành và ghi lại tên danh sách, thời điểm và mọi lý do được hiển thị.
  2. Khắc phục nguyên nhân trước. Tìm các tài khoản bị chiếm quyền, biểu mẫu web bị lợi dụng, máy bị nhiễm, việc quản lý danh sách nhận thư kém, và DNS ngược (PTR) hoặc tên HELO không khớp. Yêu cầu gỡ khi nguyên nhân vẫn còn thường dẫn đến việc bị liệt kê lại.
  3. Làm theo quy trình gỡ của danh sách đó. Quyết định gỡ khỏi danh sách thuộc về từng đơn vị vận hành, và việc gửi yêu cầu không phải là lời hứa rằng mục liệt kê sẽ được gỡ. Nếu bạn không kiểm soát IP, như với hosting chia sẻ, hãy liên hệ nhà cung cấp hosting hoặc ISP của bạn.
  4. Để công cụ giám sát xác nhận kết quả. Bên nhận cũng chạy bộ lọc riêng, vì vậy hãy tiếp tục theo dõi việc chuyển thư sau khi kết luận trở lại trạng thái sạch.

Để kiểm tra nhanh một IP hoặc tên miền, hãy dùng công cụ kiểm tra danh sách đen. Nếu việc truy tìm nguyên nhân hoặc xử lý các yêu cầu vượt quá khả năng của bạn, bạn có thể nhờ chúng tôi hỗ trợ. Để xem toàn bộ quy trình xử lý sự cố khi thư bị trả về, xem email bị chặn bởi danh sách đen.

Nếu bạn không muốn tự xử lý

Chúng tôi giới thiệu các nhà cung cấp nhận làm yêu cầu gỡ tên (delist), tư vấn và hỗ trợ (từ JPY 50,000). Việc gỡ tên do từng đơn vị quản lý danh sách quyết định và không thể được cam kết.

Nhận hỗ trợ

Trang web này có thể nhận phí giới thiệu từ các nhà cung cấp được liệt kê. About

Câu hỏi thường gặp

Tôi kiểm tra qua 8.8.8.8 và không thấy bị liệt kê. Vậy là sạch chưa?

Không hẳn. Câu hỏi thường gặp của Spamhaus cho biết truy vấn qua các resolver mở miễn phí như Google Public DNS trong hầu hết trường hợp sẽ nhận phản hồi không bị liệt kê (NXDOMAIN), nên một IP bị liệt kê có thể trông như sạch. Hãy truy vấn từ resolver của chính bạn, hoặc dùng trang tra cứu của đơn vị vận hành.

Tôi nhận được 127.255.255.254. Có phải tôi bị liệt kê?

Không. Đây là mã lỗi được trả về cho các truy vấn qua resolver công cộng hoặc resolver mở, và Spamhaus nêu rằng nó không có nghĩa là đối tượng bị liệt kê. Hãy ghi nhận nó là lỗi và không gửi cảnh báo bị liệt kê.

Tôi có thể chỉ gọi API hàng loạt mỗi ngày để làm công cụ giám sát không?

Một lô có thể trả về kết quả đã lưu tới 30 ngày trước, nên không phải lúc nào cũng là trạng thái hôm nay. Hãy kiểm tra checked_at, hoặc dùng giám sát qua webhook (POST /api/v1/monitors), vốn chạy một lần kiểm tra mới mỗi ngày.

Tôi có nên yêu cầu gỡ ngay khi có cảnh báo không?

Hãy khắc phục nguyên nhân trước. Yêu cầu gửi khi vấn đề vẫn còn thường dẫn đến việc bị liệt kê lại. Quyết định luôn thuộc về đơn vị vận hành danh sách.

Các trang chính thức được tham khảo

Thông tin trong bài viết này đã được đối chiếu với các trang chính thức dưới đây tại thời điểm đăng. Chính sách và cách vận hành có thể thay đổi mà không báo trước, vì vậy bạn hãy kiểm tra lại các trang chính thức trước khi dựa vào thông tin cho việc quan trọng.

Hướng dẫn liên quan

Giải thích mã trả về DNSBL: 127.0.0.2, 127.255.255.x và NXDOMAIN

Cách đọc mã trả về DNSBL: ý nghĩa của 127.0.0.2 theo RFC 5782, mã của Spamhaus, SpamCop và UCEPROTECT, mã lỗi, và NXDOMAIN khác SERVFAIL thế nào.

Gỡ tên khỏi Spamhaus: cách gỡ IP hoặc tên miền bị liệt kê

Bị Spamhaus liệt kê? Xác định bạn nằm trong danh sách nào (ZEN, PBL, XBL, CSS, SBL, DBL), ý nghĩa của mã trả về và cách gỡ tên đúng cho từng danh sách.

Email bị blacklist? Cách đọc thư báo lỗi và gỡ khỏi danh sách đen

Email bị chặn vì danh sách đen? Đọc mã lỗi trả lại, kiểm tra nguyên nhân theo đúng thứ tự, xác định danh sách nào quan trọng và yêu cầu gỡ đúng cách.

Tất cả hướng dẫn →