[rbldnsd] /32 listings and exclusions on ip4trie -> possible troubles

[Michael Tokarev]

furio ercolessi wrote:
> If a dataset contains a /32 listing and also an exclusion for that IP,
> then using ip4trie for that dataset may lead to troubles.
> The IP will appear listed if the /32 listing comes first in the
> file, or unlisted if the exclusion comes first.  The record that
> comes first takes the slot, and the other is tossed away.
> This behavior may lead to unintended results.

In fact this is the same for a listing of any size.  ip4trie,
unlike ip4set for example, can only hold one "value" for every
possible entry, the same listing can't have multiple "values",
due to internal structures used and a tradeoff - flexibility
vs effectiveness.  It's easy to add support for multiple values
per entry, at a cost of additional pointer for each (while for
ip4set it's costless), and I hope that it's a reasonable
tradeoff... ;)

> I think this is OK once people are fully aware of this, but perhaps
> the documentation should stress this point.
> Or perhaps the code can be fixed by giving priority to the exclusion
> (that is, if the slot for the IP is occupied by a listing and an
> exclusion appears, the exclusion could be put in place of the listing),
> but I do not know if such behavior would break other things.

I don't think such a change will break something, at least not
significanty.

The thing is - rbldnsd warns about any duplicates (be it exclusions
or something else), on every dataset reload.  So unless one does
not care at all, any dups should be fixed by now already... ;)

Speaking of treating exclusions with higher priority - it seems
that "first come and took the place" is - almost - a consistent
behavour now in rbldnsd.  Exception is ip4set, which can hold
multiple entries for any given IP address (range), and exclusions
are sorted first -- it's a set after all, not an ordered sequence... ;)

First version(s) were quite inconsistent in this matter - for
example, it wasn't possible to change a set of nameservers for a
zone, only add to the list; TTL values were handled inconsistently,
and so on.  At some time I realized the inconsistencies, and tried
to fix them all without adding too much trouble - and I think I
fixed them all, at least a reasonable subset ("set" again ;)...

Well ok.  I'll review the docs, -- not only ip4trie, but the whole
thing - to check if it all matches each other.

But first I'd want to ask - whenever current behavour of ip4trie
(out of context - (in)consistency etc) is really problematic.  May
be unexpected if one is used to ip4set - that's for sure, but is
it problematic?  (Note the warning produced by rbldnsd, too)

Thanks.

/mjt