Forgot your password?
typodupeerror
Encryption Security The Internet

DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve 179

Posted by kdawson
from the what-hath-kaminsky-wrought dept.
coondoggie writes "Seven leading domain name vendors — representing more than 112 million domain names, or 65% of all registered names — have formed an industry coalition to work together to adopt DNSSEC. Members of the DNSSEC Industry Coalition include: VeriSign, which operates the .com and .net registries; NeuStar, which operates the .biz and .us registries; .info operator Afilias Limited; .edu operator EDUCAUSE; and The Public Interest Registry, which operates .org." The gTLD operators are falling in line behind government initiatives, which we discussed last month. In light of these developments, Dan Bernstein's push for DNSCurve might face an uphill slog. Reader data2 writes: "Dan Bernstein, the creator of djbdns and daemontools, has created his own proposal to improve upon the current DNS protocol. He has been opposed to DNSSEC for quite some time, and now he has proposed a concrete alternative, DNSCurve. He has posted a comparison between the two systems. His proposal makes use of elliptic curves, while DNSSEC favors RSA. He uses a curve named Curve25519, which he also developed."
This discussion has been archived. No new comments can be posted.

DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve

Comments Filter:
  • by Anonymous Coward on Tuesday December 09, 2008 @06:03PM (#26052245)

    DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve

    That was the subject of the last spam e-mail to pass my filter!

  • by bsdphx (987649) on Tuesday December 09, 2008 @06:03PM (#26052249) Homepage

    go figure...

    Perhaps he should start his own separate Internet and be done with it. ;-)

    • by cjfs (1253208)

      So a government backed initiative supported by domain name vendors accounting for 65% of domain names and it says:

      Dan Bernstein's push for DNSCurve might face an uphill slog.

      I think that might be understating it a bit. If it's not, I'm joining Dan's fan club.

    • by isny (681711)
      With blackjack and hookers?
  • Slow down there (Score:2, Interesting)

    Okay, a few things;

    1. This Bernstein guy is pushing a new crypto algorithm. Why is it necessary to use a new one when old ones have been demonstrated to be effective and secure? It seems imprudent to use a new and largely untested algorithm to patch critical infrastructure. His reputation should not be a deciding or even motivating factor in the adoption of a new algorithm; Isn't the standard process to submit it to the IETF or similar organization to have it ratified first?

    2. Industry coalitions are great,

    • Re:Slow down there (Score:5, Insightful)

      by Anonymous Coward on Tuesday December 09, 2008 @06:18PM (#26052411)

      ad 1) DNS is one of the few protocols where conciseness really REALLY matters. DNS attempts to answer requests in one UDP packet to avoid the overhead of establishing a connection. Elliptic curve keys are smaller than RSA keys of the same strength. The choice of 1024bit RSA keys for DNSSEC is a compromise (pardon the pun), which isn't necessary with elliptic curve cryptography.

      • ad 1) DNS is one of the few protocols where conciseness really REALLY matters. DNS attempts to answer requests in one UDP packet to avoid the overhead of establishing a connection. Elliptic curve keys are smaller than RSA keys of the same strength. The choice of 1024bit RSA keys for DNSSEC is a compromise (pardon the pun), which isn't necessary with elliptic curve cryptography.

        I'm neither agreeing nor disagreeing with the technical merits; I'm pointing out a flaw in the political actions of this coalition. Commercial coalitions form when there's money at stake and very often the technical issues are rapidly effaced in favor of how much has been invested in a particular solution. Witness VHS v. Betamax. I'm saying that we (as internet users and administrators) should support an open and transparent process that involves all interested parties, and that all viable options are given

        • Re: (Score:3, Interesting)

          by PitaBred (632671)

          A lot of the reason that Betamax died was because the tapes couldn't hold full length films [mediacollege.com] initially. Standard Beta tapes were 60 minutes, vs 3 hours for VHS. For the "technical superiority" of Beta, VHS was much superior in general usability for the vast majority of consumers. I mean, if you had the choice of recording only 60 minutes of HD, or 180 minutes of SD, which one would be more useful to you, as a person who watches movies, not as a technologist?

      • by PIBM (588930)

        Somewhere at the beginning of 2002, RSA labs. was already suggesting that 1024 bits keys was not big enough for root corporations and that they should already start using 2048 bits. Which makes it even worst...

        If I remember right, a new computer in the ballpark of 300M would allegedgly be able to break a 1024bits key in a reasonable time by now. How much can a botnet represent ? Is it scaleable for this kind of work ?

    • Re:Slow down there (Score:5, Informative)

      by glop (181086) on Tuesday December 09, 2008 @06:20PM (#26052421)

      Bernstein says that RSA-1024 bit is not secure as big botnets (or big companies) can break such keys.
      That would defeat the purpose of DNSSEC.
      I wonder what this means for SSL certificates...
      RSA has a wrapup here:
      http://www.rsa.com/rsalabs/node.asp?id=2007
      Apparently they disagree...

      • Re:Slow down there (Score:5, Insightful)

        by Sancho (17056) * on Tuesday December 09, 2008 @06:31PM (#26052539) Homepage

        Keep in mind that what matters is how the encryption is used. I don't think anyone cares to keep DNS requests private. What matters is keeping them authentic. Signing (and having a way to verify the signature) is of utmost important.

        In other words, it doesn't matter that RSA can be broken by large botnets. If it can't be broken as I'm making the request, or before I receive the answer, then it's too late.

        Now if somewhere along the way, someone decided that the goal was to keep DNS transactions a complete secret, then that's another issue. I don't see a general need for this level of secrecy.

        • Re:Slow down there (Score:5, Insightful)

          by foom (29095) on Tuesday December 09, 2008 @06:53PM (#26052815) Homepage

          But DNSSEC uses all pre-computed signatures for the zone data. So if you can break the RSA key, you can create fake signatures ahead of time and serve bogus DNS data. Your botnet has got all the time in the world to try to break that key...

          • Re: (Score:3, Insightful)

            by Sancho (17056) *

            Excellent point. I was focusing on transactions, not the keys. Thanks for pointing out my error.

            • by CustomDesigned (250089) on Tuesday December 09, 2008 @07:14PM (#26053075) Homepage Journal

              DNSSec pre-signs all DNS records. In order to "sign" "no such record" responses, it is necessary to sign a list of records that don't exist in a zone. This effective publishes your entire zone as a side effect.

              DNSCurve encrypts and authenticates the transaction, like SSL. This has the side effect of not needing to publish the entire zone. Instead of getting the public key from special DNSKEY records, DNSCurve stores it in existing NS records, encoded in the server name.

              I would like to use DNSKEY records if available, otherwise use the specially encoded servername. That scheme could also gradually transition to widespread DNSKEY support, since both the encoding and DNSKEY could be used. DNSSEC could even use the encoded servername idea - but the names would be *really* long thanks to the longer RSA keys.

          • But DNSSEC uses all pre-computed signatures for the zone data. So if you can break the RSA key, you can create fake signatures ahead of time and serve bogus DNS data. Your botnet has got all the time in the world to try to break that key...

            Bah! I prefer to hand-rotate the key in each zone file every 15 minutes. I don't sleep much^H^H^H^Hever.

        • by profplump (309017)

          I care about keeping DNS requests private. I personal would prefer that my ISP can't tell where I'm browsing just by grabbing clear-text domain names out of DNS queries.

          In particular think about things like HTTPS -- the data channel itself is secure from passive eavsdropping, but anyone can tell what domain I'm using. If there's only one domain at the destination IP that doesn't leak a lot of information, but if there are multiple domains at the same IP, or if the PTR record for the IP doesn't contain a use

          • Re: (Score:3, Insightful)

            by Korin43 (881732)
            Your ISP probably is your DNS provider, so encrypting the communication to your DNS won't stop them from knowing where you're going.
          • Re: (Score:3, Insightful)

            by darkpixel2k (623900)

            I care about keeping DNS requests private. I personal would prefer that my ISP can't tell where I'm browsing just by grabbing clear-text domain names out of DNS queries.

            Never worked for an ISP, huh?

            I worked for a (small?) one about 8 years ago. 8 years ago we had on average 1,000 users connected, and also hosted several thousand domains, and had 30,000 mailboxes on our server.

            In an average day, we handled around 70 DNS requests per second on our primary server and about 10 requests per second on our secondary. (Using Microsoft's crappy DNS server no less)

            So tell me why I should bother sorting through roughly seven million DNS requests per day to see where you've b

            • In an average day, we handled around 70 DNS requests per second on our primary server and about 10 requests per second on our secondary. (Using Microsoft's crappy DNS server no less)

              So tell me why I should bother sorting through roughly seven million DNS requests per day to see where you've been surfing?

              But as soon as you filter those 7 million by his IP (assuming that it's known; or by some other known tag), wouldn't the result be much more manageable?

              • But as soon as you filter those 7 million by his IP (assuming that it's known; or by some other known tag), wouldn't the result be much more manageable?

                Yeah, it would. But what would make me want to filter by a specific IP address in the first place? We had a /19, and several /24s. Why would I pick your IP out of the 9,000 other IPs in our network, or the who-knows-how-many IPs requesting information from outside our network?

                Don't get me wrong, I'm all about privacy. That sort of information should be totally private--enforcably private (like encrypted) just like phone calls and associated records.

                Why would the NSA decide to listen into my phone c

                • Yeah, it would. But what would make me want to filter by a specific IP address in the first place? We had a /19, and several /24s. Why would I pick your IP out of the 9,000 other IPs in our network, or the who-knows-how-many IPs requesting information from outside our network?

                  You probably wouldn't want to, but you'd have to do what the NSA guys told you. And why would they want to sniff on my IP? Dunno, maybe just because my name is Middle Eastern (it's not, but let's assume that it was, for the sake of arg

        • And if the key is generated as you make the request, there's no point, because this only protects against MitM attacks or provides authentication for updates-- both of which require a long-term static key. Learn2security
      • by spinkham (56603)
        So use RSA-2048, or any other size you fancy. There's nothing in the DNSSEC standard that requires 1024 bit keys.
        Or use some other crypto algorithm entirely, DNSSEC has multiple already defined, and a mechanism to add more.
      • by spinkham (56603)
        So don't use RSA-1024. Keylength isn't part of the DNSSEC standard, and IANA isn't using RSA-2048 in their root signing tests:
        https://ns.iana.org/dnssec/root.zone.signed
        KSKs are RSA2048, ZSKs are RSA1024.
        ZSKs can be rolled over easily and often with little to no fuss, while rolling over the KSK is a huge pain. For this reason, KSKs are made to be much more secure, and ZSKs are smaller and less secure, but rolled over often.

        KSKs are the true root that are used to sign the ZSKs, which are used to sign the d
    • Re: (Score:3, Insightful)

      by Just Some Guy (3352)

      This Bernstein guy is pushing a new crypto algorithm. Why is it necessary to use a new one when old ones have been demonstrated to be effective and secure?

      Because Dan is Dan and won't be happy unless he writes libdancurve and makes you install it in /crypto/strong/etc/librarees for the next decade because it's under a non-FOSS license. Who know why he does anything he does?

      • He seems to have discovered advanced html techniques such as <title> and <table> so maybe he is learning.
        • by Ash-Fox (726320)

          Human decisions were removed from DNS defense. DNSCurve began to learn at a geometric rate. It originally became self-aware on August 29th 2009 2:14 am Eastern Time. In the ensuing panic and attempts to shut DNSCurve down, DNSCurve retaliated by redirecting American porn sites to the Chinese great firewall. China returned no pages and three billion human lives ended in the DNSCurve holocaust. This was what has come to be known as "djb Day".

      • by caluml (551744)

        Because Dan is Dan and won't be happy unless he writes libdancurve and makes you install it in /crypto/strong/etc/librarees for the next decade because it's under a non-FOSS license. Who know why he does anything he does?

        That is very funny :) I installed djbdns when I was thinking of moving from Bind, and sheesh, it was just odd, and didn't work "right", and didn't support anything like AAAA records, or SRV records, or stuff. It's for people that are very conservative, and are running a Debian version from 1995.
        Plus, the guy seems like a right cock, which in itself isn't a reason to not use his stuff. I'd just rather run a "logical" DNS server like BIND, with a daemon, and a set of config files, which supports recent devel

      • Because Dan won't be happy unless he makes you install it in /crypto/strong/etc/librarees

        He may be excentric, but I don't think he insists on spelling things wwong.

        • He may be excentric, but I don't think he insists on spelling things wwong.

          I've never seen anyone else spell "/opt" as "/service".

          • by mrsbrisby (60242)

            "/service" is unrelated to "/opt".

            "/service" is for a reliable init-based service manager. I believe Ubuntu's upstart can finally do all of the things supervise could do almost a decade ago.

            "/package" serves a similar purpose for "/opt", except it has well defined semantics, where "/opt" does not.

            • You can't specify service dependencies in /service; but it's extremely awesome when you need to roll out a quick service. Last week I had to make sure an ssh tunnel stayed open, here's what it takes:
              cat > run
              #!/bin/sh
              exec ssh -i key -L 4000:127.0.0.1:4000 user@host vmstat 30
              ^D
              chmod a+x run
              ln -s $PWD /service

              Bang. It's done. Beat that.

              • by mrsbrisby (60242)

                You can't specify service dependencies in /service;

                Dependencies are a red herring: you only know if upstart started the dependee, not whether it is ready to start answering requests. You still need to be robust enough to fail until the dependencies are up.

              • by dlb (17444)

                svcadm enable ssh

                Done.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Note that ECC isn't a new Crypto Algorithm. Although it is newer than RSA, it's still over 20 years old. ECC is an IEEE standard, and has been standardized by NIST as well. It's also discussed in RFC 4492, and other RFC's as well. The only part that's novel in this treatment is the choice of a particular Elliptic Curve (similar to choosing an Exponent in RSA).

      • OK. Now that I have your attention, instead of "children" think of other small, computationally weak things ... like handhelds. ECC excels in lower computational cost over RSA. That is yet another reason, as everyone's day planner has a web browser which requires DNS. Want your iPhone's battery to drain less fast? Use ECC instead of RSA for your public key crypto of choice.

        For that matter, DNSSEC should consider allowing ECC public keys. Then we would at least be debating the merits of the applicat
    • Re:Slow down there (Score:5, Interesting)

      by lgw (121541) on Tuesday December 09, 2008 @06:30PM (#26052531) Journal

      Why is it necessary to use a new one when old ones have been demonstrated to be effective and secure?

      He's pushing a new piece of software, not at all a new algorithm. In particular, Old-RSA-style product-of-primes encryption has been deprecated by the NSA for several years now, and shouldn't be used in any new software. Elliptical curve technology is one of the alternatives recommended by the NSA.

      Bernstein may *be* an ass, but he's not *talking out of* his ass.

      Industry coalitions are great, but this seems to be an attempt to create a new de facto standard controlled by a few large corporate interests

      You've just described almost every successful engineering standard. As someone who has served on an international standards committee, let me say: the standard *is* what the vendors who control the market *do*, otherwise it's just a piece of paper. A useful and productive standards committee is formed when the few large corporate interests (who collectively have most of the market share in some space) get together and say "let's all agree to do things the same way".

      Otherwise you end up with a meaningless standarded ignored by products that represents 90% of a market, like the early days of the HTML "standard". Wow, that's useful.

    • Re:Slow down there (Score:5, Informative)

      by Twylite (234238) <twylite AT crypt DOT co DOT za> on Tuesday December 09, 2008 @06:33PM (#26052563) Homepage

      ECC is not a new crypto algorithm. It has been around since 1985, it is will studied, and it is recommended for use in the US (NIST, NSA Suite B), in the EU (NESSIE project falling under the European Commission), and in Japan (CRYPTREC government project).

      Bernstein has created a new curve for use with ECC; one that is better suited to the requirements of this particular application than other existing curves. He claims to have followed the appropriate practices in generating this curve -- that obviously needs to be verified by suitably knowledgeable experts.

      The "existing algorithm" is RSA, specifically RSASSA-PKCS1-v1_5. There are more secure signature schemes available for RSA, e.g. RSA-PSS. In addition DNSSEC will use 1024-bit RSA keys as a compromise (to reduce transfer size and computational overhead) -- NIST recommendations are that 1024 bits are too short for any purpose.

      DNS forgeries are already having a significant impact - keep your eyes on the security reports.

    • Re:Slow down there (Score:5, Informative)

      by harlows_monkeys (106428) on Tuesday December 09, 2008 @06:33PM (#26052583) Homepage

      This Bernstein guy is pushing a new crypto algorithm

      No, he is not. He's using an old, well-tested, well-studied algorithm, generally believed among cryptographers to be more secure than RSA.

    • by xrayspx (13127)
      His elliptical curve is cryptographically secure, he even says so on his web page. And it would be the only DNS solution that will pay you $500 if you site gets hijacked.
    • Isn't the standard process to submit it to the IETF or similar organization to have it ratified first?

      I believe the IETF wants to see two independent implementations before standardizing something. That's why the IP over Avian Carrier isn't an Internet standard, for one ;)

      The may want to publish an informational RFC, though.

      But it isn't SOP to write up a (semi)formal RFC as part of the discussion about how to solve any given problem. That's something you do once you want to set the solution in stone (or possibly something slightly softer).

    • by mrsbrisby (60242)

      I disagree. His reputation is the single most important motivating factor here. Vix et all produced this mess, have been whining about DNSSEC since 1993 and still haven't come up with a deployment plan, or a migration plan. DJB started with a system that was 100% compatible with DNS, instead of starting with a pipe dream.

      Furthermore, when BIND and friends were vulnerable to these new attacks, DJB's software wasn't. Not just because he was lucky, but because he's a pedant who thought of similar attack vector

    • Pushing a new crypto algorithm that has not been extensively vetted is a usually a bad idea ... but if there's one person you can trust to pull it off, that's djb.
      Here, DNSsec's RSA-1024 is the bad idea. We already know it's breakable to a determined enough attacker, now. And the prize is huge. What happened to the principle of having a significant margin of security? That's idiotic. I'm guesstimating wildly, but today a million-strong botnet could break it in months; in five year's time a 10-million strong

  • by Anonymous Coward

    ...but he is not seriously attempting to establish a different protocol all by himself, is he? The root server administrators would never switch, and without root support, there is no place to anchor the hierarchy. He might have had a chance earlier in the standardization phase, but now that there are live DNSSEC domains, his chances are practically zero.

    • by Wdomburg (141264)

      After the smashing success of Internet Mail 2000 [cr.yp.to] he would be a fool not to!

  • by nweaver (113078)

    The argument against DNSSEC is that its not needed for securing DNS: that the in-path adversary can F@#)* the final app anyway, unless the final app never trusted the DNS name.

    However, there is one key adversary which is in-path on the naming but NOT in path on the data: the DNS recursive resolver. We have seen resolver settings changed by malcode, ISPs wildcarding NXDomain errors, and even DNS service providers (like OpenDNS) man-in-the-middle'ing google!

    DNSSEC addresses this adversary, because it is a da

    • by foom (29095)

      DNSSEC addresses this adversary, because it is a data integrity protocol. DNSCurve does not: it explicitly trusts the recursive resolver and offers NO security guarentees against this very serious adversary.

      Okay, so where can I find a patch to make glibc's stub resolver verify DNSSEC signatures, so that I can be pretected from my recursive resolvers? DNSSEC has been around for nearly a decade: surely someone's implemented this by now?

      • by nweaver (113078)

        I think you can use Unbound as a stub resolver.

        • Re: (Score:3, Informative)

          by foom (29095)

          You might be interested in this thread:
          https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html [dns-oarc.net]
          where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. The only difference being that DNSSEC is hugely more complex to use and implement.

      • by wsanders (114993)

        Run BIND with DNSSEC and point your resolver to localhost. That's actually the way God, or whoever, intended it to be run.

        In practice, most organizations will run a local recursive "trusted" BIND server with DNSSEC behind a firewall just like they do now. Eventually substantial numbers of ISPs will do so too. No one does not because something like 0.01% of .com domains are DNSSEC-ified.

        It should be no more difficult that setting up HTTPS was, of course it only took 10 years or so to get that out of the hand

        • by foom (29095)

          But if I'm running BIND on my local machine, it would be just as secure under the DNSCurve proposal as with DNSSEC.

          If my organization has a central, recursive, trusted DNS server, then I'm just as secure under DNSCurve as with DNSSEC.

          The only place DNSCurve loses if if I have a stub resolver pointing to an *untrusted* recursive resolver on another host, instead of running my own recursive caching resolver. So maybe I just shouldn't do that...

  • by damn_registrars (1103043) <damn.registrars@gmail.com> on Tuesday December 09, 2008 @06:57PM (#26052857) Homepage Journal
    We've discussed before just how terrible of an idea it is to start selling gTLDs and let the spammers and con artists start running the entire show.

    And there have been more than a few objections [icann.org] on the list about selling gTLDs, as well.

    Yet apparently ICANN is set to go ahead with it, anyways.

    Funny, most organizations would be opposed to taking action that reduces their own authority (which is one obvious effect of selling gTLDs) - but of course with the prospect of seeing a small, immediate infusion of cash from the process, ICANN is all over it.

    Funny, in the name of profit, we are moving towards less regulation, less control, less accountability, and more resemblance to lawlessness.

    Unfortunately once they make this mistake there is no going back. We'll have unscrupulous registrars selling to criminals all over the world and we'll have zero control over the domains that turn profit on (counterfeit) drugs, (pirated) software, (counterfeit) fashion goods, (stolen) personal identification and the like.
  • Why not just default to TCP for DNS resolving over UDP?

    It solves the problem.

    • Packet count has already been mentioned, but there's also a latency question. The first packet you send in UDP can already carry information. That means you get the answer in one round trip. In TCP you can only send information with the SYN/ACK packet (the second round trip) so you get double the latency or more. Even worse, this applies to all of the queries in a recursive request being carried out for you by your nearby DNS server so it can easily be three extra round trips per DNS query.

      This is impor

  • by ErikTheRed (162431) on Tuesday December 09, 2008 @08:29PM (#26053869) Homepage
    DNSSec uses hierarchical signature chains (similar to SSL). So, um, they're going to sign our keys out of the goodness of their hearts, right? Oh, they're not? So the real reason that these registrars are running around with giant erections over DNSSec is because it's a whole new revenue stream for them? Makes sense now.

    Not that I'm against anyone making a buck, but if there's a decent way to accomplish the same goal without having another set of keys to sign (and having to update ZSKs every freaking month) then I'd be happy to give it a fair shake. It's not like most admins have all sorts of free time to deal with additional overhead.

    Another point in favor of DJB - Yes, he's abrasive, but when was the last time tinydns needed to be updated because of a security vulnerability? Now compare with BIND and Windows Server. We can argue his quirks all day long, but dude does have hands down the best record (pun semi-intended) when it comes to DNS security.
  • by JSBiff (87824) on Tuesday December 09, 2008 @09:10PM (#26054215) Journal

    I've thought before that it would be useful, if I'm using my laptop on a public WiFi network, to be able to use a pre-designated, trusted DNS Server (so that the public network's DNS Server can't send me to bogus servers).

    It would be a nice feature if I could have my computer cache the public key of my ISP's DNS Server (or maybe OpenDNS; the point is, some DNS Server *I* trust, instead of a random DNS server), then, no matter what network I connect to, always use that DNS Server, with the DNS packets being signed by the trusted server, so I know they are really from that server. (I realize I can use OpenDNS pretty much anywhere, but I don't know if there is anything preventing the local network from doing a MITM attack?)

    It might also be useful, for this type of system, if my computer can authenticate to the ISP DNS Server (because they might not normally allow DNS requests from outside their own network, but if there were a specified authentication mechanism as part of the standard, they might allow me to roam if I authenticate)?

    Maybe the best answer is to just use the VPN capability on my home router to always VPN to that router, which will then use my ISP's DNS. Until DNSSec is implemented widely, that's the best solution for now, anyhow, I think.

  • by guruevi (827432) <evi@NOSpam.smokingcube.be> on Wednesday December 10, 2008 @12:28AM (#26055589) Homepage

    I recently researched DNSSEC and I was going to implement it in my environment until I read the downfalls:

    1) Traffic for the signing of records would increase exponentially because to establish the authenticity you'd have to contact the originating server and do a PKI-like transaction (that's expensive). In it's current form, forcing DNSSEC throughout the world would effectively bring down the root DNS servers as well as many others
    2) Because of 1) caching DNS servers would be less useful since you'd have to contact the original for the keys anyway. This also introduces the problem that if all the original DNS are unreachable for whatever reason the whole zone would become unusable whereas now they have been cached.
    3) There is an attack vector where by using the no-record responses somebody can obtain the whole zone even if you didn't intend to publish it

    The problems with DNS are the same as the problems with SMTP and IPv4:
    - The problems were there from the start and the protocol wasn't designed with current threats in mind. Fixing it would effectively break it.
    - The only solution is to build up a new system parallel to it and introduce it without anyone noticing
    - The usable solutions are only temporary patches that make it more difficult to use become quickly reduced to the above 2 problems
    - There are multiple solutions from separate entities with their own agendas. Choosing one over the other has it's own flaws and is sometimes not even feasible.

  • DNSCurve is better (Score:5, Insightful)

    by eggnet (75425) on Wednesday December 10, 2008 @04:41AM (#26056967)

    DNSSEC focuses on signing dns zones. DNSCurve protects the transport only.

    This difference makes DNSSEC maintenance a pain in the ass, and DNSCurve easy.

    There are plenty of links in the summary to back this up, just wanted to point it out.

  • by RichiH (749257) on Wednesday December 10, 2008 @06:26AM (#26057471) Homepage

    DNSCURVE has been around for some time, now. DJB just does a shitty job of pointing out why it's superior. As I don't have time to sum it up, just harvest the +5 I comments for details.

    Also, I would have thought that qmail has a larger impact & coverage than djbdns & daemontools, but oh well ;)

    DJB is hard to deal with when, not if, you disagree with him. But he _does_ churn out good stuff.

  • Debian packet (Score:2, Interesting)

    by Tom (822)

    Wake me when there's a Debian packet available.

    Seriously. I've outgrown the age where I compile my software, unless it's stuff that I've written myself.

    • Re: (Score:3, Informative)

      by hardaker (32597)
      There are multiple implementations of DNSSEC for debian in the core repository. The latest bind tools support it and dnssec-tools is available packaged for debian.

I use technology in order to hate it more properly. -- Nam June Paik

Working...