Re: LDAP, DNS, & M-cards

From: Christopher Browne <>
Date: 19 Apr 2004 00:20:20 GMT
Message-ID: <c5v603$66o41$>

In an attempt to throw the authorities off his trail, "Dawn M. Wolthuis" <> transmitted:
> "mAsterdam" <> wrote in message
> news:4081f386$0$568$
>> Dawn M. Wolthuis wrote:
>> > ... What I haven't been able to figure out is if the "record types" are
> hosted
>> > in separate tables (one table per type) ...
>> AFAIK the DNS is a distributed hierarchical database
>> implemented as a protocol.
>> Any server or resolver complying to that protocol could be said to
>> be part of the dbms. Any such program is free to choose whatever way to
>> maintain it's part of the data, as long as it talks with the other
>> programs in adherence to the protocol. BIND is such a program.
> so, in theory, a DNS implementation could use a relational database?

In practice, some "vendors" actually do so.

UltraDNS would be a good case in point, using Oracle as their 'data store.' <>

It is uncertain whether they use it in a particularly 'relational' way, or whether they use it similarly to the way SAP uses databases as "rather dumb" data stores.

>> > or if DNS has that "M-card design pattern" thing going.
>> What's that?
> When a single "file" is used to store records with varying schema,
> it needs one template/schema from which one can determine which
> schema to apply to a particular record. This was done all of the
> time (and likely still is) with flat sequential or index sequential
> files, particularly with the input records into batch processing.
> It came from the "card deck" era. A file used for updating the
> database might have an "M" in the first column and the batch process
> would then look at this record as an "M card" in order to maintain a
> "master file" and then a "T" in the first column for a transaction.
> I don't know if there is any common terminology used today for such
> an approach, given that an RDBMS would not allow this, so I've
> referred to it as an "M-card" design pattern. It is not frequently
> warranted today, but there are times when this design scenario might
> be very useful.

That would presumably be a _process_ question, as opposed to a _database_ question.

BIND 'zone files' do contain numerous sorts of records; this enforces between zero and nothing on how one would use a database system to store the data.

But it seems pretty usual for "Pickies" to conflate those things, which makes it rather more difficult to "pin down" either process or storage.

>> > Does anyone know how DNS handles these different record types or can you
>> > point me to a good URL for more info that would describe the underlying
> data
>> > structures?
>> Every participating program needs to have some underlying data stucture,
>> of course - but they may all be different.
> So, then I'm curious whether these "record types" are just part of
> parameter strings in all cases, or whether any implementations of
> DNS actually store records of varying "types" within the same file.
> I would rather refer to this data design pattern in a way that those
> a bit younger than I might be able to relate to. Thanks. --dawn

Look for any BIND "HOWTO," and you'll presumably see that the serialized form of a zone file does indeed store many different "types" of records in a single file.

This of course imposes _nothing_ on the implementation of a DNS server, which may use any sorts of data structures the implementor wishes to use.

output = reverse("gro.gultn" "_at_" "enworbbc")
"Usenet is like a herd of performing elephants with diarrhea; massive,
difficult to  redirect, awe-inspiring,  entertaining, and a  source of
mind-boggling amounts of excrement when you least expect it."  
-- Gene Spafford (1992)
Received on Mon Apr 19 2004 - 02:20:20 CEST

Original text of this message