RFC 1611
DNS Server MIB Extensions
RFC 1611: DNS Server MIB Extensions 🎀
okay bestie, let's get into this one 💅
- RFC number: 1611
- Title: DNS Server MIB Extensions
- Authors: R. Austein (Epilogue Technology Corporation) and J. Saperia (Digital Equipment Corporation)
- Category: Standards Track
- Date: May 1994
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates ✨
Network Working Group, Request for Comments 1611, same squad as always 🦋
Status of This Memo ✨
this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 for the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). and the 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 .......................................... 28
6. References ................................................ 28
7. Security Considerations ................................... 29
8. Authors' Addresses ........................................ 301. Introduction 🌸
this memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. the main idea is a set of extensions that instrument DNS name server functions. this memo was produced by the DNS working group 🧚
so the backstory is: there's an Internet-standard Network Management Framework [4,5,6,7], and loads of vendors built it into real products. that made it possible to manage TCP/IP-based internets at a much higher level than before, and it got people thinking about managing other parts of the infrastructure too. the DNS is a key piece of that infrastructure 💖
the problem is that up to this point there was no mechanism for managing DNS with SNMP-based managers. this memo fixes that, so IP-based management stations can manage DNS name server software in an integrated way ✨
we defined DNS MIB objects to be used alongside the Internet MIB. the goal is to let the Internet community access and control DNS name server software via SNMP 👑
2. The SNMPv2 Network Management Framework 🦋
the SNMPv2 Network Management Framework has four major components:
- RFC 1442 defines the SMI, the mechanisms used for describing and naming objects for the purpose of management.
- STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols.
- RFC 1445 defines the administrative and other architectural aspects of the framework.
- RFC 1448 defines the protocol used for network access to managed objects.
the Framework also permits new objects to be defined for experimentation and evaluation 🧪
2.1. Object Definitions 🎀
managed objects are accessed via a virtual information store called 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. each object type is named by an OBJECT IDENTIFIER, which is an administratively assigned name. the object type together with an object instance uniquely identifies one specific instantiation of the object. for human convenience, we often use a textual string, called 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, and name servers answer them. the real world, however, is not so simple 💀
implementors have made widely differing choices about how to divide DNS functions between resolvers and servers. they've also built all sorts of exotic hybrids. the hardest part of defining this MIB was fitting this whole range of entities in without making a separate MIB for each one 🙈
so we split the DNS functions into two non-overlapping classes, called "resolver functions" and "name server functions." a DNS entity that performs resolver functions contains a resolver, so it must implement the MIB groups required of all resolvers, which are defined in a separate MIB Module. a DNS entity that implements name server functions is considered a name server, so it must implement the MIB groups required for name servers in this module. if the same piece of software does both resolver and server functions, we imagine it contains both a resolver and a server, and it would implement both the DNS Server and DNS Resolver MIBs 🫶
3.1. Resolvers 🔍
in our model, a resolver is a program (or piece of one) that obtains resource records from servers. usually it does this at the behest of an application, but it can also do it 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 🙅♀️
there are two flavours. a full service resolver knows how to resolve queries: it gets the needed resource records by contacting a server that's authoritative for the records it wants. a stub resolver does not know how to resolve queries. instead it sends all of its queries to a local name server, setting the "recursion desired" flag to indicate that it hopes 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 of one) that provides resource records to resolvers. every reference in this document to "a name server" implies "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 queries it could answer with authoritative information. however, if a name server gets a query it can't respond to with purely authoritative information, it may choose to try to get the necessary additional information from a resolver, which may or may not be a separate process 🤷♀️
3.3. Selected Objects 📦
a lot of the objects in this memo were created from information in the DNS specifications [1,2], as amended and clarified by later host requirements documents [3]. other objects were based on experience with existing DNS management tools, expected operational needs, the statistics generated by existing DNS implementations, and the configuration files those implementations use. these objects are ordered into the following groups:
- Server Configuration Group
- Server Counter Group
- Server Optional Counter Group
- Server Zone Group
this information was 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 DNS record queries 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 textual conventions in this DNS MIB document. these additions make it easier for everyone to share an understanding of the information the DNS uses. no changes to the SMI or the SNMP are necessary to support these conventions ✨
people who know MIBs for the lower layers of the Internet protocol suite might be surprised by how many non-enumerated integers this MIB uses to represent things like DNS RR class and type numbers. the reason is simple: the DNS itself is designed to be extensible, so new classes and types of resource records can be added without recoding the core DNS software. using non-enumerated integers here means the MIB can accommodate those changes too 🌷
4. Definitions 💅
the MIB module itself is below. the module is named DNS-SERVER-MIB, and the code is copied exactly as written 👇
DNS-SERVER-MIB DEFINITIONS ::= BEGIN
IMPORTS
mib-2
FROM RFC-1213
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
IpAddress, Counter32, Gauge32
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, DisplayString, TruthValue
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
dns OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The OID assigned to DNS MIB work by the IANA."
::= { mib-2 32 }
dnsServMIB MODULE-IDENTITY
LAST-UPDATED "9401282251Z"
ORGANIZATION "IETF DNS Working Group"
CONTACT-INFO
" Rob Austein
Postal: Epilogue Technology Corporation
268 Main Street, Suite 283
North Reading, MA 10864
US
Tel: +1 617 245 0804
Fax: +1 617 245 8122
E-Mail: sra@epilogue.com
Jon Saperia
Postal: Digital Equipment Corporation
110 Spit Brook Road
ZKO1-3/H18
Nashua, NH 03062-2698
US
Tel: +1 603 881 0480
Fax: +1 603 881 0120
Email: saperia@zko.dec.com"
DESCRIPTION
"The MIB module for entities implementing the server side
of the Domain Name System (DNS) protocol."
::= { dns 1 }
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 conventionspart 1 ends right at the textual conventions header, so part 2 picks up from there 🎀
Okay bestie, this is where the DNS data types get defined, and they're giving precise 💅✨ Each one is a textual convention, which just means a named type with its own rules for how it looks and what it holds.
DnsName is the big one 🌸 It's a sequence of labels, so Acme.COM has two labels, Acme and COM. On the wire there are no dots at all. Each label gets a length byte in front of it, and the whole name ends with a zero for the root. The example is literally { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O', 'M', 0 }, which is so clean 😭 Also, a DnsName has to be fully qualified, and encoding a relative name without making it fully qualified first is an error 🚫
DnsName ::= TEXTUAL-CONVENTION
-- A DISPLAY-HINT would be nice, but difficult to express.
STATUS current
DESCRIPTION
"A DNS name is a sequence of labels. When DNS names are
displayed, the boundaries between labels are typically
indicated by dots (e.g. `Acme' and `COM' are labels in
the name `Acme.COM'). In the DNS protocol, however, no
such separators are needed because each label is encoded
as a length octet followed by the indicated number of
octets of label. For example, `Acme.COM' is encoded as
the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O',
'M', 0 } (the final 0 is the length of the name of the
root domain, which appears implicitly at the end of any
DNS name). This MIB uses the same encoding as the DNS
protocol.
A DnsName must always be a fully qualified name. It is
an error to encode a relative domain name as a DnsName
without first making it a fully qualified name."
REFERENCE
"RFC-1034 section 3.1."
SYNTAX OCTET STRING (SIZE (0..255))
DnsNameAsIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This textual convention is like a DnsName, but is used
as an index componant in tables. Alphabetic characters
in names of this type are restricted to uppercase: the
characters 'a' through 'z' are mapped to the characters
'A' through 'Z'. This restriction is intended to make
the lexical ordering imposed by SNMP useful when applied
to DNS names.
Note that it is theoretically possible for a valid DNS
name to exceed the allowed length of an SNMP object
identifer, and thus be impossible to represent in tables
in this MIB that are indexed by DNS name. Sampling of
DNS names in current use on the Internet suggests that
this limit does not pose a serious problem in practice."
REFERENCE
"RFC-1034 section 3.1, RFC-1448 section 4.1."
SYNTAX DnsName
DnsClass ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2d"
STATUS current
DESCRIPTION
"This data type is used to represent the class values
which appear in Resource Records in the DNS. A 16-bit
unsigned integer is used to allow room for new classes
of records to be defined. Existing standard classes are
listed in the DNS specifications."
REFERENCE
"RFC-1035 section 3.2.4."
SYNTAX INTEGER (0..65535)
DnsType ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2d"
STATUS current
DESCRIPTION
"This data type is used to represent the type values
which appear in Resource Records in the DNS. A 16-bit
unsigned integer is used to allow room for new record
types to be defined. Existing standard types are listed
in the DNS specifications."
REFERENCE
"RFC-1035 section 3.2.2."
SYNTAX INTEGER (0..65535)
DnsQClass ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2d"
STATUS current
DESCRIPTION
"This data type is used to represent the QClass values
which appear in Resource Records in the DNS. A 16-bit
unsigned integer is used to allow room for new QClass
records to be defined. Existing standard QClasses are
listed in the DNS specification."
REFERENCE
"RFC-1035 section 3.2.5."
SYNTAX INTEGER (0..65535)
DnsQType ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2d"
STATUS current
DESCRIPTION
"This data type is used to represent the QType values
which appear in Resource Records in the DNS. A 16-bit
unsigned integer is used to allow room for new QType
records to be defined. Existing standard QTypes are
listed in the DNS specification."
REFERENCE
"RFC-1035 section 3.2.3."
SYNTAX INTEGER (0..65535)
DnsTime ::= TEXTUAL-CONVENTION
DISPLAY-HINT "4d"
STATUS current
DESCRIPTION
"DnsTime values are 32-bit unsigned integers which
measure time in seconds."
REFERENCE
"RFC-1035."
SYNTAX Gauge32
DnsOpCode ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This textual convention is used to represent the DNS
OPCODE values used in the header section of DNS
messages. Existing standard OPCODE values are listed in
the DNS specifications."
REFERENCE
"RFC-1035 section 4.1.1."
SYNTAX INTEGER (0..15)
DnsRespCode ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used to represent the DNS RCODE value
in DNS response messages. Existing standard RCODE
values are listed in the DNS specifications."
REFERENCE
"RFC-1035 section 4.1.1."
SYNTAX INTEGER (0..15)Next up is the server config group 🎀 This is where you find the implementation string, which is literally something like FNS-2.1 🧚 You also get recursion settings with three options (available, restricted, unavailable) 🦋, plus uptime and reset time counters. The reset object is the fun one, because setting it to reset(2) restarts the name server as if it had just started 🔥
-- Server Configuration Group
dnsServConfigImplementIdent OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The implementation identification string for the DNS
server software in use on the system, for example;
`FNS-2.1'"
::= { dnsServConfig 1 }
dnsServConfigRecurs OBJECT-TYPE
SYNTAX INTEGER { available(1),
restricted(2),
unavailable(3) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This represents the recursion services offered by this
name server. The values that can be read or written
are:
available(1) - performs recursion on requests from
clients.
restricted(2) - recursion is performed on requests only
from certain clients, for example; clients on an access
control list.
unavailable(3) - recursion is not available."
::= { dnsServConfig 2 }
dnsServConfigUpTime OBJECT-TYPE
SYNTAX DnsTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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 will
be zero."
::= { dnsServConfig 3 }
dnsServConfigResetTime OBJECT-TYPE
SYNTAX DnsTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the server 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 name server was
`reset.' For software that does not have persistence or
does not support a `reset' operation, this value will be
zero."
::= { dnsServConfig 4 }
dnsServConfigReset 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 name
server state. When set to reset(2), any persistant
name server state (such as a process) is reinitialized as
if the name server 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) - server in some unknown state;
initializing(3) - server (re)initializing;
running(4) - server currently running."
::= { dnsServConfig 5 }Now the counter group 📊 These are all Counter32 objects, and they tally up things like authoritative answers, cached answers, referrals, and errors. Errors are defined as RCODE values other than 0 and 3, so anything that isn't a clean answer or a no-such-name 💀 The relative-names counter is also a cute one, since it counts names that are only one label long 🌈
-- Server Counter Group
dnsServCounterAuthAns OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of queries which were authoritatively answered."
::= { dnsServCounter 2 }
dnsServCounterAuthNoNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of queries for which `authoritative no such name'
responses were made."
::= { dnsServCounter 3 }
dnsServCounterAuthNoDataResps OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of queries for which `authoritative no such data'
(empty answer) responses were made."
::= { dnsServCounter 4 }
dnsServCounterNonAuthDatas OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of queries which were non-authoritatively
answered (cached data)."
::= { dnsServCounter 5 }
dnsServCounterNonAuthNoDatas OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of queries which were non-authoritatively
answered with no data (empty answer)."
::= { dnsServCounter 6 }
dnsServCounterReferrals OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests that were referred to other servers."
::= { dnsServCounter 7 }
dnsServCounterErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests the server has processed that were
answered with errors (RCODE values other than 0 and 3)."
REFERENCE
"RFC-1035 section 4.1.1."
::= { dnsServCounter 8 }
dnsServCounterRelNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests received by the server for names that
are only 1 label long (text form - no internal dots)."
::= { dnsServCounter 9 }
dnsServCounterReqRefusals OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of DNS requests refused by the server."
::= { dnsServCounter 10 }
dnsServCounterReqUnparses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests received which were unparseable."
::= { dnsServCounter 11 }
dnsServCounterOtherErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests which were aborted for other (local)
server errors."
::= { dnsServCounter 12 }Last bit of this chunk is the counter table 🦋 It's indexed by DNS class and type, so the counters can be broken down that way.
-- DNS Server Counter Table
dnsServCounterTable OBJECT-TYPE
SYNTAX SEQUENCE OF DnsServCounterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Counter information broken down by DNS class and type."
::= { dnsServCounter 13 }okay so this part is basically the whole DNS server counter table 📊✨ bestie, it's giving "count everything, sort it by vibes" 💅
Each row is one combo of OPCODE, class, type, and transport, and the table only makes a row when there's actually traffic, so it doesn't balloon out of control 🦋
dnsServCounterEntry OBJECT-TYPE
SYNTAX DnsServCounterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains count information for each DNS class
and type value known to the server. The index allows
management software to to create indices to the table to
get the specific information desired, e.g., number of
queries over UDP for records with type value `A' which
came to this server. In order to prevent an
uncontrolled expansion of rows in the table; if
dnsServCounterRequests is 0 and dnsServCounterResponses
is 0, then the row does not exist and `no such' is
returned when the agent is queried for such instances."
INDEX { dnsServCounterOpCode,
dnsServCounterQClass,
dnsServCounterQType,
dnsServCounterTransport }
::= { dnsServCounterTable 1 }
DnsServCounterEntry ::=
SEQUENCE {
dnsServCounterOpCode
DnsOpCode,
dnsServCounterQClass
DnsClass,
dnsServCounterQType
DnsType,
dnsServCounterTransport
INTEGER,
dnsServCounterRequests
Counter32,
dnsServCounterResponses
Counter32
}
dnsServCounterOpCode OBJECT-TYPE
SYNTAX DnsOpCode
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The DNS OPCODE being counted in this row of the table."
::= { dnsServCounterEntry 1 }
dnsServCounterQClass OBJECT-TYPE
SYNTAX DnsClass
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The class of record being counted in this row of the
table."
::= { dnsServCounterEntry 2 }
dnsServCounterQType OBJECT-TYPE
SYNTAX DnsType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of record which is being counted in this row in
the table."
::= { dnsServCounterEntry 3 }
dnsServCounterTransport OBJECT-TYPE
SYNTAX INTEGER { udp(1), tcp(2), other(3) }
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A value of udp(1) indicates that the queries reported on
this row were sent using UDP.
A value of tcp(2) indicates that the queries reported on
this row were sent using TCP.
A value of other(3) indicates that the queries reported
on this row were sent using a transport that was neither
TCP nor UDP."
::= { dnsServCounterEntry 4 }
dnsServCounterRequests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests (queries) that have been recorded in
this row of the table."
::= { dnsServCounterEntry 5 }
dnsServCounterResponses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of responses made by the server since
initialization for the kind of query identified on this
row of the table."
::= { dnsServCounterEntry 6 }okay now the Server Optional Counter Group 🎀 this is the "who's asking?" section. it's all about splitting up queries by where they came from, so you can see whether it was the server's own host, a friend on the access list, or a total stranger 👀
the big rule is no double counting, so every host goes in exactly one group 💜
-- Server Optional Counter Group
-- The Server Optional Counter Group is intended for those systems
-- which make distinctions between the different sources of the DNS
-- queries as defined below.
--
-- Objects in this group are implemented on servers which distinguish
-- between queries which originate from the same host as the server,
-- queries from one of an arbitrary group of hosts that are on an
-- access list defined by the server, and queries from hosts that do
-- not fit either of these descriptions.
--
-- The objects found in the Server Counter group are totals. Thus if
-- one wanted to identify, for example, the number of queries from
-- `remote' hosts which have been given authoritative answers, one
-- would subtract the current values of ServOptCounterFriendsAuthAns
-- and ServOptCounterSelfAuthAns from servCounterAuthAns.
--
-- The purpose of these distinctions is to allow for implementations
-- to group queries and responses on this basis. One way in which
-- servers may make these distinctions is by looking at the source IP
-- address of the DNS query. If the source of the query is `your
-- own' then the query should be counted as `yourself' (local host).
-- If the source of the query matches an `access list,' the query
-- came from a friend. What constitutes an `access list' is
-- implementation dependent and could be as simple as a rule that all
-- hosts on the same IP network as the DNS server are classed
-- `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 the
-- `yourself' group regardless of what the access list, if any,
-- says.
--
-- 3. The access list should not define `your friends' in such a way
-- that it includes all hosts. That is, not everybody is your
-- `friend.'so the "yourself" counters come first, and they're all about queries from the same host as the server 🙈 they cover authoritative answers, no-name and no-data answers, cached answers, referrals, errors, single-label names, refusals, unparseable requests, and other local errors 🫶
dnsServOptCounterSelfAuthAns OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host for which
there has been an authoritative answer."
::= { dnsServOptCounter 1 }
dnsServOptCounterSelfAuthNoNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host for which
there has been an authoritative no such name answer
given."
::= { dnsServOptCounter 2 }
dnsServOptCounterSelfAuthNoDataResps OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host for which
there has been an authoritative no such data answer
(empty answer) made."
::= { dnsServOptCounter 3 }
dnsServOptCounterSelfNonAuthDatas OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host for which a
non-authoritative answer (cached data) was made."
::= { dnsServOptCounter 4 }
dnsServOptCounterSelfNonAuthNoDatas OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host for which a
`non-authoritative, no such data' response was made
(empty answer)."
::= { dnsServOptCounter 5 }
dnsServOptCounterSelfReferrals OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of queries the server has processed which
originated from a resolver on the same host and were
referred to other servers."
::= { dnsServOptCounter 6 }
dnsServOptCounterSelfErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests the server has processed which
originated from a resolver on the same host which have
been answered with errors (RCODEs other than 0 and 3)."
REFERENCE
"RFC-1035 section 4.1.1."
::= { dnsServOptCounter 7 }
dnsServOptCounterSelfRelNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests received for names that are only 1
label long (text form - no internal dots) the server has
processed which originated from a resolver on the same
host."
::= { dnsServOptCounter 8 }
dnsServOptCounterSelfReqRefusals OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of DNS requests refused by the server which
originated from a resolver on the same host."
::= { dnsServOptCounter 9 }
dnsServOptCounterSelfReqUnparses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests received which were unparseable and
which originated from a resolver on the same host."
::= { dnsServOptCounter 10 }
dnsServOptCounterSelfOtherErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests which were aborted for other (local)
server errors and which originated on the same host."
::= { dnsServOptCounter 11 }and last up, the friends counters 🧚 these are the queries from your access-list crew. the thing to know is that what counts as a "friend" is totally up to the local setup, and every one of these descriptions says so 💖
dnsServOptCounterFriendsAuthAns OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of queries originating from friends which were
authoritatively answered. The definition of friends is
a locally defined matter."
::= { dnsServOptCounter 12 }
dnsServOptCounterFriendsAuthNoNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of queries originating from friends, for which
authoritative `no such name' responses were made. The
definition of friends is a locally defined matter."
::= { dnsServOptCounter 13 }
dnsServOptCounterFriendsAuthNoDataResps OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of queries originating from friends for which
authoritative no such data (empty answer) responses were
made. The definition of friends is a locally defined
matter."
::= { dnsServOptCounter 14 }
dnsServOptCounterFriendsNonAuthDatas OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of queries originating from friends which were
non-authoritatively answered (cached data). The
definition of friends is a locally defined matter."
::= { dnsServOptCounter 15 }
dnsServOptCounterFriendsNonAuthNoDatas OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of queries originating from friends which were
non-authoritatively answered with no such data (empty
answer)."
::= { dnsServOptCounter 16 }Okay bestie, this is where the friends counters come in 👯♀️ They track requests from "friends," and the RFC says what counts as a friend is a locally defined matter 🫶
dnsServOptCounterFriendsReferrals OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests which originated from friends that
were referred to other servers. The definition of
friends is a locally defined matter."
::= { dnsServOptCounter 17 }
dnsServOptCounterFriendsErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests the server has processed which
originated from friends and were answered with errors
(RCODE values other than 0 and 3). The definition of
friends is a locally defined matter."
REFERENCE
"RFC-1035 section 4.1.1."
::= { dnsServOptCounter 18 }
dnsServOptCounterFriendsRelNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests received for names from friends that
are only 1 label long (text form - no internal dots) the
server has processed."
::= { dnsServOptCounter 19 }
dnsServOptCounterFriendsReqRefusals OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of DNS requests refused by the server which were
received from `friends'."
::= { dnsServOptCounter 20 }
dnsServOptCounterFriendsReqUnparses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests received which were unparseable and
which originated from `friends'."
::= { dnsServOptCounter 21 }
dnsServOptCounterFriendsOtherErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of requests which were aborted for other (local)
server errors and which originated from `friends'."
::= { dnsServOptCounter 22 }Next up is the Server Zone Group 🌸 This part is all about zone configuration, so it's basically the server's little address book of zones it's responsible for 📒
-- Server Zone Group
-- DNS Management Zone Configuration Table
-- This table contains zone configuration information.
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 }
dnsServZoneEntry OBJECT-TYPE
SYNTAX DnsServZoneEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the name server zone table. New rows may be
added either via SNMP or by the name server itself."
INDEX { dnsServZoneName,
dnsServZoneClass }
::= { dnsServZoneTable 1 }
DnsServZoneEntry ::=
SEQUENCE {
dnsServZoneName
DnsNameAsIndex,
dnsServZoneClass
DnsClass,
dnsServZoneLastReloadSuccess
DnsTime,
dnsServZoneLastReloadAttempt
DnsTime,
dnsServZoneLastSourceAttempt
IpAddress,
dnsServZoneStatus
RowStatus,
dnsServZoneSerial
Counter32,
dnsServZoneCurrent
TruthValue,
dnsServZoneLastSourceSuccess
IpAddress
}
dnsServZoneName OBJECT-TYPE
SYNTAX DnsNameAsIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"DNS name of the zone described by this row of the table.
This is the owner name of the SOA RR that defines the
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-TYPE
SYNTAX DnsClass
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"DNS class of the RRs in this zone."
::= { dnsServZoneEntry 2 }
dnsServZoneLastReloadSuccess OBJECT-TYPE
SYNTAX DnsTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Elapsed time in seconds since last successful reload of
this zone."
::= { dnsServZoneEntry 3 }
dnsServZoneLastReloadAttempt OBJECT-TYPE
SYNTAX DnsTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Elapsed time in seconds since last attempted reload of
this zone."
::= { dnsServZoneEntry 4 }
dnsServZoneLastSourceAttempt OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"IP address of host from which most recent zone transfer
of this zone was attempted. This value should match the
value of dnsServZoneSourceSuccess if the attempt was
succcessful. If zone transfer has not been attempted
within the memory of this name server, this value should
be 0.0.0.0."
::= { dnsServZoneEntry 5 }
dnsServZoneStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of the information represented in this row of
the table."
::= { dnsServZoneEntry 6 }
dnsServZoneSerial OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Zone serial number (from the SOA RR) of the zone
represented by this row of the table. If the zone has
not been successfully loaded within the memory of this
name server, the value of this variable is zero."
::= { dnsServZoneEntry 7 }
dnsServZoneCurrent OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Whether the server's copy of the zone represented by
this row of the table is currently valid. If the zone
has never been successfully loaded or has expired since
it was last succesfully loaded, this variable will have
the value false(2), otherwise this variable will have
the value true(1)."
::= { dnsServZoneEntry 8 }
dnsServZoneLastSourceSuccess OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"IP address of host which was the source of the most
recent successful zone transfer for this zone. If
unknown (e.g., zone has never been successfully
transfered) or irrelevant (e.g., zone was loaded from
stable storage), this value should be 0.0.0.0."
::= { dnsServZoneEntry 9 }Now for the DNS Zone Source Table 🦋 This one is a list of IP addresses the server can pull zone info from using zone transfers ✨
-- DNS Zone Source Table
dnsServZoneSrcTable OBJECT-TYPE
SYNTAX SEQUENCE OF DnsServZoneSrcEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is a list of IP addresses from which the
server will attempt to load zone information using DNS
zone transfer operations. A reload may occur due to SNMP
operations that create a row in dnsServZoneTable or a
SET to object dnsServZoneReload. This table is only
used when the zone is loaded via zone transfer."
::= { dnsServZone 2 }
dnsServZoneSrcEntry OBJECT-TYPE
SYNTAX DnsServZoneSrcEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the name server zone source table."
INDEX { dnsServZoneSrcName,
dnsServZoneSrcClass,
dnsServZoneSrcAddr }
::= { dnsServZoneSrcTable 1 }
DnsServZoneSrcEntry ::=
SEQUENCE {
dnsServZoneSrcName
DnsNameAsIndex,
dnsServZoneSrcClass
DnsClass,
dnsServZoneSrcAddr
IpAddress,
dnsServZoneSrcStatus
RowStatus
}
dnsServZoneSrcName OBJECT-TYPE
SYNTAX DnsNameAsIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"DNS name of the zone to which this entry applies."
::= { dnsServZoneSrcEntry 1 }
dnsServZoneSrcClass OBJECT-TYPE
SYNTAX DnsClass
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"DNS class of zone to which this entry applies."
::= { dnsServZoneSrcEntry 2 }
dnsServZoneSrcAddr OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"IP address of name server host from which this zone
might be obtainable."
::= { dnsServZoneSrcEntry 3 }
dnsServZoneSrcStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of the information represented in this row of
the table."
::= { dnsServZoneSrcEntry 4 }And last but not least, the SNMPv2 groups 💜 These bundle the objects we've already met into named collections, so you can grab the whole config set or the whole counter set in one go 🍓
-- SNMPv2 groups.
dnsServMIBGroups OBJECT IDENTIFIER ::= { dnsServMIB 2 }
dnsServConfigGroup OBJECT-GROUP
OBJECTS { dnsServConfigImplementIdent,
dnsServConfigRecurs,
dnsServConfigUpTime,
dnsServConfigResetTime,
dnsServConfigReset }
STATUS current
DESCRIPTION
"A collection of objects providing basic configuration
control of a DNS name server."
::= { dnsServMIBGroups 1 }
dnsServCounterGroup OBJECT-GROUP
OBJECTS { dnsServCounterAuthAns,
dnsServCounterAuthNoNames,
dnsServCounterAuthNoDataResps,
dnsServCounterNonAuthDatas,
dnsServCounterNonAuthNoDatas,
dnsServCounterReferrals,
dnsServCounterErrors,
dnsServCounterRelNames,
dnsServCounterReqRefusals,
dnsServCounterReqUnparses,
dnsServCounterOtherErrors,
dnsServCounterOpCode,
dnsServCounterQClass,
dnsServCounterQType,
dnsServCounterTransport,
dnsServCounterRequests,
dnsServCounterResponses }
STATUS current
DESCRIPTION
"A collection of objects providing basic instrumentation
of a DNS name server."
::= { dnsServMIBGroups 2 }5. Acknowledgements 💖
This document is the result of work undertaken the by DNS working group. The authors would particularly like to thank the following people for their contributions to this document: Philip Almquist, Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM). Iconic squad 🫶✨
6. References 📚
[1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
[2] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
[3] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support, STD 3, RFC 1123, USC/Information Sciences Institute, October 1989.
[4] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.
[5] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990.
[6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems 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 LAN Systems, March 1991.
[8] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991.
[9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.
[10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.
[11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.
[12] Galvin, J., and K. McCloghrie, "Administrative Model for version 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, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.
[14] "Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.
7. Security Considerations 🔒
Security issues are not discussed in this memo. Yes, bestie, that's the whole entry 💀 Keep it in mind when you're deploying this stuff 🙈
8. Authors' Addresses 💌
Rob Austein
Epilogue Technology Corporation
268 Main Street, Suite 283
North Reading, MA 01864
USA
Phone: +1-617-245-0804
Fax: +1-617-245-8122
EMail: sra@epilogue.com
Jon Saperia
Digital Equipment Corporation
110 Spit Brook Road
ZKO1-3/H18
Nashua, NH 03062-2698
USA
Phone: +1-603-881-0480
Fax: +1-603-881-0120
EMail: saperia@zko.dec.com📦 where this page comes from
- ietf: rfc1611 1994-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms