Date: Mon, 19 Feb 2001 22:46:27 -0700 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert@primenet.com> Cc: Dan Peterson <danp@danp.net>, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <3A9204B3.B4FA5B88@softweyr.com> References: <200102200103.SAA04042@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > > > But with BIND, you the user can fix them. You can do that with DJBDNS, too, > > > but you can't share your fixes with anyone else. > > > > http://www.djbdns.org Been there, read that, understand the part that says I can't modify tinydns to do what I need it to and then sell or even give it to my customers. What part of this do you NOT understand? > Unfortunately, I still can't sell my company, if I patch DJBDNS, and > my company relies upon it, since I will be in violation of the license. ^^^^^^^^^^^^^^^^^^^^^^^^ > > > Dynamic DNS? > > > > I can't say I've ever used this. Sounds like another BIND klugde, though. It > > would probably be easier to write a simple script to edit your data file and > > rebuild data.cdb. RTFM at http://cr.yp.to/djbdns/tinydns-data.html . > > DNSUPDAT, which is the proper name of the facility, allows you to > make updates to zone data in the primary, without taking the server > down, and without an outage while the server reloads its file. In particular, in recent versions of BIND, you can do this via a LOCAL library, and is supported in recent versions of DHCP from ISC. The two work together to form a very effective way to introduce workstation names into the DNS zone as they are given DHCP leases. Yes, we need this, no tinydns does not support them, and no, you can't make it support them and distribute the code without violating DJB's license. ^^^^^^^^^^^^^^^^^^^^^^^ > > > DNSSEC? > > > > http://cr.yp.to/djbdns/forgery.html Right, this is his justification for not providing DNSSEC. I have control over the machines that will be communicating with my server, and can verify that to a degree that meets my needs. So, what we are left with is YET AGAIN software that doesn't meet my needs, and cannot be made to meet my needs AND be distributed to anyone else without violating the license. ^^^^^^^^^^^^^^^^^^^^^ > This is substantially incorrect. His reading is based on trusting > an exterior zone on the basis of trusting a signature authority; > if, on thge other hand, you want to establish your own security > associations internally, perhaps going so far as to establish > exterior associations with other companies for whom you have a > record of their public keys, you can do so. > Also, it is out of date: NSI has stated an intent to start signing, > as soon as the RFC goes standard. Other authoritative zone servers may do the same. Mine, for instance. DJB's analysis is valid as far as it goes, but mostly just refuses to address the issue because DJB doesn't think it's necessary. That's fine, but the rest of the world is marching on and making it work, in the mean- time we can't even update tinydns to do so unless we violate DJB's license. ^^^^^^^^^^^^^^^^^^^^^ > Meanwhile, there's still the license. I hope you're all finally starting to pick up on the "you can't do that without VIOLATING DJB's LICENSE" part here, it seems to be echoing quite loudly in this thread. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A9204B3.B4FA5B88>