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

[Michael Tokarev]

Thank you all who replied.  Let me summarize this
thread a bit here...

First of all, this really is a "no-problem", sort
of.  People doing stupid things will always find
a way to do even more stupid things, regardless
of how "smart" the program will be.  For this
reason, no stuff like locking, or lock files,
or whatever, is going to be implemented - not
because it leads to other problems (like stale
lockfiles), but because people who use `cp' to
copy over existing files or who generate the
data directly into the datafile using some shell
(or whatever) script will not use locks anyway
(it's much easier to just write temp file and
rename when done).  No locking or lock files,
period.

There is a real issue, namely, a lack of clean
documentation about this possible problem.  It
is easy to fix I think, and this is what I will
do first ofcourse: to provide examples about how
to create the data files *properly* (by using
temp file and atomic rename).

Next, and this is questionable contr-measure, I'm
thinking about refusing (re)loading a datafile if
it's timestamp differs from `now' for less than
several secounds (5? 10? 1?), but not if the
reload was triggered by SIGHUP.  This should solve
direct `cp' problem - it is, and will be a common
mistake to do, and it's just damn easy to use
`cp * dest/' than to use rename if there are
multiple files, so people WILL use this way
regardless of a risk to get half-copied file
(e.g. cp interrupted, out of disk space, whatever -
there's nothink that can be done with that) -
checking timestamp and requiring it to be
different from "now" will prevent most of
such problems, but will not eliminate the
problem completely (note system clocks may
differ significantly, and sometimes this check
will trigger "falsely" - when source system's
clock and thus file timestamp is greather than
of destination, at some point "in the future"
destination will have the same value of "now"
as the file).  Again, this feature is questionable
(but very easy to implement), and I'm not yet
sure I'll do this.

Next, I will disallow (ignore) last line of
a file if it is incomplete (missing newline).
Should not hurt at all.

Another possible stuff I'm thinking of is to
recognize something like `$MINPREFIXLENGTH n'
in data files, and ignore (with warning) any
entries that violates the rule (and may be even
set it to, say, 16 by default).  The option
will be effective per dataset, first wins,
so one will be able to place his own data
file before any 3rd party files that specifies
the constraint (and other stuff like $NS,
$SOA and whatnot).  This feature should help
to avoid original mistakes (mistyping an
entry) as well.  It isn't quite obvious what
to do with combined dataset in this case,
because the constraint should be global for
the whole dataset, and it is good to be able
to specify more strict rule for some subdataset
(well.. it's easy doable too).

And last, I think I will disallow the stuff like
bare number on a line entirely (which means a /8
listing), requiring at least one dot in an IP
prefix (to mean /16 listing) - /8 listings will
be still possible by specifying the mask.  Also
the stuff like 8/8 or 1-5 will not be accepted
too, but 8.0/8 (no equivalent for 1-5) will.
If someone is using "bare numbers" like this,
it should be easy to change that entries right
now... ;)  But I guess there are very few such
users, if at all.

In short:

  1) documentation, with examples of the right way
  2) disallow (reject) incomplete lines
  3) require timestamp to be different from "now",
     with logging suggesting to stop copying data
     directly (questionable)
  4) disallow bare numbers w/o any dots
  5) $MINPREFIXLENGTH

should do the trick, i think.

/mjt