[rbldnsd] Option -d (Bind dump) and wildcards: a small problem

[Michael Tokarev]

Amos Jeffries wrote:
[]
>>> The only potential problem I can see is if there is a /16 exclusion 
>>> and a few /32 listed inside it.
>>> The /32 will appear as listed, the /16 itself and all implicit /24 
>>> below get ignored nicely.
>>
>> What's a problem in that?
>>
> 
> I thought maybe some people might want _all_ IPs inside an exclusion to 
> be excluded.

Well, this is an old question which still don't have a reasonable answer.
For some, any exclusion is just that - exclusion, and should be treated
as such, even when there are smaller listings exists.  For others,
"smaller range wins".  Both approaches have their own usages, but
currently there's only one type of exclusion, which can't be used
for both approaches at the same time, obviously.  Ok, I understand
that first way - exclusion always wins - is more practical, while
I was thinking differently initially.

In case of ip4set, the most used type, implementing exclusions this
way means more time for lookups or for (re)loads, as rbldnsd will
need to process all larger arrays too (it may be done during reload,
by removing entries in eg /32 array which are covered by an exclusion
in /24 or greather -- seems not that much work..)  How about this case,
anyone -- about turning exclusions into always-winning beasts?  No,
I'm not talking here about a "super-exclusion" entries, where an
exclusion works across several datasets composing the same zone --
this is a very different case.

In any way, current ip4set implements sort of 2nd approach
(smaller entry wins) when handling queries, so master-format
dump should be at least consistent.  And if the change in
semantics will be made, current code will still just work
anyway, and it will be possible to make it a bit cleaner
too, by removing several cases.

[]
>> Got it.  Care to explain how it works? ;)
>> Funny enouth, I can't seem to understand it.
> 
> 
> Um, lets see.

Heh, too late... I saw this your email after sending out mine ;)

[good explanation]

Yeah, sort of like that.  Interesting way.
After reading the code several times, I still feel it does
something incorrectly, but I can't say what exactly.  Maybe
I just haven't "used" to it, -- some +/-1 error, or referencing
one element past or before an array...  It looks like it works
for simple cases, and I can't definitely say whenever it is
correct or not, I just don't see it.  What a bastard I am, eh? ;)
I'll try to look at it -- hopefully -- again tomorrow (it's a deep
night here now already... ;)

/mjt