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

DENTS: A call for help



Hello!  I hope this message is welcome here; I'll only post it once
regardless.

I am a member of a team of programmers developing a new DNS server called
Dents.  You can find out more information on Dents at http://www.dents.org.

When I was at LinuxExpo last week, a prominent member of the Linux
community suggested that I post here about Dents, for the following
reason: the present dominant name server, named from the BIND suite, is
licensed under a Berkeley license, and Paul Vixie has publicly spoken
several times of his interest in taking BIND development commercial.
Heck, Microsoft's DNS server in WinNT is just a port of BIND.  (Do they
have anything network-related that's not a port of some Berkeley-licensed
software?)  We have licensed Dents under the GPL to prevent exactly this
kind of abuse; work on Dents will not be lost.

We are close to releasing v0.1.0 of Dents.  We plan for this to be our
first production-quality release.  We have not done any optimization
yet, and we still have a lot of development to do, but we are protocol
compliant and fairly protocol feature complete, so we believe that
people can actually begin running Dents in progressively more important
production environments.

We have not solicited general involvement previously because the core of
the Dents engine and the main features were not done, and we were afraid
that more cooks would spoil the soup.  Now that the main features are in
place, we would like to involve more people in the development of Dents.
We very much need to accelerate the development process if we are to fulfil
our goal, which is to become the best and most widely-used name server in
existence.  I am sending this mail in the hope that some Debian developers
will be interested in joining us and helping us reach our goals.

We need people to:
	- do feature development, esp. on the control facility (see below);
	- help us with module code clean up.  Some of our driver modules
	(see below) predate the module system, and so the division of
	code between them and the server is not very clean;
	- help us continue to develop the core protocol engine to support
	more recent RR types and DNS extensions like DNSSEC;
	- generally help out.

Interested parties should read our web page, join our mailing list,
check our code out of CVS, and, once they've written some code, contact
me to arrange CVS write access.  We can use people of almost any skill
level for tasks from actual coding to packaging (dpkg control files etc.
wanted) to assisting with the build enironment to documentation to web
page maintenance.  If you are a non-coder but want to help a free software
project, then we would love to work with you.

Below is more info on the project.  Again, I apologize if this is an
inappropriate message for this forum.  Thanks a million for producing
such a great distribution!

--
Todd Graham Lewis                        Postmaster, MindSpring Enterprises
tlewis@mindspring.net                                (800) 719-4664, x22804

"A pint of sweat will save a gallon of blood."          -- George S. Patton


DENTS INFORMATION
Todd Lewis <tlewis@mindspring.com>
Wed May 26 11:54:39 EDT 1999
======

CODE BASE: Dents is a from-scratch implementation of the DNS
specifications.  Dents is coded in ANSI C using the POSIX environment.

LICENSE: Dents is licensed under the GNU GPL.

FEATURES:

- Dents is written in ANSI C using only POSIX routines.  We are seriously
considering embracing glib as a helper library, for reasons explained
below.  The primary development platform is Linux.  (If my home machine is
the primary development machine, then the primary platform is Debian.  8^)
We use autoconf, etc., for configuration, and libtool to generate our
shared object module files.

- Dents features a modular driver system.  Under this system, zones are
"mounted" into the name space using a driver, much as a file system
is mounted into the file space using a fs driver.  Under this system,
zones can be stored as they traditionally are, in flat zone files,
but zone data may also be drawn from relational databases (as in the
MySQL module now under development), from hierarchical databases (like
the Berkeley DB driver now under development), or even generated on
the fly algorithmically (as in our "forward-reverse lookup" module,
where in-addr names are generated by base-32 encoding the IP address,
allowing one to serve infinite numbers of in-addr's in constant memory.)
If you can imagine a way to generate DNS data, then we think that you
can use our module system to make your idea a reality.  See the document
on our web page which describes how to write a driver module for more
info.  http://www.dents.org./modules/modules.html

- Dents features a CORBA-based control facility (ctlfac) which will allow
many previously impossible feats:

	+ administrators will be able to load, unload, and reload zones
	on the fly, without restarting the server;

	+ users will be able to edit zone data in a transactional way
	which does not require reloading and redistributing the zone,
	provided that the underlying driver module supports these features;

	+ administrators will be able to delegate editing privileges
	to users;

	+ statistics will be queryable interactively and collectable
	with tunable granularity based on originating IP address;

	+ the ctlfac is already used to export information to the UCD
	SNMP daemon, allowing us to implment RFC-1611, the DNS Server
	MIB.  This work took a single afternoon by an inexperienced
	programmer (me), demonstrating how powerful the CORBA interface
	can be.

The ctlfac exists in skeleton form (i.e., CORBA works and some
interfaces exist), but most of the planned features remain to be
implemented.  See the design doc on our web page for more info.
http://www.dents.org./ctlfac/ctlfac.html (slightly out of date)

- We are segregating our tree code, which is used to store the hierarchical
information of DNS within Dents.  We hope that, once we can replace the tree
engine in a modular way, we will be able to experiment with caching engines
that increase locality of oft-hit DNS data.  DNS is especially amenable to
these sorts of optimizations, and so we hope that by this means we will be
able to have commonly-hit names reside high in the hardware cache hierarchy,
resulting in much faster response times for those names.


Reply to: