Re: F24 System Wide Change: Default Local DNS Resolver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07.12.2015 12:23, Lennart Poettering wrote:
> On Mon, 07.12.15 10:48, Tomas Hozza (thozza@xxxxxxxxxx) wrote:
> 
>> On 04.12.2015 15:57, Lennart Poettering wrote:
>>> On Tue, 01.12.15 11:15, Tomas Hozza (thozza@xxxxxxxxxx) 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/AAAA RRs for *.box. Now, one can certainly argue that
>>> this is borked, since the manufacturer doesn't own the ".box" domain,
>>> but discussing this is pretty pointless, as the fact that this is what
>>> is deployed in probably half of the homes in Germany... Also I am
>>> pretty sure other routers form other manufacturers do the same
>>> thing. Now, if we default to DNSSEC validation soon, does this mean
>>> people won't be able to configure their wifi routers anymore, or reach
>>> other systems on their home networks anymore, because the NSEC/NSEC3
>>> RRs in the root domain claim .box does not exist?  What's your
>>> strategy there?  Why do you think DNSSEC is worth breaking pretty much
>>> everybody's network? Note that Fritzbox is not a random crappy router,
>>> it's probably of the better products you can find.
>>
>> As you've said, this is basically an attack and hijacking of someone's
>> else domain name space. It is not correct and it is not expected that
>> this will work with DNSSEC.
> 
> Humm, I find that way too cavalier... I am pretty sure this is a total
> deal breaker for your feature. You cannot just break everybody's
> network and not consider that a problem that *you* have to think about
> rather than just ignoring it completely.

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

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

>> I don't think there is any universal or even right solution to this. Once you
>> start doing such hacks, there is a very thin line when you are starting to degrade
>> the security gained by using DNSSEC.
> 
> I am pretty sure there are solutions possible that are simple and safe
> enough to fix these problems. For example, after doing a proof of
> non-existance on a top-level domain, permit it anyway, but only
> those. That way, people won't be able to add in extra RRs below
> microsoft.com, but they could define additional top-level domains such
> as .box without this creating problems.

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

>> So the answer is that it could be doable for some cases and if the user
>> explicitly specifies some set of domains. However I don't think this will
>> solve all the issues with ISP's and hardware vendors trying to be smart
>> while actually breaking the RFCs and hijacking the domain name
>> space.
> 
> Well, ffs, you cannot discount everybody's setups as just "breaking
> RFCs" and "hijacking" domains, and then ignore them.
> 
> You know, I am certainly not the person who wouldn't agree to the
> concept of breaking eggs to make an omelette. But it's completely
> unnacceptable to go to the supermarket and break everybody else's eggs
> too, just because you want to make yourself one little omelette...
> 
>>> How do other popular desktop/consumer OSes deal with this? Windows,
>>> MacOS, iOS, Android, ChromeOS? Does any of them do client-side DNSSEC
>>> validation by default and how are they dealing with this issue?
>>
>> I'm not able to answer this question.
> 
> It's probably a good idea to do your homework first, and see what
> others do, before coming up with a proposal. 

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

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


Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux