IP Address Management Tool (IPAM) for DNS and DHCP

Stephen John Smoogen smooge at gmail.com
Tue Mar 4 20:39:29 UTC 2008

On 04 Mar 2008 19:09:02 +0000, Paul Vixie <Paul_Vixie at isc.org> wrote:
> "Persiko, Mark" <Mark.Persiko at Level3.com> writes:
>  > BIND-DLZ looks highly desirable as an augmentation to a DNS management
>  > tool (by that, I mean a database with DNS information could be seamlessly
>  > tied to BIND servers.)  However, is that part of the standard
>  > distribution now, or would it need integration (and optimization) to work
>  > its way into BIND 10?
>  to the best of my knowledge, DLZ is a standard feature in late model BIND9.
>  equivilent functionality will almost certainly find its way into BIND10 (but
>  i hope we have hot-spot caches with SQL-triggered invalidation, and i hope we
>  can accept RFC2136 updates and back-propagate them into SQL, both of which
>  prevent me from running DLZ on my own zones.)  we (ISC) love that BIND9 is
>  seen as a general DNS protocol engine for other folks' DNS storage systems.
>  what i'm looking for in this thread, though, is management features like
>  clustering, XML-based config, better support for GUI, or other reasons why
>  people aren't running raw BIND9 and instead pulling in something like
>  InfoBlox, M&M, etc.  how can BIND10 better support this functionality, and/or
>  better support these vendors, than BIND9 does?

1) The ability to allow a reasonably trained person able to edit,
change, undo changes in a clearly defined methodology that can be
audited for some overall reason (ITIL for example). I need to make
sure that Joe who just got out of high school (or 2 year associates or
whatever is a minimal level of IT training these days) and has had a
couple of weeks of local IT training of what is allowed and not
allowed can enter and remove entries. I also need for it to make sure
he doesnt make mistakes.

2) The ability to limit such trained people to their sand-boxes. Joe
can edit with xy.zzy.com sub-zone but not plugh.zzy.com.

3) The ability to tie DNS and DHCP together. When he adds
dwarf.xy.zzy.com it is able to create an associated entry in DHCP or
tell him that he can't add it because the zone is full with DHCP.

4) The ability to make reports for auditing purposes and projections.
In the case where I have existing report tools.. the ability to export
what data I need out in csv etc format.

5) The ability to report issues via SNMP or similar tools to give
alerts on DHCP zones full, or
 the level of expertise of the person entering and editing data should be lower.

6) The ability to script commands in a 'higher' level language so that
items can be automated to business methods. Shipping gets computer,
puts on rfid/etc tag on computer and enters whatever data about the
system into database. When local systems admin gets the computer, they
then enter MAC/owner/etc and the data is all able to 'tracked'
together. While DNS is not the place to store all of it.. being able
to script that when I click on this web page, a DHCP item(s) and a DNS
item(s) are done quickly because the data can be injected via a
scripting ABI is good. [And the same for the opposite.]

I think that is about the major things..

Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

More information about the bind-users mailing list