Browse Prior Art Database

Applicability Statement for DNS MIB Extensions (RFC3197)

IP.com Disclosure Number: IPCOM000006035D
Original Publication Date: 2001-Nov-01
Included in the Prior Art Database: 2019-Feb-14
Document File: 5 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Austein: AUTHOR

Related Documents

10.17487/RFC3197: DOI

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. This memo provides information for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 39% of the total text.

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 implementatio...

Processing...
Loading...