On Sun, 1 Jun 2025, John Curran wrote:
Thanks, John – while cast in DNS-based lists, the RFC definitely includes quite
a bit of best practice about blocklist
management in general.
You make an excellent point about the difficulty of running a useful blocklist;
unlike some other areas of Internet
infrastructure (e.g., routing with routing table entries, route objects, etc.
as visible artifacts), it’s nowhere near
as evident whether a blocklist is behaving appropriately – the list and/or
individual entries may be visible,
but the information feeds that drive such listings are far more opaque.
It's a problem we've been thinking about for literal decades. The bad
guys can read anything that's public, and I can assure you that if there
were a spec that said we'll block anything that's more than 5% bad
traffic, they'd figure out how to send 4.9999% bad traffic and then bulk
up the denominator with traffic that is useless but doesn't provoke
complaints. So the rules have to be opaque.
There are hundreds of blocklists, viz. the list at multirbl.valli.org but
in practice there's only a handful that are widely used. Spamhaus is
clearly the leader, then perhaps Trend Micro which is the descendent of
Vixie's MAPS RBL. Spamhaus' lists are mostly intended for mail and
similar messaging but they do have DROP, Don't Route Or Peer, which is a
list of networks from which they suggest you accept no traffic at all.
DROP is very conservatively managed, never had reason to think it blocked
traffic I want.
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/[email protected]/message/WCMWZUQCHQ2SPIYC2XY3VXXCLOLSNV34/
