Bug 980036

Patch sent to upstream, see https://open.nlnetlabs.nl/pipermail/dnssec-trigger/2013-July/000210.html

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?

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

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)

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

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.

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.