Re: F24 System Wide Change: Default Local DNS Resolver

[Harald Hoyer]

On 07.12.2015 20:57, Paul Wouters wrote:
> On Mon, 7 Dec 2015, Matthew Miller wrote:
> 
>> 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 ?
> 
>> 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"
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Miroslav Grepl]

On 12/17/2015 10:19 AM, Harald Hoyer wrote:
> On 07.12.2015 20:57, Paul Wouters wrote:
>> On Mon, 7 Dec 2015, Matthew Miller wrote:
>>
>>> 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 ?
>>
>>> 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"?


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


-- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

P J P wrote:

>> On Wednesday, 2 December 2015 6:33 PM, Neal Becker wrote:
> 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1287607
> 
> 
>   Thank you for filing the bug.
> 
> 
>> * howto prevent dnsmasq from starting (right now I'm just manually
>> killing it for testing)
> 
>   # systemctl disable dnsmasq
> 
> 

ps aux | grep dns
nobody1056  0.0  0.0  57544   484 ?SDec14   0:00 
/sbin/dnsmasq --conf-file=/var/lib/libvir
root  1058  0.0  0.0  5751624 ?SDec14   0:00 
/sbin/dnsmasq --conf-file=/var/lib/libvir

[nbecker@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.

>> * howto get domainname set automatically from dhcp
> 
> 
> 
>   Dhcp configuration manual should help with that.
> 
> ---
>   -P J P
> http://feedmug.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Richard Z]

On Mon, Dec 07, 2015 at 12:23:34PM +0100, Lennart Poettering wrote:
> On Mon, 07.12.15 10:48, Tomas Hozza (tho...@redhat.com) wrote:
> 
> > On 04.12.2015 15:57, Lennart Poettering wrote:
> > > On Tue, 01.12.15 11:15, Tomas Hozza (tho...@redhat.com) wrote:

> > As you've said, this is basically an attack and hijacking of someone's
> > else domain name space. It is not correct and it is not expected that
> > this will work with DNSSEC.
> 
> 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

-- 
Name and OpenPGP keys available from pgp key servers
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

Tomasz Torcz wrote:

> On Wed, Dec 16, 2015 at 09:33:18AM -0500, Neal Becker wrote:
>> P J P wrote:
>> 
>> >> On Wednesday, 2 December 2015 6:33 PM, Neal Becker wrote:
>> > 
>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1287607
>> > 
>> > 
>> >   Thank you for filing the bug.
>> > 
>> > 
>> >> * howto prevent dnsmasq from starting (right now I'm just manually
>> >> killing it for testing)
>> > 
>> >   # systemctl disable dnsmasq
>> > 
>> > 
>> 
>> ps aux | grep dns
>> nobody1056  0.0  0.0  57544   484 ?SDec14   0:00
>> /sbin/dnsmasq --conf-file=/var/lib/libvir
>> root  1058  0.0  0.0  5751624 ?SDec14   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?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomasz Torcz]

On Wed, Dec 16, 2015 at 09:33:18AM -0500, Neal Becker wrote:
> P J P wrote:
> 
> >> On Wednesday, 2 December 2015 6:33 PM, Neal Becker wrote:
> > 
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1287607
> > 
> > 
> >   Thank you for filing the bug.
> > 
> > 
> >> * howto prevent dnsmasq from starting (right now I'm just manually
> >> killing it for testing)
> > 
> >   # systemctl disable dnsmasq
> > 
> > 
> 
> ps aux | grep dns
> nobody1056  0.0  0.0  57544   484 ?SDec14   0:00 
> /sbin/dnsmasq --conf-file=/var/lib/libvir
> root  1058  0.0  0.0  5751624 ?SDec14   0:00 
> /sbin/dnsmasq --conf-file=/var/lib/libvir

  Try
systemctl status 1056

I guess it's started by libvirtd.

-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Wed, 2015-12-16 at 10:45 -0500, Neal Becker wrote:
> Tomasz Torcz wrote:
> 
> > On Wed, Dec 16, 2015 at 09:33:18AM -0500, Neal Becker wrote:
> > > P J P wrote:
> > > 
> > > > > On Wednesday, 2 December 2015 6:33 PM, Neal Becker wrote:
> > > > 
> > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1287607
> > > > 
> > > > 
> > > >   Thank you for filing the bug.
> > > > 
> > > > 
> > > > > * howto prevent dnsmasq from starting (right now I'm just
> > > > > manually
> > > > > killing it for testing)
> > > > 
> > > >   # systemctl disable dnsmasq
> > > > 
> > > > 
> > > 
> > > ps aux | grep dns
> > > nobody1056  0.0  0.0  57544   484 ?SDec14   0:00
> > > /sbin/dnsmasq --conf-file=/var/lib/libvir
> > > root  1058  0.0  0.0  5751624 ?SDec14   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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

 
>>> 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?
> 
> I don't know. I don't think the integration with firewalld/NM uses the
> same concept of "zones".
> 
>>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.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On 12/12/2015 09:11 PM, Oron Peled wrote:
> On Friday 11 December 2015 09:09:28 Paul Wouters wrote:
>> On 12/09/2015 06:02 PM, Oron Peled wrote:
>>> 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.
> 
> I'll answer both Paul and Reindl which replied "there's no safe and clean way 
> to solve that"...
> 
>> 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.

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

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

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

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

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.

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

> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Oron Peled]

On Monday 14 December 2015 09:34:56 Paul Wouters wrote:
> On 12/12/2015 09:11 PM, Oron Peled wrote:
> > 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.
> 
> 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.

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

> >* 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 ".local" was considered 
*best-practice*
 by some Microsoft Active Directory setups when this corporation was 
small.

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

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

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

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On 12/14/2015 04:26 PM, Oron Peled wrote:

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

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.

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

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.

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

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

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

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

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

>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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Oron Peled]

On Friday 11 December 2015 09:09:28 Paul Wouters wrote:
> On 12/09/2015 06:02 PM, Oron Peled wrote:
> > 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.

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

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

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

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron
MCSE: Must Consult Someone Experienced
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On 12/09/2015 06:02 PM, Oron Peled wrote:

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

DNS lookups don't have users like web browsers.

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

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 11.12.2015 um 15:09 schrieb Paul Wouters:

On 12/09/2015 06:02 PM, Oron Peled wrote:


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.


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




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Jiri Eischmann]

Paul Wouters píše v St 09. 12. 2015 v 13:37 -0500:
> On 12/09/2015 01:04 PM, Debarshi Ray wrote:
> > On Mon, Dec 07, 2015 at 10:48:55AM +0100, Tomas Hozza wrote:
> > > On 04.12.2015 15:57, Lennart Poettering wrote:
> > > > 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
 

signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Ralf Corsepius]

On 12/11/2015 05:25 PM, Jiri Eischmann wrote:


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.



You can bet what the users would
decide for...
Exactly ... take into account the "user experience" some 
Fedora-"novelties" communicated over the years ;)


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Leon Tester]

Test

> On Dec 11 2015, at 5:08 pm, Ralf Corsepius rc040...@freenet.de
wrote:  

>

> On 12/11/2015 05:25 PM, Jiri Eischmann wrote:

>

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

>

>  You can bet what the users would  
 decide for...  
Exactly ... take into account the "user experience" some  
Fedora-"novelties" communicated over the years ;)

>

> Ralf

>

> \--  
devel mailing list  
devel@lists.fedoraproject.org  




ubiquity.desktop
Description: Binary data
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Petr Spacek]

On 10.12.2015 00:02, Oron Peled wrote:
> On Wednesday 09 December 2015 13:37:12 Paul Wouters wrote:
>> On 12/09/2015 01:04 PM, Debarshi Ray wrote:
>>> 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?

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.

-- 
Petr Spacek  @  Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Debarshi Ray]

On Mon, Dec 07, 2015 at 10:48:55AM +0100, Tomas Hozza wrote:
> On 04.12.2015 15:57, Lennart Poettering wrote:
> > 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

pgptg7jbhfzba.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Fabio Alessandro Locati]

2015-12-09 19:04 GMT+01:00 Debarshi Ray :
> On Mon, Dec 07, 2015 at 10:48:55AM +0100, Tomas Hozza wrote:
>> On 04.12.2015 15:57, Lennart Poettering wrote:
>> > 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On 12/09/2015 01:04 PM, Debarshi Ray wrote:
> On Mon, Dec 07, 2015 at 10:48:55AM +0100, Tomas Hozza wrote:
>> On 04.12.2015 15:57, Lennart Poettering wrote:
>>> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Oron Peled]

On Wednesday 09 December 2015 13:37:12 Paul Wouters wrote:
> On 12/09/2015 01:04 PM, Debarshi Ray wrote:
> > 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?

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron

The most exciting phrase to hear in science, the one that heralds new
 discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
 -- Isaac Asimov
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 08.12.2015 um 10:25 schrieb Petr Spacek:

On 8.12.2015 09:41, Gerd Hoffmann wrote:

   Hi,


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





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Petr Spacek]

On 8.12.2015 09:41, Gerd Hoffmann wrote:
>   Hi,
> 
>> 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?

-- 
Petr Spacek  @  Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Gerd Hoffmann]

  Hi,

> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Florian Weimer]

On 12/07/2015 09:40 PM, Paul Wouters wrote:
> On Mon, 7 Dec 2015, Florian Weimer wrote:
> 
>>> 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.

> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Petr Spacek]

On 7.12.2015 20:35, Lennart Poettering wrote:
> On Mon, 07.12.15 15:31, Björn Persson (Bjorn@rombobjörn.se) wrote:
> 
>> Lennart Poettering  wrote:
>>> 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.
> 
>> 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.

-- 
Petr Spacek  @  Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Matthew Miller]

On Mon, Dec 07, 2015 at 10:17:20AM +0100, Tomas Hozza wrote:
> > 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.

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomas Hozza]

On 07.12.2015 12:23, Lennart Poettering wrote:
> On Mon, 07.12.15 10:48, Tomas Hozza (tho...@redhat.com) wrote:
> 
>> On 04.12.2015 15:57, Lennart Poettering wrote:
>>> On Tue, 01.12.15 11:15, Tomas Hozza (tho...@redhat.com) wrote:
>>>
 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/ 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.

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

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

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

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

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomas Hozza]

On 07.12.2015 14:52, Matthew Miller wrote:
> On Mon, Dec 07, 2015 at 12:23:34PM +0100, Lennart Poettering wrote:
> >> As you've said, this is basically an attack and hijacking of someone's
> >> else domain name space. It is not correct and it is not expected that
> >> this will work with DNSSEC.
> > 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
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Björn Persson]

Lennart Poettering  wrote:
> 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.

> 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


pgpS97kboMIPn.pgp
Description: OpenPGP digital signatur
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Richard Hughes]

On 7 December 2015 at 14:04, Tomas Hozza  wrote:
> 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.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Matthew Miller]

On Mon, Dec 07, 2015 at 03:04:06PM +0100, Tomas Hozza wrote:
> > On Mon, Dec 07, 2015 at 02:59:18PM +0100, Tomas Hozza wrote:
> > >> 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.


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

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomas Hozza]

On 07.12.2015 15:15, Richard Hughes wrote:
> On 7 December 2015 at 14:04, Tomas Hozza  wrote:
>> 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
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Pádraig Brady]

On 01/12/15 15:59, Randy Barlow wrote:
> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Dec 7, 2015 1:49 AM, "Tomas Hozza"  wrote:
>
> On 04.12.2015 15:57, Lennart Poettering wrote:
> > On Tue, 01.12.15 11:15, Tomas Hozza (tho...@redhat.com) wrote:
> >
> >> 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/ 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Lennart Poettering]

On Mon, 07.12.15 13:25, Gerd Hoffmann (kra...@redhat.com) wrote:

>   Hi,
> 
> > 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

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Matthew Miller]

On Mon, Dec 07, 2015 at 02:59:18PM +0100, Tomas Hozza wrote:
> > 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.

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomas Hozza]

On 07.12.2015 15:00, Matthew Miller wrote:
> On Mon, Dec 07, 2015 at 02:59:18PM +0100, Tomas Hozza wrote:
> >> 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
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Björn Persson]

Lennart Poettering  wrote:
> 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/ 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


pgpGCbE90xnKI.pgp
Description: OpenPGP digital signatur
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Matthew Miller]

On Mon, Dec 07, 2015 at 12:23:34PM +0100, Lennart Poettering wrote:
> > As you've said, this is basically an attack and hijacking of someone's
> > else domain name space. It is not correct and it is not expected that
> > this will work with DNSSEC.
> 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.



-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 07.12.2015 um 15:56 schrieb Pádraig Brady:

On 01/12/15 15:59, Randy Barlow wrote:

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


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




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomas Hozza]

On 07.12.2015 16:44, Andrew Lutomirski wrote:
>
> On Dec 7, 2015 1:49 AM, "Tomas Hozza"  > wrote:
> >
> > On 04.12.2015 15:57, Lennart Poettering wrote:
> > > On Tue, 01.12.15 11:15, Tomas Hozza (tho...@redhat.com 
> > > ) wrote:
> > >
> > >> 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/ 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
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer 

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomas Hozza]

On 05.12.2015 18:57, Florian Weimer wrote:
> On 11/30/2015 05:14 PM, Jan Kurik wrote:
>> 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

> Thanks,
> Florian
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 

-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Lennart Poettering]

On Mon, 07.12.15 10:48, Tomas Hozza (tho...@redhat.com) wrote:

> On 04.12.2015 15:57, Lennart Poettering wrote:
> > On Tue, 01.12.15 11:15, Tomas Hozza (tho...@redhat.com) wrote:
> > 
> >> 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/ 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.

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

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

> 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 

Re: F24 System Wide Change: Default Local DNS Resolver

[Gerd Hoffmann]

  Hi,

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

> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Lennart Poettering]

On Mon, 07.12.15 10:15, Tomas Hozza (tho...@redhat.com) wrote:

> On 05.12.2015 18:57, Florian Weimer wrote:
> > On 11/30/2015 05:14 PM, Jan Kurik wrote:
> >> 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...

> 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

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Scott Schmit]

On Mon, Dec 07, 2015 at 04:12:20PM +0100, Lennart Poettering wrote:
> On Mon, 07.12.15 13:25, Gerd Hoffmann (kra...@redhat.com) wrote:
> > > 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.

-- 
Scott Schmit


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Lennart Poettering]

On Mon, 07.12.15 17:23, Tomas Hozza (tho...@redhat.com) wrote:

> > Can you elaborate a bit?  Is the intent that, if .box were private, then 
> > .box would be forwarded to DHCP-provided revolvers regardless of whether 
> > those resolvers were functional when asking for DNSSEC signature data?
> >
> > If so, what cases does this not cover?  It fails in the split-horizon 
> > DNSSEC-enabled case where the domain owner hasn't set it up right, but I'd 
> > argue that that's a good thing.
> 
> 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

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Lennart Poettering]

On Mon, 07.12.15 15:31, Björn Persson (Bjorn@rombobjörn.se) wrote:

> Lennart Poettering  wrote:
> > 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.

> 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

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Mon, Dec 7, 2015 at 11:31 AM, Lennart Poettering
 wrote:
> On Mon, 07.12.15 17:23, Tomas Hozza (tho...@redhat.com) wrote:
>
>> > Can you elaborate a bit?  Is the intent that, if .box were private, then 
>> > .box would be forwarded to DHCP-provided revolvers regardless of whether 
>> > those resolvers were functional when asking for DNSSEC signature data?
>> >
>> > If so, what cases does this not cover?  It fails in the split-horizon 
>> > DNSSEC-enabled case where the domain owner hasn't set it up right, but I'd 
>> > argue that that's a good thing.
>>
>> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Mon, 7 Dec 2015, Lennart Poettering wrote:


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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 07.12.2015 um 20:48 schrieb 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



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Mon, 7 Dec 2015, Matthew Miller wrote:


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 ?


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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Florian Weimer]

On 12/07/2015 08:31 PM, Lennart Poettering wrote:

> 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
 and you'll switch
systemd from “gateway” to something like “_gateway”, which cannot collide?

Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Florian Weimer]

On 12/07/2015 07:21 PM, Paul Wouters wrote:

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

> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Mon, 7 Dec 2015, Lennart Poettering wrote:


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.


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?


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.


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


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.


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.


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.


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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fwd: Re: F24 System Wide Change: Default Local DNS Resolver (fwd)

[Paul Wouters]

(resending - looks like mty @redhat.com is not subscribed)

On 12/07/2015 04:48 AM, Tomas Hozza wrote:


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

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

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!


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.


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


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.


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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Mon, 7 Dec 2015, Florian Weimer wrote:


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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 07.12.2015 um 21:40 schrieb Paul Wouters:

On Mon, 7 Dec 2015, Florian Weimer wrote:


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



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Oron Peled]

On Monday 07 December 2015 14:57:36 Paul Wouters wrote:
> 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 "
   (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,

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron

"A standard for copy protection is as premature as a standard for 
teleportation."
--- Noted computer security expert and Princeton University Professor Edward 
Felten.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Björn Persson]

Lennart Poettering  wrote:
> On Mon, 07.12.15 15:31, Björn Persson (Bjorn@rombobjörn.se) wrote:
> 
> > Lennart Poettering  wrote:
> > > 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On 12/07/2015 04:48 AM, Tomas Hozza wrote:

>> 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/ 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
>> 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
>> 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!

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

> 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

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

>> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Scott Schmit]

On Mon, Dec 07, 2015 at 08:49:03AM -0500, Matthew Miller wrote:
> On Mon, Dec 07, 2015 at 10:17:20AM +0100, Tomas Hozza wrote:
> > > 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.

-- 
Scott Schmit


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Florian Weimer]

On 12/04/2015 09:46 PM, Dan Williams wrote:
> On Fri, 2015-12-04 at 16:09 +0100, Timotheus Pokorra wrote:
>>> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Florian Weimer]

On 11/30/2015 05:14 PM, Jan Kurik wrote:
> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Lennart Poettering]

On Tue, 01.12.15 11:15, Tomas Hozza (tho...@redhat.com) wrote:

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

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Timotheus Pokorra]

> 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
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Björn Esser]

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

Am 04.12.2015 16:09 schrieb Timotheus Pokorra 
:
>
> > 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 
> devel@lists.fedoraproject.org 
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org 
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Fri, 2015-12-04 at 16:09 +0100, Timotheus Pokorra wrote:
> > 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[P J P]

> On Wednesday, 2 December 2015 6:33 PM, Neal Becker wrote:

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


  Thank you for filing the bug.


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

  # systemctl disable dnsmasq


> * howto get domainname set automatically from dhcp



  Dhcp configuration manual should help with that.

---
  -P J P
http://feedmug.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomas Hozza]

On 02.12.2015 14:03, Neal Becker wrote:
> Neal Becker wrote:
> 
>> P J P wrote:
>>
>>> Hello Neal,
>>>
 On Wednesday, 2 December 2015 1:03 AM, Neal Becker wrote:
 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.
>>
>> 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)

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.

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

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

-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

P J P wrote:

> Hello Neal,
> 
>> On Wednesday, 2 December 2015 1:03 AM, Neal Becker wrote:
>> 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.

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


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

P J P wrote:

> Hello Neal,
> 
>> On Wednesday, 2 December 2015 1:03 AM, Neal Becker wrote:
>> 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.

Also, I think we need it to work out-of-the-box.  Editing a config file is 
not working out-of-the-box.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Neal Becker]

Neal Becker wrote:

> P J P wrote:
> 
>> Hello Neal,
>> 
>>> On Wednesday, 2 December 2015 1:03 AM, Neal Becker wrote:
>>> 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.
> 
> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Tue, 1 Dec 2015, Randy Barlow wrote:


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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[P J P]

Hello Neal,

> On Wednesday, 2 December 2015 1:03 AM, Neal Becker wrote:
> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[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.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[P J P]

Hello Vit,

> On Tuesday, 1 December 2015 1:45 PM, Vít Ondruch wrote:
> > 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[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

On 01.12.2015 09:14, Vít Ondruch wrote:
> If I am not mistaken, this is at least 3rd time this change is proposed.
> Can somebody post some short summary what was changed, that you believe
> it will be successful this time?
>
> Thx
>
>
> Vít
>
>
> Dne 30.11.2015 v 17:14 Jan Kurik napsal(a):
> > = Default Local DNS Resolver =
> > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> >
> > Change owner(s):
> > * P J P 
> > * Pavel Šimerda 
> > * Tomas Hozza 
> > * Petr Špaček 
> >
> > 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 

Re: F24 System Wide Change: Default Local DNS Resolver

[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


Dne 30.11.2015 v 17:14 Jan Kurik napsal(a):
> = Default Local DNS Resolver =
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>
> Change owner(s):
> * P J P 
> * Pavel Šimerda 
> * Tomas Hozza 
> * Petr Špaček 
>
> 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
> 

Re: F24 System Wide Change: Default Local DNS Resolver

[Björn Persson]

Tomas Hozza  wrote:
> - 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


pgpw0576kFeWU.pgp
Description: OpenPGP digital signatur
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomas Hozza]

On 01.12.2015 16:06, Björn Persson wrote:
> Tomas Hozza  wrote:
> > - 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
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[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?

-- 
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc:  bowlofeggs on Freenode



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomas Mraz]

On Út, 2015-12-01 at 11:15 +0100, Tomas Hozza wrote:
> 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

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

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Tomas Hozza]

On 01.12.2015 13:28, Tomas Mraz wrote:
> On Út, 2015-12-01 at 11:15 +0100, Tomas Hozza wrote:
> > 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
>
> 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
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Tue, 1 Dec 2015, Björn Persson wrote:


Tomas Hozza  wrote:

- 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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 
* Pavel Šimerda 
* Tomas Hozza 
* Petr Špaček 

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.

-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org

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 
* Pavel Šimerda 
* Tomas Hozza 
* Petr Špaček 

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.

-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Russell Doty]

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

On Mon, 2015-11-30 at 17:14 +0100, Jan Kurik wrote:
> = Default Local DNS Resolver =
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> 
> Change owner(s):
> * P J P 
> * Pavel Šimerda 
> * Tomas Hozza 
> * Petr Špaček 
> 
> 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
> 

Re: F24 System Wide Change: Default Local DNS Resolver

[P J P]

Hello Russell,

> On Tuesday, 1 December 2015 12:21 AM, Russell Doty wrote:
>> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Steve Grubb]

On Monday, November 30, 2015 01:50:54 PM Russell Doty wrote:
> 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


> On Mon, 2015-11-30 at 17:14 +0100, Jan Kurik wrote:
> > = Default Local DNS Resolver =
> > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> > 
> > Change owner(s):
> > * P J P 
> > * Pavel Šimerda 
> > * Tomas Hozza 
> > * Petr Špaček 
> > 
> > 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
>