[rbldnsd] The round-robin problem

Michael Tokarev rbldnsd@corpit.ru
Mon, 17 Nov 2003 04:39:22 +0300


furio ercolessi wrote:
> I noticed that rbldnsd (0.99) does not seem to do round robin rotation
> of A records.  This can be a problem with zones that have the A
> records of the nameservers within the zone itself, as it leads to
> unbalancing.

Hmm.. not only it leads to unbalancing.  By using nameservers in the
same zone as data, you just breaks things, since end result will be
that other nameservers will not be able to access the zone data since
they will not be able to find nameservers, due to chicken&eggs problem.
The issue is that rbldnsd does not fills additional section where the
"glue" records for nameservers are located.  I mean this one:

;; QUESTION SECTION
;hobbit.corpit.ru.                 IN      A

;; ANSWER SECTION:
hobbit.corpit.ru.       172800  IN      A       217.23.134.194

;; AUTHORITY SECTION:
corpit.ru.              172800  IN      NS      ns.corpit.ru.
corpit.ru.              172800  IN      NS      dirserv.rgs-podm.ru.
corpit.ru.              172800  IN      NS      ns2.caravan.ru.

;; ADDITIONAL SECTION:
ns.corpit.ru.           172800  IN      A       217.23.134.194
dirserv.rgs-podm.ru.    172800  IN      A       217.23.130.214

Last section provides glue A records for the NS records if known
by the nameserver.  This glue record is MANDATORY if the NS is
inside the zone being queried, or else we have chicken & eggs
problem: we have to resolve ns.corpit.ru, so we need to have
list of nameservers for corpit.ru, but for this to be possible
we need to have a list of nameservers for corpit.ru...

In short: rbldnsd currently CAN NOT be used as a complete nameserver
for a given zone.  Namely, nameservers should be inside another,
maybe upper-level, zone.  E.g.

list.dsbl.org name server is X.ns.dsbl.org
relays.ordb.org name server X.ns.ordb.org
cbl.abuseat.org name server ns1-cbl.abuseat.org
dnsbl.sorbs.net name server rbldns0.sorbs.net

and so on.

Usually, the zone holding the "meta-information" like NSes,
plus stuff like www., MX etc, is very small and static.
I recommend to use other nameservers for this zone, like e.g.
BIND, which has a benefit of automatic data distribution
methanism (NSNOTIFY/AXFR, which are good for small data).

Also, you're missing the point here.  The list of nameservers
(NS records) returned by rbldnsd are being rotated (not
randomized but rotated).  *This* is what is needed for the
round-robin dns to work.  Mind you, if you have one NS record
that resolves to multiple A records, most BIND servers will pick
random A - *one* and treat it as if it was only one (ie, if this
A will not work, BIND will NOT try other As, but it will try other
NSes if any).

> For instance (w.spamhaus.org is an experimental SBL server running
> rbldnsd, soon to become public):
> 
> % dig a afr.sbl.spamhaus.org @w.spamhaus.org
> afr.sbl.spamhaus.org.   2D IN A         147.102.222.210
> afr.sbl.spamhaus.org.   2D IN A         217.160.72.252
> afr.sbl.spamhaus.org.   2D IN A         204.152.184.189
> afr.sbl.spamhaus.org.   2D IN A         160.124.208.81

Well, this is something different.  I'm thinking about "glue"
records only for now.  Ie, to have an ability to rotate
records in ADDITIONAL section of the answer, not to rotate
several RRs in reply to A query... well, *this* may be a bit
more difficult, it means digging into "generic" dataset, and
integrating it more deeply into the core packet processing.
Certainly not this year.

This "issue" (unability to act as a complete nameserver) is
known one, and I've several requests to address this. It isn't
difficult to do, the same way as done with NS records (by
"pre-computing", or "pre-compiling" some templates containing
future replies).  Maybe I'll do that this year.  Still, I
don't recommend to go this way at all.

[]
> (Actually for public servers it would be very nice to be able to give 
> weights to the nameservers, in order to alleviate bandwidth problems
> that some volunteers may experience by redistributing the traffic).

Hmm.. that is, to place certain NSes on the top less frequently than
others?  Interesting...

/mjt