Network Working Group R. Austein
Request for Comments: 3197 InterNetShare
Category: Informational November 2001
Network Working Group R. Austein
Request for Comments: 3197 InterNetShare
Category: Informational November 2001
Applicability Statement for DNS MIB Extensions
DNS MIB扩展的适用性声明
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status.
本文档解释了为什么在作为提议的标准使用了六年多之后，DNS服务器和解析程序MIB扩展从未部署，并建议通过将这些MIB扩展移到历史状态使其退役。
The road to the DNS MIB extensions was paved with good intentions.
通往DNS MIB扩展的道路是由良好的意愿铺就的。
In retrospect, it's obvious that the working group never had much agreement on what belonged in the MIB extensions, just that we should have some. This happened during the height of the craze for MIB extensions in virtually every protocol that the IETF was working on at the time, so the question of why we were doing this in the first place never got a lot of scrutiny. Very late in the development cycle we discovered that much of the support for writing the MIB extensions in the first place had come from people who wanted to use SNMP SET operations to update DNS zones on the fly. Examination of the security model involved, however, led us to conclude that this was not a good way to do dynamic update and that a separate DNS Dynamic Update protocol would be necessary.
回顾过去，很明显，工作组从未就MIB扩展中的内容达成过太多一致意见，只是我们应该有一些一致意见。这发生在当时IETF正在研究的几乎每一个协议中MIB扩展的狂热时期，因此我们为什么要这样做的问题从未得到过太多的关注。在开发周期的后期，我们发现，最初编写MIB扩展的大部分支持来自希望使用SNMP集操作动态更新DNS区域的人。然而，对涉及的安全模型的检查使我们得出结论，这不是进行动态更新的好方法，需要单独的DNS动态更新协议。
The MIB extensions started out being fairly specific to one particular DNS implementation (BIND-4.8.3); as work progressed, the BIND-specific portions were rewritten to be as implementation-neutral as we knew how to make them, but somehow every revision of the MIB extensions managed to create new counters that just happened to closely match statistics kept by some version of BIND. As a result, the MIB extensions ended up being much too big, which raised a number
MIB扩展最初相当特定于一个特定的DNS实现（BIND-4.8.3）；随着工作的进行，特定于BIND的部分被重写为与实现无关的部分，因为我们知道如何制作它们，但不知何故，MIB扩展的每一次修订都设法创建了新的计数器，这些计数器恰好与BIND的某个版本保存的统计数据非常匹配。结果，MIB扩展太大了，这增加了一个数字
of concerns with the network management directorate, but the WG resisted every attempt to remove any of these variables. In the end, large portions of the MIB extensions were moved into optional groups in an attempt to get the required subset down to a manageable size.
尽管网络管理委员会对此表示担忧，但工作组拒绝了任何消除这些变量的尝试。最后，大部分MIB扩展被移动到可选组中，以尝试将所需的子集降低到可管理的大小。
The DNS Server and Resolver MIB extensions were one of the first attempts to write MIB extensions for a protocol usually considered to be at the application layer. Fairly early on it became clear that, while it was certainly possible to write MIB extensions for DNS, the SMI was not really designed with this sort of thing in mind. A case in point was the attempt to provide direct indexing into the caches in the resolver MIB extensions: while arguably the only sane way to do this for a large cache, this required much more complex indexing clauses than is usual, and ended up running into known length limits for object identifiers in some SNMP implementations.
DNS服务器和解析器MIB扩展是为通常被认为是在应用层的协议编写MIB扩展的首批尝试之一。很早以前就很清楚，虽然为DNS编写MIB扩展肯定是可能的，但SMI的设计并没有真正考虑到这一点。一个典型的例子是尝试在解析器MIB扩展中为缓存提供直接索引：虽然可以说这是对大型缓存执行此操作的唯一明智的方法，但这需要比通常更复杂的索引子句，并且最终在某些SNMP实现中遇到了对象标识符的已知长度限制。
Furthermore, the lack of either real proxy MIB support in SNMP managers or a standard subagent protocol meant that there was no reasonable way to implement the MIB extensions in the dominant implementation (BIND). When the AgentX subagent protocol was developed a few years later, we initially hoped that this would finally clear the way for an implementation of the DNS MIB extensions, but by the time AgentX was a viable protocol it had become clear that nobody really wanted to implement these MIB extensions.
此外，SNMP管理器中缺少真正的代理MIB支持，或者缺少标准的子代理协议，这意味着没有合理的方法在主要实现（BIND）中实现MIB扩展。当AgentX子代理协议在几年后开发出来时，我们最初希望这将最终为DNS MIB扩展的实现扫清道路，但当AgentX成为一个可行的协议时，已经很清楚没有人真正想要实现这些MIB扩展。
Finally, the MIB extensions took much too long to produce. In retrospect, this should have been a clear warning sign, particularly when the WG had clearly become so tired of the project that the authors found it impossible to elicit any comments whatsoever on the documents.
最后，MIB扩展的生成时间太长。回想起来，这本应该是一个明确的警告信号，特别是当工作组显然已经厌倦了这个项目，以至于作者发现不可能对文件提出任何评论时。
Observations based on the preceding list of mistakes, for the benefit of anyone else who ever attempts to write DNS MIB extensions again:
基于上述错误列表的观察结果，为了再次尝试编写DNS MIB扩展的其他人的利益：
- Define a clear set of goals before writing any MIB extensions. Know who the constituency is and make sure that what you write solves their problem.
- 在编写任何MIB扩展之前，定义一组明确的目标。知道选民是谁，确保你写的东西解决了他们的问题。
- Keep the MIB extensions short, and don't add variables just because somebody in the WG thinks they'd be a cool thing to measure.
- 保持MIB扩展简短，不要仅仅因为工作组中有人认为变量很酷就添加变量。
- If some portion of the task seems to be very hard to do within the SMI, that's a strong hint that SNMP is not the right tool for whatever it is that you're trying to do.
- 如果任务的某一部分似乎很难在SMI中完成，那么这就强烈地暗示，无论您尝试做什么，SNMP都不是合适的工具。
- If the entire project is taking too long, perhaps that's a hint too.
- 如果整个项目花费的时间太长，也许这也是一个暗示。
In view of the community's apparent total lack of interest in deploying these MIB extensions, we recommend that RFCs 1611 and 1612 be reclassified as Historical documents.
鉴于社区显然对部署这些MIB扩展完全不感兴趣，我们建议将RFC 1611和1612重新分类为历史文档。
Re-classifying an existing MIB document from Proposed Standard to Historic should not have any negative impact on security for the Internet.
将现有MIB文档从建议的标准重新分类为历史文件不应对Internet的安全性产生任何负面影响。
Getting rid of the DNS MIB extensions should not impose any new work on IANA.
去掉DNS MIB扩展不应该在IANA上强加任何新的工作。
The author would like to thank all the people who were involved in this project over the years for their optimism and patience, misguided though it may have been.
作者要感谢多年来参与这个项目的所有人，感谢他们的乐观和耐心，尽管这个项目可能被误导了。
[DNS-SERVER-MIB] Austein, R. and J. Saperia, "DNS Server MIB Extensions", RFC 1611, May 1994.
[DNS-SERVER-MIB]Austein，R.和J.Saperia，“DNS服务器MIB扩展”，RFC 16111994年5月。
[DNS-RESOLVER-MIB] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", RFC 1612, May 1994.
[DNS-RESOLVER-MIB]Austein，R.和J.Saperia，“DNS解析器MIB扩展”，RFC 1612，1994年5月。
[DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[DNS-DYNAMIC-UPDATE]Vixie，P.，Thomson，S.，Rekhter，Y.和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[AGENTX] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000.
[AGENTX]Daniele，M.，Wijnen，B.，Ellison，M.，和D.Francisco，“代理可扩展性（AGENTX）协议版本1”，RFC 27412000年1月。
Rob Austein InterNetShare, Incorporated 325M Sharon Park Drive, Suite 308 Menlo Park, CA 94025 USA
Rob Austein InterNetShare，注册成立于美国加利福尼亚州门罗公园夏隆公园大道325M号308室，邮编94025
EMail: sra@hactrn.net
EMail: sra@hactrn.net
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。