Trisquel defaults to using google's name servers

Categoria:segnalazione di bug
Assigned:Non assegnata

If you take a look at /etc/resolv.conf, you'll find 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,, 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)

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

Gio, 08/08/2013 - 22:16
Lun, 08/12/2013 - 02:03

This is a pretty serious issue in my oppinion. It may be better to use OpenDNS since they offer this:

This could be packaged with Trisquel - (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.

Lun, 08/19/2013 - 18:40

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.
Version: GnuPG v1.4.11 (GNU/Linux)


Lun, 08/19/2013 - 18:42

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.
Version: GnuPG v1.4.11 (GNU/Linux)


Ven, 08/23/2013 - 18: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.

Mar, 10/01/2013 - 04:51

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

Dom, 06/21/2015 - 20:58
Stato:active» fixed

This was fixed in 6.0.1.

Dom, 07/05/2015 - 21:00
Stato:fixed» closed

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