DNSSEC Still Pie In The Sky

| 4 Comments | No TrackBacks
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. 

No TrackBacks

TrackBack URL: http://nialldonegan.me/cgi-bin/mt-tb.cgi/82

4 Comments

What's betting we all end up using IPv6 long before DNSSEC? At least it has a compelling use case and no reasonable alternative, unlike DNSSEC. Say whatever you might about DNSCurve, but at least a design like that is simple enough and transparent enough to be gradually deployed without sacrificing small animals.

Any change you could enable OpenID?

Well, seeing as you connected via IPv6 to leave that comment, I would say that IPv6 has had a bit of a head start.

In fairness, there's some decent tools for managing DNSSEC coming online such as OpenDNSSEC, however there's a lot left to do.

The main advantage of DNSSEC over DNSCuvre as I see it is that DNSSEC will provide end to end security. DNSCurve wins on ease of use though.

OpenID has been enabled.

Interesting article, but let's assume for a moment that there is no magic bullet, and that DNSSEC is assumed to be neither a magic bullet nor instantly globally deployable.

DNSSEC appears to solve a number of problems - not all of them - and is a logical next step towards providing a level of security and authority to the data we now rely on heavily on the internet. This will take time and testing before deployment - but then again, so does everything else. Just because it's not completely deployed overnight does not negate its usefulness. Seat belts in cars took a long time to introduce globally and a longer time to become mandatory and still provide zero protection against a truck jackknifing and crushing your car from the top - but that doesn't negate the usefulness of seat belts or make them inherently 'pie in the sky.'

Firewalls configured to allow UDP only for DNS are already 'broken' - that's not a fault in DNSSEC, and DNSSEC is not required to make packets too large for UDP only. Also, IPv6 deployment doesn't negate the need for DNSSEC - both solve a different problem and both are required.

You're absolutely right though, support in CPE devices and indeed elsewhere is limited and we need to push manufacturers to start supporting this. Same with IPv6, same with RADSEC, same with SSH support for administration, same with jumboframe support, etc., etc.

DNSSEC fulfills a need and is being rolled out - but we all have to accept that this will take time and not rubbish the work already done just because it's not 100% effective. Indeed, the message that network device and Operating System producers should be building in support for these services should be the main thrust of your post, IMHO :)

Best regards,
-->Gar

I admit that the tone of the post was a bit negative. It was more a reaction to the absolute enthusiasm that Affilias are promoting DNSSEC with at the moment without going into any of the pitfalls!

DNSSEC does, as you say, solve a lot of problems. However, along the way it has turned into a fairly complex system which will take a long time to fully deploy. Strangely enough, someone else used the exact same safety belt analogy in an email reply!

I'm actually going through what will need to be done to deploy DNSSEC at work, so I'm getting to learn the pitfalls first hand and fix up any issues that are appearing.

To be brutally honest, we have a lot of customers who wouldn't be able to tell the difference between an A record and a bagel, and nor do they need to as long as they can upload their website. Unless Hosters and Registrars abstract away a lot of the complexity, the vast majority of domain owners aren't going to make user of DNSSEC. And I include companies who should be looking at deploying it in that group.

Of course the issue then becomes, how do you securely abstract away the details!

Leave a comment

About this Entry

This page contains a single entry by Niall Donegan published on April 14, 2010 5:09 PM.

Enhanced AIB Security? was the previous entry in this blog.

Selection Bias In Virtualisation Marketing is the next entry in this blog.

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

Pages

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