[rbldnsd] IPv6 implementation thoughts

[TreeNet Admin]

On 26/03/2012 8:36 a.m., Alexander Maassen wrote:
> Sigh, yes, again :P
>
> Ok, I know there is a discussion going on, but the last thing I've seen
> about it was like a few ages ago. From what I remember the discussion
> was more like about what minimum range to support (/128 vs /64 etc).
>
> My opinion about this is: /128. Why? Very simple, not everyone assigns a
> block to a client (yes, most tunnel providers do, some do /64,
> others /56, others /48 etc etc).

The vast majority of home LAN where spam bots and the like dig in have a 
mandatory /64 allocation.

>
> However, blocking an entire /64 due to ONE faulty machine in that range
> is quite confusing towards the blocked party trying to SOLVE the issue
> (it's not only about blocking, but the blocked party surely needs a
> simple hint where the issue originates from). If there are people
> evading the rbl entry then it's up to the dnsbl system in question to
> decide whether to block the entire /64 or not depending on the amount of
> hits within that range. This is not something rbldnsd should decide in
> my opinion.

To put this in perspective:  Last time I heard this same argument it was 
from a spam-friendly ISP arguing against being blocked at the /26 level.

As an argument for /128 as minimum entry I agree with you on this. As an 
argument for RBL not doing /64 by default its questionable.
  /64 is the IPv6 equivalent of /32 in IPv4. Today we can block a /32 
and be relatively sure we stopped most of its output, same with a /64. 
Not so much with a /65 or less.

Equivalently: Should we extend DNSBL to block at the per-port level just 
in case it is a server with legitimate services on some ports? what if 
it was a server running virtual machines and shared global IP with 
blocks of ports assigned each VM by NAT? That is a real problem today 
with IPv4 DNSBL.

The hint you mention comes in the form of the TXT record associated with 
a block entry, and the list documentation. Same as always. You don't 
block a IPv4 /32 without evidence do you?


As a side issue:
  You seem to still have the IPv4-centric view that each machine has one 
IP address assigned. This is false. IPv6-enabled machines have at least 
2 routable *prefixes* assigned at all times. DHCP walled gardens simply 
increases that to a minimum of 3 routable prefixes. It used to be 1 
minimum globally routable, then people insisted on creating NAT66 so 
they could route traffic from the previously secure subnets into global 
space :(

Several OS distributions have also chosen to implement the so-called 
"privacy" addressing algorithm _by default_. Their end-user machines 
require a minimum /64 and bounce around within it randomly changing 
their IP every 10-90 minutes. Unfortunately these are also the user 
machines, most likely to be infected with spam bots and relay malware 
from everyday use. Blocking the whole /64 on sight is the *only* way to 
block spam by IP from networks where these machines exist.

IMHO its also better to block the /64 as one event and call it one 
offense, than to let these individuals perform N deliveries and call it 
N offenses. When linked to reputation or scoring systems as is common 
practice, the reputation damage a single "privacy address" machine can 
generate for the network is way out of proportion to the scale of the 
actual problem.


>
> Another issue I remember being discussed is how to support the lookups.
> Simple answer in my opinion: ip6.arpa style, with ip6.arpa being
> replaced by the zone provided. It's being done for IPv4 this way, so do
> it for IPv6 as well, no shortcuts. I think even MTA's like exim (at
> least in my case) do lookups this way. IRC services I know about (which
> heavily use various dnsbl's) also do it that way.
>
> Just my 2 cents,
>
> Alexander Maassen
> DroneBL Maintainer
>
>
> _______________________________________________
> rbldnsd mailing list
> rbldnsd at corpit.ru
> http://www.corpit.ru/mailman/listinfo/rbldnsd