[rbldnsd] dsbl dump to bind config

furio ercolessi rbldnsd@corpit.ru
Fri, 31 Oct 2003 18:23:18 +0100


On Fri, Oct 31, 2003 at 07:29:11PM +0300, Michael Tokarev wrote:
> furio ercolessi wrote:
> >
> >Not yet, but coming real soon.  
> >SBL mirrors running rbldnsd (with the purpose of answering queries to 
> >the whole world) already exist, but have not been rolled into production 
> >yet due to some minor differences in the CIDR definition semantics
> >which at the moment are introducing slight differences between the
> >bind and the rbldnsd zones.  This is insane and it is being solved.
> 
> Hmm... Furio, any details about this?  What's the difference?

A notation like 192.168.10.8/28 is interpreted to mean
192.168.10.8-192.168.10.23 by the current database->bind zone generator.
In other words, the algorithm is 'list from base address to base
address+offset', where base is always the address appearing in the
listing, and offset is taken from the bitmask.
SBL editors knew that this was the way things worked, and occasionally
(and unfortunately) created listings which rely on this behavior.
For instance, if a spammer had two consecutive IPs like 131 and 132,
a SBL listing ending 131/31 would be created, and the bind zone
would contain 131 and 132.  With true CIDR you need to create two
/32 listings in such a case.

There is no need for anybody to point out that this is silly semantics,
and that 192.168.10.8/28 should mean 192.168.10.0-192.168.10.15:
the 'wrong' records are being chased, corrected and will disappear soon.  
At the end of the process the database->rbldnsd generation will be 
straightforward.  
The database will probably still contain things like 192.168.13.177/24
(meaning "there is a problem at 177 that is causing the whole /24 to be
listed"), but these will be taken care of in the database->rbldnsd zone
generation, so the rbldnsd zone will contain 192.168.13.0/24 and the
-e option will not be required.

I hope this clarifies the matter..

furio