Google and Neustar propose security fix for DNS geolocation technology

Google and DNS provider Neustar have jointly proposed an extension to the DNS protocol that would fix many of its security problems.

Google and Neustar, which posted the proposal on an IETF mailing list last week, would like to see the protocol extended to include significant significant IP address information about the computer making a DNS request. The extension to DNS would enable nameservers to understand roughly where a query was coming from, which would reduce the risk of attacks such as DNS poisoning, in which a nameserver can be convinced by a rogue computer that an illegitimate internet destination is the right one.

"It specifies an EDNSo option that carries IP address information (by default, only the first 24 bits to preserve privacy) of the user that triggered a DNS resolution," said the posting, made by executives from Google and Neustar. "This should allow authoritative name servers that keep geo-targeted responses to be more accurate, even in cases where the resolver and its users are close to each other."

The posting accompanied a 20-page document detailing the extension, which allows an authoritative name server to issue responses based upon the client's network address, rather than the network address of a recursive name server.

Google has been increasingly active in the battle to make the domain name service more secure. Ever since a fundamental flaw was discovered by researcher Dan Kaminskiy in 2008, the security of the service, which results URLs to IP addresses on the internet, has been in question.

Early last month, it was revealed that 80% of US federal agencies had failed to implement DNSSEC, a set of security extensions to DNS that use public-key encryption to help make the service more secure. The government had imposed a deadline of Dec. 31, 2009 for the upgrades.

Source: Google and Neustar propose security fix for DNS geolocation technology, Retrieved on February 2, 2010 from infosecurity-us.com/view/6920/google-and-neustar-propose-security-fix-for-dns-geolocation-technology/

80% of government Web sites miss DNS security deadline

Most U.S. federal agencies -- including the Department of Homeland Security -- have failed to comply with a Dec. 31, 2009, deadline to deploy new authentication mechanisms on their Web sites that would prevent hackers from hijacking Web traffic and redirecting it to bogus sites.

Agencies were required to roll out an extra layer of security on their .gov Web sites under an Office of Management and Budget mandate issued in August 2008, although at least one expert calls that yearend deadline "a little aggressive."

Aggressive or not, independent monitoring indicates that only 20% of agencies show signs of deploying this new security mechanism, which is called DNS Security Extensions, or DNSSEC for short.


Source: Carolyn Duffy Marsan, IDG News Service, Retrieved on January 21, 2009 from news.idg.no/cw/art.cfm?id=519CAE32-1A64-67EA-E410635A87B80381

Testing and Implementation Requirements for the Initial Deployment of DNSSEC in the Authoritative Root Zone

Excellent DNSSEC document provided by DOC NTIA, ICANN and VeriSign.

Get it here:
Testing and Implementation Requirements for the Initial Deployment of DNSSEC in the Authoritative Root Zone

Root DNSSEC

Information about DNSSEC for the Root Zone


This website contains announcements, releases and other pertinent information about the deployment of DNSSEC for the root zone.

DNSSEC for the root zone is a joint effort between ICANN and VeriSign, with support from the U.S. Department of Commerce.

Planned High Level Timeline

* December 1, 2009: Root zone signed for internal use by VeriSign and ICANN. ICANN and VeriSign exercise interaction protocols for signing the ZSK with the KSK.
* January, 2010: The first root server begins serving the signed root in the form of the DURZ (deliberately unvalidatable root zone). The DURZ contains unusable keys in place of the root KSK and ZSK to prevent these keys being used for validation.
* Early May, 2010: All root servers are now serving the DURZ. The effects of the larger responses from the signed root, if any, would now be encountered.
* May and June, 2010: The deployment results are studied and a final decision to deploy DNSSEC in the root zone is made.
* July 1, 2010: ICANN publishes the root zone trust anchor and root operators begin to serve the signed root zone with actual keys – The signed root zone is available.

Please note that this timeline is tentative and subject to change based on testing results or other unforeseen factors.

Get more info at http://www.root-dnssec.org/

Deploying and Monitoring DNS Security (DNSSEC)

"Abstract—SecSpider is a DNSSEC monitoring system that
helps identify operational errors in the DNSSEC deployment
and discover unforeseen obstacles. It collects, verifies, and
publishes the DNSSEC keys for DNSSEC-enabled zones, which
enables operators of both authoritative zones and recursive
resolvers to deploy DNSSEC immediately, and benefit from its
cryptographic protections. In this paper we present the design
and implementation of SecSpider as well as several general
lessons that stem from its design and implementation."

Paper: Deploying and Monitoring DNS Security (DNSSEC) (PDF)