Tools for DNS debugging
RFC 1713

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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