On Dec 7, 2015 1:49 AM, "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.
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