in-addr.arpa files....

Re: in-addr.arpa files....

From:

Date:

Time:

Well I've stared on the Filemaker Pro Application to keep my list of DNS
Entries... It works pretty well so far and I can get both the db files
and the in-addr.arpa files from it.

It seems that My app does pretty much the same as the QuickDNS Admin
except it exports the files in the proper format for an ordinary DNS
Server. It would seem that if I can do it in Filemaker Pro, then
QuickDNS Admin should be able to just whip it out. If its written in
C/C++ I could add a couple of menu options and implement it for them...

Scott<-

> ----------
> From:
> owner-quickdns-talk@menandmice.is[SMTP:owner-quickdns-talk@menandmice.
> is] on behalf of Chris Buxton[SMTP:cbuxton@ix.netcom.com]
> Reply To: quickdns-talk@menandmice.com
> Sent: Saturday, March 8, 1997 10:00 PM
> To: quickdns-talk@menandmice.com
> Subject: RE: in-addr.arpa files....
>
> >It just
> >makes sense that if I have the following Entries:
> >
> > scott-mac.healdsburg.net A 206.13.44.9
> >; Scott's Mac
> > 9.44.13.206.in-addr.arpa PRT scott-mac.healdsburg.net
> >; Scott's Mac
> >
> >It just seems that the second can be created from the first. If the
> >domain files are loaded into a internal Database when the app starts,
> >then why not just create the internal in-addr.arpa database on the
> fly
> >when loading the domain files. I would rather wait a bit more on
> >startup then have to maintain the files myself.
> >
> >In the case where you would like to override the entry in the
> internal
> >database, then put it in the file and have the contents of the file
> >override the defaults of the one already there.
> >
> >From a programming standpoint it seems like its a piece of cake to
> >implement.
>
> What if you're not serving the data from the same server? I.e., what
> if
> you've got domain zones served one place, reverse zones served
> elsewhere?
> Would that be a universal preference? What if you've got some of the
> reverse zones on the same server as the domain zones? So do you make
> it
> setable per domain? What if you're not responsible for all the
> networks
> that a domain has hosts in? You'd have to make it a preference setable
> at
> the record level. At that point, what's the point?
>
> It may seem tedious, but so's double entry accounting. That doesn't
> mean
> there isn't a good reason for it.
>
> A possible solution for you is to create a database of names and
> addresses.
> You could automate the process of exporting the data into BIND-format
> zone
> files, and then automate the process of converting those to
> QDNS-format
> zone files. Thus, when you've made a change, press a button on the
> screen
> and have your zone files updated automatically based on the contents
> of the
> database. I could do that in FileMaker Pro, and it would only take me
> maybe
> 8 hours. Is it worth that kind of time/money to you?
>
> For my needs, it isn't worth it, but then I only manage about a dozen
> domains, and they don't change much. Besides, I'm not responsible for
> the
> reverse zone for the network they all reside in - my client is renting
> space in an office of NT servers.
>
>
> -------------------------------
> Chris Buxton
> Independent Consultant
> Specializing in Web Development
>
>

Sales:
888/4-DPOINT

Support:
858/452-3696