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

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Pavel,

On 01/22/2014 12:16 PM, Pavel Simerda wrote:
>> 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.

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

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

Best regards,
   Wouter



> 
> 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
> 
> _______________________________________________ dnssec-trigger
> mailing list dnssec-trigger at NLnetLabs.nl 
> http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS38L3AAoJEJ9vHC1+BF+NXisP/19LIJ4+XnEvVTiVC7y2iiUh
J0eCA5guvMQwEmV7wCAtO/GflgagTYmsjDiHfaNbYheqYbFwhwdXnBdfZlUi5t3N
XFa9T3szFr9tyjzrB6G92HlrzHVpuvtXyd2DmhQeF+ouZnO4/z1mh1+jdibgbB8x
C17aUD3EUWhYR/pTFx7udt3eFh231sKZN/6z+xrZab8DlbDnJ+QxgLhf4jTU+kA/
XF/Njc+Fp10je/GhOIzB7tvbqQlRBngH/YmhSrfSgfb3N1hiTAYAdIrPR/0ra+g/
HONZyVW672JOO00sA4snICzxky7avomMvBWmU+Jp+znbWeyAbh4Er5aVPCFJ9AXA
0Bj3Q2D9kYPHbQr5qm/eUd6QvV5oNMZDlgE6k5nj30//E+lVyiGycCixOXkNQCvf
krN5EHhOvSh4xKXt4UTjiK8Z5IEznTxZV5ODsnfYLrlwDMGiGVTVEBVhxgMW8TTX
u7HPm4av82x1e0ZGDEJSj3L4/AEiAZ5+AGUj0bZwb3qbsrnfoi+TcQq127S19LfL
GLxsl3rNtrHs9PR9MGLjlawdINZd4wNt16kFlfJLwd506xQ3o/Vk8otw4UDBrwMw
Feg/rDkrmbwDq363SIBIOnpHUXWMZaDeXBZzaEG4RjZ36m8X/RB7vBKV2Zk5pUou
xsUhWteFvUoi6CRCJKde
=ca0b
-----END PGP SIGNATURE-----