Bug 1317593
| Summary: | handle missing or not running unbound and dnssec-trigger services better with dns=unbound | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | David Jaša <djasa> |
| Component: | NetworkManager | Assignee: | Thomas Haller <thaller> |
| Status: | CLOSED WONTFIX | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | CC: | aloughla, atragler, bgalvani, lrintel, mleitner, rkhan, sukulkar, thaller, thozza |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-06-16 14:24:23 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Currently, NetworkManager's dns=unbound plugin is a very simple thing. It does nothing but calling /usr/libexec/dnssec-trigger-script --async --update on every DNS change. https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns-manager/nm-dns-unbound.c?id=e8b7d3e01dc2d2f73a09558f3b019b0a2a425dbb I think, dnssec-trigger still prefers to be invoked via /etc/NetworkManager/dispatcher.d/01-dnssec-trigger-hook, instead of setting dns=unbound, doesn't it? The dns=unbound plugin is essentially unused at this point. (CC-ing Tomas) (In reply to Thomas Haller from comment #1) > I think, dnssec-trigger still prefers to be invoked via > /etc/NetworkManager/dispatcher.d/01-dnssec-trigger-hook, instead of setting > dns=unbound, doesn't it? > The dns=unbound plugin is essentially unused at this point. Yes, this is correct. RHEL-7 documentation contains the guide about how to setup dnssec-trigger with Unbound (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Securing_DNS_Traffic_with_DNSSEC.html). While it may be confusing, it is not expected that setting dns=unbound in NM configuration will make dnssec-trigger and Unbound work correctly. We don't even promote it anywhere in the documentation. The unbound DNS plugin is more of a PoC than final implementation. With the current state of dnssec-trigger in RHEL-7 I don't think there is any easy and quick solution on dnssec-trigger / Unbound side. Maybe just documenting that it is expected that dnssec-trigger and Unbound is running would be a solution for now? The dns=unbound plugin is really just a initial implementation, see https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns/nm-dns-unbound.c?id=1.8.0#n41 As Tomáš said, it is not documented, nor recommended to set this DNS plugin for dnssec-trigger. Instead, the suggested way to use dnssec-trigger is via it's NetworkManager dispatcher script. Maybe, one day "dns=unbound" plugin will gain more functionality. Or maybe it should be just retired. But for the DNS plugin to be actually useful, it would first need to get significantly more functionality to be able to replace the dispatcher script. That is a lot of work, far beyond not working well when the unbound service is disabled. I would vote for closing this as WONTFIX, unless somebody comes up with a concrete plan for which features to implement. And also important: what are the shortcomings of the current implementation (dispatcher script), that ought to be fixed by improving the DNS plugin. +1 for closing this as WONTFIX. We currently don't plan to extend the unbound plugin in NM beyond what is already expected and documented in the official documentation. |
Description of problem: Setting dns=unbound is not enough to make DNS work using unbound (unlike dns=dnsmasq when NM arranges everything) so NM should handle when required unbound and dnssec-trigger services are not present and running. NM currently: * quietly falls back to dns=default when services are not present at all * runs with old DNS configuration with present but not running services * doesn't give a clue of what's going on in either case. NM should in either case complain that the system settings are incompatible with its configuration on both service start and connection activation (when it would like to update unbound configuration) and it should fail in the same way in both cases: either to dns=default or to no dns at all. I prefer no dns as dns=default masks error, giving possibly an administrator warm cosy feeling that user's DNS is secure when it is not. Choosing dns=default as the fallback makes proper logging even more important. Version-Release number of selected component (if applicable): NetworkManager-1.0.6-27.el7.x86_64 How reproducible: always Steps to Reproduce: 1. connect to a network with dns=unbound but unbound & dnssec-trigger missing 2. connect to a network with dns=unbound but unbound & dnssec-trigger installed but disabled 3. Actual results: 1. connection is successful, upstream dns is used 2. connection is successful, resolv.conf is retained as-is (so DNS may or man not work. Not good to fail in upredictable way). no clear message about missing unbound & dnssec-trigger services is given either on service start or upon connection activation. Just cryptic messages about scripts missing (e.g. [1] when service is present but not running). Expected results: * NM logs clear messages on service start and on activation of connection with upstream DNS * NM behaves the same way in both error cases * NM fails/falls back predictably (IOW not to dns=none) * either to to dns=default (insecure but more robust) * or to "nameserver 127.0.0.1 (more secure but less robust - system may end up with no DNS available) Additional info: [1]: <warn> (2) 01-dnssec-trigger-hook failed (failed): Script '/etc/NetworkManager/dispatcher.d/01-dnssec-trigger-hook' exited with error status 1