Re: LDAP, DNS, & M-cards

In an attempt to throw the authorities off his trail, "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> transmitted:
> "mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> news:4081f386$0$568$e4fe514c_at_news.xs4all.nl...
>> 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.' <http://www.ultradns.com/about_us/tech_overview.cfm>

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")
http://cbbrowne.com/info/sap.html
"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)