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

[Tomas Hozza]

Hi Paul.

Thank you for your feedback.

----- Original Message -----
> 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?

Exactly like you've said, NM dispatcher runs the script that tries to
configure forward domain running the add_forward, but since unbound is
not running and the information is discarded. Before there was no way
how to get the information from NM after the interface (or connection)
was already up, especially for VPNs. But now there is such a way.

As for the idea of starting unbound before NM. I had the same idea right
after I realized what was actually happening and experimented whit it.
Unfortunately this solution is no feasible due to (systemd) service
dependencies.

NM needs to be started before the network is fully configured, since itself
configures interfaces. The DNS (unbound) has to be started after the network
interfaces are configured. I tried it and it didn't work due to these
dependencies.
 
> > 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.

The reason for such behaviour is described later (marked with *). However
I'm aware of the implication, therefore I think the DNSSEC validation of
such forward zones should be enabled by default to prevent possible
DNS answers manipulation. User needs to intentionally turn the validation
off.

At the current implementation I don't see any reasonable solution how
to enable the user to explicitly specify for which connections they want
to configure forward zones.

Other thing is that you are connecting to some network (wifi for example)
intentionally. It's not like your notebook is randomly connecting to
any network it discovers by default.

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

One can use IP address instead of domain name in this case, but anyway
in this case it was not meant for VPN connection, but any other connection.
For example in the RH office, the wired connection provides you "redhat.com"
domain.

(*)
In case local (internal) NS are not fully DNSSEC capable, dnssec-trigger would
not use them for resolving. But you still may want to use them at least
for the provided domain, hence the forward zone for a connection provided
domain(s) and not only for VPNs.

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

I agree, hence I see the need for correcting this 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?

I agree with you that NM behaviour is not correct in this case.
Unfortunately I'm not NM developer and therefore not a good person
to discuss the NM behaviour 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.

You may have a "secured corporate" wifi connection the same situation
as described in (*) can happen. I'm not sure there is any
way how to distinguish it from regular secured wifi connection.

For the information NM has when VPN goes down, it is correct. However
in the current shell script it was not implemented in any way, since
the script only removed the forward zone for the connection that went
down, but didn't add new forward for existing connection if it provided
the same domain.

The forward domain was added only for connection going up, since it would
require getting runtime information from NM for all active connections
and extended logic - the thing the new python script does.

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

This behaviour basically didn't change since previous dispatcher scripts.

FWIK active connection in NM terminology means connection that is
active and connected at the time you're checking it. It's configuration
may be fully dynamic (information provided via DHCP), static (if configured
manually in NM) or combination.

So in most cases it is information provided by DHCP, but this may not
be fully true in all cases. I hope Pavel Simerda will correct me if I'm
wrong in this.

> > 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' ?

>From my point of view it is some NM magic. The flag is based on some
NM logic and prioritization. Default means that the connection should be
used by default for outgoing communication (it may be different for IPv4
and IPv6). In case you have wifi and wired connection, the wired connection
is always preferred.

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

This is more of a Python terminology. It means that only active connections
with provided (forward) domains are used for further logic. This is due to
it doesn't make much sense to work with a connection that does not provide
any domain in terms of Forward zones addition/deletion.

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

What about the "secured corporate" wifi network situation I described before?
I personally see a use case also in wifi networks, but I agree that it is hard
to come up with a really good solution. I'm willing to improve it in some way
if you have any constructive ideas (in the constraints of current possibilities),
but stopping the addition of forward zones for wifi connections completely is
also not a good idea by my opinion.

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

I agree with this. Unfortunately at the moment it is not possible in the
NM UI and will require even further NM integration (which is planned,
but will not happen over night).

The plan is that the configuration file could be at least partially
used by NM in the future. This way we will be able to at least provide some
backward compatibility with the current solution that uses dnssec-trigger.
Therefore we think it is not a good approach to leave the configuration
solely in dnssec-trigger dispatcher script.

The motivation here is to improve the current situation due to some
issues I described before, in the constraints of current possibilities,
rather than implement the best possible solution later on (which will
anyway happen).


Regards,

Tomas Hozza