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

Kevin Darcy kcd at daimlerchrysler.com
Sat Jun 30 00:37:44 UTC 2001


My basic approach is: the DNS database is for DNS information, i.e.
name-to-address, address-to-name, mail-exchanger, etc. information, and
nothing else belongs there. Now, having said that, I have no problem with
information from disparate databases being *merged* into a single
consistent interface, e.g. specify the host name, get the IP address
and/or mail-exchanger information from DNS, get the asset/inventory
information from some DBMS, get the location/contact information from an
LDAP database, get the networking information from an NMS, etc., etc.
What is *presented* to the administrator may come from multiple sources,
and they may update multiple databases from the same interface. Of
course, this means you have to keep those databases in synch with each
other, but the big payoff I think is that each database can optimize for
the type of data, and the type of data structures, that it deals with
best. In particular, I don't think it's particularly efficient or
flexible to store non-DNS data in the DNS database. For instance, I'm
pushing to get all of the "machine" data (physical location, machine
type, organization, etc.) that certain people are currently maintaining
in TXT records here, out of DNS and into an LDAP database, where it
should be much more easy to maintain, easier to search/index/etc..

Once one restricts the DNS database to only DNS information, then
maintenance can be simplified tremendously. I've converted over our
maintenance system to be based purely on Dynamic Update (straight from
the web interface to a CGI to the Dynamic Update, no database nonsense in
between). This makes it very fast, very flexible, and integrates nicely
with DHCP, Win2K and anything else coming down the pike which wants to
use Dynamic Update. When we implement the LDAP database, it'll be
maintained in parallel with this process.

I'm not sure I understand the issue with sub-/24 networks. Once you
centralize DNS maintenance, doesn't this issue go away? It seems like
there are only DNS issues here if you're decentralized and therefore have
to get into RFC 2317 ugliness etc. Or am I looking at things in a far too
DNS-centric way? On the other hand, I haven't heard anything from our
other Telecom groups to suggest that managing sub-/24 networks (and we
have lots of those) is qualitatively any more difficult than /24 or
larger...


- Kevin

cwilson at slurp.corp.sgi.com wrote:

> 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





More information about the bind-users mailing list