This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 975789 - NM should provide a way to obtain internal DNS IPs and internal zone provided by VPN connection
NM should provide a way to obtain internal DNS IPs and internal zone provided...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity urgent
: rc
: ---
Assigned To: Rashid Khan
Desktop QE
: Patch
Depends On:
Blocks: 872575
  Show dependency treegraph
 
Reported: 2013-06-19 07:11 EDT by Tomáš Hozza
Modified: 2014-06-17 22:45 EDT (History)
5 users (show)

See Also:
Fixed In Version: NetworkManager-0.9.8.2-7.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 05:22:23 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)
Fix for dispatcher to expose IP4/6 domains (1.72 KB, patch)
2013-06-21 10:31 EDT, Tomáš Hozza
no flags Details | Diff
Fix for dispatcher to expose IP4/6 domains (1.84 KB, patch)
2013-06-21 15:25 EDT, Tomáš Hozza
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 701820 None None None Never

  None (edit)
Description Tomáš Hozza 2013-06-19 07:11:10 EDT
Description of problem:
Currently there is no way to obtain internal DNS servers IP addresses and
internal zone provided by VPN server from NM. There is no way how to do this
using nmcli. This information is also not provided to NM dispatcher script
if action is vpn-up/down. The only extra information that is provided to
the script is the UUID of VPN connection. The UUID is also not usable to
obtain internal DNS servers IPs.

NM should provide a way to obtain these information. It is crucial for
DNSSEC validation on workstations (using unbound and dnssec-trigger)
to work with any NM supported VPN out of the box.

Currently dnssec-trigger is providing a NM dispatcher hook script to obtain
DNS servers provided by DHCP. But when using VPN connection it is necessary
to signal internal DNS servers to unbound so it is able to resolve domain
names from within the internal (VPN) zone.

Version-Release number of selected component (if applicable):
NetworkManager-0.9.8.1-2.git20130507.el7

How reproducible:
Always

Steps to Reproduce:
1.
2.
3.

Actual results:
There is NO way to obtain internal DNS servers IPs and internal zone on
vpn-up/down action in NM dispatcher script.

Expected results:
There IS a way to obtain internal DNS servers IPs and internal zone on
vpn-up/down action in NM dispatcher script. (using environment variables
or using nmcli)

Additional info:
Comment 2 Tomáš Hozza 2013-06-19 10:37:37 EDT
I found out that there are UNDOCUMENTED environment variables with "VPN_" prefix
in case dispatcher script is called with vpn-up/down. So it is possible to get
internal DNS IPs this way (although it looks there would be some issues with
IPv6 configuration from VPN server), but there is still missing the possibility
to get internal domain received from VPN server.
Comment 3 Paul Wouters 2013-06-19 13:38:04 EDT
There are 4 parts here that need to work together.

1) NM
2) unbound (or other DNS server)
3) vpn software
4) dnssec-triggerd


currently 1) and 4) are "fighting" over who should control /etc/resolv.conf. The best solution would be for NM to keep control, and for dnssec-triggerd to have support for nm, so instead of writing /etc/resolv.conf itself, it should dispatch that to NM

The vpn hooks should be updated so that they do not call unbound-control directly, but tell NM, which in turn then uses unbound-control if that's the current DNS server used. These vpn hooks should allow for sending DOMAIN and name server list to NM.

out of scope for this bugzilla is that dnssec-trigger also decides/detects hotspots and changes resolv.conf accordingly. all that communication should really be done by NM, which should be informed by dnssec-triggerd when the "DNS situation" changes.
Comment 4 Tomáš Hozza 2013-06-21 10:31:53 EDT
Created attachment 763870 [details]
Fix for dispatcher to expose IP4/6 domains

Fix for NM dispatcher to expose IPx_DOMAINS environment variable to the script.
The functionality was already there, but broken. With this patch the NM
dispatcher in case of vpn-up exposes VPN_IP4_DOMAINS with domains received from
VPN server to the script.
Comment 5 Tomáš Hozza 2013-06-21 15:25:35 EDT
Created attachment 763944 [details]
Fix for dispatcher to expose IP4/6 domains

new version of the patch
Comment 6 Dan Williams 2013-06-21 18:09:08 EDT
Pushed the updated version of the patch.  Thanks!
Comment 7 Tomáš Hozza 2013-06-26 10:57:06 EDT
(In reply to Paul Wouters from comment #3)
> There are 4 parts here that need to work together.
> 
> 1) NM
> 2) unbound (or other DNS server)
> 3) vpn software
> 4) dnssec-triggerd
> 
> 
> currently 1) and 4) are "fighting" over who should control /etc/resolv.conf.
> The best solution would be for NM to keep control, and for dnssec-triggerd
> to have support for nm, so instead of writing /etc/resolv.conf itself, it
> should dispatch that to NM

There is already a way how to resolve this. In the upstream repo there is fix
in NM DNS manager. It introduces a new keyword that can be used in
NetworkManager.conf to tell NM not to take care of DNS configuration.
The usage is as follows:

dns=none

I'll create another NM Bug to include this fix in RHEL-7.

I think dnssec-trigger could modify NM configuration so it does not do DNS
configuration so dnssec-trigger does not have to lock resolv.conf.

> The vpn hooks should be updated so that they do not call unbound-control
> directly, but tell NM, which in turn then uses unbound-control if that's the
> current DNS server used. These vpn hooks should allow for sending DOMAIN and
> name server list to NM.

AFAIK VPN clients hooks don't work out of the box with unbound. Also VPN
is currently providing all information to the NM. I think it would be better
to use and modify existing dnssec-trigger NM dispatcher script to do all
necessary unbound configuration, than implementing a NM plugin.

> out of scope for this bugzilla is that dnssec-trigger also decides/detects
> hotspots and changes resolv.conf accordingly. all that communication should
> really be done by NM, which should be informed by dnssec-triggerd when the
> "DNS situation" changes.
Comment 8 Jirka Klimes 2013-07-09 08:22:52 EDT
(In reply to Tomas Hozza from comment #5)
> Created attachment 763944 [details]
> Fix for dispatcher to expose IP4/6 domains
> 
> new version of the patch

The patch and related changes was backported to current RHEL7 code-base and built: NetworkManager-0.9.8.2-7.el7

Note:
http://bugzilla.gnome.org/show_bug.cgi?id=703395 is not handled yet.
Comment 9 Tomáš Hozza 2013-07-09 08:50:39 EDT
Thank you Jiri!

I'll create a separate Bug for http://bugzilla.gnome.org/show_bug.cgi?id=703395
so it can be tracked there, since this Bug is in MODIFIED.
Comment 11 Vladimir Benes 2014-04-15 08:03:24 EDT
We enabled dnssec-trigger (and unbound) and connected to vpn, checked that /etc/resolv.conf contains just 127.0.0.1 and tried some dns resolving. It worked as expected.
Comment 12 Ludek Smid 2014-06-13 05:22:23 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.