On Dec 7, 2015 1:49 AM, "Tomas Hozza" <tho...@redhat.com> wrote: > > On 04.12.2015 15:57, Lennart Poettering wrote: > > On Tue, 01.12.15 11:15, Tomas Hozza (tho...@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
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
