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. Our use of the mixed-mode module expects, that the network-provided resolvers are not DNSSEC capable. This means, that in a situation when the network-provided resolvers are determined to be DNSSEC capable (based on some set of tests), but then they return BOGUS answers, e.g. claiming that there is a TLD, but can not provide the signatures, Unbound would most probably return SERVFAIL. I'm not sure if this is the case with the German ISP's-provided routers. I don't think there is any universal or even right solution to this. Once you start doing such hacks, there is a very thin line when you are starting to degrade the security gained by using DNSSEC. So the answer is that it could be doable for some cases and if the user explicitly specifies some set of domains. However I don't think this will solve all the issues with ISP's and hardware vendors trying to be smart while actually breaking the RFCs and hijacking the domain name space. > How do other popular desktop/consumer OSes deal with this? Windows, > MacOS, iOS, Android, ChromeOS? Does any of them do client-side DNSSEC > validation by default and how are they dealing with this issue? I'm not able to answer this question. > Lennart > [1] http://www.ietf.org/mail-archive/web/dnsop/current/msg16208.html [2] https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/UnboundMixedMode [3] http://www.ietf.org/mail-archive/web/dnsop/current/msg16209.html Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
