Even the man page is better: http://linux.die.net/man/5/resolv.conf
"Optimised" resolv.conf has one line - 127.0.0.1 and the host runs a local cache (dnsmasq / bind / djbdns / ...)
I have a PowerDNS setup on localhost that was a lot slower than Google's servers. That's because by default it recurses to the root servers.
I found that the fastest setup in my case was to use PowerDNS and have it recurse via bt.com servers (this is in London). BT is a big commercial provider so what I need is often hot in their cache, the same goes for Google.
With a local DNS cache on my network for the same domain name I get replies within 30 or so milliseconds, with Google's DNS servers there is at least another 60 ms or so required for the round trip, making most of the queries take 90 ms. Now that may not seem like a lot, and most likely I will spend more time waiting on a website to load, but in the long run it does make a difference.
Anyway, this isn't much of an improvement honestly..
Please don't do this unless you're a GTE/Verizon customer. Use your ISP's or run a resolver yourself.
For a bit of the history behind it check out this site: http://www.tummy.com/Community/Articles/famous-dns-server/
Using the DNS server is not suggested, since it is not officially a public DNS server, and Level 3 could cease the service at any time (in all likelihood that is very slim, since they have been telling their customers to use them for years now). Since they are anycast it will reach the closest server to your location when you query that DNS, and as such using it shouldn't be too big of a deal, whether you are a customer or not.
Oh wait, that's 22.214.171.124. Maybe that's what he meant.
And now I checked the article. That's what it says now.
Note: This recommendation is for server setups, where dns latency can easily add ms to processing time. With workstations we can tolerate some latency and should probably benchmark your ISPs resolvers.
Because AFAIK, ubuntu distros (and maybe redhat/fedora even) suffer from multisecond delays due to ipv6 lookups - https://bugs.launchpad.net/ubuntu/lucid/+source/eglibc/+bug/...
I thought this article had some solution to that (other than disabling ipv6, right now) - but dont think so