F23 System Wide Change: Default Local DNS Resolver

Wed Jun 17 11:02:11 UTC 2015

On 12.06.2015 18:53, Dan Williams wrote:
> On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek 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.
>>
>> Okay, let's start once again from scratch.
>>
>> All of this was already discussed and we even had a huge meeting around
>> DevConf and FLOCK 2014 about this, so following text will be just a short
>> refresher:
> 
> Yeah, we did.  From my recollection, most of that focused on the unbound
> parts and how NM could add the dns=unbound stuff (which Pavel
> contributed) but less on the NM connectivity checking, becuase Fedora
> hadn't turned that on by default yet.  I'm all fine with dns=unbound,
> that's not the issue.  The issue is more around what happens with NM's
> connectivity checking, since that's used by quite a few clients,
> including GNOME Shell.
> 
>> The ultimate goal
>> =================
>> Make various man-in-the-middle attacks *automatically* detectable - without
>> any user interaction. Especially we want to get rid of dialogs like "Site
>> www.gmail.com is using certificate issued for xxx.porn and certificate's
>> validity ended 10 years ago. Do you want to continue? [YES] [YES] [YES]".
>>
>>
>> Tools
>> =====
>> To achieve this goal we need to do DNSSEC validation on every client machine
>> (ignoring Docker for a moment, see below) and allow applications to use DNS as
>> trusted source of sensitive data (certificate fingerprints, SSH fingerprints,
>> etc.).
>>
>> DNSSEC allows all parties to publish their fingerprints in DNS and gives us a
>> secure way to get the data and to detect that someone prevents us from getting
>> the data.
>>
>>
>> Longer description
>> ==================
>> http://developerblog.redhat.com/2015/04/14/writing-an-application-that-supports-dnssec-in-rhel-and-fedora/
>>
>>
>> First step: DNSSEC validation
>> =============================
>> Contemporary networks are full of broken DNS proxies so we need to jump
>> through various hoops to get non-faked DNSSEC data for DNSSEC validation.
>>
>> The goal of this step is to get *cryptographical* proof that the data we
>> received are the same as DNS zone owner published.
>>
>> This includes two sub-problems:
>> a) Hot-spots:
>> Captive portal detection needs to allow user to disable all the security so he
>> can log-in but this needs to be done in a secure and reliable way so an
>> attacker cannot misuse this.
>>
>> b) Broken networks:
>> Some networks are so broken that even without captive portal they are not able
>> to deliver DNSSEC data to the clients.
>>
>> In that case will try tunnel to other DNS servers on the Internet (Fedora
>> Infra or public DNS root) and use them. Naturally, local/internal domains need
>> to be available.
> 
> While I don't actually care, this might well be a sticking point for
> many people since their DNS information is going to an untrusted (to
> them) DNS server.  Yeah, I tend to trust Fedora, but not everyone will.
> Can the tunnel be turned off, or the broken servers whitelisted, or is
> the answer here to just "dnf remove dnssec-trigger"?

The fallback infrastructure is used as the last resort of DNS data
source. Full recursion is preferred over the fallback servers.

If someone is trusting a DNS server without using DNSSEC, that that
person is not really aware of the potential security implications of
such name resolution. With DNSSEC validation done locally, it is
irrelevant what DNS servers are uses, as long they can provide all the
DNSSEC data.

It is not like Fedora infrastructure is collecting data about which user
is resolving which name. Although ANY DNS service provider can do that!

If user wants to use broken nameservers, they can switch the
dnssec-trigger to "hotspot sign-on" mode. I agree that this is
completely not intuitive and should be rather named "insecure mode".
Practically this means that the DHCP provided resolvers are placed into
resolv.conf and the user is free to shoot themselves into the feet.

Also turning off the dnssec-triggerd.service is a solution, since it
will clean up after itself and return back the system to the "original"
state. Of course you can remove it if you wish :)

>> All these sub-problems (including VPN handling an so on) are solved by
>> dnssec-trigger with tweaks by Tomas Hozza and Pavel Simerda.
>>
>>
>> HERE we need to coordinate with other parties who might want to write into the
>> /etc/resolv.conf file. These include (but might not be limited to):
>>     NetworkManager
>>     initscripts
>>     dhclient
>>     libreswan ?
>>     resolved
>>     connman
> 
> pppd, vpnc, openvpn, etc. should get added to the list since they all
> have scripts that can potentially write to /etc/resolv.conf.
> 
>> Option is either to implement all the checks and workarounds in all the
>> projects over and over or to implement all the logic in one place -
>> dnssec-trigger might be such place.
>>
>> Anyone who is going to write to resolv.conf needs to check for captive
>> portals, find a DNSSEC-enabled DNS server, and deal with VPN-provided DNS
>> servers and domains.
>>
>> *Questions:*
>> Guys, what are your plans for handling the situations mentioned above?
>>
>> Can we integrate on one place (e.g. by calling into dnssec-trigger) instead
>> overwriting /etc/resolv.conf independently?
> 
> This is the real issue.  It sounds like What you're proposing is to make
> dnssec-trigger into the "DNS broker".  The previous solutions
> (resolvconf, NetworkManager, etc) have all failed for various reasons.
> Touching/changing something so fundamental to the system, as you've
> probably discovered, can be hard...
> 
> systemd-resolved might have a chance here, since it's small and pretty
> simple, but they don't have an external API and don't seem interested in
> creating one any time soon which severely limits it's usefulness.

systemd-resolved plans to do just a kind of "best effort" DNSSEC, at
least from what I asked on the Linux PLumbers Conference in Dusseldorf
last year on the Tom Gundersen's presentation. This means they will do
the validation, but only if they are able to. They don't plan and don't
want to do any fallback to external infrastructure, but rather want to
turn off the validation. I'm not sure if this is still the case, but it
was. This is exactly what we don't want to do with dnssec-trigger and
Unbound. We will try really hard to do DNSSEC validation.

> If this is indeed what you're proposing, then lets have a discussion
> about dnssec-trigger+unbound in that context, I do have some thoughts to
> contribute here.

Good, we are open to thoughts and ideas ;)

> ----
> 
> The third part of the problem, unrelated to your "API for Applications"
> is the actual hotspot sign-on and connectivity detection issue.  I think
> that's getting discussed in other replies though.

I agree.

Tomas

> Dan
> 
>> Second problem: API for applications
>> ====================================
>> (this second step is not part of the F23 feature but it is worth discussing)
>> Applications and crypto libraries need "an" interface to get DNS data which
>> are either 100 % correct or declared as not trusted. False positive (trusted)
>> answers are simply unacceptable because that would allow serious attacks.
>>
>> Imagine that OpenSSH client is verifying server's fingerprint against the
>> value obtained from DNS *instead of asking the user*. If the client accepted a
>> fake response with faked server's fingerprint then everything is doomed.
>>
>>
>> The proposal https://sourceware.org/ml/libc-alpha/2014-11/msg00426.html on
>> glibc mailing list is to extend getaddr API with flag which says 'secure
>> answers only'. This will return an answer only if DNSSEC validation for given
>> answer was successful and the answer was properly signed.
>>
>> The assumption here is that something like dnssec-trigger properly configures
>> local resolver (using the information from DHCP + applying all the necessary
>> workarounds) to do DNSSEC validation locally so we are 100 % sure that the
>> fake answer can be detected.
>>
>> The open question is how to pass the information about security status to all
>> the parties. The mechanism needs to be simple so other resolver libraries like
>> e.g. python-dns can follow the same rules and use the same logic as Glibc.
>>
>> Possible states:
>> a) We are in hot-spot sign-on mode or validating resolver is unavailable for
>> some reason (early boot, resource constraints, Docker container [finally!],
>> and so on):
>>
>> In this case *nothing* can be trusted. Resolver might return faked answers and
>> we have no means to check if declared trustworthiness is correct or not.
>> Again, we need to be 100 % sure from the cryptographical point of view.
>> => Application MUST NOT receive any answer marked as "secure"/"trusted" if we
>> are in this mode.
>>
>>
>> b) Validating resolver is up, running, properly configured, and the path to
>> the resolver is trusted - it might be running on localhost or we are in Docker
>> container and we trust the host and so on.
>>
>> In this case we trust to the result of validation indicated by AD bit.
>> Application will receive the answer marked as trusted if the resolver tells us
>> to do so by AD bit in the DNS reply.
>>
>> Please read the post on Glibc mailing list for more details.
>>
>> Any suggestions how to do that are more than welcome!
>>
>> -- 
>> Petr Spacek  @  Red Hat
> 
> 
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                 http://cz.redhat.com