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

[David Landgren]

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 :)

David