Bug 1168278 - [RFE] unbound: implement hotspot signon mode
Summary: [RFE] unbound: implement hotspot signon mode
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: unbound
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paul Wouters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: dnssec
TreeView+ depends on / blocked
 
Reported: 2014-11-26 15:05 UTC by Pavel Šimerda (pavlix)
Modified: 2020-11-03 14:02 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-03 14:02:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Pavel Šimerda (pavlix) 2014-11-26 15:05:58 UTC
Currently dnssec-trigger when getting in hotspot signon mode has to unlock the resolv.conf containing 127.0.0.1 and replace it with either the original resolv.conf written by the administrator or with the one written by NetworkManager (which doesn't even work, yet).

This bug is about one alternative solution where dnssec-trigger would rely on unbound to:

1) Not perform DNSSEC validation in signon mode in order to allow the user to access the captive portal.

2) Avoid polluting the cache in a way that would impact security after switching back from the signon mode.

3) Filter out any AD flag for the user. This also works as a partial solution for bug #1164339 and bug #1164337. Partial in that they would no longer affect the signon mode, so they would not occur as long as dnssec-trigger daemon is running and managing /etc/resolv.conf.

This may be an easier solution than a special browser window excluded from DNSSEC coverage, so it might be more suitable for the short term.

Comment 1 Jaroslav Reznik 2015-03-03 17:05:47 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 2 Tomáš Hozza 2015-04-01 15:37:24 UTC
Pavel, I think this should be filled into the upstream bugzilla and discussed there first.

Comment 3 Paul Wouters 2015-04-01 15:42:20 UTC
upstream has created dnssec-trigger for that. I dont understand why we think it should go into unbound nativly? Upstream will never do that. That's why they wrote dnssec-trigger.

Comment 4 Tomáš Hozza 2015-04-01 15:46:57 UTC
Paul, I think the reason behind this idea is to have some support in Unbound itself, so we don't have to do all the hacks with /etc/resolv.conf. Although I'm not sure if it is worth it. That's why I think it should be discussed with upstream first.

Comment 5 Paul Wouters 2015-04-01 15:55:06 UTC
I personally think the hotspot detection code belongs in networkmanager, and it should have a plugin based on dnssec-trigger natively.

I understand the desire for wanting resolv.conf immutable and only pointing to 127.0.0.1 though. Perhaps that can be done differently, eg by running the insecure cache on another port and using iptables?

Anyway, feel free to talk to upstream and explain the problem.

Comment 6 Tomáš Hozza 2015-04-01 16:08:25 UTC
(In reply to Paul Wouters from comment #5)
> I personally think the hotspot detection code belongs in networkmanager, and
> it should have a plugin based on dnssec-trigger natively.

This report is not about the hotspot detection, but rather what happens after the hotspot is detected. I would agree with the NM part a year ago. Now I think it would be too much of a limitation with things like systemd-networkd happening. Also NM has already some kind of Internet connectivity detection.

> I understand the desire for wanting resolv.conf immutable and only pointing
> to 127.0.0.1 though. Perhaps that can be done differently, eg by running the
> insecure cache on another port and using iptables?

Yeah, I think we should review all the possibilities, ideally in the upstream bugzilla. I think that the less hackish the solution will be, the better.

> Anyway, feel free to talk to upstream and explain the problem.

Right, that's exactly what I think we should do.

Thanks!

Comment 7 Pavel Šimerda (pavlix) 2015-04-01 16:14:55 UTC
The basic idea behind this RFE is to modify unbound so that its non-DNSSEC features (split DNS views support basically) are retained even when dnssec-trigger disables DNSSEC (which now AFAIK only happens in hotspot signon mode) either temporarily or permanently.

If we don't have this feature, dnssec-trigger/networkmanager/unbound setup will be in some cases inferior to networkmanager/dnsmasq setup that provides the client side split DNS views unconditionally. Those cases include limited networks that don't allow you to reach any DNSSEC fallbacks.

In my opinion, if we want to run dnssec-trigger and unbound by default, we should take those cases into account. There are possible alternative approaches, so I changed the summary slightly.

It would even be possible to do it without modifying unbound by reconfiguring it accordingly upon each transition between DNSSEC and non-DNSSEC mode doing a full flush at that time, but that would go against other requirements we discussed.

(In reply to Paul Wouters from comment #5)
> I personally think the hotspot detection code belongs in networkmanager

I don't think there's any direct relation between that and this RFE. We can discuss it on a different channel.


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