On Mon, 07.12.15 10:48, Tomas Hozza (thozza(a)redhat.com) wrote:
On 04.12.2015 15:57, Lennart Poettering wrote:
> On Tue, 01.12.15 11:15, Tomas Hozza (thozza(a)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/AAAA RRs for *.box. Now, one can certainly argue that
> this is borked, since the manufacturer doesn't own the ".box" domain,
> but discussing this is pretty pointless, as the fact that this is what
> is deployed in probably half of the homes in Germany... Also I am
> pretty sure other routers form other manufacturers do the same
> thing. Now, if we default to DNSSEC validation soon, does this mean
> people won't be able to configure their wifi routers anymore, or reach
> other systems on their home networks anymore, because the NSEC/NSEC3
> RRs in the root domain claim .box does not exist? What's your
> strategy there? Why do you think DNSSEC is worth breaking pretty much
> everybody's network? Note that Fritzbox is not a random crappy router,
> it's probably of the better products you can find.
As you've said, this is basically an attack and hijacking of someone's
else domain name space. It is not correct and it is not expected that
this will work with DNSSEC.
Humm, I find that way too cavalier... I am pretty sure this is a total
deal breaker for your feature. You cannot just break everybody's
network and not consider that a problem that *you* have to think about
rather than just ignoring it completely.
The ".box" domain is not owned by anyone, at least currently, it's
certainly not "hijacking" of anybody else's domain name space.
But it really doesn't matter whether that's hijacking or not. What
matters is that a large number of setups are like that... And you
break them by default, and apparently don't consider this a problem.
Quite frankly: a setup like this one isn't just very typical for home
router networks, but also in many companies, where ".lan" or
".companyname" or something like that is frequently established in the
internal network. And you will make Fedora incompatible with all these
networks by default.
The way you proposed your feature this has no place at all on the
desktop I am sure, where systems migrate between networks all the
time, and sometimes quite shitty networks. I am very sure that most
Fedora users would prefer their internet to work, rather than be
"pretend-safe", after all DNSSEC is neither necessary for safe
connections nor enables otherwise unsafe connections to be suddenly
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
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 ,
so once it is standardized, it could be done for these
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
, 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
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
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?
> MacOS, iOS, Android, ChromeOS? Does any of them do client-side DNSSEC
> validation by default and how are they dealing with this issue?
I'm not able to answer this question.
It's probably a good idea to do your homework first, and see what
others do, before coming up with a proposal.
(Disclaimer on all of this: we are working on adding DNSSEC support to
systemd-resolved, and about ways to make this available by default,
without breaking too much stuff. I am convinced that the stuff we are
working on there is definitely the better approach in the end, than
this current feature proposal. But of course, the DNSSEC support in
resolved is still being worked on, it's not ready yet, and I will not
file a proposal about this anytime time soon. It's just that these
problems come up when you work on this, and you need to find a
sufficiently good solution for it, and this feature has not)
Lennart Poettering, Red Hat