[rbldnsd] Excluding a CIDR range

[Chris Gabe]

On Dec 1, 2005, at 6:56 PM, Matthew Sullivan wrote:

> furio ercolessi wrote:
>
>> On Fri, Dec 02, 2005 at 10:15:33AM +1100, Matthew Sullivan wrote:
>>
>> Superexclude should not replace the current exclude, so it should
>> be notated differently.  Let us temporarily indicate it with !!
>>
> Agreed.
>
>>> At this point remember that everyone has their own zone format,  
>>> eg SORBS will create the zones with includes first and excludes  
>>> afterwards.  Also what do you do if you see:
>>>
>>> 1/8
>>> !1.2/16
>>> 1.2.3/24
>>>
>>> Personally I would expect, to exclude 1.2/16 from 1/8 but include  
>>> 1.2.3/24 specifically....
>>
>> I agree (this is what it does, right?), but
>>
> IIRC no because of the net boundaries in the internal structures  
> 1/8 would be listed.  (Michael correct me if I'm wrong please ;-))

Well, I tried the above and found that 1.2.2.2 is excluded and  
1.2.3.4 is included.

However, I think Matthew is right there are issues with the /8/16/24  
boundaries.  My issue is even simpler case
	1.2.3.4
	!1.2.3/24
Then 1.2.3.4 is included, and I wouldn't want that.  So, my ISP that  
uses mail-abuse that lists DULs can't exclude his own DULs by CIDRs.


>> 1/8
>> !!1.2/16
>> 1.2.3/24
>>
>> should not list 1.2.3/24, because !!1.2/16 wins -- it is a  
>> superexclude.
>>
> If you have super exclude yes.

Well, yes, the !! is a cleaner and more general concept but it's  
going down a path of logical debate which isn't the problem I really  
worried about.  The above /24 example is.  What I believe I need is  
"I don't care what came before, or what would have come after, we're  
done, this is not a match, stop".  (*)
So, from an implementation point of view, if there were something  
that just checked every match for a particular result, one single  
comparison to a hard and fast ip, say 0.255.9.9, so that
	:0.255.9.9:excludeme
	x.y.z/whatever
would always stop processing the moment it hit something matching  
x.y.z/whatever.  It ought to be easy to implement, as it uses the  
include detection mechanism (which is always without question going  
to work) and has a single 4 byte word comparison I would think on  
each match detected.

(*) Maybe it's not that simple, maybe I don't want that.  But it  
seems to be the case.  For example, ISP uses mail-abuse.org that  
lists DULs.  ISP customers are DULs.  Wants to allow them through in  
spite of being listed on mail-abuse, even if they have other worse  
issues than being DULs.  I suppose the next request they will have is  
"let my own DULs through if that (DUL) is the only reason they are  
listed".  But given that mail-abuse doesn't distinguish the reasons  
necessarily, that seems impossible.

I hope I'm making some sense, it's not imperative that any of this is  
the way to solve the problem.  Obviously the MTA can provide other  
mechanisms to avoid the RBL check entirely... We'll do that in the  
long run.  We are actually the vendor of the MTA software in this  
case, as well as the rbldnsd, but one can't necessarily change such  
commercial software in a flash.

>>> seems a reasonable request, but how about if we do this:
>>>
>>> 1/8
>>> 1.2.3/24
>>> !1.2/16
>>>
>>> Would this be handled differently?
>>>
>>
>> I would not expect the result depend on the order under any  
>> circumstance.
>>
> Good, nor I.
>
> _______________________________________________
> rbldnsd mailing list
> rbldnsd at corpit.ru
> http://www.corpit.ru/mailman/listinfo/rbldnsd

________________________________________________________________________
Chris Gabe                                     Manager, Borderware  
Security Network
Phone: 905-804-1855 x283                        Fax:   905-804-1865
Borderware Technologies Inc.                   http://www.borderware.com