(resending - looks like mty @redhat.com is not subscribed)

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@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Reply via email to