Subject: DNS Resolver Instrumentation

From: Jon Saperia <[email-masked]>
Date: Thu, 08 Apr 1999 07:58:14 +0100

At the last IETF meeting Randy asked if I would put together some
information on existing DNS instrumentation that is relevant to remote
management/diagnostics of the DNS.  In particular there was a discussion
about development of a MIB for testing DNS responsiveness similar to
that provided in the PING MIB.  I suggested that this was somewhat more
complex.  Below is a list of some of the objects that do exist in the
DNS Resolver MIB [RFC1612] that may be helpful in remote diagnostics. 
They are the DNS Resolver Safety Belt Table in the configuration group.

   dnsResConfigSbeltAddr OBJECT-TYPE
       SYNTAX      IpAddress
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "The IP address of the Sbelt name server identified by
               this row of the table."
       ::= { dnsResConfigSbeltEntry 1 }

   dnsResConfigSbeltName OBJECT-TYPE
       SYNTAX      DnsName
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
               "The DNS name of a Sbelt nameserver identified by this
               row of the table.  A zero-length string indicates that
               the name is not known by the resolver."
       ::= { dnsResConfigSbeltEntry 2 }

   dnsResConfigSbeltRecursion OBJECT-TYPE
       SYNTAX      INTEGER { iterative(1),
                             recursive(2),
                             recursiveAndIterative(3) }
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
               "Kind of queries resolver will be sending to the name
               server identified in this row of the table:

               iterative(1) indicates that resolver will be directing
               iterative queries to this name server (RD bit turned
               off).

               recursive(2) indicates that resolver will be directing
               recursive queries to this name server (RD bit turned
               on).

               recursiveAndIterative(3) indicates that the resolver
               will be directing both recursive and iterative queries
               to the server identified in this row of the table."
        ::= { dnsResConfigSbeltEntry 3 }

   dnsResConfigSbeltPref OBJECT-TYPE
       SYNTAX      INTEGER (0..2147483647)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
               "This value identifies the preference for the name server
               identified in this row of the table.  The lower the
               value, the more desirable the resolver considers this
               server."
        ::= { dnsResConfigSbeltEntry 4 }

   dnsResConfigSbeltSubTree OBJECT-TYPE
       SYNTAX      DnsNameAsIndex
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "Queries sent to the name server identified by this row
               of the table are limited to those for names in the name
               subtree identified by this variable.  If no such
               limitation applies, the value of this variable is the
               name of the root domain (a DNS name consisting of a
               single zero octet)."
       ::= { dnsResConfigSbeltEntry 5 }

   dnsResConfigSbeltClass OBJECT-TYPE
       SYNTAX      DnsClass
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "The class of DNS queries that will be sent to the server
               identified by this row of the table."
       ::= { dnsResConfigSbeltEntry 6 }

   dnsResConfigSbeltStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
               "Row status column for this row of the Sbelt table."
       ::= { dnsResConfigSbeltEntry 7 }

   dnsResConfigUpTime OBJECT-TYPE
       SYNTAX      DnsTime
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "If the resolver has a persistent state (e.g., a
               process), this value will be the time elapsed since it
               started.  For software without persistant state, this
               value will be 0."
       ::= { dnsResConfig 5 }

   dnsResConfigResetTime OBJECT-TYPE
       SYNTAX      DnsTime
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "If the resolver has a persistent state (e.g., a process)
               and supports a `reset' operation (e.g., can be told to
               re-read configuration files), this value will be the
               time elapsed since the last time the resolver was
               `reset.'  For software that does not have persistence or
               does not support a `reset' operation, this value will be
               zero."
       ::= { dnsResConfig 6 }

   dnsResConfigReset OBJECT-TYPE
       SYNTAX      INTEGER { other(1),
                             reset(2),
                             initializing(3),
                             running(4) }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
               "Status/action object to reinitialize any persistant
               resolver state.  When set to reset(2), any persistant
               resolver state (such as a process) is reinitialized as if
               the resolver had just been started.  This value will
               never be returned by a read operation.  When read, one of
               the following values will be returned:
                   other(1) - resolver in some unknown state;
                   initializing(3) - resolver (re)initializing;
                   running(4) - resolver currently running."
       ::= { dnsResConfig 7 }

On reading this, it would seem to me that it would be possible to write
a table which AUGMENTS this table which could be used for reachability
testing of different sorts.  Entries could not exist in that other table
unless there was an entry first in this one.  This would solve one of
the other problems I mentioned at the meeting.  That is that resolvers
that I know of are generally implemented as library functions not as
standalone processes.  An agent which implements this test mib could
probably usefully implement several other portions of this mib.

The DNS Server MIB [RFC1611] has several tables that might also be of
use in remote identification of problems.  One is the 

dnsServZoneTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF DnsServZoneEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "Table of zones for which this name server provides
               information.  Each of the zones may be loaded from stable
               storage via an implementation specific mechanism or may
               be obtained from another name server via a zone transfer.

               If name server doesn't load any zones, this table is
               empty."
       ::= { dnsServZone 1 }

By looking at this table it would be possible to determine if the server
in question 'thought' that it was supposed to provide service to the
host which implemented the resolver mib described above.

There are several counter tables which also contain error information of value.

Now, to implementation.  Any mib which does this tests would probably
have to be implemented as a separate process or made part of some other
agent which has persistence (that is a process).  It seems unlikely that
any of the platform vendors would implement this.  My recommendation
would be that if this group decides to take this up as a work item,
somebody should sign-on for a public implementation which would work
with popular resolver implementations, and the most popular Sever base
which is BIND.

/jon