Using DNS to manage the network... deep thoughts.

Nicholas Ritter ritter at lfc.edu
Sat Jun 30 00:27:42 UTC 2001


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have been working on a software package for my employer to
accomplish the same ends...it uses BIND 8, and DHCP v2, data is
stored within and SQL database, and administrated through both SQL
command line, and forms based web interface. The software is written
in Perl, and PHP. 

This summer I have been considering fine tuning it a little and
releasing it for public consumption. It still need some work to do
everything you have mentioned (which is everything I want it to do.)
We have been using it at the college here for the last year with
great success.

If anyone wants details, or to help with the design of it...let me
know. The software is currently called NOMAN, and it is missing some
key features, but I am all for free solutions to problems.

Nicholas Ritter
Network Administrator
Lake Forest College

- ----- Original Message ----- 
From: "Chan Wilson" <cwilson at slurp.corp.sgi.com>
Newsgroups: comp.protocols.dns.bind
To: <comp-protocols-dns-bind at moderators.isc.org>
Sent: Friday, June 29, 2001 5:54 PM
Subject: Using DNS to manage the network... deep thoughts.


> 
> Hello, all.
> 
> I've got one of those "legacy enterprise" type of problems that I'm
> pondering ideas and solutions for.  Hundreds of domains, ten of
> thousands of nodes, half-a-dozen /16's worth of address space.  99%
> Bind4 and /etc/hosts (gen zones via inhouse tool), DHCP (but
> naturally no DYNDNS), and oh let's not forget sub /24 networks. 
> The tangles in this are myriad.
> 
> The goal is to reduce the complexity and administrative load, as
> well as improve the offering in as many ways as possible.  This
> means...  
> 
> * Reducing and restructuring the domains -- regionalizing into
> three global parent domains.
> 
> * Centralizing management -- historical reasons for decentralized
> management do not hold true today, and DBMS/networks/everything is
> much better than it was in '86.
> 
> * Improve visibility and control "over the network", such as:
> ** what the network space utilization is (both DHCP and fixed)
> ** physical location of nodes and networks
> ** interconnections between networks
> 
> 
> I've looked at some of the commercial offerings, and they all seem
> to fall short in one area or another, lack enough "hooks" for
> customization, or "lock in" to a specific vendor.  Some seem more
> promising than the others, so there's a short list to investigate
> further.
> 
> Pondering these problems and reading through the DNS RFCs for
> potential tips and clues, I have come to the general conclusion
> that there is very little preventing one from building such an
> enterprise class DNS solution with the DNS information itself.  The
> explicitly defined RRsets cover quite a bit of this ground, and the
> freeform TXT record can fill any gaps.  Incorporating an
> alternative backend dbase (the bind9 sdb interface to LDAP, for
> example) can be utilized to ease the development of administrative
> tools.  
> 
> But of course, there's issues.  Tools need to be coerced into
> producing RFC1101 and RFC1876 relevant RRs.  Shortcomings in the
> existing bind9 sdb interface appear to make using a backend dbase
> problematic with DYNDNS [RFC2136], especially if a "cloaked master"
> is used to introduce "bind-side" caching.  There doesn't appear to
> be any well defined mechanism to determine interconnects (gateways)
> between networks; RFC 1035 suggests the use of PTR records but
> later RFCs tend to contradict that practice.  Lastly but not least
> is the complexity introduced by sub /24 networks in a distributed
> environment, both in constructing the in-addr zones and attempting
> to manage/visualize the networks and utilization.
> 
> These are all solvable problems individually, but taken together
> are a tad overwhelming.  I'd be interested in hearing thoughts and
> suggestions about this.
> 
> thanks,
> 
> --Chan
> 
> --
> Information Services requires Information to Serve.
> 
>   // Chan Wilson cwilson at sgi.com
>  //  Enterprise Network Services +1-650-933-9515

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOz0c+QreEi8cxHXCEQJqdwCguHJ4GBfX1Kk4mwgadsL2Pxx1yGsAnRtV
clYKB9htq0hp4mBXTC7q15fz
=EWFI
-----END PGP SIGNATURE-----




More information about the bind-users mailing list