Tools for DNS debugging
RFC 1713
Document | Type |
RFC - Informational
(November 1994; No errata)
Also known as FYI 27
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1713 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 queryShow full document text