--- /dev/null
+
+
+
+
+
+
+Network Working Group R. Austein
+Request for Comments: 3197 InterNetShare
+Category: Informational November 2001
+
+
+ Applicability Statement for DNS MIB Extensions
+
+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.
+
+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.
+
+1. History
+
+ The road to the DNS MIB extensions was paved with good intentions.
+
+ 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.
+
+ 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
+
+
+
+Austein Informational [Page 1]
+\f
+RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+2. Lessons
+
+ Observations based on the preceding list of mistakes, for the benefit
+ of anyone else who ever attempts to write DNS MIB extensions again:
+
+ - 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.
+
+ - 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.
+
+ - 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.
+
+
+
+Austein Informational [Page 2]
+\f
+RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
+
+
+ - If the entire project is taking too long, perhaps that's a hint
+ too.
+
+3. Recommendation
+
+ 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.
+
+4. Security Considerations
+
+ Re-classifying an existing MIB document from Proposed Standard to
+ Historic should not have any negative impact on security for the
+ Internet.
+
+5. IANA Considerations
+
+ Getting rid of the DNS MIB extensions should not impose any new work
+ on IANA.
+
+6. Acknowledgments
+
+ 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.
+
+7. References
+
+ [DNS-SERVER-MIB] Austein, R. and J. Saperia, "DNS Server MIB
+ Extensions", RFC 1611, May 1994.
+
+ [DNS-RESOLVER-MIB] Austein, R. and J. Saperia, "DNS Resolver MIB
+ Extensions", RFC 1612, May 1994.
+
+ [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.
+
+ [AGENTX] Daniele, M., Wijnen, B., Ellison, M., and D.
+ Francisco, "Agent Extensibility (AgentX)
+ Protocol Version 1", RFC 2741, January 2000.
+
+
+
+
+
+
+
+
+
+
+Austein Informational [Page 3]
+\f
+RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
+
+
+8. Author's Address
+
+ Rob Austein
+ InterNetShare, Incorporated
+ 325M Sharon Park Drive, Suite 308
+ Menlo Park, CA 94025
+ USA
+
+ EMail: sra@hactrn.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Informational [Page 4]
+\f
+RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Informational [Page 5]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group D. Lawrence
+Request for Comments: 3425 Nominum
+Updates: 1035 November 2002
+Category: Standards Track
+
+
+ Obsoleting IQUERY
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ The IQUERY method of performing inverse DNS lookups, specified in RFC
+ 1035, has not been generally implemented and has usually been
+ operationally disabled where it has been implemented. Both reflect a
+ general view in the community that the concept was unwise and that
+ the widely-used alternate approach of using pointer (PTR) queries and
+ reverse-mapping records is preferable. Consequently, this document
+ deprecates the IQUERY operation, declaring it entirely obsolete.
+ This document updates RFC 1035.
+
+1 - Introduction
+
+ As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS
+ queries is used to look up the name(s) which are associated with the
+ given value. The value being sought is provided in the query's
+ answer section and the response fills in the question section with
+ one or more 3-tuples of type, name and class.
+
+ As noted in [RFC1035], section 6.4.3, inverse query processing can
+ put quite an arduous burden on a server. A server would need to
+ perform either an exhaustive search of its database or maintain a
+ separate database that is keyed by the values of the primary
+ database. Both of these approaches could strain system resource use,
+ particularly for servers that are authoritative for millions of
+ names.
+
+
+
+
+
+Lawrence Standards Track [Page 1]
+\f
+RFC 3425 Obsoleting IQUERY November 2002
+
+
+ Response packets from these megaservers could be exceptionally large,
+ and easily run into megabyte sizes. For example, using IQUERY to
+ find every domain that is delegated to one of the nameservers of a
+ large ISP could return tens of thousands of 3-tuples in the question
+ section. This could easily be used to launch denial of service
+ attacks.
+
+ Operators of servers that do support IQUERY in some form (such as
+ very old BIND 4 servers) generally opt to disable it. This is
+ largely due to bugs in insufficiently-exercised code, or concerns
+ about exposure of large blocks of names in their zones by probes such
+ as inverse MX queries.
+
+ IQUERY is also somewhat inherently crippled by being unable to tell a
+ requester where it needs to go to get the information that was
+ requested. The answer is very specific to the single server that was
+ queried. This is sometimes a handy diagnostic tool, but apparently
+ not enough so that server operators like to enable it, or request
+ implementation where it is lacking.
+
+ No known clients use IQUERY to provide any meaningful service. The
+ only common reverse mapping support on the Internet, mapping address
+ records to names, is provided through the use of pointer (PTR)
+ records in the in-addr.arpa tree and has served the community well
+ for many years.
+
+ Based on all of these factors, this document recommends that the
+ IQUERY operation for DNS servers be officially obsoleted.
+
+2 - Requirements
+
+ The key word "SHOULD" in this document is to be interpreted as
+ described in BCP 14, RFC 2119, namely that there may exist valid
+ reasons to ignore a particular item, but the full implications must
+ be understood and carefully weighed before choosing a different
+ course.
+
+3 - Effect on RFC 1035
+
+ The effect of this document is to change the definition of opcode 1
+ from that originally defined in section 4.1.1 of RFC 1035, and to
+ entirely supersede section 6.4 (including subsections) of RFC 1035.
+
+ The definition of opcode 1 is hereby changed to:
+
+ "1 an inverse query (IQUERY) (obsolete)"
+
+
+
+
+
+Lawrence Standards Track [Page 2]
+\f
+RFC 3425 Obsoleting IQUERY November 2002
+
+
+ The text in section 6.4 of RFC 1035 is now considered obsolete. The
+ following is an applicability statement regarding the IQUERY opcode:
+
+ Inverse queries using the IQUERY opcode were originally described as
+ the ability to look up the names that are associated with a
+ particular Resource Record (RR). Their implementation was optional
+ and never achieved widespread use. Therefore IQUERY is now obsolete,
+ and name servers SHOULD return a "Not Implemented" error when an
+ IQUERY request is received.
+
+4 - Security Considerations
+
+ Since this document obsoletes an operation that was once available,
+ it is conceivable that someone was using it as the basis of a
+ security policy. However, since the most logical course for such a
+ policy to take in the face of a lack of positive response from a
+ server is to deny authentication/authorization, it is highly unlikely
+ that removing support for IQUERY will open any new security holes.
+
+ Note that if IQUERY is not obsoleted, securing the responses with DNS
+ Security (DNSSEC) is extremely difficult without out-on-the-fly
+ digital signing.
+
+5 - IANA Considerations
+
+ The IQUERY opcode of 1 should be permanently retired, not to be
+ assigned to any future opcode.
+
+6 - Acknowledgments
+
+ Olafur Gudmundsson instigated this action. Matt Crawford, John
+ Klensin, Erik Nordmark and Keith Moore contributed some improved
+ wording in how to handle obsoleting functionality described by an
+ Internet Standard.
+
+7 - References
+
+ [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+ Specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+Lawrence Standards Track [Page 3]
+\f
+RFC 3425 Obsoleting IQUERY November 2002
+
+
+8 - Author's Address
+
+ David C Lawrence
+ Nominum, Inc.
+ 2385 Bay Rd
+ Redwood City CA 94063
+ USA
+
+ Phone: +1.650.779.6042
+ EMail: tale@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lawrence Standards Track [Page 4]
+\f
+RFC 3425 Obsoleting IQUERY November 2002
+
+
+9 - Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lawrence Standards Track [Page 5]
+\f
projects / thirdparty / bind9.git / commitdiff
