Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Encryption The Internet

DNSSEC: Good Enough? 181

Posted by timothy from the those-darn-numbers dept.
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)."
This discussion has been archived. No new comments can be posted.

DNSSEC: Good Enough? More

DNSSEC: Good Enough?

Comments Filter:

  • dan bernstein's position on this (Score:5, Informative)

    by tmu ( 107089 ) <todd-slashdot@renesys . c om> on Tuesday August 19, 2003 @09:19PM (#6740335) Homepage
    People interested in this issue should see dan bernstein's position [cr.yp.to] 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 (Score:5, Interesting)

      by macshit ( 157376 ) <snogglethorpe AT gmail DOT com> on Tuesday August 19, 2003 @09:38PM (#6740458) Homepage
      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).
      • 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.
        • 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.

        • 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

      • Re:dan bernstein's position on this (Score:5, Insightful)

        by gregmac ( 629064 ) on Tuesday August 19, 2003 @10:27PM (#6740733) Homepage
        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.

        • 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

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

        • 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

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

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

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

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

        • 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 i
        • 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 [whmag.com]; The WWW was developed in 1990 [w3.org]. That right there i
      • >> Is he living on the same earth we do?

        Notwithstanding the overwhelming indications to the contary, yes.
      • 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 ?
      • 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!

      • 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

    • Re:dan bernstein's position on this (Score:4, Insightful)

      by Anonymous Coward on Tuesday August 19, 2003 @09:41PM (#6740472)
      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.

    • DNSSEC needn't be a panacea to be useful. (Score:4, Interesting)

      by mellon ( 7048 ) * on Tuesday August 19, 2003 @10:05PM (#6740624) Homepage
      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.
      • Comment removed based on user account deletion
        • 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. :'(
      • 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 audi

  • Cynicism over recommendation (Score:4, Insightful)

    by Anonymous Coward on Tuesday August 19, 2003 @09:21PM (#6740341)
    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.

  • DNSSEC: Good Enough? (Score:5, Funny)

    by Anonymous Coward on Tuesday August 19, 2003 @09:23PM (#6740364)
    Nothing is ever good enough for /. readers, well except for Ogg Vorbis.

  • You young whippersnappers! (Score:4, Funny)

    by Anonymous Coward on Tuesday August 19, 2003 @09:24PM (#6740372)
    '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...
    • "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.

      • 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 [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....
        • "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. :)

    • Back when we didn't have DNS, pathalias was our dear friend. Gone, but not forgotten!
      • "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....

    • Please site the RFCs! (Score:4, Funny)

      by El ( 94934 ) on Tuesday August 19, 2003 @09:57PM (#6740579)
      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! (Score:5, Funny)

        by Odin's Raven ( 145278 ) on Tuesday August 19, 2003 @11:05PM (#6740909)
        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:You young whippersnappers! (Score:4, Funny)

      by beacher ( 82033 ) on Tuesday August 19, 2003 @10:09PM (#6740647) Homepage
      Oh.... I've always wanted to meet someone that's had a successful CPIP implementation that's rfc 1149 compliant [ietf.org]..... 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

  • Why would we want to be identified? (Score:3, Insightful)

    by Anonymous Coward on Tuesday August 19, 2003 @09:24PM (#6740373)
    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?

    • Is it 1984? (Score:2, Insightful)

      by thinkerdreamer ( 682437 )
      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

    • Consistency, not True Name Identification (Score:4, Interesting)

      by billstewart ( 78916 ) on Wednesday August 20, 2003 @12:39AM (#6741385) Journal
      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.

  • Blame Game (Score:2, Insightful)

    by PktLoss ( 647983 )
    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 addre

  • Ripe Training For DNSSEC (Score:5, Informative)

    by thriemus ( 514728 ) * on Tuesday August 19, 2003 @09:25PM (#6740376)

    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)

    by SlashCrunchPop ( 699733 ) on Tuesday August 19, 2003 @09:29PM (#6740393)

    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)

    by crucini ( 98210 ) on Tuesday August 19, 2003 @09:29PM (#6740397)
    Of course, no discussion of DNSSEC would be complete without Bernstein's comments. [cr.yp.to] And here are the slides from his talk [cr.yp.to] 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.

    • Last message (Score:1, Funny)

      by 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 [goatse.cx]. 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 poss

  • First, solve this ... (Score:5, Interesting)

    by Anonymous Coward on Tuesday August 19, 2003 @09:31PM (#6740410)
    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_
  • 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.

  • I think project IRIS from MIT is more interesting (Score:5, Informative)

    by hansreiser ( 6963 ) on Tuesday August 19, 2003 @09:50PM (#6740537) Homepage
    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
    • 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/unauth

  • Why? (Score:1, Interesting)

    by 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? (Score:4, Informative)

      by El ( 94934 ) on Tuesday August 19, 2003 @10:07PM (#6740636)
      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?
  • 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.

  • ICANN (Score:2)

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

  • Let's see PGP applied here (Score:3, Interesting)

    by Anonymous Coward on Tuesday August 19, 2003 @10:38PM (#6740780)
    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?
    • 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

  • Other aspects of DNSSEC (Score:5, Informative)

    by karl.auerbach ( 157250 ) on Tuesday August 19, 2003 @10:41PM (#6740790) Homepage
    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 (Score:4, Informative)

      by amorsen ( 7485 ) <benny+slashdot@amorsen.dk> on Wednesday August 20, 2003 @03:08AM (#6741929)
      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.

  • 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

    • "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
      • 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, I

    • 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 w

      • 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 li
  • It was going to be called DNSSEX, until the developers realized it might be mistaken for something else.

  • Political Problems with DNSSEC (Score:5, Interesting)

    by billstewart ( 78916 ) on Tuesday August 19, 2003 @11:08PM (#6740924) Journal
    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
    • 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.

    • 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

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

  • DNSSEC mini HOWTO (Score:4, Informative)

    by bobbozzo ( 622815 ) on Wednesday August 20, 2003 @12:01AM (#6741215)
    Paul Wouters from the FreeSWAN project spoke at DefCon 11 on DNSSEC... he has some materials online at: http://www.xtdnet.nl/paul/dnssec/ [xtdnet.nl]

  • DNSSEC seems awful overblown (Score:4, Interesting)

    by Jordy ( 440 ) <jordan&snocap,com> on Wednesday August 20, 2003 @12:47AM (#6741414) Homepage
    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.
    • DNS can be easily and efficiently changed on the wire. Cisco and other vendors sell boxes which are very good at it.
    • 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.

  • My original thesis work was how to do this right (Score:4, Informative)

    by raph ( 3148 ) on Wednesday August 20, 2003 @12:47AM (#6741418) Homepage
    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 [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)

    by leto ( 8058 ) on Wednesday August 20, 2003 @04:50AM (#6742186) Homepage
    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:


    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?

Slashdot Top Deals

According to the latest official figures, 43% of all statistics are totally worthless.

Close