4.4BSD/usr/src/contrib/bind-4.9/contrib/misc/ddt.info
Date: Mon, 26 Apr 93 17:45:39 GMT
From: Jorge Frazao de Oliveira <frazao@colombo.puug.pt>
Message-Id: <9304261745.AA02646@colombo.puug.pt>
Received: by NeXT Mailer (1.62)
To: vixie
Subject: Re: send me your tools
Hi,
I have implemented a package that allow to check several of the
most usually problems in DNS.
Find attached the introduction page of the manual.
This package is available in ftp.ripe.net:/tools/dns/ddt.
I'll appreciate your comments,
Thanks
Jorge Frazao
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
May 6 1992 ddt(1)
Domain Debug Tools Manual
NAME
ddt - domain debug tools
DESCRIPTION
The DNS database is a distributed database where almost all the distri-
buted bindings of the TCP/IP application level take place. This database
is managed by several primary and secondary servers running in a
master/slave fashion. During updates, there are temporary inconsisten-
cies that are more or less tolerated by the different user services. By
its nature, the database is managed in a descentralized way, with hun-
dreds, or even thousands, of individuals envolved. This is a very
interesting and valuable feature of this application. However, in con-
junction with the fact that inconsistencies must be tolerated, this col-
lective managing style may lead to the introduction of hard to find
errors. Sometimes, some of these errors can introduce several problems
and resource usage far from ideal.
Ddt (domain debug tools) is a package to help zone administrators to
avoid as much as possible these problems. The package is a set of com-
mands that allow administrators to analyze any portion of the DNS tree.
Ddt works on cached data files because, as such, it can be reasonable
efficient. A command is available to try to cache the "real world"
situation as close as possible. This command, ddt-xfer(1), is a
slightly modified version of the bind named-xfer(8) that allows the
transfer to the cache of a zone and, optionally, all its descendents
zones. If you have enough disk and bandwith, you can cache all the zones
of the world with one only command. Probably, at end, you should start
again because some of the cached zones will not reflect the real ones
anymore.
All the available commands can receive one or more zone files as parame-
ters. So, one command can spread its analysis throughout a set of
zones. With the exception of ddt-xfer(1), all commands are written in
gawk (GNU awk).
The commands available are:
ddt-xfer to cache one or more zones.
soac to analyze the RRs that describe the top node of the zone,
i.e., the NS RRs that list the servers for the zone and a
single SOA RR that describe zone management parameters.
rrc to check the semantic of the RRs, like valid host names,
names without trailing dot, etc.
grc to analyze the glue records for a zone.
mxc to analyze the MX RRs defined within a zone.
rmc to analyze the reverse mapping.
1
ddt(1) May 6 1992
Domain Debug Tools Manual
Besides the commands that allow the analysis of the zone, there are some
small commands to obtain several accounts, like number of hosts, number
of nets, number of domains, most popular names, etc. In conjunction
with some user written awk scripts, it is easy to obtain a lot of other
information. These commands are the following filters:
expand replaces the owner name of the RR by an absolute or fully
qualified name.
hosts returns all hosts in the zone.
hosts-addr returns all hosts with their ip-addresses.
hosts-domain returns all domains defined in the zones with the number
of hosts per domain.
cnames returns all nicknames in the zone.
nets returns all nets in the zone with the number of hosts per
network.
names-stat does some statistics about names.
To make the interpretation of the several messages returned by the
available commands easier, those messages are divided into four levels
of severity:
[Warning 1] You should investigate it now!
[Warning 2] Don't forget this warning!
[Warning 3] You should analyze it someday!
[Comment] You can ignore it /
DDT has not enough data to take an effective decision.
Messages belonging to [Warning 1] level are the most serious. On the
other hand, messages belonging to [Comment] level are less important,
but this doesn't mean that these messages can be completely ignored.
Unfortunately, there are some serious errors that were included in the
this level because, when the message is displayed, DDT has not enough
data (zone files) to take an effective decision.
The DDT_LEVEL environment variable is used to select what messages
should be displayed. If it has the value 1, only messages belonging to
[Warning 1] level are displayed. If it is 2 are displayed all messages
belonging to [Warning 1] and [Warning 2] levels and so on.
2
May 6 1992 ddt(1)
Domain Debug Tools Manual
The commands ddt-xfer(1), grc(1), mxc(1), rrc(1) rmc(1) and saoc (1) are
described in separate manual pages. The commands for gathering statis-
tics about zones are described below with some examples.
1) Get all zones below the domain fr. (inclusive):
ddt-xfer -z fr -f . -r inria.inria.fr layon.inria.fr
2) Get the zone ul.pt only if the serial number had changed:
ddt-xfer -z ul.pt -f . -s 199202140 muttley.ul.pt dec4pt.puug.pt
3) Generate the portuguese statistics of hostnames (All zones below pt.
are in /usr/local/ddt.cache/pt directory):
expand /usr/local/ddt.cache/pt/* | hosts | names-stat | sort -rn
4) Count hosts in a zone beginning at the node inesc.pt (The zone
inesc.pt is in the file /usr/local/ddt.cache/pt/inesc.pt):
expand /usr/local/ddt.cache/pt/inesc.pt | hosts | wc -l
5) Print the number of hosts by nets in Italy (All zones below it. are
in /usr/local/ddt.cache/it directory):
expand /usr/local/ddt.cache/it/* | hosts-addr | nets | sort -rn
Comments and suggestions are welcome.
SEE ALSO
ddt-xfer(1), soac(1), rrc(1), mxc(1), grc(1), rmc(1)
AUTHOR
Jorge Frazao