DevHeads.net

F24 System Wide Change: Default Local DNS Resolver

= Default Local DNS Resolver =
<a href="https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver" title="https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver">https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver</a>

Change owner(s):
* P J P <pjp AT fedoraproject DOT org>
* Pavel Šimerda <pavlix AT pavlix DOT net>
* Tomas Hozza <thozza AT redhat DOT com>
* Petr Špaček <pspacek AT redhat DOT com>

Plain DNS protocol is insecure and therefore vulnerable from various
attacks (e.g. cache poisoning). A client can never be sure that there
is no man-in-the-middle, if it does not do the DNSSEC validation
locally.
We want to have Unbound server installed and running on localhost by
default on Fedora systems. Where necessary, have also dnssec-trigger
installed and running by default. Unbound and dnssec-trigger will be
properly integrated with the default network configuration manager
(e.g. NetworkManager for Fedora Server and Workstation) and with the
graphical user interface (especially GNOME). The localhost address
will be the only record in /etc/resolv.conf and no other software
except dnssec-trigger will be allowed to change its content.

== Detailed Description ==
Plain DNS protocol is insecure and therefore vulnerable from various
attacks (e.g. cache poisoning). DNSSEC is a DNS extension which
enabled the client to verify the DNS query response and make sure
there is no attacker to spoof some records. A user connected to
network usually receives a set of resolvers from DHCP, which should be
used for name resolution. These resolvers may also do the DNSSEC
validation. However a client can never be sure that there is no
man-in-the-middle, if it does not do the DNSSEC validation locally.
Purpose of this Fedora change is to have a validating DNS resolver
installed on Fedora systems by default. This includes necessary
discussions, coordination and integration with other components
installed on Fedora by default.

There are growing instances of discussions and debates about the need
for a trusted local validating DNS resolver. There are multiple
reasons for having such a resolver, most importantly security and
usability. Security and protection of user's privacy becomes paramount
with the backdrop of the increasingly snooping governments and service
providers world wide.

People use Fedora on portable/mobile devices which are connected to
diverse networks as and when required. The automatic DNS
configurations provided by these networks are never trustworthy for
DNSSEC validation, as currently there is no way to establish such
trust.

Apart from trust, these name servers are often known to be flaky and
unreliable which only adds to the overall bad and at times even
frustrating user experience. In such a situation, having a trusted
local validating DNS resolver not only makes sense but is, in fact,
badly needed. It has become a need of the hour. (See: [1], [2], [3])

All DNS literature strongly recommends it and amongst all discussions
and debates about the issues involved in establishing such trust, it
is unanimously agreed upon and accepted that having a trusted local
DNS resolver is the best solution possible. It will simplify and
facilitate a lot of other design decisions and application development
in the future. (See: [1], [2], [3])

[1] <a href="https://www.ietf.org/mail-archive/web/dane/current/msg06469.html" title="https://www.ietf.org/mail-archive/web/dane/current/msg06469.html">https://www.ietf.org/mail-archive/web/dane/current/msg06469.html</a>
[2] <a href="https://www.ietf.org/mail-archive/web/dane/current/msg06658.html" title="https://www.ietf.org/mail-archive/web/dane/current/msg06658.html">https://www.ietf.org/mail-archive/web/dane/current/msg06658.html</a>
[3] <a href="https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html" title="https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html">https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html</a>

== Scope ==
Proposal owners: Proposal owners shall have to
* define the syntax and semantics for new configuration parameters/files.
* properly document how to test and configure the new default setup
* persuade and coordinate with the other package owners to incorporate
new changes/workflow in their applications.
* discuss with WGs in which products the change makes sense and what
are the expectations of WGs for different Fedora products
* resolve interoperability issues for Docker and other containers use-cases

Other developers: (especially NetworkManager and the likes)
* NetworkManager has to implement notifications on connectivity state changes
* Gnome Shell has to use the connection provided resolvers (fetched
directly from NM) for Hot-Spot login purposes
* Ideally other developers and user should test their software and
application in this setup and verify that it is working as expected

Release engineering:
* Make sure that the necessary packages (dnssec-trigger, unbound) are
part of the composes for the appropriate Fedora Products.
* Add services needed for the setup into the default presets
(dnssec-triggerd.service)

Policies and guidelines:
* Any software, including NetworkManager, will have to be configured
to not tamper with the content of '/etc/resolv.conf' by default. The
connection-provided resolver entries should be stored in a separate
configuration file or in memory and accessible via some API.

Comments

Re: F24 System Wide Change: Default Local DNS Resolver

By Florian Weimer at 12/05/2015 - 12:57

On 11/30/2015 05:14 PM, Jan Kurik wrote:
Would someone please clarify the proposal if Unbound would run as a
forwarder, or as a stand-alone recursive resolver?

Thanks,
Florian

Re: F24 System Wide Change: Default Local DNS Resolver

By Tomas Hozza at 12/07/2015 - 04:15

On 05.12.2015 18:57, Florian Weimer wrote:
It depends on the network. If the resolvers from the DHCP are usable
for DNSSEC, then these will be used as forwarders. Nevertheless, Unbound
does the validation locally, so it will query for all the necessary
data to build the chain of trust.

In case the network-provided resolvers are not usable for DNSSEC, then
Unbound is configured to do the recursion.

In case this is blocked on the network, Unbound is configured to tunnel
the DNS queries to Fedora public infrastructure over TCP (80, 443) or
SSL (443), in which case this is similar to the first situation, when
Unbound forwards queries to the resolvers, but does the validation
locally.

This is part of dnssec-trigger documentation, since it is used as the
mean to reconfigure Unbound.

Tomas

Re: F24 System Wide Change: Default Local DNS Resolver

By Lennart Poettering at 12/07/2015 - 06:39

Ahum. This is another deal-breaker. It's really wrong to simply ignore
local DNS servers. Just because my local company DNS server doesn't do
DNSSEC it's in *no way* OK to make it impossible for me to resolve
local names.

You *have* to use the local DNS servers by default, even if they are
crap. If you don't you break pretty much half of the setups. For
example, with such a Fedora installation I couldn't even print anymore
in my local network, I couldn't access my NAS anymore, and not
reconfigure my router. I couldn't connect to stereo's internal web
page, and neither to my internet radio's internal web page. And that's
just my little home network. In a company network it's *way* worse...

It's completely OK to gracefully degrade to non-DNSSEC DNS if the
local DNS server cannot do it. Sure the APIs shouldn't claim it was
safe, but that's about it.

The idea of forwarding DNS queries to Fedora servers sounds completely
non-sensical to me... Given the port numbers I assume that's even
HTTP?

Do you really think that Fedora is capable and willing to handle all
that traffic? Are you aware of the infrastructure Google is investing
to keep that 8.8.8.8 server up and running? Even if Fedora user's are
a tiny tiny fraction of the number of 8.8.8.8 users, the processing
power it takes for dealing with HTTPS requests is a multitude of what
the 8.8.8.8 requests take...

DNS and DNSSEC are designed to scale, with all its caching,
forwarding, offline signing and so on. By then pushing the whole
traffic through HTTPS you completely trash all that...

It would be good to mention this in the feature page.

Lennart

Re: F24 System Wide Change: Default Local DNS Resolver

By Paul Wouters at 12/07/2015 - 15:08

You can't, thanks to hotels and coffeeshops.

If your DHCP supplied DNS servers work, then these will be used as
forwarders, and you can have your own zone, provided you are not
squatting on the namespace of someone else and it will work fine.

This feature should not affect .local, so you should be able to find
your printer fine?

If you use your own domain name for that, all of it will still work. And
even without FQDN if you put the right search domains in DHCP.

No it is not. coffee shop, hotel network......

No it is raw DNS on port 80.

The fedora DNS servers are a "last ditch" effort. If that is needed in
your network, you have accumulated several deficiencies you should fix:

- don't use broken DNS servers (in other words, yum|dnf update on your dns
server)
- don't block port 53 to the internet
- don't screw up UDP 53 fragments or TCP port 53, or drop >512byte DNS
packets

If you do all of that, you deserve broken DNS, and I only feel sorry
that house of cards did not come down sooner to help you.

It is expected to be extremely rare this is needed. When the IETF drafts
for DNSoverTLS are implemented (eg on 8.8.8.8) we suspect it will never
be needed again.

It's TLS without any validation. It's just to get through stupid
networks blocking legitimate traffic AND having a DNSSEC-broken
(years old!) DNS server running.

It should never happen on networks that normal people build.

Paul

Re: F24 System Wide Change: Default Local DNS Resolver

By =?iso-8859-1?q?... at 12/07/2015 - 09:31

Lennart Poettering < ... at 0pointer dot de> wrote:
I for one want my laptop to be suspicious of random DNS servers it
encounters in public places, and bypass them if they're found to be
lying.

I also want to be able to make an exception in case I'm visiting a
misconfigured network and really need to access some internal server.

It seems to me that the system needs to ask the user whether they are
in a public hotspot that they're using only as a way to access the
Internet, or whether they're visiting a friend and want to access
internal servers. I don't see a way to tell the difference reliably
without any user interaction.

The port numbers are obviously chosen to get through overzealous
firewalls. All too often everything except TCP port 443 is blocked or
tampered with. It is certainly far from ideal, which is why it's right
to do it only as a last resort when all other ways are blocked.

Björn Persson

Re: F24 System Wide Change: Default Local DNS Resolver

By Lennart Poettering at 12/07/2015 - 14:35

Well, if you are knoweledgeable enough to understand the problem, then
you hould also be able to install/configure dnssec yourself. But I am
pretty sure that the typical user is neither knowledgeable enough
about this to make the decision, nor does he really care...

As I understood the feature was posted to make something the default
in Fedora, and I am just concerned about that new default.

I think that would be pretty bad UI. You shouldn't ask users questions
they likely won't grok. In fact, you better shouldn't ask users
technical questions at all...

Lennart

Re: F24 System Wide Change: Default Local DNS Resolver

By Petr Spacek at 12/08/2015 - 04:39

On 7.12.2015 20:35, Lennart Poettering wrote:
Lennart, you could find more information in the Fedora change page:
<a href="https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/Design#Broken_networks" title="https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/Design#Broken_networks">https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/Design#B...</a>

As you might see, we were thinking about this hard and actually made attempted
to make it interaction-less.

In short, public/fallback DNS servers will be used to detect if part of DNS
sub-tree (like home.lennart.me) is unsigned. If the sub-tree is unsigned the
query will be re-send to local servers and returned to the client.

The assumption here is that if your domain is signed you have enough wisdom so
use DNSSEC-enabled resolvers in your network. If the domain is not signed we
will trust the crappy local servers.

Re: F24 System Wide Change: Default Local DNS Resolver

By =?iso-8859-1?q?... at 12/07/2015 - 16:10

Lennart Poettering < ... at 0pointer dot de> wrote:
You are right about the typical user. This is what happens to the
typical user as a result:

<a href="http://swiftonsecurity.tumblr.com/post/98675308034/a-story-about-jessica" title="http://swiftonsecurity.tumblr.com/post/98675308034/a-story-about-jessica">http://swiftonsecurity.tumblr.com/post/98675308034/a-story-about-jessica</a>

Is it Jessica's fault that she doesn't know what a DNS server is, or
that it can lie to her? Is it her fault that she has never heard about
DNSsec, or PGP, or OPENPGPKEY records? Is it her fault that her email
program doesn't bring those pieces together to authenticate incoming
mail?

Or do we programmers have some responsibility to provide Jessica with
software that at least tries to keep her secure?

Björn Persson

Re: F24 System Wide Change: Default Local DNS Resolver

By Randy Barlow at 12/01/2015 - 10:59

This sounds overall pretty neat to me! One detail came to my mind: how
would this interact with VPN DNS servers? In my experience with VPNs,
it's common for them to provide a DNS server that allows internal host
resolution to work. Would this local resolver be notified by NM of a new
VPN connection so that it knows to use the VPN-provided DNS server for
hosts on that particular domain, rather than the usual external records
for that same domain?

Re: F24 System Wide Change: Default Local DNS Resolver

By =?ISO-8859-1?Q?... at 12/07/2015 - 09:56

On 01/12/15 15:59, Randy Barlow wrote:
That split DNS setup has been working well for me since Fedora 21,
which I enabled using:

dnf install crudini
crudini --set /etc/NetworkManager/conf.d/99-split-dns.conf main dns dnsmasq

Details of that setting are in man NetworkManager.conf
Not sending general DNS queries over the VPN
improves speed and avoids stalls when the VPN drops.

cheers,
Pádraig

Re: F24 System Wide Change: Default Local DNS Resolver

By Reindl Harald at 12/07/2015 - 10:02

Am 07.12.2015 um 15:56 schrieb Pádraig Brady:
depends on the VPN - if my company VPN drops i have to take a taxi
anyways because it only drops when houston has a problem

given we have some hundret domains the whole point of the VPN is working
from home the same way as if i would be in the office and make *anything
which is possible* through the DHE-4096 connection and avoid as much as
possible network contact bypassing the tunnel

Re: F24 System Wide Change: Default Local DNS Resolver

By Paul Wouters at 12/01/2015 - 11:45

Yes, this already works in most VPN implementations shipped with Fedora.
(libreswan/IPsec, vpnc/IPsec, openvpn, and probably openconnect)

For IPsec, that support will be extended for IKEv2 in the future too,
see <a href="https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/" title="https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/">https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/</a>

The running unbound DNS server will be told to "forward" certain domains
to certain IPs of nameservers received during the VPN negotiation. It
will remove the forward when the VPN connection goes down. And for those
domains, the cache is flushed on each event too, to prevent using stale
data that is only used when the VPN is up (or down)

Paul

Re: F24 System Wide Change: Default Local DNS Resolver

By =?ISO-8859-1?Q?... at 12/01/2015 - 03:14

If I am not mistaken, this is at least 3rd time this change is proposed.
Can somebody post some short summary what was changed, that you believe
it will be successful this time?

Thx

Vít

Dne 30.11.2015 v 17:14 Jan Kurik napsal(a):

Re: F24 System Wide Change: Default Local DNS Resolver

By Tomas Hozza at 12/01/2015 - 05:15

You are not mistaken.

This is the third time, because previously we rather moved the change to the
next Fedora to bring better user experience. Every time there was something
enhanced, since we learned a lot about user use-cases, so this is definitely
not the same change as before, only the root idea is the same. The Change Wiki
is up-to-date and contains the current information.

Also with many projects involved - Gnome Shell, NetworkManager, Unbound,
dnssec-trigger, SELinux (always a pleasure:), Docker... it is not the easiest
thing to agree on changes and coordinate everything on time.

What changed from the top of my head:
- We decided not to install the dnssec-trigger panel by default and rather
better integrate dnssec-trigger with NM and Gnome Shell
- We decided not to query user for security decisions, and for the beginning
if there is no other option just fall back to the current state that that is
in Fedora today
- better handling of environments, where the resolvers on the network don't
support DNSSEC by new Unbound plugin. This is still not in upstream, since
we wanted to get the algorithm to the RFC draft that is currently discussed
on IETF WG (<a href="http://www.ietf.org/id/draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt" title="http://www.ietf.org/id/draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt">http://www.ietf.org/id/draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt</a>)
- dnssec-trigger does not do the Captive Portal detection and handling and
we rather rely on NM for the detection and on Gnome Shell for the Portal login
- Some enhancements of the portal helper in Gnome Shell are being reviewed,
(it will not rely on the resolv.conf content and rather use sandboxed environment
with resolv.conf containing resolvers for the connection from NM).

If you check the "decisions made" part of the change wiki, it discusses
the important outcomes of discussions.

Some of these things are not polished, implemented or merged upstream yet,
but we are working on them with the F24 schedule in mind. We are also
communicating with NM and Gnome devels and will discuss the defaults with
WGs with some Product, once FESCo approves the change.

Regards,
Tomas

On 01.12.2015 09:14, Vít Ondruch wrote:

Re: F24 System Wide Change: Default Local DNS Resolver

By Lennart Poettering at 12/04/2015 - 09:57

So, here's a question: in germany "Fritzbox" wifi routers are very
popular. Their configuration page is reachable under the "fritz.box"
pseudo-domain from inside their wifi network, and all other systems on
the network are also eachable below this domain under their
DHCP-configured hostnames. It implements a DNS proxy otherwise, only
synthesizing A/AAAA RRs for *.box. Now, one can certainly argue that
this is borked, since the manufacturer doesn't own the ".box" domain,
but discussing this is pretty pointless, as the fact that this is what
is deployed in probably half of the homes in Germany... Also I am
pretty sure other routers form other manufacturers do the same
thing. Now, if we default to DNSSEC validation soon, does this mean
people won't be able to configure their wifi routers anymore, or reach
other systems on their home networks anymore, because the NSEC/NSEC3
RRs in the root domain claim .box does not exist? What's your
strategy there? Why do you think DNSSEC is worth breaking pretty much
everybody's network? Note that Fritzbox is not a random crappy router,
it's probably of the better products you can find.

How do other popular desktop/consumer OSes deal with this? Windows,
MacOS, iOS, Android, ChromeOS? Does any of them do client-side DNSSEC
validation by default and how are they dealing with this issue?

Lennart

Re: F24 System Wide Change: Default Local DNS Resolver

By =?iso-8859-1?q?... at 12/07/2015 - 09:30

Lennart Poettering < ... at 0pointer dot de> wrote:
I wonder what they were planning to do the day somebody registers box.

Björn Persson

Re: F24 System Wide Change: Default Local DNS Resolver

By Tomas Hozza at 12/07/2015 - 04:48

On 04.12.2015 15:57, Lennart Poettering wrote:
As you've said, this is basically an attack and hijacking of someone's
else domain name space. It is not correct and it is not expected that
this will work with DNSSEC.

Now, we realized some time ago, that there are situations where the
local network-provided resolvers should be used to some extent, even
if they don't support DNSSEC. We think that such resolvers could be
used for INSECURE or INDETERMINATE answers and requeried. This would
allow you to use the local resources from the network.

Obviously this would not work with TLDs, since the root zone is signed
and therefore you should never get an INSECURE answer for TLD. The same
for any non-existing subdomain of a signed domain, etc.

The mechanism of using the network provided resolvers is something
we were trying to get into the "DNSSEC roadblock avoidance" IETF
RFC draft [1]. We have an experimental "mixed-mode" [2] module for Unbound,
however it is still not in upstream, because we were waiting for the
algorithm to get into the RFC draft.

I think we could extend the module with an option to configure list of domains
for which you would like to fallback to the local resolvers, even if the
answer was SECURE. This could be used for the non-existing or "abused" TLDs.
Note that IETF is thinking about reserving some of such domains as private [3],
so once it is standardized, it could be done for these automatically.

Our use of the mixed-mode module expects, that the network-provided resolvers
are not DNSSEC capable. This means, that in a situation when the network-provided
resolvers are determined to be DNSSEC capable (based on some set of tests), but
then they return BOGUS answers, e.g. claiming that there is a TLD, but can not provide
the signatures, Unbound would most probably return SERVFAIL.

I'm not sure if this is the case with the German ISP's-provided routers.

I don't think there is any universal or even right solution to this. Once you
start doing such hacks, there is a very thin line when you are starting to degrade
the security gained by using DNSSEC.

So the answer is that it could be doable for some cases and if the user
explicitly specifies some set of domains. However I don't think this will
solve all the issues with ISP's and hardware vendors trying to be smart
while actually breaking the RFCs and hijacking the domain name space.

I'm not able to answer this question.

[1] <a href="http://www.ietf.org/mail-archive/web/dnsop/current/msg16208.html" title="http://www.ietf.org/mail-archive/web/dnsop/current/msg16208.html">http://www.ietf.org/mail-archive/web/dnsop/current/msg16208.html</a>
[2] <a href="https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/UnboundMixedMode" title="https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/UnboundMixedMode">https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/UnboundM...</a>
[3] <a href="http://www.ietf.org/mail-archive/web/dnsop/current/msg16209.html" title="http://www.ietf.org/mail-archive/web/dnsop/current/msg16209.html">http://www.ietf.org/mail-archive/web/dnsop/current/msg16209.html</a>

Regards,

Re: F24 System Wide Change: Default Local DNS Resolver

By Debarshi Ray at 12/09/2015 - 13:04

On Mon, Dec 07, 2015 at 10:48:55AM +0100, Tomas Hozza wrote:
That is troubling. :(

Since this is likely to break networking on a lot of client-side
systems, I would have expected you to do this research before
submitting it as a System Wide Change.

Cheers,
Rishi

Re: F24 System Wide Change: Default Local DNS Resolver

By Paul Wouters at 12/09/2015 - 13:37

On 12/09/2015 01:04 PM, Debarshi Ray wrote:
We did. We are the First at undertaking this at an OS level. If the others
proceed they will run in the exact same issue. The problem of broken and
badly designed DNS setups is, is that they only go away when it finally
breaks down.

Paul

Re: F24 System Wide Change: Default Local DNS Resolver

By Jiri Eischmann at 12/11/2015 - 11:25

Paul Wouters píše v St 09. 12. 2015 v 13:37 -0500:
I'm glad to see Fedora being a pioneer in network security among OSes,
but I'm not sure if pioneering something that will bring a lot of
disruption into lives of our users is something Fedora can afford.
Yes, insecure local DNS servers is a problem, but it's the kind of
problem only market leaders can effectively crack. If Windows or
Android stopped working with those DNS servers there would be complains
from users, but there would also be enough pressure to fix it.
Fedora is not relevant enough to make such pressure, and I don't think
we're relevant enough to motivate the "big guys" to jump on the wagon
right after us.
So my worry is that we would be an OS which is more secure than others,
but doesn't work in many networks. You can bet what the users would
decide for...

Jiri
 

Re: F24 System Wide Change: Default Local DNS Resolver

By Oron Peled at 12/09/2015 - 18:02

On Wednesday 09 December 2015 13:37:12 Paul Wouters wrote:
OK, but currently it's hard to estimate the amount of real-world breakage.

E.g: if 90% of user setups will break -- the backlash would damage not only Fedora,
but also DNSSEC adoption.

Why don't we plan this feature in two stages:
* Fedora 24: turn it on by default, but *keep using results* from bad DNS servers,
just issue a user-visible warning, possibly with a link to a page with friendly
explanation and suggestions for further action.

* Fedora 25: we would have much better view of the amount and types of failures
in real world (from F24). This would enable to improve/fine-tune the ways
to handle problematic use-cases.
So at that stage, we may ship DNSSEC as "fail-bad-DNS-servers-by-default".

Make sense?

Re: F24 System Wide Change: Default Local DNS Resolver

By Paul Wouters at 12/11/2015 - 09:09

DNS lookups don't have users like web browsers.

I have been running this setup since Fedora 17. Breakage is not that bad.

Paul

Re: F24 System Wide Change: Default Local DNS Resolver

By Oron Peled at 12/12/2015 - 21:11

On Friday 11 December 2015 09:09:28 Paul Wouters wrote:
I'll answer both Paul and Reindl which replied "there's no safe and clean way to solve that"...

First, that's only partially correct:
* The client (resolver) normally *does* have a user (the uid of the process calling the resolver library).
* But after that, your are correct that the caller identity is gone.

Still, IMO, the goal to warn users can be achieved quite easily. Two examples from the top of my head.
1. log + notify:
* The information may be logged with special prefix (or special field via sd-journal).
* Users would have a small desktop service that would monitor for these messages and notify about them.

2. dbus:
* The local DNS server would send specific DBUS signal (e.g: net.dnsseq.InsecureDNSReply).
* A desktop process would listen on these signals and show proper desktop notification.

BTW: SELinux failures may also be found in non-desktop-user context, but still the desktop user
can receive warnings about them.

Hmmm... even if all of us, fedora-devel subscribers, would run this
it's still a far cry from a full release cycle of Fedora:

* large-numbers: millions of machines would reveal much more varied use-cases
than what a 500-1000 machines of "fedora-devel" people can show.

* I suspect Fedora developers are very different from Fedora users (like
developers/users in other technologies), so we are bound to miss important
use-cases.

So my hunch feeling is still: make F24 with DNSSEC by default, but not
"enforcing". Than, F25 will enforce DNSSEC validation.

Re: F24 System Wide Change: Default Local DNS Resolver

By Paul Wouters at 12/14/2015 - 09:34

On 12/12/2015 09:11 PM, Oron Peled wrote:
You can do that logging using tools like dnssec-system-tray pointing to the unbound log file.

But these solutions can quickly become a denial of service through popups.

the problem with bad DNS deployments is that it keeps becoming a bigger house of cards until
it actually fails to work, similarly how raided disks that write a log message that one of the
two disks is failing usually gets found when the second disk failed.

google dns, verisign dns and many large DNS deployments already validate and break setups of
people using 8.8.8.8 manually. We've gone out of our way to try and be nice to existing DNS
deployments, but at some point you got to treat the wound, cause some pain and fix things.

That just postpones the hurt for 6 months. We've already had a few of these cycles. As I said,
I run this since fedora 17.

Really, the biggest issue people fear is their split view DNS. Which is easilly solved by extending
the concept of firewalld zones into Network Manager, and always use broken DNS forwarders on
"trusted networks".

Paul

Re: F24 System Wide Change: Default Local DNS Resolver

By Oron Peled at 12/14/2015 - 16:26

On Monday 14 December 2015 09:34:56 Paul Wouters wrote:
IMO, the question is not if I can do that (or others on Fedora-devel mailing list).
It's if we can have such a warning setup be the *default* for end-users in Fedora-24.

Good point, but that could be mitigated at both ends:
* The local DNS server can apply a "rate-limit" for these DBus signals.
* Also, the display don't have to use desktop "notifications".
Alternatively, it can be implemented as a single process that listen to
these signals and show one popup with minimal info (global warning,
with a possible list of latest problematic domains).

Those DNS deployments are good for general DNSSEC technology validation.

They have nothing to do with the problem I pointed:
* They do not test the crazy DNS world *inside* NAT'ed networks.
* In these private networks is where most bad DNS setups exists.
* This is the environment that the new Fedora DNS setup will likely encounter.

factoid: In a medium corporation I know (few thousands desktops/servers across ~5 timezones),
they still use internal domains like "foobar.local" (which practically kill
great technologies like mDNS).
This is pretty obvious as "<something>.local" was considered *best-practice*
by some Microsoft Active Directory setups when this corporation was small.

I agree, but still think doing it in *two steps* would be beneficial for both
Fedora and DNSSEC.

First make it default and analyze the backlash (which won't be fatal, as it's only warnings)
Than make it "enforcing" and force the pain (after you already have clear
notification mechanisms that are *familiar* to the end-users).

As I said -- "you" (or me) running it for some time is nothing like few million Fedora users.

My proposal does not "just postpone" -- Let's make it Fedora-24 default,
but *warn* about bad replies instead of *rejecting* them -- this would give us
valuable information.

Hmmm... "easily solved" is not "solved":
* Has this "biggest issue" really been solved? Do we have this NM integration?
Does it show in "nm-applet" (I avoid bringing up KDE which I personally use,
or other desktops)
* What other issues we don't know, simply because this Fedora setup hasn't been *widely* deployed?

Thanks,

Re: F24 System Wide Change: Default Local DNS Resolver

By Paul Wouters at 12/14/2015 - 17:38

All these dnssec validation errors would be equally invisible if the system used 8.8.8.8 because google would also ServFail these since they do DNSSEC.

The only simple solution here is the "trusted network zone" where the user explicitly
states they trust their local server. This is something NetworkManager should expose
to the user - possibly on first connect.

I have no problem breaking those kind of setups.

20 years of DNS has taught me no one ever fixes any DNS until it is causing an outage.

People will click away the warnings until they upgrade to F-25.

I don't know. I don't think the integration with firewalld/NM uses the same concept of "zones".

I'd be more sympathetic to this if we haven't gone through major things like /usr move already :P

Paul

Re: F24 System Wide Change: Default Local DNS Resolver

By Neal Becker at 12/15/2015 - 19:00

The split-dns case is I believe what I have at work. I did test the
proposed local dns resolver. I was able to resolve names of machines
internal to my work network (after some workaround), but when I needed to
connect to a machine with a different domainname, and it wasn't resolved,
and I needed that to do my timesheet, I reverted.

Using firewalld is not a perfect solution either, if that's the suggestion.
My machines are configured to use iptables. I have a perfectly good working
iptables setup, and found firewalld looked like it had too much learning
curve, so I don't use it.

Re: F24 System Wide Change: Default Local DNS Resolver

By Reindl Harald at 12/11/2015 - 09:19

Am 11.12.2015 um 15:09 schrieb Paul Wouters:
and there is *no* safe and clean way to solve that

since it's the DNS server it *could* return in such case a dedicated IP
to a site which accepts every host header and explains what have
happened - BUT that won't work with HTTPS sites, they wuld end just in
another warning AND NO don't come with the idea install a Fedora
certificate like Dell did it short ago

the problem here is that the browser would send it's cookies from
previous visits there so it's not possible for security/privacy reasons
and since DNS don't cover ports there can also not be a tiny process on
the local machine with a embedded webserver easily, the user could have
run it's own webserver which must not be replaced

Re: F24 System Wide Change: Default Local DNS Resolver

By Petr Spacek at 12/10/2015 - 07:23

On 10.12.2015 00:02, Oron Peled wrote:
It certainly makes sense, and if read

<a href="https://fedoraproject.org/w/index.php?title=Changes/Default_Local_DNS_Resolver" title="https://fedoraproject.org/w/index.php?title=Changes/Default_Local_DNS_Resolver">https://fedoraproject.org/w/index.php?title=Changes/Default_Local_DNS_Re...</a>

and pages linked from

<a href="https://fedoraproject.org/w/index.php?title=Changes/Default_Local_DNS_Resolver#Documentation" title="https://fedoraproject.org/w/index.php?title=Changes/Default_Local_DNS_Resolver#Documentation">https://fedoraproject.org/w/index.php?title=Changes/Default_Local_DNS_Re...</a>

you will find yourself that that is basically what we intended to do, with few
tweaks.

Re: F24 System Wide Change: Default Local DNS Resolver

By Fabio Locati at 12/09/2015 - 13:30

2015-12-09 19:04 GMT+01:00 Debarshi Ray <rishi. ... at lostca dot se>:
As far as I've seen, no Operating System today ships client-side
DNSSEC validation. Some ISP (like Comcast since 2012) perform DNSSEC
validation on their DNS servers, as well as some public DNS (like
Google DNS) perform them.

Fabio

Re: F24 System Wide Change: Default Local DNS Resolver

By Paul Wouters at 12/07/2015 - 13:21

Well, there is going to be a very interesting lawsuit about damage then
because in a few months .box will be live run by a Hong Kong company
called "NS1 Limited"

<a href="https://www.icann.org/resources/agreement/box-2015-11-12-en" title="https://www.icann.org/resources/agreement/box-2015-11-12-en">https://www.icann.org/resources/agreement/box-2015-11-12-en</a>

.box Registry Agreement

12 Nov 2015

On 12 November 2015, ICANN and NS1 Limited, entered into a Registry
Agreement under which NS1 Limited, operates the .box top-level domain. [....]

Clearly, fedora cannot be changed to hijack a real domain, so Fritzbox better
solve this quickly with an update, even if no one actually will update their
router :(

We can make some web page available that will explain how to configure unbound
with an override, but I guess it will be a different IP for everyone? Assuming your
fritz.box is 192.168.1.1 you can do:

echo ' local-data: "fritz.box. 3600 IN A 192.168.1.1"' > /etc/unbound/local.d/fritz.box.conf

Of course you can also use /etc/hosts

Also I am
Don't they work when you use <a href="http://192.168.1.1/" title="http://192.168.1.1/">http://192.168.1.1/</a> ?

What's your
See above. It's going to get broken anyway. Actually, this could be a security nightmare
if someone registers fritz.box and will start receiving connections for IP address that
give them their router passwords!

That only works if .box is not delegated. Unfortunately, it will be very soon.

Initially it will resolve to 127.0.53.53 when the TLD is brought up. So hopefully
that will cause people to safely see the failure mode. Only after the domain has
launched fully will someone be able to possibly register fritz.box maliciously.

Actually DNS servers will either fail those queries, or they will be targeted
at the global blackhole running via AS112

Worse, we open up ourselves for legal issues if the domain is delegated.

It will start failing for people irrespective of DNSSEC.

Paul

Re: F24 System Wide Change: Default Local DNS Resolver

By Florian Weimer at 12/07/2015 - 15:08

Ah, nice.

Well, AVM could just register fritz.box and leave it unsigned, which
solves the problem for us.

Florian

Re: F24 System Wide Change: Default Local DNS Resolver

By Paul Wouters at 12/07/2015 - 15:40

If my fritz.box is 192.168.1.254 and yours is 192.168.1.1, what would
you want the AVM registered domain fritz.box to return as A record?

One of us will break regardless, unless the fritz box hijacks all port
53 to push it through its preprocessor its fake .box domain.

Paul

Re: F24 System Wide Change: Default Local DNS Resolver

By Florian Weimer at 12/08/2015 - 03:30

On 12/07/2015 09:40 PM, Paul Wouters wrote:
The public DNS would return NODATA.

Okay, AVM would also have to fix their boxes not to strip RRSIG records,
so that Unbound's fallback mechanism would become unnecessary. (It was
said earlier on this thread that Unbound would use the DNS servers
received over DHCP as forwarders if possible.)

Florian

Re: F24 System Wide Change: Default Local DNS Resolver

By Reindl Harald at 12/07/2015 - 15:42

Am 07.12.2015 um 21:40 schrieb Paul Wouters:
* typically this devices act as DNS for the LAN
* fritz.box != *.box
* hence your or his IP don't matter

Re: F24 System Wide Change: Default Local DNS Resolver

By Andrew Lutomirski at 12/07/2015 - 10:44

On Dec 7, 2015 1:49 AM, "Tomas Hozza" < ... at redhat dot com> wrote:
Can you elaborate a bit? Is the intent that, if .box were private, then
.box would be forwarded to DHCP-provided revolvers regardless of whether
those resolvers were functional when asking for DNSSEC signature data?

If so, what cases does this not cover? It fails in the split-horizon
DNSSEC-enabled case where the domain owner hasn't set it up right, but I'd
argue that that's a good thing.

--Andy

Re: F24 System Wide Change: Default Local DNS Resolver

By Tomas Hozza at 12/07/2015 - 11:23

On 07.12.2015 16:44, Andrew Lutomirski wrote:
I think that explicit list of domains would cover pretty much any use-case. We were thinking about configuring the mixed-mode module with local resolvers only in case these are not DNSSEC-capable. In such situation everything would work fine. However if the local resolvers are DNSSEC-capable, then we would not configure the mixed mode module with them and I such case the validation would simply fail for any faked TLD. So we would have to configure mixed-mode module with local resolvers in any case. I guess it would be fine, but I would have to think about it little bit more.

Tomas

Re: F24 System Wide Change: Default Local DNS Resolver

By Lennart Poettering at 12/07/2015 - 14:31

Hmm? If I work for a company "Foo Corp" that defined .foocorp as its
private TLD, then I won't be able to access servers in that local
network until I added .foocorp to a local whitelist, is that what you
are saying? Or do you want to ship your package with all those domains
pre-configured? How would you know .foocorp in advance?

I am pretty sure these things need to work out-of-the-box, and that
means a whitelist cannot really work.

Lennart

Re: F24 System Wide Change: Default Local DNS Resolver

By Florian Weimer at 12/07/2015 - 15:03

Does this mean I can reopen
<https://github.com/systemd/systemd/issues/2026> and you'll switch
systemd from “gateway” to something like “_gateway”, which cannot collide?

Florian

Re: F24 System Wide Change: Default Local DNS Resolver

By Paul Wouters at 12/07/2015 - 14:48

Foo Corp should not have done that. If you had picked .hotel or .pizza
you would have noticed this already. If you had picked .corp you would
soon find your domain blackholed at AS112. Basically, you got away with
domain squatting but with DNSSEC this has become indistinguishable from
a DNS attack.

With DNSSEC validation moving towards to stub, it will just fail.

Move your own domains within one of your real legitimate domains, and
you have the freedom to do whatever you want. Start moving away from
split DNS because that's going to be very hard to support.

Paul

Re: F24 System Wide Change: Default Local DNS Resolver

By Gerd Hoffmann at 12/08/2015 - 03:41

Hi,

Seriously? How do you suggest to handle DNS for my 192.168.2.0/24 home
network then? Making the forward zone for home.kraxel.org public would
at least work, although I fail to see the point in having public dns
records for private networks. Registering the reverse zone is never
ever going to work though ...

cheers,
Gerd

Re: F24 System Wide Change: Default Local DNS Resolver

By Petr Spacek at 12/08/2015 - 04:25

On 8.12.2015 09:41, Gerd Hoffmann wrote:
For the record, this is an invalid example.

Special-use domain names are listed in IANA registry
<a href="http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml" title="http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml">http://www.iana.org/assignments/special-use-domain-names/special-use-dom...</a>

It is not a problem to hard-code special-handling for domain names like
10.in-addr.arpa. so validation is not required for them, and that all queries
are always forwarded to local DNS servers.

Guys around dnssec-trigger actually done that in previous versions. Have you
tried it?

Re: F24 System Wide Change: Default Local DNS Resolver

By Reindl Harald at 12/08/2015 - 04:34

Am 08.12.2015 um 10:25 schrieb Petr Spacek:
what is there invalid?

* rhsoft.net is my public zone
* rhsoft.net is also my internal DNS zone
* there is no point calling my smart-tv "tv.example.com"
instead "tv.rhsoft.net"
* there is also no point to add a 192.168.x.x record in public DNS
* there is also no point calling my devices something.test
* .local shouldn't be used (look in the samba list-archives)

not that i am affected by any network changes Fedora decides since my
local DNS server will always be a full featured BIND forwarding any
non-lan zones over VPN to the comapany nameservers where i also control
the internal and external DNS views, but there are *millions* of valid
use-cases for split-DNS

Re: F24 System Wide Change: Default Local DNS Resolver

By Petr Spacek at 12/08/2015 - 04:44

On 8.12.2015 10:34, Reindl Harald wrote:
Reindl, you are mixing two things here.

The e-mail I was replying to was about sub-trees used for reverse IP->name
resolution. This can be easily solved by the registry as mentioned above.

Solution for generic DNS views is described on
<a href="https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/Design#Broken_networks" title="https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/Design#Broken_networks">https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/Design#B...</a>

As you might see, we were thinking about this hard and actually made attempt
to make it interaction-less.

In short, public/fallback DNS servers will be used to detect if part of DNS
sub-tree (like rhsoft.net) is unsigned. If the sub-tree is unsigned the
query will be re-sent to local servers and returned to the client, so data
from your local DNS view will be accessible as usual.

The assumption here is that if your domain is signed you have enough wisdom so
use DNSSEC-enabled resolvers in your network. If the domain is not signed we
will trust the crappy local servers.

Re: F24 System Wide Change: Default Local DNS Resolver

By Reindl Harald at 12/07/2015 - 14:53

Am 07.12.2015 um 20:48 schrieb Paul Wouters:
that's simply not possible for every environment

cases where your company stuff is behind a VPN and your normal internet
connection and DNS resolution for anything else is using your ISP's
nameserver are quite common

frankly when you sit in a customer LAN provisioning it's own DNS and
internal views from where you at the same time have a VPN tunnel to your
own company network there is no way to avoid "split DNS"

not that i use such setups but that's real world usage

Re: F24 System Wide Change: Default Local DNS Resolver

By Andrew Lutomirski at 12/07/2015 - 14:39

On Mon, Dec 7, 2015 at 11:31 AM, Lennart Poettering
< ... at 0pointer dot de> wrote:
If you work for foocorp, and they use .foocorp as a private TLD, then
shouldn't do some combination of:

(a) tell their employees to set whatever config they need specifically
for their connection to the foo corp network
(b) actually use foocorp.private.foocorp.com or some such and have
employees set it up in the search path so they are actually protected
by DNSSEC
(c) make sure that .foocorp isn't about to become a public TLD

I honestly don't think that Fedora should consider supporting broken
setups like the one you're describing without requiring setting
changes to be an absolute requirement.

Also, I've connected to public networks with unusable DNS twice in the
last week. I would *love* for my laptop to have automatically fallen
back to something other than the DHCP-provided non-working servers.

--Andy

Re: F24 System Wide Change: Default Local DNS Resolver

By Lennart Poettering at 12/07/2015 - 06:23

Humm, I find that way too cavalier... I am pretty sure this is a total
deal breaker for your feature. You cannot just break everybody's
network and not consider that a problem that *you* have to think about
rather than just ignoring it completely.

The ".box" domain is not owned by anyone, at least currently, it's
certainly not "hijacking" of anybody else's domain name space.

But it really doesn't matter whether that's hijacking or not. What
matters is that a large number of setups are like that... And you
break them by default, and apparently don't consider this a problem.

Quite frankly: a setup like this one isn't just very typical for home
router networks, but also in many companies, where ".lan" or
".companyname" or something like that is frequently established in the
internal network. And you will make Fedora incompatible with all these
networks by default.

The way you proposed your feature this has no place at all on the
desktop I am sure, where systems migrate between networks all the
time, and sometimes quite shitty networks. I am very sure that most
Fedora users would prefer their internet to work, rather than be
"pretend-safe", after all DNSSEC is neither necessary for safe
connections nor enables otherwise unsafe connections to be suddenly
safe...

Your feature has no place on the server the way it is either,
because those are often enough located in some company network with
internal DNS zones.

I am pretty sure your feature has no place in Fedora the way it is
until *after* these problems are delt with, not before.

I am pretty sure there are solutions possible that are simple and safe
enough to fix these problems. For example, after doing a proof of
non-existance on a top-level domain, permit it anyway, but only
those. That way, people won't be able to add in extra RRs below
microsoft.com, but they could define additional top-level domains such
as .box without this creating problems.

Well, ffs, you cannot discount everybody's setups as just "breaking
RFCs" and "hijacking" domains, and then ignore them.

You know, I am certainly not the person who wouldn't agree to the
concept of breaking eggs to make an omelette. But it's completely
unnacceptable to go to the supermarket and break everybody else's eggs
too, just because you want to make yourself one little omelette...

It's probably a good idea to do your homework first, and see what
others do, before coming up with a proposal.

(Disclaimer on all of this: we are working on adding DNSSEC support to
systemd-resolved, and about ways to make this available by default,
without breaking too much stuff. I am convinced that the stuff we are
working on there is definitely the better approach in the end, than
this current feature proposal. But of course, the DNSSEC support in
resolved is still being worked on, it's not ready yet, and I will not
file a proposal about this anytime time soon. It's just that these
problems come up when you work on this, and you need to find a
sufficiently good solution for it, and this feature has not)

Lennart

Re: F24 System Wide Change: Default Local DNS Resolver

By Richard Zidlicky at 12/16/2015 - 09:11

On Mon, Dec 07, 2015 at 12:23:34PM +0100, Lennart Poettering wrote:
not everyones network - I allways use the IP to access routers.

It should be a feature of unbound to find the router and offer a stable
DNS pseudo-entry for that.

Richard