diff options
Diffstat (limited to 'doc/rfc/rfc1713.txt')
| -rw-r--r-- | doc/rfc/rfc1713.txt | 731 |
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] + |