[rbldnsd] ipv6 support: beginnings of an ip6trie dataset

[Michael Tokarev]

[Sending to the mailing list, hope it's okay]

28.06.2013 19:33, Jeff Dairiki wrote:
> Hi Michael,
> 
> I hope things are going well with you and that you're not too busy.

Yes it's okay.  Thank you!

> Alexander Maassen has filed a couple of tickets (with patches) for
> rbldnsd on my github repository.  Personally, I don't think either
> ticket has a lot of merit, but I thought I should point you at them
> in case you have strong feelings about them:
> 
>   https://github.com/dairiki/rbldnsd/issues/1
>   https://github.com/dairiki/rbldnsd/issues/2

I think both of these are sort of wrong (and as you pointed out,
filed in a wrong place).

First, the maxrange (issue1).  It was supposed to limit mistakes of
occasional over-listings.  For example, you made a typo and instead
of 10.0.0.0/24 you specify 10.0.0.0/4.  You don't normally expect
to specify listings this large, so specifying `$MAXRANGE4 /24' --
to allow maximum of 256 IPs listed in one go -- will save you from
a disaster.  (For really large listings you may use a separate file
which you edit with much great care).

The same can be done for IPv6 too ofcourse, and actually it is an
omission and should be implemented.  But the patch linked to from
issue1 is at least incomplete, -- it uses dsc_ip6maxrange, but never
sets it.  And it produces wrong diagnostic message when the range
listed is larger than the specified maximum.

So the approach is right, that is, we really should fix this issue,
but the implementation is wrong.


Speaking of issue2, I strongly disagree.  There's no point in listing
specific /128 entries if you use rbldnsd in spam-prevention systems
(as it has been designed for).  Every customer has whole /64 range
so in case one of those addresses will be listed, it is trivial to
move on to the next address and not bother about fixing the problem
or request delisting.  More, some OSes will use another address on
every boot, so you may not even notice a listing to begin with.
This way we opening a huge door to abuse of the resources - if we
start listing every new /128 from the same /64, we'll quickly run
out of everything.

This has been mentioned before numerous times.  The only sane minimum
range for a listing is /64.  It is possible to specify particular
/128 for a WHITElist, say, to allow a single mailserver in this /64
range, but that's about it.

By turning ip6tset from listing /64s to listing /128s we effectively
making it completely useless.

I'd say it isn't a good idea to list /128s in other ip6* datasets too,
and maybe this should be mentioned in the manpage (together with the
above explanation).


Thank you for bringing those to me!

/mjt