rfc1713.txt

最近的中文RFC文档

   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

   电话: [phone]
   传真:   [phone]
   EMail: [e-mail]
RFC1713  Tools for DNS debugging                                        RFC1713  DNS调试工具




1
中文文档翻译计划