The Ddt commands provide help for the administration of DNS zones. They can assume an important role in the detection of several errors in zone configuration files that otherwise would not be detected so quickly. Some of these errors are very frequent and can introduce very dangerous and resource consuming behaviors in the applications using the DNS or in the system itself.
There are still some open issues. Some of those issues are closely related with the options taken by the bind software during the zone transfers. An example of this is the problem of knowing if a glue record transferred with the zone is or is not defined in the transferred master file. We concluded that if the server from where the zone is pulled has an authoritative answer for that host, then its IP address (glue record) is always pulled with the remaining data of the zone, even if it is not defined in the zone master file. This is due to the current implementation of the bind software and will be corrected in future releases, we hope.
Other open issues are the analysis of which are the correct policies of mail routing for a zone and which are the better SOA timers to use. Ddt has no special treatment of those two issues. Mail routing is more or less a policy issue if the related site is not fully interconnected with all parts of the internet, or if there are mutual agreements for backup of mail receipt. SOA timers are also closely related with the quality of the lines available.
We have not experienced many difficulties with the fact that Ddt only works with cached data (Ddt tests if a server is running authoritative for a domain, otherwise only cached data is used). Generally, zone updates are very occasional and, when analysing only one zone, the probability of using outdated data is low. Administrators tend to run the analysis just after having cached the zone file from the primary server. In these situations, the test is run a few seconds after the caching took place. This is not the case when we analyse extensively a significant part of the tree, as for example all the sub-tree starting with the ``de.'' node. In these cases, caching time is significant, and when the analysis starts, some cached zones may not be consistent with the real ones any longer. However, these extensive analysis have, generally, the purpose of getting statistics. As the management of the DNS tree is decentralized, an administrator only deals directly with a small fraction of the zones, mainly zones directly below the zone for which he or she is directly responsible. Moreover, practice shows that, with the exception of name servers, CNAMEs and MX pointers, DNS data has, in general, only local (in the same zone) references.
During the implementation of Ddt we also took the option of ignoring TTL values (``Time To Live'') associated with the cached data. Obviously, Ddt only deals with authoritative data and it is up to its user to garantee that he or she runs the analysis on the current version of the zone database.
Finally, all the Ddt commands only analyze RRs of the Internet type (IN). This restriction is due to the few weight of others types. We decided to wait until other types of records have a wider use.
Analysing european DNS data has been an exciting exercise providing us an extensive set of examples of correct and incorrect practices, as well more confidence about the richness of European cultures. Networking in such a disparate environment is a real challenge.
The Ddt package is public domain and available in the server dec4pt.puug.pt by anonymous ftp under the name pub/ddt.1.0beta