doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc1713.txt b/doc/rfc/rfc1713.txt
new file mode 100644
index 0000000..7562454
--- /dev/null
+++ b/doc/rfc/rfc1713.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                           A. Romao
+Request for Comments: 1713                                          FCCN
+FYI: 27                                                    November 1994
+Category: Informational
+
+
+                        Tools for DNS debugging
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   Although widely used (and most of the times unnoticed), DNS (Domain
+   Name System) is too much overlooked, in the sense that people,
+   especially administrators, tend to ignore possible anomalies as long
+   as applications that need name-to-address mapping continue to work.
+   This document presents some tools available for domain administrators
+   to detect and correct those anomalies.
+
+1. Introduction
+
+   Today more than 3,800,000 computers are inter-connected in a global
+   Internet [1], comprising several millions of end-users, able to reach
+   any of those machines just by naming it.  This facility is possible
+   thanks to the world widest distributed database, the Domain Name
+   System, used to provide distributed applications various services,
+   the most notable one being translating names into IP addresses and
+   vice-versa.  This happens when you do an FTP or Telnet, when your
+   gopher client follows a link to some remote server, when you click on
+   a hypertext item and have to reach a server as defined by the URL,
+   when you talk to someuser@some.host, when your mail has to be routed
+   through a set to gateways before it reaches the final recipient, when
+   you post an article to Usenet and want it propagated all over the
+   world.  While these may be the most visible uses of DNS, a lot more
+   applications rely on this system to operate, e.g., network security,
+   monitoring and accounting tools, just to mention a few.
+
+   DNS owes much of its success to its distributed administration.  Each
+   component (called a zone, the same as a domain in most cases), is
+   seen as an independent entity, being responsible for what happens
+   inside its domain of authority, how and what information changes and
+   for letting the tree grow downwards, creating new components.
+
+
+
+
+
+Romao                                                           [Page 1]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   On the other hand, many inconsistencies arise from this distributed
+   nature: many administrators make mistakes in the way they configure
+   their domains and when they delegate authority to sub-domains; many
+   of them don't even know how to do these things properly, letting
+   problems last and propagate.  Also, many problems occur due to bad
+   implementations of both DNS clients and servers, especially very old
+   ones, either by not following the standards or by being error prone,
+   creating or allowing many of the above problems to happen.
+
+   All these anomalies make DNS less efficient than it could be, causing
+   trouble to network operations, thus affecting the overall Internet.
+   This document tries to show how important it is to have DNS properly
+   managed, including what is already in place to help administrators
+   taking better care of their domains.
+
+2. DNS debugging
+
+   To help finding problems in DNS configurations and/or implementations
+   there is a set of tools developed specifically for this purpose.
+   There is probably a lot of people in charge of domain administration
+   having no idea of these tools (and, worse, not aware of the anomalies
+   that may exist in their configurations).  What follows is a
+   description of some of these programs, their scope, motivations and
+   availability, and is hoped to serve as an introduction to the subject
+   of DNS debugging, as well as a guide to those who are looking for
+   something to help them finding out how healthy their domains and
+   servers are.
+
+   Some prior knowledge from the reader is assumed, both on DNS basics
+   and some other tools (e.g., dig and nslookup), which are not analyzed
+   in detail here; hopefully they are well-known enough from daily
+   usage.
+
+2.1. Host
+
+   Host is a program used to retrieve DNS information from name servers.
+   This information may be used simply to get simple things like
+   address-to-name mapping, or some more advanced purposes, e.g.,
+   performing sanity checks on the data.  It was created at Rutgers
+   University, but then Eric Wassenaar from Nikhef did a major rewrite
+   and still seems to be actively working on improving it.  The program
+   is available from ftp://ftp.nikhef.nl/pub/network/host_YYMMDD.tar.Z
+   (YYMMDD is the date of the latest release).
+
+   By default, host just maps host names to Internet addresses, querying
+   the default servers or some specific one.  It is possible, though, to
+   get any kind of data (resource records) by specifying different query
+   types and classes and asking for verbose or debugging output, from
+
+
+
+Romao                                                           [Page 2]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   any name server.  You can also control several parameters like
+   recursion, retry times, timeouts, use of virtual circuits vs.
+   datagrams, etc., when talking to name servers.  This way you can
+   simulate a resolver behavior, in order to find any problems
+   associated with resolver operations (which is to say, any application
+   using the resolver library).  As a query program it may be as
+   powerful as others like nslookup or dig.
+
+   As a debugger, host analyzes some set of the DNS space (e.g., an
+   entire zone) and produces reports with the results of its operation.
+   To do this, host first performs a zone transfer, which may be
+   recursive, getting information from a zone and all its sub-zones.
+   This data is then analyzed as requested by the arguments given on the
+   command line.  Note that zone transfers are done by contacting
+   authoritative name servers for that zone, so it must be possible to
+   make this kind of request from such servers: some of them refuse zone
+   transfers (except from secondaries) to avoid congestion.
+
+   With host you may look for anomalies like those concerning authority
+   (e.g., lame delegations, described below) or some more exotic cases
+   like extrazone hosts (a host of the form host.some.dom.ain, where
+   some.dom.ain is not a delegated zone of dom.ain).  These errors are
+   produced upon explicit request on the command line, but you may get a
+   variety of other error messages as a result of host's operations,
+   something like secondary effects.  These may be mere warnings (which
+   may be suppressed) or serious errors - in fact, warning messages are
+   not that simple, most of them are due to misconfigured zones, so it
+   might not be a good idea to just ignore them.
+
+   Error messages have to do with serious anomalies, either with the
+   packets exchanged with the queried servers (size errors, invalid
+   ancounts, nscounts and the like), or others related to the DNS
+   information itself (also called "status messages" in the program's
+   documentation): inconsistencies between SOA records as shown by
+   different servers for a domain, unexpected address-to-name mappings,
+   name servers not responding, not reachable, not running or not
+   existing at all, and so on.
+
+   Host performs all its querying on-line, i.e., it only works with data
+   received from name servers, which means you have to query a name
+   server more than once if you want to get different kinds of reports
+   on some particular piece of data.  You can always arrange arguments
+   in such a way that you get all information you want by running it
+   once, but if you forget something or for any reason have to run it
+   again, this means extra zone transfers, extra load on name servers,
+   extra DNS traffic.
+
+
+
+
+
+Romao                                                           [Page 3]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   Host is an excellent tool, if used carefully.  Like most other
+   querying programs it may generate lots of traffic, just by issuing a
+   simple command.  Apart from that, its resolver simulation and debug
+   capabilities make it useful to find many common and some not so
+   common DNS configuration errors, as well as generate useful reports
+   and statistics about the DNS tree.  As an example, RIPE (Reseaux IP
+   Europeens) NCC uses it to generate a monthly european hostcount,
+   giving an overview of the Internet usage evolution in Europe.  Along
+   with these counts, error reports are generated, one per country, and
+   the whole information is made available in the RIPE archive.
+
+2.2. Dnswalk
+
+   Dnswalk is a DNS debugger written in Perl by David Barr, from
+   Pennsylvania State University.  You'll find the latest version at
+   ftp://ftp.pop.psu.edu/pub/src/dnswalk.  With the software comes a
+   small document where the author points some useful advice so it may
+   be worth reading it.
+
+   The program checks domain configurations stored locally, with data
+   arranged hierarchically in directories, resembling the DNS tree
+   organization of domains.  To set up this information dnswalk may
+   first perform zone transfers from authoritative name servers. You can
+   have a recursive transfer of a domain and its sub-domains, though you
+   should be careful when doing this, as it may generate a great amount
+   of traffic.  If the data is already present, dnswalk may skip these
+   transfers, provided that it is up to date.
+
+   Dnswalk looks for inconsistencies in resource records, such as MX and
+   aliases pointing to aliases or to unknown hosts, incoherent PTR, A
+   and CNAME records, invalid characters in names, missing trailing
+   dots, unnecessary glue information, and so on.  It also does some
+   checking on authority information, namely lame delegations and
+   domains with only one name server.  It is easy to use, you only have
+   to specify the domain to analyze and some optional parameters and the
+   program does the rest.  Only one domain (and its sub-domains, if
+   that's the case) can be checked at a time, though.
+
+   While in the process of checking data, dnswalk uses dig and resolver
+   routines (gethostbyXXXX from the Perl library) a lot, to get such
+   data as authority information from the servers of the analyzed
+   domains, names from IP addresses so as to verify the existence of PTR
+   records, aliases and so on.  So, besides the zone transfers you may
+   count on some more extra traffic (maybe not negligible if you are
+   debugging a relatively large amount of data and care about query
+   retries and timeouts), just by running the program.
+
+
+
+
+
+Romao                                                           [Page 4]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+2.3. Lamers
+
+   A lame delegation is a serious error in DNS configurations, yet a
+   (too) common one.  It happens when a name server is listed in the NS
+   records for some domain and in fact it is not a server for that
+   domain.  Queries are thus sent to the wrong servers, who don't know
+   nothing (at least not as expected) about the queried domain.
+   Furthermore, sometimes these hosts (if they exist!) don't even run
+   name servers.  As a result, queries are timed out and resent, only to
+   fail, thus creating (more) unnecessary traffic.
+
+   It's easy to create a lame delegation: the most common case happens
+   when an administrator changes the NS list for his domain, dropping
+   one or more servers from that list, without informing his parent
+   domain administration, who delegated him authority over the domain.
+   From now on the parent name server announces one or more servers for
+   the domain, which will receive queries for something they don't know
+   about.  (On the other hand, servers may be added to the list without
+   the parent's servers knowing, thus hiding valuable information from
+   them - this is not a lame delegation, but shouldn't happen either.)
+   Other examples are the inclusion of a name in an NS list without
+   telling the administrator of that host, or when a server suddenly
+   stops providing name service for a domain.
+
+   To detect and warn DNS administrators all over the world about this
+   kind of problem, Bryan Beecher from University of Michigan wrote
+   lamers, a program to analyze named (the well-known BIND name server)
+   logging information [2].  To produce useful logs, named was applied a
+   patch to detect and log lame delegations (this patch was originally
+   written by Don Lewis from Silicon Systems and is now part of the
+   latest release of BIND thanks to Bryan Beecher, so it is expected to
+   be widely available in the near future).  Lamers is a small shell
+   script that simply scans these logs and reports the lame delegations
+   found.  This reporting is done by sending mail to the hostmasters of
+   the affected domains, as stated in the SOA record for each of them.
+   If this is not possible, the message is sent to the affected name
+   servers' postmasters instead.  Manual processing is needed in case of
+   bounces, caused by careless setup of those records or invalid
+   postmaster addresses.  A report of the errors found by the U-M
+   servers is also posted twice a month on the USENET newsgroup
+   comp.protocols.tcp-ip.domains.
+
+   If you ever receive such a report, you should study it carefully in
+   order to find and correct problems in your domain, or see if your
+   servers are being affected by the spreading of erroneous information.
+   Better yet, lamers could be run on your servers to detect more lame
+   delegations (U-M can't see them all!).  Also, if you receive mail
+   reporting a lame delegation affecting your domain or some of your
+
+
+
+Romao                                                           [Page 5]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   hosts, please don't just ignore it or flame the senders.  They're
+   really trying to help!
+
+   You can get lamers from ftp://terminator.cc.umich.edu/dns/lame-
+   delegations.
+
+2.4. DOC
+
+   Authority information is one of the most significant parts of the DNS
+   data, as the whole mechanism depends on it to correctly traverse the
+   domain tree.  Incorrect authority information leads to problems such
+   as lame delegations or even, in extreme cases, the inaccessibility of
+   a domain.  Take the case where the information given about all its
+   name servers is incorrect: being unable to contact the real servers
+   you may end up being unable to reach anything inside that domain.
+   This may be exaggerated, but if you're on the DNS business long
+   enough you've probably have seen some enlightened examples of this
+   scenario.
+
+   To look for this kind of problems Paul Mockapetris and Steve Hotz,
+   from the Information Sciences Institute, wrote a C-shell script
+   called DOC (Domain Obscenity Control), an automated domain testing
+   tool that uses dig to query the appropriate name servers about
+   authority for a domain and analyzes the responses.
+
+   DOC limits its analysis to authority data since the authors
+   anticipated that people would complain about such things as invasion
+   of privacy.  Also, at the time it was written most domains were so
+   messy that they thought there wouldn't be much point in checking
+   anything deeper until the basic problems weren't fixed.
+
+   Only one domain is analyzed each time: the program checks if all the
+   servers for the parent domain agree about the delegation information
+   for the domain.  DOC then picks a list of name servers for the domain
+   (obtained from one of the parent's servers) and starts checking on
+   their information, querying each of them: looks for the SOA record,
+   checks if the response is authoritative, compares the various records
+   retrieved, gets each one's list of NS, compares the lists (both among
+   these servers and the parent's), and for those servers inside the
+   domain the program looks for PTR records for them.
+
+   Due to several factors, DOC seems to have frozen since its first
+   public release, back in 1990.  Within the distribution there is an
+   RFC draft about automated domain testing, which was never published.
+   Nevertheless, it may provide useful reading.  The software can be
+   fetched from ftp://ftp.uu.net/networking/ip/dns/doc.2.0.tar.Z.
+
+
+
+
+
+Romao                                                           [Page 6]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+2.5. DDT
+
+   DDT (Domain Debug Tools) is a package of programs to scan DNS
+   information for error detection, developed originally by Jorge Frazao
+   from PUUG - Portuguese UNIX Users Group and later rewritten by the
+   author, at the time at the Faculty of Sciences of University of
+   Lisbon.  Each program is specialized in a given set of anomalies: you
+   have a checker for authority information, another for glue data, mail
+   exchangers, reverse-mappings and miscellaneous errors found in all
+   kinds of resource records.  As a whole, they do a rather extensive
+   checking on DNS configurations.
+
+   These tools work on cached DNS data, i.e., data stored locally after
+   performing zone transfers (presently done by a slightly modified
+   version of BIND's named-xfer, called ddt-xfer, which allows recursive
+   transfers) from the appropriate servers, rather than querying name
+   servers on-line each time they run.  This option was taken for
+   several reasons [3]: (1) efficiency, since it reads data from disk,
+   avoiding network transit delays, (2) reduced network traffic, data
+   has to be fetched only once and then run the programs over it as many
+   times as you wish and (3) accessibility - in countries with limited
+   Internet access, as was the case in Portugal by the time DDT was in
+   its first stages, this may be the only practical way to use the
+   tools.
+
+   Point (2) above deserves some special considerations: first, it is
+   not entirely true that there aren't additional queries while
+   processing the information, one of the tools, the authority checker,
+   queries (via dig) each domain's purported name servers in order to
+   test the consistency of the authority information they provide about
+   the domain.  Second, it may be argued that when the actual tests are
+   done the information used may be out of date.  While this is true,
+   you should note that this is the DNS nature, if you obtain some piece
+   of information you can't be sure that one second later it is still
+   valid.  Furthermore, if your source was not the primary for the
+   domain then you can't even be sure of the validity in the exact
+   moment you got it in the first place.  But experience shows that if
+   you see an error, it is likely to be there in the next version of the
+   domain information (and if it isn't, nothing was lost by having
+   detected it in the past).  On the other side, of course there's
+   little point in checking one month old data...
+
+   The list of errors looked for includes lame delegations, version
+   number mismatches between servers (this may be a transient problem),
+   non-existing servers, domains with only one server, unnecessary glue
+   information, MX records pointing to hosts not in the analyzed domain
+   (may not be an error, it's just to point possibly strange or
+   expensive mail-routing policies), MX records pointing to aliases, A
+
+
+
+Romao                                                           [Page 7]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   records without the respective PTR and vice-versa, missing trailing
+   dots, hostnames with no data (A or CNAME records), aliases pointing
+   to aliases, and some more.  Given the specialized nature of each
+   tool, it is possible to look for a well defined set of errors,
+   instead of having the data analyzed in all possible ways.
+
+   Except for ddt-xfer, all the programs are written in Perl.  A new
+   release may come into existence in a near future, after a thorough
+   review of the methods used, the set of errors checked for and some
+   bug fixing (in particular, a Perl version of ddt-xfer is expected).
+   In the mean time, the latest version is available from
+   ftp://ns.dns.pt/pub/dns/ddt-2.0.1.tar.gz.
+
+2.6. The Checker Project
+
+   The problem of the huge amount of DNS traffic over the Internet is
+   getting researchers close attention for quite some time, mainly
+   because most of it is unnecessary.  Observations have shown that DNS
+   consumes something like twenty times more bandwidth than it should
+   [4].  Some causes for this undoubtedly catastrophic scenario lie on
+   deficient resolver and name server implementations spread all over
+   the world, from personal to super-computers, running all sorts of
+   operating systems.
+
+   While the panacea is yet to be found (claims are made that the latest
+   official version of BIND is a great step forward [5]), work has been
+   done in order to identify sources of anomalies, as a first approach
+   in the search for a solution.  The Checker Project is one such
+   effort, developed at the University of Southern California [6].  It
+   consists of a set of C code patched into BIND's named, for monitoring
+   server activity, building a database with the history of that
+   operation (queries and responses).  It is then possible to generate
+   reports from the database summarizing activity and identifying
+   behavioral patterns from client requests, looking for anomalies.  The
+   named code alteration is small and simple unless you want do have PEC
+   checking enabled (see below).  You may find sources and documentation
+   at ftp://catarina.usc.edu/pub/checker.
+
+   Checker only does this kind of collection and reporting, it does not
+   try to enforce any rules on the administrators of the defective sites
+   by any means whatsoever.  Authors hope that the simple exhibition of
+   the evidences is a reason strong enough for those administrators to
+   have their problems fixed.
+
+   An interesting feature is PEC (proactive error checking): the server
+   pretends to be unresponsive for some queries by randomly choosing
+   some name and start refusing replies for queries on that name during
+   a pre-determined period.  Those queries are recorded, though, to try
+
+
+
+Romao                                                           [Page 8]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   to reason about the retry and timeout schemes used by name servers
+   and resolvers.  It is expected that properly implemented clients will
+   choose another name server to query, while defective ones will keep
+   on trying with the same server.  This feature seems to be still under
+   testing as it is not completely clear yet how to interpret the
+   results.  A PEC-only error checker is available from USC that is much
+   simpler than the full error checker.  It examines another name server
+   client every 30 minutes to see if this client causes excessive load.
+
+   Presently Checker has been running on a secondary for the US domain
+   for more than a year with little trouble.  Authors feel confident it
+   should run on any BSD platform (at least SunOS) without problems, and
+   is planned to be included as part of the BIND name server.
+
+   Checker is part of a research project lead by Peter Danzig from USC,
+   aimed to implement probabilistic error checking mechanisms like PEC
+   on distributed systems [7].  DNS is one such system and it was chosen
+   as the platform for testing the validity of these techniques over the
+   NSFnet.  It is hoped to achieve enough knowledge to provide means to
+   improve performance and reliability of distributed systems.
+   Anomalies like undetected server failures, query loops, bad
+   retransmission backoff algorithms, misconfigurations and resubmission
+   of requests after negative replies are some of the targets for these
+   checkers to detect.
+
+2.7. Others
+
+   All the tools described above are the result of systematic work on
+   the issue of DNS debugging, some of them included in research
+   projects.  For the sake of completeness several other programs are
+   mentioned here.  These, though just as serious, seem to have been
+   developed in a somewhat ad-hoc fashion, without an implicit intention
+   of being used outside the environments where they were born.  This
+   impression is, of course, arguable, nevertheless there was no
+   necessity of dedicating an entire section to any of them.  This
+   doesn't mean they are not valuable contributions, in some cases they
+   may be just what you are looking for, without having to install a
+   complete package to do some testings on your domain.
+
+   The reference taken was the contrib directory in the latest BIND
+   distribution (where some of the above programs can also be found).
+   There you will find tools for creating your DNS configuration files
+   and NIS maps from /etc/hosts and vice-versa or generate PTR from A
+   records (these things may be important as a means of avoiding common
+   typing errors and inconsistencies between those tables), syntax
+   checkers for zone files, programs for querying and monitoring name
+   servers, all the small programs presented in [8], and more.  It is
+   worth spending some time looking at them, maybe you'll find that
+
+
+
+Romao                                                           [Page 9]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   program you were planning to write yourself.  The latest public
+   version of BIND can be found at
+   ftp://gatekeeper.dec.com/pub/misc/vixie/4.9.2-940221.tar.gz.  As of
+   this writing BIND-4.9.3 is in its final beta stages and a public
+   release is expected soon, also at gatekeeper.dec.com.
+
+   You may also want to consider using a version control system like
+   SCCS or RCS to maintain your configuration files consistent through
+   updates, or use tools like M4 macros to generate those files.  As
+   stated above, it's important to avoid human-generated errors,
+   creating problems that are difficult to track down, since they're
+   often hidden behind some mistyped name.  Errors like this may end up
+   in many queries for a non-existing name, just to mention the less
+   serious kind.  See [9] for a description of the most common errors
+   made while configuring domains.
+
+3. Why look after DNS?
+
+   Several pieces of software were presented to help people administer
+   and debug their name services.  They exhibit many differences in
+   their way of doing things, scope and requirements and it may be
+   difficult just to choose one of them to work with.  For one thing,
+   people's expectations from these tools vary according to their kind
+   of involvement with DNS.  If you are responsible for a big domain,
+   e.g., a top-level one or a big institution with many hosts and sub-
+   domains, you probably want to see how well is the tree below your
+   node organized, since the consequences of errors tend to propagate
+   upwards, thus affecting your own domain and servers.  For that you
+   need some program that recursively descends the domain tree and
+   analyzes each domain per se and the interdependencies between them
+   all.  You will have to consider how deep you want your analysis to
+   be, the effects it will have on the network infrastructure, i.e.,
+   will it generate traffic only inside a campus network, no matter how
+   big it is, or will it be spread over, say, a whole country (of
+   course, your kind of connectivity plays an important role here).
+
+   You may simply want to perform some sanity checks on your own domain,
+   without any further concerns.  Or you may want to participate in some
+   kind of global effort to monitor name server traffic, either for
+   research purposes or just to point out the "trouble-queries" that
+   flow around.
+
+   Whatever your interest may be, you can almost surely find a tool to
+   suit it.  Eliminating problems like those described in this document
+   is a major contribution for the efficiency of an important piece of
+   the Internet mechanism.  Just to have an idea of this importance,
+   think of all the applications that depend on it, not just to get
+   addresses out of names.  Many systems rely on DNS to store, retrieve
+
+
+
+Romao                                                          [Page 10]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   and spread the information they need: Internet electronic mail was
+   already mentioned (see [10] for details) and work is in progress to
+   integrate X.400 operations with DNS [11]; others include "remote
+   printing" services [12], distributed file systems and network routing
+   purposes, among others.  These features may be accomplished by some
+   standard, well-known resource records [13], or by new, experimental
+   ones [14, 15].  Even if some of them won't succeed, one may well
+   expect some more load on the DNS burden.
+
+   The ubiquitous DNS thus deserves a great deal of attention, perhaps
+   much more than it generally has.  One may say that it is a victim of
+   its own success: if a user triggers an excessive amount of queries
+   only to have one request satisfied, he won't worry about it (in fact,
+   he won't notice it), won't complain to his system administrator, and
+   things will just go on like this.  Of course, DNS was designed to
+   resist and provide its services despite all these anomalies.  But by
+   doing so it is frequently forgotten, as long as people can Telnet or
+   ftp.  As DNS will be given new responsibilities, as pointed in the
+   above paragraph, the problems described in this text will grow more
+   serious and new ones may appear (notably security ones [16], with a
+   lot of work being presently in progress addressing security in DNS),
+   if nothing is done to purge them.
+
+References
+
+   [1] Lottor, M., "Internet Domain Survey, October 1994",
+       http://www.nw.com/zone/WWW/report.html, October 1994.
+
+   [2] Beecher, B., "Dealing With Lame Delegations", Univ. Michigan,
+       LISA VI, October 1992.
+
+   [3] Frazao, J. and J. L. Martins, "Ddt - Domain Debug Tools, A
+       Package to Debug the DNS Tree", Dept. Informatica Faculdade
+       Ciencias Univ. Lisboa, DI-FCUL-1992-04, January 1992.
+
+   [4] Danzig, P., "Probabilistic Error Checkers: Fixing DNS", Univ.
+       Southern California, Technical Report, February 1992.
+
+   [5] Kumar, A., J. Postel, C. Neuman, P. Danzig and S. Miller, "Common
+       DNS Implementation Errors and Suggested Fixes", RFC 1536,
+       USC/Information Sciences Institute, October 1993.
+
+   [6] Miller, S. and P. Danzig, "The Checker Project, Installation and
+       Operator's Manual", Univ. Southern California, TR CS94-560, 1994.
+
+   [7] Danzig, P., K. Obraczka and A. Kumar, "An Analisys of Wide-Area
+       Name Server Traffic", Univ. Southern California, TR 92-504, 1992.
+
+
+
+
+Romao                                                          [Page 11]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   [8] Albitz, P. and C. Liu, "DNS and BIND", O'Reilly and Associates
+       Inc., October 1992.
+
+   [9] Beertema, P., "Common DNS Data File Configuration Errors", RFC
+       1537, CWI, October 1993.
+
+  [10] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN Laboratories Inc., January 1986.
+
+  [11] Allocchio, C., A. Bonito, B. Cole, S. Giordano and R. Hagens,
+       "Using the Internet DNS to Distribute RFC1327 Mail Address
+       Mapping Tables", RFC 1664, GARR, Cisco Systems Inc., Centro
+       Svizzero Calcolo Scientifico, ANS, August 1994.
+
+  [12] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT
+       Subdomain: General Principles and Policy", RFC 1530, Internet
+       Multicasting Service, Dover Beach Consulting Inc., October 1993.
+
+  [13] Rosenbaum, R., "Using the Domain Name System to Store Arbitrary
+       String Attributes", RFC 1464, Digital Equipment Corporation, May
+       1993.
+
+  [14] Everhart, C., L. Mamakos, R. Ullmann and P. Mockapetris (Ed.),
+       "New DNS RR Definitions", RFC 1183, Transarc, Univ. Maryland,
+       Prime Computer, Information Sciences Institute, October 1990.
+
+  [15] Manning, B., and R. Colella, "DNS NSAP Resource Records", RFC
+       1706, USC/Information Sciences Institute, NIST, October 1994.
+
+  [16] Gavron, E., "A Security Problem and Proposed Correction With
+       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
+       October 1993
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Romao                                                          [Page 12]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+Security Considerations
+
+   Security issues are not discussed in this memo (although security is
+   briefly mentioned at the end of section 3).
+
+Author's Address
+
+   Artur Romao
+   DI - Faculdade de Ciencias e Tecnologia
+   Universidade Nova de Lisboa
+   Quinta da Torre
+   P-2825 Monte de Caparica
+   Portugal
+
+   Phone: +351 1 294 28 44
+   Fax:   +351 1 295 77 86
+   EMail: artur@fct.unl.pt
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Romao                                                          [Page 13]
+