Why Systems Administrators Should Stop Using 8.8.8.8 (Google DNS)

We have all been there at least once. It’s nearing the end of the day and now we have a workstation or server with DNS issues that needs to be addressed. It might be a local DNS problem, or maybe its the ISP’s DNS server. Either way, its been a long day and we just want to get home at a decent hour. So we go the easy route for now and configure to Google’s 8.8.8.8 and 8.8.4.4 DNS servers. Connectivity and domain resolution now works? Great. Let’s just diagnose the underlying problem tomorrow morning and hope we don’t forget to circle back to that ticket.

Not so fast, Jack!

There is no question that Google’s servers are easy to remember for debugging, and without question the fastest DNS servers on the internet. So what is the big deal? It seems like a no-brainer. Well, have you thought about a possible privacy issue you just introduced to the network? No?

Well, we need to dive into Google’s privacy policy when it comes to their DNS services then.

What is Google tracking on your DNS queries?

According to Google, their public DNS stores two sets of logs: temporary and permanent.

Temporary

Google doesn’t deny that they are collecting your machine’s full IP address in their temporary logs. They claim they use this to track likely distributed denial of service attacks or to fix problems such as domain issues for a specific demographic of users. They do delete temporary logs within 24 to 48 hours.

That seems reasonable, right? Yes and no. We need to look further. What’s in the permanent logs.

Permanent

Google says they do not keep personally identifiable information or IP information in their permanent logs. They do collect location information for debugging and abuse analysis. After a two week retention, they randomly collect a portion of those record for permanent storage.

So what ends up in the permanent storage?

The following is what finally ends up in Google’s permanent DNS database for each query.

• Request Domain Name
• Request Type
• Transport Protocol
• Client’s Autonomous System / Internet Service Provider
• User’s Geo-location information / Geocode
• Response Code
• Front end cache request hit
• Non-front end cache request hit
• Arrival time
• Total time to process request
• Name of Google’s process machine
• Google’s target IP

And there is the rub. Did you miss it?

Geocode! And don’t forget internet service provider information!

What is geocoding? Systems Admins all know what geocoding is but let’s refresh ourselves anyways for the layperson with Wikipedia’s definition; the process of taking an address or the name of a place and returning a latitude/longitude location on the Earth’s surface for that place.

So what does this mean for Systems Administrators?

What it means is by using Google’s DNS servers, you are potentially giving up your network’s privacy. Can you guarantee your employer and client’s DNS records will not be randomly collected up into Google’s permanent database? If you cannot, then you have an issue. As you can see from the privacy policy, Google can now correlate the requested domain name, internet service provider and geolocation. If you have that information, you can deduce pretty easily who is making the request if coming from a residential or commercial location.

The internet is highly monitored so it’s mostly a rare case to have an active site on the clearnet that is unlawfully running before it gets shutdown by law enforcement. This isn’t about protecting or concealing your networks activity of unlawful activity.

This is about two things:

1. Data mining

Nowhere in the privacy literature does it state that Google will not be doing deep analysis on permanent records. This should be opt-in and your employer or client should be aware that they are potentially giving up valuable data to Google to either use to market new products and services back to them or sell that data for a profit. As Google states “We may share non-personally identifiable information publicly and with our partners — like publishers, advertisers, developers, or rights holders.” If this is something your employer or client is not comfortable with, you shouldn’t be using the service.

2. Censorship / Targeting

It’s human nature to want to trust, but we cannot verify in this case. Can you verify that your queries will not land in permanent records and be passed on to another entity for targeting and/or censorship? Targeted for political affiliations, religious beliefs or accessing information that is slated to be censured? If not, again, you shouldn’t use the service.

What is a your role?

As a systems administrator, it is your job to protect your network and its people. You are expected to see all the angles and inform your people of potential threats and implications of using certain technologies. So next time you are about to punch 8.8.8.8 in, think about this. There are better solutions out there that offer privacy such as Cloudflare’s 1.1.1.1, but at the end of the day, a no-log DNS service should be coupled with encrypted DNS to protect queries from man in the middle attacks, but that’s a discussion for another day.