search

namecoin / meta

General-Purpose Namecoin Repository
4 stars 3 forks source link

Dnssec-Trigger + ncdns doesn't play well with non-DNSSEC upstream DNS #46

Open JeremyRand opened 7 years ago

JeremyRand commented 7 years ago

There are 2 cases where Dnssec-Trigger encounters DNSSEC-related problems:

  1. Dnssec-Trigger probe detects that DNSSEC is broken, and warns the user.
  2. Dnssec-Trigger probe fails to detect that DNSSEC is broken, but Unbound rejects upstream DNS responses. (See IRC logs on #namecoin from 2016 Oct 09; it appears that using a WiFi router whose DNS is set to OpenDNS triggers this behavior.)

In case 1, when the user chooses to access DNS anyway, Dnssec-Trigger removes Unbound from the DNS chain. This kills access to .bit domains, and therefore constitutes a censorship-resistance vulnerability for Namecoin. It doesn't impact MITM-resistance.

In case 2, .bit domains still work, but DNS domains do not work. This constitutes a UX problem, but doesn't impact MITM-resistance or censorship-resistance. It should be noted that this scenario is probably a bug in Dnssec-Trigger and will be replaced by case 1 when that bug is fixed.

There are a few ways we might be able to work around this:

  1. To fix case 1, when the user authorizes insecure DNS, Dnssec-Trigger should set Unbound to use val-permissive-mode: yes instead of removing Unbound from the DNS chain. This would require changes to Dnssec-Trigger; maybe we should contact NLnet Labs about this. (Setting that property in unbound.conf.d via our installer script should fix case 2, but I don't recommend this since it's insecure for DNS domain names.)
  2. On Windows, we could probably use the DNS TLD registry hack from NMControl, so that .bit requests always get routed to Unbound even when Unbound is removed from the DNS chain by Dnssec-Trigger. I don't think there's any similar hack for GNU/Linux; I am skeptical that macOS has one. This shouldn't have any impact on security.
JeremyRand commented 7 years ago

(Note that this is filed in the Meta repo since it's not an ncdns bug, and it doesn't seem to be specific to a given OS's install scripts.)

JeremyRand commented 7 years ago

CC: @hlandau

JeremyRand commented 7 years ago

Workaround 2 might also be useful as an optional mode for users who don't want to deal with the performance issues of Unbound and who are okay with not having DNSSEC protection for DNS domain names.

JeremyRand commented 6 years ago

To fix case 1, when the user authorizes insecure DNS, Dnssec-Trigger should set Unbound to use val-permissive-mode: yes instead of removing Unbound from the DNS chain. This would require changes to Dnssec-Trigger; maybe we should contact NLnet Labs about this. (Setting that property in unbound.conf.d via our installer script should fix case 2, but I don't recommend this since it's insecure for DNS domain names.)

This is actually a bad idea, because it will probably cause DNSSEC-delegated .bit domains to lose MITM-resistance.

It should be noted that Case 1 is probably relevant to bundling ncdns with ZeroNet; since ZeroNet is commonly used in China -- I suspect that Dnssec-Trigger will detect DNSSEC errors and break ncdns resolution when behind the GFW.

Does Dnssec-Trigger's DNS over TLS functionality support SOCKS proxying? If it does, then hypothetically we could route it over Tor as a workaround.

JeremyRand commented 6 years ago

I suspect that Dnssec-Trigger will detect DNSSEC errors and break ncdns resolution when behind the GFW.

Citation Needed (TM).