Home » Trisquel » Issues
Submitted by lembas on Thu, 08/08/2013 - 09:15

Trisquel defaults to using google's name servers

Project:Trisquel
Version:6.0
Component:Misc
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed
Description

If you take a look at /etc/resolv.conf, you'll find 8.8.8.8 there which is google's DNS. This is not a wonderful choice from a privacy view point.

That file is apparently dynamically created by resolvconf adding content from /etc/resolvconf/resolv.conf.d/tail

There is also some other name server, 213.186.33.99, whois says it's "OVH SAS" in France. Apparently it's an ISP. Looks like they stood up for Wikileaks (of course, giving in to banning sites would mean a huge hassle to them so perhaps this decision wasn't entirely altruistic) https://en.wikipedia.org/wiki/OVH#WikiLeaks

I'm no expert on this subject. Do we even need such defaults?

lembas:
Thu, 08/08/2013 - 21:16

FWIW I also started a thread about this https://trisquel.info/en/forum/you-might-be-using-google-name-server

G4JC:
Mon, 08/12/2013 - 01:03

This is a pretty serious issue in my oppinion. It may be better to use OpenDNS since they offer this:
http://blog.opendns.com/2010/02/23/opendns-dnscurve/

This could be packaged with Trisquel -
https://github.com/opendns/dnscrypt-proxy (BSD License)

Basically even though "they" could still log you, no one over the network could. This is a big plus - especially over public wifi.

lloydsmart:
Mon, 08/19/2013 - 17:40

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

DNSCurve/DNSCrypt is a great technology, and OpenDNS are to be commended for supporting it. However, I'd rather not have OpenDNS as the default nameserver for Trisquel if we can avoid it. They practice nxdomain hijacking by default.

OpenNIC would be a better choice, IMO. It's just a shame they don't support DNSCrypt. That would make them perfect. But anyone who's that worried about their DNS being spied on should be directing it through a VPN, anyway.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAlISSmsACgkQgijxUCZnvlvO7wEAyYj1qogF6hAtNQfgjVHiZADN
7CK7PkdcXzhBEJBXW6ABAJdWCdyRPeWuP6U/+78KQ4Y9aSnusvcC6eH7TIGMwEmb
=2BVX
-----END PGP SIGNATURE-----

lloydsmart:
Mon, 08/19/2013 - 17:42

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Of course, the default should be to obtain DNS server addresses through DHCP if possible. The system should only fall back to pre-defined DNS servers if the DHCP server doesn't nominate a DNS server.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAlISSt4ACgkQgijxUCZnvls9gQD+JQoJkm3Xmm4Nu+ISoXI8Nj8x
U5OjuRH5W2xDsfjSxqwBAMDbLYuQSU9MRpl8jIHGMYwi1IqmzKtgGkfrPWEZv3UC
=+nnn
-----END PGP SIGNATURE-----

quidam:
Fri, 08/23/2013 - 17:40

I've just researched this and it is true, that configuration leaked from the build server's own configuration, which it's used during the build process for the iso image.

The resolv.conf file is emptied in the clean-up process for the image, but apparently recent versions of the avahi-daemon make a copy of that file when installed, and those settings are used as a fallback from that point on. Those servers should in any case be queried only if the nameserver set by dhclient (the one the router suggests) fails to resolve the request.

I'm adding those files (/etc/resolvconf/resolv.conf.d/*) to the clean-up process so newly produced images will not have that fallback. I'll be spinning new images both for Trisquel and for the FSF membership card during the weekend.

kete:
Tue, 10/01/2013 - 03:51

Is there a way to make this a package update or to announce (how) we should fix it?

Legimet:
Sun, 06/21/2015 - 19:58
Status:active» fixed

This was fixed in 6.0.1.

quidam:
Sun, 07/05/2015 - 20:00
Status:fixed» closed

Automatically closed -- issue fixed for 2 weeks with no activity.