From a85fa508e28dd2919a7ece1a02c482df1a6eff60 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 14 Mar 2003 23:37:56 +0000 Subject: [PATCH] added --- doc/rfc/rfc3197.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++ doc/rfc/rfc3425.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 566 insertions(+) create mode 100644 doc/rfc/rfc3197.txt create mode 100644 doc/rfc/rfc3425.txt diff --git a/doc/rfc/rfc3197.txt b/doc/rfc/rfc3197.txt new file mode 100644 index 0000000000..94cefa4c6b --- /dev/null +++ b/doc/rfc/rfc3197.txt @@ -0,0 +1,283 @@ + + + + + + +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] + +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] + +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] + +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] + +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] + diff --git a/doc/rfc/rfc3425.txt b/doc/rfc/rfc3425.txt new file mode 100644 index 0000000000..707cafd18a --- /dev/null +++ b/doc/rfc/rfc3425.txt @@ -0,0 +1,283 @@ + + + + + + +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] + +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] + +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] + +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] + +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] +