Slashdot Mirror

← Back to Stories (view on slashdot.org)

VeriSign Will Support DNSSEC In .com By 2011

Posted by kdawson on from the phish-while-you-may dept.

alphadogg writes "VeriSign has promised to deploy DNS Security Extensions, known as DNSSEC, across all of its top-level domains within two years. DNSSEC is viewed as the best way to bolster the DNS against vulnerabilities such as the Kaminsky bug discovered last year. (Yesterday we discussed the workarounds coming into place until the US government signs the Internet's root zone.) DNSSEC has been deployed on top-level domains operated by Sweden, Puerto Rico, Bulgaria, Brazil, and the Czech Republic. Two larger domains — .org operated by the Public Interest Registry and .gov operated by the US government — are deploying DNSSEC this year."

26 of 39 comments (clear)

  1. erm... by XanC · · Score: 4, Insightful

    What takes so long? Why not now?

    1. Re:erm... by NecroPuppy · · Score: 1

      Because the wheels of a bureaucracy grind slow, and exceedingly dumb.

      --
      I like you, Stuart. You're not like everyone else, here, at Slashdot.
    2. Re:erm... by winkydink · · Score: 5, Insightful

      They need time to figure out how to profit from the deployment.

      --

      "I'd rather be a lightning rod than a seismometer." -Ken Kesey

    3. Re:erm... by Timothy+Brownawell · · Score: 1

      They need time to figure out how to profit from the deployment.

      Very funny. If that was the hold-up, they wouldn't be promising or planning anything.

    4. Re:erm... by Tony+Hoyle · · Score: 1

      Oh that's easy. A 'secure' entry will cost $$$, require a verisign certificate and they'll pressure browser makers to produce ominous warnings if your domain isn't signed by them.

      I suspect the delay is because NSEC3 only just got put into bind 9.6, and DNSSEC is (ironically) just too insecure to deploy without that.

    5. Re:erm... by thue · · Score: 5, Informative

      Because when released it will reduce the profit from their certificate signing business, as people can get end-to-end public key encryption just by updating their DNS entry.

    6. Re:erm... by jd · · Score: 1

      Saying they are planning something != they actually are. If DNSSEC isn't something that will generate revenue, expect "unforeseen delays" to cause the roll-out to be postponed indefinitely - or scrapped entirely. Press releases cost very little, and by the time 2011 rolls around, nobody will remember them anyway.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    7. Re:erm... by Timothy+Brownawell · · Score: 1

      Or maybe they've just realized that it's necessary and inevitable, and they have to participate regardless. Because if they get left behind, they get lots of bad press for allowing .com domains to be spoofed and maybe even lose their nice fat tld contracts.

    8. Re:erm... by Timothy+Brownawell · · Score: 2, Interesting

      Because when released it will reduce the profit from their certificate signing business, as people can get end-to-end public key encryption just by updating their DNS entry.

      Maybe this is the real reason behind the "Extended Validation" certificates they're pushing? Those include some verification of your real-world identity (like I thought regular certs were always supposed to have...), so they can't be replaced by dnssec.

    9. Re:erm... by Anonymous Coward · · Score: 5, Insightful

      Many reasons....

      The root is just the root...
      70 million domains to sign. Think you can just do that on your desktop in a couple of hours? It's going to take an infrastructure of machines to do this. That infrastructure itself is going to need to be secure. And reliable. And backed up. Securely. And with a geographical disaster recovery plan in place. ( A secure one ). And they need to ensure that their root servers ( A and J ) can handle DNSSEC too. Just to be clear, neither A nor J are a single server - you just don't handle more than 50 BILLION queries EVERY SINGLE DAY from a couple of boxes on a T1. VeriSign has a large number of distributed boxes that comprise each root server.

      That's just the technology - the easy part. The harder part comes with the business processes needed to support this. New domains will need to be signed. Employees are going to need to be able to do that somehow, but every employee that has access to the root key is a risk to that key Consider that if that key gets compromised the whole stack of cards will come tumbling down, thus requiring those 70M domains to be resigned with a new key. And that new key's cert will need to be published downstream etc. So somehow VeriSign has to come up with business processes that allow new domains to be signed without the root key being compromised. Processes that allow the infrastructure to be administrated and monitored without the root key being compromised etc.

      If you're not getting the picture yet, this is really not a trivial exercise.

      The good news is that VeriSign has experience with these kinds of problems - running the CAs that sign >90% of the World's PKI certificates has given them that.

      Before the usual VeriSign hating slashdot crowd get in here... it's my opinion that VeriSign do a great job with DNS. I can't think of any other service that I pay for that has given me 100% uptime this year alone, let alone for a number of years.

      Most corporations strive for five 9s uptime. That allows 5 minutes and 15.35 seconds of downtime in a (non-leap) year. My electricity, water, gas, oil and ISP have all had outages longer than that in the past year, and most of them have outages every year, and yet I pay them a damn sight more than the $7 a year that VeriSign gets for serving my DNS records.

      Disclaimer... I'm an ex-employee and small-time stock-holder of VRSN.

    10. Re:erm... by Timothy+Brownawell · · Score: 1

      What takes so long? Why not now?

      TFA says the delay is related to the size of the zones, so I'd guess it's related to increased hardware and bandwidth requirements. I can double my computing power with a trip to walmart, and double my bandwidth with a call to Comcast and probably a reset of the cable modem... Verisign might have a bit more difficulty.

    11. Re:erm... by ion.simon.c · · Score: 1

      My electricity, water, gas, oil and ISP have all had outages longer than that in the past year, and most of them have outages every year, and yet I pay them a damn sight more than the $7 a year that VeriSign gets for serving my DNS records.

      I've a few niggling points to make here...
      Your utilities companies have to acquire, distribute, and track usage of a good in meatspace. VeriSign has to store and serve some hundreds of bytes of data per domain, per request in cyberspace. What's the cost of shipping some hundreds of bytes, again? (Hell, what's the cost of shipping a trillion bytes?)
      Most utilities companies also serve a comparatively insignificant area when compared to VS's market. VS can really work the "economies of scale" thing in connection acquisitions, utilities purchasing, and data warehousing.

      I'd be willing to bet that VS's per-customer overhead is significantly lower than the overhead of your local utilities company could ever possibly be. I'd also bet that VS's per-customer profit margin is higher than that of your local utilities company. :)

    12. Re:erm... by cakefragment · · Score: 1

      Well, you're half right.

      DNSSEC's original form allowed for unrestricted zone walking via querying for non-existent domains and receiving an answer containing the RRs appearing just before and after the non-existent domain. This was a major stopping point for widespread implementation. RFC 5155 and NSEC3 addresses this by using hashes of domains instead of domains themselves.

      As for the certificates, you do not need to buy a certificate from VeriSign to sign your DNS data. You generate your own keys and provide a key fingerprint to whomever is delegating your domain to you. Queriers can use that fingerprint to validate the DNSKEYs you present for their use in validating your signed records.

    13. Re:erm... by Eric+Smith · · Score: 1

      As for the certificates, you do not need to buy a certificate from VeriSign to sign your DNS data. You generate your own keys and provide a key fingerprint to whomever is delegating your domain to you.

      And who do you suppose is delegating my .com domain to me? Even if I don't have to "buy a certificate" from them, do you really think that they will do anything useful with that key fingerprint without trying to extract more money from me?

      I somehow doubt that telling people with .com domains that they can use DNSSEC by switching to a different gTLD or ccTLD would make them particularly happy.

  2. are you sure this is such a good idea? by Onymous+Coward · · Score: 1

    DNSSEC is viewed as the best way to bolster the DNS against vulnerabilities such as the Kaminsky bug discovered last year.

    [citation needed] Or maybe this is "weasel words". In any case, "Says who?"

    I'd like to see some discussion around the relative merits of DNSSEC v. DNSCurve. DJB knows his shit, and I want to see his ideas getting proper exposure here.

    1. Re:are you sure this is such a good idea? by Timothy+Brownawell · · Score: 2, Informative

      I'd like to see some discussion around the relative merits of DNSSEC v. DNSCurve.

      With DNSSEC, it's the data that's authenticated. With DNSCurve, it appears to be the server. Does DNSCurve protect against a meddling cache, or does it require all queries to be processed by the authoritative server or a trustable cache?

      DNSCurve encrypts connections. This has per-byte overhead, plus per-connection overhead which can (mostly?) be made into per-peer overhead with caching. DNSSEC doesn't, so someone could potentially see what records you look up (and save themselves the trouble of having to look at which IP you connect to next, I suppose?).

      And probably much more...

    2. Re:are you sure this is such a good idea? by jonaskoelker · · Score: 1

      With DNSSEC, it's the data that's authenticated. With DNSCurve, it appears to be the server.

      The server? As I see it, it's the connection from the client (i.e. your ISP's caching proxy resolver) to the server; that is, the communication.

      What's the difference? If you run your own trusted resolver and you trust the root, let's see:

      Sec: you get the IP of .com and a signature which you trust
      Curve: you get the IP via a channel which you trust.

      In both cases, you know the .com address that root wants you to know, and you trust the result. By induction,

      2. ???
      3. profit.com

      One difference, though: in Sec, you have to trust the root at the time it signs .com. With Curve, you have to trust the root when you talk to it. If the data-sending server is broken into, with Curve you're screwed (not so with Sec). I'm not saying that the machine the signing is done on (with Sec) is invulnerable, but it can probably be secured somewhat better... maybe?

      Does DNSCurve protect against a meddling cache, or does it require all queries to be processed by the authoritative server or a trustable cache?

      Good point. DNSCurve only secures the connection between the cache and the DNS servers. You as a plain ol' user have to trust the connection to your ISP's caching proxy. If you have nefarious neighbours and an ISP who thinks hubs are great (or whose switches can be made to act like hubs) and they know arp spoofing and stuff... you might be hosed. Not so with Sec: they might be able to modify traffic arbitrarily, but they can't make up a valid signature on their own data.

      DNSCurve encrypts connections. This has per-byte overhead, plus per-connection overhead which can (mostly?) be made into per-peer overhead with caching. DNSSEC doesn't

      Per-byte cost of what? Traffic or time?

      With Sec, you have to validate signature(hash(data)). That's a per-byte time overhead for the hash function. Symmetric encryption is similar. Assymetric encryption is always (well, almost always) applied to a symmetric key which is used to encrypt the data; symmetric encryption has performance characteristics much like hash functions: per-byte processing, 1-to-1 size ratio between input and output.

    3. Re:are you sure this is such a good idea? by Timothy+Brownawell · · Score: 1

      DNSCurve encrypts connections. This has per-byte overhead, plus per-connection overhead which can (mostly?) be made into per-peer overhead with caching. DNSSEC doesn't

      Per-byte cost of what? Traffic or time?

      With Sec, you have to validate signature(hash(data)). That's a per-byte time overhead for the hash function. Symmetric encryption is similar. Assymetric encryption is always (well, almost always) applied to a symmetric key which is used to encrypt the data; symmetric encryption has performance characteristics much like hash functions: per-byte processing, 1-to-1 size ratio between input and output.

      Extra per-byte CPU cost on the server (and client/caches) to do the encryption. Validating signature(hash(data)) is likely more expensive as a public-key operation (similar to the per-connection/peer part of the DNSCurve overhead), but is client-side where it doesn't matter... except it also probably happens on caches, so I guess DNSSEC would put a (slightly?) higher (CPU) load on caches (and clients) and a lower load on servers.

    4. Re:are you sure this is such a good idea? by Onymous+Coward · · Score: 1

      What!

      Where have you been for the last decade? Pay attention!

      http://www.kb.cert.org/vuls/byid?searchview&query=isc%20bind

      http://www.kb.cert.org/vuls/byid?searchview&query=djbdns

      18 v. 0? And you're looking for what kind of "authority" to make this judgement for you?

      (For full disclosure, there is now a single candidate (by-design) vulnerability listed with the CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4392)

  3. DJB causes his own problem here by DragonHawk · · Score: 3, Insightful

    [citation needed] Or maybe this is "weasel words". In any case, "Says who?"

    Everybody *but* DJB. And since DJB has apparently pissed off just about the entire rest of the population of the planet at this point, his pet-project ideas have just about zero chance of being adopted widespread. So, in a very real sense, DNSCurve is by definition the least-good way to secure DNS, because it will never see real adoption.

    Whether or not DNSCurve has any good ideas or not doesn't matter, because DJB has burned every bridge to his own little island. And it turns out that a network that doesn't connect to anything isn't very interesting.

    --

    dragonhawk@iname.microsoft.com
    I do not like Microsoft. Remove them from my email address.
    1. Re:DJB causes his own problem here by mattbee · · Score: 1

      Bernstein doesn't need to convince people with his diplomacy, just his software and its minimalist documentation. qmail and djbdns achieved widespread deployment *despite* their unhelpful licenses and lack of official maintenance. If he can put out a new tinydns release to prove DNSCurve, rather than just a vague specification, he stands a high chance of spreading the idea from the ground up.

      --
      Matthew @ Bytemark Hosting
    2. Re:DJB causes his own problem here by nabsltd · · Score: 1

      qmail and djbdns achieved widespread deployment *despite* their unhelpful licenses and lack of official maintenance.

      There are many pieces of software that are not the best tool for the job (or even in the top three in their category) of which similar things can be said.

      For example, Internet Explorer has been behind the curve in browser quality for years, yet is the most used. Photoshop probably isn't the best tool for the job for 90% of people, yet it is the "must have" graphics editing tool.

      Whether qmail is internally secure or not isn't important if it's default configuration leads to blowback spam. One of the touted features of djbdns is that it randomizes outgoing ports, but this is not needed if your firewall already does this, and is wasted if your firewall uses some predictable pattern.

      Basically, Bernstein is loud and his volume seems to mask the ability of people to look at his software rationally.

  4. Huh? by wsanders · · Score: 1

    The DNSSEC and https/SSL certificate systems are completely different.

    I mean, you *could* use https/SSL to get secure DNS via port 443 right now, all it would take would be a few lines in Apache. Now convince the rest of the world to follow your lead....

    DNSSEC (and DNSCurve) are only as good as the clients that adopt it.

    --
    Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
    1. Re:Huh? by Timothy+Brownawell · · Score: 3, Informative

      The DNSSEC and https/SSL certificate systems are completely different.

      I mean, you *could* use https/SSL to get secure DNS via port 443 right now, all it would take would be a few lines in Apache. Now convince the rest of the world to follow your lead....

      DNSSEC (and DNSCurve) are only as good as the clients that adopt it.

      Huh?

      The idea is that instead of paying a CA to give you a SSL certificate, you generate your own and put the hash in a DNS record. With DNSSEC, this means that your SSL certificate is effectively signed by your DNSSEC key, with a chain going back to the keys for the root zone. This eliminates the need for CAs (unless you use the EV certs, that map to a real-world identity that browsers will usually show people), and even gets rid of the problem of bad signers that give out certs they shouldn't.

  5. 2011? by actionbastard · · Score: 1

    That gives me plenty of time to install the latest BIND distro from source...

    --
    Sig this!
  6. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion