DNSSEC: Good Enough?

Phil Windley writes "DNS Security Extension, or DNSSEC, is a set of extensions to DNS, which provide end-to-end authenticity and integrity. Paul Mockapetris, the inventor of DNS believes DNSSEC is the answer to many of the identity problems on the Internet. He wants the IETF to get off the dime and approve the DNSSEC spec. A recent article in ZDNet TechUpdate interviews Mockapertis on DNSSEC (summary)."

Comments

Check out Internet Mail 2000

[Bryan Ischo]

D. J. Bernstein, the author of the supremely reliable and secure qmail mail server, wrote a proposal for a new Internet mail system a couple of years ago. It's called Internet Mail 2000. Check it out at:

http://cr.yp.to/im2000.html

The basic premise is this:

"IM2000 is a project to design a new Internet mail infrastructure around the following concept: Mail storage is the sender's responsibility."

It's an interesting concept and worth a read.

Unfortunately it doesn't look like it would do much to stop spamming, which is the major problem with the current internet mail infrastructure. For that, we need some way to make sending bulk email costly to spammers. Actually I'd say that this could be done already with current technologies, it's just that ISPs and large network providers are not being responsible in ensuring that the users of their networks pay the appropriate price for sending out SPAM.

Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email ...

Re:Check out Internet Mail 2000

[letxa2000]

Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email ...

I wish people would stop inviting rate increases or new charges as an answer to spam. It's not the answer. It might be inexpensive for you, but many of us DO send a lot of email and it'd get expensive really quick. You'd get rid of a lot of good and valid email communication along with the spam.

I'm even opposed to the "pay a dime, but I'll give it back if I wanted to hear from you" approach. Those of us running a mailing list would run the risk of having some idiot sign-up a bunch of accounts only to have that person say "No, I didn't want that" and collect the money.

I believe we need a trusted protocol. This might be as simple as having all emails PGP signed and everything else being sent to the bit-bucket (if you want to be aggressive) or only passed through to the user if the unsigned message had an extremely low spam score.

But if everyone were to use Bayesian I swear we wouldn't even have to propose a new protocol, talk about new legislation, etc.

*SIGH*

New Protocol Name

[liam193]

This sounds like a great idea. Let's present a new protocol. I suggest we name it Slashdot Mail Transfer Protocol. We could use the shortened form SMTP. hmmm well... on second thought maybe the name needs more work.

Costs

[$exyNerdie]

A lot of research and ideas and papers have been thrown around to replace SMTP with a better protocol but the costs involved are a major discouraging factor and people don't want to install a system when there is no guarantee that all the recipients have it too.

Maybe servers using a new mail protocol should be designed such that they first attempt to use the new protocol and if connect fails, try the good old SMTP

slashdot

[Anonymous Coward]

is it possible for the Slashdot collective to come up with another one?

Not a chance. The slashdot collective taken as a whole, is a very stupid group of people. Even the few intelligent people wouldn't be able to get anything useful done because they'd be shouted down by the teaming masses of idiots.

We hate Sony's recording arm, but we'll sell our souls to them for the next cool gadget. We hate MS, but 90% of us use windows on our main home machine. No to mention all the idiots who use words like boxen.

well... ok...

[Ninja Master Gara]

As long as SMTP continues to the be the friendly protocol.

HELO imamailserver.com
250 Hello imamailserver.com [127.0.0.1] nice to meet you!

A simple as hell answer.

[Anonymous Coward]

Do not send the message along with the envelope. Mail servers should only collect message envelopes, which contain information to obtain the real message. Then when someone reads their email their email program contacts the server to obtain the message. Thus you can't send email and vanish, since if you're not there when someone checks their email, they won't get your message.

Obviously ISPs will have to have the ability to store the messages of their users so they can deliver them while the user is offline, but that's no problem. If a user, or someone else, sends spam, once the ISP is notified, they can remove it from their servers, so that no further people who were sent the spam will actually recieve it upon reading their email.

Why I'm writing this I don't know. No one reads below score 3 anyway unless you're lucky and get one of the first 10 replies. Slashdot is useless. I'd shit myself if one person actually read this post. Hell, I can't even find posts after I make them, even after waiting several hours.

dan bernstein's position on this

[tmu]

People interested in this issue should see dan bernstein's position on the issue of DNSSEC.

The summary: It's unfinished, the BIND company has poor implementations (like most everything else it implements), and won't provide a real increase in security. Interesting stuff.

Re:dan bernstein's position on this

[macshit]

djb's points about dnssec seem reasonable, but his proposed solution `nym' seems quite nutty.

He basically proposes only allowing a form of hostname which is (1) too long to type manually, and (2) includes long random-looking strings. His justification for this is `users seem to do alright with bookmarks, and as soon as everything is links, no problem!'

Is he living on the same earth we do? It's going to be a long time before manually enterable -- and verifiable -- hostnames become redundant (if they ever do).

Re:dan bernstein's position on this

[Anonymous Coward]

Yes, DNSSEC is unfinished. The IETF has become worse than ISO.

DNSSEC would provide an increase in security if DNS spoofing attacks become more prevalent. Given tools now available (dnspoof, for one), such attacks are likely to increase in the future.

Bernstein takes a simplistic and operationally insane approach in his proposal. Also, it won't work as he describes it.

Of course, bernstein-ites will now froth at the mouth. So it goes.

Re:dan bernstein's position on this

[bradipo]

I don't think he is so far out there. How many of you use google to lookup resources these days? I find it much more convenient to look through a website using google to search on specific terms. Your answer shows lack of insight into the situation.

Re:dan bernstein's position on this

[plague3106]

Yes, but if i need to go to a website i know, i usually just type it. I don't bookmark things that often, b/c i don't usually forget the important ones. I bookmark sites i'm likely to forget about.

Re:dan bernstein's position on this

[jazir1979]

Hear, hear.

Re:dan bernstein's position on this

[Bob The Lizard]

I agree.
ctrl-t, alt-l, http://slashdot.org is a lot easier than, alt-b, arrow-key-around, look at screen, enter, or worse use the mouse.

Using bookmarks for sites you use regulary is slow.

G/

Re:dan bernstein's position on this

[gregmac]

djb's points about dnssec seem reasonable, but his proposed solution `nym' seems quite nutty.

in my experience, djb's stuff has always been interesting. He has good ideas about things, and they work nicely, but his implementations are just wacky. Don't get me wrong, I use a lot of it (qmail and daemontools, namely), but the way it fits together, and the way he does things.. it's out there. qmail in particular.. there's like 30 programs messages run through on their way.

Although I use daemontools, in order to change pathnames (since I wanted to put it in it's own path), I had to manually change a whole bunch of things hardcoded in the source. His build system is also very cooky.. it works, it's just totally different from the way you compile anything else and thus takes a lot of learning to figure it out.

I've never tried his DNS implementation, but I've heard it works nicely.

Re:dan bernstein's position on this

[Angst Badger]

Is he living on the same earth we do? It's going to be a long time before manually enterable -- and verifiable -- hostnames become redundant (if they ever do).

Ever watch end users? I mean, really watch end users? They almost never type in domain names. If it isn't a link or a bookmark, it seldom gets visited. Some of the brighter ones will go to Google and type a domain name into the search box (which exasperates me to no end -- "Location bar? What's that?"), but that's it.

The only time most end users type a domain name is as part of an email address. And I think we can all agree that the existing email infrastructure is in desperate need of a complete overhaul. (We can all probably agree that's as likely as "non-partisan" hearings in Congress, too.)

Not that Bernstein's proposed solution is all that great, but it's not as far-fetched as it seems at first blush.

Re:dan bernstein's position on this

[Alan]

Actually based on my SO it's google and auto-form fill fields. She will go to google (via the home button in IE), type in the start of something, even a domain name, select it when the IE "remember what I typed in" dropdown drops down, then clicks from there.

-1 boring and unrelated.

Re:dan bernstein's position on this

[bratgrrl]

Oh for shitsakes, DNSSEC is rearing its head AGAIN? Talk about vaporware- DNSSEC is the ultimate. Anyway, anything that involves VeriSign will suck so bad even people who don't use computers will curse it. It doesn't take much imagination to envision the nightmare of bureaucracy a centrally-managed DNS authentication system will create. Who authenticates the users in the first place, at registration? Who makes VeriSign do the job competently and honestly? (OK, sorry, I know it's completely ridiculous.)

The best first step to securing DNS is to eliminate all traces of BIND. Start with something that is fast, secure, and works right- like djbdns. Start with something that is not a bloated, buggy, insecure mess. Then look at how to authenticate DNS. Start with garbage, you still get garbage.

Re:dan bernstein's position on this

[macshit]

Um, I hate to break it to you, but we -- you and me -- are end-users. I'm certainly not going to accept a `standard' that works only for the mouth-breathing (and windows-using) set.

Re:dan bernstein's position on this

[Anonymous Coward]

Using bookmarks for sites you use regulary is slow.

Traditional bookmarks may be slow since you're navigating a menu. But if you put the really important sites on your toolbar it's just one click.

Re:dan bernstein's position on this

[Bob The Lizard]

Fair point!

Re:dan bernstein's position on this

[ZoneGray]

>> Is he living on the same earth we do?

Notwithstanding the overwhelming indications to the contary, yes.

Re:dan bernstein's position on this

[colinleroy]

He basically proposes only allowing a form of hostname which is (1) too long to type manually, and (2) includes long random-looking strings. His justification for this is `users seem to do alright with bookmarks, and as soon as everything is links, no problem!'
As if DNS was only used to browse the web. What about ssh, ftp, mail, all these things that use hand-typed hostnames ?

Re:dan bernstein's position on this

[the_olo]

How many of you use google to lookup resources these days? I find it much more convenient to look through a website using google to search on specific terms. Your answer shows lack of insight into the situation.

Then why use DNS at all? It's a service which has only one aim: to substitute IP addresses hard to remember by humans with something more memorizable (Well, you can say "Round-robin DNS records for providing clusters", but there are better ways for providing redundance).

DJB's proposed solution is worse than getting rid of DNS and using v4 or even v6 IP's in yperlinks and bookmarks.

Surely http://66.35.250.150 is better than, say, http://weoir123623tt23u4tgd2uwmnfskmhrlwhrjkqshfwh riwwyhwpurhuihrkjwehwhfh237wuhr4r272.slashdot.org?

The fact is, when I want to go to slashdot.org, openoffice.org or mozilla.org I type them into location bar (and the browser usually autocompletes them from history if I were working on that machine before).

Re:dan bernstein's position on this

[warrax_666]

No. You are ignoring the fact that one can (now, and presumably in DJB's scheme) change the IP address of the server WITHOUT everyone having to update their bookmarks.

Re:dan bernstein's position on this

[ansible]

I've never tried his DNS implementation, but I've heard it works nicely.

It does work nicely. Been using it for about 3 years now. No problems at all. After you get used to the DJB way of doing things, it is very simple to configure. The main data file makes more sense to me than BIND's stuff ever did.

But DJB is out there. One of these days, in my copious free time, I'll have to re-implement some of his better ideas, so that they can be released under a normal F/OSS license.

But I'm not using Qmail any more. Hasn't been updated in years, and to get needed features, it is patch hell. Switched to Courier MTA because I needed mail filtering, webmail and IMAP. I still like Maildirs though. Never had a problem with mailbox corruption or lost messages since we switched to that.

Re:dan bernstein's position on this

[mwood]

"Ever watch end users?"

Well, *I* am an end user (in addition to sysadmin, programmer, etc.) and *I* type in domain names all the time. Where exactly does ssh keep bookmarks, for example?

As for people who think web==internet, who cares about them? The tools *I* use will be crocked, and the way *I* use them will be made pointlessly hideous. We'll wind up inventing another DNS layer on top of the mess just to get back sensible names.

Re:dan bernstein's position on this

[poot_rootbeer]

It's going to be a long time before manually enterable -- and verifiable -- hostnames become redundant (if they ever do).

Not if they step up the production and distribution of CueCat wands! Man, those things are great!

Re:dan bernstein's position on this

[headcharge]

...proposed solution `nym' seems quite nutty.... He basically proposes only allowing a form of hostname which is (1) too long to type manually, and (2) includes long random-looking strings.

So, your issue with nym is not that it doesn't offer a simple and effective layer of security, but that it threatens the convenience and useability you and others have become accustomed to. Is that accurate?

Is it news to you? Security and convenience/useability are almost always tradeoffs. Because you and many others (myself included) don't immediately see a way to do your job, hop around on the Internet, or what have you, with comparable convenience to the ways you perform these tasks now, you discredit nym as 'nutty' or 'wacky'? Why is it impossible, or outlandish, or nutty to devise an equally simple and effective mechanism to limit or eliminate the inconvenience nym would cause? If Bernstein had developed both simultaneously, would you still be complaining?

His justification for this is `users seem to do alright with bookmarks, and as soon as everything is links, no problem!'

Well, how dare he come up with an idea for DNS signatures that completely avoids the problems of DNSSEC, without making sure it's to everyone's liking first! Clearly, Bernstein's comment about bookmarks is not a proposed ideal solution: he admits candidly it's a problem- today. Are you willing to make some sacrifices of convenience today for the sake of security? If not- why? Are you aware of the sad state of security in information technology today- where Slammer, a trivial 376-byte program, is capable of utterly crippling many systems that everyone depends on for anything and everything, to name just one example?

Regardless of the pros and cons of nym, we as a community and as computer scientists, have to be smarter than this- I would expect such sentiments from Windows users who think they are 'network administrators' because they know how to right-click on TCP/IP Settings, and shy at the thought of editing a text file on the command line to accomplish the same task.

Re:dan bernstein's position on this

[Tyler Close]

Where exactly does ssh keep bookmarks, for example?

/etc/hosts

We'll wind up inventing another DNS layer on top of the mess just to get back sensible names.

But that layer could be a locally managed namespace instead of a globally managed namespace. Why should everyone use the same mnemonic to refer to a given site? A global namespace means centralized bureaucracy, like IANA. A local namespace is just as convenient for the user, but creates no dictators.

See YURLs.

Re:dan bernstein's position on this

[BeBoxer]

He basically proposes only allowing a form of hostname which is (1) too long to type manually, and (2) includes long random-looking strings. His justification for this is `users seem to do alright with bookmarks, and as soon as everything is links, no problem!'

All this really does is push the security problem from DNS into whatever system is publishing the bookmarks/links. I'm not sure a self-certifying system really buys you much. And if you are now relying on obfuscated DNS names which are always hidden behind bookmarks, does it matter if the names are self-certified? No one is looking at them anyway.

Not to mention a whole crapload of other problems. URL's can no longer be used in print media. Email addresses cannot be written down, put on business cards, nor read over a phone. I'm sure that won't introduce any problems.

More importantly, the chain of trust doesn't have to start at Verisign/.com. You can exchange keys manually with folks in order to have DNSSEC with their whole domain. The protocols can handle having multiple starting points for trust. It's just more convenient to have a single key at the top so that not as much has to be exchange, and it works universally. Kind of like how it's nice to have a single root of the DNS tree, but not mandated by the protocol.

Re:dan bernstein's position on this

[mwood]

"A local namespace is just as convenient for the user...."

Until the user moves to a different host. Why do people *always* forget this?

Re:dan bernstein's position on this

[Tyler Close]

So take your namespace with you. What's the big deal? You don't abandon all your data when you switch computers, why should you abandon your namespace?

Re:dan bernstein's position on this

[Phil Gregory]

Where exactly does ssh keep bookmarks, for example?

To address your specific example, in ~/.ssh/config . You can set all sorts of options on a per-host basis, including hostname and username. So this:

ssh -p 42 phil@bob.somelongdomain.com

becomes this:

ssh bob

if your ~/.ssh/config contains

Host bob
HostName bob.somelongdomain.com
Port 42
User phil

That notwithstanding, I agree with your points. (I often find myself disliking DJB's approaches to things, though he does certainly write good code.) I just wanted to mention an aspect of ssh that you might not be familiar with.

--Phil (crypto geek)

Re:dan bernstein's position on this

[Gleef]

Anonymous Coward wrote:
Yes, DNSSEC is unfinished. The IETF has become worse than ISO.

Nope, IETF won't be worse than the ISO as long as the IETF allows you to read the standard without charging you.

Re:dan bernstein's position on this

[bluGill]

I prefer to type domain names into google myself. When I don't know for sure what name I'm looking for google will figgure out if I want a .com or .org. Google also figgures out (often right) that I spelled that name diffebad spelling) If I know the name for sure I will type it in the location bar, but I don't always know.

Re:dan bernstein's position on this

[sjames]

The thing is, the whole point of DNS is to allow simple and human readable names instead of unmemorable numbers or line noise looking strings.

Thus, if this 'solution' looks good, it will be much simpler to just shut down the root servers and do away with DNS entirely.

Cynicism over recommendation

[Anonymous Coward]

It's hard take a recommmendation from the inventor to seriously.

The Trust pyramid is the kicker, it seems these things fall into the hands of the untrustworthy. Almost analogous to the handling of domain names.

Whoever is at the top should be non-profit and transparent.

Re:Cynicism over recommendation

[lildogie]

> Whoever is at the top should be non-profit and transparent.

That's an unstable situation.

There should be no "top."

boring

[Anonymous Coward]

let's get back to bashing microsoft or something

I'm sorry but...

[Anonymous Coward]

The proper acronym for "DNS Security Extension" should be "DNSSEX"

DNSSEC: Good Enough?

[Anonymous Coward]

Nothing is ever good enough for /. readers, well except for Ogg Vorbis.

Re:DNSSEC: Good Enough?

[Gherald]

> Nothing is ever good enough for /. readers, well except for Ogg Vorbis

No, even most /. readers will acknowledge that the name sucks, so its not *entirely* perfect.

Re:DNSSEC: Good Enough?

[asv108]

Nothing is ever good enough for /. readers, well except for Ogg Vorbis.

Ogg Vorbis? Real /. readers only encode in FLAC..

Re:DNSSEC: Good Enough?

[andrewski]

No, real ./ readers don't have terabytes of HD space to waste on compressed .WAV's. Real /. readers do listening tests with their favorite encoders, and eventually use the Quicktime AAC at 96 because it sounds as good as the original on NS-10's, Klipsch monitors, the car stereo, the Sony home theater, and their BeyerDynamic headphones. They also laugh when their 'audiophile' friends choose the AAC over the original.

Re:DNSSEC: Good Enough?

[Anders]

> Ogg Vorbis? Real /. readers only encode in FLAC..
> --
> Phataudio.org MP3 Device News

There is something funny about your signature.

Re:DNSSEC: Good Enough?

[yerricde]

Isn't AAC that format with pre-echo problems that can't be played with free software in the United States?

Re:DNSSEC: Good Enough?

[andrewski]

There are a quite a few implementations of AAC. I know that the Quicktime encoder is superb. I know little about other implementations.

You young whippersnappers!

[Anonymous Coward]

'Course it's good enough. Why, back in my day we didn't even have DNS; you had to send the domain to the next server via smoke signals, and that didn't always work so we often sent the packet data tied to the legs of birds. Of course, the going got real rough sometimes, usually around dove season...

Re:You young whippersnappers!

[quick_dry_3]

"Why, back in my day we didn't even have DNS; you had to send the domain to the next server via smoke signals..."

modded informative? so thats how they really did it huh.

you'd be pissed when the dove finally made it back with host not found.

Re:You young whippersnappers!

[stox]

Back when we didn't have DNS, pathalias was our dear friend. Gone, but not forgotten!

Re:You young whippersnappers!

[beacher]

Oh.... I've always wanted to meet someone that's had a successful CPIP implementation that's rfc 1149 compliant..... Maybe we should all get duck calls and have a duck naming service to make sure the pigeons know which duck to follow. Next thing you know the DNS will do round robin going duck duck goose until you're crazy as a loon.

Dammit.. too many bird jokes.. I know I'm running afowl of the etiquette.. Hell with it, I'm not chicken.
-B

Re:You young whippersnappers!

[Jerf]

you'd be pissed when the dove finally made it back with host not found.

Especially since history indicates that the standard retry time was seven days long. 14 days to send a one-bit message ("host found" vs. "host not found") sucks pretty hard.

Better make sure you get the hostname right the first time....

Re:You young whippersnappers!

[aled]

What so bad with good old plain IP address? not this nonsense of IPv6. Six!!! That isn't even a power of two!!! Next will know everyone will try some protocol over TCP. I'm telling you, God wanted us to use plain TCP, not these unnatural HTTPs and Web Services. Everyone that those differently should be switched out and will be thrown to the firewall of hell.
In the old times nobody needed to autenticate. Only with username was used, everyone knew everyother and passwords were left blank.
Now let me tell you about the times before ARPANET...

Re:You young whippersnappers!

[mwood]

"Back when we didn't have DNS, pathalias was our dear friend. Gone, but not forgotten!"

Not gone, either. I still have it and use it occasionally.

BTW, two words: "host table". I remember....

Re:You young whippersnappers!

[mafeesh]

We used to use Packet over Sheep.

http://www.devilnet.net/rfc3203/

Re:You young whippersnappers!

[Anonymous Coward]

There there, don't be so hard on yourself over a simple parroty error.

dropped carrier... pidgeon.

Re:You young whippersnappers!

[rifter]

"you'd be pissed when the dove finally made it back with host not found."

Especially since history indicates that the standard retry time was seven days long. 14 days to send a one-bit message ("host found" vs. "host not found") sucks pretty hard.

Better make sure you get the hostname right the first time....

That was very funny, but since this is Slashdot I must nitpick that you misread the passage. The lagtime for the packet to return was 1 day. However Noah did wait 7 days between retries. :)

Why would we want to be identified?

[Anonymous Coward]

Haven't we posted long enough about how none of us want anymore info on positively identifying ourselves online, and now this comes along? What is it we want, total invasion on knowledge of our whereabouts, or ability to be anonymous?

Blame Game

[PktLoss]

Personally, I have always seen identity confirmation problems as a software issue, rather than a protocoll one.

Rather than relying on the protocoll to identify the source of communications, either working off some non-protocoll-related trust basis (ie, dont just MD4 your IP or something) for pre-established communications. Or for first-contact type situations, agreeing on some type of communication security.

I do not see these types of problems as the sort of problems lower level protocolls should be addressing.

Ripe Training For DNSSEC

[thriemus]

It seems RIPE have a One Day Introduction Course for "DNSSEC and related tools, and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zone"

Design vs. Implementation

[SlashCrunchPop]

Protocol design and implementation are two very different things, as anyone who has ever configured and used BIND knows from personal experience filled with agony over buffer overflows from hell. I hope that DNSSEC code will be written at the level of quality of djdns.

Yes, Dan Bernstein is a very exasperating person and his code is hideously formatted, but it is effective, efficient and among the most secure code ever written. I still hate him though.

Set the creative juices flowing for 10+years

[Anonymous Coward]

Sometimes, to get those creative juices flowing, it makes sense to go for it, and that is what we should do with DNSSEC. What do think? When it comes to DNSSEC, is it time to just go for it or should we debate it for another 10 years?

I, for one, think that even if we go for it and get our creative juices flowing, so to speak, we will still end up debating about it for another 10+ years.

Then there's Bernstein

[crucini]

Of course, no discussion of DNSSEC would be complete without Bernstein's comments. And here are the slides from his talk in pdf.

Not being an expert on the topic, I find DNSSEC a little worrying, as it seems to be a consolidation of the centralized power of Verisign or whatever. Ideally we should be planning how to move away from traditional DNS altogether, as the single-rooted namespace has led to much political abuse. But that is a really hard problem to solve.

First, solve this ...

[Anonymous Coward]

Quoth the article:

"The technology behind these confidence
checks uses digital signatures and
public key cryptography..."

First, find a way that I can get a "top level" CA to give me a certificate without charging me $US350 _per year_

Re:First, solve this ...

[SlashCrunchPop]

Grasshopper not want to pay for domain, but not want to register at /. either, eventhough registration free. Grasshopper right price shopper.

Re:First, solve this ...

[Anonymous Coward]

$350 doesn't seem like much for a commercial web site, but for the rest of us Yikes! Also would you have to buy a different certificate for each domain you owned, or would one cover all of them?

Re:First, solve this ...

[BeerMilkshake]

done! (I always intended to login someday anyway)

Re:First, solve this ...

[Anonymous Coward]

Jeez. It's about to go above 700k, isn't it?

Re:First, solve this ...

[SlashCrunchPop]

Welcome aboard! Now, to answer your question: the CAs should be regulated by an exclusively governing body such as ICANN, meaning that anyone who meets the prescribed criteria and adheres to the rules should be allowed to register with the governing body as a CA. That ensures fairness and competition, so you will not be seeing such outrageous prices.

Re:First, solve this ...

[HiroProtagonist]

Now the problem with that is that the ICANN has turned from a publicly governed body into a boys club of "industry leaders" who are playing favorites w/ their business partners.

DNSSEC?

[AltGrendel]

Wouldn't working on a improved form of SMTP be a better project?

Re:DNSSEC?

[Gherald]

> Wouldn't working on a improved form of SMTP be a better project?

We covered that in a previous story and basically concluded that SMTP was too widely implemented (think embeded systems, etc) for a replacement to be viable within the near future.

Re:DNSSEC?

[Gherald]

gah, typed href"= instead of href="...

here is the link to that story

Re:DNSSEC?

[Anonymous Coward]

What "improved form of SMTP" would that be? Why don't you detail what the problem is with existing SMTP, and how replacing the protocol would solve it, instead of spouting the slashbot "SMTP sucks and causes all spam" party line?

Re:DNSSEC?

[eluusive]

And DNS _isn't_?

Re:DNSSEC?

[Gherald]

I have no idea... ask the other people posting to this story. I was just informing your grandparent what the consensus was about SMTP.

Re:DNSSEC?

[Bert690]

Wouldn't working on a improved form of SMTP be a better project? No. DNS security impacts much more than just e-mail. Note for example that few websites use HTTPS, so DNSSEC would go a long way towards improving web security as well.

Re:DNSSEC?

[captaink]

Are you American?

Last message

[Anonymous Coward]

I know you're out there. I can feel you now. I know that you're afraid. You're afraid of us. You're afraid of change. I don't know the future. I didn't come here to tell you how this is going to end. I came here to tell you how it's going to begin. I'm going to make this post and then I'm going to show these people what you don't want them to see. I'm going to show them a world without you, a world without special character filters or repetitious character limits - a world where any form of trolling is possible. Where we go from there is a choice I leave to you.

How do you spell his name ?

[subStance]

Top page ... Mockapetris or Mockapertis. But there are some countries where the name can be spelled different ways .... o well, do what you like - he'll just get mad anyway.

Re:How do you spell his name ?

[El]

"It's a damn poor mind that can think of only one way to spell a word!" -- Andrew Jackson

I think project IRIS from MIT is more interesting

[hansreiser]

Time for ICANN to be obsoleted by a nice DARPA funded project from MIT and Berkeley. The guys working on it are pretty bright, and DNS is what distributed hash tables are best for.

You can find it at IRIS

Please site the RFCs!

[El]

I know RFC 1149 governs "packet data tied to the legs of birds", but I can't seem to find the relevant RFC governing IP over smoke signals, only a draft document. Was this protocol ever finalized? Can you provide a link? I'd hate to see people out there implementing non-RFC compliant IP over smoke signals -- that would cause massive interoperability problems!

Re:Please site the RFCs!

[Odin's Raven]

I can't seem to find the relevant RFC governing IP over smoke signals, only a draft document. Was this protocol ever finalized?

The protocol was nearly finalized, but had to be withdrawn after SCO threatened to sue, claiming that the "smoke signals" protocol infringed on as much as 50% of the IP contained in their "smoke and mirrors" business model.

Re:Please site the RFCs!

[Mryll]

Wasn't there a prototype effort involving the encapsulation of primitive "SSDI7" Smoke Signal DNS Information within the birds, abandoned due to a high rate of dropped packets and the realization of the efficiency improvements of a better encoding?

Why?

[Anonymous Coward]

Why would you want to authenticate DNS traffic? I'm sure there is a perfectly good reason, it just isn't immediately apparent to me.

Re:Why?

[El]

Certainly for dynamic DNS, you would want to know that the person redirecting "www.amazon.com" to a different IP address is really from Amazon, wouldn't you? Or do you not mind giving out your credit card number to random people?

Re:Why?

[DA-MAN]

The point of SSL cert's was to verify that amazon.com is who they say it is, this isn't DNS's job.

And if Amazon was incapable of securing their DNS servers, what makes you think when you put your CC into amazon.com that amazon is the only one that gets it.

And amazon.com is most likely not running dynamic dns.

Re:Why?

[SlashCrunchPop]

He just does not mind giving out random numbers to credit people.

Re:Why?

[Anonymous Coward]

Amazon.com is not responsible for securing _your_ DNS server.

Trusted computing...

[Ryan Broomfield]

Trusted computing means seperating hosts into two piles: trust and non-trusted. What rules apply to gaining "trust"? Is gaining "trust" a monetary decision? How does the little guy make sure that his content is seen without paying for a costly, restrictive license? Would he have to constantly censor what content he has with his host in order to maintain a "trust" certificate? Seems more like censorship than protection to me :\ This is only my opinion, of course.

Re:Trusted computing...

[Wyzard]

"Trusted Computing" is a Microsoft initiative that isn't really related to this. It's basically just a nifty-sounding name for the idea that "we'll try to stop leaving so many holes in our products", plus some DRM stuff.

The purpose of DNSSEC is to ensure that the result of your DNS query is genuine -- that it really is the IP address corresponding to the name you asked for, and not some other IP address given by an imposter. Once the DNS lookup is done, your communication with the host is completely outside the scope of DNSSEC, so censorship is out of the picture.

Security Issues?

[euxneks]

I don't understand the security issues here? I tried reading the FAQ but I'm a mumbling nincompoop. Can someone explain in a bit better detail about why we need security for DNS? Is there any actual recorded instances of people breaking into the DNS database? Is this the website hacking I've heard about?

Re:Security Issues?

[Anonymous Coward]

DNSHijacker is one tool that facilitates DNS spoofing.

Re:Security Issues?

[mellon]

I don't understand the security issues here? I tried reading the FAQ but I'm a mumbling nincompoop. Can someone explain in a bit better detail about why we needsecurity for DNS? Is there any actual recorded instances of people breaking into the DNS database? Is this the website hacking I've heard about?

DNS is mostly a UDP-based protocol, and it's pretty easy to spoof. When you type "www.ibm.com" in your browser, a UDP packet goes from your computer to a caching name server at your ISP (I'm oversimplifying here, BTW, but if you aren't a DNS geek this is most likely exactly what happens). The resolving name server sends another UDP packet out to the root name server to find out who to ask about "ibm.com". Then the root name server says "go talk to ibmns1.ibm.com at 10.1.17.2". Then the caching name server talks to 10.1.17.2 and asks it to resolve "www.ibm.com". Then it sends a UDP packet back to your computer telling it the IP address for www.ibm.com.

Notice that all of these UDP packets went over the network in the clear, and you can see that there were quite a number of opportunities to spoof you. If I can do a root hack on the machine that's running your ISP's caching name server, for example, I can give you a bogus IP address for www.ibm.com, and then steal your credit card info when you try to buy something there. If I can watch your packets and respond faster than the caching name server does, I can also convince you to go to the wrong place. So it's not an insignificant vulnerability.

With HTTP, if you are smart, you check to make sure that your web browser is doing a secure transaction, but frankly, most people just ignore this issue, or don't even know what it means.

With DNSSEC, your resolver on your computer knows the public half of the root DNSSEC key. So it can verify the answer it gets, all the way from the top down to the bottom. If someone spoofs the response, the resolver ignores the spoofed packet, and you get the real one. If your ISP's caching name server is compromised, you can't look up www.ibm.com, and eventually you call your ISP and complain. They fix their nameserver, and you go back to your business, unspoofed.

As I said in a previous comment, DNSSEC is also a handy place to stash keys, precisely because you can validate them as I've described.

And, BTW, I glossed over a lot of details here. If you really want to know how this stuff works, you should probably read the RFCs... :'}

DNSSEC needn't be a panacea to be useful.

[mellon]

DNSSEC provides a secure key distribution mechanism. Right now, the only secure key distribution mechanism on the Internet is the SSL key mechanism, whereby a cartel of ~5 companies with keys that got into the original Netscape release essentially rule the roost, because Joe Average has no idea how to install a new root key in his browser. The cheapest key of this type will cost you ~$150 per year, and you can't use it to make more keys.

DNSSEC does require a top-level root key, but once you have registered your domain securely, you can generate keys whose public halves are *in the DNS* where anybody can get at them. That is, you can use your key to make more keys. Also, if you don't want to do business with one registrar, you can go to another, and as you are no doubt aware, the DNS registration market is quite competitive. So in fact DNSSEC is very democratic compared to its only current alternative.

Unfortunately, this is not a glitzy thing. This is nuts and bolts, wire dragged through conduits. DNSSEC is a really nice platform for building a more secure internet, but it doesn't solve the problem on its own - you have to build on it - e.g., using it to make SMTP more verifiable.

DJB says that BIND doesn't do DNSSEC very well. It's true that BIND 8 doesn't do as well as BIND 9. If you want to spend some money, my employer will sell you something even nicer. But the fact is that there are several free, working implementations of DNSSEC out there right now.

BTW, in the interests of full disclosure, I should say that I work for the same company as Paul Mockapetris (Nominum), and have in the past worked for the company that DJB styles "the BIND company," although I know much more about DHCP than about DNS.

Re:DNSSEC needn't be a panacea to be useful.

[Florian Weimer]

DNSSEC provides a secure key distribution mechanism. Right now, the only secure key distribution mechanism on the Internet is the SSL key mechanism, whereby a cartel of ~5 companies with keys that got into the original Netscape release essentially rule the roost, because Joe Average has no idea how to install a new root key in his browser. The cheapest key of this type will cost you ~$150 per year, and you can't use it to make more keys.

A browser key costs $250,000 per year, and $250,000 up front for audits etc., AFAIK.

Re:DNSSEC needn't be a panacea to be useful.

[headcharge]

DNSSEC provides a secure key distribution mechanism. Right now, the only secure key distribution mechanism on the Internet is the SSL key mechanism...

You apply the description 'secure' as though security was a switch to be toggled on or off, or that in such black and white terms, it's even possible. Any such claim is either ignorance or mere lip-service: I don't place trust in "Trustworthy Computing" because Microsoft calls it trustworthy. (I don't place trust in it at all, but that is beside the point.) Nor should anyone believe there is such a thing as 'security' that is really secure in and of itself, much less because someone claims it to be so.

DNSSEC provides a layer of security; a countermeasure. It absolutely does need to be a panacea- as close to it as we, as fallible humans, are capable of designing. Have we learned nothing from the weaknesses of TCP/IP, SMTP, and the like? Have we learned nothing from the problems that arise from designing architectures on which to build future technology, when unrealistic assumptions continue to be made about the environment they will exist in? The failures of past implementors (like Mockapetris, ironically) can be excused, on one condition: present and future implementors must learn from their mistakes, and avoid them.

Keeping this in mind, is it obtuse of me to discard, nay, to vehemently reject and persecute 'good enough' solutions as building blocks for the future?

DJB says that BIND doesn't do DNSSEC very well. It's true that BIND 8 doesn't do as well as BIND 9. If you want to spend some money, my employer will sell you something even nicer.

OT: BIND has a proven past and present of not doing a whole helluva lot very well. Also OT: Your employer, whether they call themselves Nominum or the Internet Software Consortium or whatever mask they choose to wear, writes/has written/continues to write both the perpetually buggy BIND software, and writes and sells the 'nicer' commercial software, correct? What justification, other than the desire to make more money for themselves, do they give for selling (supposedly) high-quality software and offering provably low-quality software (that runs the root nameservers, no less) to the community?

DNSSEC is a half-assed attempt at getting things done the quick and dirty way. Mockapetris wants his name in a few more RFCs; the BIND/ISC/Nominum people need another impressive but misleading tagline to further their marketing efforts.

Re:DNSSEC needn't be a panacea to be useful.

[mellon]

The instantssl key isn't recognized by most browsers, unfortunately. They claim something like 95% coverage, if I remember correctly, but when I tried one of their keys in a real deployment, my users got a _lot_ of certificate errors. So it's a nice idea in theory, but if you really care about people being able to use your key, it's not good enough. Nice price, though. :'(

Re:DNSSEC needn't be a panacea to be useful.

[mellon]

DNSSEC provides a layer of security; a countermeasure. It absolutely does need to be a panacea- as close to it as we, as fallible humans, are capable of designing.Have we learned nothing from the weaknesses of TCP/IP, SMTP, and the like?

Hm, what I've learned is that they work. Yes, they have security problems, and yes, we need to fix them. But if we have something that's a significant incremental improvement, and don't have the complete panacea, is it a mistake to use what we have? It sounds like you're saying it is. That's not a very good attitude for an engineer to have - you never get anything done with that attitude.

Keeping this in mind, is it obtuse of me to discard, nay, to vehemently reject and persecute 'good enough' solutions as building blocks for the future?

I think it is, yes! :')

OT: BIND has a proven past and present of not doing a whole helluva lot very well.

It's unfortunate that BIND 8 and BIND 9 are always discussed by DJB and his acolytes as if they are the same product, when in fact they are two completely separate code bases, one of which was in fact engineered to specifically avoid the failings of the other. It would be much more fun to debate these points if we were actually talking about the merits of each software package, rather than tarring one with the same brush as the other.

Also OT: Your employer, whether they call themselves Nominum or theInternet Software Consortium or whatever mask they choose to wear,

The ISC and Nominum are both going concerns, with a completely unrelated set of employees - that is, nobody who works for Nominum also works for ISC, or vice versa. So to speak of them as if they are the same entity is incorrect.

writes/has written/continues to write both the perpetually buggy BIND software, and writesand sells the 'nicer' commercial software, correct? What justification, other than the desire to make more money for themselves, do they give for selling (supposedly) high-quality software and offering provably low-quality software (that runs the root nameservers, no less) to the community?

I use BIND 9 as the name server for my domain, and I'm very happy with it. I think it's very high quality software. The value added in Nominum's product have more to do with enterprise-level and telco-level support infrastructure than they do with differing levels of code quality. I am sure Nominum would love to sell our DNS products to more providers of root name service - to the extent that this hasn't happened (and I have no idea who our DNS customers are, TBH, so I don't know that it hasn't happened), I suspect it's because BIND does a good enough job for that particular application, and there's no motivation to upgrade.

DNSSEC is a half-assed attempt at getting things done the quick and dirty way. Mockapetris wants his name in a few more RFCs; the BIND/ISC/Nominum peopleneed another impressive but misleading tagline to further their marketing efforts.

You make a lot of assertions. If assertions were valid arguments, you would have just whupped my ass here. :'}

Re:DNSSEC needn't be a panacea to be useful.

[headcharge]

Hm, what I've learned is that [TCP/IP, SMTP, other aged Internet standards] work.

I agree, in a way analogous to how Microsoft Windows "works". Perhaps I'm expecting too much, but that's simply not good enough.

But if we have something that's a significant incremental improvement, and don't have the complete panacea, is it a mistake to use what we have? It sounds like you're saying it is.

I'll continue with the Microsoft analogy: every one of the 40-some-odd security and bugfix updates I had to apply the last time I installed Windows on a machine was a 'significant incremental improvement'. Incremental improvements necessitated by flawed design, IMHO, are simply not good enough- especially when we know they're not good enough before we even implement them! This is even more true when we try to use them as building blocks for the future.

I'm not trying to equate DNSSEC and Windows- but similar, really the same, concepts are involved. Poor design necessitates more and more of these significant incremental improvements. With Windows, it's marginally acceptable to apply these improvements; if you're one of the many who don't like doing that, there are choices of other software to run on your computer. But how do you 'patch' an Internet standard once it's been widely deployed, with a lot of time and effort spent to implement this in software applications? And unlike Windows, there is *no* choice. If someone says 'I want a protocol for publishing and resolving names to IP addresses on the Internet', what option does s/he have other than DNS?

That's not a very good attitude for an engineer to have - you never get anything done with that attitude.

It does indeed take more time to realize a complete, properly deisgned solution than one that is an incremental improvement. But this does not equate to 'never getting anything done'- it simply requires more patience. I am very willing to be patient in that case.

It's unfortunate that BIND 8 and BIND 9 are always discussed by DJB and his acolytes as if they are the same product, when in fact they are two completely separate code bases, one of which was in fact engineered to specifically avoid the failings of the other.

Whether it's BIND version 4, 8, or 9 is of minor importance. I don't trust the people writing the code, and here's why: I'm aware that the ISC says BIND 9 was a complete redesign from previous versions. I haven't read the source code to see if this is actually true or not, but I'll take their word for it for purposes of this discussion. I appreciate the fact that they recognized the problems caused by poor design in previous versions, and did the right thing- rewrote it from scratch. But it didn't take very long for attackers to be able to kill a BIND 9 server with a malformed DNS packet or find remotely exploitable buffer overflows in BIND 9's resolver library. (If you're unclear or doubtful on what vulnerabilities I'm referring to, I'll be happy to provide references.)

Whether the ISC is lying about BIND 9 being a complete rewrite, or they have simply done a poor job implementing their finally-got-it-right-this-time design, or whatever the reason, matters very little. I wouldn't trust them to sit the right way on a toilet seat.

In contrast, Bernstein's still sitting on the $500 reward for finding similar security holes in djbdns. My own experience with BIND and djbdns has shown me BIND is not particularly high quality software, and that the problems encountered with BIND don't appear in djbdns. Given the choice between these software packages, does my choice of djbdns over BIND seem unreasonable?

It would be much more fun to debate these points if we were actually talking about the merits of each software package, rather than tarring one with the same brush as the other.

BIND's ugly history, regardless of version, is well documented by many third parties (not ISC or DJB: CERT, for example, has all the info one n

Re:DNSSEC needn't be a panacea to be useful.

[mellon]

I have a lot of IE4 users. My users aren't people who have a lot of money to buy new Microsoft licenses, and because they follow the buddhist code of ethics, they also don't steal copies of Microsoft software. So they're mostly running Win95. :'}

ICANN

[mabu]

But if we get rid of ICANN we can't vicariously live through their amazingly productive corporate meetings in Sri Lanka and Bermuda!

OK here is a /. MS bash from a bash user.

[ratfynk]

What I think we will see with the Fritz chip .NET will be a DNS that first asks "where do you want to go today" then tells you need to obtain the key!

Hey, you're right!

[roystgnr]

I'll notify the one guy who designs all internet protocols and tell him to switch tasks.

Re:Hey, you're right!

[I_redwolf]

Ummm he's busy at the moment so all protocols are currently at a stand still till he gets back from las vegas.

Petris or Pertis?

[Anonymous Coward]

Is it Petris or Pertis?

Come, come, we have inconsistent mockery here!

'Course, it'd fit right in on Limbaugh or O'Reilly.....

This guy's older than WOOD

[Anonymous Coward]

He wants the IETF to get off the dime

What is this guy, like, 50 years old? Twenty-three skidoo... Tippecanoe and Tyler too, and hubba hubba and don't take any wooden nickels, and the flappers these days! Scandelous!

Fuckin' old people.

Let's see PGP applied here

[Anonymous Coward]

Let's say the Slashdot guys create a PGP key, publish the public key on the various keyservers, and start signing their web pages. Once I have a path from my key to theirs, I can be pretty sure that it's really them.

Even if I don't have a path, my future browser could record the key that's used when bookmarking a site. That way if I come back to it later and the key doesn't check out or another key has been used, then I know it's been compromised since then.

This could be used for other purposes. Let's say someone has a personal web page somewhere and is forced to move for some reason. You could be sure that it's the same person at the new URL because the same key would be used to sign the content. The best part is that whoever takes over the old URL can't spoof the old guy since they don't have his private key. All they can do is publish the exact data he already had out there.

Taken to an extreme, you could almost stop caring about URLs. You could look up someone by searching for their PGP key, and then work out from there. It wouldn't matter where they were actually hosted, since it is verifiably them. There would be no point in publishing phony information, since the key wouldn't check out.

DNS let us abstract away IP addresses to some degree. URLs can get us away from worrying about specific hostnames. Can this be the thing to abstract URLs away to some degree?

Re:Let's see PGP applied here

[Just Some Guy]

Let's say the Slashdot guys create a PGP key, publish the public key on the various keyservers, and start signing their web pages. Once I have a path from my key to theirs, I can be pretty sure that it's really them.

I don't oppose that in theory, but my sites have a lot of dynamic content and I'd have the choice of:

1. Caching my GPG key (presumably a special-purpose one for nothing but web stuff).
2. Typing it in each time a request comes in.

What about those of us not running our own servers? I could probably feel secure that my own machine isn't 0wn3d by anyone but me, but how could I guarantee that my ISP isn't "borrowing" my key to sign their own content or do some other bizarre thing?

No, I don't think that's quite the direction we should be moving. The basic idea isn't bad, but I can't imagine a reasonable implementation. Any ideas?

Re:Let's see PGP applied here

[Tyler Close]

Even if I don't have a path, my future browser could record the key that's used when bookmarking a site.

That would leave you open to an MITM attack. The attacker can intercept that first request and send your browser whatever key it wants. What you need is a way to strongly correlate the request URL to the site's public key.

I've built a protocol for doing just this. Check out YURLs. The site also provides a proof-of-concept WWW browser that can use to surf the WWW with this protocol.

Re:Let's see PGP applied here

[Fastolfe]

TLS (the new SSL standard) can just as easily use PGP-based keys instead of X.509 certificates. Browsers don't support that, clearly, but the protocol itself does.

Re:Let's see PGP applied here

[Anonymous Coward]

DNS let us abstract away IP addresses to some degree. URLs can get us away from worrying about specific hostnames. Can this be the thing to abstract URLs away to some degree?

Yes, please people, let's replace those annoying urls with convenient 2000 bit numbers.

Other aspects of DNSSEC

[karl.auerbach]

There are certain aspects of DNSSEC that are infrequently discussed.

First is that DNSSEC adds a degree of rigidity and inter-dependency to the net that makes it more brittle in the face of a natural or intentional disaster. When things have fallen apart, the time to recover is greatly increased if the rebuilders have to rebuild the security hierarchy before names can start resolving.

Another aspect is that DNSSEC tends to wire-in a single DNS root and wire-out competing roots.

Now, a lot of people think that competing roots are a horrible thing. And a lot of other people think they are a great thing. (I've been using competing roots for years with zero problems, so you can guess which camp I'm in.) And some communities (AOL) and countries, are not necessarily making noises that they really like the idea of one god-like root for DNS. (They want consistency, their concern is about there being a single authority.) Competing roots are also advocated as a way to escape captured regulatory bodies, such as ICANN.

For some of the big zones - .com - I have heard that DNSSEC can make it take a very long time to come up after a change in zone contents. That's sort of having to wait for fsck to complete on a 500gigabyte disk every time you want to change a file in the filesystem.

Re:Other aspects of DNSSEC

[amorsen]

For some of the big zones - .com - I have heard that DNSSEC can make it take a very long time to come up after a change in zone contents. That's sort of having to wait for fsck to complete on a 500gigabyte disk every time you want to change a file in the filesystem.

That's a myth spread (mostly) by VeriSign. In reality, the .de zone (which is about as large as .com) was signed in a few hours on a workstation a few years back. CPU speed is growing way faster than the number of domains these days, and a few hours are not a problem compared to propagation delays you face anyway when changing .com.

Reality is that DNSSEC doesn't let VeriSign make more money off each second-level domain. They want DNSSEC changed so they can turn it on and off for each second-level domain. That way they get to charge everyone again. Of course they don't say that out loud; instead they claim performance requires that. Search for DNSSEC opt-in if you want to know more.

DNS SEC

[Omnifarious]

Any solution that leaves DNS around in its current form is broken. DNS's centralized naming scheme is and endless source of annoying political problems.

The problem is that DNS is trying to be Google

[Sanity]

URLs were never intended to be things that people could guess off the top of their heads based on what they were looking for - and they are really bad at it.

URLs should provide a unique way to identify information, but the process of finding the URL that someone is looking for should be left up to those that specialize in this - namely web search engines.

With Freenet - information is identified by complex URLs which allow the user to guarantee that the information is what the user expects it to be. The problem of finding the URL you want is left to freesites that specialize in this.

Re:The problem is that DNS is trying to be Google

[mwood]

"URLs were never intended to be things that people could guess off the top of their heads based on what they were looking for - and they are really bad at it."

Uh? I'm looking for Toyota Motor Co. "http://www.toyota.com/" works. Lookit the cars!

I'm looking for Purdue University. "http://www.purdue.edu" works. Financial aid? classes? it's right there.

I'm looking for the U.S. executive mansion, the "White House". "http://www.whitehouse.gov" works. There's GWB big as life.

Looks like I'm 3 for 3. Gee, I'm really bad at guessing URLs -- I can't seem to do better than 100%.

Re:The problem is that DNS is trying to be Google

[Fastolfe]

This "works" because these companies have gone to the courts to wrestle these domains away from other (frequently quite legitimate) holders.

You're picking some fairly obvious examples. The case of the White House in particular is only obvious because you've been there before. If I want to see information about the presidency, and did not know that the "White House" was the title of his Internet presence, I might try a large number of combinations before coming across that one.

Why does Apple Computers, Inc. get apple.com? Why not Apple Supermarkets or some other company with Apple in their name?

DNS is used as a search engine because in a large number of the cases (not all), companies have litigated to allow that to happen. The very fact that litigation is even needed suggests that DNS is being used for something it's not designed for.

What's really needed is a directory that associates real-world names (official company names and/or trade/service marks) with DNS domains. SRV records in DNS could then point you to that domain's primary HTTP server. Users don't necessarily need to even see a URL or a hostname at that point.

Search engines can do the rest. But let's stop bloating IP laywers by continuing to misuse DNS like this.

It was going to be called something else.

[Devil's BSD]

It was going to be called DNSSEX, until the developers realized it might be mistaken for something else.

Re:The SBD girls

[Billly Gates]

I couldn't agree with you more. They sure do.

Political Problems with DNSSEC

[billstewart]

Some of the problems with DNSSEC are technical - most of them have to do with making things fit inside 512-byte packets and not breaking too many server implementations. But the big problems have been political, including politics implied by the protocol structure and politics that's separate from it.

• Old US Fed Attempts to Stifle Crypto - Back in 1993, when DNSSEC was drafted, the US government was still doing the Cold War thing of pretending that there were Commies who shouldn't be allowed to have Crypto because their Spies could send Unbreakable Messages, and the FBI was encouraging them to maintain this charade because crypto might make illegal wiretapping difficult and mass wiretapping expensive. So Open Source publishing of DNSSEC code on the Internet or export to other countries was threatened by all the rest of the anti-crypto Export Law stuff, even though it only needed digital signatures and not encryption - because RSA digital signature code is also usable as encryption code, and because good digital signatures make forgery impossible. At one point, John Gilmore got approval for exporting a "bones" version of DNSSEC (with the crypto code removed) and then the approval got yanked shortly afterwards, in spite of their being no adequate legal justification for it. DNSSEC was pretty much stillborn because of those politics, which was too bad because we could have had a DNSSEC in place when the Web thing was taking off.
• Hierarchical Nature of DNS - For many security and political applications, a hierarchy is a Bad Thing, because it means that somebody's in charge, and that there's one big weak point to attack it with. That doesn't seem to be much of a problem for DNSSEC, because it's piggybacking on DNS, which is inherently hierarchical. Sure, there's all that ugly politics about who gets to sell the name example.com and who gets to resolve conflicts if multiple companies want to be the One True Owner of the domain name example.com, but getting the folks who manage official assignment of the name example.com to sign the DNS record is a simple technical implementation, just as getting them to put the IP address in the DNS server is - it's *much* simpler than getting them to send the bill or the renewal notice correctly.
• ICANN Ugliness - Of course, all this was mired in political ugliness, and the ICANN Name Gods fundamentally weren't interested in doing the right thing technically - they were interested in doing the power-grab thing on the intellectual property trademark space, not in technical administration. And the people who fight about name space ownership and collect your registrar money aren't really the people who run the physical root and .com DNS servers, many of whom worked for organizations funded by the US Government, who weren't going to push for crypto protection.
• Multiple Name Registrars, Single Keys - There's a big ugly gap in the DNS hierarchicalness, which is that multiple registrars can sell you the name example.com, but there's only one DNS Signature Key for .com - does that mean that 50 random companies around the world can all be trusted to own those keys and not leak them? Fat chance! But the protocol wasn't designed for that kind of sharing.
• One Root To Rule Them All, again - If there's only one Root, and they don't get it to buy in to the plan, which they didn't, and it doesn't sign the keys for com, edu, etc., or the country codes, then there's no clean way to bootstrap the system. Sure, there were all the alternate-root guys trying to compete, and any country-code TLD administrator (e.g. Tonga's .to) could have created a key for their TLD and started signing keys, but without The One True root key, eventually it falls apart. Tonga or Norway or someone could declare themselves to be the head of the Cabal, issue a Root Key, sign other TLD's domain name with it, and start selling more DNS names to people who wanted them, and

Re:Political Problems with DNSSEC

[leto]

You do not have to trust anyone you dont trust.
You can use truted-key statements to create "Secure entry points". You can trust .nl's key for .nl and you can decide not to trust the key for "." or ".com" if you don't trust them.

Re:Political Problems with DNSSEC

[Wesley Felter]

There's a big ugly gap in the DNS hierarchicalness, which is that multiple registrars can sell you the name example.com, but there's only one DNS Signature Key for .com

Isn't that what the registry is for?

Is it 1984?

[thinkerdreamer]

Your point is rather interesting, if it is true. A rapid deployment of a system that defeats spam would mask its invasion of privacy leaving the public ignorant and there would be commercial and government spying on posts in forums like these.
That is if, and a big if, it tags everyone. I don't understand it all myself.

Hopefully if it actually tags everyone, there will be a public outcry similar to the RFID complaints when Walmart tried to implement them. Maybe calling up such a privacy group like the one that complained about Walmart would be an excellent thing to do.

This stuff is straight out of the book 1984. That prophetic book of the perils of technology has been in the minds of many lately. Unless people all across the world view invasion of privacy like taking away their civil rights, then nothing will happen. Microsoft and others like this company will strip away every right we have under the umbrella of "beneficial" technology. Businesses and governments will take advantage of such technology and know everything about a person. If a political or commercial figure doesn't like a citizen of his country that person would lose his job, his fame, his wealth, his friends or even his life.

When this happens, we will all be saying "I told you so!" but it may be be too late. Privacy then will be like a civil rights movement. There are many things I can say that might take place then, but I cannot say all of them. All I can say is that governments need to act now or risk losing public confidence. When public confidence erodes, so will the government. It is not wise for a government to have its people live in fear. Those type of governments have a history of being overthrown.

Now I've dragged on awhile about privacy, but if there is no invasion of privacy from this technology then I say "Go for it!"

dnssec, how about authenticated email reply-to?

[tjstork]

Someone at 130.160.91.27 evidently is spamming people with my email address as the reply to. While they are working on dnssec, perhaps someone could modify SMTP / POP servers to validate the reply-to domain or disallow the mail.

Re:dnssec, how about authenticated email reply-to?

[Anonymous Coward]

Try publishing SPF data in your zone(s) and hope the rest of the world starts using it. If that happens, your forgeries should go way down, since they'll be coming from systems that are not authorized to send mail as your domain.

Note: I set this up on my domain about two weeks ago, and a fair amount of mail goes out from here to various mailing list subscribers. So far I haven't logged so much as one query for the SPF data. It's still very much in larval stage.

Re:dnssec, how about authenticated email reply-to?

[fyonn]

exim by default does try and validate the mailserver the mail claims to come from, to the extent of checking to see if the from domain has mx records. it can also be configured to "callout" to verify domains, if when it recieves an email it makes an smtp connection to the primary mx for the sending domain and see's if it would accept an email for that user. thats pretty expensive though and hardly anyone turns it on.

dave

Re:dnssec, how about authenticated email reply-to?

[WuphonsReach]

Search for "RMX" - which is a proposed addition to the DNS records. Basically, when you setup your domain, you specific what IP addresses are allowed to send out e-mail for folks in your domain.

The destination mail server has the option of looking up that RMX record, cross-referencing to the IP that it received the e-mail from, and deciding whether to keep / toss / reject the e-mail if the e-mail didn't come from an authorized system.

Nice system, mostly compatible with DNS, so requires very little to change technically (and the spam issue is expensive enough that you can build a business case for upgrading your DNS software). Nicer is that it's up to the destination whether or not they want to be strict about matching RMXs. It also makes whitelists much easier to program because you can be surer that e-mail from example.com actually came from a server that example.com controls.

It doesn't solve the issue where spammers abuse an open-relay or mis-configured server. Or where a spammer sets up a spamming domain with a wide-open RMX range (all addresses allowed to send e-mail for this domain), but it's at least a step in the right direction.

Re:DNSSEC and extending protocols

[MrChuck]

SMTP has (and should have) no way to do end to end encryption of a message. It shouldn't. It's transport, not data.

SMIME is a fine and lovely and centralizable way to do mail body encryption.
SMTP/TLS is a fine way to do transport encryption/authenication from one hop to another.

Lacking is a way - perhaps a signature header - for an MTA to "know" where a message is from. I'd love to be able to prioritize mail that's perhaps from "known good" domains. I believe IronPort is doing something proprietary along these lines.

Back to DNS:
DNSSEC tries to offer a way to ensure the content of a zone.

It's a good notion.

It's not been implemented well. I don't trust VeriSign, I certainly don't trust JoeBlow registrar. However, I'm willing to trust my domain and that's really what's needed when dealing with subdomains. And most of the meat of my DNS use is in the subdomains - every desktop, every server lives in a subdomain. www, ftp and MX records are in the top level - that's about it.

With BIND 9, I'm delighted that all my zones use notification and IXFR's (tranferring a 40,000 record zone over a DSL is not good without incremental zone transfers - esp in a DHCP heavy environment that can cause regular zone updates).

We can "extend" DNS with DNSSEC (or -alikes) because it's negotiable (like ESMTP is for SMTP). We cannot change how ALL DNS transfers and works by default without GREAT pain (we did that pain ONCE in 1980 going from NCP to TCP).

DNSSEC mini HOWTO

[bobbozzo]

Paul Wouters from the FreeSWAN project spoke at DefCon 11 on DNSSEC... he has some materials online at: http://www.xtdnet.nl/paul/dnssec/

Decentralized authentication

[Tyler Close]

Since you're willing to give Bernstein's solution a fair hearing, I suggest you also check out YURLs. There's even a simple proof-of-concept WWW browser that you can use to get a feel for how the WWW without DNS works.

Note that switching to decentralized authentication doesn't mean giving up on human memorable names, just global human memorable names. Users can still use a local namespace. This provides both useability and security benefits. See the YURL Name paper.

Tyler

Re:I think project IRIS from MIT is more interesti

[Bert690]

Time for ICANN to be obsoleted by a nice DARPA funded project from MIT and Berkeley. The guys working on it are pretty bright, and DNS is what distributed hash tables are best for.

Try again. IRIS hasn't proposed a thing that can solve DNS security issues. It might address decentralizing the mostly hierarchical lookup procedure (to address scalability for example), but this would in fact require something like DNSSEC so that DNS records could be verified as legitimate even when provided by untrusted/unauthoritative hosts in a DHT.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Bookmark file keywords

[Tyler Close]

Your issue is easily handled by the bookmark file keywords provided by Mozilla Firebird. After you've bookmarked a page, you can return to it by typing in your personally chosen keyword.

It is interesting how this simple user interface feature provides a function you thought could only be provided by a central bureaucracy like the DNS. Hold off on the hyperbole a bit. There are some good solutions if you look.

I've worked through a lot of these issues with my YURL work.

Re:Bookmark file keywords

[macshit]

Your issue is easily handled by the bookmark file keywords provided by Mozilla Firebird. After you've bookmarked a page, you can return to it by typing in your personally chosen keyword.

I think you're kind of missing the point.

1. The obvious implementation burdens extend beyond the web-browser. There are many programs out there which need host names -- ssh, telnet, ftp, my mail reading program (for pop3), etc -- all of which need an extra indirection layer added, plus the infrastructure need to populate it without driving users nuts.
   
   
2. More importantly, people often use hostnames gathered from non-electronic sources. They're written on business cards and letterheads, displayed in advertisements, included in magazine articles, and mentioned by friends in conversation; in Korea they even put them on the side of buildingsin place of a company's logo. All of these are basically global names. Sure you can add a new system to translate between such global names and your obfuscated `hostnames' in a secure manner -- but isn't that what DNSSEC is?!?

Re:Bookmark file keywords

[Gleef]

Tyler Close wrote:

Your issue is easily handled by the bookmark file keywords provided by Mozilla Firebird. After you've bookmarked a page, you can return to it by typing in your personally chosen keyword.

It is interesting how this simple user interface feature provides a function you thought could only be provided by a central bureaucracy like the DNS. Hold off on the hyperbole a bit. There are some good solutions if you look.

DNS was developed in 1981; The WWW was developed in 1990. That right there is a clue that DNS is for more than just web addresses.

Off the top of my head here are some uses of DNS that just don't seem to fit with the YURL concept:
1) Configuring security policy
2) Configuring routing policy
3) Troubleshooting routing issues (ping, traceroute, etc)
4) Command line internet tools (ssh, rsync, cvs, etc)
5) Configuring distributed functionality in a large application across an enterprise (databases, directory services, etc)

In all the above, I need machine identifiers to be both reliable (something YURL and nym offers and DNS doesn't), and human readable (something DNS offers and YURL and nym does not). Since there's nothing out there that offers everything I need, I stick with DNS, it doesn't require I implement anything new.

Now if something like YURL or nym were combined with something like DNS's CNAME feature in a way that allows for human readable, reliable and secure addresses, then I'll sit up and take notice. I'm sorry, I just can't take any alternative naming scheme seriously if its solution to complex identifiers is "let the bookmarks handle it".

Re:Bookmark file keywords

[Tyler Close]

The obvious implementation burdens extend beyond the web-browser. There are many programs out there which need host names -- ssh, telnet, ftp, my mail reading program (for pop3), etc -- all of which need an extra indirection layer added, plus the infrastructure need to populate it without driving users nuts.

Take a step back and look at the problem to be solved: users need to communicate with their software using human memorable names.

The technical solution you are so vigorously advocating is for all identifiers, in all parts of the system, to be human memorable. Using human memorable identifiers beyond the human-to-computer interface causes difficult security and scaleability problems. These problems can be easily avoided by using self-authenticating identifiers.

Self-authenticating identifiers are easily deployed in existing software. All of the applications you listed already support keyword/alias/bookmark functionality. GUI based ssh and telnet programs typically support a list of shortcuts for establishing a connection. Another poster to this thread showed how to use a keyword with the command-line version of ssh. FTP is easily used from a WWW browser with bookmarks. Every mail program I have ever used supports aliases for email addresses. Users happily use these features. The indirection layer you are so worried about already exists and is in common use. We're just not fully exploiting the functionality we already have.

More importantly, people often use hostnames gathered from non-electronic sources.

Keywords are again already in common use here. AOL keywords are commonly used in offline advertising.

Sure you can add a new system to translate between such global names and your obfuscated `hostnames' in a secure manner -- but isn't that what DNSSEC is?!?

No, that's not what DNSSEC is. DNSSEC is another instantiation of a PKI hierarchy. PKI does not use self-authenticating identifiers.

Most importantly, keywords form a local namespace, not a global namespace. A global namespace demands a centralized bureaucracy, with all the costs that entails. Why pay for a bureaucracy when you can provide the functionality you need locally?

Re:Bookmark file keywords

[Tyler Close]

In all the above, I need machine identifiers to be both reliable (something YURL and nym offers and DNS doesn't), and human readable (something DNS offers and YURL and nym does not).

When using YURLs, you still use a human memorable namespace, like the DNS. The only difference is that the namespace is local instead of global. Whatever interface you use to interact with the DNS namespace can be immitated with a local namespace for YURLs. From the user's perspective there need be no perceptible difference between using DNS versus YURLs.

I'm sorry, I just can't take any alternative naming scheme seriously if its solution to complex identifiers is "let the bookmarks handle it".

Boorkmarks are just one way of implementing a local namespace. If you don't like them, choose another mechanism. There are lots of options and no doubt new ones to be discovered. As I said, you can make it so that your local namespace interface is indistinguishable from using a DNS like namespace. It's all just UI issues that can be solved locally.

For more on this, take a look at another post I wrote for this thread.

Re:Bookmark file keywords

[macshit]

I'm not `vigorously advocating' anything, just pointing out that your (and bernstein's) pet approach has some glaring flaws which you're glossing over.

[ List of random bookmark/shortcut features deleted ]

Users happily use these features. The indirection layer you are so worried about already exists and is in common use. We're just not fully exploiting the functionality we already have.

Do you really believe what you just said constitutes a solution? (1) It's not acceptable to just say `Use the GUI version.' No. (2) If hostnames really disappear, and users are forced to use all of these disparate facilities, they're going to go nuts; it's really a pain having to enter the same damn information in 10 different forms because there's no central (user/machine/whatever) list.

This problem is (obviously) soluble, but it's not a minor little change, it's going to require a fair amount of work, and changing a lot of existing tools.

No, that's not what DNSSEC is. DNSSEC is another instantiation of a PKI hierarchy. PKI does not use self-authenticating identifiers.

Huh? I never said DNSSEC used `self-authenticating' identiers, merely that it could be thought of as a solution to the global-keyword -> self-authenticating identifiers mapping problem (that is, it can return them).

Maybe there is some benefit to separating the namespace into two sorts, `global keywords' and `self-authenticating identifiers,' and using each where appropriate (keywords on your business card, s.a.i. for internal web links) -- but none-the-less, the `global keywords are important' problem still exists.

Re:Bookmark file keywords

[Tyler Close]

I'm not `vigorously advocating' anything, just pointing out that your (and bernstein's) pet approach has some glaring flaws which you're glossing over.

Words like 'glaring' are 'vigorous'.

Note that you have yet to present a single use-case where YURLs are awkward, that I haven't been able to solve using *existing* software features. I have yet to even dip into the set of new software features that could be added.

In contrast, you are supporting a solution, DNSSEC that has serious design and deployment problems.

If you weigh the (disputed) UI issues of YURLs against the functionality failures of DNSSEC, I think you have to decide in favour of YURLs. As you said about the UI issue: "This problem is (obviously) soluble". DNSSEC still has outstanding and challenging problems to solve.

Consistency, not True Name Identification

[billstewart]

DNSSEC means that if somebody sends you IP packets at anonymous-coward-43.com, they can be cryptographically certain that they are using the IP address that the owner of anonymous-coward-6.com currently wants to advertise. Nobody had to mess with True Names here - this isn't solving the problem of verifying that Anonymous-coward-6.com belongs to John Smithy, who's the heavy guy with the slightly greying beard and the name anonymous-coward-43 tattooed on his arm who lives at 1500 Pennsylvania Ave and has Amex number 8811-432612-990433. This just means that when the Name Gods issue you the domain name anonymous-coward-43.com, you give them the admin key for the DNS as well as the money.

It's unfortunate that the ICANN Gods want to require everybody in the world who sells domain names to get a True Name and Subpoena Address and ICBM address and Retina Print in Triplicate in return for letting you use the name, but you knew that when you got the name. And if you're using a subdomain Number-6.anonymous-cowards.com, and the people who run anonymous-cowards.com will let anybody get a subdomain name without providing all that personal data, you're still protected - you've got a cert that anybody who wants your IP address can use to verify that it's really yours and not some proxy server at fbi.gov.

Decentralized Names in Plan 9

[billstewart]

You were probably just flaming, but the Plan 9 From Bell Labs operating systems folks did some good work on decentralized naming, which is their approach to things - See Pike & Weinberger's "The Hideous Name".

Thanks; ihnp4!arpanet!pobox!bill.stewart

Re:Decentralized Names in Plan 9

[Omnifarious]

I have no idea why I was moderated 'flamebait'. Thanks for pointing me at the paper, though I can only find the first page of it there.

I have my own system for decentralized naming I'm designing.

I still find my moderation of 'flamebait' to be very strange.

DNSSEC seems awful overblown

[Jordy]

Maybe I'm missing something, but DNSSEC seems to go a bit overboard when trying to fix the major flaw in DNS today, the ability to falsify records.

Now, there are two ways to falsify records that I know of.

The first is a cross-zone caching issue where a DNS response contains records for a zone it doesn't control. This is a rather simple problem to fix and requires no changes to the protocol bitstream itself (though changes are required to how the protocol is handled). It basically involves applying a trust zone model and tossing some previously useful records.

The second is an ID prediction attack where a response to a DNS query is falsified by guessing the ID number of the query made by the DNS server. With a decent ID generator, this becomes difficult and you have to brute force the thing basically making it a one-in-a-billion chance. This is still too high, so modifications to the protocol bitstream are required to enhance the size of the ID field or add a secondary one. It is possible to hack in this with minimal compatibility problems, but it wouldn't be pretty. Alternatively having the DNS server simply query twice or use TCP would accomplish the same thing, though that slows things down a bit.

I fail to see how the leap to a full blown cryptographic PKI was made. Sure, technically it may be better, but it is also complex, intrusive and adds only slightly more security.

Personally, I'm happier with 99.999% security with minimal work vs. 99.99999% security with a complete overhaul of the system.

Maybe I'm missing something.

Re:DNSSEC seems awful overblown

[Anonymous Coward]

Don't you also have to spoof the port numbers involved for the systems that are doing the DNS transaction? Obviously the source port will be 53 if you're trying to spoof an answer, but you won't know the destination port on the client unless he's talked to you recently.

client.1234 sends a request to server.53 with id 999. You have to forge a packet that claims to be from server.53, get the right id (999), and deliver it to client.1234, and you have to do it before the real packet gets there. Wouldn't you also have to answer the exact question which was being asked by the client?

The "additional info" cache poisoning DNS spoofing was fun to watch. I saw a number of hilarious things happen on various IRC networks. Guess what happens when you connect with a userid of * and spoof your domain name to be something like .*. Someone thought it was a good idea to do an automatic global K-line for cloning. So you spoof and clone. One word: BOOM.

"I accidentally ran over Walter today..."

Re:DNSSEC seems awful overblown

[amorsen]

DNS can be easily and efficiently changed on the wire. Cisco and other vendors sell boxes which are very good at it.

Re:DNSSEC seems awful overblown

[Fastolfe]

with a complete overhaul of the system.

That's kind of an exaggeration. There's no overhaul. It's just the addition of a couple of new record types and the added procedural step of signing your zone when you make changes to it. This can all be automated, if you trust the security of your automation. Requests and replies look the same as they always did unless you're DNSSEC-aware and make the extra step to ask for DNSSEC-related records.

Re:DNSSEC seems awful overblown

[Smaug the Golden]

There is a third way, man in the middle. The only fix that problem is by using crypto and being sure you bypass him during the initial key exchange. Then he is harmless.

It was mentioned in the article too :)

Re:DNSSEC seems awful overblown

[Jordy]

Yes, but if you are in the position to be compromised by a man-in-the-middle attack, DNS redirection is the least of your problems. Why bother redirecting when you already get all their traffic? :)

Re:DNSSEC seems awful overblown

[Smaug the Golden]

That is true, but DNSSEC, like a good root password or anything else, is just a step in the right direction. Not a magic bullet. DNSSEC with IPSEC would do what I said, but sadly that won't be for a while. You were right i guess :)

But still, keep that in mind. DNSSEC isn't amazing on it's own, but it is still a very important foundation for IPSEC. We need to move forward.

My original thesis work was how to do this right

[raph]

But after wrestling with it for a long time, I've concluded that it's a very difficult problem.

The proposal for the secure nameserver is here: http://www.levien.com/fc.ps

And the draft thesis version is here: http://www.levien.com/thesis/compact.pdf

I originally started investigating trust metrics as a way to identify trustworthy, credible sources of name->key binding data. The trust metrics turned out to be interesting and useful on their own, and a lot easier to deploy successfully. I think there's a lot of important research still to be done on the problem, but I'm not especially hopeful that it'll get done any time soon. For one, if your goal is to avoid single points of vulnerability, you have to build the service as a peer-to-peer network, and we're still struggling with the best way to design those, even for relatively simple tasks such as media piracy^Wsharing, much less anything mission-critical.

I do hope that anyone seriously looking into the question of secure name services at least skims my thesis drafts. There are some good ideas in there, and I have a funny feeling that people will be remaking all the same mistakes I did.

No more lynx

[Is every nickname ta]

This will be a lot of fun for lynx users.

The Real Slashdot!

[moncyb]

You call yourself a real /. reader? HA! Real /. readers custom code their own audio codecs and triple encrypt them. Only they are able to listen to their audio files! Let's see the RIAA stormtroopers steal my song "moncyb-In Soviet Russia-the Natasha chronicles.mecommieformat"!

The use and state of DNSSEC

[leto]

DNSSEC is long overdue. We not only need to secure our domains, we also need a secure placeholder for cryptographic information that's hierarchical. DNSSEC is the answer for that.

If you think DNSSEC is vapourware, your information is outdated. As I presented in various talks this year at BlackHat, DefCon and CCC this year, DNSSEC is ready to be deployed, and IS deployed.

We are currently running over 150 domains in DNSSEC, using bind9 and some perl tools written by RIPE. We are using this to accomplish IPsec Opportunistic Encryption, which means massive deployment of IPsec tunnels by using secured DNS information for key material.
Please see:

• The Dutch SECREG
  
• Opportunistic Encryption
  
• My OpenOffice or PowerPoint presentation on deplying DNSSEC and OE.
  

DNSSEC is not vapourware. It will happen, and you want it to happen. Think about VOIP using the ENUM dnszone without DNSSEC. Do you WANT your phonecalls to be hijacked?

DNSSEC doesn't obsolete SSL for web...

[bourne]

Conflict of Interest between SSL Key Certs and DNSSEC Key Certs - SSL keys certify something, usually about the "owner" of a given key, and let you have some trust in whoever possesses that key, often trusting a connection to a particular web server.

There is no conflict of interest, because the two serve different purposes.

Firstly, HTTPS (HTTP over SSL) is used for encryption as much as authentication. How many people check to see if the little lock symbol is there? Good. Now how many people check to see if the credentials associated with that lock match the company they're dealing with? Uh-oh. All you're getting, then, is encryption. DNSSEC will not provide the encryption to secure your credit card number, so the market for SSL certs is unaffected.

Secondly, DNSSEC aims at securing a different level. For many transactions that don't require SSL, it would be nice to have some assurance you're dealing with the right site. What if someone poisoned your DNS cache and redirected you to a fake Slashdot to gather your credentials and steal your account? How about sending mail, which is often handled completely under the hood by the MTAs involved without you, the mail client, having any say in checking on the routing?

Mind you, I tend to believe DJB knows what he's talking about when he criticizes DNSSEC, but the problem space is a valid one, and solving it won't conflict with SSL certificates.

Note on the government aspect

[Sycraft-fu]

They have largely gotten over that shit. It is now permissable to export higher grade encrypton. The new NITS approved encryption, AES, will go up to 256-bit keys and is fine for export, they just want to see what you are exporting first.

http://csrc.nist.gov/CryptoToolkit/aes/aesfact.h tm l
http://www.bxa.doc.gov/Encryption/

It's still not as simple as it should be (the government should mind their own bussiness) but it isn't illegal like it used to be.

You missed the draft!

[Anonymous Coward]

RFC for Smoke Signals already went up in smoke!

Revisionist history

[Medievalist]

URLs were never intended to be things that people could guess off the top of their heads based on what they were looking for - and they are really bad at it.

URLs (Uniform Resource Locators) are a web thing. Before URLs we used hostnames and domain names - that is, DNS and before that host tables. The web is a recent invention that many people regret... but I kind of like it myself.

But regardless of whether you are talking about URLs, hostnames, or domain names, you are still wrong. All these names were most definitely intended to be as intuitive as possible, because search engines weren't invented until after ICANN's greed and foolishness wrecked the consistency of the namespace. Stop trying to rewrite the past.

Re:Revisionist history

[Fastolfe]

Search engines existed long before ICANN.

The Internet started off as a network for the technical. Hostnames were fine then, as ways to identfy hosts on the Internet. There weren't many DNS domains and things were done properly in a hierarchy. URLs were invented with the web, but since everything was still targeted to the technically-oriented, this was fine. Geeks didn't mind passing URLs around, and generally they weren't needed if all of your content was reasonably compact such that things could be linked together. There wasn't a lot of content around that you couldn't find by following a couple of links from your local portal.

At this point, AOL is starting to shine and the marketing world revolves around AOL keywords. Companies paid for the privilege of having an AOL keyword map to content provided by them.

If you're of the impression that URLs (as they were used at the time) were created with the intent of slapping them on TV commercials (e.g. http://www.marketing.example.com/product-literatur e/new-widget-2000), you're mistaken. The intent of the designers, very early on, was to push for search engines to do the job of locating a piece of content, while the URI would identify that content.

It just turned out that search engines did a fairly shitty job of reliably sending users to the content they were hunting for. This, combined with the fact that there was no "authoritative" search engine designed to locate official URIs (or even DNS domains) for an organization, caused web browsers to start allowing abbreviated URIs to be used (making assumptions about the missing pieces), which allowed marketers to abbreviate URLs until the second-level domain itself was the only significant piece. We now have something akin to AOL's keywords, and suddenly everyone has to have example.com, example-widgets-2000.com, and every other product name, service mark and trade mark.com they can get their hands on, much to the annoyance of others that may have a very legitimate claim to them.

But instead of having AOL decide what was and was not a legitimate keyword for the organization requesting it, we have litigation successfully applying IP weight to DNS hostnames!

DNS was intended simply to provide a memorable, convenient label for an IP address. It's used for a bit more than that today, but as a locator service, DNS is inappropriate. We still need a better kind of search engine (perhaps a real directory) and need to stop relying on the fact that "example.com" will take me to the most widely-known company with "Example" in its name. It's a sucky state of affairs, and even if it works today in a pinch, the immense overhead required to make it that way is nothing other than a lawyer's dream.

Sendmail and Bind.

[anon1888]

Sendmail and Bind. The two programs, with the most fucked config files... completely archaic, bizarre config files. I've been using Unix since 93, and sendmail and bind have the most fucked config files compared to every other program I've configured.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Correction

[thinkerdreamer]

When I talked about government eroding I meant trust in government. I will stick with mine through thick and thin. If there is an invasion of privacy where I live, I will join the privacy activists. Others across the world like in China might view their governments differently when they announce computer chip ID cards for everyone. That is scary. Imagine the government tracking all your movements and having to display personal information wherever you go. One thing will lead to another and then . . . ,well, guess.

RFC1149's been done by Berlin LUG

[aegilops]

28 Apr '01 - 64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms

Aegilops

You're still pushing revisionist history

[Medievalist]

The organization that became ICANN certainly existed before the type of search engine you are talking about. WAIS is not a locator service for sites, it's a text search on steroids. You can fiddle with the definitions of "ICANN" and "search engine" for the purposes of argument, but it's not really germane to this discussion.

Your viewpoint is interesting, but biased to the point of inaccuracy. I was actually around when DNS was designed and implemented, and I remember quite clearly when the host table system was deprecated (because my VAX was using them at the time). I remember when Alta Vista and AOL were created, too; I even used Geo-based AOL on an 8088 XT once or twice.

DNS would work fine if we freed the namespace and allowed it to work as a distributed directory (which is what it would quickly become, if it weren't for the incompetence with which it is currently managed). ICANN's objections are pseudo-technical strawmen that serve only greed.

DNSSEC has some problems, as Dr. Berstein has frequently pointed out, but key distribution through DNS is at least as good an idea as Hesiod.

Re:You're still pushing revisionist history

[Fastolfe]

The organization that became ICANN certainly existed before the type of search engine you are talking about

Yes, in the form of a technical body, not a political one.

At one time, there was a transition from a technically-oriented Internet to a commercially-oriented one. The point where marketers started giving DNS hostnames IP weight is the point where DNS became inappropriate for IP-weighted naming. DNS came about from technical requirements and was intended to solve just those requirements, not to be an AOL keyword. That's the big issue here.

There's nothing "revisionist" about what I'm saying. Perhaps you're just misinterpreting or maybe I'm not making my point clearly enough.

It's all about the mindset of the users. Hostnames and URLs were fine for geeks. We respected the hierarchy of DNS and understood what the components of a URL meant. These things are not fine for Joe Public, which should be obvious when you watch the name grab for example.com, and the allowance for abbreviated URLs in the form of example.com. The public wants AOL keywords, and neither DNS nor URLs in general are fit for that purpose.

It almost sounds like you're suggesting that the DNS hierarchy be freed (like at the top level). If I'm understanding you, this would give anyone and everyone the ability to register any top-level domain they wanted. There have been lots of articles and messages discussing this and it all boils down to the fact that DNS would quickly become very top-heavy. Everyone would want their identifier to be at the top-level (making it just like an AOL keyword; no dot-com!). Litigation would abound and the root servers would have to be beefed up several orders of magnitude. I don't see how this would solve anything. But perhaps I am misinterpreting.

In my opinion, the best solution to this problem is to give the public a simple way to associate common names and marks to their official Internet entities. LDAP and X.500 would do this splendidly. At least there, a search for "Apple" will give you a better selection than the general assumption that a company named "Apple" is at "apple.com". Keep DNS out of the public's eyes and ICANN's politics and DNS-based litigation will disappear.

DNS issues

[bowdog]

Is DNS ok now? http://average.matrix.net/Daily/markP.html

Common names are what advertisements say they are

[Medievalist]

There's nothing "revisionist" about what I'm saying. Perhaps you're just misinterpreting or maybe I'm not making my point clearly enough.

Since you are being so reasonable, I'll tone down the inflammatory rhetoric... but I still think your capsule descriptions of Internet history (like "At one time, there was a transition from a technically-oriented Internet to a commercially-oriented one") are very misleading; the problems encountered during the period you mention were primarily due to the influx of new users (most of whom were not marketers or businessmen, but rather college students and scientists from non-technical fields) and the explosion of public interest (which was not due to commercialism but rather to the accumulation of a critical mass of information in forms useable without extensive prior training).

As for freeing the namespace, the objections you raise are the same ones ICANN trots out (well, except you didn't mention their favorite "without central control nothing could possibly work!"). I'll trot out the usual responses, although you've probably heard them already.

If I'm understanding you, this would give anyone and everyone the ability to register any top-level domain they wanted.

No. To have a top-level domain, you would have to be demonstrably able to reliably run the top-level nameservers for that domain, able to arbitrate disputes within that namespace, and willing to provide namespace at lower levels for a reasonable fee. It should be obvious that most top-level domains (such as, for example, .pepsi) would not generate enough income through name sales to support themselves; so simple economics would suffice (in the long run) to weed out non-viable top-level domains.

Litigation would abound...

Creating a market-based model such as the one I've mentioned would not be any more complex, litiginous, or subject to incompetence than the current system.

Think about how the nameservers are currently funded. Terp.umd.edu for example, or the Vixie nameserver. And does Paul Vixie go a single day without a lawsuit being at least threatened?

...and the root servers would have to be beefed up several orders of magnitude.

Not so. Several people have gone so far as to predict that the total number of names would decrease if the namespace was freed. Think about it; the George W. Bush campaign bought over 200 domain names, (including bushblows.com and bushsux.com, incidentally) and the average multinational corporation buys three. In a wide-open namespace, there would be no point in doing this, and companies would buy only one name and spend their money advertising it in meatspace. You might see a decrease in the total size of the DNS namespace along the order of 50% or more!

You would also see unpredictable morphing of the namespace to reflect global human economic and cultural patterns - something like ".blitzork" becoming the most popular domain, or ".lovesjesus" or whatever. That type of emergent behaviour alone would be worth the price of admission.

In my opinion, the best solution to this problem is to give the public a simple way to associate common names and marks to their official Internet entities. LDAP and X.500 would do this splendidly.

I'm afraid they won't, though. The only LDAP server that would scale to the degree required would be Novell's NDS, and I personally do not consider it stable enough for this purpose (that's just my opinion, though - I think Gary Porter at UKy might disagree).

Oddly enough, I'm at work on Saturn's Day because I am working on LDAP replication problems in a ring of boxes (linux, HP-UX, and Sun) that authenticate using LDAP (the master server runs OpenLDAP). I don't think LDAP is anywhere near as robust as DNS, and in current incarnations it's certainly just as difficult to secure properly.

Re:Common names are what advertisements say they a

[Fastolfe]

the same ones ICANN trots out (well, except you didn't mention their favorite "without central control nothing could possibly work!") ...because my arguments are independent from theirs.

It should be obvious that most top-level domains (such as, for example, .pepsi) would not generate enough income through name sales to support themselves; so simple economics would suffice (in the long run) to weed out non-viable top-level domains.

I'm not sure I understand how you're coming to this conclusion. Your .pepsi example is a good one. Are you suggesting that ICANN (or whoever their successor is) have a requirement that a TLD owner re-sell? What expenses do you think a TLD owner has at this point that a major corporation doesn't already have funding for?

If Pepsi had the opportunity to register a 'pepsi' top-level domain, even if they were "required" to resell underneath 'pepsi', throwing down a few million dollars or so for hardware and operating expenses for that TLD is nothing compared to what they throw at online expenses.

So hell yah, I'd buy some shiny new servers, drop the 'pepsi' TLD on them, and if required, start up a marketing campaign to give away joe-smith.loves.pepsi hostnames.

What company wouldn't?

What expenses do you think they would have that would make this unattractive or impractical?

Not so. Several people have gone so far as to predict that the total number of names would decrease if the namespace was freed.

You're looking at the gtld-servers, not the root-servers. The root servers today just answer for the top-level domains. These are a static list (today), and those servers can be optimized to just spewing out those results. By "freeing" the top-level namespace, every subsidiary of every company is going to want one, and even if a few are weeded out because they don't have the infrastructure (which I'm not sure will ever be the case, since there's a lot of money to be made from this idea), this will "fatten" DNS at the root level, even if it thins DNS out at the second-level.

Basically, the DNS hierarchy will become top-heavy. You've got to shift resources around to accomodate that shift in load, away from the gtld-servers and towards the root-servers.

But it does seem logical that overall, the number of registered names would decrease. As more TLDs come available, corporations begin to realize that they're not going to be able to buy every name that's going to be remotely similar to their own. The ".com" craze will wither as www.example.com stops being the standard locator mechanism.

Assuming something else has stepped in to be that locator.

The only LDAP server that would scale to the degree

LDAP (like X.500 and DNS) does support delegation, though. You don't need to set up one monolithic LDAP farm here, just one big enough to cover your organization. Get your locality to set up delegation properly and it's just as distributed as DNS.

The big scalability problems you see with DNS revolve around that silly second-level name, where everyone and their mother has to own every conceivable name dot-com. Once that goes away in favor of a more reasonable hierarchy, scalability becomes easier as things become more distributed.

But you still could be right; LDAP or X.500 might not be the appropriate thing here. But DNS (at least in its current form) isn't either.