Providers like Linode assign a single IPv6 address from a /64. I had to
request my own block of /64 to use on my server as my IP neighbors were
always getting the /64 blocked... since I've had my own I've been all
good. Before this my IPv6 IP was getting blocked daily because of
someone else on that /64. It was quite annoying for myself.
ps your server blocks .nz domains :P
On 03/03/2018 00:54, Daniele Duca wrote:
apologies if this is not directly SA related. "Lately" I've started to
notice that some (not saying names) VPS providers, when offering v6
connectivity, sometimes tends to not follow the best practice of
giving a /64 to their customer, routing to them much smaller v6
subnets, while still giving to them the usual /30 or /29 v4 subnets.
What It's happening is that whenever a spammer buys a VPS with those
providers and get blacklisted, most of the time the dnsbls list the
whole v6 /64, while still listing only the single ipv4 address. This
makes some senses, as it would be enormously resource intensive to
track each of the 18,446,744,073,709,551,616 addresses in the /64, but
unfortunately not respecting basic v6 subnetting rules causes
reputation problems also for the other customers that have the bad
luck of living in the same /64 and are using their VPS as an outgoing
While I'm not judging the reasons why VPS providers are doing this
type of useless v6 subnetting (micronetting?), I've started to deploy
some countermeasures to avoid FPs. Specifically I wrote a rule that
identifies if the last untrusted relay is a v6 address, and then is
subsequently used in other meta rules that subtract some points in
dnsbl tests that check the -lastexternal ip address on v6-aware lists.
I know that probably is not the best solution, but I've started to see
real FPs that worried me. I've even pondered if it could have sense to
go back to v4 only connectivity for my inbound mtas.
If you are in a similar situation I would like very much to discuss
what would be the best approach to balance spam detection while