Re: F23 System Wide Change: Default Local DNS Resolver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12.06.2015 18:58, Dan Williams wrote:
> On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
>> On 11.06.2015 22:48, Dan Williams wrote:
>>> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
>>>> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
>>>>> decision needs to then be made by the system. I believe that's been
>>>>> mostly due to lack of time for the various parties to sit down and
>>>>> plan and then program this further.
>>>>
>>>> We should try to make that happen.
>>>
>>> Unfortunately the Proposal doesn't say anything about how this will
>>> actually work, which is something NetworkManager needs to know.  It also
>>> fails to address the failure cases where your local DNS doesn't support
>>> DNSSEC or is otherwise broken here out of no fault of your own.
>>
>> NetworkManager is pure network configuration manager in this scenario.
>> We don't expect nor want NM to handle /etc/resolv.conf. We will only get
>> the current network configuration from it and act upon it. NM
>> configuration will contain "dns=unbound".
> 
> Correct, and I personally have no problem with this.  NM is quite happy
> to hand off DNS information wherever it has been told to do so.
> 
> But this is separate from the connectivity detection/hotspot issue which
> I think we'll discuss more below.
> 
>> The cases when local (to the network you are connected to) DNS resolver
>> does not support DNSSEC is handled by the logic in dnssec-trigger and
>> dnssec-trigger script. Unbound is always configured in a way that it is
>> able to do DNS resolution and DNSSEC validation. If this can not be
>> done, the user is informed.
> 
> Right, and that's where most of this discussion lies, I think.
> 
>>>>>> I see that there's a "hotspot sign on" option if you right click on the
>>>>>> icon. How does this work with Network Manager and GNOME's captive
>>>>>> portal detection?
>>>>> I have never seen those work except for when the backend was down and
>>>>> I got a stream of false positives. But possibly that is because I've used
>>>>> dnssec-trigger for years now and it might win the captive portal
>>>>> detection race. There are some bugs once in a while but overal it works
>>>>> pretty reliably.
>>>>
>>>> I think that's probably it — the race. The hotspot signon thing works
>>>> for me at coffeeshops. Or it did before I enabled this feature. We'll
>>>> see now!
>>>
>>> So, if you're behind a portal then unbound could potentially fail all
>>> DNS lookups.  That means that NetworkManager's connectivity detection,
>>> which relies on retrieving a URL from a known website, will fail because
>>> the DNS lookup for it was blocked by unbound.  Thus GNOME Shell portal
>>> detection will also fail.  That kinda sucks.
>>
>> If there is such situation, that Unbound fails all DNS lookups, then it
>> is a bug. This is pure theory until you have some real situation. The
>> logic is designed in a way to prevent such situations from ever happen.
>> Hotspot detection is done by dnssec-trigger. The hot-spot-signon is done
>> by putting DHCP provided resolvers into resolv.conf. So in this
>> situation Unbound it not used at all.
>>
>>> While I'm sure the dnssec-trigger panel applet works great for some
>>> people, I think the GNOME team would rather have the portal
>>> functionality in the existing GNOME Shell indicator.  There is nothing
>>> wrong with having DNSSEC enabled and part of the portal detection
>>> scheme, but the UI handling portals is clearly a desktop-specific
>>> decision.  So whatever we need to do in NM to enable the workflow that
>>> desktops need is what we'll end up doing...  Ideally the process goes
>>> like this when unbound/dnssec-trigger are installed:
>>>
>>> 1. NM connects to a new network
>>
>> 1.1. Dispatch dispatcher with the network configuration change event.
>>
>>> 2. NM updates DNS information
>>
>> NM is not expected to touch resolv.conf in the intended default
>> configuration.
> 
> My #2 was intended to be the same as your #1.1.  I was assuming
> "dns=unbound" here.
> 
>>> 3. NM waits for some signal from unbound/dnssec-trigger about the
>>> trustability of the DNS server
>>
>> If you think NM needs to do some action (as I don't), we don't have
>> problem with notifying NM (if you provide some API).
> 
> NM may need to do some action for connectivity checking.
> 
>>> 3a. if the DNS server is trusted, NM continues with its connectivity
>>> check
>>> 3b. if the DNS server is not trusted or DNSSEC is broken, then ???  How
>>> do we distinguish between "portal" and simply that your local DNS
>>> doesn't support DNSSEC or is otherwise broken, if we cannot resolve the
>>> address of the connectivity server?
>>
>> The only trusted DNS resolver is the local Unbound. The DNS resolver
>> from the network you are connected to is never trusted. It is just used
>> in case it can provide all the necessary information to do the DNSSEC
>> validation. Since using such data we are able to build the chain of
>> trust and verify that the Answer is correct, there is no point in
>> distinguishing if network provided resolver is trusted or not... it is
>> not. This is the reason we do the validation locally.
> 
> Ok, I should rephrase my question to be clearer.  NM's connectivity
> checking (which yes, does overlap in functionality with dnssec-triggers)
> will resolve a hostname and attempt to contact it.  In this "untrusted"
> state, will that hostname resolve to some address (either valid or
> spoofed from a portal), or will NM get an error response from
> gethostbyname/getaddrinfo-type calls?

How is NM doing the resolution specifically? Do you use the system stub
resolver?

When doing the connectivity checking, NM should rather query the
connection-provided DNS resolvers directly (via some other DNS library)
and not via the system stub resolver (libc) that relies on entries in
the resolv.conf.

Tomas

> Dan
> 
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                 http://cz.redhat.com
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux