On 17.06.2015 16:22, Paul Wouters wrote: > 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. Right, although it would be technically possible to also add VPN resolvers to resolv.conf in "hotspot signon mode" it is not the goal of the mode. > > 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. Right, I meant it for the single-user machine. Disabling the panel will not turn off the dnssec-trigger itself, so I don't think it would solve anything other than getting rid of the UI popup windows. > > 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. I hope, too. :) > >> 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 Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct