[rbldnsd] Warning: possible danger of using rbldnsd, and upcoming data format change

[Matthew Sullivan]

David Landgren wrote:

> Michael Tokarev wrote:
>
>> There's one possible problem with using rbldnsd and
>> ip4set dataset type in particular, which may happen
>> due to somehow corrupted input data.  Imagine somehow
>> incorrect data transfer, when the input file is
>> incomplete, for example, original file contains the
>> line
>>
>>  127.0.0.2
>>
>> which list a single IPv4 address, but after a failed
>> transfer, the line shortened to only one digit:
>>
>>  1<EOF>
>>
>> This is valid input for rbldnsd, and it will treat
>> such an input as...  1.0.0.0/8!  Or, if the line
>> was shortened to
>
>
> I appreciate the fact that rbldnsd tries to accept a vast variety of 
> data formats, but isn't this going a bit far? I'll have to re-read the 
> bit about just what is accepted. I'm pretty sure I tend to use 
> abbreviated CIDRs (e.g. 172.17/12). Anyway, just accepting a lone 
> numeric on a line as something useable strikes me as Risk-y.
>
> And I'm thinking that if you are worried about truncated transfers 
> from occuring there are better (read: more lightweight) methods of 
> addressing the problem. The press wires used to signal the end of a 
> wire transfer with
>
> -30-
>
> at the end of a message. I.e. if you don't see an explicit agreed on 
> EOF marker, you consider the file is corrupt and do nothing. The 
> looked for marker could be given as a command line option to rbldnsd.
>
> Otherwise you open yourself up to other data corruption possibilities: 
> like 128.0.0.0/19 being transferred incorrectly as 128.0.0.0/1 so 
> you're still no better off.
>
> Now you've got me worried about this issue. But if that were to happen 
> to me, I'd solve the problem myself by, on the sending side, sending a 
> zone file, and a file containing the computed MD5 checksum, and on the 
> receiving side, checking that the MD5 corresponds to the received 
> file, and only if they match, then moving the zone file over to where 
> rbldnsd picks it up. I could whip up a couple of example shell or perl 
> scripts to bundle with the distribution if you like.
>
> It also nicely sidesteps the backwards compatibility issue of the data 
> formats at the same time :)
>
You could also implement a <zonefile>..LCK file...?!

That would mean no backwards compatability problems.  If it knows about 
the lockfile it works - if it doesn't it doesn't simple...

/ Mat