Re: [Q] DNS(bind) ER model

Steve Atkins wrote:
>
> On Aug 15, 2008, at 12:16 PM, Andrew Sullivan wrote:
>
>> On Fri, Aug 15, 2008 at 07:44:36AM -0700, Roderick A. Anderson wrote:
>>
>>> Thanks again. This is a pretty specialized application (at this
>>> time) so
>>> the RRTYPEs used are limited. I am trying to make the model and Pg
>>> implementation as generic as possible in case it gets released into the
>>> wild later.
>>
>> I made the mistake in the past of not supporting the unknown type, and
>> regretted it. The nice thing about implementing unknown is that you
>> can automatically add another RR later, even if you're not sure what
>> it's supposed to look like.
>
> +1
>
>>> plus the company I'm doing this for gets some strange requests from
>>> their
>>> customers -- not always correct or logical. :-(
>>
>> We DNS geeks have seen every mistake in the book, and some of the
>> worst ideas are still being developed. (In Dublin, I heard someone
>> from the DKIM working group at last suggest that maybe using the TXT
>> RRTYPE wasn't such a hot idea. I think it's now 5 years since the DNS
>> folks pointed out that TXT was going to cause headaches later. Sigh.)
>
> The DKIM people have been pointing that out for at least as long.
>
> Guess why they still went with the TXT record? Mostly because of the
> number of lame self-service DNS interfaces that don't support much
> apart from A, MX, CNAME and TXT. (To bring it on-topic, mostly
> because they use very simplistic database backends, I suspect...)
>
> Back to the original problem... I'm not sure there's a generic good
> structure for DNS data, it'd depend a lot on what you were planning
> on doing with it. Serving DNS directly out of the database is
> a very different set of needs to basic self-service management, which
> is a different set of needs to enterprise intranet DNS and so on.

Here is the hitch. It is for a application to be used in-house.
Actually several applications with all tied together quite closely.

1. Domain information: owner, webmaster, registrar, email manager, etc.
2. IP address allocation: There are several non-contiguous blocks of
addresses and they tend to be assigned to a specific system or client.
3. DNS things: This will not be a name server but be used build
named.conf and the zone files.
4. And tying the above together an application to let a
tech/support/sales person add a new domain and have it automagically
assigned the correct IPs for web, mail, ftp, and all that other stuff.
5. Finally a application to allow the system people to add, change,
reassign, and delete domain and zone file entries.

Rod
--

>
> Cheers,
> Steve
>
>