On Wed, 17 Jun 2015, Tomas Hozza wrote:
While I don't actually care, this might well be a sticking point for
many people since their DNS information is going to an untrusted (to
them) DNS server. Yeah, I tend to trust Fedora, but not everyone will.
If you don't trust fedora infrastructure, you have more issues
though....
Can the tunnel be turned off, or the broken servers whitelisted, or is
the answer here to just "dnf remove dnssec-trigger"?
Yes. It is all configured in /etc/dnssec-trigger/dnssec-triggerd.conf
The fallback infrastructure is used as the last resort of DNS data
source. Full recursion is preferred over the fallback servers.
And full recursion means your privacy might be in even more danger too
until the IETF dprive comes up with DNS privacy protocols.....
If someone is trusting a DNS server without using DNSSEC, that that
person is not really aware of the potential security implications of
such name resolution. With DNSSEC validation done locally, it is
irrelevant what DNS servers are uses, as long they can provide all the
DNSSEC data.
I think DNS privacy was the issue here, not security. Eg the fact that
fedora servers see your DNS queries for evil.com. There are no logs kept
of queries to these servers. I think we would discontinue the service
before adding logging to them.
It is not like Fedora infrastructure is collecting data about which user
is resolving which name. Although ANY DNS service provider can do that!
If user wants to use broken nameservers, they can switch the
dnssec-trigger to "hotspot sign-on" mode. I agree that this is
completely not intuitive and should be rather named "insecure mode".
Practically this means that the DHCP provided resolvers are placed into
resolv.conf and the user is free to shoot themselves into the feet.
And your VPN DNS forwards are no longer used, so if you have a VPN up,
then going into "insecure mode" means your network behind the VPN
becomes basically unreachable. The hotspot/insecure mode is not a "dont
trust fedora mode". People should not use that way.
Also turning off the dnssec-triggerd.service is a solution, since it
will clean up after itself and return back the system to the "original"
state. Of course you can remove it if you wish :)
But that would affect all users. Granted, we are probably talking
about private laptops here. But in theory one should disable
dnssec-trigger-panel on a per-user basis, and not stop the system service.
systemd-resolved plans to do just a kind of "best effort" DNSSEC, at
least from what I asked on the Linux PLumbers Conference in Dusseldorf
last year on the Tom Gundersen's presentation. This means they will do
the validation, but only if they are able to. They don't plan and don't
want to do any fallback to external infrastructure, but rather want to
turn off the validation. I'm not sure if this is still the case, but it
was. This is exactly what we don't want to do with dnssec-trigger and
Unbound. We will try really hard to do DNSSEC validation.
A design that will just turn it off DNSSEC, possibly even silenly,
seems like the wrong approach. I assume we are misunderstanding the
systemd-resolvd goals here, and will let the systemd people explain
their design.
If this is indeed what you're proposing, then lets have a discussion
about dnssec-trigger+unbound in that context, I do have some thoughts to
contribute here.
Good, we are open to thoughts and ideas ;)
Indeed, I'm curious to what others have to say. Clearly, I have a
somewhat strong bias toward DNSSEC :)
Paul
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
