At the request of several organizations (not just debian), ISC has modified the distribution so that you can type "make noesw" (no encumbered software) which will remove the encumbered sources from the distribution (specifically, the DNSSafe library from RSA and the DSS/DSA library from Cylink). Rgds, -drc Executive Director, ISC
Yes, this situation was mishandled, however it was mishandled on ISC's part, not CERT's. The web page was released prematurely. The CERT advisory was originally planned to go out today (prior to the web page getting linked in), but was delayed until Monday at ISC's request. Unfortunately, the ISC page got updated according to the original schedule. CERT is _NOT_ to blame. I apologize to all who may have been negatively impacted by this issue. Rgds, -drc Executive Director, ISC.
What do you mean by "not interoperate"? Will it just fail to be secure and instead fall back to non-secure methods of zone transfer?
It depends on a site's security policy. If the system is configured to ignore non-secure zones (unlikely, but theoretically possible), then it will not function at all. Of course, there is no way for a client to tell the server it supports DNSSEC...
So clue me in.... how many mistakes were actually made (or do I have to go d/l the RFC and count them myself)?
I'd recommend reading the RFC and not relying on the opinion of myself (or others).
So show me how to download it without downloading the add on and I'll believe you.
When we release 8.2.2 final, there will be two versions, bind-8.2.2 and bind-norsa-8.2.2. The difference in the two being -norsa doesn't have the DNSsafe code.
It would have been easier to make two variants of the package if you had that in mind when actually doing it originally.
Actually, as there is an interface between BIND and the crypto stuff, it is actually quite easy to drop the RSA stuff out (and in fact, we had already made a version without RSA before due to questions about the exportability of the RSA stuff).
I find it a bit ironic that the DFSG results in the same solution as the US policy on crypto export...
My guess is that ISC will have the RSA-free version "done" around 9/2000
No, 9/1999 (hopefully sooner, depending on how the beta testing goes).
So you admit that IETF made a blunder in choosing to integrate a proprietary algorithm in a protocol?
No. I believe it made a blunder in designing a protocol that does not allow for reasonable interoperation between multiple algorithms. I detest software patents, but I was given no say in their existance. Given they exist, I believe it appropriate to allow people the choice of using them or not.
do I really need all those extra features BIND gives me?
The extensions to the DNS supported by BIND are there because there was an itch that needed scratching and the IETF standardized on the way to do it. As BIND is a reference implementation, it would seem appropriate that we implement those itch scratchers. You are free to not use the features if your particular situation does not require it, however you must admit it is nice having the ability should the need arise.
A lot of people are bringing up DENTS. It's an alternate DNS implementation, dedicated to remaining 100% Free Software,
Which, of course, it can not be if it implements the DNS as it has currently been specified by the IETF. I find it unfortunate that ISC is put into the position of being either standards conformant xor "free" according to the Debian folks. We are addressing this by creating an additional distribution, one without RSA, and will be working in the IETF to try to come up with a better solution (use of RSA is among the least grotesque warts of DNSSEC from an operational perspective).
and it's technically superior too!
I'm a bit confused. DENTS, last time I checked, was at version 0.0.3, was unstable, and had essentially no deployment (understandable, given it is still under development). Yet you claim it is "technically superior". By what measure? Can it handle the 900+ Mbyte.COM zone? Can it sustain 6000+ queries per second? Does it support Dynamic DNS, IXFR, Notify, split DNS, etc.? Vaporware can often be "technically superior" until it has to face an often very unpleasant reality.
this is one of the more mature Slashdot discussions concerning Open Source that I've seen in a while
Funny. Wasn't there a bit of an arguably immature flame war resulting from an article in DaemonNews about *BSD being "technically superior" to Linux with no objective criteria?
Indeed they can. Given the (IMHO) poor operational design of DNSSEC, they undoubtedly will be, particularly after we gain a bit of operational experience with the current DNSSEC protocol. However, the current proposed standard DNSSEC specification states that RSA is the recommended algorithm. ISC prefers to implement standards as opposed to (say) Microsoft which invents their own.
All it takes is publication of draft and going through usual process until it becomes RFC.
I gather you haven't been involved in the IETF much. It is a bit more involved than that...
MS Win2000 implementing some half-arsed version of the Dynamic DNS RFC
No, their version of DDNS conforms to the RFCs. What is unique to Microsoft if their mechanism for secure dynamic updates. They use GSS-TSIG which is non-standard (but for which they have written an IETF Internet-draft). The problem is that to interoperate with Win2K, GSS-TSIG requires a GSS-API implementation that conforms to Microsoft's unique implementation of GSS-API. Unfortunately, it does not appear that Microsoft has provided enough information to create an interoperable GSS-API implementation.
Dynmic DNS not making it into BIND till the new version
No, BIND has had DDNS for 3 years. What was new to 8.2 was DNSSEC which provides security with public key cryptography (TSIG uses private key crypto) and is thus much more scalable (at least in theory). The problem is that the IETF chose RSA for the "recommended" signing algorithm (for good reasons) and RSA is patented. ISC negotiated a fairly liberal license but the Debian folk do not consider it liberal enough.
a new dynamic dns is unnessary in most cases, and could be done fine with dhcp+a few scripts
You can do this now with BIND 8, albeit not securely. 8.2.2 (due out real soon now) will have the ability to do secure dynamic update with the IETF standard TSIG (not Microsoft's GSS-TSIG).
The problem (which may or may not be a problem, depending on your environment): you won't be able to interoperate with Win2K.
No-one outside the BIND group wants the awful RSAREF code.
We would have prefered to not use code from RSADSI (it isn't RSAREF, it is DNSsafe -- they are different), however given RSA is the recommended algorithm in DNSSEC and RSA is patented, our choices were a bit limited.
The patent will expire next year, so if BIND insist on shipping this non-free code I hope they will undertake to replace it with FREE code next year
As as been referenced elsewhere, we will be creating a BIND-NORSA distribution for those who find the DNSsafe license objectionable.
Then it will not interoperate with other sites which use the recommended DNSSEC algorithm (which will most likely be the majority of sites using DNSSEC).
Since the keys are being signed off-line, even if DSA is considerably slower than RSA, it shouldn't be that big of a deal -- they only need be signed once.
Consider the.COM zone. It is over 900 Mbytes (without the NXT records, which will likely kick it up by 30%), increasing about 50Mbytes/week (so I'm told). Consider how often the.COM zone is updated. It is a big deal.
Yes, Dents is a replacement for BIND. It is currently in active development.
If Dents is going to implement DNSSEC according to the RFCs and expect to interoperate with other DNSSEC implementations, then it will need to support RSA as well. If they do not wish to use DNSsafe under the license provided, they can either risk patent infringement lawsuits or they can negotiate a separate license.
Additionally, I'd like to point out that DNSSEC does not depend on RSA; other signature systems (DH and DSA) are possible too.
Yes, but due to the DNSSEC spec, alternate signatures do not interoperate. Also, DSA & DH are much, much slower than RSA. There is a reason the IETF chose RSA as the RFC "recommended" algorithm...
Slashdot Mirror
At the request of several organizations (not just debian), ISC has modified the distribution so that you can type "make noesw" (no encumbered software) which will remove the encumbered sources from the distribution (specifically, the DNSSafe library from RSA and the DSS/DSA library from Cylink). Rgds, -drc Executive Director, ISC
Yes, this situation was mishandled, however it was mishandled on ISC's part, not CERT's. The web page was released prematurely. The CERT advisory was originally planned to go out today (prior to the web page getting linked in), but was delayed until Monday at ISC's request. Unfortunately, the ISC page got updated according to the original schedule. CERT is _NOT_ to blame. I apologize to all who may have been negatively impacted by this issue. Rgds, -drc Executive Director, ISC.
It depends on a site's security policy. If the system is configured to ignore non-secure zones (unlikely, but theoretically possible), then it will not function at all. Of course, there is no way for a client to tell the server it supports DNSSEC...
So clue me in.... how many mistakes were actually made (or do I have to go d/l the RFC and count them myself)?
I'd recommend reading the RFC and not relying on the opinion of myself (or others).
When we release 8.2.2 final, there will be two versions, bind-8.2.2 and bind-norsa-8.2.2. The difference in the two being -norsa doesn't have the DNSsafe code.
It would have been easier to make two variants of the package if you had that in mind when actually doing it originally.
Actually, as there is an interface between BIND and the crypto stuff, it is actually quite easy to drop the RSA stuff out (and in fact, we had already made a version without RSA before due to questions about the exportability of the RSA stuff).
I find it a bit ironic that the DFSG results in the same solution as the US policy on crypto export...
My guess is that ISC will have the RSA-free version "done" around 9/2000
No, 9/1999 (hopefully sooner, depending on how the beta testing goes).
No. I believe it made a blunder in designing a protocol that does not allow for reasonable interoperation between multiple algorithms. I detest software patents, but I was given no say in their existance. Given they exist, I believe it appropriate to allow people the choice of using them or not.
do I really need all those extra features BIND gives me?
The extensions to the DNS supported by BIND are there because there was an itch that needed scratching and the IETF standardized on the way to do it. As BIND is a reference implementation, it would seem appropriate that we implement those itch scratchers. You are free to not use the features if your particular situation does not require it, however you must admit it is nice having the ability should the need arise.
Which, of course, it can not be if it implements the DNS as it has currently been specified by the IETF. I find it unfortunate that ISC is put into the position of being either standards conformant xor "free" according to the Debian folks. We are addressing this by creating an additional distribution, one without RSA, and will be working in the IETF to try to come up with a better solution (use of RSA is among the least grotesque warts of DNSSEC from an operational perspective).
and it's technically superior too!
I'm a bit confused. DENTS, last time I checked, was at version 0.0.3, was unstable, and had essentially no deployment (understandable, given it is still under development). Yet you claim it is "technically superior". By what measure? Can it handle the 900+ Mbyte .COM zone? Can it sustain 6000+ queries per second? Does it support Dynamic DNS, IXFR, Notify, split DNS, etc.? Vaporware can often be "technically superior" until it has to face an often very unpleasant reality.
this is one of the more mature Slashdot discussions concerning Open Source that I've seen in a while
Funny. Wasn't there a bit of an arguably immature flame war resulting from an article in DaemonNews about *BSD being "technically superior" to Linux with no objective criteria?
Indeed they can. Given the (IMHO) poor operational design of DNSSEC, they undoubtedly will be, particularly after we gain a bit of operational experience with the current DNSSEC protocol. However, the current proposed standard DNSSEC specification states that RSA is the recommended algorithm. ISC prefers to implement standards as opposed to (say) Microsoft which invents their own.
All it takes is publication of draft and going through usual process until it becomes RFC.
I gather you haven't been involved in the IETF much. It is a bit more involved than that...
No, their version of DDNS conforms to the RFCs. What is unique to Microsoft if their mechanism for secure dynamic updates. They use GSS-TSIG which is non-standard (but for which they have written an IETF Internet-draft). The problem is that to interoperate with Win2K, GSS-TSIG requires a GSS-API implementation that conforms to Microsoft's unique implementation of GSS-API. Unfortunately, it does not appear that Microsoft has provided enough information to create an interoperable GSS-API implementation.
Dynmic DNS not making it into BIND till the new version
No, BIND has had DDNS for 3 years. What was new to 8.2 was DNSSEC which provides security with public key cryptography (TSIG uses private key crypto) and is thus much more scalable (at least in theory). The problem is that the IETF chose RSA for the "recommended" signing algorithm (for good reasons) and RSA is patented. ISC negotiated a fairly liberal license but the Debian folk do not consider it liberal enough.
a new dynamic dns is unnessary in most cases, and could be done fine with dhcp+a few scripts
You can do this now with BIND 8, albeit not securely. 8.2.2 (due out real soon now) will have the ability to do secure dynamic update with the IETF standard TSIG (not Microsoft's GSS-TSIG).
The problem (which may or may not be a problem, depending on your environment): you won't be able to interoperate with Win2K.
They also do not implement DNSSEC. For various reasons, people would like to make the DNS infrastructure stronger and DNSSEC was the method chosen.
We would have prefered to not use code from RSADSI (it isn't RSAREF, it is DNSsafe -- they are different), however given RSA is the recommended algorithm in DNSSEC and RSA is patented, our choices were a bit limited.
The patent will expire next year, so if BIND insist on shipping this non-free code I hope they will undertake to replace it with FREE code next year
As as been referenced elsewhere, we will be creating a BIND-NORSA distribution for those who find the DNSsafe license objectionable.
Then it will not interoperate with other sites which use the recommended DNSSEC algorithm (which will most likely be the majority of sites using DNSSEC).
Consider the .COM zone. It is over 900 Mbytes (without the NXT records, which will likely kick it up by 30%), increasing about 50Mbytes/week (so I'm told). Consider how often the .COM zone is updated. It is a big deal.
If Dents is going to implement DNSSEC according to the RFCs and expect to interoperate with other DNSSEC implementations, then it will need to support RSA as well. If they do not wish to use DNSsafe under the license provided, they can either risk patent infringement lawsuits or they can negotiate a separate license.
Because ElGammal isn't an IETF specified algorithm for DNSSEC. ISC tries to conform to the RFCs as much as possible.
Yes, but due to the DNSSEC spec, alternate signatures do not interoperate. Also, DSA & DH are much, much slower than RSA. There is a reason the IETF chose RSA as the RFC "recommended" algorithm...