Most of the comments which I’m reading about Google Public DNS (GPD) performance centers around round trip latency from an end-users location to GPD’s resolvers vis-a-vis their network location and comparing the round trip time to their local ISP DNS cache. Ping time is only one part of the time taken for DNS resolution, one needs to factor in DNS resolution time also which can be affected by cache locality and sizing as well as how connected the requested authorative nameserver for the query is relative to the DNS resolver. IMHO, an effective way for setting up an office DNS cache is to setup a local caching nameserver such as Dan Bernstein’s dnscache and use GPD as an upstream forwarder.
Thus domains which are repeatedly asked are answered from your local dnscache and the long tail of domains can be answered by GPD which may have its in its cache because what may be infrequent for your organisation is frequent for someone else who is using GPD thus giving you the best of both worlds. Fast local caching, and a fast recursive resolver when you have no locally cached results.
I’m assuming that in the coming weeks, Google will reach out to a number of organisations who use anycast DNS such as Content Delivery Network operators (Akamai, Limelight, CDNetworks etc) and authorative DNS servers operators (Dynect,UltraDNS,DNSMadeEasy etc) and work out better network routing amongst them.
These instructions assume that you have setup dnscache as an external forwarding cache for your organisation.
Then run the following commands (asssumes that you have installed dnscache as per DJB’s setup. Ubuntu/Debian users may have to adjust paths if they use packages from these distributions
echo 1 > /service/dnscache/env/FORWARDONLY echo '188.8.131.52 184.108.40.206' > /service/dnscache/root/servers/@ svc -t /service/dnscache
There has been a lot of buzz regarding Google Public DNS herafter called GPD. Google’s instructions are designed for end users modifying their own computers. I think GPD can be very useful if used in conjunction with a forwarding cache on a router. This is the mechanism I used on my Linksys WRT54GL running DD-WRT
v24 to combine using DNSMasq and use GPD’s provided IP addresses 220.127.116.11 and 18.104.22.168 as the upstream DNS.
I assume that you have enabled SSH access to the router so you can login via SSH and take backups of the old values of the upstream DNS
- SSH into your router and run
cat /tmp/resolv.dnsmasq. Save the IP addresses listed somewhere in case you want to revert back
- Go to the Commands tab under Administration.
- In the Commands box paste the following:
- Click Save Firewall (note: your WAN interface will be restarted)
echo "nameserver 22.214.171.124 nameserver 126.96.36.199" > /tmp/resolv.dnsmasq sleep 1 killall -HUP dnsmasq
Now, you can take advantage of the DNS caching on your router and misses on the routers DNS cache are sent to GPD for resolution. Note that websites which use CDN will now determine the closest node based on where the anycasted GPD addresses 188.8.131.52 and 184.108.40.206 resolve to relative to your network.
In a future post, I’ll write about how GPD can be integrated as an upstream forwarder using dnscache and why PowerDNS recursor doesn’t support using an open resolver as an upstream forwarder at present
There have been a lot of discussions, blog posts describing how Chrome is one of the shortest if not the shortest beta cycle from Google. Most of the discussion has centered around the business requirements from OEM of having a non-beta software for pre-installation. Whilst this is valid, in my opinion this pre-deployment would still take a while to go through since I expect the earliest manufacturers will start a new build will be after Chinese New Year (end of Jan) and subsequently with another QA cycle could be March-April before boxes with Chrome pre-installed show up in stores
In my opinion, Google wants to take advantage of the holiday season where everyone is visiting family and doing the usual “tech support”. A lot of early adopters would like to get their parents computer cleaned up and install alternative browsers. Google’s Chrome is clean and with the search box integrated nicely with the address bar would be very useful to many who don’t care about the lack of extensions.
It will however be interesting to see how Chrome’s mechanism of being chatty with Google for its auto-suggestion may impact usage in markets where people have bandwidth limits.
I’m having a great time watching Season 3 of the IT Crowd. I loved Season 1 and Season 2 and converted a lot of my colleagues to be watchers of the show.
Season 3 hasn’t disappointed so far and I had a great time watching Episode 3 with a brilliant moment when Moss recovers from his concussion and there is a Windows startup sound to signify his brain being “rebooted”
Very impressive UI for the Dashboard, Love the QuickPress widget on the top right hand corner. Maybe this will get me get back to blogging rather than twittering
I was introduced to uber-smart hacker and phenomenally successful serial entrepreneur Adam Twiss who originally wrote ApacheBench whilst he was at Zeus and subsequently donated to the Apache Foundation.
Velocix is well known for its hybrid P2P based CDN network and I was trying to get a better understanding of how things worked behind the scenes in order to evaluate its suitability for various projects at work.
This is really oversimplifying their value proposition but for a technical person I would say that Velocix basically can provide a constant backfill to a BitTorrent swarm should a client want to use BitTorrent as a content delivery protocol.
Obviously Velocix can do a lot more than the above but it was hard for me to extract the above value proposition which was interesting to me from their website.
Hopefully this blog post can get some Google karma and help prospective Velocix customers
If you aren’t familiar with the browser, I would encourage you to visit Deb Richardson’s brilliant Field Guide to Firefox 3 which describes a number of key Firefox 3 features in a very accessible manner.
One thing I would like to mention is that Firefox 3 has improved connection parallelism. The default limit for concurrent connections per hostname has been increased from 2 to 6 which is similar to IE8. Details can be found in this bug report here and for the technically inclined these are the new defaults
Whilst the improved connection parallelism is one factor in improved page load performance, web server administrators who are currently serving content via Apache need to factor in increased concurrent connections from Firefox 3 and tweak their MaxClients setting appropiately.
Google’s Steve Souder has a great roundup on Parallel Connections in this blog entry.