Re: Looking for dnssec-triggerd alpha testers!

[Dan Williams <dcbw redhat com>]

On Thu, 2011-09-22 at 14:26 -0400, Paul Wouters wrote:
> On Thu, 22 Sep 2011, Dan Williams wrote:
> 
> > But I'm not really familiar with unbound.  Is it a long-running service?
> 
> Yes, It's a fully dnssec validating caching resolver. You start it at boot
> and leave it running.
> 
> > What does its config file look like?  Does it re-read config data on
> > SIGHUP?
> 
> 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.

Ideally we can send all the information to unbound in *one* request (to
reduce possible race conditions) and get back meaningful status/error
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?

Dan

> > Is there any case you'd run more than one instance at a time,
> > like we do with dnsmasq when you have virtual machines that use dnsmasq
> > as the forwarding nameserver between the NAT-ed VM and the host?
> 
> You could, but in general one does not. Unlike dnsmasq, unbound delivers no
> dhcp or other services. It is just a very secure DNS resolver.
> 
> > How complicated is the config file format?  Does it have the ability to
> > specific different nameservers on a per-zone basis?
> 
> Yes you can specify specific forwarders for specific zones using the forward
> and stub sections (not sure if you can send these via unbound-control currently)
> You can even assign those a DNSSEC key, so you can validate non-public zones
> that would normally be proven "not to exist" in the real world.
> 
> >> which you got via DHCP (aka ISP's nameservers). Those servers perform
> >> caching so local unbound/bind will use them and there won't be increased
> >> DNS traffic over the Internet due bypassing those caches.
> >
> > Understood.
> 
> Indeed.
> 
> Paul
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list