NSI policy on lame delagations

Mailman List Mirror (Read Only)
1

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.

2

Paul A Vixie writes:

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.

Yet having the advantage that when your SQL- or other-based database
fails, your nameservers don't.

3

Yet having the advantage that when your SQL- or other-based database
fails, your nameservers don't.

I don't disagree with this. There's certainly a mode where BIND should
be able to create its own b-tree by loading all of a zone and then
managing it through a memory window. But there's also a more sparse mode
where you just don't want to have another copy of your zone data, nor
the resource consumption of having to make that copy, nor the delay
between the times you pick to make that copy.

Right now there's no choice since there's no zone API. One is coming, but
not in 8.1.2++.

4

_Classic_. Jon Bentley will, no doubt, put that in Programming Pearls
III, if someone sends it to him.

Cheers,
-- jra