Summary

  • In 2001, RFC 3197 said the DNS Server MIB and DNS Resolver MIB had not been deployed despite more than six years as Proposed Standards, and recommended moving RFCs 1611 and 1612 to Historical.
  • Its sharper lesson is institutional: a technically imaginable management interface can remain unused when no constituency, implementation path and sustained demand meet around it. That judgment is the RFC author's retrospective, not an independent census.

When a standard records its own stalled project

DNS became foundational by answering a compact question—what information belongs to this name?—through a distributed hierarchy of servers and caches. Network operators still needed ways to inspect and manage those systems. The 1994 DNS Server MIB and DNS Resolver MIB proposed exposing configuration and operational statistics through SNMP, the management framework used elsewhere in the Internet stack.

Seven years later, RFC 3197 did not announce a new DNS capability. It explained why these management specifications had failed to attract implementation and recommended that the standards record acknowledge it. The document is unusually direct: after more than six years as Proposed Standards, RFCs 1611 and 1612 were, in its author's words, never deployed. The recommendation was to make them Historical, not to change how DNS resolves names.

That distinction matters. DNS protocol success is not evidence that a particular SNMP interface was implemented. Nor does “never deployed” prove that operators had no monitoring, that vendors lacked private counters, or that every deployment behaved alike. RFC 3197 supplies a standards participant's account of these two specifications, not a measured survey of products.

A management interface looking for a constituency

The postmortem describes a project whose purpose never settled. Some participants, it says, wanted SNMP SET operations to perform dynamic DNS updates. But the SNMP security model was not an adequate foundation for that function; dynamic update was a separate DNS protocol, later specified by RFC 2136. A tool for observing and configuring a service was being asked to stand in for a different control mechanism.

Implementation fit also proved costly. The initial server MIB reflected a specific BIND release; later counters followed implementation statistics rather than a stable, shared operational model. The proposals grew. Resolver-cache indexing became intricate enough to run into object-identifier length limits in some SNMP implementations. And the dominant BIND architecture lacked both a standard proxy MIB path and a standard subagent protocol that would make integration straightforward.

RFC 2741's AgentX eventually offered a standard subagent model, but RFC 3197 says the timing was too late: by then, its author believed no one remained willing to implement these MIBs. That is the author's explanation, not a claim that AgentX itself failed or that BIND never exposed any useful statistics.

Retirement as useful information

The RFC's recommendations are practical: define a constituency and goals before writing a MIB; keep extensions short; avoid collecting “cool” counters without a clear operational purpose; and treat persistent difficulty expressing the objects in SMI as evidence that SNMP might be the wrong interface. A project that takes years without review or implementation is not automatically more mature because it has a standards-track label.

RFC 3197 is Informational and explicitly not an Internet Standard. Its formal recommendation was to reclassify RFCs 1611 and 1612. Their RFC Editor records now mark them Historic. That is a lifecycle decision about two management documents. The DNS architecture in RFCs 1034 and 1035 continued to serve a different function; dynamic update had its own protocol; SNMP and MIB-II remained useful in other contexts.

The value of this episode is not a morality tale about SNMP. It is a rare record of standards maintenance admitting that publication had not produced adoption. Retirement preserved the distinction between an idea that can be specified and an interface that operators and implementers actually want to carry.

Sources

Evidence boundary

The “never deployed” claim and explanations of project failure come from RFC 3197's author. The RFC Editor records establish document metadata and current status; they do not provide an independent deployment census, quantify operator demand, or show that DNS itself lacked operational management.