NSI policy on lame delagations

Mon Nov 23 07:53:33 UTC 1998

> How about simply using libdb.a from SleepyCat Software?  It does all
> cacheing and can be used with threads.  And it also makes dynamic
> updates a breeze.

I've been talking to Keith about this since before DB was first released.
There are some reasons owing to key semantics why we can't just use DB:
unless we stored the fully qualified domain name in the key of every RR,
there's no "find parent" operation.  This is because there's no small
integer "object ID" to use when one DB object has to reference another.
You just have to instantiate its key, and the choice is therefore a fully
qualified key (deadly for space reasons) or an application-generated object
ID (deadly for performance reasons).

Bob Halley once expressed our #1 rule about DNS implementation designs as
"if you have an idea you think will work, multiply everything you know by
six million and think about it again."

We know that we need zones larger than virtual memory.  We would have used
DB if we could have.  We will continue talking to Keith and Margo about it;
they're as interested in this as we are.

> SQL (or any other kind of relational database for that matter) is
> clearly an overkill.

If your DNS is not part of an infrastructure data management system, then
that is a true statement.  However, many larger sites integrate their DNS
with their existing database systems so that there can be a single source
of authentic data for the Entreprise.  At this moment, they have to do this
by exporting their zones into text files that BIND can read.  Suboptimal.