On Dec 7, 2015 1:49 AM, "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.
>
> 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@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
