Bug 980036 - dnssec-trigger NM dispatcher script should configure unbound in case of vpn-up/down action
dnssec-trigger NM dispatcher script should configure unbound in case of vpn-u...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dnssec-trigger (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Tomáš Hozza
Desktop QE
:
Depends On:
Blocks: 872575
  Show dependency treegraph
 
Reported: 2013-07-01 05:52 EDT by Tomáš Hozza
Modified: 2014-06-18 03:46 EDT (History)
4 users (show)

See Also:
Fixed In Version: dnssec-trigger-0.11-13.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 08:25:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomáš Hozza 2013-07-01 05:52:48 EDT
Description of problem:
Currently dnssec-trigger provided NM does not add new forward zones into
unbound in case vpn-up/down action (connecting/disconnecting to/from VPN).
Instead of that it relies on VPN clients hooks to do this by their own.
This causes DNSSEC validation not to work out of the box if used with VPNs.

Recent fixes in NM allow dnssec-trigger hook to obtain VPN internal DNS
servers IPs and also internal VPN domains.

Version-Release number of selected component (if applicable):
dnssec-trigger-0.11-11.el7

How reproducible:
Always

Steps to Reproduce:
1. install unbound, dnssec-trigger
2. start unbound and dnssec-triggerd
3. connect to some VPN (vpnc, openvpn, ...)
4. try to resolve some internal domain name from the namespace provided
   by VPN server as internal domain.

Actual results:
The domain name is NOT resolved to IP

Expected results:
The domain name is resolved to IP

Additional info:
Comment 1 Tomáš Hozza 2013-07-09 09:08:56 EDT
Patch sent to upstream, see https://open.nlnetlabs.nl/pipermail/dnssec-trigger/2013-July/000210.html
Comment 3 Pavel Šimerda (pavlix) 2013-08-12 10:58:14 EDT
Plans to support unbound even if dnssec-trigger is not installed? With the dnssec-trigger script, NetworkManager/unbound integration is fully dependent on the presence of the dnssec-trigger package, which may be a little bit surprising, at the least. Should there be a separate bugzilla ticket for that?
Comment 4 Tomáš Hozza 2013-08-12 11:15:26 EDT
(In reply to Pavel Šimerda from comment #3)
> Plans to support unbound even if dnssec-trigger is not installed? With the
> dnssec-trigger script, NetworkManager/unbound integration is fully dependent
> on the presence of the dnssec-trigger package, which may be a little bit
> surprising, at the least. Should there be a separate bugzilla ticket for
> that?

AFAIK there are no plans to support DNSSEC on workstations with unbound and
without dnssec-trigger in RHEL-7.
Comment 5 Paul Wouters 2013-08-12 11:17:41 EDT
When you are using networkmanager with a non-static DNS (eg a roaming device) then you cannot blindly add unbound without dnssec-trigger, as  hotspot portals  depend on lying in DNS. You would not be able to get on many wifi networks.

There are two functions that dnssec-trigger performs for this:

1) Detect port 80 mangling and deducing we are on a hotspot, and offer the user an option to briefly disable DNSSEC to logon to the hotspot

2) Check the DHCP obtained DNS servers for suitability with DNSSEC. If so, reconfigure unbound to use these. If not, try other ways to get DNSSEC to the host. If that fails in all ways, warn the user to choose between "insecure" and "cache-only"

So until NM has a "dnssec-trigger like" plugin that takes over that function, you cannot just enable unbound and point resolv.conf to 127.0.0.1 while roaming.

For static servers that want to use dnssec with unbound, there should be nothing more required then "yum install unbound", possible allowing for a single DNS forwarder within the LAN/WAN (which we currently have no config option for AFAIK)
Comment 6 Pavel Šimerda (pavlix) 2013-08-12 12:36:51 EDT
(In reply to Tomas Hozza from comment #4)
> AFAIK there are no plans to support DNSSEC on workstations with unbound and
> without dnssec-trigger in RHEL-7.

I'm just afraid it's too surprising to lose proper [split] DNS support upon dnssec-trigger uninstall or upon installation without dnssec-trigger.

(In reply to Paul Wouters from comment #5)
> When you are using networkmanager with a non-static DNS (eg a roaming
> device) then you cannot blindly add unbound without dnssec-trigger,

Please define “blindly”. NetworkManager already supports dnsmasq for DNS configuration and one would expect unbound to be *at least* as usable as dnsmasq.

> as 
> hotspot portals  depend on lying in DNS. You would not be able to get on
> many wifi networks.

Then it might be worth teaching unbound to avoid enforcing DNSSEC validation by default (i.e. when dnssec-trigger is *not* running) which is a fairly easy modification of the script. Then, if the script (or part of it) is distributed with unbound instead of dnssec-trigger, we would have support for both dnssec-trigger and non-DNSSEC (as well as explicit DNSSEC if we ever want that).

> There are two functions that dnssec-trigger performs for this:
> 
> 1) Detect port 80 mangling and deducing we are on a hotspot, and offer the
> user an option to briefly disable DNSSEC to logon to the hotspot
> 
> 2) Check the DHCP obtained DNS servers for suitability with DNSSEC. If so,
> reconfigure unbound to use these. If not, try other ways to get DNSSEC to
> the host. If that fails in all ways, warn the user to choose between
> "insecure" and "cache-only"

Clearly those are only needed for DNSSEC, which is in line with the use case I was describing.

> So until NM has a "dnssec-trigger like" plugin that takes over that
> function, you cannot just enable unbound and point resolv.conf to 127.0.0.1
> while roaming.

Or until we learn to configure unbound as a non-DNSSEC recursive DNS server.

I consider unbound in many cases superior to dnsmasq and I don't see a reason to keep switching between two recursive DNS server implementations based on the simple DNSSEC versus no DNSSEC decision (s/DNSSEC/dnssec-trigger/ if you wish so).

> For static servers that want to use dnssec with unbound, there should be
> nothing more required then "yum install unbound", possible allowing for a
> single DNS forwarder within the LAN/WAN (which we currently have no config
> option for AFAIK)

Sure, that's yet another use case, or, to be precise, yet another class of use cases.

My intention was not only to solve a specific usecase (like the one Tomáš worked on as described in this bug report) but also to make the individual tools fit nicely with each other. Being able to use unbound as a better replacement for dnsmasq with NetworkManager sounds like a very natural idea as well as a fix for a couple of integration issues. Also, the testing burden would be much lower if the combination of NetworkManager and unbound [and optional dnssec-trigger] became a widely used standard.
Comment 7 Paul Wouters 2013-08-12 14:15:23 EDT
pavel: split dns with libreswan works fine without dnssec-triggerd. If other VPN software does not support it, we can add support for unbound to it. It is unrelated to dnssec-trigger

"blindly" as in "yum install unbound" and pointing resolv.conf to 127.0.0.1

why would i want some unbound fallback to non-dnssec? The whole point of dnssec-trigger is to handle these events _securely_. Doing this without dnssec-trigger is just re-inventing the wheel. There are lots of corner cases.

unbound should _NEVER_ be configured with non-DNSSEC. There is no reason to ever want to support that.

We are not switching between dnsmasq and unbound. We are switching via dnssec-trigger between unbound and whatever upstream dhcp told us to use.

dnsmasq AFAIK is only used on the host for KVM guests doing dhcp+dns. That's another problem that needs fixing as dnsmasq does not support DNSSEC and should not even be in use as DNS server (only as DHCP server) in my opinion

I am not sure what you are asking for. If it is "unbound without dnssec-trigger on roaming devices" then you should tell me why that is a vaild use case. I do not think it is.
Comment 13 Ludek Smid 2014-06-13 08:25:37 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Note You need to log in before you can comment on or make changes to this bug.