April 2010 Archives

DNSSEC Still Pie In The Sky

Affilias recent put a post claiming that DNSSEC is no longer pie in the sky! The post immediately proclaims than DNSSEC would have stopped the issue on Mar 24th where a Chinese root server was leaked outside of China. While this is technically true, they seem to be vastly underestimating how far off we are from seeing this happen.

Starting at the client level, whether it is a browser, mail server or mail client. At the moment very few clients have native support, and most seem to need to be patched which is not something the vast majority of end users would be comfortable doing. Microsoft only seem to be supporting DNSSEC in Windows 7 and Windows 2008, although I could be wrong on this. Then there's the variety of browsers on the variety of mobile devices. In all cases it's more likely that you'll have IPv6 support!

The next step would be the dns resolver that the client talks to. This could be your ISP's resolver, your local router, a third party such as OpenDNS and Google or possibly a dedicated local server. At the moment then chances of them being DNSSEC enabled is minuscule.

In the case of local routers (CPE), Nominet tested a cross section of CPE devices in 2008. The result?
As a consequence, we conclude that just 6 units (25%) operate
with full DNSSEC compatibility "out of the box." 9 units (37%)
can be reconfigured to bypass DNS proxy incompatibilities.
Unfortunately, the rest (38%) lack reconfigurable DHCP DNS
parameters, making it harder for LAN clients to bypass their
interference with DNSSEC use.
Of course even if the router supports DNSSEC, you then have to make sure that the upstream DNS servers support it, which is by no means a given. Comcast are still only testing it which probably puts them well ahead of their competition.

Then you have to make sure that any firewalls between you and the upstream DNS server are correctly setup. It's not unknown for Network Admins to only allow UDP packets over port 53. This will break horribly with DNSSEC as the response to a query will be a lot bigger so it's very likely that the server will have to fall back on TCP. Even if the the Network Admin has opened TCP port 53, it's possibly that the firewall "knows" that a DNS packet can ever be larger than X bytes, and will indiscriminately drop any packets larger than it's set limit.

Then there's the root servers and the various TLD servers. The earliest that we'll see a signed root zone is July 2010, and that's presuming that their testing goes well. PIR have implemented it on .org already, and various other cctlds have either implemented or have testbeds. Verisign have said that Q1 2011 is when they expect to have it rolled out for .net and .com.

Presuming that all the above has been fully implemented, it's possible that DNSSEC would have stopped what happened on Mar 24th. However, then there's the leaking of more specific routes such as what happened Youtube in 2008, but that's a different problem with different fixes.

The above is only a very quick and nasty overview of the issues with DNSSEC at the moment as far as a client is concerned. There's plenty of other issues to be sorted out such as transferring domains and key rollover among others.

Then there's the human element. Phishing won't be cured by DNSSEC, most phishing attacks use absolutely random urls, such as http://this.is.a.fake.url.com/path/to/bankhomepage.com/login.html.  The deployment of DNSSEC also won't force people to upgrade their browsers, IE 5 and IE 6 still make a good percentage of the the browsers out there!

Unfortunately, DNSSEC is going to remain very much pie in the sky for the time being. 

About this Archive

This page is an archive of entries from April 2010 listed from newest to oldest.

June 2009 is the previous archive.

May 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Creative Commons License
This blog is licensed under a Creative Commons License.
Powered by Movable Type 5.02