[Dnssec-trigger] New dnssec-trigger NM dispatcher script

[Paul Wouters]

On Wed, 22 Jan 2014, W.C.A. Wijngaards wrote:

>> knowledge about that, yet). Please speak up if you have reasons to
>> believe that any configuration of unbound is capable of running
>> before NetworkManager.
>
> Unbound may be able to start with interface-automatic: yes enabled
> (for incoming).  It then is an open resolver that serves everyone.
> The default outgoing interfaces (0.0.0.0 and ::0) work fine.  I think
> this can start before the network is up.  When interfaces come up,
> unbound starts to serve port53 DNS to them.
>
> A side effect would be an open resolver accessible from the outside,
> because your config now is that unbound binds 127.0.0.1.  However, the
> access-control statements are checked after that, and there you can
> say that 127.0.0.1 gets service and other addresses are REFUSED (or
> dropped) (and also firewall port53 is another option).

I would be okay with this change. Currently, interface-automatic: is no
to comply with the policy of not starting servers without user consent,
but if we are making unboudn the default, this indeed makes sense, and
we should just configure unbound with localhost ACL's but let it listen
on all interfaces. Thanks for this suggestion.

> It would conflict for people that additionally want to run a DNS
> server for the outside world, i.e. on port53 on another interface.
> But the OS may also bind the more-specific interface for that other
> daemon (I think this depends on socket options).

This might be a problem indeed, especially with KVM/virt-manager and
dnsmasq instances that run on vnet* interfaces. I don't know of a
solution for this, as dnsmasq is needed for DHCP. Perhaps we could tell
dnsmasq to forward all DNS to 127.0.0.1? However, that would expose
host DNS changes to the guests. Which I think is okay?

Paul