DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve 179
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."
What a Coincidence! (Score:3, Funny)
DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve
That was the subject of the last spam e-mail to pass my filter!
djb has an alternative? (Score:4, Funny)
go figure...
Perhaps he should start his own separate Internet and be done with it. ;-)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
With blackjack and hookers?
In fact, forget blackjack and djb.
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)
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.
Re: (Score:2)
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)
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?
Re: (Score:2)
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: (Score:2, Informative)
http://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Implementations
Re:Slow down there (Score:5, Informative)
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)
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)
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)
Excellent point. I was focusing on transactions, not the keys. Thanks for pointing out my error.
That is the point of DNSCurve (Score:5, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
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)
Re: (Score:3, Insightful)
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
Re: (Score:2)
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?
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Yes, as someone else pointed out.
Re: (Score:2, Informative)
Jolly good show in owning up to the mistake, and with grace. Extraordinary forthrightness for Internet behavior.
Re: (Score:2)
Or use some other crypto algorithm entirely, DNSSEC has multiple already defined, and a mechanism to add more.
Re: (Score:2)
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)
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?
Re: (Score:2)
Re: (Score:2)
He's using it for tabular data (Score:2)
Or what's you definition of "tabular data"? Numerical spreadsheets?
Re: (Score:2)
I suppose you're referring to the tables on the page "Comparison of DNSSEC and DNSCurve". Well, I was referring to the big navigation bar on the top of every of those pages.
Go ahead, do that without in CSS2 (Score:2)
Me I'd just use display: -moz-box; [mozilla.org] --moz-box-align: horizontal; and -moz-box-flex: 1;, but that's very much non-standard.
Thing is, even if it's not strictly speaking tabular data, it's not a case of tablesoup either.
Re: (Score:2)
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
Re: (Score:2)
Too bad it does support AAAA records and SRV records.
No it doesn't. The official release, version 1.05 on his site [cr.yp.to], doesn't support serving AAAA records and contains no mention of SRV at all. Go ahead: download and grep for it. There are patch unofficial versions that do all sorts of things, but by that standard any software supports just about anything.
Re: (Score:2, Informative)
Yes, it does. It supports arbitrary record types, something that even your precious BIND does not (even though the RFC says it should). Grep for "generic record" in the tinydns-data documentation.
It doesn't support IPv6 queries without a patch (not that software last updated in 2001 reasonably could), but it most definitely supports AAAA and SRV records -- I'm currently using it to serve both.
/ Feel free to not like DJBDNS, just pick technically valid reasons
Re:Slow down there (Score:5, Informative)
You are mistaken. Go to tinydns.org and read
I did. That isn't the official version of djbdns; it's a fork. Furthermore, note that even the "enhanced" fork fails to support such fundamental necessities as IXFR. You can hobble together some hackish workalike with rsync - assuming you have control over both servers. Good luck getting a registrar or any other free/cheap DNS hosting service to go along with that arrangement.
As always, djbdns is probably OK as long as you don't need any of the (common) features it doesn't support. If you do, it stops looking so clever.
Re: (Score:3, Informative)
You need to work on your reading comprehension then.
DJBDNS supports all RR types, by way of generic RR support. See near the bottom of this page [cr.yp.to] for details.
There is a series of patches that produce friendly syntax for tinydns-data, a single component of DJBDNS. This isn't valuable to large sites who don't source with tinydns-data's built-in format.
It's the official version, and generic records (Score:2)
Generic records have an awkward syntax, but they allow you to store any kind of record. If you don't like it, you can just write a single line perl script to preprocess it. I have 100 domains managed with tinydns, the "data" file was getting a bit big. So I broke it up in a few files, and then have a makefile to
* svn commit
* Cat it all together and
* preprocess it into "data"
* Run tinydns-data
* scp data.cdb to a number of secondary servers
* Delete data (so that someone doesn't mistakenly edit it)
Trust me, it
Re: (Score:2)
Trust me, it beats the kludgy master/slave BS of bind.
you introduced make, svn and scp into the mix. how the fuck does that kludge beat a simple bind reload?
Does your bind do version control? (Score:2)
I don't need svn to do that, I just use it to keep an history of the changes I made, and it's free to use since it's just included in the make process. Instead of signalling bind to reload, I type "make" instead, and it does much more, more predictively. /snark
And yes, I use scp, and make, and also bash and vi. Looook at meee! I use Haute Technology! My zone "transfers" are compressed, encrypted and authentified; I'm so spoiled!
Re: (Score:2)
how the fuck does that kludge beat a simple bind reload?
But you don't get it! djbdns is simpler than BIND! Well, except when you have to make your own ad-hoc workaround for its lack of features, and your workaround is non-standard and won't interoperate with any of your partners' systems, and you're the only person in the world testing it so there's no peer review. But it's simpler! Really!
Re: (Score:3, Insightful)
IXFR, not AXFR. IXFR is sort of like a journal playback. Suppose you have 100,000 records in a zone. With AXFR, if you change one record, you have to retransmit all 100,000 records. With IXFR, you transmit the change alone. The suggested workaround is to use rsync or some other synching mechanism, but with djbdns that'd mean that rsync has to sync a directory with 100,000 files. Again, with IXFR you'd just replay the journal.
Re: (Score:2)
Data point: using axfr-get to download approximately 63,667 records from a host 16 hops away takes about nine seconds. The file 2.7MB in size. Most zones aren't that large, so the IXFR thing isn't a real problem.
Re: (Score:2)
The difference is... if the server is coded correctly it can still ANSWER for the other things in that zone while it's IXFR'ing the changes.
People looking for that record have to wait 9 seconds, people asking for the other records, don't have to wait.
IF the server is coded correctly, of course.
Add to this the fact that not all DNS servers are as well-connected as you have there, especially back when IXFR was added -- and you now see what the problems really were.
Re: (Score:2)
How long/how much data would 100,000 records transmitted via AXFR take? Like 1 minute? Big deal.
Now imagine it's the zonefile for Dynamic DNS for a large organization, so it's not only the fact that there are 100,000 records, but that there are continual updates. AXFR, etc.: you wouldn't be finished with the transfer before the next needs to start. IXFR: you keep the 10 slave servers updated with changes no more than a second or two old.
Re: (Score:2)
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.
Re: (Score:2)
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".
Re: (Score:2)
"/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.
To be fair, /service doesn't do dependency (Score:2)
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: /service
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
Bang. It's done. Beat that.
Re: (Score:2)
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.
Re: (Score:2)
svcadm enable ssh
Done.
Re: (Score:2)
That would be the "after a decade" I was alluding to.
Re: (Score:2, Insightful)
Re: (Score:2)
Just to be clear, it's not re-licensed; it has been released into the public domain, and no license is needed at all. DJBDNS and the like have similarly been released from copyright protection.
Re: (Score:2, Informative)
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).
THINK OF THE CHILDREN! (Score:2)
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)
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)
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)
No, he is not. He's using an old, well-tested, well-studied algorithm, generally believed among cryptographers to be more secure than RSA.
Re: (Score:2)
Re: (Score:2)
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).
Re: (Score:2)
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
New crypto algorithm (Score:2)
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
I have deep respect for DJB (Score:2, Insightful)
...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.
Re: (Score:2)
After the smashing success of Internet Mail 2000 [cr.yp.to] he would be a fool not to!
Re: (Score:2)
I don't think anyone's found a overflow in notepad either djb!
I wouldn't doubt it - try typing in "this app can break" (without quotes) or another string in that format. Save the file and reopen.
Don't throw the baby out with the bathwater (Score:4, Insightful)
Re: (Score:2)
The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.
George Bernard Shaw
Re: (Score:2)
I think he's released most of his stuff into the public domain, has he not?
DNSCURVE doesn't work... (Score:2, Informative)
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
Re: (Score:2)
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?
Re: (Score:2)
I think you can use Unbound as a stub resolver.
Re: (Score:3, Informative)
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.
Easy (Score:2)
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
Re: (Score:2)
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...
Some bad ideas won't go away... (Score:3, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
There's a ton of dns traffic.. that adds up. Not to mention system overhead in the connection establishment on the higher usage(think root) servers.
In fairness, you could mitigate that two ways:
Re: (Score:2)
Unfortunately that's not going to work well.
Many of the current top level DNS servers are running via anycast meaning many different servers have the same IP and the internet routes to the nearest one. This works very well since it scales but it can not handle TCP it has to be one packet in n packets out otherwise the first and second packets might night reach the same server.
Keeping state for all the upper level recursive servers would be a nightmare and who gets to choose who gets to be an upstream. Thi
Re: (Score:2)
Re: (Score:2)
I cant comment on Dalnet but that may involve having the back ends coordinate.
Falling back to UDP after how much time? The point is any slow down causes big headaches upstream there isn't time to fall back etc and still keep a fast system. The current 3000ms timeouts can cause nightmares adding another layer just makes it worse.
Now if they had just put all the security bits in follow on UDP packet(s) and use maybe a few bits in the request to ask for security verification. If the firewalls munged them no
What's DNSSec going to cost us? (Score:5, Insightful)
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.
Re:What's DNSSec going to cost us? (Score:4, Informative)
I personally find djbdns easier to use and less error prone than BIND for most stuff ( http://cr.yp.to/djbdns/blurb/easeofuse.html [cr.yp.to] ).
If you want to manipulate DNS records with perl, the djbdns format is much simpler than BIND's.
Yes it is different from BIND, but different can also be better.
Postfix's main.cf is different from sendmail.cf but much simpler(yes I know about m4, but honestly is it really simpler than Postfix? ).
The ISC have a long track record for producing hard to manage stuff with security problems.
It's no surprise that DNSSEC is a bad design (it's a good way for corporations like Network Solutions/Verisign to extract more money from people tho).
http://www.dnscurve.org/dnssec.html [dnscurve.org]
Will either DNSSEC or Curve solve this prob? (Score:3, Interesting)
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.
There's a reason we haven't implemented DNSSEC (Score:5, Insightful)
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)
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.
How is DNSCURVE news? (Score:4, Interesting)
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)
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)
Re: (Score:3, Interesting)
If RSA were not considered computationally secure, I might applaud his intent to provide "a better mousetrap".
Since 1024 bit RSA used by DNSSEC is *not* considered computationally secure, I'm sure he'll appreciate your applause.
Also, his "hack" of encoding the key in NS records actually simplifies deployment and could also be used by DNSSEC (at the expense of long DNS server names - *really* long in the case of DNSSEC).
DNSSEC is pre-signed, and can be checked by a client even if a DNS cache is compromised.
Re: (Score:2, Flamebait)
At just a moment when the internet at large needs to standardize on secure mechanisms, he has to gratuitously add another potential standard to the mix, increasing the difficulty of getting anything done.
that's because he's an egomaniac who'll not be happy until the internet becomes DJBnet, all based on DJB/IP, with DJBDNS, DJBML and the like
Re: (Score:2, Insightful)
Re: (Score:2)
you've made yourself look cock on the internet, won't be the first time or last (for either of us :)
1024 bit RSA keys are too short and too long (Score:2)
We've known since the beginning that the security of RSA depends on the key length that computers can factor using the latest algorithms. 10-bit keys were always too short; 512-bit keys were cracked in 1999, and Shamir ("S" in "RSA") published work in 2003 suggesting that 1024-bit keys might be endangerable soon - they're probably fine for one-shot use on any individual message less important than planning the overthrow of a large government, and they're certainly fine for bank transactions, because the co
Re: (Score:2)
You're wrong. The crux of his argument against DNSSEC is that it's stupid, requires everyone deploy it until anyone can enjoy it, and is incompatible with DNS. It has also wasted valuable space and time on the promise of an "extensible" cryptosystem completely ignoring the fact that deploying a new cryptosystem would require almost as much work as deploying the first one.
Don't you think we should get it rig
Re: (Score:2)
Curve is very well understood, and its security is twenty years old at this point. Curve is much faster than RSA, and in something like DNS, slowness can turn into denial-of-service attacks. Futhermore, Curve can guarantee only exponential time solutions exist, where RSA has been broken in sub-exponential time.
Technically, while cryptographers have not found sub-exponential attacks on elliptic curves, they are not guaranteed not to exist. The point, though, is that with existing attacks (which, as you mentioned, are 20 years old), 255-bit ECC is believed to be considerably more secure than 1024-bit RSA... in fact, it should be comparable to 4096-bit RSA. The signatures are considerably shorter. 255-bit ECC is probably slower than 1024-bit RSA for verifies, however.
Excellent question.
Because not only does someone have to break RSA to break your bank transactions, someone also has to break TCP, which is actually much harder, and requires a monstrous amount of computer power and bandwidth available at sub-msec speeds. With DNS, breaking TCP isn't a requirement, because DNS doesn't use TCP.
This isn't true... the best known attacks agai
Re: (Score:2)
Breaking TCP presently requires guessing sequence numbers reliably or a MITM attack. Both are extremely uncommon outside of LANs.
What isn't true? Breaking RSA is easier than breaking RSA and TCP? (note "also" in my original phrasing)
Not just probably, definitely. That's probably why dnscurve uses Curve25