Re: Looking for dnssec-triggerd alpha testers!

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

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...


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

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
2) use the auth servers directly (unbound-control forward off)
3) block unbound from doing any new lookups (unbound-control forward
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 :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]