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