
Here are some answers to a few questions you might have about Domtools.


Q. WHY DID YOU WRITE THESE TOOLS USING BOURNE SHELL AND AWK SCRIPTS?

A. I didn't know Perl through most of this development.  Really!
   Everything you see in this package was written in my spare time,
   over the past few years.  I have been teaching myself Perl using
   O'Reilly's Perl books.  Rewriting these tools in Perl would improve
   things in the following ways:

	1. won't need two or more files per tool (sh + awk),
	2. everything would be faster

   Bourne shell was chosen over C-shell because of startup speed.  On slower
   Unix machines, the startup time of the csh is annoying at best.  This
   factor would be painful for higher level tools, and would be worse with
   the tools that require recursion.

   The tools written in C were done so either because the job was much easier
   to do in that language (i.e. bit-level manipulations), or because the
   speed would have been _WAY_ too slow in sh or awk.


Q. WHAT WAS YOUR ORIGINAL GOAL IN DESIGNING THIS PACKAGE?

A. After learning about the great new distributed concepts of the Domain Name
   System, reading with excitement the RFC1101 document and creating the
   very first BIND databases for our site when we first joined the Internet,
   I realized that DNS was the most flexible and wide-ranging network database
   tool in existence for Internet records today.  I wanted to maintain only
   our BIND database, and have the system derive from it anything that was
   similar, such as /etc/hosts and /etc/networks tables.  There's nothing more
   annoying to the overworked System Administrator than having two or more files
   with the same information in different formats, because you can't ever keep
   them both up to date!  I also imagined graphical tools that would let you
   wander around your network, looking things over.  All of these ideas had
   two things in common.  First, they would take forever to write because they
   are all at a MUCH higher level than the low-level DNS tools we have available
   today, and second, there was much overlap in some of the intermediate
   functions, such as trying to find out "what are all the subnets within this
   network?"  Thus, Domtools was created.


Q. WHERE ARE THE MAN PAGES?

A. Sorry, no time.  Everything's in the file MANUAL, because I kept making
   improvements to masses of tools at a time; it is just easier to keep the
   documentation up to date when it is all one big file.  Maybe in version 2?


Q. WHAT ARE YOUR FUTURE PLANS FOR DOMTOOLS?

A. The bottom line is always the high-level tools, because those are the most
   useful to the person trying to get their work done.  The Internet needs
   quite a few tools, which I would like to be involved in the creation of.
   High-level tools can give you a wider view; you can start thinking of
   overall groupings, not just individual elements.  High-level tools also
   help you avoid making mistakes by prompting you for required info, range
   checking your parameters, copy & paste objects (not just lines of text),
   and so on.
   One thing that is required before ANY really great high-level tools can
   be implemented is to make sure that DNS databases are Set Up Right.
   This is where "Domain Lint" comes in handy.  Verify your database
   regularly, and you'll save everyone on the Internet a lot of trouble.
   Another thing to Set Up Right is in following RFC1101.  Yes,
   it isn't a requirement for the Internet, but it is a Really Good Idea.
   Certain tools in this package require it, and more high-level tools
   in the future won't be able to do without it.

   Imagine an X-window tool that presents your domain to you in a clear,
   graphical manner, letting you zoom around the sub-domains, click on
   "get-info" boxes to find out what type of computer that new host that
   just showed up is, who is in charge of that domain over there, and so on.
   Now imagine another graphical tool that presents your network(s) to you
   in a clear graphical manner, letting you find out about individual hosts,
   wander through a gateway into a connected network to see where it goes,
   and so on.  Zoom out to look at your whole organization, zoom in to a
   specific network element -- and print any of it on a high-quality printer.

   You want the latest PostScript map of the Internet complete with all
   first- and second-level domains, like the one on your wall from many
   years back?  No problem, but I hope you can find about 13 square feet of
   wall-space to hang it up!  (My estimate of the size, as of March 1992!)
   [Update: the "com." branch is about 24 feet long as of November 1992!!]

   Now integrate SNMP information, and you're really cruising.  Again, we're
   just eliminating having to manipulate duplicate information in different
   formats by hand.  Get or set system.sysDescr variables automatically,
   display host uptime, packet flow-rates, numbers of users, and host usage
   trends over time.  Blam, here's a graph, from which I can see that making
   that change last week fixed the load-distribution problem; what the heck,
   I'll e-mail it to my boss with a short caption below it.  :-)

--
Paul Balyoz,  Unix Sysadmin and Programmer
Domtools Consulting                           pab@domtools.com
Phoenix Arizona, USA                          pbalyoz@jammed.com
