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."

Comments

Nice, but not necessary

[ehaggis]

DNS, if configured correctly, works well. Blind zone transfers and poor setup are usual culprits with exploits. A secure(r) DNS would be nice, but I think there are bigger security fish to fry.

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.

Re:Nice, but not necessary

[hal9000(jr)]

SecDNS doens't address poor set-up. It attemtps to assert zone authority through record signing. Right now, you don't know if DNS is resolving the correct address or not which makes poisoning such a nasty threat.

RUMOR has it that Verisign can't sign the records fast enough, however. Public key operations are so slow, that by they can't get through the whole .com zone before they begin to expire. Anyone know any different?

Re:Nice, but not necessary

[Cruithne]

lol no this is not a virus You mean like that? :)

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:Nice, but not necessary

[SatanicPuppy]

Sure, but DNS as it stands is much better in terms of scalability and redundancy. If you add a lot of authentication and double checking, the whole system becomes less efficient.

Your scenario is plausible, but if someone is in a position to execute a Man in the Middle attack, then they can just snoop your traffic by redirecting it through a proxy under their control...Why bother with a DNS redirect? Cache poisoning exploits have been around forever, but they're not all that common either.

I think the reason no one is rushing to switch over, is that things are still working pretty well as it stands.

Re:Nice, but not necessary

[Professor_UNIX]

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.

That's your problem though, not mine as a server admin. Besides, a simple SSL server would foil that attack and pop up a warning that the server names don't match the certificate. Again, if you as a user are so completely braindead that you ignore the warning then it's your own damn fault for getting your information compromised. Besides, what good is DNSSEC going to do if your machine is already compromised by malware installed on your machine!? Stop using Windows for Christ's sake before you point the finger at one of the most stable elements of the Internet architecture. 95% of the problems people have are their god damn Windows box having spyware or viruses on it.

Re:Nice, but not necessary

[mellon]

Most people can't tell if they are connected using SSL or not. One of the nice things about secure DNS is that if the DNS response is spoofed, it just doesn't come back. So if you have someone spoofing a zone, you don't see answers to the zone, rather than seeing and accepting the wrong answers. This leads to trying to figure out why "the internet isn't working," which leads to the revelation that someone is spoofing DNS, which leads to the problem being corrected.

To spoof you without secure DNS, all I have to do is present a copy of the real web page that has all the https:/// strings substituted for http:/// - at that point unless you're fairly sophisticated, you're going to wind up sending your info to the spoofer, and you're not going to know that you've been spoofed.

This is not to say that secure DNS is a panacea, but if it were deployed on a widespread basis, it would solve a number of significant problems.

By the way, speaking of SSL again, it has no root key rollover. Your root keys are preconfigured in your browser. So if a root key is ever compromised, your browser is going to be vulnerable until such time as you download a new copy, even assuming that the root key compromise is detected. DNS also lacks root key rollover right now, but this is a problem that is being worked on, whereas as far as I can tell in the SSL world, at least on a practical level, it's not.

Re:Nice, but not necessary

[cat6509]

"...That's your problem though, not mine as a server admin. Besides, a simple SSL server would foil that attack and pop up a warning that the server names don't match the certificate...."

If I am truely in the middle, i can rewrite URL, present other certificates etc, ( spoof the certificate authority too even ), all this software technology exists Load balancers content switches ssl concentrators all have to legitmately do this now.

All that being said, this is currently not the biggest threat, although pulled off successfully could efect many at time.

Re:Nice, but not necessary

[razvedchik]

The way I look at it is like PKI (remember when it was the silver bullet to everybody's security concerns? It always make me cringe when people started talking PKI for a company with 15 employees). It works great if you are a huge organization like the government, but if most people will not see any benefit of it at all. But then again, most government agencies have their own Certificate Authority, which makes DNSSec and PKI easier to tie into.

And, to be honest, I like SSL better than DNSSec because there already is some sort of infrastructure and trust relationship that already exists, so I agree with you. But the parent post wasn't understanding what secure DNS was. =)

Re:Nice, but not necessary

[hackstraw]

What's to keep an attacker from routing me somewhere that I don't want to go?

An SSL certificate.

The cert name and the DNS name must agree.

Re:Nice, but not necessary

[nihaopaul]

so this would stop china from its middleman dns attacks? where do i sign up?
one way they filter sites is to return false dns information for lets say one site: no-ip.com:

;no-ip.com. IN A

;; ANSWER SECTION:
no-ip.com. 86395 IN A 169.132.13.103

;; AUTHORITY SECTION:
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
[snip]

and request it again:

;; ANSWER SECTION:
no-ip.com. 1D IN A 64.66.163.251

;; AUTHORITY SECTION:
com. 17h10m38s IN NS H.GTLD-SERVERS.NET.
com. 17h10m38s IN NS I.GTLD-SERVERS.NET.
com. 17h10m38s IN NS J.GTLD-SERVERS.NET.
[snip]

but i have a server elsewhere (via ssh) that would return the real records:

;; QUESTION SECTION:
;no-ip.com. IN NS

;; ANSWER SECTION:
no-ip.com. 160322 IN NS nf2.no-ip.com.
no-ip.com. 160322 IN NS nf3.no-ip.com.
no-ip.com. 160322 IN NS nf4.no-ip.com.
no-ip.com. 160322 IN NS nf1.no-ip.com.

;; ADDITIONAL SECTION:
nf2.no-ip.com. 12426 IN A 216.66.37.12
nf3.no-ip.com. 47790 IN A 70.86.196.66
nf4.no-ip.com. 73793 IN A 63.208.74.227
nf1.no-ip.com. 28090 IN A 204.16.252.8

so securedns would foil that filtering method?

Re:Nice, but not necessary

[Gud]

Rumor is false, with hardware accelerator .com can be signed in
about 1 hour on a fast AMD system.
The distribution of the zone is a bigger issue, but most of the time only fragments of the zone would be signed at the same time.

Re:Nice, but not necessary

[turbidostato]

"Most people can't tell if they are connected using SSL or not"

Those are beyond salvation and I don't think that secure DNS was developed with them in mind.

I mean, someone which will accept following an hyperlink coming on a html e-mail from somebody unknown to him that says "your.bank.of.confidence" while obviously opening a browser pointing to "your.hacker.of.the.day" won't benefit any more from using secure DNS.

Re:Nice, but not necessary

[hardaker]

RUMOR has it that Verisign can't sign the records fast enough, however. Public key operations are so slow, that by they can't get through the whole .com zone before they begin to expire. Anyone know any different?

That's not true... They have indeed signed the whole .com zone in practice on some fairly decent machines and it was on the order of hours (if I recall; I think 6), not months which is the more likely signature life time they'd pick

Re:Nice, but not necessary

[turbidostato]

"If I am truely in the middle, i can rewrite URL, present other certificates etc, ( spoof the certificate authority too even )"

So what?

You, as a user, are deem to stablish your own security rules. You, as a MiM, can only defeat a first-time unknowledgeable visitor: I'd want to see you trying to offer me a root CA public key... for a CA I already know about... or the public key for a site I already visited. And if it is a site I visit for first time, I want you to try to offer me a fraudulent key-chain, or try to defeat me with a "sudden" new CA, or trying to redirect me out the *entire* Internet, so I can't use Google, Yahoo, or any other web crawler of my choice to recheck the public key from the CA.

"all this software technology exists Load balancers content switches ssl concentrators all have to legitmately do this now"

All they can legitimately gain knowledge about the proper secret key, or they won't work at all.

"although pulled off successfully could efect many at time"

The knowledge and/or situation needed for such an attack to become successful insures you can successfully try more effective attacks.

All in all, dns-related attacks are not and can't target the Internet in the wild but can be effectively used on Intranet/in-house or corporation-to-corporation environments because a) then it's easier to spoof the (relative) whole internet and b) most probably there will be less in-deep security measures (like not using https because your are confident about the network path being secure).

Re:Nice, but not necessary

[bogado]

If you have a malware that poisoned your DNS cache, it might as well install a new trusted key in your browser. The malware site can then have another key that is signed with the key that the malware have already installed and you will have a secured connection.

But starting with a corrupted computer to begin with is a bad example anyway. The malware could simply substitute the ie.exe program for a new one that show what he want.

Re:Nice, but not necessary

[askegg]

SSL does not solve DNS issues. Nothing prevents determined hackers from installing an SSL certificate on their phishing website to look like the real thing - most users don't know the difference anyway.

Re:Nice, but not necessary

[memodude]

SSL does nothing to prove you're connecting to the right site if the attacker gets a cert from a CA. Most of the CAs now have "instant" SSL certs which have zero identity checking and a lower price. Very few users pay attention to the SSL icon, but even fewer open up the certificate properties and verify that the organization name on the cert is from who they think it is.

Re:Nice, but not necessary

[Anonymous Coward]

You're trusting the layer 1-6 routing all the way from your machine to the DNS server and the final destination as well. But I don't see anyone suggesting that we implement SecureMAC to ensure that my layer 2 switch doesn't get spoofed.

Re:Nice, but not necessary

[Wikipedia]

Funny you should say that, because hotmail never matches up with cb1.msn.com, and mail.yahoo.com never matches up with login.yahoo.com, and logging in at login.yahoo.com only brings you to the main www.yahoo.com page, so essentially you're always clicking "accept this blahblah for this session". mail.google.com always matches correctly, as expected.

Re:Nice, but not necessary

[Wikipedia]

Have you heard of Tor?
http://tor.eff.org/
offtopic but essential

Tor: An anonymous Internet communication system Tor is a toolset for a wide range of organizations and people that want to improve their safety and security on the Internet. Using Tor can help you anonymize web browsing and publishing, instant messaging, IRC, SSH, and other applications that use the TCP protocol. Tor also provides a platform on which software developers can build new applications with built-in anonymity, safety, and privacy features. Your traffic is safer when you use Tor, because communications are bounced around a distributed network of servers, called onion routers. Tor's technology aims to provide Internet users with protection against "traffic analysis," a form of network surveillance that threatens personal anonymity and privacy, confidential business activities and relationships, and state security. Instead of looking at the content of your communications, traffic analysis tracks where your data goes and when, as well as how much is sent. Tor aims to make traffic analysis more difficult by preventing websites, eavesdroppers, and even the onion routers themselves from tracing your communications online. This means Tor lets you decide whether to identify yourself when you communicate. Tor's security is improved as its user base grows and as more people volunteer to run servers. Please consider volunteering your time or volunteering your bandwidth. And remember that this is development code--it's not a good idea to rely on the current Tor network if you really need strong anonymity. We are now actively looking for new sponsors and funding. The Tor project was launched by The Free Haven Project in 2002. In the past, Tor development was funded by contracts with the Naval Research Lab (inventor of onion routing) and the Electronic Frontier Foundation (who still kindly hosts our website). Sponsors of Tor get personal attention, better support, publicity (if they want it), and get to influence the direction of our research and development!

Hard to understand

[Mr. Flibble]

Enough of my customers don't understand REGULAR DNS, nevermind secure DNS. The only way that this is likely to be adopted is to have the top level name servers eventually require the secure extensions. I doubt, however, that that will happen.

As it is now, I have my users going to their registrars and "deleting the 'A' records because: "There is no A on my website."

Re:Hard to understand

[LilGuy]

Hahaha. That last statement was priceless. Now send me a squeegy to clean off my monitor.

Re:Hard to understand

[TerminalInsanity]

Hard to understand

When i visited the dnssec site, thats what came to my mind... but it had more to do with the abhorrent use of ad space.

Re:Hard to understand

[Anonymous Coward]

The only way that this is likely to be adopted is to have the top level name servers eventually require the secure extensions.

Or if a widespread exploit comes onto the scene. Security problems don't exist for most people or companies until there's some direct cost to be paid.

Re:Hard to understand

[TheBeardIsRed]

I agree with this completely. Far too often I am working with customers who can't even understand the basics of their own DNS. It's a large enough challenge to get people to realize that their MX records have to be in place if they want to recieve mail or getting them to understand what a zone transfer is let alone the importance of limiting who can do zone transfers and the like. Moving over to secure dns, while nice, would be a party trick at the moment.

Look at the abundance of well built DNS daemons in place.... PowerDNS, Daniel Bernsteins djbDNS, MaraDNS. Hell djbDNS has an ongoing cash prize to people who can find security vulnerabilities in the latest production version. Still though, people stick with microsoft dns and bind.

bigger fear

[keithhackworth]

I run my own DNS server at home because I have a bigger fear that my ISP's DNS may be hijacked rather than my bank. It seems like that would be the easiest hole to crack for hackers.

I would hope that if my bank's DNS servers were hijacked that they would work with me to get any money I lost back. However, if my ISP's DNS servers were hijacked, I don't know that the bank would be as cooperative.

Keith

Re:bigger fear

[Dolda2000]

That oughtn't be a great problem, however, since your bank (hopefully?) uses a SSL certificate to ensure you that you are on the right web site. If you click past the SSL warning that says that the certificate doesn't match the domain name when you go to do some on-line banking, you really shouldn't be all too surprised to find all your money gone the next day.

Re:bigger fear

[rbannon]

I guess I am really clueless, but don't banks use a security certificate so that a user like myself won't be misled into thinking that a spoofed site is really the bank? For example, I am a customer of bankX.com and I let my browser verify the site, if it's the right site I get the right response, if it's the wrong site I don't get the proper response.

I do this with my machine at work too, I use ssh with a public/private key set-up. If someone highjacks my machine I will be informed when I log on --- actually happened on to me on a university managed UNIX machine.

Am I safe, or am I clueless?

Free iPod?

Re:bigger fear

[iambarry]

That's why your bank uses HTTPS with a server certificate. They assume that DNS is going to be owned by an attacker.

The lock in the browser confirms that the site in the URL is the one serving the page.

Re:bigger fear

[iambarry]

Guess everyone posted the same answer at the same time :)

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.

Re:bigger fear

[Dolda2000]

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.

Yes, well, that was exactly what I was referring to. One shouldn't even begin to suspect that a bank would have a web server certificate that wasn't signed by one of the big CAs.

Re:bigger fear

[Ucklak]

They wouldn't even have to get the warning.

www.spoofedbank.com that looks like Bank of America can get a certificate on their own and the end user wouldn't even know. How many non-slashdotters never or even know how to read a certificate? They just clicky through.

Of course there would be somewhat of a trail if the cert is signed by a CA and that's the only way they won't get a popup.

Re:bigger fear

[baadger]

How much hard checking do these CA's really do? The user won't notice if it's a smaller CA as long as the root cert is in their trusted list.

Re:bigger fear

[Dolda2000]

Then again, if the user goes to www.spoofedbank.com instead of www.bankofamerica.com, then it's not a problem with DNS.

Re:bigger fear

[hal9000(jr)]

Yeah, and that is especially a concern with all the DNS registrars. Can they be trusted to really identify that some one is who they say they are beyond taking the information off of a credit card statement?

Re:bigger fear

[morgan_greywolf]

Wait. So your solution to the insecurity of DNS is to run a another DNS server? That sounds a bit insane to me. What if someone hacked the root DNS servers? It's been done before.

Seems like a more sane solution would be to add your banks IP address to your /etc/hosts file(s) and then set the /etc/nsswitch.conf hosts entry to 'files dns'. Then, if the bank's IP address changes, confirm it with the bank's IT department.

Re:bigger fear

[Agelmar]

This is a valid point, especially when you look at the number of small fish in the pond. You have small registrars, you have small CAs (do you really trust Unizeto? I don't even know what it is, and yet by default Mozilla gives it the same trust as it gives Verisign.) Even so, I posit that it really doesn't matter how much trust I can place in the CAs and the registrars, because the (unfortunate) end result is that most users, when presented with a certificate error, simply click OK. We train users to do this. Many corporate and educational entities set up their own CAs, and then when users see a message in their browser about an untrusted CA, the tech staff just tells them to 'click ok'. As such, the user is now conditioned to click 'OK'. What have we done? Totally diminished the usefulness of the trust aspect of SSL.

Re:bigger fear

[ehrichweiss]

" How much hard checking do these CA's really do?"

Quite a bit actually. I quote Godaddy.com's Wildcard High Assurance 256bit SSL Cert "The Validation Process verifies: domain name and domain control; identity and authority of requesting person or company". I think some of the personal verification steps include credit reports and the like. Funny that I was JUST thinking of this last night.

Re:bigger fear

[utlemming]

How about performance issues? I found that running my own DNS server actually increased my internet speeds. The computer was spending less time trying to find the websites and was actually getting to them. Then again, the internet providers in South Eastern Idaho are pretty brain dead. So it was no suprise. At the time that I put up the DNS server, I was living with room mates, and they actually connected to the server, and within about a month I had an entire building connecting to my FreeBSD 4.6 box. The best part was that they were totally understanding whenever I had to do an upgrade or took it down to work on a project or tinker. The way I had them setup was me as the primary DNS and then then I had the secondary as public DNS server. Sure, it wasn't as fast (the secondary DNS), and ever time I did something with my computer, they would ask, but they were just glad to be able to get the performance increase of being able to use my DNS server. My speculation about the reason why the DNS server was slow is because of the filters on gateway that the apartment complex was using. My guess is that the gateway was using some sort of logging. They also used MAC filtering and the like to be real pricks. Needless to say when I moved out, I was real pleased to have normal internet again. I wasn't the nicest of netizens, since I connected my DNS to the root servers, instead of my ISP, but oh well.

Re:bigger fear

[hardaker]

What if someone hacked the root DNS servers? It's been done before.

If the roots get signed, they'll certainly going to be using off-line signing so the private half of the signing key won't be kept on the servers themselves. Thus, an attacker couldn't modify the data without people that were already aware of the public key wouldn't detect (and if they tried to change the key validating resolvers with the root keys installed as trust anchors would notice the difference and ignore the answers; end result a DoS at best instead of bogus data).

Re:bigger fear

[ednopantz]

" How much hard checking do these CA's really do?"
Thawte just wanted a fax of our phone bill. Ours even had the wrong company name. I told them to look up our newly filed "doing business as" statement, but I don't know if they did.

Maybe if we claimed to be Chase.com they would care.

Re:bigger fear

[Dolda2000]

How much hard checking do these CA's really do?

I would believe that browser developers don't put CAs in the root CA set without very good reason. I haven't been requesting any certificates myself (I run my own CA instead for home use), but I believe that all the CAs in the standard browsers' root CA lists do very stringent control of the applicants.

After all, if they didn't, they wouldn't remain in the browsers' root CA list for very long.

Nice, but not necessary-A royal pane.

[Anonymous Coward]

"A secure(r) DNS would be nice, but I think there are bigger security fish to fry."

Windows.

Re:Nice, but not necessary-A royal pane.

[stefanlasiewski]

Windows is not a fish. It's a feature.

Re:Nice, but not necessary-A royal pane.

[Anonymous Coward]

Riiiiighhhht. This page was obviously put up by one of his dickhead students (and a not very bright or creative one at that).

Was it you? Or are you really dumb enough to think it was real?

I suggest growing up as your first priority.

Re:Nice, but not necessary-A royal pane.

[Anonymous Coward]

somehow im not amazed that every post in his recent posts lists is scored at -1?

Same as Sony

[Nom du Keyboard]

While the vulnerabilities in the DNS are well known, the absence of widespread attacks, regulations, and proven business models are holding back DNSsec adoption

One could have said the same thing about music CD DRM (e.g. the Sony XCP RootKit) -- or the 9/11 terrorist attacks for that matter.

There's not a problem with it -- until there's a big problem with it. Then everyone asks why wasn't something done to protect us against it?

Re:Same as Sony

[ImaLamer]

the absence of widespread attacks

It's true, nothing gets the ol' blood pumping for action than a good Reichstag fire!

Also

[Anonymous Coward]

Wasn't this proposal Microsoft designed, breaks the standard, and patent-encumbered?

secure domains

[digitaldc]

"Some registrars talk of adding a "significant" add-on fee for DNSsec "expert services", while others talk of making domain registration a case of picking from two services -- a domain name and a "secure domain name", the latter costing more."

So you have domain, secure domain, and when that gets compromised, you will then have super secure domains, ultra secure domains, and supermax domains?

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:Not gonna happen anytime soon.

[ehrichweiss]

SPF is for email, not *general* DNS operations like web browsing, ftp, etc. so it would have zero usage in DNS hijacking and actually might make it easier in some regards to send spam through a hijacked DNS server.

A solution looking for a problem?

[26199]

We already have authentication systems. Why should DNS, which every website uses, be doing something which only a tiny fraction of websites need?

Besides -- technology can't stop phishing. A combination of education, authentication and client software that can with 100% reliability inform the user whether authentication has happened is the answer. Authentication is by far the easiest problem of the three. Education is more or less impossible, and reliably informing users is next to impossible. (In a web browser, anyway. If you let websites display images and run active content, how do you stop them fooling a user, even a well educated one? How do you guarantee it's impossible to do so?)

A Modest Proposal

[Nom du Keyboard]

What it might take to bring about adoption would be a .sec TLD that only operates with DNSsec, and any other major security improvements. Banks and others might prefer to be associated with a domain that is secure from the beginning, spurring its adoption. This way the market place would decide since it would have a real choice.

Re:A Modest Proposal

[g0at]

How about a .balls domain to which we may attach our testicles?

Er, pardon me. I'm flipping out today.

-b

Re:A Modest Proposal

[schon]

What it might take to bring about adoption would be a .sec TLD that only operates with DNSsec

The thing is that this isn't really feasable, because you have to replace all the client software to make it work - and at that point you might as well mandate IPV6 with IPSEC.

Think about it: DNS is only as secure as its weakest link, and that link is the desktop. If your suggestion is implemented without making every desktop aware of the .sec TLD's requirement to use DNSsec, all an attacker has to do is convince your desktop to talk to his DNS server (which is pretty easy, if you think about it) and it's game over.

Re:A Modest Proposal

[turbidostato]

"Think about it: DNS is only as secure as its weakest link, and that link is the desktop"

Truly speaking it's a bit beyond the desktop.

Between the desktop and the chair, to name it precisely.

Perhaps better marketing?

[Halo-]

I know this is a rather stupid thing to be hung up on, but the referenced link (DNSsec.org) was so visually cluttered and ugly that I couldn't muster the desire to spend much time there.

Security is always harder to sell than most products, because you are usually trying to convince a customer to spend more time and money for something without out a tangiable return. (If my DNS hasn't been spoofed yet, why pay money? And even if they do secure it, they don't have an easy way to say: "this saved us X dollars this year, and thus was worth the investment")

Add in an "official" website which is hard to read, and painful on the eyes, and you've got a hard sell indeed. As petty as it sounds, a better web presence might help ease acceptance.

Re:Perhaps better marketing?

[Eric Giguere]

It's not an official site, though, just a compilation of DNSSEC information. It actually seems to be very comprehensive, obviously the compiler put a lot of effort into it. Maybe a bit crowded layout on the home page, yes, but lots of info. But here's the direct link to RFC 4033 if that helps.

Eric
Read my Invisible Fence Guide

Re:Perhaps better marketing?

[hey]

If there was a little logo banks, etc can put on their site:
[we proudly use Secure DNS]
Soon everyone would want it.

DNS; not so hard really

[SpinJaunt]

I will admit that a first glance DNS is a real PITA, but a little persistance like with most things and you'll come out smelling of roses. Watching the first AXFR is quite something.

I thought about doing Secure DNS but seems highly irrelevant on a private home network.

at the end of the day, it is lazyness, lack of understanding the Whole PictureTM and the old mantra of "Why change what works already".

Re:DNS; not so hard really

[Tony Hoyle]

I tried to setup dnssec at one point and just screwed up my working system, as the documentation didn't match the behaviour of the server.

The biggest killer is having to pay verisign for the privilege.. Domain $15, certificate to authenticate domain $100. Yeah, that'll fly..

dnssec and nym ala dan

[arakis]

Dan is the man in DNS. He pretty much explains why they don't have implementation here:

http://cr.yp.to/djbdns/forgery.html

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

Re:dnssec and nym ala dan

[Anonymous Coward]

I disagree. Qmail is a prime example of getting things very wrong.

Re:dnssec and nym ala dan

[mellon]

Bwahahahahahaha!

I find Dan highly amusing, and would find a world without him a sadder place, but that's an opinion piece, without an iota of basis for any of the assertions he makes.

The one factoid he presents is the Microsoft ActiveX key spoof, which is indeed interesting. It also isn't addressed by his proposal, so I'm not sure what good it is. As for querying multiple servers to validate a lookup, that's a fun idea, but you still haven't cryptographically authenticated the information, and all it would take to hack this would be to successfully spoof the NS records for the zone, which isn't particularly harder than spoofing the zone itself.

The reason that reputation-based security works is that you have an active, intelligent participant tracking reputation; even in that case, it works only so well - many of the spoofs we're talking about here actually take advantage of someone's trust in reputation, by convincing the person that they are talking to someone to whom they are not actually talking. The better a critical thinker you are, the better reputation-based security will work for you; the more you know in the moment about the person to whom you are talking, the better it will work for you. Lacking either of these, as is the case with Dan's proposal, you've got nothing but a house of cards.

Re:dnssec and nym ala dan

[drewzhrodague]

I'm sure Dan is a nice guy, but his work (Qmail) has made me pull my long hair out by the handful. I prefer, that when I install stuff onto a UNIX machine, that the package I am installing doesn't EAT MY COMPUTER. Every time I've succombed to people's opinions about Qmail, and how great it is, and want to give it a try, I am again reminded that sendmail already works, is already installed, and already configured, and that I've just fucked up everything by installing Qmail. As an added bonus, qmail generates a constant stream of errors, enough to render the machine unusable. TinyDNS is another story, and I've seen this work properly in some situations. However, I think BIND works okay, and I am perfectly happy with my DNS the way it is. DNS works, why do people and government organizations want to fuck it up?

Re:dnssec and nym ala dan

[19thNervousBreakdown]

How does qmail eat your computer?

True, I'm not a big fan of it's default install location, but you can almost certainly change that. Well, since it's distributed in source form, even if it's not a config option it'd probably be pretty easy to change even if every path is hardcoded. You have to add a few new users, but pretty much every service on your machine should have its own locked down user. You have to install daemontools, but that's just a dependency, nothing new to us UNIX folks.

As for a constant stream of errors... chances are pretty good you messed something up. Not for nothing, but there's a reason that qmail hit 1.03 and stopped. The install and config process could use a bit of work, I'll admit that. It's not that bad though, and as it is if you successfully get qmail up and running it's almost as good as giving an IQ test to anyone who wants to run a mail server.

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:dnssec and nym ala dan

[mabinogi]

I notice you're not willing to put your name to that statement.

Re:dnssec and nym ala dan

[papason]

I disagree. qmail is the best MTA IMHO. djbdns is also the best in DNS/dnscache/rbldns/walldns/etc.

Re:dnssec and nym ala dan

[Anonymous Coward]

I don't understand how anyone can screw up their computer by installing qmail if they bother to read the excellent instructions available for qmail.

A free book on qmail, Life with Qmail, is even available online and the quality is similar to Subversion's book which is among the best downloadable tech books available. It describes how to install netqmail-1.05 which is basically qmail-1.03 with a minimal recommended set of patches:

http://www.lifewithqmail.org/lwq.html

A company, Inter7, provides commercial qmail support but they publish most of their qmail-related software as GPL open source projects which can be downloaded and redistributed for free. They are super easy to use.

And then there's http://www.qmailrocks.org/ which offers installation scripts for qmail plus a dozen optional qmail-addons for these operating systems:

* Redhat Linux/RHEL
* Fedora Core
* FreeBSD
* Debian
* Slackware
* Solaris
* coming soon: Suse and OpenBSD

You can blame qmail for eating your system, but I was able to install it fine (manually from scratch) as my very first MTA ever and it worked fine. I didn't even fully understand bash or symbolic links at the time but managed to do fine.

NOTE: I installed (and still use) netqmail-1.05 + vpopmail-5.4.x + qmailadmin-1.2.x installation without all the extras available from qmailrocks.org

I chose qmail because it is currently the most secure MTA and that outweighed some of its disadvantages (like being slower than Postfix 2.2 by using more disk i/o and no-binary license). I'm considering a switch to postfix 2.3/2.4 when that branch is stable purely out of my curiosity and desire to be disloyal to every software/OS/distro I ever use. Switching whenever a *sufficiently* better software comes along (disloyalty) promotes better software all around.

UNBIASED SUMMARY OF MTA
(I'm using qmail+vpopmail in 2005-6, postfix in 2007-8, exim in 2009-10, qmail-2.0?)

qmail: most secure so far (amazingly so), easy to configure/admin after install, but not as good for relaying, slower than postfix, only unmodified source can be redistributed so installs are via patch+compile scripts, requires 'thedjbway' of doing things which I initially disliked but have grown to prefer it over init.d

postfix: 2nd most secure, fastest, not as mature as qmail but catching up fast

exim: monolithic & not as secure as qmail or postfix, usually fast but not for queued mails, Debian's default MTA means popularity will grow

I know some people think DJB (qmail author) is strange (he's a professor of computer science in illinois) but he managed to do 2 things that are rare:
1. write very widely used server-side software which managed to avoid serious security vulnerabilities for years: he helped us avoid using BIND and sendmail
2. fight the US govt. in court over cryptography

And for that, he deserves some respect regardless of what GPL fanatics say about him because of his unmodified-source-only distribution licenses. Their fanaticism is rivaled only by fundamentalist radicals infecting major religions like Christianity which ends up driving rational people away rather than toward it.

---

"Humans wrote the Bible. God wrote the world."
God vs Bible

Re:dnssec and nym ala dan

[DNS-and-BIND]

Yeah, I used to be a lurker on comp.protocols.ntp, and it was a nice little traditional Usenet group. Everyone polite, informative, etc. Then, one day, this total asshole barges in and starts flaming the regulars. I mean, using profanity and everything. Of course, in ntpd, everything is done for a reason, and it's not perfect, but it's pretty damn good. He started railing on about some leap second issue, and wouldn't stop. Any post that pointed out his shortcomings was typically answered with a stream of abuse instead of a refutation.

Money talks

[Billosaur]

From Computer Business Review: Some registrars talk of adding a "significant" add-on fee for DNSsec "expert services", while others talk of making domain registration a case of picking from two services -- a domain name and a "secure domain name", the latter costing more.

So in the end, economics will drive SecDNS more than anything else. It seems like a good idea though for some institutions to go to a more secure DNS format. Let's face it: Fred's House of Flowers probably doesn't need as secure a domain as Citicorp or the CIA. The Internet ends up becoming a two-level affair, with the majority of sites being regular DNS sites and corporations and such using the more secure DNS setup.

Re:Money talks

[mellon]

If Fred's House of Flowers has your credit card info, and it's not secure, then it's the weak link in the chain, and it's the place where the attack will happen. I don't mean to say that in order for secure DNS to be useful, everyone has to use it, but certainly if it comes into widespread use and its use makes it a lot harder to spoof secured sites, then the sites that aren't secured are the ones that are going to get spoofed.

Re:Money talks

[Billosaur]

Fred's House of Flowers wouldn't be doing the credit card processing though. That would be done through a bank or e-commerce firm, and they would supposedly be using the more secure domain. If not, I doubt anybody would do business with them. Social and business pressure would start to force unwilling companies to switch to the more secure format.

Redundant

[CyberVenom]

The problem with SecDNS is that pretty much the same thing is already performed at the SSL level with domain certificates, so there is little argument for changing the DNS system.
The article says:

It's possible that a web surfer could think they are visiting their bank or an auction site and hand over their sensitive data, and it would be impossible to tell they were at a malicious site.

I disagree: there is a good way to tell if that is your bank you are talking to; check that they have the proper SSL certificate for their domain. Or better yet, just look at the color of the address bar in Firefox. If your bank isn't using SSL already, there are reasons far beyond DNS that they should be!
Also, even with SecDNS in place, physical man-in-the-middle or route poisoning attacks could intercept the communication at the IP level, making SecDNS marginally useful at best. In my opinion, the proper solution would be to encourage more widespread adoption of the existing SSL cert solution for services other than HTTPS. (e.g. SMTP, POP, FTP) Also, it would be good for the industry to have some additional certificate authorities with lower certification prices added to the major browsers' default trust list.

Re:Redundant

[Anonymous Coward]

Checking the color of the bar in firefox doesn't tell you whether or not you are at your bank's website. It just tells you that you are at some web site who got their cert signed by an organization recognized by your browser. If you made a typo or got tricked into clicking on a link that you thought was for your bank and the web site looks like the one for you bank, you won't see a warning.

Re:Redundant

[Florian Weimer]

The problem with SecDNS is that pretty much the same thing is already performed at the SSL level with domain certificates, so there is little argument for changing the DNS system.

Once you've got a DNSSEC-enabled zone, you can put interesting things into it, like CERT RRs with SSH keys. The advantage is clear: you only pay for the delegation (the domain registration fee), and not for each server certificate individually.

Apart from the threat to existing CA business models, there are also some unsolved technical problems (cryptographically secured negative answers without providing zone enumeration, for example).

DNS Poisoning

[Anonymous Coward]

There used to be a technique called DNS cache poisoning. http://en.wikipedia.org/wiki/DNS_cache_poisoning
Where phishers could cause a URL to redirect to thier Phish site instead of the actual site. I'm guessing that this type of attack is rare enough that it doesn't hold the attention of the decision makers.

DNS, Phishing, and secure DNS

[queenb**ch]

Many phishing sites do offer authentication, just not to the place you thought. I've seen a couple that operate in MIM mode and they're growing in complexity as they try to avoid many of the new software applications that are out to catch them.

Changing the way authentication happens from 2-factor to 3-factor is the only viable means for defeating most of the current phishing sites, but a slight expansion to some of the new MIM sites will be able to manage that as well. Then what? DNS is definitely not the answer since most of the ones we see rely on cloaked URL's and not DNS to carry out the attacks. DNS is more like a phone book. Let me look up who I think I might want to talk to. If you dial the number and get the wrong person, you hang up and try again or try a different number.

Now, if you could do a secure DNS that could prevent someone from doing DNS footprinting of your network, then you might have something. Other than that, what's the use? This seems to be mostly directed at cache poisoning and domain hijacking. If you stop them at the DNS level, all that's going to do is point the hackers back to the registrars so that they can try to social engineer the hijack at the registrar level a la sex.com.

2 cents,

Queen B

Resistance from the DNS registries

[Anonymous Coward]

The major stumbling block to adoption is that the current specification of DNSSEC requires NXT records, used for proving NXDOMAIN responses. Unfortunately, the NXT records can also be used to walk the zone, which the registries are very unhappy with - they don't like the idea that the contents of their zone files might be publically available. They'd much prefer the contents of their databases to remain a deep dark secret, available only via individual queries.

That, and they've yet to figure out how to charge for this extra security. :>

Re:Resistance from the DNS registries

[hardaker]

The major stumbling block to adoption is that the current specification of DNSSEC requires NXT records

Unfortunately true, though you could delete all those records and be subject to name injection. The NXT records (actually called "NSEC" by the way not NXT) just protect against proof of non existence. There is a new version called NSEC3 which uses hashed names to get around the data leak.

dear somebody skilled.

[blackomegax]

please go to your local university with a wifi laptop and hack the current DNS system to death.

its called forced addaptation.

Re:dear somebody skilled.

[Al Dimond]

Ah, but don't most Universities with wifi force you to VPN before you can access anything? You'd have to be a student to do it and you'd be logged anyway. At least my University is this way.

On the other hand, there are various places around said University where you can plug in your cat5 and get to the Internet without VPN. Not the places where it's marked as OK to do so, mind you, mostly extra jacks in computer labs. I have a laptop but no wifi, and though I have no intention of doing anything illegal I'd never plug in in one of the general purpose University labs because they have lab monitors that would look at you funny. Same goes for the College of Engineering's workstation labs. But in the ECE department labs I do it all the time because: (1) no lab monitors, at most professors that you probably know (2) those labs are already a mess of cables anyway, so it doesn't stand out (3) relatedly, everyone re- and mis-configures the equipment constantly anyway for their projects.

You can't get it.

[mellon]

The main problem with "secure DNS" is that you can't get it. This is because some of the problems remain unsolved - the problem of key rollover is currently generating a huge debate on the namedroppers mailing list, not the least because one of the proposals being advanced is patented.

On top of that, even if you ignore the signing of the root key, by and large you can't get ad-hoc zone signing - if you want to secure a zone, everybody who's going to see it as secure needs a copy of the zone key, because your top level domain (e.g., .com) isn't in a signed zone.

On top of that, many TLD providers seem to want signed zones to be a value-added option rather than basic functionality. So as with RSA, lo those many years ago, adoption will be slow because people want to monetize it, rather than seeing it as basic functionality that has to be there.

So it's no surprise that the end user isn't interested in it yet - they can't get it even if they are interested.

Re:You can't get it.

[pawal]

The .SE-domain is running a signed zone since a couple of months as the first TLD in the world. Here is all you need to know.

Re:You can't get it.

[mellon]

Yeah, I know, it's very cool, but all my domains are in the US. So I could register in .se, but it would look weird to my users. And it still requires installing the zone key for .se in any resolver that's going to securely resolve DNS entries in my zone, so it's actually not that useful yet. But it is a nice start - I hope more TLDs follow suit.

Re:You can't get it.

[BVis]

http ://all.your.ba.se/are/belong/to/us

Am I a bad person if this was the first thing I thought of? (Space added so teh sl4sh doesn't auto-generate link)

Re:You can't get it.

[hardaker]

On top of that, even if you ignore the signing of the root key, by and large you can't get ad-hoc zone signing - if you want to secure a zone, everybody who's going to see it as secure needs a copy of the zone key, because your top level domain (e.g., .com) isn't in a signed zone.

FYI, there is at least some work being done on getting things signed by something other than your DNS parent. Look for the internet-drafts on "DLV" and the "lookaside" support in bind. It's unclear if this sort of work will advance in the IETF though.

Re:You can't get it.

[mellon]

No, you're a good pattern matcher. Which is a key part of being a geek. So wear your colors proudly, brother (or sister). :')

Mostly OT: How long for MX record propagation?

[Anonymous Coward]

I was just procrastinating from dealing with this question (by reading Slashdot) when I saw this very topical story ...

I'm moving mail hosting from one hosting company to another. Once I change the MX records (in DNS), in your realworld experience, how long before it's fully propagated across the Internets?

Theoretically, it should be no more than the TTL setting. But theoretically, the universe is made of 4 elements, rockets don't work in space, and time is constant -- so I don't put much faith in theory. What's your experience? I don't want to lose any mail during the transition.

(Just to clarify: I'm not changing to new name servers -- which takes days to propagate -- I'm just changing the MX record.)

Thank you! You may return to your thread now ...

Re:Mostly OT: How long for MX record propagation?

[PhilipPeake]

As you said, it should be no longer than the TTL. But in the real world there are some truely evil DNS implementations out there (Microsoft comes to mind) who choose not to follow standards, including not paying attention to TTL.

My own attitiude to people who accept and run such systems is simply "screw 'em". But you might want to be a little more caring than that ...

What you can do is add your new MX records and leave the old ones in place, with a lower priority. Then just monitor the traffic to the old MX systems, which should drop dramatically as the TTL expires -- then its up to you to decide at what point to pull the plug and remove the old MX records.

Re:Mostly OT: How long for MX record propagation?

[Anonymous Coward]

Thanks! I suspected there were nonconformist malcontents out there.

Re:Mostly OT: How long for MX record propagation?

[alienmole]

I saw an extreme example when I switched my MX record and months later received an email on my old mail server, which was still running but not pointed to by any public MX records. The email came from someone I knew at MetLife, and was sent via Lotus Notes. I kind of imagined Notes might be at fault, but I don't know what DNS servers MetLife uses.

Re:Mostly OT: How long for MX record propagation?

[Tony Hoyle]

I changed the IP address on a server and left the old one on for the changeover... checking the logs I found that people were still hitting the site *months* afterwards, usually the same ISPs. They might still be trying today.. the server is gone now.

It seems some ISPs not only ignore TTL, they aggressively cache so the first version of a domain they see is the one they always use, until someone complains.

Re:Mostly OT: How long for MX record propagation?

[tyldis]

The way I do it:
- Configure a temp mailserver that forwards your companies email to the current MX
- Change the MX records to point to this server
- As the TTL expires and changed propogate you start seeing hits on your server. It still just forwards it to the old MX..
- Verify the headers of the email you receive, you can see if it's delivered via your MX or not
- When it seems all mail comes through your temp MX you either reconfigure it the way you want it or drop in a new one with the desired config

Then you have double-buffered the whole process.

If you control the original MX you can do it the other way around and make it relay directy to your new MX.

Security is always a hard sell

[MrNougat]

... until someone takes advantage of an unsecured system. One of the pieces I heard on NPR about Sony/XCP talked about DoD and Sec of State computers having the XCP rootkit installed. If the DoD and Sec of State offices are allowing users to install software on the computers they use, how can anyone expect any company to take security seriously?

Re:Security is always a hard sell

[SpaceLifeForm]

Wrong question. The question should be:

Why are government agencies that have a responsibilty for security using non-secure Windows platforms?

Re:Security is always a hard sell

[MrNougat]

I don't think it has anything to do with what platform is being used at the desktop.

While a Windows computer and network can be secured, it's rare to find any businesses that actually do it. For the most part, users have elevated privileges that they do not need to do their jobs (read: local admin on the Windows desktop). This comes from lazy or stupid network admins, and those come in all flavors. It also comes from the user culture of "This is my computer, and I can do whatever I want with it," which is allowed by management to thrive.

I would expect that companies that migrate from Windows to [enter your favorite competing operating system here] will have the same problems with security, because the unwashed masses in the cubicles will be running with elevated privileges they don't need so that they can Install Free Games!!! -- just like they are now -- and this will (still) be allowed because someone whined to a middle manager about how the IT guy was being mean to them, and that got up to the execs, who passed down through some chain: "Let people do whatever they want."

If your business migrates to Linux, management will allow many users to run as root, and make you (the admin) let them, even though it is wrong wrong wrong, and even though you tell them a thousand times "no."

Ultimately, IT is not run by IT people, it's run (like everything else in a bureocracy) by executives. So if you wanna ask the right question, ask: "Why do executives, who have no tech experience or knowledge whatsoever, have control of technology? Why can't they hire (and pay appropriately) experienced people to make the right decisions?"

Even better - "Why is IT always the red-headed stepchild of the company, usually delegated to report to Accounting?"

Okay, that tangent/rant has gone far enough. All apologies.

A real shame too

[finkployd]

Everything people trust to be protected and identified by x509 server certs (https, pops, imaps, , etc) has a major weakness: DNS. You can have all the eliptical curve crypto, 4096bit RSA keys, and even someday quantum crypto you want, it all fails utterly if DNS is compromised or spoofed. It is really odd that so few people seem to care. It is kind of like putting a hundred dollar deadbolt on a screen door.

The only solution is either get secure DNS, or find a way to securly exchange keys out of band (rendering the point of x509 kind of moot)

Finkployd

Re:A real shame too

[pthisis]

Everything people trust to be protected and identified by x509 server certs (https, pops, imaps, , etc) has a major weakness: DNS. You can have all the eliptical curve crypto, 4096bit RSA keys, and even someday quantum crypto you want, it all fails utterly if DNS is compromised or spoofed

Please explain.

SSL is designed to ensure that DNS spoofing will cause SSL authentication failure. An attacker needs to hijack the domain name and get a matching (signed, trusted) certificate for that domain name in order to spoof a secure site. If they could get such a signed certificate, all kinds of passive man-in-the-middle attacks become viable (in other words, that's not a DNS problem, it's a far more severe problem in your key management).

Re:A real shame too

[finkployd]

But it ultimately pretty much comes down to DNS. If I can receive email from a domain, I can generally get a cert for that domain. Pehaps not from your better certificate authorities, but have you looked at the number of CAs in your browsers CA cache? Have you tried getting certs from them? Some are much easier than others, but ALL are trusted equally and completely.

As you say it is a problem of key management, but the way CAs do key management (distribution) today depends on DNS not being compromised.

All the browser does is make sure the strong cryptographically signed and verified cert's DN matches the totally insecure DNS lookup result. Does that not seem like a major lopsided security check? Which is easier and more damaging way to attack, the cryptographic hash and encryption methods, or hijacking a DNS server and returning false results. I submit the latter could yield much easier and damaging results on a larger scale. However until it happens, nobody is really going to think much about it.

Finkployd

Re:A real shame too

[infiniti99]

All the browser does is make sure the strong cryptographically signed and verified cert's DN matches the totally insecure DNS lookup result.

Incorrect. The browser checks the certificate domain against the intended domain. The result of a DNS lookup is not part of the trust equation. This is the great thing about end-to-end security, everything else in the path doesn't even matter.

I agree that the way domains and certificates are purchased is ridiculous. For God's sake why are we still proving email address and domain ownership via SMTP?!

Re:A real shame too

[finkployd]

My mistake, that is actually how I intended to word it, and point out that we are only comparing against the intended domain, not the actual IP address we are connecting to. The lack of secure DNS means we get no assurance that the intended domain name is actually getting to the IP it is supposed to.

Finkployd

Re:A real shame too

[Anonymous Coward]

If only SSL provided a method for mutual authentication -- I don't know, like a fingerprint or something -- so that you could verify that the remote system is using the (presumably controlled, otherwise you've got much bigger problems) private certificate that you expect. OH WAIT, IT ALREADY DOES, IT'S JUST THAT NO ONE CARES TO CHECK.

If people want security it's not hard to obtain, but there's no way to have "automatic" and "secure" go together, because "automatic" requires that you trust some outside source to do the verification step for you. Let's not pretend that f'ing with DNS will somehow make things more secure. If you wanted to complain that browsers don't maintain a list of acceptable fingerprints (ala SSH) you might have a point, but whining that SSL doesn't meet your needs because, um, you don't use the features that it has to meet your needs, is ridiculous.

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 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.

SPAM

[Anonymous Coward]

Is this going to help stop SPAM?

just kidding!

HAHAHA, the word I have to type to allow this message to be posted is "resolve" !!!!

Re:That's because...

[Hymer]

I usually tell those people to enter some garbage in there and check how well their Internet works... It works for 99% of the cases...

OT: e.root-servers.net

[Anonymous Coward]

Anyone know why I (and others) can't reach this "root" name server?

Seems relevant given the discussion.

Re:OT: e.root-servers.net

[Hymer]

This page shows that all root servers a up...

Re:OT: e.root-servers.net

[Anonymous Coward]

It may be up, but it's definitly unroutable by some folks.

Try using some of the remote ping/traceroute utilities that are available on the web and you'll see what I mean:

PING 192.203.230.10 (192.203.230.10) from 66.23.192.50 : 56(84) bytes of data.
--- 192.203.230.10 ping statistics ---
10 packets transmitted, 0 received, 100% loss, time 9012ms

from 208.214.184.130
Pinging 192.203.230.10 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.203.230.10:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Oh, and if your wondering you can't traceroute it either (drops before it gets there).

I saw this today because I can't get to a web site, and in tracing it down found that I can't reach a root server (e in this case, the others ping and tracert fine).

I just found it interesting, it may be nothing, but *is* related to DNS :)

It's a hard sell because it's not secure

[mrsbrisby]

Another word for "security early adopter" is fool.

DNSSEC is not secure because it doesn't address the fundimental issues with security and nameservers.

* It doesn't stop cache poisoning attacks- a client resquesting a name from a poisoned cache won't get the key so they won't know anything is wrong.

* Breaking the nameserver itself gives you the keys as the nameserver is required to sign the resource records, so in this case, it gives people a false sense of security that they don't have!

* Finally, as it stands, DNSSEC perscribes to give a particular company power that hasn't demonstrated that they're trustworthy enough to hold it. You can't get a DNSSEC certificate right now unless you make your own, and even one day, if someone will sign DNSSEC certificates (like Verisign), whos to say someone won't get them to sign a bogus certificate (HINT: Verisign was already convinced to sign a code-signing certificate for someone claiming to be Microsoft Corp- are we supposed to trust these people?)

A better option would be to record a new RR type, like "VER" which acts as a verifier for (all) other data- the result contains an indexed hash of every response the server can give and the whole shebang is signed by a key that's signed by the immediate parent of the zone. Timelimit it and you're CURRENTLY safer than anything DNSSEC offers. VER would not be generated by the DNS server itself, but would have to be updated periodically all the same. It would also be big, which would mean likely TCP connections...

A better option would be to continue using in-transport mechanisms like S/MIME, PGP, SSL, or SSH that are ALREADY DEPLOYED.

A better option would be to do away with all that is DNS and make something good.

But nowhere is it even an option to deploy something that doesn't do anything but MAYBE produce a false sense of security.

Re:It's a hard sell because it's not secure

[hardaker]

DNSSEC is not secure because it doesn't address the fundimental issues with security and nameservers.

I'm not sure you've read the specs...

It doesn't stop cache poisoning attacks- a client resquesting a name from a poisoned cache won't get the key so they won't know anything is wrong.

Like all security, you need a trust-anchor root. This is the same way that your browser has a list of trusted root CA certificates. DNSsec requires something similar: a list of keys for roots that you trust. It a can securely navigate below that point, but you do need to track the changes to at least these "anchors".

Breaking the nameserver itself gives you the keys as the nameserver is required to sign the resource records, so in this case, it gives people a false sense of security that they don't have!

DNSsec is designed so that you can do offline signing of data. thus you don't need to keep the keys on the nameserver serving your data. If it's broken, and people have you or something above you as a trust anchor there is no way the attacker can publish new data that will be trusted (though they can still obviously do DoS on the data by stopping it from being served).

Finally, as it stands, DNSSEC perscribes to give a particular company power that hasn't demonstrated that they're trustworthy enough to hold it.

Hopefully you'll have a choice in who signs it. The problem will come when you don't want to use verisign but you do want a .com address. You'd have to settle for a non-verisign opperated TLD

I couldn't understand your VER proposal at all based on the wording, so I won't respond to it.

Re:It's a hard sell because it's not secure

[mrsbrisby]

I'm not sure you've read the specs...

What gives you that idea?

Like all security, you need a trust-anchor root.

Wrong. You need what RFC 4033 calls a "trust anchor" if you want to prove identity (that the resource is what it claims to be), not if you want to prove authority (that the resource is being generated by the correct host) or integrity (that the resource data hasn't been altered). Go read ISBN 0471117099 for practical algorithms if you like.

Meanwhile, existing attacks on DNS have involved subverting authority (by transferring names between nameservers without permission) and integrity (through cache poisoning) and not on identity (which DNSSEC spends considerable complexity on).

DNSsec is designed so that you can do offline signing of data.

Wrong. Check RFC 4033 sec 3.1: It breaks Dynamic DNS if you sign your data offline.

I couldn't understand your VER proposal at all

There's a lot you couldn't understand. Asking questions can often help solve that problem.

Re:It's a hard sell because it's not secure

[hardaker]

You need what RFC 4033 calls a "trust anchor" if you want to prove identity (that the resource is what it claims to be)

true

not if you want to prove authority (that the resource is being generated by the correct host)

The resource can't be signed by an incorrect host (holder of a key; not a host) unless the key has been stolen or broken. Obviously, if you don't have a trust anchor then an attacker can generate any key it wants if you'll believe it. With a trust anchor, however, you won't believe it.

or integrity (that the resource data hasn't been altered).

If altered the signatures won't validate and/or won't have a secure path from the trust anchors and integrity will fail. Again, without trust anchors an attacker can generate their own key and hopefully get you to use them (there isn't a secure protocol yet that has not resulted at some point to an out-of-band initial distribution in some way of root keys.

Meanwhile, existing attacks on DNS have involved subverting authority (by transferring names between nameservers without permission) and integrity (through cache poisoning)

Which don't work with DNSsec enabled and (big and) trust anchors in place and high up. Human attacks still work just fine though (such as talking a parent into signing a key for a zone that a human didn't have rights over).

Check RFC 4033 sec 3.1: It breaks Dynamic DNS if you sign your data offline.

Agreed. I should have mentioned it before, you're right. The practical solution that I've used in practice (and seen others use) is to put dynamic entries in their own zone which at least separates them out into records that require live keys.

I'll refrain from responding to the other trolling statements

Deployment in Sweden

[nealmcb]

A lot is happening with DNSSEC these days. It is being deployed in the ccTLD for Sweden: ".se" Check out

http://dnssec.nic.se/

Tutorial/howto: http://www.ripe.net/disi/dnssec_howto/

$ dig @bind.dnssec.se www.ripe.net +retry=1 +dnssec +multiline
and look for the "flags" to include "ad": ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

http://www.dnssec-deployment.org/
  Threat Analysis Of The Domain Name System
    IETF RFC 3833 http://www.rfc-archive.org/getrfc.php?rfc=3833

Cache poisoning, in the wild:
      http://isc.sans.org/presentations/dnspoisoning.php
      http://www.dnssec-deployment.org/epi.htm

http://www.dnssec.net/

Re:Deployment in Sweden

[hardaker]

There is also the requisite sourceforge project with additional helpful tools: www.dnssec-tools.org

Re:Deployment in Sweden

[Anonymous Coward]

"A lot is happening with DNSSEC these days"

Someone (and I don't mean Veris..., of course) might be pumping it. After all it is not as if "some" companies (and I don't mean Veris... really) were going to bill you extra$$ for the superduper new ultrasecure domains...

Insurances too

[Nikademus]

Insurances are also something you pay for hoping that you won't use it like IT security. But they are considerably easier to market, probably because you are speaking about tangible goods.

Helps in securing mail (DKIM) and other protocols

[nealmcb]

SSL is helpful for some protocols, but not others. PKI via X.509 is also hard to deploy, and more complicated, and requires distribution of root certs in clients. And the user interface issues
with SSL in todays browsers is a whole 'nother topic....

DNSSEC helps secure all DNS-based protocols, even those that couldn't adopt SSL/TLS.
DKIM (DomainKeys Identified Mail) is the lastest case in point, and if adopted will help drive DNSSEC deployment since it relies on DNS to help stop spam etc.

  http://dkim.org/

BIND "okay"?

[Grendel Drago]

However, I think BIND works okay, and I am perfectly happy with my DNS the way it is.

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

Re:BIND "okay"?

[cortana]

Bind 9 is fine.

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 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.

Re:BIND "okay"?

[Anonymous Coward]

not to address all your points - but lol how your "employer" trashes the performance of BIND 9 (which they, themselves wrote) and then on top of it go on to explain how their high performance commercial version is written as separate auth and cacheing servers like BIND 4 - 9? No, like the guy they have been trashing for doing so all these years.

Your company has no credibility - they'd gain some of they said - "We wrote BIND 9 under contract to ISC Corp and it was crap, so we wrote something a little better that you can pay through the nose for. But in the end its not any better than djbdns or nsd http://www.nlnetlabs.nl/nsd/ " Your "employer's" software is bested by one grouchy guy's 5+ year old software and by a group of 5 Northern European Bongheads on a 500K EUR budget - its a joke, how much did you guys get for writing BIND 9, how many millions ?

As for a few of the other things - how about the cult of the term "reference implementation" the Brad Knowles is on ? Now that ISC has sucked up ntp, notice how he has started bad-mouthing OpenNTPd and using the term "reference implementation" with ntp software, too - the guy has a problem.http://66.102.7.104/search?q=cache:2CD_GXH _YAoJ:bradknowles.typepad.com/considered_harmful/2 004/09/openntpd.html+reference+implementation+open ntp "reference implementation" doesn't mean jack, esp. when it sucks. And yeah the BIND zone transfer is _so_ much better than rsync/scp. And please don't compare the number of patches in BINDs history to djbdns - yeah he doesn't incorporate the few that there are out there but boohoo, I have an automated build for djbdns and there are lots of pre-patched bundles available on the net.

Re:BIND "okay"?

[mellon]

Bind 9 isn't crap, so there would be no reason for us to say it was. It's a fine product. Its target market is different than ours, that's all.

Boo-hoo all you want about automated builds and patch distributions. I'm a big fan of keeping things simple. With BIND, I just install the .deb and I'm done. It takes about ten seconds, and it's exactly the same process as the other hundred or so packages I need on my server. A package that requires a special compile and a manual install had better be *hugely* better than any competitor.

Spoofed DNS servers

[jd]

These are a serious problem. It would be relatively trivial for someone to poison DNS by spoofing a server that is pointed to by other DNS servers. The poison will then run downstream, affecting all servers that (ultimately) derive information from what should have been the master server. Because many corporations use SSL only after a person has entered login data, it would be possible for someone to use this to masquerade as a legit bank, with the bank's actual human-readable name but pointed to their own server. A really clever scammer could then pass that info on and relay the results, so that users would be utterly unaware anything had happened at all. (The latter case is sometimes called a man-in-the-middle attack.) Poisoning the public DNS tree to re-direct Windows update traffic could be used to spread viruses and trojans the same way.

Spoofed DNS can also be used to cause havoc in other ways. Because DNS records are generally cached for a long time, it would be possible for someone to poison DNS by having DNS records point to random machines. Because of the latency in DNS, once such poison starts spreading, it could take days to clear the system.

Finally, with service discovery, users would not be given the IP address of their DNS server - they would send a service discovery request and they would get the IP of the nearest machine providing such a service. On something like a cable network, where there could be literally thousands of machines closer to your machine than the "official" DNS server, you absolutely do NOT want your machine to auto-discover some private DNS server (shared by accident or design). You want the DNS server you expect.

Secure DNS would prevent these problems, as only a trusted DNS server would be used - by an existing DNS server or by a user's machine that is autoconfiguring. The parent post is absolutely correct, though, in arguing that nobody is going to use DNSSec unless it is enforced - the same way they won't (not can't, won't) use IPSec, and why raw telnet is still used for public network logins in preference to SSH or even Kerberos-enabled telnet. Inertia is good, when you want a stable environment, but it is BAD when you discover major security holes in that same environment.

The other problem is that there is a conflict of interest. The US Government controls ICANN, and the US Government's spy agencies and law enforcement divisions don't want a network they can't spoof on or hack, for intelligence-gathering reasons. The moment you secure the Internet against the exploits used by sniffers and spoofers, you secure the Internet against the exploits used by Government wiretappers. Now, arguably, this is no bad thing - only, the ones in charge happen to think otherwise and by being in charge, they get to make the rules.

(This is one reason I want control of critical services to be taken out of the hands of ANY organization that may have a vested interest in the Internet being broken. I don't so much care how this happens, only that it does. Governments should indeed have an interest in law enforcement and public safety - that is a key function of theirs - but it is precisely for this reason that they should have NO control over critical infrastructure. The separation of powers, to prevent abuse, has been understood as far back as human tradition goes. If done right, it does not harm legitimate needs, but prevents - or, at least, reduces - illegitimate wants.)

Personally, I would favour someone very high up the heirarchy mandating DNSSec, IPSec and IPv6. The combination of all three would eliminate many vulnerabilities that currently exist on the Internet. It might even help IPS', as there would be the potential to make a LOT of money from such a migration. Mom-and-pop shops could benefit too, as they'd be far more able to make the change - and smoothly - than many of the bigger names, making them much more attractive to customers.

Why??

[jskline]

Why on earth would you expect them to embrace it?? There is NO cost incentive to go to this. Apparently something catastrophic has not yet happened to emtpy the coffers and there-by motivate them...

Uhh, give me a break

[shrtcircuit]

Yeah I guess you could check your bank's cert every time you visit the site, but get real - even hardcore techies don't bother with that unless something just seems wrong. The average user doesn't even know what an SSL certificate is, let alone how to check it or why they should. All they know is the website has a picture on it saying "This Site Secured by [insert favorite CA here]" and they believe it.

I dare say most would click 'OK' on any cert warning, and if you can manage to bypass that somehow the user will be *completely* blind to what is going on, happily giving up their information. You don't even have to give them anything back, just spit out a "We're sorry, this site is experiencing technical difficulties right now, try back later" page and call it a day while you silently gather whatever information you want.

mod parent funny

[Anonymous Coward]

I know it's a reply to a fp troll, but this one truly got me laughing.

Fix all the links in the chain

[agriope]

Paradigm shift is hard, I understand. However, it always amazes me how so many smart people are eager to continue spending money / making money on technologies they know are broken; and are slack-jawed shocked when the inevitable catastrophe happens. All their analogies, intentions and excuses lay shattered on the floor then.
If you know that something is less than perfect (i.e. it's broken such as DNS, Email, etc.), set about fixing it. Sure, the money matters, the resources matter. But it's not an argument about "Shall we implement?", it's an argument about "When will we have this finished?"