组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：郭永彬（miles，guoyongbin@263.net）
译文发布时间：2001-4-8
版权：本翻译文档可以用于非商业用途自由转载，但必须保留本文档的翻译及组织信息。
Network Working Group A. Romao
Request for Comments: 1713 FCCN
FYI: 27 November 1994
Category: Informational
RFC1713 DNS调试工具
(RFC1713 Tools for DNS debugging)
本备忘录状态
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
摘要
DNS（域名服务器）尽管得到了很广泛的应用（绝大多数时间却没有引起人们的注意），但是人们往往却太忽视它的存在。人们的认识，尤其是那些系统管理员的认识存在这样一种倾向，那就是：只要是需要使用由域名向地址映象来工作的应用软件，他们往往忽视可能发生的异常。本文档为DNS管理员提供了一些可利用的工具来诊断和处理异常情况。
目录
1. 绪论 2
2. DNS 调试 3
2.1. host 3
2.2. Dnswalk 4
2.3. Lamers 4
2.4. DOC 5
2.5. DDT 6
2.6. The Checker Project 6
2.7.其它 7
3. 为什么注意监视DNS? 8
参考文献 8
安全事项 9
作者地址： 9
1. 绪论
今天，联入全球互联网上的计算机超过3,800,000台[1]，这其中包括了几百万终端用户，他们只通过为其命名的计算机就可以联接到世界各地任何一台计算机上。这种便利条件可能要归功于世界范围的广域分布式数据库，域名系统用于提供分布式、应用于不同服务器的服务，且域名系统最引人注目之处是将域名转化为IP地址并代替IP地址。你可以在很多应用中使用到它，当使用FTP或者Telnet时，当你的客户联接远程服务器时，当你单击一个超文本选项联接到一个由URL（Uniform Resource Locator ,在Internet的WWW服务程序上用于指定信息位置的表示方法）定义的服务器时，当你与其它域的计算机对话时，当你的电子邮件在到达指定的容器之前必须通过一个网关发送时，当你向Usenet（世界性的新闻组网络系统）投递一篇文章并且希望能够向全世界宣传时。所有的这些都是最显而易见的DNS的使用，还有更多的应用程序都需要依靠DNS这个系统才能运行，比如：网络安全，监控和统计工具，前面提到的只是一小部分。
在分布式管理上，DNS取得了很大的成功。每一个组分（称为区，在很多方面与域相同）作为一个独立的实体是可见的，可以很可靠的处理任何发生于权威域上的事件，如信息怎样变化，变成什么，减少子目录结构，创建新的组件等。
另一方面，很多矛盾的事情来自这种分布式的特性：许多系统管理员会犯这种错误，他们配置域管理，当他们授权给下一级域时，很多人甚至不知道如何正确的操作，只好让问题持续地存在下去并且越积越多。另外，很多问题与DNS客户机和服务器的错误的操作有关，尤其那种非常古老的客户机和服务器的问题更为突出。他们或者没有按照标准来操作，或者有错误的倾向，使得上述的问题经常发生。
所有的这些异常情况使得DNS不能高效率的运作，并且在相关的网络操作上带来很多不必要的麻烦，因此这有可能会全面的影响整个Internet。本文献将竭尽全力地去说明正确地管理DNS是的重要性，文中还在适当的位置指导系统管理员如何行之有效地更好的管理他们的域名服务。
2. DNS 调试
为了帮助系统管理员及时的发现DNS配置或者执行时的问题，这里将介绍一系列特定的工具软件。可能有很大一部分人在域名服务部门管理该项服务，但是苦于没有这种相关的工具软件或者根本就不了解这种相关的工具软件（尤为糟糕的是，他们对已经存在的配置和运行上的一些异常情况根本没有任何警觉）。下面即将对这种相关的程序以及适用条件、使用目的和有效性进行描述，作为主要内容——DNS调试的一个引子，同时引导那些正在苦苦寻找这种相关工具软件并且希望借助这些软件来判断他们的域名管理服务是否运行得很强健的管理员。
假设读者已经了解到了一些相关的比较基础的入门知识，包括DNS的基本知识和一些其它相关工具软件（如 dig和nslookup），这里就不再详述，希望他们已经从日常的使用与维护中已经了解到了大量的知识。
2.1. host
host是一种可以从域名服务器上找到DNS信息的程序。这种信息可能仅仅用于得到一些简单的信息，如：地址——域名映射；或者用于一些更高级的目的，如执行数据的强健性检验。该程序是由Rutgers大学开发的，但是后来Nikhef的ric Wassenaar重新改写了源程序，而且现在似乎还在继续修改。本程序可以从如下地址得到：
ftp://ftp.nikhef.nl/pub/network/host_YYMMDD.tar.Z
（YYMMDD是最新版本的版本数字）
由于疏忽，host只能映射主机名称到Internet地址，查询默认的服务器或者某些特定的服务器。但是，通过以下几种方式使得从任何域名服务器中得到种种数据（源记录）是可能的。这几种方式有通过特定的不同的查询类型和等级，通过详细的或者调试输出。当涉及到使用域名服务器时，你可以支配几个参数，如递归循环、复算时间、超时设定、使用虚拟系统以及数据包（自带寻址信息的,独立地从数据源行走到终点的数据包）等。为了及时发现任何与决策操作（也就是说，任何使用决策库的应用）有关的任何异常，你可以通过这种方式来模仿得出一个解决方案。作为一个查询程序，它可以象其它工具软件一样强劲有力，如nslookup 和 dig。
作为一个调试器，host分析DNS空间的一些组（如：整个区），并且生成操作结果的报告。Host是如何作到的？host首先执行一个操作，这种操作可能是递归的，从一个区和它的所有的子区中得到有用的信息。然后，分析作为在命令行上被请求实现的数据。注意：区传输必须通过联接该区的授权域名服务器才能实现，所以必须保证向这些服务器请求会响应；这种服务器中的一些会拒绝区传输（尤其二级服务器）以避免网络拥塞。
使用host，你可以找出这样的异常，比如：那些与授权有关的（如下面讨论到的不完全授权）或者一些更为奇特的例子象区域外主机（一台主机的形式为host.some.dom.ain，some.dom.ain不是由dom.ain授权）。这些错误很明显地发生在命令行的请求上，但是host操作后，你可能得到一个其它的错误信息，象是次要因素。这些可能仅仅是警告（可能你会禁用）或者更为严重的错误——事实上，警告信息不是那么简单，大多数可以归因于未配置区，所以对警告信息置之不理不是一种明智之举。
错误信息必须当作是严重的异常来对待，或者当成与查询服务器之间的信息交换包（大小错误，非法帐户等），或者其它联系DNS的信息（在程序清单中也叫“状态信息”）；SOA记录之间矛盾在一个域的不同服务器之间表现出来的，意外的地址——域名映射，可能引起域名服务器不响应，不能登陆，不运行或者根本不存在等。
Host执行所有的在线查询，它只处理从域名服务器得来的数据，这意味着你与其想要得到特定数据块的种类报告，不如查询一个域名服务器。你可以拿出一些论点来说明你可以通过运行Host来得到你想要得到的所有的信息，但是如果你忘记某些细节或者因为某种原因必须重新运行时，这意味着额外的区传输，域名服务器额外的装载，额外的DNS 通讯量。
如果使用谨慎， Host是一种非常优秀的工具。象一些其它的查询程序，只是通过发出一个简单的命令，而产生了很大的信息量。除此之外，它的解决方案和调试能力会发现许多普通的或者不普通的DNS配置错误，同时生成有关DNS目录的有用地报告和分析结果，这显得很实用。举一个例子，RIPE网络控制中心利用host生成每月的欧洲主机记录报告，从中得出欧洲Internet用户的发展状况。根据这些记录，生成错误信息报告，每个国家一人，而且所有的信息在RIPE文件中是可用的。
2.2. Dnswalk
Dnswalk是宾夕法尼亚州立大学的David Barr使用Perl语言开发出来的，你可以在以下地址中找到它的最新的版本。
ftp://ftp.pop.psu.edu/pub/src/dnswalk
与这个软件捆绑在一起的还有一些文档，文档中作者指定了一些有用的文件，很值得去仔细阅读。
Dnswalk这个软件可以检查当地存储的域名配置，和各级目录的信息，如DNS域的树状结构。为了得到该信息，dnswalk可以首先从授权的域名服务器执行区传输。你可以递归式的传输域以及它的次级域信息，执行该操作时应该谨慎，因为这可能产生大量的数据流量。如果数据已经存在，而且是最新的，dnswalk可以跳过这一步。
Dnswalk在源代码中寻找不相容之处，如：域名MX和别名指向别名或者未知的主机，不连贯的PTR，A和CNAME记录，名称中无效的字符，IP地址中没有圆点，不必要的联接信息等等。Dnswalk同时寻找授权信息，即不完全授权和只有一个域名服务器的域。该软件简单易用，你只需要定义这个要分析的域和一些可选参数，其它的由本软件来做。但是，一次只能检查一个域（或者它的次级域）。
当检验数据时，dnswalk使用很多收集和解决方案程序（Perl 库的gethostbyXXXX），为了得到要分析的域的服务器的授权信息的数据，由IP地址映射的域名，如此以致于去检验PTR、别名等记录的存在。所以，仅仅运行了该程序，除了区传输以外，你可能好要依靠一些额外的数据流量（如果你正在调试一个相关的大量的数据并且关心再次查询和超时设置时，可能是不可以忽略的）。
2.3. Lamers
不完全授权在某种意义上来说，是DNS配置中的一种比较严重的错误，也是比较普通的一种错误。它发生于一个域名服务器正在为一些域列举NS记录时，实际上它不是那个域的服务器。因而查询被发送到了一个错误的服务器上，我们可能得到一些有关的查询域，但不是我们想要的。此外，有时主机（如果存在）甚至不能管理域名服务器。导致的结果是查询超时，只能舍弃，然后产生（更多的）无必要的信息流量。
产生不完全授权是很容易的：最为普遍的例子是发生在当系统管理员为域改变NS列表，从列表中抛弃一个或者多个服务器时，没有通知它的上一级域的系统管理员，授权给他的权利超过这个域时。从现在开始，父域名服务器通告该域的一个或者多个服务器接受一些它们所不知道的查询。（另一方面，服务器可能没有得到上一级服务器的同意就加入到列表当中，然后，隐藏他们的重要的信息——这不是不完全授权，但是同样不应该发生。）另外的例子是没有通知该主机的系统管理员而包含名称于NS列表，或者当域名服务器突然停止该域的名称服务时。
为了能够及时的发现和通知全世界的系统管理员这种情形，美国密歇根州wrote大学的Bryan Beecher开发出了lamers这个软件，本软件用来分析域名命名（举世闻名的是BIND域名服务器）记录信息[2]。为了产生有用的日志，名称使用一个补丁程序去探测和记录不完全授权（这个补丁程序起初是由Silicon System软件公司的Don Lewis开发出来的，现在由于Bryan Beecher的努力，这个补丁程序成为了BIND最新版本的一部分，希望在不久的将来BIND可以被广泛的使用。）Lamers是一个很小的外壳程序，它可以简单的扫描这些日志并且汇报发现的不完全授权的情况。报告通过电子邮件的形式发送到受影响域的管理员处，如果有可能的话，同样会定期检查每一个SOA记录，消息会发送到受影响的服务器的管理员处。为避免由于疏忽的记录或者无效的管理员地址而引起的信息反弹，需要手动操作。由U-M服务器发现的错误的报告会一个月两次地粘贴在USENET（世界性的新闻组网络系统）新闻组comp.protocols.tcp-ip.domains.上。
如果你曾经收到这样一个报告，那么你应该仔细地研究，这样你可以发现并纠正你的域的错误，或者看一下你的服务器是否被错误的正在扩大的错误的信息的影响。更好的是lamers可以在你的服务器上运行，并监测以发现更多的不完全授权（U-M不能完全检测出）。同样，如果你收到一份电子邮件，该邮件报告称有不完全授权影响着你的域或者其中的一些主机，请不要不理睬并且迁怒于这个邮件的发送者。他们正在帮助你！
你可以从以下的地址得到lamers：
ftp://terminator.cc.umich.edu/dns/lame-delegations
2.4. DOC
DNS数据的一个最重要的部分是授权信息，在运行机制中依靠它来正确地传输整个域的目录。不正确的授权信息能引发许多问题如不完全授权或更严重的问题，在后面的例子，可能造成难以访问该域。举出这个例子，授权信息给出的所有的域名服务器的信息都是错误的，你不能登陆实际的服务器，你不能访问域内的任何信息，只能结束访问登陆。这可能有些夸大，但是如果你在DNS的业务部门工作了很长一段时间，你可能会见到很多有关这种假想的例子。
为了及时发现这种问题，信息科学研究院的Paul Mockapetris和Steve Hotz开发了一个C语言的外壳程序，并命名为DOC（域的异常控制），这是一个自动检测域的工具软件，该软件使用收集和查询适合的域名服务器有关域的授权信息并且分析相关的反应。
自从该软件作者预测到可能有一些人会抱怨这是侵犯个人隐私，DOC就限定了分析授权数据的范围。同时，DOC指出多数的域是如此的杂乱无章的以致于他们只能在基本的问题解决之后才能检查更深入的问题。
一次只能分析一个域：程序检查是否所有的上一级域的服务器与该域的授权信息一致。DOC然后列出一份域名服务器的列表（由上一级域获取信息）并且开始检查信息，查询每一个服务器：寻找SOA记录，检查响应是否经过授权，比较得到的不同的记录，得到每一个NS列表，比较列表（既比较这些服务器之间的列表，也比较上一级域的列表），并且程序还为那些域内的服务器搜索PTR记录。
由于某些原因，DOC自从1990年发布了第一个版本后，就好象没有什么新的进展。在销售过程中有一个有关自动域检测的RFC方案，这是从来没有出版过的。然而，这是提供的很有用的阅读材料。该软件可以从以下地址获取：
ftp://ftp.uu.net/networking/ip/dns/doc.2.0.tar.Z
2.5. DDT
DDT（域调试工具）是一个软件包，用来扫描DNS的错误信息，最初该软件包是由PUUG（葡萄牙UNIX用户组）的Jorge Frazao开发的。后来，作者重新开发，当时作者在里斯本大学自然科学系工作。每一个程序都是专门针对一系列异常情况的：你有一个授权信息的检验员，另一个是模糊数据的检验员，在所有的源代码中通过邮件交换等方式发现各种各样的错误信息。总的来说，它们在DNS配置上进行更为深入的检测。
这些工具在DNS数据的处运行，也就是说，数据在执行了区传输（最近BIND有了一些小的修改，命名为-xfer，称为ddt-xfer，允许递归式的传输）之后贮存在本地，比每一次运行都要在线查询域名服务器要好。这种选择有几个原因[3]：(1)效率，既然能够从磁盘上读取数据，避免了网络传输的延迟，（2）减少了网络的信息流量，数据只需要获取一次然后可以根据需要来运行程序，（3）易用性——在农村Internet存取有一定的限制，在葡萄牙的一个例子，到目前为止，DDT一直在第一线上，这可能是使用该工具软件的唯一的实用的方式。
上一段提到的第（2）点应该特别的思考一下：首先，当处理信息时不需要额外的查询，这不是完全正确的，为了验证一下授权信息与域提供的信息的一致性，权威授权部门的检验员曾经（借助dig软件）查询了每一个域的域名服务器。其次，当在现实检验中，使用的数据可能是过时的，这引起了很多人的争议。 这是真实的，你应该注意这是DNS的特性，如果你获得了一些信息，你不能保证一秒钟以后这些信息仍是有效的。此外，如果你的资料不是域的基本资料，那么你不能保证在你得到资料时刻，这些资料的可用性。但是，经验显示：如果你见到了一个错误，它可能存在于域信息的下一个版本中（如果不是错误，在刚才的检测中没有丢失任何东西）。另一方面，在检查一个月以前的数据时，当然几乎没有意义。
要寻找的错误信息包括：不完全授权，服务器之间的版本的不匹配（这可能只是一个暂时的问题），不存在的服务器，只有一个服务器的域，不需要的模糊信息，不在要分析的域的指向主机的MX记录（这可能不是一种错误，这可能只是一个奇怪的指向或者一种昂贵的电子邮件路由政策），指向别名的MX记录，没有单独的PTR的A记录，丢失小圆点，没有数据信息的主机名（A o或CNAME记录），指向别名的别名以及其它更多的情况。给出了每一个工具的特性，可以更好的寻找定义了的错误，而不需要通过所有可能的方式分析数据。
除了ddt-xfer以外，所有的程序都是用Perl开发的。在不久的将来可能会发行一个新的版本，回顾了所有的使用方式、检查的错误系列以及修改了一些漏洞（更值得关注的是，可能还会推出一个Perl版本的ddt-xfer）。到目前为止，最新的版本可以从以下地址获得：
ftp://ns.dns.pt/pub/dns/ddt-2.0.1.tar.gz.
2.6. The Checker Project
Internet上DNS的巨大的信息传输量的问题，使得研究员更关注，主要是因为大部分的信息是不必要的。观测资料表明：DNS耗费了20多倍它应该耗费的带宽[4]。这个不容置疑的有些灾难性的情况的一些原因是缺少解决方案和世界范围的域名服务器的扩散，从个人电脑到超级计算机，运行着各种各样的操作系统。
到目前为止还没有发现万能的解药（最新的BIND官方最新的报告声称已经取得了很大的进展[5]），为了发现资源中的异常情况，在解决方案中首先开发出万能解药，已经做了很多的工作。The Checker Project就是这样的一种努力，它是南加州大学开发的[6]。包括一个C语言的代码加入BIND的命名，可以监视服务器的活动情况，创建一个操作记录的数据库（查询和响应）。然后，根据总结服务器活动的数据库和从用户的请求确定的响应方式，创建一个报告，寻找异常情况。代码的改变是很少的也很容易，除非你想要检查PEC。你可以从以下地址得到该软件。
ftp://catarina.usc.edu/pub/checker
Checker只处理这种收集和报告工作，无论用何种方式，它都不去强制执行任何系统管理员职责的事情。作者希望：异常错误证据的一个简单的显示是那些系统管理员解决问题的强有力的因素。
一个很有趣的特征是PEC（主动错误检测）：服务器随机的选择一些域名并假装对查询没有响应，并且在整个前期检测过程中拒绝响应该域名的任何查询。记录下这些疑问，并尽力找出域名服务器以及解决方案的超时原因。人们期望正确的执行客户机的程序可以选择另一个域名服务器去查询，错误的继续在同一台服务器上调试。这个特征还处于测验当中因为它不能很清楚了解如何解释原因。一个只有PEC的checker比所有错误检测的checker要简单的多。它每30分钟检测一次域名服务器，检查是否是客户机的原因引起系统负荷过重。
目前，Checker已经几乎无故障地运行于US域已经一年多了。作者很自信地认为Checker可以无故障地运行于任何BSD平台（至少是SunOS），并且计划加入到BIND域名服务器中。
Checker是Peter Danzig领导的科研项目当中的一部分，目的是在分布式操作系统上实现可能存在的类似PEC的错误检测机制[7]。DNS是一个系统，可以作为NSF（国家科学基金会）网测试这些技术可行性的平台。希望可以获取足够的知识用来提供种种手段，改善分布式操作系统的稳定性与可靠性。象未被识破的服务器故障、查询的循环等异常是checkers检测的目标。
2.7.其它
以上讨论的工具软件都是对DNS调试起作用的软件，其中的某些包含在科研项目当中。为了文章的完整性，这里将提到其它的一些程序。这些工具软件尽管看起来比较严肃，但是开发的已经有一些特别的方式，没有任何盲目的意图要将这些软件用到它们诞生的环境之外。这种印象当然是有争议的，然而没有必要致力于掌握它们的所有的各部分功能。这并不意味着这些软件没有有价值的贡献，在某些时候可能就是你要找的软件，因为你没有安装完整的程序包来检测你的域名。
提及的软件可以在最新发行的BIND中得到（同时也可以找到上述一些软件）。在那里，你可以找到工具，用来创建你的DNS配置文件和NIS映像或者从A记录生成PTR（这对于避免出现出现普遍的典型错误很重要），区域文件的语法检查器、查询和监视域名服务器的程序，所有这些小程序均可发现[8]，可能还会有更多的发现。很值得花一些时间去研究一下，可能你计划亲自编写的程序。最新的BIND可以在以下地址找到：
ftp://gatekeeper.dec.com/pub/misc/vixie/4.9.2-940221.tar.gz.
BIND-4.9.3已经完成了最后测试版的测试工作，将在近期发行，在gatekeeper.dec.com上同样可以找到。
你可能想要思考，使用一个象SCCS或者RCS控制系统的版本去维护你的配置文件以避免不一致，或者使用象M4 macros这样的工具去生成这些文件。
象以上所描述的，避免人为错误、产生难以捕获的错误是非常重要的，因为这些错误经常隐藏在一些不规则的域名之后。这些错误可以终止你的很多查询。[9]描述了在配置域名时发生的大多数错误。
3. 为什么注意监视DNS?
已经有几款软件用来帮助人们管理和调试域名服务器。在工作机制、应用范围和使用条件等方面各有不同，可能选择一款合适的软件很难。一方面，人们对这些工具软件的期望值根据它们的DNS情况会有所不同。如果你信赖大的域，如一个顶级域或者有很多主机和次级域的部门，你可能想要知道在你的节点组织下的目录情况，因为错误几乎总是向上传播，因而影响你的域名和服务器。这种原因，你需要一些软件来分析下级的域名目录树。你必须决定你想要向下分析的深度，思考可能对网络下部构造的影响，如：可能产生的信息流量，尽管只在校园网内，而不管这信息流量有多大，扩展有多广。可以这样说，整个国家（当然，这里的连通性起了重要作用）。
你可能只是想要在你自己的域上进行系统的健壮性检测，没有其它的任何目的。你也可能想要预测一些监视域名服务器信息流量的结果，可能有科研目的或者只是想指出错误的查询。
不管你对什么感兴趣，你都可以找到一个合适的工具软件。排除象文档中阐述的问题是对Internet系统机制的主要贡献。对其重要性有了一个了解后，你需要考虑依靠工具的所有应用，而不是仅仅得到域名的地址。很多系统依赖DNS去储存、找到、向外传播他们需要的信息：Internet的电子邮件已经提到过（详情请见[10]）并且正在向与使用DNS 的X.400一体化的方向发展[11]；另外的涉及远程打印服务器[12]，分布式文件系统等。这些特征可能会促进一个标准的完成，也可能完成一些著名的源记录[13]，或某种实验方法[14, 15]。即使，有一些可能会不成功，人们可能希望加强DNS的任务。
普遍存在的DNS应该得到充分的重视。人们可能会说这是它自己的成功的牺牲品：如果用户引发一个极大的查询没想到只有一个合适的请求，他不必担心（实际上，他根本就没有注意到），也不会埋怨系统管理员，还会继续下去。当然，DNS的设计目的是提供服务而不管这些异常。但是，只要人们能够使用Telnet或者ftp，会经常忘记DNS。当赋予DNS如前面提到过的新的使命时，本文中阐述的问题会显得很严重，如果没有采取任何措施，可能还会出现新的问题（尤为突出的是安全问题，在DNS的安全方面目前正在做大量的工作[16]）。
参考文献
[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.
[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
安全事项
在本文中没有讨论这个方面的问题（尽管在第3部分简要地提及）
作者地址：
Artur Romao
DI - Faculdade de Ciencias e Tecnologia
Universidade Nova de Lisboa
Quinta da Torre
P-2825 Monte de Caparica
Portugal
电话: +351 1 294 28 44
传真: +351 1 295 77 86
EMail: artur@fct.unl.pt
RFC1713 Tools for DNS debugging RFC1713 DNS调试工具
1
中文文档翻译计划