[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Strategy: DNS server in main for potato?



In article <[🔎] 19990905213941.A12444@watervalley.net> you wrote:

> 1. Use DENTS (http://www.dents.org/); however, it may not make the
>    November freeze date.  And it's not BIND (which everyone who
>    is/should be setting up a DNS server "knows".)

Feels good since it's GPL'ed.  I don't personally know how close to "ready
for prime time" DENTS is since I haven't run it.  Further investigation is
definitely in order.

> 2. Use the last DFSG-free BIND (8.1.2?).  We'll need some strategy for
>    it to coexist with current BIND releases, though.  And it is
>    unlikely to be maintained upstream.

I don't think this is a great idea.  The BIND community moves on security
issues pretty quickly, and 8.1.2 is getting "old" at this point.  Forking the
code in this way seems like a bad approach.

> 3. Somehow separate the DNSSEC code from new BIND releases.  I suspect
>    this will be very hard.

My analysis, and that of a couple of other folks, is that this is hard for
8.2.1, getting harder for 8.2.2, and likely to be nearly impossible for 9.X.

> Option 2 is probably the most feasible, but perhaps we should look at
> making DENTS compatible with BIND configurations (or include a
> conversion tool).

There are other options.  One is to wait for the RSA patent to expire, write
a replacement for the code RSA provided, and help BIND upstream get free again.
Another is that it appears there's nothing in the security spec that requires
the RSA code, it was just convenient, and it is that code for which an export
license has been acquired or some such.  Thus, changing that code is likely
to cause non-us issues in addition to the non-free issues. 

There are probably others.  Frankly, if I had time to spare, I'd spend it 
helping to make DENTS ready for prime time inclusion in Debian.  It's GPL'ed,
after all.

Bdale


Reply to: