rbl-style zones?

Paul Vixie vixie at vix.com
Mon Apr 25 03:23:53 UTC 2005

hello bind workers.  it's been a while, i thought i'd share a conundrum.

we've (isc) received another bug report concerning BIND9's greater use of
memory (compared to BIND8) when loading and serving "rbl" style dns zones.

as some of you know, one non-bind dns implementation ("rbldnsd") treats
rbl-style zones as a different data type, and stores/transfers/loads them
as a sort of a "bitmap".

i don't know if i'd be comfortable with a different kind of AXFR for rbl-
style zones, since IXFR really ought to make these "efficient enough".  but
i have to admit, speaking as a co-founder of MAPS, that a better memory
layout for rbl-style zones would help the world in many ways.

for background, my local unpublished rbl-style zone looks like this.  note
that it's only updated by "nsupdate" so the zone doesn't pretty-print well:


$TTL 3600       ; 1 hour
reject-all.vix.com      IN SOA  ns.lah1.vix.com. hostmaster.vix.com. (
                                2016622328 ; serial
                                3600       ; refresh (1 hour)
                                1800       ; retry (30 minutes)
                                604800     ; expire (1 week)
                                180        ; minimum (3 minutes)
                        NS      ns.lah1.vix.com.
                        NS      ns.sql1.vix.com.
$ORIGIN 10.12.reject-all.vix.com.
$TTL 1800       ; 30 minutes
67.191              A
                    TXT     "reason" "sa.vix.com" "watchmaillog" "mailworm6"
                    TXT     "created" "20041118211920"
88.204              A
                    TXT     "reason" "sa.vix.com" "watchmaillog" "spam043"
                    TXT     "created" "20041215123455"
250.220             A
                    TXT     "reason" "sa.vix.com" "watchmaillog" "spam040"
                    TXT     "created" "20041223073242"


the TXT RRs are just fluff, nothing uses them except sysadmins, who could
be using SQL to store this stuff.  most RBL's have a template TXT RR that's
the same for all nodes, or even no TXT RRs at all (mostly to save space).
so there are some alternatives in an rbl-zone storage design: (1) don't
allow TXT RRs if this optimization is desired; (2) allow a template to be
specified, sprintf-style, for answers to TXT queries where an associated
"A" queries would succeed (this is controversial, rr-specific synthesis),
or (3) assume that the greatest memory use is in the zone's node tree and
just store TXT RRs if they are present.  for now i'll assuming (1) since
most rbl-style zones in the world today don't use anything but a single
A RR (to save space), and that strikes me as an excellent opportunity.

dave rand (the other co-founder of MAPS) and i have discussed this a few
times over the years, and the obvious internal design is a 64K array of
"class B"'s, each pointing to a 64K array of "A records".  this would be
a disaster if every /16 had one /32 in it, and may call out
for more of a tiered-by-octet array of pointers to arrays of pointers to
arrays to pointers to addresses.  (that way it would take a /32 in every
/24 to reach maximum memory pain.)

imagine a zone option like "subtype rbl;" to indicate that this is an RBL
zone and that there can be no TXT or other non-A RRs other than at the apex.

my questions are:

1. is this simplistic storage method too simplistic?

2. is there demand in the BIND community for this feature?

3. can we really do away with TXT RRs here and still have this
   be a relevant feature in the RBL community, or would we need
   to synthesize them from a template?



More information about the bind-workers mailing list