added

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]
+

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]
+