Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 980036 - dnssec-trigger NM dispatcher script should configure unbound in case of vpn-up/down action
Summary: dnssec-trigger NM dispatcher script should configure unbound in case of vpn-u...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dnssec-trigger
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Tomáš Hozza
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 872575
TreeView+ depends on / blocked
 
Reported: 2013-07-01 09:52 UTC by Tomáš Hozza
Modified: 2014-06-18 07:46 UTC (History)
4 users (show)

Fixed In Version: dnssec-trigger-0.11-13.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 12:25:37 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Tomáš Hozza 2013-07-01 09:52:48 UTC
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 13:08:56 UTC
Patch sent to upstream, see https://open.nlnetlabs.nl/pipermail/dnssec-trigger/2013-July/000210.html

Comment 3 Pavel Šimerda (pavlix) 2013-08-12 14:58:14 UTC
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 15:15:26 UTC
(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 15:17:41 UTC
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 16:36:51 UTC
(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 18:15:23 UTC
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 12:25:37 UTC
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.