On 12/07/2015 04:48 AM, Tomas Hozza wrote: >> 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... Well, there is going to be a very interesting lawsuit about damage then because in a few months .box will be live run by a Hong Kong company called "NS1 Limited" https://www.icann.org/resources/agreement/box-2015-11-12-en .box Registry Agreement 12 Nov 2015 On 12 November 2015, ICANN and NS1 Limited, entered into a Registry Agreement under which NS1 Limited, operates the .box top-level domain. [....] Clearly, fedora cannot be changed to hijack a real domain, so Fritzbox better solve this quickly with an update, even if no one actually will update their router :( We can make some web page available that will explain how to configure unbound with an override, but I guess it will be a different IP for everyone? Assuming your fritz.box is 192.168.1.1 you can do: echo ' local-data: "fritz.box. 3600 IN A 192.168.1.1"' > /etc/unbound/local.d/fritz.box.conf Of course you can also use /etc/hosts 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? Don't they work when you use http://192.168.1.1/ ? 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. See above. It's going to get broken anyway. Actually, this could be a security nightmare if someone registers fritz.box and will start receiving connections for IP address that give them their router passwords! > 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. That only works if .box is not delegated. Unfortunately, it will be very soon. Initially it will resolve to 127.0.53.53 when the TLD is brought up. So hopefully that will cause people to safely see the failure mode. Only after the domain has launched fully will someone be able to possibly register fritz.box maliciously. > 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. Actually DNS servers will either fail those queries, or they will be targeted at the global blackhole running via AS112 > 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. Worse, we open up ourselves for legal issues if the domain is delegated. >> 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. It will start failing for people irrespective of DNSSEC. Paul -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
