Enterprise Class DNS

[Kevin Darcy]

bobbarber99 at yahoo.com wrote:

>I am working with a company that has implemented Lucent's QIP product.
>This is apparently a
>repackaging of DNS, DHCP, and so forth with a database backend to drive
>it all and some kind
>of frontend tools to manage it.
>
>I cannot seem to find much info on QIP.  The Lucent website mentions it
>last in the late 1990s.
>So ... I have a few questions:
>
>1) Is this a current product?
>
Yes. We're running the latest version (6.2) here, as well as earlier 
versions in other parts of the company.

>2) Is there an open source equivalent replacement suite of tools
>bundled together this way?
>
Depends on what you mean by "this way". AFAIK, there's nothing in the 
Open Source world that implements the "Message Service" layer of QIP, 
which is kind of the "plumbing" that allows all of the various pieces to 
talk to each other. As for the individual components, DNS, DHCP, with or 
without RDBMS backends, etc., obviously there are Open Source packages 
that will do each one of those individually, and things like Webmin 
purport to be able to put a GUI frontend on such subsystems. I'm just 
not aware of any Open Source package or packages that provide the same 
level of integration as proprietary products like QIP (don't get me 
wrong, I think QIP is far from perfect, but it does a fairly good job on 
the integration front).

>3) When bind is deployed in really large corporate settings, what tools
>do you all recommend
>    for managing its configuration databases?
>  
>
I don't know that I _recommend_ it, but our pre-QIP environment 
consisted of a fancy Perl script running on all of the remote 
nameservers, that would walk through our internal-DNS hierarchy and, 
based on certain conventions, determine what it should slave or stop 
slaving, and from where. That script was all we really needed to keep 
the configs up to date with respect to zone definitions. As for other 
customizations of named.conf, e.g. performance tuning, we've never 
really had a requirement to customize that on a per-server basis. Mostly 
we prevent performance issues by just buying significantly more capacity 
than we demonstrably need at any particular point in time (it's called 
"allowing for future growth" :-)

                                                                         
                                                            - Kevin