Last week, Google announced a new service, Google DNS. The idea is simple – instead of using your own, or your ISPs DNS, you use theirs. Most readers of this blog will know what DNS is, why it’s really important and how to configure and manage it, at least I sure hope so! But that leaves a great percentage of the Internet-using population who both don’t know and probably don’t care as it all just works.
The idea of an independent DNS network is not new. Several years ago, I wrote about the ORSN, the European Open Root Server Network. I sometimes set systems up to use it, but like most folks, the DNS that most of I use is a part of the huge distributed network that comes as part of the Internet. Personally, I have my own internal DNS server which serves as a resolver for the systems in my network, as well as hosting the records for my AD domain.
The Google DNS service is just a resolving DNS cache – they host no zones (other than Google’s own zones) and they do not host any root domains. They just resolve the names you send it, and cache those results for others to use. Google say their goal is “to benefit users worldwide while also helping the tens of thousands of DNS resolvers improve their services, ultimately making the web faster for everyone.” A laudable goal, but is it actually a useful service. On Google’s code blog, they cite three main advantages: Speed, Security and Validity. I’ve spent some this morning looking at the speed claim.
Google DNS is hosted at several servers. In their configuration instructions, they :there are two servers (at 8.8.8.8 and at 8.8.8.4), although another document shows 5 servers (ns[1-4].google.com). I have been doing some testing, using PathPing.Exe this morning to look at performance. Access to these servers from the UK (where this article is being written) is quick and has no packet loss. The path to the servers goes first via my ISP to Google-Lon.Google.Com and then via a few un-named routers to the DNS server. The RTT to 8.8.8.8 was 38 ms.
I then ran a PathPing against my own ISP’s DNS server and another DNS Server run by Demon Internet. For both UK servers, I see a shorter route (10 hops vs 12) – not surprising as these servers are in the UK, and Google’s I suspect are not.I also see a faster path (31 ms to Demon, 28 to Clara.Net vs 38 to Google). Packet loss to both UK servers is also zero although the route to Demon’s name server goes via tele-service-22-s267.router.demon.net which drops 100% of the ICMP packets (no such issue to Clara.Net. So on path grounds, using Google does not seem to provide much benefit as it’s slower and has more hops.
As for security, Google makes the valid point that DNS is vulnerable to attach – it can be spoofed routing users to malicious sites rather than the intended site. The DNSSEC protocol is meant to attack that problem through cryptography, but DNSSEC is not yet in widespread use (and is a lot more work to setup). I’m not sure I entirely buy the argument that they are any better at protecting DNS than my ISP. We’ll have to see.
The validity advantage that Google cites seems even less interesting. They say their DNS servers comply with DNS Standards. Well I’d sure hope so – a non-standards compliant DNS server would be a bit a a waste of time. They also avoid blocking, filtering or redirection. Doing some testing using NSLookup, it looks like they don’t do wildcard DNS – thus trying to resolve (hopefully!) non-existent domains gives teh expected error. I tried resolving x.microsoft.com and foo.foo.foo – both queries were “refused” since ns1.google.net could not find those domains.
All in all, this looks to be a reasonably fast and competent DNS solution. For many users, using this might benefit their web surfing. For me, it looks a tad slower – so ‘buyer’ beware. As for the security argument, I accept they intend to make their service secure, but experience will show whether this is a good argument, or not.
1 comment:
Not that fast when item not in cache which is most things non-public.
Post a Comment