On 07.12.2015 16:44, Andrew Lutomirski wrote: > > On Dec 7, 2015 1:49 AM, "Tomas Hozza" <thozza@xxxxxxxxxx <mailto:thozza@xxxxxxxxxx>> wrote: > > > > On 04.12.2015 15:57, Lennart Poettering wrote: > > > On Tue, 01.12.15 11:15, Tomas Hozza (thozza@xxxxxxxxxx <mailto: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. 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 > --Andy > > > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx > -- 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
