Should rblcheck query NS servers directly?

[JulienPalard]

Currently rblcheck use the machine configured servers, the machine can be configured to hit a public resolver, which is not allowed by spamhauss, at least not on their free plan.

spanhaus give an error when a public resolver tries to query them:

$ dig 79.106.226.46.xbl.spamhaus.org +short
127.255.255.254

Which means according to https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 "Query via public/open resolver".

The query works when querying their resolver directly:

$ dig 79.106.226.46.xbl.spamhaus.org @$(dig NS xbl.spamhaus.org +short | head -n 1) +norec

(oohh I which dig have an option for this, a bit like '+trace' but not from root...)

which gives NXDOMAIN as I'm hopefully not blacklisted.

This is surprising because it give false positives using rblcheck:

$ rblcheck 46.226.106.79
46.226.106.79 listed by xbl.spamhaus.org
46.226.106.79 listed by pbl.spamhaus.org

[rfc1036]

Currently rblcheck use the machine configured servers, the machine can be configured to hit a public resolver, which is not allowed by spamhauss, at least not on their free plan.

So does the MTA, hence why should rblcheck work differently?

The query works when querying their resolver directly:

Here you are querying the authoritative servers, not a resolver.

And I do not believe that it would be right for rblcheck to directly query authoritative servers since then it would not benefit from caching.

Anyway, doing that would require using some low-level DNS library instead of the libc API.