Erm.. didn't Paul create MAPS to explicitly provide - and later monetize - the RBL? Wasn't the RBL a "directory service"? Didn't it map IPs to policy-based information?
MAPS was created to stop spam. Monetizing it was a late necessity due to the need to pay lawyers, but I'm still down about USD 1.0M.
We mapped IP's to policy based information, using DNS to deliver that data. All DNS responses issued by our DNS servers were absolutely factual in the policy they expressed.
actually i can have it both ways. i was a co-founder and was the first board chairman of nominum, and i still have many friends there. they know exactly how i feel about typosquatting. their product is smarter and tamer than others i can think of, but i still complain to them about it. i'm happy to be able to advise them on other matters.
a decade or longer before it was fashionable to decry the lack of transparency in government databases, carl was out there creating technology and deploying content to prove that what should be done also *could* be done. as a brass knuckled visionary carl could give us the kind of open government that everybody likes to talk about these days but few know how to build. carl also has the executive, financial, political, and administrative experience to pull this off. like the sign says "if you don't like the news go out and make some of your own"... or just hire carl malamud as the next head of the GPO. --paul vixie
"Grow up, kid, and learn how we grownups do stuff, and then later when you've built yourself a name and a reputation, and you can be trusted to write code for the masses, we'll let you play in our sandbox."
It's long past time for Secure DNS, which is a combination of TSIG+TKEY, SIG(0), and DNSSEC. End to end crypto authentication. Protects not just against off-path spoofed-source attacks like Kaminsky's, but also on-disk attacks against zone files, and provider-in-the-middle attackers who remap your NXDOMAIN responses into pointers to their advertising servers.
Sadly, it's a year away even if everybody started now, and most people want to be last not first, so very few people have started, and some of those people are saying "why bother, if it's not an instant solution there's no point to it, let's scrap the design and start over." (Had it not taken 12 years to get Secure DNS defined, then the prospect of doubling that time would not daunt me as much as it does.)
So, everybody please start already. NSD and Unbound from NLNetLabs supports DNSSEC. So does BIND, obviously. Sign your zones, and if your registrar won't accept keys from you, send them to a DLV registry while you wait for that. Turn on DNSSEC validation in your recursive nameservers. Write a letter to your congresscritter saying "please instruct US-DoC to give ICANN permission to sign the root DNS zone." In the time it would take for this Russian physicist's attack to work over your 512K DSL line (2.2 years, I heard?) we could completely secure the DNS or at least the parts of DNS whose operators gave a rat's ass about security (which is not the majority but it certainly includes your server, right?)
Had ssl 'worked' it would be deployed on close to every single site.
agreed.
any secure DNS system that requires you to trust third parties simply isn't secure. So we get the current situation where DNSSEC just isn't a solution.
the design calls for a path of trust that goes through a zone's parent (so, for slashdot.org, that's org) which made sense at the time since we're already trusting a zone's parent to hand us the right nameserver records (NS RRs) that bring the child into existence. so while this is a third party, it's not a new third party compared to normal DNS. are you sure this isn't secure?
your first-meeting trust distribution system sounds like what SSH uses, and it surely does work well for SSH. however, SSH isn't a lightweight datagram oriented protocol and i'm not sure that DNS can handle that much setup cost between trust-partners since there are millions of such for each RDNS and ADNS. the natural churn rate from key rollovers would probably be more traffic than all of DNS is today, which is a lot. since one of my hopes for Secure DNS is that it will someday obsolete X.509, i'd like it to have better scaling properties than X.509.
if i had to point to a weakness in the Secure DNS trust model it wouldn't be the existence of third parties, since as i said above there are no new third parties, just a new duty for the existing third parties (parent zone operators). noting that this new duty may strip the gears of many of the existing third parties, i would still say that the big weakness in the Secure DNS trust model isn't in the third party, but in the apex. the ultimate ancestor of all DNS zones is the "root zone", which is controlled by the U S Government through its contract with ICANN. we can't seem to get the root zone signed, but if we ever do get this, i feel uncomfortably certain that the U S Government will have key escrow.
while i wish we could do what PGP does, multiple paths of trust, each entity choosing whom to trust and how much to trust, each entity deciding for themselves which objects have enough trust coverage to be trustworthy... i was not able to sell that model inside the halls of the IETF, so we got trust-follows-delegation, with all its weaknesses, and without any way to get the root zone signed in any predictable or finite time. i find it darkly funny to be called a DNSSEC fanboy here whereas i'm seen inside IETF circles as a dangerous rabblerousing rebel on this topic. fun.
"Secure DNS" isn't the same thing as DNSSEC- one exists, the other does not.
Secure DNS includes TSIG, TKEY, and all revisions thus far to DNSSEC. So I'm not sure we're using the same dictionary.
We also know that BIND's credibility rules are stupid.
They exist to prevent cyclic glue reproduction, and were upgraded due to the Kashpureff attacks. They are not part of Secure DNS.
But most importantly, we also know that a lot of the practical DNS forgery attacks in the past - nearly two decades - could have been mitigated and yet you have led people to believe there is good reason not to stop these attacks.
UDP port randomization would not have stopped Kashpureff. Which attacks are you thinking of? I've led people to believe that if they deploy Secure DNS, including TSIG for their zone transfers, GSS-TSIG if they have the neccessary GSS infrastructure, RRSIG(0) if they have the necessary DNSSEC infrastructure, DNSSEC for their RDNS (making them into validators), and DNSSEC for their ADNS (meaning signing their zones and pressing their vendors to accept their DS RRs and sending their DLV RRs to ISC for inclusion in our DLV registry). None of which will help. Not today. But all of which will be necessary if we ever want to reach Secure DNS's tipping point.
As is often the case, I am not sure at this stage exactly what it is we're arguing about.
DNS Forgery has been well understood for decades now, and Paul Vixie is only accepting a simple solution while dragging his heels because his very complicated idea didn't work.
i'm accepting a solution because the cost:benefit of that solution is the best of all known alternatives in the nec'y timeframe. i'm also still pushing Secure DNS even though the quality of that technology and of the process which produced it makes me want to heave, because i'm aware of problems that don't occur at the transaction (hop by hop) layer, and i fully expect that next year dan will once again break the hop by hop layer in some way that we just won't have an easy fix for.
The real problem is that Paul is a very smart man, so it's very easy for people like you to see that this is an argument between very smart people. However Paul is also a douchebag and an idiot because he's dragged you into defending his ego, for something that affects millions.
say what you want about me, but don't call me a Secure DNS fanboy. it's all about cost:benefit across a long span of years.
EDNS having an extended ID field would also have solved
i don't think so, since EDNS is subject to downgrade attacks, it's not a good bearer for security-relevant information. i've also heard from some large internet portal companies that they have to ignore EDNS in a lot of queries since an EDNS response is often destroyed or dropped in the far-end firewall. this is fixable in the long run but it means we couldn't depend on EDNS for this fire drill even if it was resilient to downgrade attacks.
Do you have a pointer towards a design of a getnodebyname() replacement that indicates how it arrived at its data? I haven't seen one, but I admit to being shamed by ignorance of NSEC3.
i believe there is a firefox plugin that does this. IETF, in typical fashion, hasn't addressed the last-mile question of "how will applications become aware of this?" i think this should be done, so that glibc and BSD libc can just start offering this. at ISC we fear to tread on the API since folks will just accuse us of trying to take over the world (which is silly since we're already in charge, right?)
Nominum, the for-profit branch of Paul Vixie's life.
you can't be serious. i resigned as chairman of nominum's board back in 2002 or so. i have no position there. they stopped working on BIND9 at about that same time. let the record show that i am grateful to nominum's then-shareholders for their significant donation of code and effort to BIND9 9.0.0, which went well beyond what ISC paid them for.
Or that you'll leave DNSSEC running but go for a DNSSEC V2?
it's an educated bet. the restarts to the Secure DNS protocol development effort over the last 13 years have been because we could not find a backward compatible way out of some mess we'd painted ourselves into. in that time EDNS has matured, providing a negotiation framework. in that time, NSEC3 was added, without invalidating any existing endpoint or implementation or data pattern. i really think we're going to be ok.
Forgive me
show me what you're investing your time and effort in that solves the same set of problems better, or solves the truer more underlying problems better, and we'll talk.
it simply won't solve the DNS problems of the world
it would have prevented this attack, and amit klein's before that, and eugene kashpureff's back in the day. it would make BCP38 irrelevant to the DNS infrastructure. in other words it will solve a whole lot of problems that we actually know about and that we actually have. that you can cite a couple problems it would not solve is unsurprising and uninteresting from a risk:rewards point of view. that the API's aren't there yet for applications to become DNSSEC-aware is part of what i'm referring to when i say "deploy it locally and then beat on your vendors and providers to do likewise." be the chicken, or be the egg, but don't just complain from the sidelines -- that's already been done.
never _did_ solve that zone exposure problem, after 13 years, did they?
well, yes, we did. once the CCTLD's started taking DNSSEC seriously, they said "we can't do this if it allows zone-walking", which sadly meant that the protocol wasn't done after all, and has added yet another two years to the schedule. google for "NSEC3" to learn what's going on, and maybe do this level of fact checking before you come out here and tell everybody what's so.
I view handing Verisign more money and ability to (*@#&*&@^#* up the network as something that should be an antigoal
if you don't like verisign then you should move out of.COM and try something like.ORG whose registry (ISOC/PIR) has recently announced plans to deploy Secure DNS. (note that if you don't like verisign, then Secure DNS isn't the problem,.COM is the problem, and you should move.)
And you're running around telling people to deploy this?
well, yes, i am. but i am old enough to remember when people called ethernet a laboratory toy and said i was irresponsible for pushing it when token ring worked just fine. similarly, i was once yelled at for pushing TCP/IP when X.25 was good enough and OSI was clearly the future. no stranger to controversy am i. but if you want to gain the significant last-mover advantage of letting others try to make a market for Secure DNS, that's up to you. but maybe if you want to be neither chicken nor egg, you can also avoid complaining from the sidelines, eh?
not as absolute truth given by Paul Vixie^W^Wgod himself.
"If someone asks you whether you're a god, you say, YES.":-)
Because in life there are chickens and there are eggs. Note that Secure DNS is its own PKI, and its first and main reason for existing is to secure the DNS infrastructure, followed eventually by securing application data that's not safe enough in Classic DNS.
ISC is a nonprofit, and our software is free. It's difficult to imagine how we'll cover more of our expenses if you all decide to start deploying Secure DNS. I have indeed urged adoption of prior editions of Secure DNS which is how we learned that the protocol and/or implementations of same still needed work. Am I doing that again? You betcha -- because we'll be fine tuning the Secure DNS protocol and its implementations, and the DNS protocol and its implementations, for the rest of the Internet's lifetime.
However, we're past the point of flag days in Secure DNS. A valid configuration today will remain valid in the future. And this time we're finally seeing investment by CCTLDs, and some interest from banks. But we're not going to convince ICANN and/or USG to take the risks and reach for these rewards unless there's a significant installed base. This makes Secure DNS a bit like IPv6 in that there's a significant last-mover advantage. That's why I'm singing this song on slashdot rather than businessweek. New stuff with rough edges and not a lot of immediate benefit has to come to the technical community to get born.
The DJB vs BIND thing is an illusion. Whatever everyone agrees is the best implementation should win and I doubt that Paul Vixie or anyone else at ISC thinks differently.
I agree that any sense of competition between free stuff is illusury. There will be no winners other than the end users who benefit from greater availability and choice. Some people just plain like BIND, or Unbound, or PowerDNS, or DJB DNS, and I'll be happy if they get their wish -- to run what they like for reasons that make sense to them.
The current Secure DNS spec has been implemented by multiple independent developers, and tested widely enough, that there is reason for calling it "good enough". And after 13 years of false starts, it's hard to call it "pushed out too soon", at least in its current form. Other than lack of political will to sign the root zone (see: ICANN and USG), Secure DNS is deployable.
If you want Kaminsky and others to keep coming up with new ways to pollute DNS caches every few years, then by all means treat Secure DNS as unnecessary or as unbelievably crappy or whatever. But for myself, I'd like to be solving different problems some day, and so, I urge everyone to deploy as much of Secure DNS as they can, and urge their vendors and service providers to do likewise. It will absolutely not help, and will hurt some, in the short term. But the effort can earn us all a better future.
It was because of forethought of one man, DJB (Bernstein).
I'm pretty sure that if DJB had known about the attack Kaminsky found that kicked off the current crisis, he would have let us know. Note that I consider his UDP port randomization to be ingenius, and BIND 9.5.0 was already scheduled to have it even before ISC heard about Kaminsky's attack. Maybe DJB was disgusted with the laboratory-toy design simplicity of the DNS protocol, or maybe he's naturally conservative, or maybe this was low hanging fruit (why not use a nonce if nature gives you one?)
Given the troubles we're encountering with firewalls and NAT/PAT boxes as we roll out UDP port randomization internet-wide, I think there was a cost:benefit equation here, and that in the absence of Kaminsky's specific attack, a the price of UDP port randomization was too high, whereas now that we know about Kaminsky's attack, no price is too high.
Believe me, this is the simplified version for beginners.
i asked the BIND development team to comment on this and the consensus is you must have been running an older version. one person said:
This guy should provide more details. He should at least show the version(s) of BIND; I've heard that even a distributor of CNS noticed that threaded BIND 9.4 (not 9.3) could beat (Nominum)CNS in some workloads.
another said:
The first comment suggests he misunderstands multi-threading. It appears he's considering replacing 2xBIND8 processes with 1xBIND9 multi-threaded process. That would be suboptimal. 2xBIND9 multi-threaded would likely yeild increased performance.
finally, someone noted:
I admit: BIND9 (before 9.5) isn't perfect as a caching server with a very large cache (e.g., over 1GB of it) due to its inefficient cleaning mechanism. BIND 9.5 should solve this problem.
feel free to post additional questions or observations here, or contact me privately (paul@vix.com), as you choose.
If you run BIND with 100K zones, it takes quite some time to come up and starts answering queries. If you do a reload, it has a dead time in between. Try it..
please try 9.4.latest and 9.5.0-RC (or 9.5.latest, when it comes out of RC) and report back here. in particular, try it with the binary zone precompilation feature. make sure you build it with threads, on a system with good kernel-supported threads. even if you don't have multiple cores, though if you do, your QPS will improve (though your zone loading speed probably won't.)
As secondary it has bugs (for more than 12 months now) that may crash it. I just had customer who paid a lot of money to get it fixed by an external company. Of course the fix was sent to the BIND maintainers.
if you have a bug number, please post it here and i'll find out what happened with it. note that the BIND maintainers (http://www.isc.org/) also offer commercial support and feature development (that's largely how BIND is funded).
[BIND] has a performance problem as a caching nameserver and a severe one.
please post your queryperf results here, along with a pointer to your dataset, a description of your methodology, and comparative results from other name servers. we regularly stress-test BIND9 looking for bottlenecks, and we think the current version is pretty much competitive on modern hardware, software, compiler combinations.
yes. verisign provided some funding, and the executive who championed this is a good guy, and the NLNetLabs folks who took that money and wrote this code are good guys. it's also BSDL, and will be studied. even if verisign wanted to put some kind of bomb in the code and even if NLNetLabs somehow permitted it, external reviewers would find it straightaway. so, yes, in this case you are supposed to trust something that has VeriSign's name attached to it.
PowerDNS works quite well at those scles, FWIW. It's also Free
PowerDNS is GPL. BIND and Unbound (and NSD) are BSDL. Many users or operators will choose one or the other based on license alone. All of these servers work fine according to the people who are using them.
So that brings me back to the question: Why the hell doesn't bind have an option to use the system PRNG? Not all systems have a good random number generator, but I trust ours far more then the junk coded into bind. For that matter, I don't really mind if bind ate another 128K of memory to secure its own sequence space, if that is what it takes.
BIND uses cryptostrength PRNG for DNSSEC operations, but not for generating 16-bit query ID's (which is the topic of Amit's paper). 16 bits just isn't wide enough to care about predictability, and stub resolvers like gethostbyname() can't afford cryptostrength randomness even if it would do any good which it won't. My sympathies in this debate are mostly with Theo, since the only real fix for DNS Security is Secure DNS (DNSSEC). In response to Amit's original paper on this, I hacked BIND8 to use arc4random() for its upstream queries, and told folks who didn't have arc4random() in their libc to either get it or upgrade to BIND9.
To your question, why doesn't BIND9 have a build option to use the underlying OS PRNG (in/dev or libc or whatever), it's partly because this problem isn't solveable without DNSSEC so a better PRNG for 16-bit query-ID's is bad engineering economics, and partly because BIND9's PRNG is "good enough" for a 16-bit field and we (ISC) don't want the risk that some BIND builds will pull in really terrible OS PRNG's. Our BIND9 PRNG isn't cryptostrength... but spending more time on it won't make DNS more secure, only DNSSEC can do that. If DragonflyBSD wants to help secure the DNS, then make DNSSEC the default on all your systems, sign your own zones, and encourage your users to sign their zones. If your parent zone (.ORG,.COM, etc) won't take your DNSSEC keys, put them in DLV. DNSSEC is stuck in IPv6-like chicken-or-egg mode, and only dedicated coherent action from the F/L/OSS community has ever been able to unstick stuff like this.
But debates around the quality of a PRNG used to generate 16-bit integers are unproductive time thieves. We used to use the C "++" operator to select the next query ID, and in some ways I wish we had kept that practice rather than adding any kind of PRNG at all since it only gave the illusion of security without making query-ID guessing attacks impossible or even impractical.
i've started a discussion thread at OARC-dnsops on this ruling, and have tried to show the ways in which the judge might be looking at this. note, it's a bad ruling in my opinion, but not nec'ily proof of judicial idiocy.
Slashdot Mirror
MAPS was created to stop spam. Monetizing it was a late necessity due to the need to pay lawyers, but I'm still down about USD 1.0M.
We mapped IP's to policy based information, using DNS to deliver that data. All DNS responses issued by our DNS servers were absolutely factual in the policy they expressed.
actually i can have it both ways. i was a co-founder and was the first board chairman of nominum, and i still have many friends there. they know exactly how i feel about typosquatting. their product is smarter and tamer than others i can think of, but i still complain to them about it. i'm happy to be able to advise them on other matters.
a decade or longer before it was fashionable to decry the lack of transparency in government databases, carl was out there creating technology and deploying content to prove that what should be done also *could* be done. as a brass knuckled visionary carl could give us the kind of open government that everybody likes to talk about these days but few know how to build. carl also has the executive, financial, political, and administrative experience to pull this off. like the sign says "if you don't like the news go out and make some of your own" ... or just hire carl malamud as the next head of the GPO. --paul vixie
i know of forms of poison that do not involve the authority section at all.
i know of servers with no BIND code inside that were poisoned by kaminsky.
i know of valid configuration changes that depend on NS RRset replacement.
is this a troll of some kind? as slashdot lead articles go, this one shows unusually high disinformation and ignorance.
"Grow up, kid, and learn how we grownups do stuff, and then later when you've built yourself a name and a reputation, and you can be trusted to write code for the masses, we'll let you play in our sandbox."
I guess what goes around comes around.
It's long past time for Secure DNS, which is a combination of TSIG+TKEY, SIG(0), and DNSSEC. End to end crypto authentication. Protects not just against off-path spoofed-source attacks like Kaminsky's, but also on-disk attacks against zone files, and provider-in-the-middle attackers who remap your NXDOMAIN responses into pointers to their advertising servers.
Sadly, it's a year away even if everybody started now, and most people want to be last not first, so very few people have started, and some of those people are saying "why bother, if it's not an instant solution there's no point to it, let's scrap the design and start over." (Had it not taken 12 years to get Secure DNS defined, then the prospect of doubling that time would not daunt me as much as it does.)
So, everybody please start already. NSD and Unbound from NLNetLabs supports DNSSEC. So does BIND, obviously. Sign your zones, and if your registrar won't accept keys from you, send them to a DLV registry while you wait for that. Turn on DNSSEC validation in your recursive nameservers. Write a letter to your congresscritter saying "please instruct US-DoC to give ICANN permission to sign the root DNS zone." In the time it would take for this Russian physicist's attack to work over your 512K DSL line (2.2 years, I heard?) we could completely secure the DNS or at least the parts of DNS whose operators gave a rat's ass about security (which is not the majority but it certainly includes your server, right?)
http://en.wikipedia.org/wiki/Lout
agreed.
the design calls for a path of trust that goes through a zone's parent (so, for slashdot.org, that's org) which made sense at the time since we're already trusting a zone's parent to hand us the right nameserver records (NS RRs) that bring the child into existence. so while this is a third party, it's not a new third party compared to normal DNS. are you sure this isn't secure?
your first-meeting trust distribution system sounds like what SSH uses, and it surely does work well for SSH. however, SSH isn't a lightweight datagram oriented protocol and i'm not sure that DNS can handle that much setup cost between trust-partners since there are millions of such for each RDNS and ADNS. the natural churn rate from key rollovers would probably be more traffic than all of DNS is today, which is a lot. since one of my hopes for Secure DNS is that it will someday obsolete X.509, i'd like it to have better scaling properties than X.509.
if i had to point to a weakness in the Secure DNS trust model it wouldn't be the existence of third parties, since as i said above there are no new third parties, just a new duty for the existing third parties (parent zone operators). noting that this new duty may strip the gears of many of the existing third parties, i would still say that the big weakness in the Secure DNS trust model isn't in the third party, but in the apex. the ultimate ancestor of all DNS zones is the "root zone", which is controlled by the U S Government through its contract with ICANN. we can't seem to get the root zone signed, but if we ever do get this, i feel uncomfortably certain that the U S Government will have key escrow.
while i wish we could do what PGP does, multiple paths of trust, each entity choosing whom to trust and how much to trust, each entity deciding for themselves which objects have enough trust coverage to be trustworthy... i was not able to sell that model inside the halls of the IETF, so we got trust-follows-delegation, with all its weaknesses, and without any way to get the root zone signed in any predictable or finite time. i find it darkly funny to be called a DNSSEC fanboy here whereas i'm seen inside IETF circles as a dangerous rabblerousing rebel on this topic. fun.
Secure DNS includes TSIG, TKEY, and all revisions thus far to DNSSEC. So I'm not sure we're using the same dictionary.
They exist to prevent cyclic glue reproduction, and were upgraded due to the Kashpureff attacks. They are not part of Secure DNS.
UDP port randomization would not have stopped Kashpureff. Which attacks are you thinking of? I've led people to believe that if they deploy Secure DNS, including TSIG for their zone transfers, GSS-TSIG if they have the neccessary GSS infrastructure, RRSIG(0) if they have the necessary DNSSEC infrastructure, DNSSEC for their RDNS (making them into validators), and DNSSEC for their ADNS (meaning signing their zones and pressing their vendors to accept their DS RRs and sending their DLV RRs to ISC for inclusion in our DLV registry). None of which will help. Not today. But all of which will be necessary if we ever want to reach Secure DNS's tipping point.
As is often the case, I am not sure at this stage exactly what it is we're arguing about.
i'm accepting a solution because the cost:benefit of that solution is the best of all known alternatives in the nec'y timeframe. i'm also still pushing Secure DNS even though the quality of that technology and of the process which produced it makes me want to heave, because i'm aware of problems that don't occur at the transaction (hop by hop) layer, and i fully expect that next year dan will once again break the hop by hop layer in some way that we just won't have an easy fix for.
say what you want about me, but don't call me a Secure DNS fanboy. it's all about cost:benefit across a long span of years.
i don't think so, since EDNS is subject to downgrade attacks, it's not a good bearer for security-relevant information. i've also heard from some large internet portal companies that they have to ignore EDNS in a lot of queries since an EDNS response is often destroyed or dropped in the far-end firewall. this is fixable in the long run but it means we couldn't depend on EDNS for this fire drill even if it was resilient to downgrade attacks.
i believe there is a firefox plugin that does this. IETF, in typical fashion, hasn't addressed the last-mile question of "how will applications become aware of this?" i think this should be done, so that glibc and BSD libc can just start offering this. at ISC we fear to tread on the API since folks will just accuse us of trying to take over the world (which is silly since we're already in charge, right?)
you can't be serious. i resigned as chairman of nominum's board back in 2002 or so. i have no position there. they stopped working on BIND9 at about that same time. let the record show that i am grateful to nominum's then-shareholders for their significant donation of code and effort to BIND9 9.0.0, which went well beyond what ISC paid them for.
it's an educated bet. the restarts to the Secure DNS protocol development effort over the last 13 years have been because we could not find a backward compatible way out of some mess we'd painted ourselves into. in that time EDNS has matured, providing a negotiation framework. in that time, NSEC3 was added, without invalidating any existing endpoint or implementation or data pattern. i really think we're going to be ok.
show me what you're investing your time and effort in that solves the same set of problems better, or solves the truer more underlying problems better, and we'll talk.
it would have prevented this attack, and amit klein's before that, and eugene kashpureff's back in the day. it would make BCP38 irrelevant to the DNS infrastructure. in other words it will solve a whole lot of problems that we actually know about and that we actually have. that you can cite a couple problems it would not solve is unsurprising and uninteresting from a risk:rewards point of view. that the API's aren't there yet for applications to become DNSSEC-aware is part of what i'm referring to when i say "deploy it locally and then beat on your vendors and providers to do likewise." be the chicken, or be the egg, but don't just complain from the sidelines -- that's already been done.
well, yes, we did. once the CCTLD's started taking DNSSEC seriously, they said "we can't do this if it allows zone-walking", which sadly meant that the protocol wasn't done after all, and has added yet another two years to the schedule. google for "NSEC3" to learn what's going on, and maybe do this level of fact checking before you come out here and tell everybody what's so.
if you don't like verisign then you should move out of .COM and try something like .ORG whose registry (ISOC/PIR) has recently announced plans to deploy Secure DNS. (note that if you don't like verisign, then Secure DNS isn't the problem, .COM is the problem, and you should move.)
well, yes, i am. but i am old enough to remember when people called ethernet a laboratory toy and said i was irresponsible for pushing it when token ring worked just fine. similarly, i was once yelled at for pushing TCP/IP when X.25 was good enough and OSI was clearly the future. no stranger to controversy am i. but if you want to gain the significant last-mover advantage of letting others try to make a market for Secure DNS, that's up to you. but maybe if you want to be neither chicken nor egg, you can also avoid complaining from the sidelines, eh?
"If someone asks you whether you're a god, you say, YES." :-)
Because in life there are chickens and there are eggs. Note that Secure DNS is its own PKI, and its first and main reason for existing is to secure the DNS infrastructure, followed eventually by securing application data that's not safe enough in Classic DNS.
However, we're past the point of flag days in Secure DNS. A valid configuration today will remain valid in the future. And this time we're finally seeing investment by CCTLDs, and some interest from banks. But we're not going to convince ICANN and/or USG to take the risks and reach for these rewards unless there's a significant installed base. This makes Secure DNS a bit like IPv6 in that there's a significant last-mover advantage. That's why I'm singing this song on slashdot rather than businessweek. New stuff with rough edges and not a lot of immediate benefit has to come to the technical community to get born.
I've got nothing against DJB. And I expect that the URL in the parent points to pretty old information.
I agree that any sense of competition between free stuff is illusury. There will be no winners other than the end users who benefit from greater availability and choice. Some people just plain like BIND, or Unbound, or PowerDNS, or DJB DNS, and I'll be happy if they get their wish -- to run what they like for reasons that make sense to them.
If you want Kaminsky and others to keep coming up with new ways to pollute DNS caches every few years, then by all means treat Secure DNS as unnecessary or as unbelievably crappy or whatever. But for myself, I'd like to be solving different problems some day, and so, I urge everyone to deploy as much of Secure DNS as they can, and urge their vendors and service providers to do likewise. It will absolutely not help, and will hurt some, in the short term. But the effort can earn us all a better future.
I'm pretty sure that if DJB had known about the attack Kaminsky found that kicked off the current crisis, he would have let us know. Note that I consider his UDP port randomization to be ingenius, and BIND 9.5.0 was already scheduled to have it even before ISC heard about Kaminsky's attack. Maybe DJB was disgusted with the laboratory-toy design simplicity of the DNS protocol, or maybe he's naturally conservative, or maybe this was low hanging fruit (why not use a nonce if nature gives you one?)
Given the troubles we're encountering with firewalls and NAT/PAT boxes as we roll out UDP port randomization internet-wide, I think there was a cost:benefit equation here, and that in the absence of Kaminsky's specific attack, a the price of UDP port randomization was too high, whereas now that we know about Kaminsky's attack, no price is too high.
To your question, why doesn't BIND9 have a build option to use the underlying OS PRNG (in /dev or libc or whatever), it's partly because this problem isn't solveable without DNSSEC so a better PRNG for 16-bit query-ID's is bad engineering economics, and partly because BIND9's PRNG is "good enough" for a 16-bit field and we (ISC) don't want the risk that some BIND builds will pull in really terrible OS PRNG's. Our BIND9 PRNG isn't cryptostrength... but spending more time on it won't make DNS more secure, only DNSSEC can do that. If DragonflyBSD wants to help secure the DNS, then make DNSSEC the default on all your systems, sign your own zones, and encourage your users to sign their zones. If your parent zone (.ORG, .COM, etc) won't take your DNSSEC keys, put them in DLV. DNSSEC is stuck in IPv6-like chicken-or-egg mode, and only dedicated coherent action from the F/L/OSS community has ever been able to unstick stuff like this.
But debates around the quality of a PRNG used to generate 16-bit integers are unproductive time thieves. We used to use the C "++" operator to select the next query ID, and in some ways I wish we had kept that practice rather than adding any kind of PRNG at all since it only gave the illusion of security without making query-ID guessing attacks impossible or even impractical.
Paul Vixie
i've started a discussion thread at OARC-dnsops on this ruling, and have tried to show the ways in which the judge might be looking at this. note, it's a bad ruling in my opinion, but not nec'ily proof of judicial idiocy.