Re: Looking for dnssec-triggerd alpha testers!

[Paul Wouters <paul xelerance com>]

On Thu, 22 Sep 2011, Dan Williams wrote:

> > You properly talk to it via unbound-control, which uses SSL certs between
> > it and the daemon. No need to re-write config files or send it weirdo
> > signals.
>
> Ok, this part mystifies me.  I assume it just has a TCP socket listening
> that you talk to it on?  Otherwise there's no point to using SSL on a
> localhost where the socket would ideally be root-protected anyway.
> Which would be a lot simpler for programmatic control.  I'm a bit
> concerned about fragility here, since if we require SSL certs to talk to
> the daemon on localhost, that means you need to have a whole bunch of
> other stuff set up (CA certificates, point the helper to the CA
> certificates, somehow generating the client/server certificates when
> unbound is installed, etc) before things will work, which typically
> shouldn't be necessary talking to a local machine with both processes
> running as root.

On first startup, the unbound init script generates all the certs for
unbound-control to talk to unbound. See:

yum install unbound
service unbound start

Then you can do things like:

[paul@bofh paul]$ sudo unbound-control status
version: 1.4.12
verbosity: 1
threads: 2
modules: 2 [ validator iterator ]
uptime: 92870 seconds
unbound (pid 2148) is running...

and:

[paul@bofh paul]$ sudo unbound-control forward
off (using root hints)
[paul@bofh paul]$ sudo unbound-control forward 193.110.157.136 193.110.157.2
ok
[paul@bofh paul]$ sudo unbound-control forward 
193.110.157.2 193.110.157.136
[paul@bofh paul]$ sudo unbound-control forward off
ok

> Ideally we can send all the information to unbound in *one* request (to
> reduce possible race conditions) and get back meaningful status/error

Let's clarify things a bit here. unbound should only be fed "known working"
DNS resolvers. Currently, dnssec-triggerd is performing that check. If
these DNS servers are broken, dnssec-triggerd checks if it can talk to the
auth servers directly. Then it is ready to reconfigure unbound to:

1) use the resolvers (unbound-control forward 1.2.3.4 5.6.7.8)
2) use the auth servers directly (unbound-control forward off)
3) block unbound from doing any new lookups (unbound-control forward 127.0.0.127)
4) go insecure (prob implemented using 1) plus unbound-control set_option val-permissive-mode: yes)

So either the NM plugin takes over that core from dnssec-triggerd, or it
outsources this ti dnssec-triggerd. If the latter, then it talks to dnssec-triggerd
in a similar way as you talk to unbound. Via a dnssec-triggerd-control command,
which uses certs that are also generating on first service start of dnssec-triggerd

> information too.  That's often the problem with running helper binaries,
> in that screen-scraping is a horrible, horrible way to return error
> information.  Ideally the helper binary returns a nice fine-grained exit
> value and hopefully prints out well-formatted error messages to stderr?

The output is pretty terse and simple? Not sure if unbound-control or dnssec-triggerd-control
use nice different exit codes for failures, and if not, if Wouter would like to
implement that :)

Paul