rfc1612.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,796 行 · 第 1/5 页

Network Working Group                                         R. Austein
Request for Comments: 1612               Epilogue Technology Corporation
Category: Standards Track                                     J. Saperia
                                           Digital Equipment Corporation
                                                                May 1994


                      DNS Resolver MIB Extensions

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.

Table of Contents

   1. Introduction ..............................................    1
   2. The SNMPv2 Network Management Framework ...................    2
   2.1 Object Definitions .......................................    2
   3. Overview ..................................................    2
   3.1 Resolvers ................................................    3
   3.2 Name Servers .............................................    3
   3.3 Selected Objects .........................................    4
   3.4 Textual Conventions ......................................    4
   4. Definitions ...............................................    5
   5. Acknowledgements ..........................................   30
   6. References ................................................   30
   7. Security Considerations ...................................   32
   8. Authors' Addresses ........................................   32

1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes a set of extensions which instrument DNS
   resolver functions.  This memo was produced by the DNS working group.

   With the adoption of the Internet-standard Network Management
   Framework [4,5,6,7], and with a large number of vendor
   implementations of these standards in commercially available
   products, it became possible to provide a higher level of effective
   network management in TCP/IP-based internets than was previously
   available.  With the growth in the use of these standards, it has
   become possible to consider the management of other elements of the
   infrastructure beyond the basic TCP/IP protocols.  A key element of



Austein & Saperia                                               [Page 1]

RFC 1612                    DNS Resolver MIB                    May 1994


   the TCP/IP infrastructure is the DNS.

   Up to this point there has been no mechanism to integrate the
   management of the DNS with SNMP-based managers.  This memo provides
   the mechanisms by which IP-based management stations can effectively
   manage DNS resolver software in an integrated fashion.

   We have defined DNS MIB objects to be used in conjunction with the
   Internet MIB to allow access to and control of DNS resolver software
   via SNMP by the Internet community.

2.  The SNMPv2 Network Management Framework

   The SNMPv2 Network Management Framework consists of four major
   components.  They are:

      o  RFC 1442 which defines the SMI, the mechanisms used for
         describing and naming objects for the purpose of management.

      o  STD 17, RFC 1213 defines MIB-II, the core set of managed
         objects for the Internet suite of protocols.

      o  RFC 1445 which defines the administrative and other
         architectural aspects of the framework.

      o  RFC 1448 which defines the protocol used for network access to
         managed objects.

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

2.1.  Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1)
   defined in the SMI.  In particular, each object object type is named
   by an OBJECT IDENTIFIER, an administratively assigned name.  The
   object type together with an object instance serves to uniquely
   identify a specific instantiation of the object.  For human
   convenience, we often use a textual string, termed the descriptor, to
   refer to the object type.

3.  Overview

   In theory, the DNS world is pretty simple.  There are two kinds of
   entities: resolvers and name servers.  Resolvers ask questions.  Name
   servers answer them.  The real world, however, is not so simple.



Austein & Saperia                                               [Page 2]

RFC 1612                    DNS Resolver MIB                    May 1994


   Implementors have made widely differing choices about how to divide
   DNS functions between resolvers and servers.  They have also
   constructed various sorts of exotic hybrids.  The most difficult task
   in defining this MIB was to accommodate this wide range of entities
   without having to come up with a separate MIB for each.

   We divided up the various DNS functions into two, non-overlapping
   classes, called "resolver functions" and "name server functions."  A
   DNS entity that performs what we define as resolver functions
   contains a resolver, and therefore must implement the MIB groups
   required of all resolvers which are defined in this module.  Some
   resolvers also implement "optional" functions such as a cache, in
   which case they must also implement the cache group contained in this
   MIB.  A DNS entity which implements name server functions is
   considered to be a name server, and must implement the MIB groups
   required for name servers which are defined in a separate module.  If
   the same piece of software performs both resolver and server
   functions, we imagine that it contains both a resolver and a server
   and would thus implement both the DNS Server and DNS Resolver MIBs.

3.1.  Resolvers

   In our model, a resolver is a program (or piece thereof) which
   obtains resource records from servers.  Normally it does so at the
   behest of an application, but may also do so as part of its own
   operation.  A resolver sends DNS protocol queries and receives DNS
   protocol replies.  A resolver neither receives queries nor sends
   replies.  A full service resolver is one that knows how to resolve
   queries: it obtains the needed resource records by contacting a
   server authoritative for the records desired.  A stub resolver does
   not know how to resolve queries: it sends all queries to a local name
   server, setting the "recursion desired" flag to indicate that it
   hopes that the name server will be willing to resolve the query.  A
   resolver may (optionally) have a cache for remembering previously
   acquired resource records.  It may also have a negative cache for
   remembering names or data that have been determined not to exist.

3.2.  Name Servers

   A name server is a program (or piece thereof) that provides resource
   records to resolvers.  All references in this document to "a name
   server" imply "the name server's role"; in some cases the name
   server's role and the resolver's role might be combined into a single
   program.  A name server receives DNS protocol queries and sends DNS
   protocol replies.  A name server neither sends queries nor receives
   replies.  As a consequence, name servers do not have caches.
   Normally, a name server would expect to receive only those queries to
   which it could respond with authoritative information.  However, if a



Austein & Saperia                                               [Page 3]

RFC 1612                    DNS Resolver MIB                    May 1994


   name server receives a query that it cannot respond to with purely
   authoritative information, it may choose to try to obtain the
   necessary additional information from a resolver which may or may not
   be a separate process.

3.3.  Selected Objects

   Many of the objects included in this memo have been created from
   information contained in the DNS specifications [1,2], as amended and
   clarified by subsequent host requirements documents [3].  Other
   objects have been created based on experience with existing DNS
   management tools, expected operational needs, the statistics
   generated by existing DNS implementations, and the configuration
   files used by existing DNS implementations.  These objects have been
   ordered into groups as follows:

         o  Resolver Configuration Group

         o  Resolver Counter Group

         o  Resolver Lame Delegation Group

         o  Resolver Cache Group

         o  Resolver Negative Cache Group

         o  Resolver Optional Counter Group

   This information has been converted into a standard form using the
   SNMPv2 SMI defined in [9].  For the most part, the descriptions are
   influenced by the DNS related RFCs noted above.  For example, the
   descriptions for counters used for the various types of queries of
   DNS records are influenced by the definitions used for the various
   record types found in [2].

3.4.  Textual Conventions

   Several conceptual data types have been introduced as a textual
   conventions in the DNS Server MIB document and have been imported
   into this MIB module.  These additions will facilitate the common
   understanding of information used by the DNS.  No changes to the SMI
   or the SNMP are necessary to support these conventions.

   Readers familiar with MIBs designed to manage entities in the lower
   layers of the Internet protocol suite may be surprised at the number
   of non-enumerated integers used in this MIB to represent values such
   as DNS RR class and type numbers.  The reason for this choice is
   simple: the DNS itself is designed as an extensible protocol,



Austein & Saperia                                               [Page 4]

RFC 1612                    DNS Resolver MIB                    May 1994


   allowing new classes and types of resource records to be added to the
   protocol without recoding the core DNS software.  Using non-
   enumerated integers to represent these data types in this MIB allows
   the MIB to accommodate these changes as well.

4.  Definitions

   DNS-RESOLVER-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Counter32, Integer32
           FROM SNMPv2-SMI
       TEXTUAL-CONVENTION, RowStatus, DisplayString
           FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP
           FROM SNMPv2-CONF
       dns, DnsName, DnsNameAsIndex, DnsClass, DnsType, DnsQClass,
       DnsQType, DnsTime, DnsOpCode, DnsRespCode
           FROM DNS-SERVER-MIB;

   -- DNS Resolver MIB

   dnsResMIB MODULE-IDENTITY
       LAST-UPDATED "9401282250Z"
       ORGANIZATION "IETF DNS Working Group"
       CONTACT-INFO
               "       Rob Austein
               Postal: Epilogue Technology Corporation
                       268 Main Street, Suite 283
                       North Reading, MA 10864
                       US
                  Tel: [phone]
                  Fax: [phone]
               E-Mail: [e-mail]

                       Jon Saperia
               Postal: Digital Equipment Corporation
                       110 Spit Brook Road
                       ZKO1-3/H18
                       Nashua, NH 03062-2698
                       US
                  Tel: [phone]
                  Fax: [phone]
               E-mail: [e-mail]"
       DESCRIPTION
               "The MIB module for entities implementing the client
               (resolver) side of the Domain Name System (DNS)
               protocol."



Austein & Saperia                                               [Page 5]

RFC 1612                    DNS Resolver MIB                    May 1994


       ::= { dns 2 }

   dnsResMIBObjects        OBJECT IDENTIFIER ::= { dnsResMIB 1 }

   -- (Old-style) groups in the DNS resolver MIB.

   dnsResConfig            OBJECT IDENTIFIER ::= { dnsResMIBObjects 1 }
   dnsResCounter           OBJECT IDENTIFIER ::= { dnsResMIBObjects 2 }
   dnsResLameDelegation    OBJECT IDENTIFIER ::= { dnsResMIBObjects 3 }
   dnsResCache             OBJECT IDENTIFIER ::= { dnsResMIBObjects 4 }
   dnsResNCache            OBJECT IDENTIFIER ::= { dnsResMIBObjects 5 }
   dnsResOptCounter        OBJECT IDENTIFIER ::= { dnsResMIBObjects 6 }


   -- Resolver Configuration Group

   dnsResConfigImplementIdent OBJECT-TYPE
       SYNTAX      DisplayString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The implementation identification string for the
               resolver software in use on the system, for example;
               `RES-2.1'"
       ::= { dnsResConfig 1 }

   dnsResConfigService OBJECT-TYPE
       SYNTAX      INTEGER { recursiveOnly(1),
                             iterativeOnly(2),
                             recursiveAndIterative(3) }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "Kind of DNS resolution service provided:

               recursiveOnly(1) indicates a stub resolver.

               iterativeOnly(2) indicates a normal full service
               resolver.

               recursiveAndIterative(3) indicates a full-service
               resolver which performs a mix of recursive and iterative
               queries."
        ::= { dnsResConfig 2 }

   dnsResConfigMaxCnames OBJECT-TYPE
       SYNTAX      INTEGER (0..2147483647)
       MAX-ACCESS  read-write



Austein & Saperia                                               [Page 6]

RFC 1612                    DNS Resolver MIB                    May 1994


       STATUS      current
       DESCRIPTION
               "Limit on how many CNAMEs the resolver should allow
               before deciding that there's a CNAME loop.  Zero means
               that resolver has no explicit CNAME limit."
       REFERENCE
               "RFC-1035 section 7.1."
       ::= { dnsResConfig 3 }

   -- DNS Resolver Safety Belt Table

   dnsResConfigSbeltTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF DnsResConfigSbeltEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "Table of safety belt information used by the resolver
               when it hasn't got any better idea of where to send a