[rbldnsd] Re: rbldnsd-related inquiry

[Michael Tokarev]

This is becoming a FAQ, so i'm CC'ing rbldnsd@ list,
and hopefully will add something to documentation too.

Jan Rafaj wrote:
> Mr. Tokarev,
> 
> First, please excuse me for bothering you with this my problem - I've
> finally made bold to ask you about my problem, since I'm totally clueless
> of how to solve it.
> 
> Here are the basic facts about my environment:
> I use a server where I'd like to deploy rbldnsd. The machine is a
> dedicated Linux server that is running ISC BIND already in a role
> of primary/secondary zone source. It also runs antivirus/antispam
> gateway backed with sendmail as an MTA.
> 
> Now, I'd like to switch away from using BIND to store the Easynet's
> 'dynablock' zone, to RBLDNSD, for many good reasons.
> However, since I need to run the rbldnsd on abovementioned machine,
> which is _already_ running ISC BIND, and I can not move BIND nor RBLDNSD
> to a different machine, I'd like to know how would I force sendmail
> to ask (through its 'dnsbl' FEATURE macro) the rbldnsd running
> on different port [or if there are other solutions how to circumvent
> this issue].
> I know that rbldnsd is capable to listen on a different than
> IANA-assigned port through '-b'.
> I simply can not bind the RBLDNSD nor ISC BIND to the same listening
> port (this is a nonsense of course).
> 
> I have direct answer from Sendmail Inc. that it is quite unlikely
> they would support port-selection for their 'dnsbl' feature,
> so I can not simply count on fact that they'd implement it anytime
> soon.

Sendmail uses standard resolver library, which, in turn, uses
/etc/resolv.conf.  You may only have recursive nameserver listed
there, or else many other things will not work.

> I have idea about using 'forward' type zones in ISC BIND to forward
> queries for these to rbldnsd for resolving, but again, 'forwarders'
> in BIND do not allow to specify ports for rbl-DNS servers to be asked...
> :(

Ok.
By default, NAMED will listen on ALL IP addresses bound to the
host.  There's listen-on directive to explicitly tell it which
addresses it should listen on.  Basically, you may use on of
IP addresses available to you for rbldnsd, and another (or
several) for NAMED.  The same port, but on different IPs.  This
is how such setup will work.

Now, where to find the necessary (extra) address?  This depends
on whenever you want your *rbldnsd* available from other machines
directly (especially from the "outside" world) or not.

For local usage, you may always set up extra IP on loopback interface,
e.g. 127.0.0.2 or any in 127.0.0.0/8 range.  For example, linux
requires nothing to do so - you may bind to any 127/8 address
directly without any additional setup, just specify -b 127.0.0.2
(or whatever).  Other operating system may require special setup,
e.g. Solaris requires you to set up an "alias" for loopback iface,
something like
   ifconfig lo0:1 inet 127.0.0.2 netmask 255.0.0.0 up
(sorry i don't remember exact syntax).  After such extra address
is set up, you may use it for rbldnsd.

Now, you either set up "forward" type zone in your named.conf,
e.g.
   zone "dynablock.easynet.nl" {
     type forward; forwarders { 127.0.0.2; };
   };
or, maybe better, set up a subdomain in your own local domain
example.com - e.g. bl.example.com, to hold dynablock.bl.example.com,
dsbl.bl.example.com etc, by adding an NS record into your example.com
zone for bl.example.com:
   blns.example.com.  A 127.0.0.2
   bl.example.com.    NS blns.example.com.
See how bl.corpit.ru and dsbl-list.bl.corpit.ru are set up for
a live example of this.

Now the interesting detail.  If you use your BIND as a caching
resolver for several machines, either forward zone or the subdelegation
will be sufficient for all your network, even if rbldnsd will be
bound to loopback address: BIND will receive queries, consult
rbldnsd, and will send complete reply to the client.  So, this
way, you're not really limited to the local queries (originated
from the same machine where rbldnsd is running), the whole your
network may use rbldnsd indirectly via bind this way.  Note that
BIND will cache results, so it may be a good idea to setup
relatively small TTL values in rbldnsd datafiles.

But if you want to be able to query your rbldnsd *directly*
from another machine, you have to set up additional IP address
which will be accessible from that another machine.  It may
be local network with private addresses (192.168.x or 10.x.x.x
etc), and in this case this is easy, since you always will
be able to assign another address from this range to your host.

If you want to query your rbldnsd from the "outside network",
you will need additional real, or routable, address for this.
Again, this is how bl.corpit.ru is set up: our main nameserver
is at one IP address (ns.corpit.ru aka 217.23.134.194), and
rbldnsd is at another:

corpit.ru.              NS      ns.corpit.ru.
ns.corpit.ru.           A       217.23.134.194    <= BIND

dsbl-list.bl.corpit.ru. NS      ns.bl.corpit.ru.
ns.bl.corpit.ru.        A       217.23.134.197    <= rbldnsd

..or something like that.

Either way, the "idea" is the same: you should set up your
BIND and rbldnsd to listen on different IP addresses, but
on the same standard port.

/mjt