37 comments

[ 100 ms ] story [ 1762 ms ] thread
I've been using 4.2.2.2 on almost daily basis since 2003 - every time I want to see if I'm connected to the Internet, anywhere in the world - that's my canary.

It had never occurred to me to wonder why I was using 4.2.2.2. Just something I learned from one our network engineers, who learned it from someone else...

Just imagine how much traffic they get.

If they really didn't want people to use it, I am sure it would be easy for them to block whole swaths of the net from using it.

They mean not to use it as your primary DNS server. Pinging it and using it for temporary DNS is likely fine, I wouldn't suggest statically assigning it for permanent use though.
I did not understand why we shouldn't use 4.2.2.2. If they did not wan people to use it, why is it open? Too bad none of the reports the authors has read about that were linked.
The idea is that they can cut off access to non-Level3 customers any day if they wanted to, and they'd be within their rights to do so.

The proper choice would be to use Google DNS or OpenDNS which are provided as a service to the public.

I started using 4.2.2.1 in early 1999. A friend of mine was a sysadmin at Genuity (then the new owners of that block) and they used it a lot internally. I went on to show it to a lot of my fellow sysadmins and I guess a lot of other folks did the same.
That's about when I started using them. I still use it today. It got passed around on IRC somehow. Maybe undernet.
Not that anyone cares who wasn't there... BBN was purchased by GTE in 1997. GTE merged with Bell Atlantic to become Verizon. Genuity was spun off, and after it foundered ("Black Rocket") it was purchased by Level 3.

Prior to that, parts of BBN were sold off, and still exist as a subdivision of Raytheon.

Source: I was there for too much of it.

What we told people outside the company about 4.2.2.x: it's there, you can use it for testing or bringing up new systems, please don't use it long-term or heavily. It works by Anycast: let me tell you about that...

I use 8.8.8.8 which is Google's public DNS
Been using 4.2.2.2 (and 4.2.2.3) for almost a decade now.

In recent years I stopped using them though because of privacy and reliablility causes; I usually setup a caching server on the local host or network.

There are different reasons to use the various dns servers:

Both Google (8.8.8.8 / 8.8.4.4) and OpenDNS (208.67.220.220 / 208.67.222.222) can be troublesome on small networks when trying to reach local LAN devices because they resolve failures to their own search pages. My fallback here is to always try one of the L3 servers (4.2.2.1 - .6)

OpenDNS is my goto when I need filtering. OpenDNS is also great when changing ip addresses on domains because you can clear their public cache and make sure everything is updated and is working immediately. http://www.opendns.com/support/cache/

Google DNS tends to make youtube streaming work much better for me.

Even Comcast has even recently changed their dns to memorable numbers 75.75.75.75 / 75.75.76.76

I have neither heard of Google`s DNS servers resolving failures to their own search pages, nor experienced it myself after using it since it`s release.

OpenDNS on the other hand...

I stand corrected. Google does not respond to incorrect domains. I mistook the auto search from the address bar in firefox as similar behavior to OpenDNS.
I hope this comes across in the constructive manner I intend it: when I am curious about a network issue, especially DNS related, a browser is never the tool I use for asking such questions. If you're on a modern OS then "dig" is an amazing tool, and on that other OS "nslookup" will do in a pinch.
Google just does it in the browser. (they call it "omnibox")
DNS is for the most part a pass-fail type system. It can in no way make streaming better, unless your ISP is purposely giving wrong addresses for YouTube. Is that common now? It wouldn't surprise me, to be honest..
DNS can give you IPs for things close by, or far away. 8.8.8.8 uses EDNS0 Client Subnet to try and improve which IP address you get served back.
Geo based DNS is the job of the auth nameserver, not the recursive as you know. So, the client subnet extension is a good idea, as otherwise it just relies on the address of the recursive resolver. I assumed, wrongly perhaps, that the ISPs recursive ns would be located close to the user, which has always been the case in my town. Well, moreso helpful than hoping the auth recognizes the client subnet extension.
I've been blocked by 4.2.2.2 before for (I assume) over-use. It took a year or two but they eventually noticed my traffic..
I noticed very strange but consistent performance behavior from Google Public DNS. Even though a DNS record was cached, the response time was in the range of 20-30ms, which is absolutely horrible. When I switched over to OpenDNS, cached response times dived down to 1ms. Needless to say just made the switch on all the servers to OpenDNS. Can anybody explain this behavior?

Here is the GitHub gist showing the output:

https://gist.github.com/nodesocket/786e3b879f74c7787ca6

Where in the world are you? Do you have a traceroute to 8.8.8.8?
I am in DigitalOcean (San Francisco). The answer is simply distance/routing. I am guessing OpenDNS has an anycast node in DigialOcean (SF), where Google Public DNS does not. A ping tells the story.

ping 8.8.8.8 => 24ms

ping 208.67.222.222 => 1ms

A traceroute would tell the story better.
From DigitalOcean in SF I'm hitting the OpenDNS Palo Alto datacenter. Google is going to San Jose.

Remember OpenDNS is a real business working to provide a service to real paying customers, Google DNS is just a fun little project of building an OpenDNS clone.

I believe all the DO droplets default to 8.8.8.8 so Google are probably applying some rate limiting across the DO network block during usage peaks.
Why 18.62.0.96 in particular for testing web service? Does MIT provide that IP as a public service?
Google should be tracking all the queries on their DNS server.
I am curious if google is using the data from its dns service to improve the search index.