You should start caching zones with the command ddt-xfer. This command allows pulling zone files as we have already presented above. In the example below, the zone ``xx.com'' is pulled to the local cache if and only if the version number defined in the file ``xx.com'' (in the current directory) and the true version number don't match. If the server ``server.xx.com'' is not available, the server ``server.yy.com'' is queried.
ddt-xfer -z xx.com -f . server.xx.com server.yy.com
To pull all the sub-zones of ``xx.com'', the ``-r'' parameter should also be included:
ddt-xfer -z xx.com -f . -r server.xx.com server.yy.com
After caching zone files, you can start your analysis. Start of authority RRs (SOA) are one of the most error prone and dangerous RRs. These RRs introduce a zone and its parameters (mostly timers). Soac is a command that analyzes SOA RRs (i.e., RRs describing the top node of a zone). It verifies if the timers of the SOA RR are consistent, i.e., if they are inside an interval of values defined in the .SOA-timers file. It also verifies if the NS RRs are sound, i.e., if the listed servers have authoritative answers for data belonging to the zone. Moreover, it verifies version numbers matching. The example shown below presents a situation where the refresh time is very low (6 minutes). This kind of error is very usual and can cause unnecessary traffic. The second message is more serious, because the ``server.xx.com'' should be an authoritative server but it isn't.
$ soac xx.com SOA Record Refresh 360 [recommended value: 28800] Authoritative servers server.xx.com [Not authoritative answer]
The command rrc finds syntactic and semantic errors in the master file. Errors like names without trailing dot, invalid host names, etc., are caught. All the errors in RRs associated with names outside the zone are also included. However, the messages related with this kind of errors got [Comment] severity level because, during the analysis, the fact that those zones were also analyzed is not recorded. In the example below, a syntax error that is caused by the absence of a dot in the master file is shown. This kind of error is very usual. The second message warns about a RR where a host should be introduced instead of its address ``192.0.0.1''.
There are also two messages about an undefined host name. The first one is more serious because the name of the host belongs to the set of authoritative data (i.e., inside the analyzed zone).
$ rrc xx.com Perharps name without trailing dot: host.xx.com.xx.com Hostname 192.0.0.1 should be in domain notation No A/CNAME record found for server.xx.com No A/CNAME record found for server.yy.com [Can't verify it]
Glue records4 are a kind of RRs that is generally responsible for the presence of most inconsistencies in the DNS, therefore Ddt supplies a command to check these RRs – grc. This command checks glue records in the zone file. The glue record can be present in the transferred (cached) zone. However, due to the behaviour of the bind transfer, it can not be really in the true master file. Therefore, the diagnosis messages have only the purpose of warning the administrator for the possibility of their existence. All glue records found are separated in two kinds, necessary and unnecessary glue records. When the glue record introduces the address of a server of a delegated domain and that server belongs to a delegated domain, the corresponding glue record must be present. Below, an example is shown with the two kinds of glue records: necessary and unnecessary. The first one is necessary because it's needed to ``glue'' the zone with its delegated sub-zone, since the server is itself inside the sub-zone.
$ grc xx.com Necessary glue records. Name servers of delegated domains. server.yy.xx.com IN A 192.1.1.1 Unnecessary glue records. If present, should be removed. server.yy.com IN A 192.0.0.1
As MX RRs are often misunderstood, and in spite of knowing that it is impossible to find a generic policy for mail routing (this is sometimes more a matter of politics than of technics) we have decided to include a command allowing its analysis in the Ddt package. This command analyzes MX RRs present in the cached zone file. Its only purpose is to highlight possible configuration errors. Those warnings are considered as evidence of possible strange mail routing policies in two cases. If there are MX RRs pointing to hosts outside the zone with preference value less than those MX RRs pointing to internal hosts, a message is displayed. If there are MX RRs pointing to hosts outside the zone, a second message is also displayed. The last case is a more normal one. The purpose of the warning is the highlighting of the policy(ies) used in a region, or in a country, etc. In the following example we can show some examples of strange mail routing policies.
$ mxc xx.com MX record pointing to an external host. xx.com IN MX 20 mailhost.yy.com MX record to local or delegated host after MX record to external host. yy.xx.com IN MX 10 mailserver.yy.com
Finally, we have introduced a command to verify reverse mappings – rmc. This command verifies if there are some PTR RRs binding an address with a host name without an A RR binding the name with the same address. It also verifies the opposite situation, i.e., it tests if there are any PTR RR for the pair host/address defined in a A RR. As can be seen below, we can see that there is an A RR for host10.xx.com. with the address 192.0.0.10 but the RR defining the reverse binding doesn't exist. The second message indicates the opposite situation, i.e., a PTR RR is present, but the A RR for same host/address isn't.
$ rmc xx.com 0.0.192.in-addr.arpa ## XX.COM. ## No 10.0.0.192.in-addr.arpa PTR RR found for host10.xx.com. ## 0.0.192.IN-ADDR.ARPA. ## No host5.xx.com. A RR found with 192.0.0.5