GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:fyi:fyi27

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]

/data/webs/external/dokuwiki/data/pages/rfc/fyi/fyi27.txt · Last modified: 1994/11/03 18:06 (external edit)