DNSSEC: Good Enough? 181
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)."
dan bernstein's position on this (Score:5, Informative)
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 (Score:5, Interesting)
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 (Score:1)
Re:dan bernstein's position on this (Score:1)
Re:dan bernstein's position on this (Score:1)
Hear, hear.
Re:dan bernstein's position on this (Score:2, Interesting)
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
Re:dan bernstein's position on this (Score:5, Insightful)
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 (Score:3, Interesting)
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 Q
Re:dan bernstein's position on this (Score:3, Insightful)
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 ty
Re:dan bernstein's position on this (Score:3, Insightful)
Decentralized authentication (Score:2, Interesting)
Since you're willing to give Bernstein's solution a fair hearing, I suggest you also check out YURLs [waterken.com]. 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 [waterken.com].
Tyler
Re:dan bernstein's position on this (Score:2)
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 (Score:2)
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:
becomes this:
if your ~/.ssh/config contains
That notwithstanding, I agree with your points. (I often find myself disliking DJB's approaches to things, though he does certainly write good code.)
Re:dan bernstein's position on this (Score:2)
Until the user moves to a different host. Why do people *always* forget this?
Re:dan bernstein's position on this (Score:2)
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 (Score:2)
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.
Bookmark file keywords (Score:2, Informative)
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 [waterken.com] work.
Re:Bookmark file keywords (Score:2)
I think you're kind of missing the point.
Re:Bookmark file keywords (Score:2)
[ 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 vers
Re:Bookmark file keywords (Score:2)
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 [whmag.com]; The WWW was developed in 1990 [w3.org]. That right there i
Re:dan bernstein's position on this (Score:3, Funny)
Notwithstanding the overwhelming indications to the contary, yes.
Re:dan bernstein's position on this (Score:2, Insightful)
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 (Score:2)
Not if they step up the production and distribution of CueCat wands! Man, those things are great!
Re:dan bernstein's position on this (Score:2)
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
Re:dan bernstein's position on this (Score:4, Insightful)
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 (Score:3, Funny)
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 [iso.org].
DNSSEC needn't be a panacea to be useful. (Score:4, Interesting)
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: (Score:3)
Re:DNSSEC needn't be a panacea to be useful. (Score:2)
Re: (Score:2)
Re:DNSSEC needn't be a panacea to be useful. (Score:2)
Re:DNSSEC needn't be a panacea to be useful. (Score:3, Informative)
A browser key costs $250,000 per year, and $250,000 up front for audi
Cynicism over recommendation (Score:4, Insightful)
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 (Score:2)
That's an unstable situation.
There should be no "top."
DNSSEC: Good Enough? (Score:5, Funny)
Re:DNSSEC: Good Enough? (Score:2, Funny)
No, even most
Re:DNSSEC: Good Enough? (Score:2)
Ogg Vorbis? Real /. readers only encode in FLAC [sourceforge.net]..
You young whippersnappers! (Score:4, Funny)
Re:You young whippersnappers! (Score:2, Funny)
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! (Score:2)
Especially since history indicates that the standard retry time was seven days long [biblegateway.com]. 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! (Score:2)
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. :)
Re:You young whippersnappers! (Score:3, Informative)
Re:You young whippersnappers! (Score:2)
Not gone, either. I still have it and use it occasionally.
BTW, two words: "host table". I remember....
Please site the RFCs! (Score:4, Funny)
Re:Please site the RFCs! (Score:5, Funny)
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:You young whippersnappers! (Score:4, Funny)
Dammit.. too many bird jokes.. I know I'm running afowl of the etiquette.. Hell with it, I'm not chicken.
-B
Why would we want to be identified? (Score:3, Insightful)
Is it 1984? (Score:2, Insightful)
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
Consistency, not True Name Identification (Score:4, Interesting)
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.
Blame Game (Score:2, Insightful)
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 addre
Ripe Training For DNSSEC (Score:5, Informative)
It seems RIPE [ripe.net] have a One Day Introduction Course [ripe.net] 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 (Score:4, Interesting)
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.
Then there's Bernstein (Score:5, Interesting)
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.
Last message (Score:1, Funny)
First, solve this ... (Score:5, Interesting)
"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 ... (Score:1)
How do you spell his name ? (Score:1)
Re:How do you spell his name ? (Score:3, Funny)
I think project IRIS from MIT is more interesting (Score:5, Informative)
You can find it at IRIS
Re:I think project IRIS from MIT is more interesti (Score:3, Informative)
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/unauth
Why? (Score:1, Interesting)
Re:Why? (Score:4, Informative)
Trusted computing... (Score:2, Interesting)
ICANN (Score:2)
Let's see PGP applied here (Score:3, Interesting)
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 (Score:2)
I don't oppose that in theory, but my sites have a lot of dynamic content and I'd have the choice of:
What about those of us not running our own servers? I could
Re:Let's see PGP applied here (Score:2)
Other aspects of DNSSEC (Score:5, Informative)
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 -
Re:Other aspects of DNSSEC (Score:4, Informative)
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.
The problem is that DNS is trying to be Google (Score:2)
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
Re:The problem is that DNS is trying to be Google (Score:2)
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
Re:The problem is that DNS is trying to be Google (Score:2)
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, I
Revisionist history (Score:2)
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 w
Re:Revisionist history (Score:2)
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 li
Re:You're still pushing revisionist history (Score:2)
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
Re:Common names are what advertisements say they a (Score:2)
It should be obvious that most top-level domains (such as, for example,
I'm not sure I understand how you're coming to this conclusion. Your
It was going to be called something else. (Score:2)
Political Problems with DNSSEC (Score:5, Interesting)
Re:Political Problems with DNSSEC (Score:2)
You can use truted-key statements to create "Secure entry points". You can trust
DNSSEC doesn't obsolete SSL for web... (Score:2)
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
Note on the government aspect (Score:3, Informative)
http://csrc.nist.gov/CryptoToolkit/aes/aesfact.
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.
Re:Political Problems with DNSSEC (Score:2)
Isn't that what the registry is for?
dnssec, how about authenticated email reply-to? (Score:3, Interesting)
Re:dnssec, how about authenticated email reply-to? (Score:2)
dave
DNSSEC mini HOWTO (Score:4, Informative)
DNSSEC seems awful overblown (Score:4, Interesting)
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 (Score:2)
Re:DNSSEC seems awful overblown (Score:2)
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 (Score:2)
My original thesis work was how to do this right (Score:4, Informative)
The proposal for the secure nameserver is here: http://www.levien.com/fc.ps [levien.com]
And the draft thesis version is here: http://www.levien.com/thesis/compact.pdf [levien.com]
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.
The use and state of DNSSEC (Score:5, Informative)
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:
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?
Re:DNSSEC? (Score:2, Informative)
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? (Score:1)
here is the link to that story [slashdot.org]
Re:DNSSEC and extending protocols (Score:5, Interesting)
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).
Hey, you're right! (Score:2)
Re:DNSSEC? (Score:2)
OK here is a /. MS bash from a bash user. (Score:3, Funny)
Re:Security Issues? (Score:5, Informative)
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...
Decentralized Names in Plan 9 (Score:2)
Thanks; ihnp4!arpanet!pobox!bill.stewart
Re:Decentralized Names in Plan 9 (Score:2)
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.