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

[Amos Jeffries]

----- Original Message ----- 
From: "Michael Tokarev" <mjt at tls.msk.ru>
To: <rbldnsd at corpit.ru>
Sent: Monday, December 13, 2004 3:38 PM
Subject: Re: [rbldnsd] Option -d (Bind dump) and wildcards: a small problem


> 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... ;)
>

Even having worked out the reasons, I still get that feeling.
Its those for-loops and cache isn't it?
_Every_ time I go to explain it, I think. 'Thats irrelevant isn't it?'
then as I'm re-coding remember an obscure case that only makes sense when 
looking at it sideways.

AYJ