Secure DNS a Hard Sell

ebresie writes "Computer Business Review Online has an interesting article about the lack of acceptance for Secure DNS." From the article: "Speaking during a workshop on the technology, Keith Schwalm of Good Harbor Consulting, a former US Secret Service agent, said that even the financial sector, traditional security early-adopters, are not rushing DNSsec."

Re:Nice, but not necessary

[razvedchik]

I disagree. What you are talking about is the research part of a good or determined attacker. In this instance, the zone transfer is just more information on what to attack. This definitely is not a big risk.

However, there is much more associated with DNS that you can do.

If I am a user, what I want is 100% confidence that I am connecting to the correct server. I'm trusting in the DNS chain all the way up to the root server and then on to the authoritative server. What's to keep an attacker from routing me somewhere that I don't want to go?

A good example is a piece of malware that changes the local DNS cache to point ebay to another server that does a man-in-the-middle attack? To the end user, it's completely invisible.

It's fairly easy to do on a LAN by using one of the mitm tools. What you are doing is setting up a rogue DHCP server and DNS server, then you give the target computer a lease with a machine you control as the DNS server. If you control DNS, you can tell them to go anywhere you want, including sniffing their traffic, altering the content of the traffic enroute, basically whatever you want.

Not gonna happen anytime soon.

[Crispix]

The goal of all this is to prevent phishing and other exploits? I think SPF will make a much bigger difference in cutting down on internet "crap". SPF seems much more likely to make a difference, and good luck getting secure DNS implemented in a significant number of domains.

Re:Nice, but not necessary

[timeOday]

If I am a user, what I want is 100% confidence that I am connecting to the correct server. I'm trusting in the DNS chain all the way up to the root server and then on to the authoritative server. What's to keep an attacker from routing me somewhere that I don't want to go?

Secure protocols like ssl already solve the problem at a different level. DNS spoofing might get you connected to the wrong server, but when they fail the key-based challenge you'll know anyways. Even with secure DNS, those higher-level protocols would *still* have to carry out the checks they do now, since even after looking up the correct IP address, your IP packets could be misrouted. So what does secure DNS really buy you?

I'm not saying the authentication protocols already available (say in ssl) are entirely satisfactory, but duplicating them in DNS won't make them any better.

Re:bigger fear

[hal9000(jr)]

But if your ISPs DNS has been poisoned, then the attacker can resolve any host to the IP address of thier choice. If I control your ISP DNS server and I tell it that www.amazon.com resolves to 192.168.10.1 which is a web server I control, then I can send you a certificate claiming to be from www.amazon.com, and the DNS name will match the FQDN in the certificate. That wouldn't be a problem.

You will get a error dialog in the browser because YOUR browser certificate store probably doesn't have the signing CA certificate the attacker used to create the SSL cert for the rogue web server in the first place. But that is a different problem altogether.

Reason for not rushing adoption

[kts.nm]

DNSSEC is just one piece in an overall risk management process. There are other pressing issues on the same list. As was posted already, until there is an attack that makes securing DNS an immediate issue for an organization or a country there will not be as much action toward it. It is common for risk management to focus on the threats of today and attacks of yesterday. We are wrapped up in the past and not looking at threats and attacks of tomorrow. This appears to be where we are with securing DNS.

Hopefully some awareness and early adopters combined with some guidance on cost and benefit will change this.
--
-Ke

Actually, existing DNS can be very insecure...

[hkhito]

... even at very well managed sites. This recent paper [cornell.edu] from Cornell lays out some of the problem, showing how even the www.fbi.gov name can be hijacked by hacking in to seemingly completely unrelated servers, such as one of the name servers at telemail.net.

So for example, to hijack www.hsbc.com, you don't have to worry just about hsbc's name servers, com's name servers, and the root name servers. You also have to worry about the other servers that hsbc and com have deligated to, and the servers that they have deligated to, and on and on.

Re:dnssec and nym ala dan

[Just Some Guy]

You might not like Dan, but he doesn't get things wrong very often.

Unfortunately, he doesn't get things right very often, either. His programs are generally thought to be somewhat secure (only "somewhat" because he likes to blame found vulnerabilities on the underlying OS, which does jack all to actually fix the problem), but they tend to earn that reputation by only implementing small subsets of their respective protocols. A DNS server that won't sync to another isn't very useful to most people, but Dan will argue 'til he's blue in the face that every other option is unworkable and hopelessly insecure.

Dan also has a nasty habit of having his tail handed to him by experts in fields he wants to branch into (google Usenet for "dan berstein ntp" for examples). When he's right, he's usually more or less right. When he's wrong, he's very, very wrong.

Listen to what Dan has to say, then weigh it against what experts think on the subject. He may very well be right, but consider him to be a source of random information that needs to be carefully vetted.

Re:BIND "okay"?

[mellon]

"Not connected to the internet", then? BIND is notorious for remote root exploits. This by you is "okay"?

Do you mean BIND 8 or BIND 9? Looking at your google query, I see about four different hits that actually have to do with BIND, and they're all about BIND 8, and they are all the same root exploit, not four different root exploits. Along with them is a root exploit for tcpdump - are you proposing that we stop using tcpdump as well?

Seriously, if you want an open source name server, BIND 9 is an amazingly high-quality piece of software. I've never used djb's software, because I hate managing patch trees, and because I like BIND 9's automatic, secure zone transfers, which aren't supported by djbdns. Perhaps there is some value in it, but it's not worth it to me. Also, the cult of personality implicit in naming a product after yourself upsets my stomach. Should I have called the ISC DHCP server tedhcp?

If you are running BIND 8 because BIND 9 doesn't perform as well, first of all, the difference probably isn't as great as you've been led to believe. Secondly, you can probably afford a high-quality commercial name server, such as the one my employer [nominum.com] makes. Personally I don't think running BIND 8 is worth the headaches - it was a credible piece of software in the early days, but by the time version 8 rolled around, it was due for a rewrite, and that's why the ISC in fact completely rewrote it from scratch for version 9.