As per Relevance of the word extensions, we have this rfc below:
Network Working Group R.
Request for Comments: 1611 Epilogue Technology
Category: Standards Track J.
Digital Equipment
May 1994
DNS Server MIB
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Table of
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 .......................................... 28
6. References ................................................ 28
7. Security Considerations ................................... 29
8. Authors' Addresses ........................................ 30
1.
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
name server functions. This memo was produced by the DNS
group
With the adoption of the Internet-standard Network
Framework [4,5,6,7], and with a large number of
implementations of these standards in commercially
products, it became possible to provide a higher level of
network management in TCP/IP-based internets than was
available. With the growth in the use of these standards, it
become possible to consider the management of other elements of
infrastructure beyond the basic TCP/IP protocols. A key element
Austein & Saperia [Page 1]
RFC 1611 DNS Server MIB Extensions May 1994
the TCP/IP infrastructure is the DNS
Up to this point there has been no mechanism to integrate
management of the DNS with SNMP-based managers. This memo
the mechanisms by which IP-based management stations can
manage DNS name server software in an integrated fashion
We have defined DNS MIB objects to be used in conjunction with
Internet MIB to allow access to and control of DNS name
software via SNMP by the Internet community
2. The SNMPv2 Network Management
The SNMPv2 Network Management Framework consists of four
components. They are
o RFC 1442 which defines the SMI, the mechanisms used
describing and naming objects for the purpose of management
o STD 17, RFC 1213 defines MIB-II, the core set of managed
for the Internet suite of protocols
o RFC 1445 which defines the administrative and other
aspects of the framework
o RFC 1448 which defines the protocol used for network access
managed objects
The Framework permits new objects to be defined for the purpose
experimentation and evaluation
2.1. Object
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object object type is
by an OBJECT IDENTIFIER, an administratively assigned name.
object type together with an object instance serves to
identify a specific instantiation of the object. For
convenience, we often use a textual string, termed the descriptor,
refer to the object type
3.
In theory, the DNS world is pretty simple. There are two kinds
entities: resolvers and name servers. Resolvers ask questions.
servers answer them. The real world, however, is not so simple
Austein & Saperia [Page 2]
RFC 1611 DNS Server MIB Extensions May 1994
Implementors have made widely differing choices about how to
DNS functions between resolvers and servers. They have
constructed various sorts of exotic hybrids. The most difficult
in defining this MIB was to accommodate this wide range of
without having to come up with a separate MIB for each
We divided up the various DNS functions into two, non-
classes, called "resolver functions" and "name server functions."
DNS entity that performs what we define as resolver
contains a resolver, and therefore must implement the MIB
required of all resolvers which are defined in a separate MIB Module
A DNS entity which implements name server functions is considered
be a name server, and must implement the MIB groups required for
servers in this module. If the same piece of software performs
resolver and server functions, we imagine that it contains both
resolver and a server and would thus implement both the DNS
and DNS Resolver MIBs
3.1.
In our model, a resolver is a program (or piece thereof)
obtains resource records from servers. Normally it does so at
behest of an application, but may also do so as part of its
operation. A resolver sends DNS protocol queries and receives
protocol replies. A resolver neither receives queries nor
replies. A full service resolver is one that knows how to
queries: it obtains the needed resource records by contacting
server authoritative for the records desired. A stub resolver
not know how to resolve queries: it sends all queries to a local
server, setting the "recursion desired" flag to indicate that
hopes that the name server will be willing to resolve the query.
resolver may (optionally) have a cache for remembering
acquired resource records. It may also have a negative cache
remembering names or data that have been determined not to exist
3.2. Name
A name server is a program (or piece thereof) that provides
records to resolvers. All references in this document to "a
server" imply "the name server's role"; in some cases the
server's role and the resolver's role might be combined into a
program. A name server receives DNS protocol queries and sends
protocol replies. A name server neither sends queries nor
replies. As a consequence, name servers do not have caches
Normally, a name server would expect to receive only those queries
which it could respond with authoritative information. However, if
name server receives a query that it cannot respond to with
authoritative information, it may choose to try to obtain
Austein & Saperia [Page 3]
RFC 1611 DNS Server MIB Extensions May 1994
necessary additional information from a resolver which may or may
be a separate process
3.3. Selected
Many of the objects included in this memo have been created
information contained in the DNS specifications [1,2], as amended
clarified by subsequent host requirements documents [3].
objects have been created based on experience with existing
management tools, expected operational needs, the
generated by existing DNS implementations, and the
files used by existing DNS implementations. These objects have
ordered into groups as follows
o Server Configuration
o Server Counter
o Server Optional Counter
o Server Zone
This information has been converted into a standard form using
SNMPv2 SMI defined in [9]. For the most part, the descriptions
influenced by the DNS related RFCs noted above. For example,
descriptions for counters used for the various types of queries
DNS records are influenced by the definitions used for the
record types found in [2].
3.4. Textual
Several conceptual data types have been introduced as a
conventions in this DNS MIB document. These additions
facilitate the common understanding of information used by the DNS
No changes to the SMI or the SNMP are necessary to support
conventions
Readers familiar with MIBs designed to manage entities in the
layers of the Internet protocol suite may be surprised at the
of non-enumerated integers used in this MIB to represent values
as DNS RR class and type numbers. The reason for this choice
simple: the DNS itself is designed as an extensible protocol
allowing new classes and types of resource records to be added to
protocol without recoding the core DNS software. Using non
enumerated integers to represent these data types in this MIB
the MIB to accommodate these changes as well
Austein & Saperia [Page 4]
RFC 1611 DNS Server MIB Extensions May 1994
4.
DNS-SERVER-MIB DEFINITIONS ::=
mib-2
FROM RFC-1213
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY
IpAddress, Counter32, Gauge32
FROM SNMPv2-
TEXTUAL-CONVENTION, RowStatus, DisplayString,
FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-
FROM SNMPv2-CONF
dns OBJECT-
STATUS
"The OID assigned to DNS MIB work by the IANA."
::= { mib-2 32 }
dnsServMIB MODULE-
LAST-UPDATED "9401282251Z
ORGANIZATION "IETF DNS Working Group
CONTACT-
" Rob
Postal: Epilogue Technology
268 Main Street, Suite 283
North Reading, MA 10864
Tel: +1 617 245 0804
Fax: +1 617 245 8122
E-Mail: sra@epilogue.
Jon
Postal: Digital Equipment
110 Spit Brook
ZKO1-3/H18
Nashua, NH 03062-2698
Tel: +1 603 881 0480
Fax: +1 603 881 0120
Email: saperia@zko.dec.com
"The MIB module for entities implementing the server
of the Domain Name System (DNS) protocol."
::= { dns 1 }
Austein & Saperia [Page 5]
RFC 1611 DNS Server MIB Extensions May 1994
dnsServMIBObjects OBJECT IDENTIFIER ::= { dnsServMIB 1 }
-- (Old-style) groups in the DNS server MIB
dnsServConfig OBJECT IDENTIFIER ::= { dnsServMIBObjects 1 }
dnsServCounter OBJECT IDENTIFIER ::= { dnsServMIBObjects 2 }
dnsServOptCounter OBJECT IDENTIFIER ::= { dnsServMIBObjects 3 }
dnsServZone OBJECT IDENTIFIER ::= { dnsServMIBObjects 4 }
-- Textual
DnsName ::= TEXTUAL-
-- A DISPLAY-HINT would be nice, but difficult to express
STATUS
"A DNS name is a sequence of labels. When DNS names
displayed, the boundaries between labels are
indicated by dots (e.g. `Acme' and `COM' are labels
the name `Acme.COM'). In the DNS protocol, however,
such separators are needed because each label is
as a length octet followed by the indicated number
octets of label. For example, `Acme.COM' is encoded
the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O',
'M', 0 } (the final 0 is the length of the name of
root domain, which appears implicitly at the end of
DNS name). This MIB uses the same encoding as the
protocol
A DnsName must always be a fully qualified name. It
an error to encode a relative domain name as a
without first making it a fully qualified name."
"RFC-1034 section 3.1."
SYNTAX OCTET STRING (SIZE (0..255))
DnsNameAsIndex ::= TEXTUAL-
STATUS
"This textual convention is like a DnsName, but is
as an index componant in tables. Alphabetic
in names of this type are restricted to uppercase:
characters 'a' through 'z' are mapped to the
'A' through 'Z'. This restriction is intended to
the lexical ordering imposed by SNMP useful when
to DNS names
Note that it is theoretically possible for a valid
Austein & Saperia [Page 6]
RFC 1611 DNS Server MIB Extensions May 1994
name to exceed the allowed length of an SNMP
identifer, and thus be impossible to represent in
in this MIB that are indexed by DNS name. Sampling
DNS names in current use on the Internet suggests
this limit does not pose a serious problem in practice."
"RFC-1034 section 3.1, RFC-1448 section 4.1."
SYNTAX
DnsClass ::= TEXTUAL-
DISPLAY-HINT "2d
STATUS
"This data type is used to represent the class
which appear in Resource Records in the DNS. A 16-
unsigned integer is used to allow room for new
of records to be defined. Existing standard classes
listed in the DNS specifications."
"RFC-1035 section 3.2.4."
SYNTAX INTEGER (0..65535)
DnsType ::= TEXTUAL-
DISPLAY-HINT "2d
STATUS
"This data type is used to represent the type
which appear in Resource Records in the DNS. A 16-
unsigned integer is used to allow room for new
types to be defined. Existing standard types are
in the DNS specifications."
"RFC-1035 section 3.2.2."
SYNTAX INTEGER (0..65535)
DnsQClass ::= TEXTUAL-
DISPLAY-HINT "2d
STATUS
"This data type is used to represent the QClass
which appear in Resource Records in the DNS. A 16-
unsigned integer is used to allow room for new
records to be defined. Existing standard QClasses
listed in the DNS specification."
"RFC-1035 section 3.2.5."
SYNTAX INTEGER (0..65535)
Austein & Saperia [Page 7]
RFC 1611 DNS Server MIB Extensions May 1994
DnsQType ::= TEXTUAL-
DISPLAY-HINT "2d
STATUS
"This data type is used to represent the QType
which appear in Resource Records in the DNS. A 16-
unsigned integer is used to allow room for new
records to be defined. Existing standard QTypes
listed in the DNS specification."
"RFC-1035 section 3.2.3."
SYNTAX INTEGER (0..65535)
DnsTime ::= TEXTUAL-
DISPLAY-HINT "4d
STATUS
"DnsTime values are 32-bit unsigned integers
measure time in seconds."
"RFC-1035."
SYNTAX Gauge32
DnsOpCode ::= TEXTUAL-
STATUS
"This textual convention is used to represent the
OPCODE values used in the header section of
messages. Existing standard OPCODE values are listed
the DNS specifications."
"RFC-1035 section 4.1.1."
SYNTAX INTEGER (0..15)
DnsRespCode ::= TEXTUAL-
STATUS
"This data type is used to represent the DNS RCODE
in DNS response messages. Existing standard
values are listed in the DNS specifications."
"RFC-1035 section 4.1.1."
SYNTAX INTEGER (0..15)
Austein & Saperia [Page 8]
RFC 1611 DNS Server MIB Extensions May 1994
-- Server Configuration
dnsServConfigImplementIdent OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The implementation identification string for the
server software in use on the system, for example
`FNS-2.1'"
::= { dnsServConfig 1 }
dnsServConfigRecurs OBJECT-
SYNTAX INTEGER { available(1),
restricted(2),
unavailable(3) }
MAX-ACCESS read-
STATUS
"This represents the recursion services offered by
name server. The values that can be read or
are
available(1) - performs recursion on requests
clients
restricted(2) - recursion is performed on requests
from certain clients, for example; clients on an
control list
unavailable(3) - recursion is not available."
::= { dnsServConfig 2 }
dnsServConfigUpTime OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"If the server 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
be zero."
::= { dnsServConfig 3 }
dnsServConfigResetTime OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
Austein & Saperia [Page 9]
RFC 1611 DNS Server MIB Extensions May 1994
"If the server has a persistent state (e.g., a process
and supports a `reset' operation (e.g., can be told
re-read configuration files), this value will be
time elapsed since the last time the name server
`reset.' For software that does not have persistence
does not support a `reset' operation, this value will
zero."
::= { dnsServConfig 4 }
dnsServConfigReset OBJECT-
SYNTAX INTEGER { other(1),
reset(2),
initializing(3),
running(4) }
MAX-ACCESS read-
STATUS
"Status/action object to reinitialize any persistant
server state. When set to reset(2), any
name server state (such as a process) is reinitialized
if the name server had just been started. This
will never be returned by a read operation. When read
one of the following values will be returned
other(1) - server in some unknown state
initializing(3) - server (re)initializing
running(4) - server currently running."
::= { dnsServConfig 5 }
-- Server Counter
dnsServCounterAuthAns OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of queries which were authoritatively answered."
::= { dnsServCounter 2 }
dnsServCounterAuthNoNames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of queries for which `authoritative no such name
responses were made."
::= { dnsServCounter 3 }
Austein & Saperia [Page 10]
RFC 1611 DNS Server MIB Extensions May 1994
dnsServCounterAuthNoDataResps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of queries for which `authoritative no such data
(empty answer) responses were made."
::= { dnsServCounter 4 }
dnsServCounterNonAuthDatas OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of queries which were non-
answered (cached data)."
::= { dnsServCounter 5 }
dnsServCounterNonAuthNoDatas OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of queries which were non-
answered with no data (empty answer)."
::= { dnsServCounter 6 }
dnsServCounterReferrals OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests that were referred to other servers."
::= { dnsServCounter 7 }
dnsServCounterErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests the server has processed that
answered with errors (RCODE values other than 0 and 3)."
"RFC-1035 section 4.1.1."
::= { dnsServCounter 8 }
dnsServCounterRelNames OBJECT-
SYNTAX Counter32
Austein & Saperia [Page 11]
RFC 1611 DNS Server MIB Extensions May 1994
MAX-ACCESS read-
STATUS
"Number of requests received by the server for names
are only 1 label long (text form - no internal dots)."
::= { dnsServCounter 9 }
dnsServCounterReqRefusals OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of DNS requests refused by the server."
::= { dnsServCounter 10 }
dnsServCounterReqUnparses OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests received which were unparseable."
::= { dnsServCounter 11 }
dnsServCounterOtherErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests which were aborted for other (local
server errors."
::= { dnsServCounter 12 }
-- DNS Server Counter
dnsServCounterTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"Counter information broken down by DNS class and type."
::= { dnsServCounter 13 }
dnsServCounterEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"This table contains count information for each DNS
Austein & Saperia [Page 12]
RFC 1611 DNS Server MIB Extensions May 1994
and type value known to the server. The index
management software to to create indices to the table
get the specific information desired, e.g., number
queries over UDP for records with type value `A'
came to this server. In order to prevent
uncontrolled expansion of rows in the table;
dnsServCounterRequests is 0 and
is 0, then the row does not exist and `no such'
returned when the agent is queried for such instances."
INDEX { dnsServCounterOpCode
dnsServCounterQClass
dnsServCounterQType
dnsServCounterTransport }
::= { dnsServCounterTable 1 }
DnsServCounterEntry ::=
SEQUENCE {
DnsOpCode
DnsClass
DnsType
INTEGER
Counter32,
Counter32
}
dnsServCounterOpCode OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The DNS OPCODE being counted in this row of the table."
::= { dnsServCounterEntry 1 }
dnsServCounterQClass OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The class of record being counted in this row of
table."
::= { dnsServCounterEntry 2 }
Austein & Saperia [Page 13]
RFC 1611 DNS Server MIB Extensions May 1994
dnsServCounterQType OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The type of record which is being counted in this row
the table."
::= { dnsServCounterEntry 3 }
dnsServCounterTransport OBJECT-
SYNTAX INTEGER { udp(1), tcp(2), other(3) }
MAX-ACCESS not-
STATUS
"A value of udp(1) indicates that the queries reported
this row were sent using UDP
A value of tcp(2) indicates that the queries reported
this row were sent using TCP
A value of other(3) indicates that the queries
on this row were sent using a transport that was
TCP nor UDP."
::= { dnsServCounterEntry 4 }
dnsServCounterRequests OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests (queries) that have been recorded
this row of the table."
::= { dnsServCounterEntry 5 }
dnsServCounterResponses OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of responses made by the server
initialization for the kind of query identified on
row of the table."
::= { dnsServCounterEntry 6 }
Austein & Saperia [Page 14]
RFC 1611 DNS Server MIB Extensions May 1994
-- Server Optional Counter
-- The Server Optional Counter Group is intended for those
-- which make distinctions between the different sources of the
-- queries as defined below
--
-- Objects in this group are implemented on servers which
-- between queries which originate from the same host as the server
-- queries from one of an arbitrary group of hosts that are on
-- access list defined by the server, and queries from hosts that
-- not fit either of these descriptions
--
-- The objects found in the Server Counter group are totals. Thus
-- one wanted to identify, for example, the number of queries
-- `remote' hosts which have been given authoritative answers,
-- would subtract the current values of
-- and ServOptCounterSelfAuthAns from servCounterAuthAns
--
-- The purpose of these distinctions is to allow for
-- to group queries and responses on this basis. One way in
-- servers may make these distinctions is by looking at the source
-- address of the DNS query. If the source of the query is `
-- own' then the query should be counted as `yourself' (local host).
-- If the source of the query matches an `access list,' the
-- came from a friend. What constitutes an `access list'
-- implementation dependent and could be as simple as a rule that
-- hosts on the same IP network as the DNS server are
-- `friends.'
--
-- In order to avoid double counting, the following rules apply
--
-- 1. No host is in more than one of the three groups defined above
--
-- 2. All queries from the local host are always counted in
-- `yourself' group regardless of what the access list, if any
-- says
--
-- 3. The access list should not define `your friends' in such a
-- that it includes all hosts. That is, not everybody is
-- `friend.'
dnsServOptCounterSelfAuthAns OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests the server has processed
originated from a resolver on the same host for
Austein & Saperia [Page 15]
RFC 1611 DNS Server MIB Extensions May 1994
there has been an authoritative answer."
::= { dnsServOptCounter 1 }
dnsServOptCounterSelfAuthNoNames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests the server has processed
originated from a resolver on the same host for
there has been an authoritative no such name
given."
::= { dnsServOptCounter 2 }
dnsServOptCounterSelfAuthNoDataResps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests the server has processed
originated from a resolver on the same host for
there has been an authoritative no such data
(empty answer) made."
::= { dnsServOptCounter 3 }
dnsServOptCounterSelfNonAuthDatas OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests the server has processed
originated from a resolver on the same host for which
non-authoritative answer (cached data) was made."
::= { dnsServOptCounter 4 }
dnsServOptCounterSelfNonAuthNoDatas OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests the server has processed
originated from a resolver on the same host for which
`non-authoritative, no such data' response was
(empty answer)."
::= { dnsServOptCounter 5 }
dnsServOptCounterSelfReferrals OBJECT-
SYNTAX Counter32
Austein & Saperia [Page 16]
RFC 1611 DNS Server MIB Extensions May 1994
MAX-ACCESS read-
STATUS
"Number of queries the server has processed
originated from a resolver on the same host and
referred to other servers."
::= { dnsServOptCounter 6 }
dnsServOptCounterSelfErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests the server has processed
originated from a resolver on the same host which
been answered with errors (RCODEs other than 0 and 3)."
"RFC-1035 section 4.1.1."
::= { dnsServOptCounter 7 }
dnsServOptCounterSelfRelNames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests received for names that are only 1
label long (text form - no internal dots) the server
processed which originated from a resolver on the
host."
::= { dnsServOptCounter 8 }
dnsServOptCounterSelfReqRefusals OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of DNS requests refused by the server
originated from a resolver on the same host."
::= { dnsServOptCounter 9 }
dnsServOptCounterSelfReqUnparses OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests received which were unparseable
which originated from a resolver on the same host."
::= { dnsServOptCounter 10 }
Austein & Saperia [Page 17]
RFC 1611 DNS Server MIB Extensions May 1994
dnsServOptCounterSelfOtherErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests which were aborted for other (local
server errors and which originated on the same host."
::= { dnsServOptCounter 11 }
dnsServOptCounterFriendsAuthAns OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of queries originating from friends which
authoritatively answered. The definition of friends
a locally defined matter."
::= { dnsServOptCounter 12 }
dnsServOptCounterFriendsAuthNoNames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of queries originating from friends, for
authoritative `no such name' responses were made.
definition of friends is a locally defined matter."
::= { dnsServOptCounter 13 }
dnsServOptCounterFriendsAuthNoDataResps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of queries originating from friends for
authoritative no such data (empty answer) responses
made. The definition of friends is a locally
matter."
::= { dnsServOptCounter 14 }
dnsServOptCounterFriendsNonAuthDatas OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of queries originating from friends which
non-authoritatively answered (cached data).
definition of friends is a locally defined matter."
Austein & Saperia [Page 18]
RFC 1611 DNS Server MIB Extensions May 1994
::= { dnsServOptCounter 15 }
dnsServOptCounterFriendsNonAuthNoDatas OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of queries originating from friends which
non-authoritatively answered with no such data (
answer)."
::= { dnsServOptCounter 16 }
dnsServOptCounterFriendsReferrals OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests which originated from friends
were referred to other servers. The definition
friends is a locally defined matter."
::= { dnsServOptCounter 17 }
dnsServOptCounterFriendsErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests the server has processed
originated from friends and were answered with
(RCODE values other than 0 and 3). The definition
friends is a locally defined matter."
"RFC-1035 section 4.1.1."
::= { dnsServOptCounter 18 }
dnsServOptCounterFriendsRelNames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests received for names from friends
are only 1 label long (text form - no internal dots)
server has processed."
::= { dnsServOptCounter 19 }
dnsServOptCounterFriendsReqRefusals OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
Austein & Saperia [Page 19]
RFC 1611 DNS Server MIB Extensions May 1994
STATUS
"Number of DNS requests refused by the server which
received from `friends'."
::= { dnsServOptCounter 20 }
dnsServOptCounterFriendsReqUnparses OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests received which were unparseable
which originated from `friends'."
::= { dnsServOptCounter 21 }
dnsServOptCounterFriendsOtherErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Number of requests which were aborted for other (local
server errors and which originated from `friends'."
::= { dnsServOptCounter 22 }
-- Server Zone
-- DNS Management Zone Configuration
-- This table contains zone configuration information
dnsServZoneTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"Table of zones for which this name server
information. Each of the zones may be loaded from
storage via an implementation-specific mechanism or
be obtained from another name server via a zone transfer
If name server doesn't load any zones, this table
empty."
::= { dnsServZone 1 }
dnsServZoneEntry OBJECT-
SYNTAX
MAX-ACCESS not-
Austein & Saperia [Page 20]
RFC 1611 DNS Server MIB Extensions May 1994
STATUS
"An entry in the name server zone table. New rows may
added either via SNMP or by the name server itself."
INDEX { dnsServZoneName
dnsServZoneClass }
::= { dnsServZoneTable 1 }
DnsServZoneEntry ::=
SEQUENCE {
DnsNameAsIndex
DnsClass
DnsTime
DnsTime
IpAddress
RowStatus
Counter32,
TruthValue
}
dnsServZoneName OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"DNS name of the zone described by this row of the table
This is the owner name of the SOA RR that defines
top of the zone. This is name is in uppercase
characters 'a' through 'z' are mapped to 'A' through 'Z
in order to make the lexical ordering useful."
::= { dnsServZoneEntry 1 }
dnsServZoneClass OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"DNS class of the RRs in this zone."
Austein & Saperia [Page 21]
RFC 1611 DNS Server MIB Extensions May 1994
::= { dnsServZoneEntry 2 }
dnsServZoneLastReloadSuccess OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"Elapsed time in seconds since last successful reload
this zone."
::= { dnsServZoneEntry 3 }
dnsServZoneLastReloadAttempt OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"Elapsed time in seconds since last attempted reload
this zone."
::= { dnsServZoneEntry 4 }
dnsServZoneLastSourceAttempt OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"IP address of host from which most recent zone
of this zone was attempted. This value should match
value of dnsServZoneSourceSuccess if the attempt
succcessful. If zone transfer has not been
within the memory of this name server, this value
be 0.0.0.0."
::= { dnsServZoneEntry 5 }
dnsServZoneStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The status of the information represented in this row
the table."
::= { dnsServZoneEntry 6 }
dnsServZoneSerial OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"Zone serial number (from the SOA RR) of the
Austein & Saperia [Page 22]
RFC 1611 DNS Server MIB Extensions May 1994
represented by this row of the table. If the zone
not been successfully loaded within the memory of
name server, the value of this variable is zero."
::= { dnsServZoneEntry 7 }
dnsServZoneCurrent OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"Whether the server's copy of the zone represented
this row of the table is currently valid. If the
has never been successfully loaded or has expired
it was last succesfully loaded, this variable will
the value false(2), otherwise this variable will
the value true(1)."
::= { dnsServZoneEntry 8 }
dnsServZoneLastSourceSuccess OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"IP address of host which was the source of the
recent successful zone transfer for this zone.
unknown (e.g., zone has never been
transfered) or irrelevant (e.g., zone was loaded
stable storage), this value should be 0.0.0.0."
::= { dnsServZoneEntry 9 }
-- DNS Zone Source
dnsServZoneSrcTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"This table is a list of IP addresses from which
server will attempt to load zone information using
zone transfer operations. A reload may occur due to
operations that create a row in dnsServZoneTable or
SET to object dnsServZoneReload. This table is
used when the zone is loaded via zone transfer."
::= { dnsServZone 2 }
dnsServZoneSrcEntry OBJECT-
SYNTAX
MAX-ACCESS not-
Austein & Saperia [Page 23]
RFC 1611 DNS Server MIB Extensions May 1994
STATUS
"An entry in the name server zone source table."
INDEX { dnsServZoneSrcName
dnsServZoneSrcClass
dnsServZoneSrcAddr }
::= { dnsServZoneSrcTable 1 }
DnsServZoneSrcEntry ::=
SEQUENCE {
DnsNameAsIndex
DnsClass
IpAddress
}
dnsServZoneSrcName OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"DNS name of the zone to which this entry applies."
::= { dnsServZoneSrcEntry 1 }
dnsServZoneSrcClass OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"DNS class of zone to which this entry applies."
::= { dnsServZoneSrcEntry 2 }
dnsServZoneSrcAddr OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"IP address of name server host from which this
might be obtainable."
::= { dnsServZoneSrcEntry 3 }
dnsServZoneSrcStatus OBJECT-
SYNTAX
MAX-ACCESS read-
Austein & Saperia [Page 24]
RFC 1611 DNS Server MIB Extensions May 1994
STATUS
"The status of the information represented in this row
the table."
::= { dnsServZoneSrcEntry 4 }
-- SNMPv2 groups
dnsServMIBGroups OBJECT IDENTIFIER ::= { dnsServMIB 2 }
dnsServConfigGroup OBJECT-
OBJECTS { dnsServConfigImplementIdent
dnsServConfigRecurs
dnsServConfigUpTime
dnsServConfigResetTime
dnsServConfigReset }
STATUS
"A collection of objects providing basic
control of a DNS name server."
::= { dnsServMIBGroups 1 }
dnsServCounterGroup OBJECT-
OBJECTS { dnsServCounterAuthAns
dnsServCounterAuthNoNames
dnsServCounterAuthNoDataResps
dnsServCounterNonAuthDatas
dnsServCounterNonAuthNoDatas
dnsServCounterReferrals
dnsServCounterErrors
dnsServCounterRelNames
dnsServCounterReqRefusals
dnsServCounterReqUnparses
dnsServCounterOtherErrors
dnsServCounterOpCode
dnsServCounterQClass
dnsServCounterQType
dnsServCounterTransport
dnsServCounterRequests
dnsServCounterResponses }
STATUS
"A collection of objects providing basic
of a DNS name server."
::= { dnsServMIBGroups 2 }
Austein & Saperia [Page 25]
RFC 1611 DNS Server MIB Extensions May 1994
dnsServOptCounterGroup OBJECT-
OBJECTS { dnsServOptCounterSelfAuthAns
dnsServOptCounterSelfAuthNoNames
dnsServOptCounterSelfAuthNoDataResps
dnsServOptCounterSelfNonAuthDatas
dnsServOptCounterSelfNonAuthNoDatas
dnsServOptCounterSelfReferrals
dnsServOptCounterSelfErrors
dnsServOptCounterSelfRelNames
dnsServOptCounterSelfReqRefusals
dnsServOptCounterSelfReqUnparses
dnsServOptCounterSelfOtherErrors
dnsServOptCounterFriendsAuthAns
dnsServOptCounterFriendsAuthNoNames
dnsServOptCounterFriendsAuthNoDataResps
dnsServOptCounterFriendsNonAuthDatas
dnsServOptCounterFriendsNonAuthNoDatas
dnsServOptCounterFriendsReferrals
dnsServOptCounterFriendsErrors
dnsServOptCounterFriendsRelNames
dnsServOptCounterFriendsReqRefusals
dnsServOptCounterFriendsReqUnparses
dnsServOptCounterFriendsOtherErrors }
STATUS
"A collection of objects providing
instrumentation of a DNS name server."
::= { dnsServMIBGroups 3 }
dnsServZoneGroup OBJECT-
OBJECTS { dnsServZoneName
dnsServZoneClass
dnsServZoneLastReloadSuccess
dnsServZoneLastReloadAttempt
dnsServZoneLastSourceAttempt
dnsServZoneLastSourceSuccess
dnsServZoneStatus
dnsServZoneSerial
dnsServZoneCurrent
dnsServZoneSrcName
dnsServZoneSrcClass
dnsServZoneSrcAddr
dnsServZoneSrcStatus }
STATUS
"A collection of objects providing configuration
of a DNS name server which loads authoritative zones."
::= { dnsServMIBGroups 4 }
Austein & Saperia [Page 26]
RFC 1611 DNS Server MIB Extensions May 1994
-- Compliances
dnsServMIBCompliances OBJECT IDENTIFIER ::= { dnsServMIB 3 }
dnsServMIBCompliance MODULE-
STATUS
"The compliance statement for agents implementing the
name server MIB extensions."
MODULE -- This MIB
MANDATORY-GROUPS { dnsServConfigGroup, dnsServCounterGroup }
GROUP
"The server optional counter group is
optional."
GROUP
"The server zone group is mandatory for any name
that acts as an authoritative server for any DNS zone."
OBJECT
MIN-ACCESS read-
"This object need not be writable."
OBJECT
MIN-ACCESS read-
"This object need not be writable."
::= { dnsServMIBCompliances 1 }
Austein & Saperia [Page 27]
RFC 1611 DNS Server MIB Extensions May 1994
5.
This document is the result of work undertaken the by DNS
group. The authors would particularly like to thank the
people for their contributions to this document: Philip Almquist
Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave
(SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
6.
[1] Mockapetris, P., "Domain Names -- Concepts and Facilities",
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[2] Mockapetris, P., "Domain Names -- Implementation
Specification", STD 13, RFC 1035, USC/Information
Institute, November 1987.
[3] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support, STD 3, RFC 1123, USC/
Sciences Institute, October 1989.
[4] Rose, M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", STD 16,
1155, Performance Systems International, Hughes LAN Systems,
1990.
[5] McCloghrie, K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based internets", RFC 1156,
LAN Systems, Performance Systems International, May 1990.
[6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol", STD 15, RFC 1157, SNMP Research
Performance Systems International, Performance
International, MIT Laboratory for Computer Science, May 1990.
[7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
STD 16, RFC 1212, Performance Systems International, Hughes
Systems, March 1991.
[8] McCloghrie, K., and M. Rose, Editors, "Management
Base for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, Hughes LAN Systems, Performance
International, March 1991.
[9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "
of Management Information for version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie
Austein & Saperia [Page 28]
RFC 1611 DNS Server MIB Extensions May 1994
University, April 1993.
[10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "
Conventions for version 2 of the the Simple Network
Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes
Systems, Dover Beach Consulting, Inc., Carnegie
University, April 1993.
[11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser
"Conformance Statements for version 2 of the the Simple
Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie
University, April 1993.
[12] Galvin, J., and K. McCloghrie, "Administrative Model for
2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
Trusted Information Systems, Hughes LAN Systems, April 1993.
[13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "
Operations for version 2 of the Simple Network
Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes
Systems, Dover Beach Consulting, Inc., Carnegie
University, April 1993.
[14] "Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1)",
International Organization for Standardization,
Standard 8824, December 1987.
7. Security
Security issues are not discussed in this memo
Austein & Saperia [Page 29]
RFC 1611 DNS Server MIB Extensions May 1994
8. Authors'
Rob
Epilogue Technology
268 Main Street, Suite 283
North Reading, MA 01864
Phone: +1-617-245-0804
Fax: +1-617-245-8122
EMail: sra@epilogue.
Jon
Digital Equipment
110 Spit Brook
ZKO1-3/H18
Nashua, NH 03062-2698
Phone: +1-603-881-0480
Fax: +1-603-881-0120
EMail: saperia@zko.dec.
Austein & Saperia [Page 30]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
