[rbldnsd] Re: pidfile patch for rbldnsd-0.73

Michael Tokarev rbldnsd@corpit.ru
Sat, 08 Mar 2003 18:18:06 +0300


[Cc'd to rbldnsd@corpit.ru]

Bruce Gingery wrote:
> Michael,
> 
>   Delighted with your rbldnsd.  The attached patch adds an optional
>   pidfile, opened before chroot, written to after fork, allowing
>   even the chroot'd operation with non-privileged user to write the
>   pid of the daemon to (e.g.) /var/run/   This allows non-killall
>   shutdown from rc.d scripts.

Yes, I thought about this but was lasy to implement... ;)  Thanks.
I'll apply it with some mods - below.

[]
>   I'd avoided Dan Bernstine's daemons because of the need to run the
>   whole daemon watcher system.

rbldnsd is just more "traditional" way.. ;)


[]
>   In this patch, both the opening of the PID file and the write+close
>   are conditioned on !nodaemon -- so that foreground operation ignores
>   the added "-p </abspath/pidfile.pid>" parameter, even if given.

Umm...  why ignore parameter if it is given?  For debugging, there is
just no need to specify a pidfile, right?  It may be used when rbldnsd
is started from some "watcher" process (but I don't know if there is
a need to write pid file in this case).

>   IF rbldnsd is run from an insecure setuid script, or installed setuid,
>   for access (for example) to reserved port 53, this patch COULD be
>   abused to overwrite files which the daemon should not be able to
>   overwrite.  I consider this a trade-off for writing a system daemon's

If rbldnsd in it's current incarnation will be setuid, it will be able
o read (not write) e.g. /etc/shadow and, perhaps, present it's contents
as a dns zone (funny enouth and I'm not sure that's possible to use such
a zone - that will be dnset), and, if -u option is also given, it will
be just easy to dump it's core by sending it a signal.  It MUST NOT be
setuid, period.

>   PID to a guarded directory, and allowing multiple instances to be
>   discriminated between -- each with the same capabilities.
> 
> In TODO, you mention ...
> 
> /* TODO:
>  * maybe multi-children environment
>  * review all names to be consistent
>  * review log/error routines to be buffer-overflow friendly
> 
>    Yes, that's important.

Currently, logging is used only when (re)loading zones.  Neverless,
logging is currently broken from this point of view - it's easy
to overflow log buffer. I hope to address this issue this weekend.

>  * implement TCP mode (in separate process, to reduce number of syscalls)
> 
>    Hmmm - I'll leave that up to you.  The problem that springs to
>    the foreground is the potential need for TCP for long TXT returns
>    and the difficulty in syncronization among multiple TCP separate
>    processes, with the UDP listener for any kind of load balancing.

TCP is mostly for AXFR.  Normal DNS answers are limited to 512 bytes
and that's enouth already - if an answer will contain several records,
last ones (which don't fit) will be ignored.  One TXT is usually
sufficient to give a rejection reason, and more TXTs makes such a
reason (e.g. in SMTP session) too long.

>    Perhaps you'd want to disallow AXFRs on TCP socket in the SAME
>    client, and have a separate client for AXFR or even BIND-compatible
>    zone generation that does _not_ use AXFR. A  tcpwrapper controlled
>    dump of zone text.

What I have in mind is - after zone reloads, spawn separate process
that will listen on TCP socket, forking childs (or using nonblocking
I/O) as appropriate (so that main UDP listener will not need to use
select or the like).  When new reload is performed, just kill the
TCP daemon (allow it to complete currently active requests).  This
way, only one (or two) copies of zones will be keept in memory, and
no fancy process syncronization is needed.

But the problem with connection rate limits and number of active
connections do exists, and implementing such controls in a right
way will require some coding... ;)

Problem with bind-style zones and with using bind for AXFR is that
in such a case, memory requiriments will be MUCH larger (rbldnsd
usually uses about 1% of memory required by bund for the same zone).
That to say - if one will use bind, why use rbldnsd? ;)

>  * implement AXFR query - stupid idea but AXFR is widely used
> 
>    Quite widely used.

Yes.  VERY many resources (bandwidth and CPU) required for AXFR in
this context, yet AXFR is just easy and people are lazy...
Rsync of zone files + reload (if not automatic) will do the trick.

>  * use config file with:
>  *  - NS records
>  *  - SOA records
> 
>    Yes, please.  Leave zone serial generation to an outside process.
> 
>    Permit me to suggest that a DIFFERENT file be used for zone
>    info data as recommended (or even mandated) operation.  That
>    allows commandline tagging to specify format for each file.

I want to use config file similar (in purpose) to named.conf.
Something like:

zone proxies.example.org {
  data ip4vset:zones/proxylist;
  data generic:zones/proxysoa;
  allow-transfer { 192.168.1.0/24; };
  ttl 5m;
};

where zone type `generic' is similar to that of bind (with less
"features"), where one will be able to specify SOA, NS, and
maybe some other TXT records (e.g. like in osirus zones -
about.relays.osirusoft.com IN TXT).

The only problem is that, at the same time, I want to be able
to "derive" SOA serial number from the date of data file, and
it's not obvious how to avoid clash with SOA specified in
"generic" zonedata, and where to find other fields required
for SOA if only one zonefile is given like currently.

>  *  - ability to construct a zone from several files
> 
>    parse #include "tagtype:filename" inlined in file?
> 
>    That makes file watching more complex, but allows mixed
>    zones to be specified, and, for example a zonehdr: tag
>    for NS/SOA records.

See above.

There is another question remains - what to do with IPv6.
E.g. default solaris9 sendmail is compiled with IPv6 support,
and it issues AAAA queries to DNSBLs.  Currently, rbldnsd
(and DJB's rbldns) just refuses the request, and if sendmail
is asking local named cache, named returns SERVFAL and the
whole system does not work.  Maybe rbldnsd may answer with
NXDOMAIN to queries it doesn't know about, or to some number
of special query types (like AAAA).

> *** rbldnsd.c.orig	Tue Feb 11 18:17:00 2003
> --- rbldnsd.c	Sat Mar  8 05:57:45 2003
[]

Yes, the patch looks nicely.  Thank you.

/mjt