[Bug]: Domain reputation DNSBL lookups query the raw domain name against IP-based blocklists, so `checkReputation()` almost never flags anything

[Rudra-clrscr]

Bug Description

DomainReputationService.checkReputation() (implemented for #955, which is closed) is meant to detect whether a sender's domain is listed on known blocklists. It queries three DNSBL zones — zen.spamhaus.org, bl.spamcop.net, and dnsbl.sorbs.net — all of which are IP-based blocklists. The correct query format for an IP-based DNSBL is the reversed IP address prepended to the zone (e.g. 2.0.0.127.zen.spamhaus.org to check whether 127.0.0.2 is listed), not a domain name prepended to the zone.

The current implementation queries ${domain}.${zone} directly, e.g. example.com.zen.spamhaus.org. Since these zones aren't keyed by domain name (only Spamhaus's separate dbl.spamhaus.org zone supports domain-based lookups, and it isn't one of the three configured here), this returns NXDOMAIN for essentially every input. listedCount stays 0, score stays 0, and isSuspicious is always false — the feature silently never flags a domain, even when its mail-sending IP is genuinely blacklisted.

Service: backend/services/domainReputation.js L16–L20
Caller: backend/routes/predictionRoutes.js L585 (domainReputation.checkReputation(domain)), feeding directly into the /predict response's domainReputation field (L600)

Steps to Reproduce

1. Query the zone the way the code does, using a domain name:

   node -e "
   const dns = require('dns');
   dns.resolve('example.com.zen.spamhaus.org', 'A', (err, addr) => {
     console.log(err ? 'NXDOMAIN (not listed / wrong query format)' : addr);
   });
   "
   # -> NXDOMAIN, because Spamhaus ZEN is IP-keyed, not domain-keyed

2. Compare with the documented Spamhaus ZEN test address (127.0.0.2, guaranteed to return a hit when queried in the correct reversed-IP format):

   node -e "
   const dns = require('dns');
   dns.resolve('2.0.0.127.zen.spamhaus.org', 'A', (err, addr) => {
     console.log(err ? 'not listed' : 'LISTED: ' + addr);
   });
   "
   # -> LISTED: [ '127.0.0.2', ... ] as expected, using the reversed-IP format

3. Call the live /predict endpoint (or checkReputation() directly) and observe domainReputation.isSuspicious is always false and score is always 0, regardless of the sender domain used in test requests.

Expected Behavior

checkReputation(domain) should resolve the domain's mail-sending IP(s), query the DNSBL zones using the reversed-IP format, and correctly return isSuspicious: true / a non-zero score for domains whose sending IP is actually blacklisted.

Actual Behavior

Every call effectively returns { score: 0, isSuspicious: false, listedIn: 'None' } because the DNS queries are malformed for the zones being used, regardless of the domain's real reputation.

Screenshots

No response

Additional Information

No response

[github-actions]

👋 Welcome back! Thanks for your continued contribution. Your issue/PR is received and waiting for maintainer review.

[github-actions]

The reported issue describes a bug in the DomainReputationService.checkReputation() function, where it incorrectly queries domain names against IP-based DNS blocklists (DNSBLs). Since these blocklists require reverse IP queries (e.g., reversing the digits of an IP address), querying raw domain names always fails (NXDOMAIN), resulting in the function never flagging potentially suspicious domains. The expected behavior would involve resolving the domain's mail-sending IP addresses and performing correct reverse-IP queries against the DNSBLs to ensure proper reputation checks.