We have been running QIP for over 2 years now. It has
given us very effective mechanisms to allow departmental
network administrators to make changes to the parts of
our DNS which they manage.
There is one fundamental design conflict with BIND
however: if you are allowing dynamic DNS updates, BIND
and QIP each maintain a repository of DNS information
which they consider canonical. There currently exists
no mechanism by which they can be brought into sync
except brute force (QIP generates flat files and BIND
is forced to load them on the assumption that QIP is
the correct). This brute force approach has some
problems however because BIND believes it owns the
flat files when dynamic updates are being performed
and under some circumstances it will overwrite the
zone file when told to reload, tossing the files
generated by QIP. It seems to me that this is only
likely to get to be a bigger problem as integration
with Win2k/AD brings more dynamic updates.
Scott
Thanks,
Chris.
"Scott S. Bertilson" wrote:
> There is one fundamental design conflict with BIND
> however: if you are allowing dynamic DNS updates, BIND
> and QIP each maintain a repository of DNS information
> which they consider canonical. There currently exists
> no mechanism by which they can be brought into sync
> except brute force (QIP generates flat files and BIND
> is forced to load them on the assumption that QIP is
> the correct).
In 5.x, we have a CLI that works with any DNS server that supports
zone transfers which pulls new information out of the DNS server and
adds it to the QIP database. Thus retaining any dynamic updates that
were made by non-QIP sources (such as Windows 2000 domain
controllers). This CLI should be run at intervals or before a DNS
configuration generation to keep the QIP database up to date.
In 6.0, we have a continuous method for keeping the QIP DB in sync
with dynamic DNS zones whereby if you are using the Lucent DNS server,
it can be configured to send dynamic updates from non-QIP sources
directly to the QIP database as it receives them.
I don't want to burden this newsgroup with the details, but if you
would like more information concerning the 5.x CLI, you can contact
QIP support. If you would like to find out more about the new 6.0
feature, you can contact me directly (since 6.0 has not yet been
released).
>This brute force approach has some
> problems however because BIND believes it owns the
> flat files when dynamic updates are being performed
> and under some circumstances it will overwrite the
> zone file when told to reload, tossing the files
> generated by QIP.
Yes, we have seen this issue. We changed our version of DNS not to
overwrite the new config files.
If you are running BIND, you can run a user exit during the push that
shuts down the DNS server, copies over the new zone files, removes any
log files, and restarts the server. Thus avoiding the problem you
described. You can contact our support department if you would like a
copy of these user-exits.
>It seems to me that this is only
> likely to get to be a bigger problem as integration
> with Win2k/AD brings more dynamic updates.
We believe that with the polling and continuous models of pulling
information out of DNS and into QIP, QIP will work well in a highly
dynamic DNS environment such as a network with many Windows 2000
machines.
--
Alexis MacFarlane
VitalQIP Software Development
Lucent Technologies