strip FreeBSD a bit
tlambert2 at mindspring.com
Mon Sep 1 19:13:18 PDT 2003
"Jeremy C. Reed" wrote:
> On Mon, 1 Sep 2003, Terry Lambert wrote:
> > > Or another alternative is his resolver code. His low-level DNS resolver
> > > routines are in "public domain".
> > >
> > > Has anyone integrated djb's public domain resolver code into libc?
> > I didn't see that the djbdns license declared it to be in the
> > public domain.
> I am not sure where either. But DJB noted to bugtraq
> <20020704164247.30990.qmail at cr.yp.to> a while back that:
> The .[ch] files (dns.h, dns_dfd.c, dns_domain.c, dns_dtda.c, dns_ip.c,
> dns_ipq.c, dns_mx.c, dns_name.c, dns_nd.c, dns_packet.c, dns_random.c,
> dns_rcip.c, dns_rcrw.c, dns_resolve.c, dns_sortip.c, dns_transmit.c,
> dns_txt.c) and all necessary lower-level .[ch] files are now in the
> public domain.
> This is also mentioned at http://cr.yp.to/djbdns/res-disaster.html
Yes, I saw this note at that location. However, I did not see
a claim and then a disclaim in the source files themselves.
> Looking at this source (djbdns-1.05), I don't see any copyrights or
> licenses in any of these individual files.
Exactly. Berne states that any files not explicitly disclaimed
by the author are inherently copyright the author, and without an
explicit disclaim by the author of record stating that it's in the
public domain, or a license, the code is not legal to use, since
nothing gives me any rights to it.
> > 3) In accordance with his standard diatribe on SRV and other
> > new record types, he only supports address records, MX,
> > and TXT records, which is less than useful in the real
> > world.
> I have no answer; I do not (knowlingly) use SRV records.
Too bad. They are required for zeroconf, and "Rendevous".
> I haven't looked at it closely. I just read that it is "designed to
> replace the old BIND res_*/dn_* library" at
Yes, in about the same way that Windows NT was designed to replace
UNIX. 8-). Not plug compatible...
> I don't know how easy it would be (or if it would be worth it) to create
Doing so would actually defeat his purpose in creating his new
API, at least according to the page you referenced on his site.
> Anyways, I am curious if anyone uses it (or has tried it) as an
I looked at it. The API is "OK", though it's not inherently
thread safe, unless you implement thread local storage, or open
a socket per outstanding request, either of which are not nice.
It's inherently reentrant, so in theory it could be made thread
safe relatively easily, if you wanted to put in the effort.
With no license attached to the code, though, it was uninteresting
to me to adopt a new API, when I could write my own and not be
under the license cloud, at the same time maintaining binary
More information about the freebsd-chat