F23 System Wide Change: Default Local DNS Resolver

[Tomas Hozza]

On 12.06.2015 19:17, Paul Wouters wrote:
> On 06/12/2015 12:53 PM, Dan Williams wrote:
>>> 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 fallbacks are configured in /etc/dnssec-trigger/dnssec-triggerd.conf
> 
> # Provided by fedoraproject.org, #fedora-admin
> # It is provided on a best effort basis, with no service guarantee.
> ssl443: 140.211.169.201 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2
> tcp80:  140.211.169.201
> ssl443: 66.35.62.163 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2
> tcp80:  66.35.62.163
> ssl443: 152.19.134.150 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2
> tcp80:  152.19.134.150
> ssl443: 2610:28:3090:3001:dead:beef:cafe:fed9 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64
> :AA:87:E6:F2
> tcp80:  2610:28:3090:3001:dead:beef:cafe:fed9
> 
>>> 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...
> 
> But it must be done for security reasons.
> 
>> 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.
> 
> And last I looked it did not support DNSSEC. I'm also weary about systemd-resolved basically marshalling DNS via DBUS.
> 
>> 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.
> 
> I believe we selected dnssec-trigger because it was the UI/daemon that worked. A better native integration into either
> NM or Gnome would be preferred.

I had the same idea before, but given that there is not only NM, but
also other projects that intend to do the same thing as NM and even
replace it in some environments (e.g. systemd-networkd) I don't think
it makes sense to implement the same thing in each and every of these.

I changed my mind and think that having one component implementing the
functionality and communicating with the network configuration software
that is used on the specific platform is a better approach. Although
dnssec-trigger may not be ideal as final solution, it is a good for
start and as a proof of concept of how to do client side DNSSEC
validation properly.

Tomas

> Paul
> 

-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

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