[sf-lug] bindrndc

[Rick Moen]

Quoting Alex Kleider (a_kleider at yahoo.com):

> Perhaps someone might be able to offer some help regarding DNS.
> I am attempting to set up my own DNS server: BIND9, on a Debian Etch
> system.
> When I try to get it going I get the following error message:
> # /etc/inid.d/bind9 force-reload
> Reloading domain name service... : bindrndc: connect failed:
> 127.0.0.1#953: connection refused
> failed!
> #
> I can only find references to rndc but only in a book dedicated to BIND
> and I can't figure out how it applies to me.
> I can find no reference to bindrndc.
> I'll be very grateful if someone can steer me towards a solution.
> alex

The error message isn't very well worded, is it?

It's _trying_ (badly) to say that the "rndc" utility provided as part of
BIND9 is failing to connect to the necessary network socket on
localhost.   When you run the /etc/inid.d/bind9 script, I vaguely recall
that for some (but not all) operations it invokes rndc behind the
scenes.

"rndc" stands for the (I think) Remote Nameserver Daemon Controller utility.
The name indicates that it's _potentially_ able to carry out control of a
nameserver from elsewhere, where "control" includes fine-grained
operations short of stopping/starting/restopping the entire nameserver.
E.g., you can force the reload of just one zone, without having to
interrupt and restart the entire daemon.

I hear you asking:  "OK, so rndc is crashing and burning.  _Why_ is rndc
crashing and burning?"

I'm going to answer that question, but first you get to hear a little
story about my being a doofus.


When I upgraded my own nameserver from BIND8 to the BIND9 from-scratch
codebase rewrite, I had two problems:  

(1) BIND9 rejected all of my BIND8 zonefiles, and its alleged diagnostic
messages gave no clue about _what_ syntax error BIND9 was upset about, 
merely that something made it run screaming in terror.  Only a bit of
Web searching revealed the secret:  I didn't have any "$TTL" line.  Once
this was added to each zonefile, they parsed perfectly.  In this, I was
lucky, because BIND9 was picky about syntax in a way that BIND8 never
had been, and many other sysadmins were going through eight kinds of
hell debugging their glitches.

(2) The SysVInit script's "start" directive worked, but the "stop" (and
thus also "restart") ones always mysteriously failed.  I couldn't figure
this out, despite vague mumblings in the logfiles about something called
rndc being unable to connect.  So, for several years, whenever I needed
to stop BIND9, I did it with the "kill" command.

Eventually, years later, I got around to looking up what rndc was, and
why it wasn't working.  

Because rndc's intended functionality includes _remote_ control (thus
the "r") of the nameserver daemon, it operates using a public-key
keypair for authentication.  For localhost-only, that would be a little
silly, but the idea is for remote connections to be feasible when/if you
need them.

Cutting to the chase, installation of my BIND9 package -- and presumably
yours -- had not run the utility required to generate that keypair.  So,
rndc was inherently unable to authenticate.  Therefore, it couldn't
issue the command to stop that is part of the reload instruction.


Anyhow:

$ zcat /usr/share/doc/bind9/README.Debian.gz | more

[...]
If you installed an early version of the Debian bind9 packages, prior to
version 1:9.2.0-2 to be more precise, you may have an /etc/bind/rndc.conf
configuration file still on your system.  There's nothing wrong with that,
and if you've explicitly configured keys for using rndc you may well want to
leave things exactly as they are!

However, since 9.2.0 BIND 9.X has supported an rndc.key file that both named
and rndc will read to obtain a shared key for rndc use against a daemon on
the same host.  The rndc-confgen program will easily create a suitable key
file.  To take advantage of this mechanism, you may want to:

        remove the /etc/bind/rndc.conf file
        remove the rndc key specification in the /etc/bind/named.conf file

        rndc-confgen -r /dev/urandom -a

Alternatively, you can 'purge' the bind9 packages and reinstall them and you
will end up with the new behavior since it is now the default.

This is more secure than using a static key that isn't generated on a per-host
basis, and is an easy alternative to more complex key schemes if you only need
to use rndc to talk to named on the same host.
[...]



I believe that's probably all you need.  In general, when in doubt about
random strangeness on a Debian system, taking a peek at
/usr/share/doc/[pkgname]/* is often a really good idea.