Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Secure DNS a Hard Sell

ScuttleMonkey posted more than 8 years ago | from the underdeveloped-ideas dept.

Security 142

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

cancel ×

142 comments

Sorry! There are no comments related to the filter you selected.

lol (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14204330)

lol no this is not a first post!

Re:lol (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14204815)

U SUCCEED IT. uh, i mean, U FAIL IT, uh, wait a sec..

Nice, but not necessary (4, Interesting)

ehaggis (879721) | more than 8 years ago | (#14204347)

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.

Nice, but not necessary-A royal pane. (0)

Anonymous Coward | more than 8 years ago | (#14204412)

"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. (1)

Donald Ferrone (863523) | more than 8 years ago | (#14204491)

BRILLIANT! SUPERB! What a well thought-out and insightful comment! Shoot yourself in the head you OSS-worshipping queer. Get a girl, maybe some ACNE medication, and oh yeah, a fuckin' life. Loser.

Re:Nice, but not necessary-A royal pane. (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14204610)

Donald Ferrone, Ph.D Professor of computer science http://www.geocities.com/donald_ferrone/ [geocities.com]

Proving yet again that ANYONE can get a PhD. I'd rather chase an industry cert like CCIE than go for the kind of credential which includes you. personal attacks aside - if you really teach CompSci then you should be ashamed of that website. There are no words strong enough for me to convey how lame it is.

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

Anonymous Coward | more than 8 years ago | (#14205154)

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. (0)

Anonymous Coward | more than 8 years ago | (#14205517)

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

Re:Nice, but not necessary-A royal pane. (2, Funny)

stefanlasiewski (63134) | more than 8 years ago | (#14204505)

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

Re:Nice, but not necessary (5, Informative)

razvedchik (107358) | more than 8 years ago | (#14204437)

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 (3, Informative)

timeOday (582209) | more than 8 years ago | (#14204510)

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 (2, Interesting)

mellon (7048) | more than 8 years ago | (#14204730)

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:/// [https] strings substituted for http:/// [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 (1)

razvedchik (107358) | more than 8 years ago | (#14204807)

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 (1)

SatanicPuppy (611928) | more than 8 years ago | (#14204536)

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 (1)

Professor_UNIX (867045) | more than 8 years ago | (#14204629)

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 (1)

cat6509 (887285) | more than 8 years ago | (#14204757)

"...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 (1)

hackstraw (262471) | more than 8 years ago | (#14204864)

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 (1)

nihaopaul (782885) | more than 8 years ago | (#14205464)

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 (1)

hal9000(jr) (316943) | more than 8 years ago | (#14204438)

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 (1)

Gud (78635) | more than 8 years ago | (#14205541)

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.

Also (0)

Anonymous Coward | more than 8 years ago | (#14204471)

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

Re:Nice, but not necessary (1)

Cruithne (658153) | more than 8 years ago | (#14204498)

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

Hard to understand (4, Insightful)

Mr. Flibble (12943) | more than 8 years ago | (#14204398)

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 (1)

LilGuy (150110) | more than 8 years ago | (#14204912)

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

Re:Hard to understand (1)

TerminalInsanity (720167) | more than 8 years ago | (#14205672)

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.

That's because... (-1, Offtopic)

LABarr (14341) | more than 8 years ago | (#14204402)

For most people DNS stands for Do Nothing Shit!

Re:That's because... (0, Offtopic)

Hymer (856453) | more than 8 years ago | (#14205045)

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

bigger fear (5, Interesting)

keithhackworth (902524) | more than 8 years ago | (#14204407)

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 (4, Interesting)

Dolda2000 (759023) | more than 8 years ago | (#14204464)

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 (4, Informative)

hal9000(jr) (316943) | more than 8 years ago | (#14204533)

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 (1)

Dolda2000 (759023) | more than 8 years ago | (#14204562)

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 (2, Interesting)

baadger (764884) | more than 8 years ago | (#14204615)

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 (2)

hal9000(jr) (316943) | more than 8 years ago | (#14204849)

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 (4, Insightful)

Agelmar (205181) | more than 8 years ago | (#14205138)

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 (1)

ehrichweiss (706417) | more than 8 years ago | (#14205177)

" 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 (1)

Ucklak (755284) | more than 8 years ago | (#14204590)

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 (1)

Dolda2000 (759023) | more than 8 years ago | (#14204672)

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 (1)

rbannon (512814) | more than 8 years ago | (#14204486)

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 [freepay.com] ?

Re:bigger fear (2, Interesting)

iambarry (134796) | more than 8 years ago | (#14204499)

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 (1)

iambarry (134796) | more than 8 years ago | (#14204527)

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

Re:bigger fear (1)

morgan_greywolf (835522) | more than 8 years ago | (#14205116)

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 (1)

utlemming (654269) | more than 8 years ago | (#14205427)

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.

Same as Sony (5, Insightful)

Nom du Keyboard (633989) | more than 8 years ago | (#14204457)

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 (1)

ImaLamer (260199) | more than 8 years ago | (#14205560)

the absence of widespread attacks

It's true, nothing gets the ol' blood pumping for action [wikipedia.org] than a good Reichstag fire [wikipedia.org] !

secure domains (3, Funny)

digitaldc (879047) | more than 8 years ago | (#14204477)

"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. (2, Informative)

Crispix (864691) | more than 8 years ago | (#14204481)

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. (1)

ehrichweiss (706417) | more than 8 years ago | (#14205235)

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? (3, Insightful)

26199 (577806) | more than 8 years ago | (#14204483)

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?)

DNS, Phishing, and secure DNS (1)

queenb**ch (446380) | more than 8 years ago | (#14204581)

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

   

A Modest Proposal (3, Insightful)

Nom du Keyboard (633989) | more than 8 years ago | (#14204485)

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 (0, Offtopic)

g0at (135364) | more than 8 years ago | (#14204577)

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 (2, Insightful)

schon (31600) | more than 8 years ago | (#14204906)

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.

Perhaps better marketing? (3, Interesting)

Halo- (175936) | more than 8 years ago | (#14204493)

I know this is a rather stupid thing to be hung up on, but the referenced link (DNSsec.org [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? (1)

Eric Giguere (42863) | more than 8 years ago | (#14204601)

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 [ietf.org] if that helps.

Eric
Read my Invisible Fence Guide [ericgiguere.com]

Insurances too (1)

Nikademus (631739) | more than 8 years ago | (#14205561)

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.

Re:Perhaps better marketing? (1)

hey (83763) | more than 8 years ago | (#14205642)

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 (1)

SpinJaunt (847897) | more than 8 years ago | (#14204506)

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 (1)

Tony Hoyle (11698) | more than 8 years ago | (#14204673)

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 (5, Interesting)

arakis (315989) | more than 8 years ago | (#14204507)

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

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

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

Re:dnssec and nym ala dan (1, Insightful)

Anonymous Coward | more than 8 years ago | (#14204643)

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

Re:dnssec and nym ala dan (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14204872)

You're a fucking retard. Get a clue.

Re:dnssec and nym ala dan (2, Interesting)

mellon (7048) | more than 8 years ago | (#14204825)

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 (1)

drewzhrodague (606182) | more than 8 years ago | (#14204996)

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 (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14205301)

Boys and girls, this species is called "retardus maximus". Generally, we keep them in Windows server rooms where they can't do much damage. Unfortunately, this one has escaped into UNIX-land...

BIND "okay"? (1)

Grendel Drago (41496) | more than 8 years ago | (#14205654)

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 [google.com] . This by you is "okay"?

Re:BIND "okay"? (1)

cortana (588495) | more than 8 years ago | (#14205696)

Bind 9 is fine.

Money talks (3, Insightful)

Billosaur (927319) | more than 8 years ago | (#14204514)

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 (1)

mellon (7048) | more than 8 years ago | (#14204761)

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 (1)

Billosaur (927319) | more than 8 years ago | (#14204907)

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 (3, Insightful)

CyberVenom (697959) | more than 8 years ago | (#14204540)

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 (0)

Anonymous Coward | more than 8 years ago | (#14204802)

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 (2, Interesting)

Florian Weimer (88405) | more than 8 years ago | (#14204823)

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

Helps in securing mail (DKIM) and other protocols (1)

nealmcb (125634) | more than 8 years ago | (#14205609)

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/ [dkim.org]

DNS Poisoning (0)

Anonymous Coward | more than 8 years ago | (#14204572)

There used to be a technique called DNS cache poisoning. http://en.wikipedia.org/wiki/DNS_cache_poisoning [wikipedia.org]
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.

Resistance from the DNS registries (0)

Anonymous Coward | more than 8 years ago | (#14204642)

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

dear somebody skilled. (3, Funny)

blackomegax (807080) | more than 8 years ago | (#14204655)

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. (1)

Al Dimond (792444) | more than 8 years ago | (#14205630)

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. (3, Insightful)

mellon (7048) | more than 8 years ago | (#14204666)

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. (1)

pawal (6862) | more than 8 years ago | (#14205194)

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. [dnssec.nic.se]

Re:You can't get it. (1)

mellon (7048) | more than 8 years ago | (#14205294)

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. (1)

BVis (267028) | more than 8 years ago | (#14205414)

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)

Mostly OT: How long for MX record propagation? (0)

Anonymous Coward | more than 8 years ago | (#14204696)

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? (1)

PhilipPeake (711883) | more than 8 years ago | (#14204869)

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? (0)

Anonymous Coward | more than 8 years ago | (#14204914)

Thanks! I suspected there were nonconformist malcontents out there.

Re:Mostly OT: How long for MX record propagation? (1)

alienmole (15522) | more than 8 years ago | (#14204964)

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? (1)

Tony Hoyle (11698) | more than 8 years ago | (#14205202)

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? (1)

tyldis (712367) | more than 8 years ago | (#14205346)

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 (1)

MrNougat (927651) | more than 8 years ago | (#14204789)

... 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 (1)

SpaceLifeForm (228190) | more than 8 years ago | (#14205697)

Wrong question. The question should be:

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

A real shame too (3, Insightful)

finkployd (12902) | more than 8 years ago | (#14204812)

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 (1)

pthisis (27352) | more than 8 years ago | (#14205302)

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 (1)

finkployd (12902) | more than 8 years ago | (#14205565)

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

Reason for not rushing adoption (2, Informative)

kts.nm (936984) | more than 8 years ago | (#14204822)

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... (4, Informative)

hkhito (901607) | more than 8 years ago | (#14204833)

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

SPAM (0)

Anonymous Coward | more than 8 years ago | (#14204851)

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

OT: e.root-servers.net (0)

Anonymous Coward | more than 8 years ago | (#14205215)

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

Seems relevant given the discussion.

Re:OT: e.root-servers.net (1)

Hymer (856453) | more than 8 years ago | (#14205388)

This page [cymru.com] shows that all root servers a up...

It's a hard sell because it's not secure (1)

mrsbrisby (60242) | more than 8 years ago | (#14205404)

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 (1)

hardaker (32597) | more than 8 years ago | (#14205734)

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.

Deployment in Sweden (1)

nealmcb (125634) | more than 8 years ago | (#14205478)

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

http://dnssec.nic.se/ [dnssec.nic.se]

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

$ 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/ [dnssec-deployment.org]
  Threat Analysis Of The Domain Name System
    IETF RFC 3833 http://www.rfc-archive.org/getrfc.php?rfc=3833 [rfc-archive.org]

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

http://www.dnssec.net/ [dnssec.net]
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?