F24 System Wide Change: Default Local DNS Resolver

[Jan Kurik]

= Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

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] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html



== 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.

[Russell Doty]

Is DNS by itself sufficient, or should we also address other network
facing capabilities with security impact such as secure time?

Post by Jan Kurik
= Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
* 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] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755
.html
== 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
* 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)
* 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.

[Steve Grubb]

Post by Russell Doty
Is DNS by itself sufficient, or should we also address other network
facing capabilities with security impact such as secure time?

The use case for the dnscache_test is to look for evidence of a system trying
to reach a known Command and Control system. This would indicate that the
server has malware on it. I believe that examining DNS cache by itself is
sufficient.

-Steve

Post by Russell Doty

Post by Jan Kurik
= Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
* 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] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755
.html
== 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
* 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)
* 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.

--
devel mailing list

[P J P]

Hello Russell,

Post by Russell Doty

Post by Russell Doty
Is DNS by itself sufficient, or should we also address other network

facing capabilities with security impact such as secure time?

Yes, we could do that. But that would have to be an independent Change
request.
---
-P J P
http://feedmug.com

[Vít Ondruch]

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

Post by Jan Kurik
= Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
* 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] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
== 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
* 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)
* 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.

[P J P]

Hello Vit,

Post by Vít Ondruch

Post by Vít Ondruch
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?

True, it was postponed couple of times because few implementation
issues were not resolved properly. There wasn't consensus about how
the proposed solution would interact with other components(ex. NM,
Gnome shell) on the system.[*] We have managed to sort out those
differences and hope to resolve implementation issues to build a
strong solution.


[*] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver


Thank you.
---
-P J P
http://feedmug.com

[Tomas Hozza]

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 (http://www.ietf.org/id/draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt)
- 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

Post by Vít Ondruch
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

Post by Jan Kurik
= Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
* 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] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
== 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
* 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)
* 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.

--
devel mailing list

[Tomas Mraz]

Post by Tomas Hozza
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.
- 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

Will there be at least some visual indicator that the network you're
connected to does not provide secure DNS?

[Tomas Hozza]

Post by Tomas Mraz

Post by Tomas Hozza
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.
- 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

Will there be at least some visual indicator that the network you're
connected to does not provide secure DNS?

Not that the network does not provide secure DNS, but only that the local DNS
resolver is not able to use DNSSEC. This information makes sense on the system
level, not really on the connection level (although technically it is possible).

We are still working on the solution. Nevertheless it should be native WRT
the desktop environment on Fedora Workstation.

Tomas

[Björn Persson]

Post by Tomas Hozza
- 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

Can I assume that users of non-Gnome desktops will also be able to log
in to a portal if they want to?

Björn Persson

[Tomas Hozza]

Post by Björn Persson

Post by Tomas Hozza
- 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

Can I assume that users of non-Gnome desktops will also be able to log
in to a portal if they want to?

Yes, it should be possible. You would need to install the dnssec-trigger-panel.

Tomas

[Paul Wouters]

Post by Björn Persson

Post by Tomas Hozza
- 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

Can I assume that users of non-Gnome desktops will also be able to log
in to a portal if they want to?

If you can do so now, then you will in the future as well? The idea here
is that dnssec-trigger will no longer fire up its own portal login page,
but leave it to the OS/Desktop.

Paul

[Neal Becker]

I think in order to make dnssec/local resolver the default, it should be
required to work for a naive user who works in a changing environment such
as:

moving between work, which has it's own private dns and
home, which has usual, public dns

without that user needing to understand anything about configuring the
components. For example, when I'm at work, I can access

hostA.work.com

where resolving hostA only works by talking to dnsserverA.work.com, which
was setup by the usual dhcp
and then when I'm at home

google.com

is resolved as normal, using my ISP's dhcp to configure dns.

And this must work without the user ever editing some unbound config file.

[P J P]

Hello Neal,

For example, when I'm at work, I can access hostA.work.com
where resolving hostA only works by talking to dnsserverA.work.com,
which was setup by the usual dhcp and then when I'm at home
google.com is resolved as normal, using my ISP's dhcp to configure dns.
And this must work without the user ever editing some unbound config file.

Yes, it does work that way. The proposed solution(tools) is available in
current Fedora repositories and is easy to set-up and test.


-> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test


Please let us know if you face any difficulties. Thank you.

--- -P J P
http://feedmug.com

[Neal Becker]

Post by P J P
Hello Neal,

For example, when I'm at work, I can access hostA.work.com
where resolving hostA only works by talking to dnsserverA.work.com,
which was setup by the usual dhcp and then when I'm at home
google.com is resolved as normal, using my ISP's dhcp to configure dns.
And this must work without the user ever editing some unbound config file.

Yes, it does work that way. The proposed solution(tools) is available in
current Fedora repositories and is easy to set-up and test.
->

https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test

Post by P J P
Please let us know if you face any difficulties. Thank you.

https://bugzilla.redhat.com/show_bug.cgi?id=1287607

[Neal Becker]

Post by Neal Becker

Post by P J P
Hello Neal,

For example, when I'm at work, I can access hostA.work.com
where resolving hostA only works by talking to dnsserverA.work.com,
which was setup by the usual dhcp and then when I'm at home
google.com is resolved as normal, using my ISP's dhcp to configure dns.
And this must work without the user ever editing some unbound config file.

Yes, it does work that way. The proposed solution(tools) is available in
current Fedora repositories and is easy to set-up and test.
->

https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test

Post by Neal Becker

Post by P J P
Please let us know if you face any difficulties. Thank you.

https://bugzilla.redhat.com/show_bug.cgi?id=1287607

So remaining difficulties are:

* howto prevent dnsmasq from starting (right now I'm just manually killing
it for testing)

* howto get domainname set automatically from dhcp

[P J P]

Post by Neal Becker

Post by Neal Becker
https://bugzilla.redhat.com/show_bug.cgi?id=1287607

Thank you for filing the bug.

Post by Neal Becker
* howto prevent dnsmasq from starting (right now I'm just manually killing
it for testing)

# systemctl disable dnsmasq

Post by Neal Becker
* howto get domainname set automatically from dhcp

Dhcp configuration manual should help with that.

---
-P J P
http://feedmug.com

[Neal Becker]

Post by P J P

Post by Neal Becker

Post by Neal Becker
https://bugzilla.redhat.com/show_bug.cgi?id=1287607

Thank you for filing the bug.

Post by Neal Becker
* howto prevent dnsmasq from starting (right now I'm just manually
killing it for testing)

# systemctl disable dnsmasq

ps aux | grep dns
nobody 1056 0.0 0.0 57544 484 ? S Dec14 0:00
/sbin/dnsmasq --conf-file=/var/lib/libvir
root 1058 0.0 0.0 57516 24 ? S Dec14 0:00
/sbin/dnsmasq --conf-file=/var/lib/libvir

[***@nbecker2 Boost.NumPy]$ systemctl status dnsmasq
● dnsmasq.service - DNS caching server.
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled; vendor
preset: disabled)
Active: inactive (dead)

So something else is starting dnsmasq - looks like related to libvirt.

Post by P J P

Post by Neal Becker
* howto get domainname set automatically from dhcp

Dhcp configuration manual should help with that.
---
-P J P
http://feedmug.com
--
devel mailing list

[Tomasz Torcz]

Post by Neal Becker

Post by P J P

Post by Neal Becker

Post by Neal Becker
https://bugzilla.redhat.com/show_bug.cgi?id=1287607

Thank you for filing the bug.

Post by Neal Becker
* howto prevent dnsmasq from starting (right now I'm just manually
killing it for testing)

# systemctl disable dnsmasq

ps aux | grep dns
nobody 1056 0.0 0.0 57544 484 ? S Dec14 0:00
/sbin/dnsmasq --conf-file=/var/lib/libvir
root 1058 0.0 0.0 57516 24 ? S Dec14 0:00
/sbin/dnsmasq --conf-file=/var/lib/libvir

Try
systemctl status 1056

I guess it's started by libvirtd.

[Neal Becker]

Post by Tomasz Torcz

Post by Neal Becker

Post by P J P

Post by Neal Becker

Post by Neal Becker
https://bugzilla.redhat.com/show_bug.cgi?id=1287607

Thank you for filing the bug.

Post by Neal Becker
* howto prevent dnsmasq from starting (right now I'm just manually
killing it for testing)

# systemctl disable dnsmasq

ps aux | grep dns
nobody 1056 0.0 0.0 57544 484 ? S Dec14 0:00
/sbin/dnsmasq --conf-file=/var/lib/libvir
root 1058 0.0 0.0 57516 24 ? S Dec14 0:00
/sbin/dnsmasq --conf-file=/var/lib/libvir

Try
systemctl status 1056
I guess it's started by libvirtd.

Yes, and does it have to be stopped in order for local dns resolver to
function?

[Dan Williams]

Post by Neal Becker

Post by Tomasz Torcz

Post by Neal Becker

Post by P J P

Post by Neal Becker

Post by Neal Becker
https://bugzilla.redhat.com/show_bug.cgi?id=1287607

Thank you for filing the bug.

Post by Neal Becker
* howto prevent dnsmasq from starting (right now I'm just manually
killing it for testing)

# systemctl disable dnsmasq

ps aux | grep dns
nobody 1056 0.0 0.0 57544 484 ? S Dec14 0:00
/sbin/dnsmasq --conf-file=/var/lib/libvir
root 1058 0.0 0.0 57516 24 ? S Dec14 0:00
/sbin/dnsmasq --conf-file=/var/lib/libvir

Try
systemctl status 1056
I guess it's started by libvirtd.

Yes, and does it have to be stopped in order for local dns resolver to
function?

No, it doesn't. If you look at the config file for each instance
you'll see

interface=virbr0 (or something similar)
except-interface=lo

otherwise you'd never be able to run multiple VMs with different
network setups. The libvirt dnsmasq instance should be binding to the
interface that libvirt owns/manages and nothing else.

Same thing for NetworkManager's "internet connection sharing"
functionality with dnsmasq.

But using NetworkManager's dns=dnsmasq config option *does* tell NM to
spawn dnsmasq as a local caching nameserver listening on lo and that
will conflict with unbound.

Dan

[Tomas Hozza]

Post by P J P

Post by Neal Becker

Post by P J P
Hello Neal,

For example, when I'm at work, I can access hostA.work.com
where resolving hostA only works by talking to dnsserverA.work.com,
which was setup by the usual dhcp and then when I'm at home
google.com is resolved as normal, using my ISP's dhcp to configure dns.
And this must work without the user ever editing some unbound config file.

Yes, it does work that way. The proposed solution(tools) is available in
current Fedora repositories and is easy to set-up and test.
->

https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test

Post by Neal Becker

Post by P J P
Please let us know if you face any difficulties. Thank you.

https://bugzilla.redhat.com/show_bug.cgi?id=1287607

* howto prevent dnsmasq from starting (right now I'm just manually killing
it for testing)

This is needed only if you intentionally started dnsmasq. You don't need to kill
all dnsamsq instances in the system (e.g. the ones started by libvirt). I'll review
the change wiki in this regard.

Post by P J P
* howto get domainname set automatically from dhcp

As discussed in the Bug, this is not going to work and it is expected not to.
Setting search domains from DHCP is a security issue.


Tomas

Post by P J P
--
devel mailing list

[Neal Becker]

Post by P J P
Hello Neal,

For example, when I'm at work, I can access hostA.work.com
where resolving hostA only works by talking to dnsserverA.work.com,
which was setup by the usual dhcp and then when I'm at home
google.com is resolved as normal, using my ISP's dhcp to configure dns.
And this must work without the user ever editing some unbound config file.

Yes, it does work that way. The proposed solution(tools) is available in
current Fedora repositories and is easy to set-up and test.
->

https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test

Post by P J P
Please let us know if you face any difficulties. Thank you.

Also, I think we need it to work out-of-the-box. Editing a config file is
not working out-of-the-box.

[Lennart Poettering]

Post by Tomas Hozza
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.

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

[Timotheus Pokorra]

Post by Lennart Poettering
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

Same for Vodafone Routers in Germany: I go to http://easy.box to
configure my router.

[Dan Williams]

Post by Timotheus Pokorra

Post by Lennart Poettering
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

Same for Vodafone Routers in Germany: I go to http://easy.box to
configure my router.

Older Netgear routers also used http://routerlogin.net before they were
set up.

Dan

[Florian Weimer]

Post by Dan Williams

Post by Timotheus Pokorra

Post by Lennart Poettering
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

Same for Vodafone Routers in Germany: I go to http://easy.box to
configure my router.

Older Netgear routers also used http://routerlogin.net before they were
set up.

That's actually much better because Netgear just has to avoid signing
the domain, and it will keep working as long as the local validating
resolver makes the queries in such a way that they can be intercepted by
the DNS-rewriting device.

Florian

[Tomas Hozza]

Post by Dan Williams

Post by Timotheus Pokorra

Post by Lennart Poettering
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

Same for Vodafone Routers in Germany: I go to http://easy.box to
configure my router.

Older Netgear routers also used http://routerlogin.net before they were
set up.

If they don't own the domain, then this is simply hijacking of domain
name space, which is not owned by them. It is expected, that these
"clever ideas" will not work with DNSSEC.

Tomas

Post by Dan Williams
Dan
--
devel mailing list

[Matthew Miller]

Post by Tomas Hozza

Post by Dan Williams
Older Netgear routers also used http://routerlogin.net before they were
set up.

If they don't own the domain, then this is simply hijacking of domain
name space, which is not owned by them. It is expected, that these
"clever ideas" will not work with DNSSEC.

FWIW, they _do_ own the domain.

[Scott Schmit]

Post by Matthew Miller

Post by Tomas Hozza

Post by Dan Williams
Older Netgear routers also used http://routerlogin.net before they were
set up.

If they don't own the domain, then this is simply hijacking of domain
name space, which is not owned by them. It is expected, that these
"clever ideas" will not work with DNSSEC.

FWIW, they _do_ own the domain.

True, though the A record does not exist. Since there's no DS record
either, the domain is not secured and the spoofing will still work as
long as the local name server uses the name server provided by the
router for its answers. I think this is the default as long as the
router supports recursive resolution, EDNS0, and doesn't corrupt
RRSIG/NSEC/... records.

[Tomas Hozza]

Post by Lennart Poettering

Post by Tomas Hozza
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.

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.

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.

Post by Lennart Poettering
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?

I'm not able to answer this question.

Post by Lennart Poettering
Lennart

[1] http://www.ietf.org/mail-archive/web/dnsop/current/msg16208.html
[2] https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/UnboundMixedMode
[3] http://www.ietf.org/mail-archive/web/dnsop/current/msg16209.html

Regards,

[Lennart Poettering]

Post by Tomas Hozza

Post by Lennart Poettering

Post by Tomas Hozza
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.

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.

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.

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.

Post by Tomas Hozza
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.

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

Post by Tomas Hozza
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.

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.

Post by Tomas Hozza
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.

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...

Post by Tomas Hozza

Post by Lennart Poettering
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?

I'm not able to answer this question.

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

[Gerd Hoffmann]

Hi,

Post by Lennart Poettering
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.

Even if you don't grab some random name it still is a problem. /me runs
home.kraxel.org zone for my home network (and, yes, kraxel.org is mine).
That zone isn't visible outsize my home network, if you try to resolve
that by walking down from the root zone you wouldn't find it, you have
to use the local dns server propagated by dhcp.

I actually have unbound running on my workstation (rhel-7.2), and it
doesn't work out-of-the-box. Had to drop a file with stub zones
into /etc/unbound/local.d to get things going.

Post by Lennart Poettering
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.

That doesn't solve $internalsubdomain.$company.com ...

cheers,
Gerd

[Lennart Poettering]

Post by Gerd Hoffmann
Hi,

Post by Lennart Poettering
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.

Even if you don't grab some random name it still is a problem. /me runs
home.kraxel.org zone for my home network (and, yes, kraxel.org is mine).
That zone isn't visible outsize my home network, if you try to resolve
that by walking down from the root zone you wouldn't find it, you have
to use the local dns server propagated by dhcp.

This case should actually not be a problem normally, even with
DNSSEC, since in such a case you wouldn't enable DNSSEC on
kraxel.org.

If you want to do such "split horizon" setups, then don't sign your
zones. I think that's a completely fair requirement to make, and if
you did sign your domains then this should really mean "don't allow
anything below my domain except what I define here or delegated".

The problem is pretty much limited to top-level domains, where those
routers and company networks invented stuff.

Lennart

[Scott Schmit]

Post by Lennart Poettering

Post by Gerd Hoffmann

Post by Lennart Poettering
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.

Even if you don't grab some random name it still is a problem. /me runs
home.kraxel.org zone for my home network (and, yes, kraxel.org is mine).
That zone isn't visible outsize my home network, if you try to resolve
that by walking down from the root zone you wouldn't find it, you have
to use the local dns server propagated by dhcp.

This case should actually not be a problem normally, even with
DNSSEC, since in such a case you wouldn't enable DNSSEC on
kraxel.org.
If you want to do such "split horizon" setups, then don't sign your
zones. I think that's a completely fair requirement to make, and if
you did sign your domains then this should really mean "don't allow
anything below my domain except what I define here or delegated".

Why would you say that? Split horizon with DNSSEC works fine -- just
sign both external and internal views.

[Matthew Miller]

Post by Lennart Poettering

Post by Tomas Hozza
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.

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.

I agree with Lennart. Whether or not this is expected to work with
DNSSEC is of academic interest given that people will expect it to work
with _their computers_, regardless of what they're running.

[Tomas Hozza]

Post by Matthew Miller

Post by Lennart Poettering

Post by Tomas Hozza
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.

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.

I agree with Lennart. Whether or not this is expected to work with
DNSSEC is of academic interest given that people will expect it to work
with _their computers_, regardless of what they're running.

I guess next time I'll not send thing to devel list that I don't want
to be picked on. This is completely out of context.

Tomas

[Matthew Miller]

Post by Tomas Hozza

Post by Matthew Miller
I agree with Lennart. Whether or not this is expected to work with
DNSSEC is of academic interest given that people will expect it to work
with _their computers_, regardless of what they're running.

I guess next time I'll not send thing to devel list that I don't want
to be picked on. This is completely out of context.

Am I misunderstanding something? It seems like a valid concern to me.

[Tomas Hozza]

Post by Matthew Miller

Post by Tomas Hozza

Post by Matthew Miller
I agree with Lennart. Whether or not this is expected to work with
DNSSEC is of academic interest given that people will expect it to work
with _their computers_, regardless of what they're running.

I guess next time I'll not send thing to devel list that I don't want
to be picked on. This is completely out of context.

Am I misunderstanding something? It seems like a valid concern to me.

Besides that my email started with the fact that it is what it is, whether
you like it or not, I continued with the possibilities we have.

I took this conversation as a mean for improvement. But it turned out
to be PR for systemd-resolved.

Tomas

[Richard Hughes]

Post by Tomas Hozza
I took this conversation as a mean for improvement.

When an email is titled "F24 System Wide Change" I think a lot of
people (like me) were under the impression you wanted this to be a new
feature in Fedora 24.

Richard.

[Tomas Hozza]

Post by Richard Hughes

Post by Tomas Hozza
I took this conversation as a mean for improvement.

When an email is titled "F24 System Wide Change" I think a lot of
people (like me) were under the impression you wanted this to be a new
feature in Fedora 24.

When I reply to an email that was a reply to my previous email, I take it
as a discussion. Sorry for confusing you.

Tomas

[Matthew Miller]

Post by Tomas Hozza

Post by Matthew Miller

Post by Tomas Hozza

Post by Matthew Miller
I agree with Lennart. Whether or not this is expected to work with
DNSSEC is of academic interest given that people will expect it to work
with _their computers_, regardless of what they're running.

I guess next time I'll not send thing to devel list that I don't want
to be picked on. This is completely out of context.

Am I misunderstanding something? It seems like a valid concern to me.

Besides that my email started with the fact that it is what it is, whether
you like it or not, I continued with the possibilities we have.

I read your whole post. Those possibilities seem pretty limited, from
the point of view of serious regressions in Fedora usability. It isn't
that I "like" Fedora being less than technically correct (especially
around security-related features), but I don't think we can discount
the prevalence of "broken" schemes in the real world.

Post by Tomas Hozza
I took this conversation as a mean for improvement. But it turned out
to be PR for systemd-resolved.

I don't really care about that. I care that we pick the solutions that
are best for our users.

[Paul Wouters]

Post by Matthew Miller
I read your whole post. Those possibilities seem pretty limited, from
the point of view of serious regressions in Fedora usability. It isn't
that I "like" Fedora being less than technically correct (especially
around security-related features), but I don't think we can discount
the prevalence of "broken" schemes in the real world.

But you gain nothing with waiting. There is no "fix" to wait for. Those
stolen domains are broken and they will start to fail. The only difference
could be that fedora won't be the first where this breaks on, but I
thought "First" was one of our motto's ?

Post by Matthew Miller
I don't really care about that. I care that we pick the solutions that
are best for our users.

Supporting DNSSEC per default is best for the user. Not enabling DNSSEC
is not a serious option. We delayed this feature a few times to ensure
we would get better integration with gnome and VPNs so that we could
address the _real_ problems.

People using stolen or made up domain names is not a use case that can
be supported anymore with Secure DNS.

Paul

[Oron Peled]

Post by Paul Wouters
But you gain nothing with waiting. There is no "fix" to wait for. Those
stolen domains are broken and they will start to fail. The only difference
could be that fedora won't be the first where this breaks on, but I
thought "First" was one of our motto's ?

Yes, as long as the "first" to fail use-case isn't too massive.

So I have a question about another very common use-case:
* Many times, Linux users or groups are a small "island" inside a big traditional corporation.

* Usually, it translates to MS products: lousy DHCP server + lousy DNS server, managed via Active Directory (TM).

* I think we should test this kind of setup and have very clear policy and instructions how to deal with it.

* Remember, in most of these places the Linux team hardly knows who manage all the Windows stuff,
let alone affect corporate internal policies (e.g: internal domain names and DHCP setup).

* Failing in this kind of environment is shooting both Fedora and DNSSEC adoption in the foot.

IMO, when introducing DNSSEC as default it should not be *enforcing*:
* There's a lesson to be learned by what happened to SELinux in Fedora-2
(I personally do have SELinux "enforcing" on all my systems, but many would never try it again).

* It's far better to accept "broken" DNS servers *at first* and just warn.
(I know warning end-users isn't effective, but its important as a stop-gap
until we know how such a feature affect millions of users in the real world.

* E.g: "WARNING: the yellow icon is a reminder that your local network use non-secure technology <link-to-further-explanation>"
(someone may have an idea how to warn server people [/etc/issue?])

* BTW: hits on the above link would give us *some* measurement about people having problems/investigating this.

Bye,

[Harald Hoyer]

Post by Paul Wouters

Post by Matthew Miller
I read your whole post. Those possibilities seem pretty limited, from
the point of view of serious regressions in Fedora usability. It isn't
that I "like" Fedora being less than technically correct (especially
around security-related features), but I don't think we can discount
the prevalence of "broken" schemes in the real world.

But you gain nothing with waiting. There is no "fix" to wait for. Those
stolen domains are broken and they will start to fail. The only difference
could be that fedora won't be the first where this breaks on, but I
thought "First" was one of our motto's ?

Post by Matthew Miller
I don't really care about that. I care that we pick the solutions that
are best for our users.

Supporting DNSSEC per default is best for the user. Not enabling DNSSEC
is not a serious option. We delayed this feature a few times to ensure
we would get better integration with gnome and VPNs so that we could
address the _real_ problems.
People using stolen or made up domain names is not a use case that can
be supported anymore with Secure DNS.

If it causes problems you have no time to fix, you will do "selinux=0 dnssec=0"

[Miroslav Grepl]

Post by Harald Hoyer

Post by Paul Wouters

Post by Matthew Miller
I read your whole post. Those possibilities seem pretty limited, from
the point of view of serious regressions in Fedora usability. It isn't
that I "like" Fedora being less than technically correct (especially
around security-related features), but I don't think we can discount
the prevalence of "broken" schemes in the real world.

But you gain nothing with waiting. There is no "fix" to wait for. Those
stolen domains are broken and they will start to fail. The only difference
could be that fedora won't be the first where this breaks on, but I
thought "First" was one of our motto's ?

Post by Matthew Miller
I don't really care about that. I care that we pick the solutions that
are best for our users.

Supporting DNSSEC per default is best for the user. Not enabling DNSSEC
is not a serious option. We delayed this feature a few times to ensure
we would get better integration with gnome and VPNs so that we could
address the _real_ problems.
People using stolen or made up domain names is not a use case that can
be supported anymore with Secure DNS.

If it causes problems you have no time to fix, you will do "selinux=0 dnssec=0"

Whoops.

Why "selinux=0"?

Do you think it would be better to tell people to set "enforcing=0" and
collect AVCs with a report instead of saying "selinux=0"?

Post by Harald Hoyer
--
devel mailing list

[Tomas Hozza]

Post by Lennart Poettering

Post by Tomas Hozza

Post by Lennart Poettering

Post by Tomas Hozza
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.

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.

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.

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.

It sounds like you stopped at the first section of the email and ended there.
I didn't said that, and if you read the whole email you should understand that.
Otherwise my email would end right after this section you commented to.

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

You hijack the root zone space.

Post by Lennart Poettering
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.

I didn't said that.

Post by Lennart Poettering
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.

Lennart, you don't have to comment on something you think I said, while
the rest of my email described the possible solution to the problem.
This means that I think it is important to take it into account and
provide some possible solution.

Post by Lennart Poettering

Post by Tomas Hozza
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.

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

This is work in progress. We are working on it and if it is not completed
it will not be included. We don't put everything in Fedora and then announce it.

Post by Lennart Poettering

Post by Tomas Hozza
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.

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.

This is exactly that I described in the mixed module section. Too bad you deleted the
section that would conflict with your comment.

Post by Lennart Poettering

Post by Tomas Hozza
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.

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...

Post by Tomas Hozza

Post by Lennart Poettering
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?

I'm not able to answer this question.

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

Right. For the future, please read my whole email and don't delete parts
that don't suite your comments.

Your whole email sounds like you are making too much noise about something
we acknowledge that we want to solve somehow. At the same time you are doing
marketing for your next project and that you are the only one to solve
everything the right way.


Regards,

[Richard Z]

Post by Lennart Poettering

Post by Tomas Hozza
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.

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.

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

[Andrew Lutomirski]

Post by Tomas Hozza

Post by Lennart Poettering

Post by Tomas Hozza
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.

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.

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.

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

[Tomas Hozza]

Post by Tomas Hozza

Post by Lennart Poettering

Post by Tomas Hozza
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.

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.

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.

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.

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

--Andy
--
devel mailing list

[Lennart Poettering]

Post by Tomas Hozza

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.

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.

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

[Andrew Lutomirski]

On Mon, Dec 7, 2015 at 11:31 AM, Lennart Poettering

Post by Lennart Poettering

Post by Tomas Hozza

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.

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.

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.

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

[Paul Wouters]

Post by Lennart Poettering
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

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

[Reindl Harald]

Post by Paul Wouters
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.

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

[Gerd Hoffmann]

Hi,

Post by Paul Wouters
Start moving away from
split DNS because that's going to be very hard to support.

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

[Petr Spacek]

Post by Gerd Hoffmann
Hi,

Post by Paul Wouters
Start moving away from
split DNS because that's going to be very hard to support.

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 ...

For the record, this is an invalid example.

Special-use domain names are listed in IANA registry
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

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?

[Reindl Harald]

Post by Petr Spacek

Post by Gerd Hoffmann
Hi,

Post by Paul Wouters
Start moving away from
split DNS because that's going to be very hard to support.

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 ...

For the record, this is an invalid example.
Special-use domain names are listed in IANA registry
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

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

[Petr Spacek]

Post by Reindl Harald

Post by Petr Spacek

Post by Gerd Hoffmann
Hi,

Post by Paul Wouters
Start moving away from
split DNS because that's going to be very hard to support.

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 ...

For the record, this is an invalid example.
Special-use domain names are listed in IANA registry
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

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

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
https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/Design#Broken_networks

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.

[Florian Weimer]

Post by Lennart Poettering
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.

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

[Paul Wouters]

Post by Tomas Hozza

Post by Lennart Poettering
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...

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"

https://www.icann.org/resources/agreement/box-2015-11-12-en

.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

Post by Tomas Hozza

Post by Lennart Poettering
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?

Don't they work when you use http://192.168.1.1/ ?

What's your

Post by Tomas Hozza

Post by Lennart Poettering
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.

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!

Post by Tomas Hozza
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.

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.

Post by Tomas Hozza
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.

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

Post by Tomas Hozza
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.

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

Post by Tomas Hozza

Post by Lennart Poettering
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?

I'm not able to answer this question.

It will start failing for people irrespective of DNSSEC.

Paul

[Florian Weimer]

Post by Paul Wouters
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"
https://www.icann.org/resources/agreement/box-2015-11-12-en
.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. [....]

Ah, nice.

Post by Paul Wouters
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 :(

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

Florian

[Paul Wouters]

Post by Florian Weimer

Post by Paul Wouters
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 :(

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

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

[Reindl Harald]

Post by Paul Wouters

Post by Florian Weimer

Post by Paul Wouters
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 :(

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

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

* typically this devices act as DNS for the LAN
* fritz.box != *.box
* hence your or his IP don't matter

[Florian Weimer]

Post by Paul Wouters

Post by Florian Weimer

Post by Paul Wouters
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 :(

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

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?

The public DNS would return NODATA.

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

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

[Debarshi Ray]

Post by Tomas Hozza

Post by Lennart Poettering
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?

I'm not able to answer this question.

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

[Fabio Alessandro Locati]

Post by Lennart Poettering
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?

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

[Paul Wouters]

Post by Debarshi Ray

Post by Tomas Hozza

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?

I'm not able to answer this question.

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.

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

[Oron Peled]

Post by Paul Wouters

Post by Debarshi Ray
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.

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.

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?

[Petr Spacek]

Post by Oron Peled

Post by Paul Wouters

Post by Debarshi Ray
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.

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.

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.
* 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?

It certainly makes sense, and if read

https://fedoraproject.org/w/index.php?title=Changes/Default_Local_DNS_Resolver

and pages linked from

https://fedoraproject.org/w/index.php?title=Changes/Default_Local_DNS_Resolver#Documentation

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

[Paul Wouters]

Post by Oron Peled
* 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.

DNS lookups don't have users like web browsers.

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

Paul

[Reindl Harald]

Post by Paul Wouters

Post by Oron Peled
* 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.

DNS lookups don't have users like web browsers

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

[Oron Peled]

Post by Paul Wouters

Post by Oron Peled
* 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.

I'll answer both Paul and Reindl which replied "there's no safe and clean way to solve that"...

Post by Paul Wouters
DNS lookups don't have users like web browsers.

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.

Post by Paul Wouters
I have been running this setup since Fedora 17. Breakage is not that bad.

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.

[Paul Wouters]

Post by Oron Peled

Post by Paul Wouters

Post by Oron Peled
* 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.

I'll answer both Paul and Reindl which replied "there's no safe and clean way to solve that"...

Post by Paul Wouters
DNS lookups don't have users like web browsers.

* 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.
* 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.

You can do that logging using tools like dnssec-system-tray pointing to the unbound log file.

Post by Oron Peled
* 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.

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

Post by Oron Peled

Post by Paul Wouters
I have been running this setup since Fedora 17. Breakage is not that bad.

Hmmm... even if all of us, fedora-devel subscribers, would run this

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.

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

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.

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

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

[Oron Peled]

Post by Paul Wouters

Post by Oron Peled
Still, IMO, the goal to warn users can be achieved quite easily. Two examples from the top of my head.
* 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.

You can do that logging using tools like dnssec-system-tray pointing to the unbound log file.

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.

Post by Paul Wouters

Post by Oron Peled
* 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.

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

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).

Post by Paul Wouters

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

google dns, verisign dns and many large DNS deployments already validate and break setups of
people using 8.8.8.8 manually.

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.

Post by Paul Wouters
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.

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).

Post by Paul Wouters

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

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.

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.

Post by Paul Wouters
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".

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,

[Paul Wouters]

Post by Oron Peled

Post by Paul Wouters

Post by Oron Peled
* 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.

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

* 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).

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.

Post by Oron Peled
Those DNS deployments are good for general DNSSEC technology validation.
* 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.

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.

Post by Oron Peled
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 have no problem breaking those kind of setups.

Post by Oron Peled

Post by Paul Wouters
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.

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).

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

Post by Oron Peled
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.

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

Post by Oron Peled

Post by Paul Wouters
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".

* Has this "biggest issue" really been solved? Do we have this NM integration?

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

Post by Oron Peled
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?

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

Paul

[Neal Becker]

Post by Paul Wouters

Post by Oron Peled

Post by Paul Wouters
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".

* Has this "biggest issue" really been solved? Do we have this NM integration?

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

Post by Oron Peled
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?

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

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.

[Jiri Eischmann]

Post by Paul Wouters

Post by Debarshi Ray

Post by Tomas Hozza

Post by Lennart Poettering
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?

I'm not able to answer this question.

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.

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.

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
 

[Ralf Corsepius]

Post by Jiri Eischmann
So my worry is that we would be an OS which is more secure than others,
but doesn't work in many networks.

If something doesn't work reliably, the logical consequence to me would
be to keep it strictly optional (opt-in) and not to make it default.

Post by Jiri Eischmann
You can bet what the users would
decide for...

Exactly ... take into account the "user experience" some
Fedora-"novelties" communicated over the years ;)

Ralf

[Leon Tester]

Test

&gt; So my worry is that we would be an OS which is more secure than others,

&gt; but doesn't work in many networks.
If something doesn't work reliably, the logical consequence to me would
be to keep it strictly optional (opt-in) and not to make it default.

&gt; You can bet what the users would

&gt; decide for...
Exactly ... take into account the "user experience" some
Fedora-"novelties" communicated over the years ;)

Ralf
\--

devel mailing list
***@lists.fedoraproject.org
<http://lists.fedoraproject.org/admin/lists/***@lists.fedoraproject.org>

[Björn Persson]

Post by Lennart Poettering
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,

I wonder what they were planning to do the day somebody registers box.

Björn Persson

[Randy Barlow]

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?

[Paul Wouters]

Post by Randy Barlow
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?

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 https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/

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

[Pádraig Brady]

Post by Randy Barlow
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?

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

[Reindl Harald]

Post by Pádraig Brady

Post by Randy Barlow
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?

That split DNS setup has been working well for me since Fedora 21,
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

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

[Björn Esser]

And some German Cable-ISP uses kabel.box across all their CPE devices.

Post by Timotheus Pokorra

Post by Lennart Poettering
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

Same for Vodafone Routers in Germany: I go to http://easy.box to
configure my router.
--
devel mailing list

[Florian Weimer]

Post by Jan Kurik
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

Would someone please clarify the proposal if Unbound would run as a
forwarder, or as a stand-alone recursive resolver?

Thanks,
Florian

[Tomas Hozza]

Post by Florian Weimer

Post by Jan Kurik
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

Would someone please clarify the proposal if Unbound would run as a
forwarder, or as a stand-alone recursive resolver?

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

Post by Florian Weimer
Thanks,
Florian
--
devel mailing list

[Lennart Poettering]

Post by Tomas Hozza

Post by Florian Weimer

Post by Jan Kurik
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

Would someone please clarify the proposal if Unbound would run as a
forwarder, or as a stand-alone recursive resolver?

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.

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...

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

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

Lennart

[Björn Persson]

Post by Lennart Poettering
You *have* to use the local DNS servers by default, even if they are
crap.

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.

Post by Lennart Poettering
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?

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

[Lennart Poettering]

Post by Björn Persson

Post by Lennart Poettering
You *have* to use the local DNS servers by default, even if they are
crap.

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.

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.

Post by Björn Persson
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.

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

[Björn Persson]

Post by Lennart Poettering

Post by Björn Persson

Post by Lennart Poettering
You *have* to use the local DNS servers by default, even if they are
crap.

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.

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...

You are right about the typical user. This is what happens to the
typical user as a result:

http://swiftonsecurity.tumblr.com/post/98675308034/a-story-about-jessica

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

[Petr Spacek]

Post by Lennart Poettering

Post by Björn Persson

Post by Lennart Poettering
You *have* to use the local DNS servers by default, even if they are
crap.

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.

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.

Post by Björn Persson
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.

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, you could find more information in the Fedora change page:
https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/Design#Broken_networks

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.

[Paul Wouters]

Post by Lennart Poettering

Post by Tomas Hozza
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.

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.

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.

Post by Lennart Poettering
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,

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

Post by Lennart Poettering
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...

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.

Post by Lennart Poettering
It's completely OK to gracefully degrade to non-DNSSEC DNS if the
local DNS server cannot do it.

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

Post by Lennart Poettering
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?

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.

Post by Lennart Poettering
Do you really think that Fedora is capable and willing to handle all
that traffic?

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.

Post by Lennart Poettering
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...

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.

Post by Lennart Poettering
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 should never happen on networks that normal people build.

Paul