[rbldnsd] To be or not to be ;-)

[Michael Tokarev]

Manfred Hielder wrote:
> Hi List,
> 
> in Zone format on the web page there is an information that ! Lines
> will read as excluded ones.
> Can you give my any suggesetions how this could be used for unset IP's
> they were set before.
> 
> eg.
> 
> A Masterzone - updated every hour - knows an ip (T.H.E.IP)
> Now the IP expires because of whatever. So an small updatezonefile is
> used for letting rbldns know this.
> 
> I tried to use a !T.H.E.IP Line in the small update file but it seams
> to be ignored.

Some more details are needed.

It seems (I'm only guessing) that you're confusing zones and datasets
here.  An exclusion entry works within a single dataset.  Several
datasets can be combined to form a single zone.

In order for exclusions to work, this has to be done (for example):

  foo.example.org:ip4set:maindata,exclusions

Where the file `maindata' obviously holds the "main" data, and the
file `exclusions' holds excluded entries.

But note that this way, even if `exclusions' file is rather small,
rbldnsd will reload the whole set of files, including (large)
`maindata' file.  So I'm unsure it's worth the effort to try to
minimize update time this way - unless re-generating the `maindata'
file itself takes significant time (disk (re)writes etc).

Combining two datasets into single zone can be used for fast
additions, not fast removals.  For example, dsbl.org uses this
mechanism to avoid frequent re-reads and transfers of large datafile:

 rbldnsd ... \
   list.dsbl.org:ip4tset:rbldns-list.dsbl.org \
   list.dsbl.org:ip4tset:rbldns-fresh-list.dsbl.org \
   ...

The former file (list) is very large (currently near
13M records, 176Mb), while the latter, fresh- one, is very
small.  "list" gets updated every hour (if memory serves
me right), and at the same time "fresh-list" is emptied.
Between two updates of "list", "fresh-list" is updated
every one or two minutes, and holds only recent additions.
All removals done during last hour will be visible when
main "list" file is updated, not before -- that's why DSBL
states that "your IP will be removed within 24..25 hours"
(24 hours forced waiting period plus 0..1 hour for the
update to actually take effect and propagate to all the
nameservers).

Again, this technique can not be used for fast removals -
full reload is still necessary (but still not full file
transfer/rewrite, as noted above).

/mjt