[rbldnsd] PATCH: clearing sqi in rbldnsd_combined.c

Alex Lasoriti lasoriti at spamteq.com
Thu Oct 15 21:20:51 MSK 2015


On Wed, Oct 14, 2015 at 10:43:01PM +0300, Michael Tokarev wrote:
> 12.10.2015 03:14, Alex Lasoriti write:
> > Hello rbldnsders,
> 
> Hello!
> 
> > we have found what appears to be a bug in 0.997a.
> [snip]
> But the problem is elsewhere.  Lemme try to address the real one,
> hopefully I still can remember how the code works :)

We are pondering about your message.

> BTW, Alex, you still haven't replied to my last question in the
> previous thread, about second form of IPv4-in-IPv6 addresses.
> Is it okay to cut off the remaining /48 from it, is it not a
> useful info?

I thought http://www.corpit.ru/pipermail/rbldnsd/2015q2/001256.html
was a "yeah, go ahead!" :)  But you are right, I did not
specifically answer the last question.  So here we go:

If there are two 6to4 addresses with the same initial 48
bits and differing in the remaining 80 bits, those are probably
different LANs or interfaces within the same installation 
which are mapped on the same IPv4.  If that IPv4 is blocklisted,
then all the 2^80 IPv6 addresses that map into it should be blocklisted 
as well, so this could already be a good reason to neglect those bits.

But I have never seen a case like this in the real world.  In the 
overwhelming majority of cases [*] the 6to4 address is a fixed one
and it has the structure
			2002:(v4ADDR)::(v4ADDR)
that is with the (v4ADDR) repeated at the bottom, and
48 bits that are always 0 in the :: middle.  So the additional
information contained in the lower 80 bits is exactly zero
in these cases.

Alex


[*] 84.4% according to the RIPE Labs measurements reported in
    https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really



More information about the rbldnsd mailing list