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

[Matthew Sullivan]

Michael Tokarev wrote:

> Matthew Sullivan wrote:
>
>> David Landgren wrote:
>
> []
>
>>> 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...
>
>
> What did you mean, Matthew? ;)

I've had 2 ideas...

1/ rbldnsd check for and create a lockfile (similar to the old Serial 
Port lockfiles) - if it's present and locked (exclusive), rbldnsd would 
not open/update the zonefiles.  If the lockfile was present and locked 
for exclusive use, then any update program would be made not to update 
the files.... Of course you could lock the zonefiles themselves for 
exclusive access and lockout things like rsync.

2/ as a temporary measure set the 'check' (-c) time to weeks in advance 
and then use SIGHUP to reload the zones after any update scripts - 
depending on the parameter limits that could be years ahead.

Yours

Mat