Bug#761658: Please do not default to using Google nameservers

Christoph Anton Mitterer calestyo at scientia.net
Sun Mar 29 21:03:24 BST 2015


On Sun, 2015-03-29 at 12:47 +0200, Marco d'Itri wrote: 
> So far, it is. If you still want to argue about this (which I something
> that I strongly recommend against!), then you should explain in detail 
> the threat model that you are trying to address and how the current 
> configuration would be worse than other configurations.
The original reporter, I and some others did so before. I don't see a
point in repeating an explanation of the same thread model over and over
again.
Either it's as it is, or the documentation is at least misleading.


> > $ geoiplookup 8.8.8.8
> > GeoIP Country Edition: US, United States
> traceroutes from multiple non-US locations may surprise you.
$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  [snip snap]
 2  [snip snap]
 3  [snip snap]
 4  93.104.240.55 (93.104.240.55)  24.388 ms  24.773 ms  25.538 ms
 5  209.85.253.113 (209.85.253.113)  25.002 ms 64.233.175.121 (64.233.175.121)  25.131 ms 209.85.252.215 (209.85.252.215)  25.808 ms
 6  google-public-dns-a.google.com (8.8.8.8)  25.623 ms  15.634 ms  15.724 ms
calestyo at heisenberg:~$ geoiplookup 209.85.253.113
GeoIP Country Edition: US, United States
calestyo at heisenberg:~$ geoiplookup 64.233.175.121
GeoIP Country Edition: US, United States
calestyo at heisenberg:~$ geoiplookup 209.85.252.215
GeoIP Country Edition: US, United States

Nope, not really a surprise. And I'm Germany based.
Unless all these hops would be anycasted, traffic goes into the US.
And even if not, there is nothing that guarantees that this would never
change, and even if, it's well known that subsidiaries of US companies
are forced by US law to obey to US governmental agencies.


> I argue that alternative DNS roots are firmly in the camp of net.kooks, 
> and there is more than enough history to support this.
> Were you around at the time of the newdom mailing list? Fun times...
> Be careful of who you choose to associate with, because you will be 
> judged by your peers for it.
I haven't said that *I* would endorse the switch to OpenNIC, have I?
Quite the contrary actually.
This was just an example that Michael should try to stay calm an not
open a CoC case just because someone doesn't share his views.


> I did, in my reply. Short summary: have a resolv.conf file or use DHCP.
As stated by the others, this is both non-obvious and non-standards
behaviour, i.e. explicitly having to opt-out of
default-Google-name-resolution (and potentially/likely
surveillance/tracking).
Now I'm for sure not a traditionalist who wants to keep things as they
are just per se, but here I see only disadvantages in changing the way
it used to be.
No nameservers configured - no resolution. Done.

What comes next? A google or aol account that's automatically set up
with Debian installation? Which of course has no "direct" disadvantage
to the user. Still it would be wrong.


> Then maybe you should work in the IETF to establish either:
> - well know IP addresses which will provide recursive DNS service (this 
>   may even work now that we have DNSSEC)
Such a thing doesn't exist, because it's not necessary + would be bad
design.
For autoconfiguration of systems (including the resolvers) we already
have plenty of mechanisms.


> - a best practice of running a caching resolver on every end user system 
>   (I highly doubt that this would be considered a good idea)
I don't see how this affects this topic?
But apart from that, it will probably be "the future", at least when
people want locally verified DNSSEC resolution.


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150329/23688080/attachment-0002.bin>


More information about the Pkg-systemd-maintainers mailing list