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
