RFC 3197 (rfc3197) - Page 1 of 5
Applicability Statement for DNS MIB Extensions
Alternative Format: Original Text Document
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