[rbldnsd] ip6tset and the RFC5782 test IPv6 don't like each other

[Alex Lasoriti]

On Thu, Oct 10, 2013 at 07:37:05AM -0700, Jeff Dairiki wrote:
> On Thu, Oct 10, 2013 at 10:01:33AM +0200, Alex Lasoriti wrote:
> > On Wed, Oct 09, 2013 at 05:52:49PM -0700, Jeff Dairiki wrote:
> > > On Thu, Oct 10, 2013 at 12:21:45AM +0200, Alex Lasoriti wrote:
> > > 
> > > Out of curiousity, how many /64 prefixes do you have?  
> > 
> > Well, the data generation guys at the Project are still working on the 
> > engines and I do not have real data yet.  I am preparing things at the
> > user delivery end.  But IPv4 XBL is on the multimillion scale (around
> > 6M now), so I guess one should be reasoning on that scale.
> > 
> > The automated CSS (snowshoe) component of SBL may explode even more, as
> > snowshoe spammers getting /40's or so may suddenly start emitting from 
> > the whole space, and you have 16M /64's in a /40, so there is a
> > potential for spikes in size until these areas are consolidated in 
> > larger SBL listings.
> 
> Maybe I'm misunderstanding something, but if you have plans to
> consolidate /64s to /40s, that seems like a strong argument for using
> ip6trie.

The SBL has two parts, one maintained manually with arbitrary CIDR
size that will run on ip6trie, and one (called CSS) automated with
/64 listings that will run on ip6tset.  Two datasets into one zone
(not counting the IPv4 datasets!).

> > > [...]
> > > 5) I haven't tested this, and it's pretty hackish (apologies for both)
> > >    but ip6tset supports /128 exclusions.  So you could list 0:: (which
> > >    includes ::FFFF:7F00:2 among many others) and then exclude
> > >    ::FFFF:7F00:1.  That would give you a whole bunch of test addresses
> > >    — perhaps too many — but it would appear to conform to RFC5782.
> > 
> > That's an interesting workaround, but listing 0:: could have unforeseen
> > consequences.  A lot of mor^H^H^Hpeople complain that we block their IP 
> > 127.0.0.2, if we were listing 127/8 except localhost there could be
> > a flow of silly mails and in general disservices of some sort that
> > we want to avoid, and the same could happen in v6.
> 
> You're right.  Listing the entire ipv4-mapped-ipv6-address space is
> probably not a wise choice.
> 
> I'm not sure why this didn't occur to me sooner but:
> 
> 6) Rbldnsd supports configuration of multiple datasets at the same
>    origin.  I believe that they are checked in the order that they are
>    configured; subsequent datasets are checked only if no record was
>    found in the previous one(s).  So you can configure both an ip6tset
>    (with the real data) and a ip6trie dataset (with the test address(es))
>    at the same origin.  (I've tested this and it does work.)
> 
>    (Additionally, if you want to list all the data in a single file,
>    you can used the 'combined' dataset type to do that.)

Yes, a dataset for the test address, this indeed seems to be the most
practical solution. I will try this. Thanks!

Alex