RFC 3197

RFC 3197: Applicability Statement for DNS MIB Extensions 💖

Okay bestie, this one is from November 2001 and it's written by R. Austein from InterNetShare 🌸 It's marked as Informational, so it's sharing info, not setting a rule. Its header doesn't list any obsoletes or updates entries, so nothing gets replaced or patched. Let's go! ✨

---

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 doc explains why the DNS Server and Resolver MIB extensions were never deployed, even after more than six years as proposed standards 😭. It recommends retiring them by moving them to Historical status 🪦.

1. History 🕰️

The road to the DNS MIB extensions was paved with good intentions 🛣️💖

So the working group never really agreed on what belonged in the MIB extensions. They just knew they should have some. This was peak MIB mania, with basically every protocol the IETF worked on getting its own MIB extensions, so nobody really asked why they were doing it 🙈. Super late in the process, the team realized a lot of the push for these MIB extensions came from people who wanted to use SNMP SET operations to update DNS zones on the fly. Looking at the security model, though, it was a no-go 🚫. It was not a good way to do dynamic update, and a separate DNS Dynamic Update protocol was needed instead 🔐

The MIB extensions started out pretty specific to one DNS implementation, BIND-4.8.3 💅. As they went on, the BIND-specific parts got rewritten to be as implementation-neutral as the team could manage. But somehow every revision kept adding new counters that just happened to match stats kept by some version of BIND 👀. The result was way too big, which worried the network management directorate. The WG kept refusing to remove any of the variables 😤. In the end, big chunks got moved into optional groups to shrink the required subset to something manageable 🫠

These were some of the first MIB extensions for a protocol usually considered to be at the application layer 🧚. It became clear early on that you could write MIB extensions for DNS, but the SMI wasn't really built for this kind of thing 😬. Take the direct indexing into the resolver caches: it was arguably the only sane way to handle a large cache, but it needed much more complex indexing clauses than usual. It also ran into known length limits for object identifiers in some SNMP implementations 💀

On top of that, SNMP managers didn't have real proxy MIB support, and there was no standard subagent protocol either. So there was no reasonable way to implement these MIB extensions in the dominant implementation, BIND 😩. When the AgentX subagent protocol came out a few years later, the team hoped it would finally unlock an implementation. By the time AgentX was a viable protocol, though, it was clear that nobody actually wanted to implement these MIB extensions 🥲

And honestly, they took way too long to produce. Looking back, that should have been a big red flag 🚩. The WG had clearly gotten so burnt out that the authors couldn't get a single comment on the documents 💔

2. Lessons 📝

Here's what we learned from all those mistakes, for anyone brave enough to try writing DNS MIB extensions again 🫶

• Define a clear set of goals before writing any MIB extensions. Know who the constituency is and make sure 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 part of the task seems really hard to do within the SMI, that's a strong hint that SNMP is not the right tool for whatever you're trying to do 🔧
• If the entire project is taking too long, maybe that's a hint too ⏳

3. Recommendation 💅

Since the community has shown basically zero interest in deploying these MIB extensions, we recommend that RFCs 1611 and 1612 be reclassified as Historical documents 🪦✨

4. Security Considerations 🔐

Okay, this is the serious part 😤 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 everyone who was 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.

8. Author's Address 💌

Rob Austein
InterNetShare, Incorporated
325M Sharon Park Drive, Suite 308
Menlo Park, CA  94025
USA

EMail: sra@hactrn.net

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. Derivative works that comment on or otherwise explain it, or help with implementing it, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind. That's allowed as long as 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. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's 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 💅✨