
Google Public DNS turns 8.8.8.8 years old - tomweingarten
https://security.googleblog.com/2018/08/google-public-dns-turns-8888-years-old.html
======
jchw
Google's DNS service is interesting. I was never really sure what the business
case for operating a public DNS resolver is, for any company really, but it
was warmly welcomed when it was unveiled, at least for me. At the time, the
public DNS resolvers I can recall were mostly oriented around blocking
content.

A lot of people are worried about the privacy implications of using Google's
DNS resolver. Paranoia is good, but it's probably overblown here. As far as I
know, the primary objective of the project is to provide a fast, accurate DNS
resolver, not to collect data. So much so that when it launched, it was
originally called 'Honest DNS', as you can see on this bizarre Twitter
account: [https://twitter.com/honestdns](https://twitter.com/honestdns)

edit: Also of interest, Google does disclose exactly what data is logged, for
the paranoid and curious: [https://developers.google.com/speed/public-
dns/privacy](https://developers.google.com/speed/public-dns/privacy)

(Disclaimer: I work for Google, but not on this. All of my knowledge of this
service comes from being an end user, on the outside. Hopefully I didn't mess
up any of the details.)

~~~
hkai
Google has done nothing so far to substantiate any trust in them. The "don't
be evil" motto was abandoned.

It is a business that relies on collecting data, monetizing it, and using it
to further reinforce its position.

~~~
uluyol
While Google's business model certainly relies on collecting and monetizing
user data, I have yet to see any cases of abuse on their part. Rules for
employee data access are very strict and I don't know of any cases whee they
directly share data with third parties (excluding government demands).

For me, this makes them one of the most trustworthy companies when it comes to
handling my data. If you know of any cases otherwise, I would love to hear
about them.

~~~
a_imho
Google abuses its position plenty and was found to be guilty in court multiple
times.

There are endless examples of shady practices on Google's part, the obvious
elephant in the room is ignoring the GDPR.

------
zokier

        In [1]: (8<<24) | (8<<16) | (8<<8)| 8
        Out[1]: 134744072
    

Oh how the time just flies past.

Incidentally there are 10 types of people, those who understand binary and
those who try to write too clever headlines.

~~~
pgeorgi
they could have used that ~4 years ago with seconds.

~~~
d0mine
Exactly.

    
    
      >>> dt = pendulum.datetime(2018, 8, 12, 0, 30)  # from the article
      >>> born = dt.subtract(years=8, months=8, days=8, hours=8)
      >>> born.add(seconds=int(ipaddress.ip_address('8.8.8.8')))
      <Pendulum [2014-03-12T05:24:32+00:00]>

------
Aardwolf
Too bad it wasn't launched 4 days earlier so this could have been on
2018-08-08

------
vermaden
There are also 1.1.1.1 and 9.9.9.9 from the 'easy remember' DNS list.

~~~
chii
who runs 9.9.9.9 ?

~~~
detaro
[https://quad9.net](https://quad9.net) \- IBM and two groups I haven't heard
of.

~~~
symtos
One of those groups is Global Cyber Allience (GCA):

"GCA, a 501(c)3, was founded in September 2015 by the Manhattan District
Attorney’s Office, the City of London Police and the Center for Internet
Security."

[https://www.cityoflondon.police.uk/advice-and-
support/cyberc...](https://www.cityoflondon.police.uk/advice-and-
support/cybercrime/gca/Pages/default.aspx/)

------
iforgotpassword
I find that map breaking down usage by country interesting. It seems almost
nobody is using it in India and Australia. Is it performing badly, is it
blocked by ISPs, or are those people just overly obsessed with privacy? Even
China's usage is higher, surprisingly, even though it wouldn't help at all
with bypassing censorship.

~~~
jazoom
> I find that map breaking down usage by country interesting. It seems almost
> nobody is using it in... Australia. Is it performing badly

No. It works well.

> is it blocked by ISPs

No.

> or are those people just overly obsessed with privacy?

No.

I don't know why it's low in usage, bit I can't think of a reason why it
wouldn't be low. I don't know anyone who would even think to change their DNS
servers.

~~~
iforgotpassword
Sure but I'd have expected similar usage throughout western countries. here in
Germany I wouldn't consider the average person any more techy than in
Australia or anywhere else. People are pretty conservative and stick to what
they know in general. I don't know anyone besides coworkers or friends working
in the field who would do that, but then at least half of them are probably
too skeptical of google to actually do it.

------
benwilber0
Public DNS is just one of the many free services that Google provides in order
to slurp up every single possible activity that happens on the internet. Visit
this website in your logged-in Google browser tab:

[https://myactivity.google.com/myactivity](https://myactivity.google.com/myactivity)

I don't know what it says for you, but for me it lists everything I do in my
life. The restaurants I look at in the Seamless app. The Reddit posts I
clicked on in the Reddit app. Every single YouTube video I watch. Everything I
search for. All of the places I went yesterday and in the last 6 months.

And these are only my "explicit" actions. Now imagine that Google also
passively knows every single web address I look up via DNS? We share private
browsing sessions to them _all the time_ regardless of in-cognito mode or any
other privacy safeguards.

~~~
kyrra
Google DNS is not used in any way to associate to your Google account. They
say exactly everything they record and how it's stored and used.

[https://developers.google.com/speed/public-
dns/privacy](https://developers.google.com/speed/public-dns/privacy)

~~~
benwilber0
What if I don't believe them?

~~~
mehrdadn
Well then you don't believe them. But then whom do you believe _would_ keep
your DNS data private, and by what rationale do you find them more believable
than Google?

~~~
earenndil
A company whose business model isn't based entirely in analyzing user data in
order to sell them the most things. Remember: these data don't _have_ to be
tied to your account. Google can use your ip address to glean your
(approximate) location, and then use the websites you visit to better tell
what kind of people live in that area. Even if they don't store the websites
themselves, they can categorize the websites and store a category breakdown.
They can find out what demographic you belong to from your account, and then
associate the websites you visit with that demographic rather than that
account. Lots of data that can be stored even if they're not directly
associated with your account or the individual websites you visit.

~~~
mehrdadn
> A company whose business model isn't based entirely in analyzing user data
> in order to sell them the most things.

Really? That's the only bar? So you're going to trust any company who isn't in
this business without even reading & comparing their privacy policy or looking
at their past history?

I also have to say I don't understand what you guys' true fear (read: threat
model) is. It seems like for Google your criterion is "if they could
potentially keep such data, they're automatically dangerous (doubly so if
their name is 'Google')", whereas for anyone else not in the advertising
business your standard suddenly changes to "I don't care what data they have,
as long as I don't see evidence of active misbehavior". To me this sounds like
what you really fear is _personalized advertising itself_ rather than an
actual privacy or security breach, which doesn't entirely make logical sense
considering what the dangers of each of them are.

~~~
earenndil
> So you're going to trust any company who isn't in this business

I never said that. I said that I'm _not_ going to trust a company that has
this business model. That by no means implies that I'm going to blindly trust
a company with another business model, rather that trust in such a company is
possible.

~~~
mehrdadn
OK, then you didn't answer my question either. I was not asking "which
companies would you _not_ trust, and by what rationale"? The question I asked
was: "Whom do you believe _would_ keep your DNS data private, and by what
rationale do you find them more believable than Google?"

Telling me you wouldn't trust someone who meets some disqualifying criterion
isn't useful if you have so many disqualifying criteria that you wouldn't
trust anybody, which frankly is the impression I get reading people's comments
on this issue. If you have an actual company that you _would_ trust, and a
clear rationale for doing so, that's where we can have a real discussion.

~~~
pdkl95
> Whom do you believe would keep your DNS data private

You presupposing that it is necessary to send all DNS traffic to one entity. I
run a local recursive nameserver (unbound) instead of sending all of my
queries to a different nameserver.

Combined with aggressive caching, any particular DNS server (from _.ROOT-
SERVERS.NET down to the specific authoritative nameservers for a specific
domain) is only able to view a tiny subset of my browsing behavior. Most of
the time the query to the final authoritative nameserver is to be followed
quickly by a TCP SYN packet that reveals roughly the same information.

Yes, running the full recursive resolver locally can be _very slightly* slower
than asking e.g. the local ISP's server that probably has the query cached.
Fortunately, local caching limits this (very minor) problem to only the first
request for a domain.

~~~
Dylan16807
Running a recursive resolver isn't really that great from a "trust no one"
perspective, because the .com nameservers are getting a decidedly _not_ tiny
subset of your access activity.

~~~
pdkl95
The TLDs are only queried for the NS records of the second-level domain, and
the A (or AAAA) records of the those NS names. This is cached, often for
longer than the record's specified TTL. The rest of the traffic is with the
0delegated nameserver,

~~~
Dylan16807
The second level domain under com is the important part 95% of the time.

~~~
pdkl95
> This is cached, often for longer than the record's specified TTL.

NS records don't change very often. They can see that I looked up the
delegation data about "example.com" _once_ every $CACHE_TTL (~months). They do
_not_ get repeated queries at the beginning of every session I have with a
website.

A lot of security is about being in the habit of minimizing attack surface.
The only thing a TLD (or ISP) nameserver _needs_ to know if I want to use the
Doomain Name System is "pdkl95 asked for example.com's nameserver once last
month" Instead of giving Google (or whomever) an update e.g.:

    
    
        ;; ANSWER SECTION:
        news.ycombinator.com.  300  IN  A  209.216.230.240
    

...every 5 minutes. This is not trying to stop someone discovering that I have
_ever_ been a domain; I'm limiting the ability to model my _pattern of life_
[1].

[1] [https://en.wikipedia.org/wiki/Pattern-of-
life_analysis](https://en.wikipedia.org/wiki/Pattern-of-life_analysis)

~~~
Dylan16807
So what I get out of this is that your system protects your privacy because it
uses a custom TTL, and not really because you run a recursive resolver. It
helps reduce errors, but you could get _almost_ the same effect with a pure
cache.

~~~
pdkl95
No, I'm still requesting the A/AAAA records at the normal TTL rate. This
doesn't expose useful information, because those queries are sent directly to
the domain's nameserver. The domain learns that data point anyway from the TCP
SYN packet I'm probably sending immediately after I learn the A/AAAA record.

Separating the requests _allows_ for different cache policies. If you simply
delegate the entire recursive resolution work to Google (or whomever), they
get to record that you needed "www.example.com" every TTL (5min?). You don't
even need to see the domain's NS records in that case, so there isn't an
opportunity to choose a cache policy.

~~~
Dylan16807
I'm not sure why you lead with "No" because you didn't disagree with anything
I said.

~~~
pdkl95
> and not really because you run a recursive resolver.

"No", because the system depends on running a recursive resolver locally to
separate queries onto different nameservers.

~~~
Dylan16807
It depends on doing so to _work better_. But a similar not-quite-as-good
system could do without that feature. It's not integral.

~~~
pdkl95
What is this system that prevents pattern-of-life analysis while still sending
all DNS queries to one nameserver? I'm still sending frequent short-TTL
(normal caching) DNS lookups for most hosts that would betray my pattern-of-
life in aggregate. The vast majority of the security is from sending those
requests to the domain-specific nameservers instead of aggregating it all
through a single upstream nameserver.

Aggressive caching of NS records for TLDs doesn't do anything to prevent a
single upstream nameserver from leaning your pattern of life from the frequent
DNS lookups for A records that are not cached longer than normal.

~~~
Dylan16807
> What is this system that prevents pattern-of-life analysis while still
> sending all DNS queries to one nameserver?

Setting $CACHE_TTL to "months" on everything, and doing nothing else.

> I'm still sending frequent short-TTL (normal caching) DNS lookups for most
> hosts that would betray my pattern-of-life in aggregate.

Your system does that. This theoretical mildly-inferior system would not have
frequent DNS lookups for any record type.

~~~
pdkl95
> Setting $CACHE_TTL to "months" on everything, and doing nothing else.

That will break a _lot_.

DNS isn't static; IPs regularly change as servers move, CDNs are
introduced/changed. Long-term caching only works on NS records because
changing DNS delegations is relatively rare. NS record caching _does_ cause
problems, but they are infrequent. Caching the addresses of the actual servers
will break some things within days, and most of the internet the next time
each server is updated/moved/etc.

------
xellisx
What about 4.4.4.4 / 4.2.2.2?

~~~
nkurz
I don't think that 4.4.4.4 is a current DNS server. Perhaps you mean 8.8.4.4
or 4.2.2.4? 4.2.2.X was originally intended to be 4.4.4.4, but it didn't
happen: [https://www.tummy.com/articles/famous-dns-
server/](https://www.tummy.com/articles/famous-dns-server/)

~~~
xellisx
Thanks for the info.

------
hi41
In the very first post Google said they will publish learnings from this
experiment. What have they learnt from this experiment that we can benefit
from.

------
l0b0
134,742,054 BCE? I really underestimated the early hominid tech stack.

------
ironjunkie
For performance and privacy reasons, you should use Cloudflare DNS. Please
don't trust blindly Google when they say they don't use your DNS request data.
It is their core business model to get their hand on all the data they can.

[https://blog.cloudflare.com/announcing-1111/](https://blog.cloudflare.com/announcing-1111/)

~~~
0xb100db1ade
Cloudflare's 1.1.1.1 DNS blocks [https://archive.is](https://archive.is)

~~~
caymanjim
I didn't believe they'd do something like this, so I went to check and prove
you wrong, but sure enough, it doesn't resolve. According to this post on
CloudFare's support site, it's not their fault:
[https://community.cloudflare.com/t/archive-is-
error-1001/182...](https://community.cloudflare.com/t/archive-is-
error-1001/18227).

> This is unfortunately something we can’t do something about. Nameservers
> responsible for archive.is (ben.archive.is, anna.archive.is) are returning
> answers tailored to the IP address of the requestor.

~~~
nmjohn
I did the same research because I too found it hard to believe and it's still
not clear to me how the problem is not on cloudflare. They claim the upstream
is misconfigured, but how then does every single other DNS provider manage to
handle it correctly?

Or are they claiming archive.is is explicitly blacklisting the cloudflare IP
range? If that is the case it seems odd they are claiming the upstream is
misconfigured as opposed to explicitly blocking them. Something does not add
up correctly.

~~~
meta_AU
Sometimes 1.1.1.1 is used as a testing value, and can get blocked for reasons.
CloudFlare is getting a huge amount of spam IP traffic to 1.1.1.1 from
misconfigured equipment, it wouldn't be too surprising if some upstreams have
firewalled valid IPs.

~~~
nmjohn
When cloudflare resolves addresses, the DNS request is not coming from
1.1.1.1, it's coming from the IP address of the server actually making the
request. You can confirm this by looking at the results of a VPN DNS leak test
[0] and seeing the IPs being used to resolve the addresses do come from
cloudflare, but are not 1.1.1.1

[0]: [https://www.dnsleaktest.com/](https://www.dnsleaktest.com/)

