[rbldnsd] Migrating From Aggregate to Combined

[Michael Tokarev]

David Cary Hart wrote:
> (From the "wish I had dunnit different" department)
> 
> Can I overlay an aggregate zone without breaking anything? In other
> words, can I do something like this:
> 
> #Current:
>      RBLDNSD="dsbl -f -c10m -r/var/lib/rbldnsd -s+stats -b127.0.0.1 \
>      spam.tqmcube.com:ip4set:spam \
>      dhcp.tqmcube.com:ip4set:dhcp \
>      prc.tqmcube.com:ip4set:prc \
>      ko.tqmcube.com:ip4set:ko \
> #Eliminate:
>      dnsbl.tqmcube.com:ip4set:spam,dhcp,prc,ko \ 
> 
> #New:
>      spam.dnsbl.tqmcube.com:ip4set:spam \
>      dhcp.dnsbl.tqmcube.com:ip4set:dhcp \
>      prc.dnsbl.tqmcube.com:ip4set:prc \
>      ko.dnsbl.tqmcube.com:ip4set:ko \
>      dnsbl.tqmcube.com:combined:dataset_map \
> 
> "
> The objective is to allow the use of the old zones for a period of
> time. People now using the aggregate zone will transparently use the
> combined zone.

I'm not sure I understand your question.

With your "New" setup, it will work exactly as before, provided
that your dataset_map includes all the "subsets" internally, and
except that your new dataset_map may defines additional subzones.

But with this setup, queries for, say, prc.dnsbbl.. will be answered
by ip4set:prc, not the new combined map, as more specific one.  Even
if the combined map defines 'prc' subzone.  Think of it as a bug if
you wish ;) -- the "megazone" combined dataset will not be consulted.

What probably you want is to just switch to combined dataset completely
(if it's what you really want - see below).  And in that dataset, specify
all the data you already have in separate files, and define all your
current subzones.  Like this:

$DATASET ip4set spam @
1.2.3.4 spammer
...
$DATASET ip4set dhcp @
2.3.4.5 dhcp
...
and so on.

Just remove everything and only specify this single dataset.  You can
keep the subzones forever - for free.  You can specify multiple files
for this combined dataset, too.

Switching for combined dataset like this has its advantages and disadvantages.
One advantage is easier maintenance of secondaries - no need to do anything
if you define new subzones or remove old ones, just single config line which
tells everything.  The disadvantages are, at least:
 o rbldnsd has to reload everything - even (sub)zones which aren't changed
   frequently like, probably, dhcp.
 o ditto, you will have to regenerate the whole (huge) file with every update.
 o rbldnsd will be a bit slower processing queries

Note also that if you plan this switch, plan it carefully.  All the secondaries
will have to switch all together, or else metadata will be inconsistent and
DNS clients will be confused.  It's because SOA and NS records will always
refer to the "megazone", not to individual subzones; and if some NSes are
using old setup, and some are new, for the subzones (like spam, dhcp etc),
old nameservers will refer to subzones (spam.dnsbl..) while new ones will
refer to the megazone (dnsbl...).  You'll have quite some SERVFAILs and
warnings in clients logs during transition period.

/mjt