On 07.12.2015 16:44, Andrew Lutomirski wrote:
On Dec 7, 2015 1:49 AM, "Tomas Hozza" <thozza(a)redhat.com
<mailto:thozza@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
<mailto:thozza@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.
>
> 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
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc.
http://cz.redhat.com