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

[Paul Wouters]

On Tue, 21 Jan 2014, Tomas Hozza wrote:

>
> 1. Imagine you boot up the system. NM is started before dnssec-trigger
> and unbound, therefore all informations about domains provided by
> existing connections are discarded.

What information is provided and disgarded? You mean NM tries to
configure a domani forward and since no unbound is running the
add_forward is lost? If so, why are we not starting unbound DNS before
NM?

> So if you were already at the boot time connected to a network that
> provides domains via DHCP no forward zones were added for such domains
> into the unbound.

I was not aware we are unconditionally forwarding random DHCP domains to
random resolvers. You mean if I create a wifi network with search domain
redhat.com and the IP of my nameserver, you are going to redirect all my
DNS lookups? That would be a security problem.

While dhcp domains from static LAN networks can usually be trusted, I
don't want to trust dhcp domains from random wifi access points. And the
only possibly use for that I see is to get past the hotspot/login page,
which I believe should have its own web page and DNS handling anyway.

> Till now there was no possible way how one could get those information
> from NM during the runtime, especially for VPN, but this is already
> fixed in the latest NM git snapshot.

I don't understand how your VPN can be up before your local DNS server
is up? One would assume you need a DNS server to reach the VPN server?

> 2. Imagine you have two connections that provide the same domain.
> One is VPN and one is not. In current situation the last connected
> connection and by it provided NS would be used for that domain.

That is wrong. Luckilly, currently at least the IPsec VPN duplicates
this DNS effort and will overwrite the NM behaviour.

> By my opinion and by what I discussed with Pavel Simerda it makes
> more sense for the VPN to be preferred.

More strongly, why did NM accept that first domain to begin with?

> 3. Imagine you have two connections that provide the same domain.
> One is VPN and one is not. Forward zone for provided domain has
> been added into unbound by the dispatcher script. If you then
> disconnect the connection for which the forward zone has been
> configured, it is removed by the dispatcher script. However even
> there is another connection providing the same domain the
> forward zone is not added, because it is added only if the connection
> goes UP.

That I can see as a problem only when we are on a "secure" LAN that
provided the dns forwards. It should never apply to wifi. And for that,
NM has all the information when it is notified that the VPN goes down,
to redo the DNS forward.

> Due to these reasons I rewrote the script into Python and used
> the NM libnm-glib Python bindings that allow one to get information
> for current active connections from NM.

Great! Having a better NM intergration is awesome!

> The new script works as follows:
>
> A. It gets all active connections from NM that have provided
>   some NS.

What does this mean? A NM manual configuration? Or a combination of
receiving domain and DNS servers from DHCP?

> It gets information if the connection is VPN,
>   or is marked as default connection by NM (for IPv4 or IPv6).
>
> B. Global forwarder are configured using dnssec-trigger-control.
>   1. Only active connections marked by NM as default (4 or 6)
>      are filtered.

I'm not sure what this means? Is a connection "eth0"? Or "StarBucks
wifi" ? What makes a 'connection' a 'default' ?

>   2. NSs provided by such connections are combined into one list
>      (both IPv4 and IPv6 addresses) and passed to dnssec-trigger-control.
>
> C. Forward zones for domains provided by active connections are configured
>   using unbound-control
>   1. Only active connections with domains provided are filtered.

What is a "filter" in terms of "connection"? domain names received  from DHCP?

Does dnssec-triggerd still have a "sane" state when you reconfigure
unbound manually outside dnssec-triggerd? I assume those unbound-control
calls are never for the global DNS resolving, but only specific domains?
Like when my DHCP server returns my nameserver and a domains ".", I
assume you will not send an unbound_control forward_add for "." ?

>   4. Previously configured Forward zones for connections which UUID
>      is different than the UUID of connection that should be used
>      for the domain are removed from unbound.
>      - example: you are connected via wire to network that provides
>      "example.com" domain therefore it has been configured as forward
>      into unbound.

As I said, I think this is dangerous. I don't want random networks to
start giving me DNS server redirects for "google.com" or other things.
While I'm willing to say that for a wire you can do this, I don't really
want this behaviour per default for wifi. I don't really control what
wifis my laptop connects to.

> I also extracted the option for whether to configure secured or unsecured
> forward zones to /etc/dnssec.conf file. This was done so the option
> can be reused also by other tools, not only dnssec-trigger, as we (me and
> Pavel Simerda) plan to implement equivalent functionality and unbound
> plugin for NetworkManager. The configuration file does not need
> to exist, the default behaviour is also specified in the script itself.
> The option name is "validate_connection_provided_zones" since from our
> point of view it is more self-explanatory than "forward zones" used unbound
> terminology.

I'd be happier if this would become an option one can set in the network
properties of NM, "allow network to forward 'redhat.com' to its supplied
nameservers", with a default of off, and possible a prompting for LANs
and and no prompting for wifi, with the only wifi option to manually go
into the network properties. I am not sure I see the value of doing this
seperately from NM in a new config file.

Paul