Google has implemented security features in Google Public DNS to help prevent DNS cache poisoning and denial-of-service attacks. But while some applaud Google's approach, others--including OpenDNS--say Google is not breaking new ground.
been made about how Google Public DNS will improve
of the Web. But
what about security
to some, Google is on the right track-though others say the company is
not exactly breaking new ground.
"DNS as a
protocol is pretty terrible in terms of security, but from a cursory glance it
appears that Google is doing all of the right things," said HD Moore, chief
security officer at Rapid7. "Specifically, they are using strongly random
transaction IDs and source ports for their outbound queries and they are not
returning fraudulent responses, as many ISPs do."
, the company sought to take on DNS
and denial-of-service attacks against DNS resolvers. To get
this done, Google implemented and recommends a number of features to help
mitigate these problems.
starters, Google has implemented a few techniques for adding entropy to request
messages, including randomizing source ports, the case of letters in domain
name queries and the choice of nameservers. Google also appended nonce prefixes
to name requests, which can help address the threat posed by exploits such as
the one uncovered last year by researcher
resolver cannot directly resolve a name from the cache, or cannot directly
query an authoritative nameserver, then it must follow referrals from a root or
nameserver," Google stated
on a Web page dedicated to Google DNS. "In most cases, requests to the root or
nameservers will result in a
referral to another nameserver, rather than an attempt to resolve the name to
an IP address. For such requests, it should therefore be safe to attach a
random label to a query name to increase the entropy of the request, while not
risking a failure to resolve a non-existent name."
in practice such requests make up less than 3% of outgoing requests, assuming
normal traffic (since most queries can be answered directly from the cache or
by a single query), these are precisely the types of requests that an attacker
tries to force a resolver to issue," Google continued. "Therefore, this
technique can be very effective at preventing Kaminsky-style exploits."
also taken steps to remove duplicate queries and rate-limiting requests to
prevent DoS attacks.
this, said OpenDNS
David Ulevitch, is not
the only DNS company not vulnerable to the Kaminsky flaw," he told eWEEK. "We
pioneered many of those techniques and have been doing things like source port
randomization since our inception in 2005. The idea of adding entropy is not
new, and again, is something we've been doing for a long, long time. We use
embedded [extension mechanisms for DNS] options, which we think is better than
their capitalization trick, though we've considered that one in the past."
analyst John Pescatore agreed that Google isn't offering anything here that
isn't available elsewhere, and questioned Google's commitment to privacy.
through Google's privacy statements around the DNS service, and they are saying
they won't store any information long term, but it says nothing about if they
will resell any of the trend information or sell advertising services based on
the information they do see at every query," he said.
stores two types of logs-permanent and temporary. The temporary logs store the
full IP address of the machine being used, but are deleted within 24 to 48
hours. The permanent logs do not include personally identifiable information or
IP information, though they do keep location information in order to perform
debugging and analyze abuse to improve their prefetching feature.
correlate or combine your information from these logs with any other log data
that Google might have about your use of other services, such as data from Web
Search and data from advertising on the Google content network," according to Google
"After keeping this data for two weeks, we randomly sample a small subset for
"We built Google Public DNS to make the Web faster and to
retain as little information about usage as we could, while still being able to
detect and fix problems," the company added.