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

[Pavel Simerda]

----- Original Message -----
> From: "Tomas Hozza" <thozza at redhat.com>
> To: "Paul Wouters" <paul at nohats.ca>
> Cc: dnssec-trigger at NLnetLabs.nl, "Juraj Marko" <jmarko at redhat.com>, "Pavel Simerda" <psimerda at redhat.com>
> Sent: Wednesday, January 22, 2014 10:47:59 AM
> Subject: Re: [Dnssec-trigger] New dnssec-trigger NM dispatcher script
> 
> 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.

Actually this is a long discussed dependency issue. Even some very basic networking services assume that the network is ready at the time they start, while they could technically start at *any* time provided that they can cope with changing network configuration (which they should do anyway). Fortunately this is generally fixable and may even already be fixed in unbound (I have no knowledge about that, yet). Please speak up if you have reasons to believe that any configuration of unbound is capable of running before NetworkManager.

Either way, Tomáš's work led to discovery of bugs and missing features in NetworkManager, which are now fixed. NetworkManager is now capable of providing (almost) all relevant information it has, which is basically the list of connections and their associated static and dynamic configuration including information from DHCP, VPNs. You can now access that information at any time whether you have any of them already or not.

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

We discussed it thoroughly and we basically came to a conclusion that you have to distinguish levels of DNSSEC support and their relation to the real world configurations. A simplified version follows:

0) No validation.
1) Validation with exceptions useful for applications supporting the AD flag.
2) Validation of all DNS queries by all applications.

The current status of virtually all realistic deployments is #0, as is the default for distributions. Switching to anything else than "no validation" previously meant many everyday networking usecases would stop working which is not acceptable.

In my view, Tomáš's patch employs #2 (the strict mode) by default and makes it work with many more use cases than before. Basically, it works with both *global internet* and *private networks covered by global DNSSEC validation tree*. Unfortunately there are many networks that need to be accessed without validation and that's where #1 comes into the play.

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

If we accept the levels written above, for level #2 that would indeed be a security problem. But for level #1 that would be acceptable (note the requirement to check the AD flag by application). I understand that is not much, but at least it allows *selected* applications to make full use of DNSSEC while not breaking everyday user experience and that encourages DNSSEC deployment both on the client side and on the server side.

Also there are many machines that aren't affected by the road warrior use cases and can make full benefit of #2 for various reasons. Tomáš's patch does't affect the validation in that case but makes it possible to still dynamically configure DNS forwarders for specific local zones.

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

I think this would be best handled in NetworkManager itself, which is the natural follow-up after we get at least basic DNSSEC (and split DNS) support in distributions (which we hope will be accelerated by Tomáš's contributions where even the most conservative distributions might consider #1 by default).
 
> 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!

+1

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

+1

You could theoretically distinguish the source of the configuration (contribution to NM may be needed, though) but my impression is that it would be better handled in NetworkManager itself. In my opinion, NetworkManager should be the service that decides whether a forward zone would be validated or would get an exception of being unvalidated. That's also why we are using /etc/dnssec.conf which is currently read by the dnssec-trigger script but could later be taken over by NetworkManager entirely, with connection configuration providing more detailed DNSSEC options.

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

When a connection is selected as 'default' or 'a default routing connection' for IPv4 and/or IPv6 traffic, a default route is set up to *route traffic by default through that connection* and to query DNS by default via servers beloning to that connection*. It's pretty simple unless you get different connections default for IPv4 and IPv6 where NetworkManager doesn't tell you which DNS servers should be used.

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

While the preference affects default connection choice, it's not entirely the same. You can actually mark a connection so that it never becomes default and so you can use it only for accessing local resources determined by IP subnets and DNS zones.
 
> > >   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.

By blocking this on wifi, you're introducing a regression in functionality. While that may be acceptable in some cases, it doesn't mean it will be acceptable for distributions to be used by default. By not using local DNS servers and/or forcing validation of local DNS domains, you're effectively blocking the user from accessing the local resources, whatever they are. We aren't saying dnssec-trigger should permit that by default (Tomáš actually did the opposite) but we want to allow the deployment of DNSSEC (at least as specified in level #1 above) without disturbing the everyday networking use cases.

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

+1

Basically if you turn off validation for local zones, you should be able to resolve local resources as you did without dnssec-trigger installed. Otherwise we're killing the solution for 99.9% of potential users.

> > > 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",

I agree with that. It's in the scope of NetworkManager and we definitely count with advanced options in NetworkManager. You can treat the script simply as a way to transport the resulting configuration from NetworkManager to dnssec-trigger and unbound and Tomáš's version already does that pretty well. There are two improvements that should IMO follow up, one is that NetworkManager should provide all the necessary configuration options for filtering and marking the zones and the other is that NetworkManager should eventually consume the script so that its functionality is an intrinsic part of NetworkManager. But none of them will happen this month ;).

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

Hope that helps.

Cheers,

Pavel