draft DNS Server MIB July 93 DNS Server MIB Extensions 8-July-1993 DNS Working Group Rob Austein Epilogue Technology Corporation sra@epilogue.com Jon Saperia Digital Equipment Corporation saperia@tay.dec.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Please check the id-abstracts.txt listing contained in the internet-drafts Shadow Directories on the nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This document will be submitted to the Internet Architecture Board as a Proposed Standard. This document defines and experimental extension to the SNMP MIB. Upon publication as a Proposed Standard, a new MIB number will be assigned. This is a working document only, it should neither be cited nor quoted Expires January 8, 1994 [Page 1] draft DNS Server MIB July 93 in a formal document. This document will expire before 8 January 1994. Distribution of this document is unlimited. Please send comments to the authors. Expires January 8, 1994 [Page 2] draft DNS Server MIB July 93 1. Introduction This memo defines a set of extensions that have been created for the Internet MIB which instrument DNS Server Functions and was produced by the DNS working group. This memo does not specify a standard for the Internet community. With the adoption of The Simple Network Management Protocol (RFC 1157), the Management Information Base for network management of TCP/IP-based internets (RFC 1213), and the Structure of Management Information (RFC 1155) by the Internet, and 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 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 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 server software in an integrated fashion through the use of the standard Internet SMI, MIB and Simple Network Management Protocol. New DNS MIB objects have been defined to be used in conjunction with the Internet MIB to allow access and control of the DNS server software via SNMP by the Internet community. Expires January 8, 1994 [Page 3] draft DNS Server MIB July 93 2. The Network Management Framework The Internet-standard Network Management Framework consists of four components. They are: o RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. o RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1157 which defines the SNMP, 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. 2.2. Format of Definitions Section 5 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [5,6]. Expires January 8, 1994 [Page 4] draft DNS Server MIB July 93 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. 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 a separate MIB Module. 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 in this 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. 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 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. 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'. Expires January 8, 1994 [Page 5] draft DNS Server MIB July 93 (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 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. Expires January 8, 1994 [Page 6] draft DNS Server MIB July 93 4. Selected Objects Many of the objects included in this memo have been created from information contained in the DNS specification. The DNS specification is found in Domain Names - Concepts and Facilities (RFC 1034) and Domain Names - Implementation and Specification (RFC 1035), as amended and clarified by Requirements for Internet Hosts - Application and Support (RFC1123). Additional usage information is found in the Domain Administrators Guide (RFC 1032), and the Domain Administrators Operations Guide (RFC 1033). Other objects have been created based on experience with existing DNS management tools, expected operational need, and the statistics generated by existing DNS implementations. These objects have been ordered into groups as follows: Server Configuration Group Server Counter Group Server Special Counter Group Records Group Server Management Group Some of the objects defined in this memo have been created from information contained in existing configuration files used by many DNS implementations. This information has been converted into a standard form using the Internet Standard SMI defined in RFC 1155. The object descriptors used in this MIB have been created from a variety of sources. For the most part, the descriptions are influenced by by the DNS related RFCs noted above. For example, the descriptors 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 Domain Names - Implementation and Specification RFC 1035. Expires January 8, 1994 [Page 7] draft DNS Server MIB July 93 5. Textual Conventions Several data types have been introduced as a textual conventions in this DNS MIB document. 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 which are described in the Definitions section. Enumerated integers are not used for many of the textual conventions defined in this document because the DNS is defined such that additional data types can be added without the server being recoded. The use of standard integer definitions for many of these data types allows this mib to accommodate these changes as well. Expires January 8, 1994 [Page 8] draft DNS Server MIB July 93 6. Definitions RFCxxxx-dnsServMIB DEFINITIONS ::= BEGIN IMPORTS IpAddress, Counter, experimental FROM RFC1155-SMI DisplayString FROM RFC1213-MIB OBJECT-TYPE FROM RFC1212; -- DNS MIB dns OBJECT IDENTIFIER ::= { experimental 43 } dnsServ OBJECT IDENTIFIER ::= { dns 1 } -- textual conventions DnsDate ::= OCTET STRING (SIZE (8 | 11)) -- This data type is intended to provide a consistent method -- of reporting date information. The information is -- organized as follows: the first two octets represent the -- year, the next two are for the month and day of the year. -- The next three octets are for hours, minutes and seconds. -- The next octet is for deci-seconds. Direction from UT is -- in the next octet. The next two octets are for hours and -- minutes from UT. Note that in systems which do not track -- UT, they will return only the first 8 octets. The table -- below is intended to help to make clear this convention. -- -- field octets contents range -- 1 1-2 year 0..65536 -- 2 3 month 1..12 -- 3 4 day 1..31 -- 4 5 hour 0..23 -- 5 6 minutes 0..59 -- 6 7 seconds 0..60 -- (use 60 for leap-second) -- 7 8 deci-seconds 0..9 -- 8 9 direction from UT "+" / "-" -- 9 10 hours from UT 0..11 Expires January 8, 1994 [Page 9] draft DNS Server MIB July 93 -- 10 11 minutes from UT 0..59 -- For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would -- be displayed as on a management station: -- 1992-5-26,13:30:15.0,-4:0 DnsName ::= OCTET STRING -- 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. See -- section 3.1 of RFC 1034 for an explanation of the -- general-purpose internal name format. -- 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. DnsClass ::= INTEGER (0..65535) -- 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 -- specification. See section 3.2.4 of RFC 1035 for more -- detail. DnsType ::= INTEGER (0..65535) -- 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 -- specification. See section 3.2.2 of RFC 1035 for more -- detail. DnsQClass ::= INTEGER (0..65535) -- 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 Expires January 8, 1994 [Page 10] draft DNS Server MIB July 93 -- specification. See section 3.2.5 of RFC 1035 for more -- detail. DnsQType ::= INTEGER (0..65535) -- 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. See section 3.2.3 of RFC 1035 for more -- detail. DnsTime ::= INTEGER -- DnsTime values are 32-bit unsigned integers which measure -- time in seconds. See RFC 1035 for additional discussion of -- time formats. DnsValid ::= INTEGER { valid (1), clear (2) } -- Tables in the Resolver MIB have as one of their -- columns, an object which can be set to a value of 2 to -- delete that row of the table. If a read operation is -- performed on this object, a value of 1 is returned to -- indicate a valid row in the table. DnsOpCode ::= INTEGER (0..15) -- This data type is used to represent the DNS OPCODE used in -- the header section of DNS messages. Existing standard -- OPCODE values are listed in the DNS specification. See -- section 4.1.1 of RFC 1035 for more detail. DnsRespCode ::= INTEGER (0..15) -- This data type is used to represent the DNS RCODE value in -- response messages. Existing standard RCODE values are -- listed in the DNS specification. See section 4.1.1 of RFC -- 1035 for more detail. -- groups in the dns server mib dnsServConfig OBJECT IDENTIFIER ::= { dnsServ 1 } dnsServCounter OBJECT IDENTIFIER ::= { dnsServ 2 } dnsServSpecCounter OBJECT IDENTIFIER ::= { dnsServ 3 } dnsServRec OBJECT IDENTIFIER ::= { dnsServ 4 } dnsServMgmt OBJECT IDENTIFIER ::= { dnsServ 5 } -- Server Configuration Group Expires January 8, 1994 [Page 11] draft DNS Server MIB July 93 -- The implementation of the Server Configuration Group is -- mandatory for all systems which implement DNS server -- software functions. dnsServConfigImplementIdent OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "The implementation identification string for the DNS server software in use on the system, for example; FNS2.1" ::= { dnsServConfig 1 } dnsServConfigRecurs OBJECT-TYPE SYNTAX INTEGER { available (1), restricted (2), unavailable (3) } ACCESS read-write STATUS mandatory DESCRIPTION "This represents the recursion status of requests made to this server. The possible values are: available - performs recursion on requests from clients. Restricted - recursion is performed on requests only from certain clients, for example; clients on an access control list. Unavailable - recursion is not available." ::= { dnsServConfig 2 } -- Server Counter Group -- The implementation of the Server Counter Group is mandatory -- for all systems which offer either recursive or non -- recursive server software functions. dnsServCounterUTime OBJECT-TYPE SYNTAX DnsTime ACCESS read-only STATUS mandatory DESCRIPTION "If the server has a persistent state, e.g., Expires January 8, 1994 [Page 12] draft DNS Server MIB July 93 a process; this value will be the time elapsed since it started. For software that does not have persistence, this value will be 0." ::= { dnsServCounter 1 } dnsServCounterAuthAns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of queries which were authoritatively answered." ::= { dnsServCounter 2 } dnsServCounterAuthNoNames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of queries for which authoritative no such name responses were made." ::= { dnsServCounter 3 } dnsServCounterAuthNoDataResps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of queries for which authoritative no such data (empty answer) responses were made." ::= { dnsServCounter 4 } dnsServCounterNonAuthDatas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of queries which were non-authoritatively answered (cached data)." ::= { dnsServCounter 5 } dnsServCounterNonAuthNoDatas OBJECT-TYPE SYNTAX Counter ACCESS read-only Expires January 8, 1994 [Page 13] draft DNS Server MIB July 93 STATUS mandatory DESCRIPTION "Number of queries which were non-authoritatively answered with no data (empty answer)." ::= { dnsServCounter 6 } dnsServCounterRefs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of requests that were referred to other servers." ::= { dnsServCounter 7 } dnsServCounterErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of requests the server has processed that were answered with errors (RCODE values other than 0 and 3). RCODE values are defined in RFC 1035 section 4.1.1." ::= { dnsServCounter 8 } dnsServCounterRelNames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of requests received by the server for names that are only 1 label long (text form - no internal dots)." ::= { dnsServCounter 9 } dnsServCounterReqRefs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of DNS requests refused by the server process." ::= { dnsServCounter 10 } Expires January 8, 1994 [Page 14] draft DNS Server MIB July 93 dnsServCounterReqUnparses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of requests received which were unparseable." ::= { dnsServCounter 11 } dnsServCounterOtherErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of requests which were aborted for other (local) server errors." ::= { dnsServCounter 12 } -- DNS Server Counter Table dnsServCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsServCounterEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Counter information broken down by DNS class and type." ::= { dnsServCounter 13 } dnsServCounterEntry OBJECT-TYPE SYNTAX DnsServCounterEntry ACCESS not-accessible STATUS mandatory 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 A record queries over UDP 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 Expires January 8, 1994 [Page 15] draft DNS Server MIB July 93 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 Counter, dnsServCounterResponses Counter } dnsServCounterOpCode OBJECT-TYPE SYNTAX DnsOpCode -- INTEGER (0..15) ACCESS read-only STATUS mandatory DESCRIPTION "The DNS OpCode being counted in this row of the table." ::= { dnsServCounterEntry 1 } dnsServCounterQClass OBJECT-TYPE SYNTAX DnsClass -- INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The class of record being counted in this row of the table." ::= { dnsServCounterEntry 2 } dnsServCounterQType OBJECT-TYPE SYNTAX DnsType -- INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The type of record which is being counted in this row in the table." Expires January 8, 1994 [Page 16] draft DNS Server MIB July 93 ::= { dnsServCounterEntry 3 } dnsServCounterTransport OBJECT-TYPE SYNTAX INTEGER { udp (1), tcp (2), other (3) } ACCESS read-only STATUS mandatory DESCRIPTION "A value of 1 indicates that the queries reported on this row were sent using UDP. A value of 2 indicates that TCP was used. 3 is for any transport other than TCP or UDP." ::= { dnsServCounterEntry 4 } dnsServCounterRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of requests (queries) that have been recorded in this row of the table." ::= { dnsServCounterEntry 5 } dnsServCounterResponses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of responses made by the server since initialization for the kind of query identified on this row of the table." ::= { dnsServCounterEntry 6 } -- Server Special Counter Group -- The implementation of the Server Special Counter Group is -- mandatory only 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 Expires January 8, 1994 [Page 17] draft DNS Server MIB July 93 -- 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 separately -- identify, for example, the number of queries which have -- been given Authoritative Answers which originated from -- 'remote' hosts - subtract the current values of -- servSpecCounterFriendsAuthAns and -- servSpecCounterSelfAuthAns 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'. dnsServSpecCounterSelfAuthAns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory 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." ::= { dnsServSpecCounter 1 } dnsServSpecCounterSelfAuthNoNames OBJECT-TYPE Expires January 8, 1994 [Page 18] draft DNS Server MIB July 93 SYNTAX Counter ACCESS read-only STATUS mandatory 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." ::= { dnsServSpecCounter 2 } dnsServSpecCounterSelfAuthNoDataResps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory 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." ::= { dnsServSpecCounter 3 } dnsServSpecCounterSelfNonAuthDatas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory 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." ::= { dnsServSpecCounter 4 } dnsServSpecCounterSelfNonAuthNoDatas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of requests the server has processed which originated from a resolver on the same host for which a non-authoritative answer - no such data response was made (empty answer)." ::= { dnsServSpecCounter 5 } dnsServSpecCounterSelfRefs OBJECT-TYPE SYNTAX Counter Expires January 8, 1994 [Page 19] draft DNS Server MIB July 93 ACCESS read-only STATUS mandatory DESCRIPTION "Number of queries the server has processed which originated from a resolver on the same host and were referred to other servers." ::= { dnsServSpecCounter 6 } dnsServSpecCounterSelfErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of requests the server has processed which originated from a resolver on the same host which have been answered with errors (RCODE values other than 0 and 3). RCODE values are defined in RFC 1035 section 4.1.1." ::= { dnsServSpecCounter 7 } dnsServSpecCounterSelfRelNames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory 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." ::= { dnsServSpecCounter 8 } dnsServSpecCounterFriendsAuthAns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of queries originating from friends which were authoritatively answered. The definition of friends is a locally defined matter." ::= { dnsServSpecCounter 9 } dnsServSpecCounterFriendsAuthNoNames OBJECT-TYPE SYNTAX Counter ACCESS read-only Expires January 8, 1994 [Page 20] draft DNS Server MIB July 93 STATUS mandatory DESCRIPTION "Number of queries originating from friends, for which authoritative no such name (NXDOMAIN) responses were made. The definition of friends is a locally defined matter." ::= { dnsServSpecCounter 10 } dnsServSpecCounterFriendsAuthNoDataResps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory 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." ::= { dnsServSpecCounter 11 } dnsServSpecCounterFriendsNonAuthDatas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of queries originating from friends which were non-authoritatively answered (cached data). The definition of friends is a locally defined matter." ::= { dnsServSpecCounter 12 } dnsServSpecCounterFriendsNonAuthNoDatas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of queries originating from friends which were non-authoritatively answered with no such data (empty answer)." ::= { dnsServSpecCounter 13 } dnsServSpecCounterFriendsRefs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory Expires January 8, 1994 [Page 21] draft DNS Server MIB July 93 DESCRIPTION "Number of requests which originated from friends that were referred to other servers. The definition of friends is a locally defined matter." ::= { dnsServSpecCounter 14 } dnsServSpecCounterFriendsErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of requests the server has processed which originated from friends and were answered with errors (RCODE values other than 0 and 3). RCODE values are defined in RFC 1035 section 4.1.1. The definition of friends is a locally defined matter." ::= { dnsServSpecCounter 15 } dnsServSpecCounterFriendsRelNames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of requests received for names from friends that are only 1 label long (text form - no internal dots) the server has processed." ::= { dnsServSpecCounter 16 } -- Records Group -- The implementation of the Records Group is mandatory for -- all systems which implement DNS server software functions. -- Records Table -- The records table contains information on the contents of -- all the authoritative zones loaded by this server. dnsServRecTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsServRecEntry ACCESS not-accessible STATUS mandatory DESCRIPTION Expires January 8, 1994 [Page 22] draft DNS Server MIB July 93 "Information on the contents of all the authoritative zones loaded by the server." ::= { dnsServRec 1 } dnsServRecEntry OBJECT-TYPE SYNTAX DnsServRecEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Detail information on authoritative zone information and pending changes." INDEX { dnsServRecZoneName, dnsServRecZoneClass, dnsServRecName, dnsServRecType, dnsServRecIndex } ::= { dnsServRecTable 1 } DnsServRecEntry ::= SEQUENCE { dnsServRecZoneName DnsName, dnsServRecZoneClass DnsClass, dnsServRecName DnsName, dnsServRecFullName DnsName, dnsServRecType DnsType, dnsServRecTTL DnsTime, dnsServRecData OCTET STRING, dnsServRecIndex INTEGER, dnsServRecStatus INTEGER } dnsServRecZoneName OBJECT-TYPE SYNTAX DnsName -- OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "Zone name to which the Resource Record which is identified in this row of the table belongs. This is the owner name of the zone's Expires January 8, 1994 [Page 23] draft DNS Server MIB July 93 SOA RR, as described in RFC1034. This name is in uppercase, the characters 'a' through 'z' in a zone's name are translated to 'A' through 'Z' in order to make the lexical ordering useful." ::= { dnsServRecEntry 1 } dnsServRecZoneClass OBJECT-TYPE SYNTAX DnsClass -- INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "DNS class of the zone contained in this row. For classes listed in the DNS specification, the values are the same." ::= { dnsServRecEntry 2 } dnsServRecName OBJECT-TYPE SYNTAX DnsName -- OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "Name within the containing zone of the Resource Record identified by this row of the table. This is the prefix which, when combined with the name of the containing zone (dnsServRecZoneName), yields the fully specified name of this resource record. As described in RFC 1034, the owner of the record is the domain name where the RR is found. This name is also in uppercase, the characters 'a' through 'z' are translated to 'A' through 'Z' in order to make the lexical ordering useful. Note that there is a trailing zero octet after the last label in this MIB object." ::= { dnsServRecEntry 3 } dnsServRecFullName OBJECT-TYPE SYNTAX DnsName -- OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "This is the complete name of the entry identified in this row of the table as it appears in the zone. It preserves the case Expires January 8, 1994 [Page 24] draft DNS Server MIB July 93 sensitivity of the information which is stored in upper case only in the dnsServRecZoneName and dnsServRecName objects." ::= { dnsServRecEntry 4 } dnsServRecType OBJECT-TYPE SYNTAX DnsType -- INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The type of the record identified in this row of the table. For types defined in the DNS specification, the values are the same." ::= { dnsServRecEntry 5 } dnsServRecTTL OBJECT-TYPE SYNTAX DnsTime ACCESS read-only STATUS mandatory DESCRIPTION "The larger of the Time-To-Live value for this record and the Zone Minimum for the zone containing it." ::= { dnsServRecEntry 6 } dnsServRecData OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "Variable length of octets. Type and Class information provided in this row of the table along with this data tell the management station how to interpret the Record. For information on the details of DNS Resource Records and their formats, see RFC1035." ::= { dnsServRecEntry 7 } dnsServRecIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A value which makes entries in the table unique when the other index values - Expires January 8, 1994 [Page 25] draft DNS Server MIB July 93 dnsServRecZoneName, dnsServRecZoneClass, dnsServRecName, and dnsServRecType do not provide uniqueness." ::= { dnsServRecEntry 8 } dnsServRecStatus OBJECT-TYPE SYNTAX INTEGER { inUse (1), pendingDeletion (2), pendingAddition (3) } ACCESS read-write STATUS mandatory DESCRIPTION "The status of the information represented in this row of the table. IN USE - a value of 1 indicates that the information represented by this row of the table is currently in use the by server. That is, this information is the current authoritative information read in by the server at startup. PENDING DELETION - A value of 2 indicates that the information represented by this row of the table will be deleted from the authoritative zone information when the dnsServMgmtReload object is next set to a value of 2 or 3. PENDING ADDITION - A value of 3 indicates that this is new authoritative data for the zone which in not yet in use. This new information will be added to the authoritative information for the zone when the dnsServMgmtReload object is next set to a value of 2 or 3." ::= { dnsServRecEntry 9 } -- Server Management Group -- The implementation of the Server Management Group is -- mandatory for all systems which implement DNS server -- software functions. dnsServMgmtReload OBJECT-TYPE Expires January 8, 1994 [Page 26] draft DNS Server MIB July 93 SYNTAX INTEGER { restart (1), load (2), loadAndStart (3), other (4) } ACCESS read-write STATUS mandatory DESCRIPTION "When set to the values above, the following actions are taken: RESTART - The name server process is restarted and existing configuration files are read in. LOAD - Changes which have been made to information in the DNS Management Zone Configuration, DNS Management Server, and Records Tables are loaded into the permanent database of the server. After the load operation is completed, all entries in the Management Zone Configuration, Management Server, and Server Records Tables are removed which had dnsServRecStatus, dnsServMgmtServStatus or dnsServMgmtZoneStatus values of 2, or 3. LOAD AND START - Changes which have been made to information in the DNS Management Zone Configuration, DNS Management Server, and Records Tables are loaded into the permanent database of the server. After the load operation is completed, all entries in the Management Zone Configuration, Management Server, and Records Tables are removed which had dnsServRecStatus, dnsServMgmtServStatus or dnsServMgmtZoneStatus, of values of 2 or 3. After this load is completed the name server process is restarted. OTHER - is returned when a read operation is performed on this object." Expires January 8, 1994 [Page 27] draft DNS Server MIB July 93 ::= { dnsServMgmt 1 } -- DNS Management Zone Configuration Table -- This table contains zone configuration information. -- Information is changed for the server when the value of -- dnsServMgmt 1 is set to 2 or 3. dnsServMgmtZoneTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsServMgmtZoneEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table of zones for which this name server is configured. If name server doesn't load any zones, this table is empty." ::= { dnsServMgmt 2 } dnsServMgmtZoneEntry OBJECT-TYPE SYNTAX DnsServMgmtZoneEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the name server zone table." INDEX { dnsServMgmtZoneName, dnsServMgmtZoneClass } ::= { dnsServMgmtZoneTable 1 } DnsServMgmtZoneEntry ::= SEQUENCE { dnsServMgmtZoneName DnsName, dnsServMgmtZoneLoad OCTET STRING, dnsServMgmtZoneDate DnsDate, dnsServMgmtZoneClass DnsClass, dnsServMgmtZoneLastReload DnsTime, dnsServMgmtZoneLastReloadAttempt DnsTime, dnsServMgmtZoneLastSource IpAddress, dnsServMgmtZoneStatus Expires January 8, 1994 [Page 28] draft DNS Server MIB July 93 INTEGER } dnsServMgmtZoneName OBJECT-TYPE SYNTAX DnsName ACCESS read-write STATUS mandatory 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." ::= { dnsServMgmtZoneEntry 1 } dnsServMgmtZoneLoad OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION "The name of the zone file read to load the data for this zone when the zone was last loaded or updated. The NULL string indicates that the data was not loaded from a named file (e.g., because it was down-loaded from another server using the DNS protocol's zone transfer facility)." ::= { dnsServMgmtZoneEntry 2 } dnsServMgmtZoneDate OBJECT-TYPE SYNTAX DnsDate -- DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "This is the date that the information found in dnsServMgmtZoneLoad was last changed at the time the zone was last loaded. The NULL string indicates that there is no dnsServMgmtZoneLoad file." ::= { dnsServMgmtZoneEntry 3 } dnsServMgmtZoneClass OBJECT-TYPE SYNTAX DnsClass -- INTEGER (0..65535) ACCESS read-write STATUS mandatory Expires January 8, 1994 [Page 29] draft DNS Server MIB July 93 DESCRIPTION "DNS class of the RRs in this zone." ::= { dnsServMgmtZoneEntry 4 } dnsServMgmtZoneLastReload OBJECT-TYPE SYNTAX DnsTime ACCESS read-only STATUS mandatory DESCRIPTION "Elapsed seconds since last successful reload of this zone." ::= { dnsServMgmtZoneEntry 5 } dnsServMgmtZoneLastReloadAttempt OBJECT-TYPE SYNTAX DnsTime ACCESS read-only STATUS mandatory DESCRIPTION "Elapsed seconds since last attempted reload of this zone." ::= { dnsServMgmtZoneEntry 6 } dnsServMgmtZoneLastSource OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "IP address of host from which most recent reload of this zone was received. If unknown or irrelevant, value should be 0.0.0.0." ::= { dnsServMgmtZoneEntry 7 } dnsServMgmtZoneStatus OBJECT-TYPE SYNTAX INTEGER { inUse (1), pendingDeletion (2), pendingAddition (3) } ACCESS read-write STATUS mandatory DESCRIPTION "The status of the information represented in this row of the table. IN USE - a value of 1 indicates that the Expires January 8, 1994 [Page 30] draft DNS Server MIB July 93 information represented by this row of the table is currently in use the by server. That is, this information is the current zone configuration information. PENDING DELETION - A value of 2 indicates that the information represented by this row of the table will be deleted from the zone configuration file(s) when the dnsServMgmtReload object is next set to a value of 2 or 3. A side effect of this is to delete any associated resource records from the dnsServRecTable. PENDING ADDITION - A value of 3 indicates that this is new zone file configuration data which is not yet in use. This new information will be added to the zone configuration file(s) when the dnsServMgmtReload object is next set to a value of 2 or 3." ::= { dnsServMgmtZoneEntry 8 } -- DNS Management Server Table dnsServMgmtServTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsServMgmtServEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table is a list of IP addresses from which the server will attempt to load zone information using DNS zone transfer operations." ::= { dnsServMgmt 3 } dnsServMgmtServEntry OBJECT-TYPE SYNTAX DnsServMgmtServEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the name server server (sic) table." INDEX { dnsServMgmtServName, dnsServMgmtServClass, dnsServMgmtServAddr } ::= { dnsServMgmtServTable 1 } Expires January 8, 1994 [Page 31] draft DNS Server MIB July 93 DnsServMgmtServEntry ::= SEQUENCE { dnsServMgmtServName DnsName, dnsServMgmtServClass DnsClass, dnsServMgmtServAddr IpAddress, dnsServMgmtServStatus INTEGER } dnsServMgmtServName OBJECT-TYPE SYNTAX DnsName ACCESS read-only STATUS mandatory DESCRIPTION "DNS name of the zone to which this entry applies." ::= { dnsServMgmtServEntry 1 } dnsServMgmtServClass OBJECT-TYPE SYNTAX DnsClass -- INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "DNS class of zone to which this entry applies." ::= { dnsServMgmtServEntry 2 } dnsServMgmtServAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "IP address of name server host from which this zone might be obtainable." ::= { dnsServMgmtServEntry 3 } dnsServMgmtServStatus OBJECT-TYPE SYNTAX INTEGER { inUse (1), pendingDeletion (2), pendingAddition (3) } ACCESS read-write Expires January 8, 1994 [Page 32] draft DNS Server MIB July 93 STATUS mandatory DESCRIPTION "The status of the information represented in this row of the table. IN USE - a value of 1 indicates that the information represented by this row of the table is currently in use the by server. That is, this information is the current list of IP addresses from which the server attempts to load zone information using DNS zone transfer operations. PENDING DELETION - A value of 2 indicates that the information represented by this row of the table will be deleted when the dnsServMgmtReload object is next set to a value of 2 or 3. PENDING ADDITION - A value of 3 indicates that this is new information and will be added when the dnsServMgmtReload object is next set to a value of 2 or 3." ::= { dnsServMgmtServEntry 4 } END Expires January 8, 1994 [Page 33] draft DNS Server MIB July 93 7. Acknowledgements This document is the result of work undertaken the by DNS working group. In addition, the contributions and comments of the following members are also specially acknowledged: Philip Almquist, Computer Communication consultant Joe Peck, Digital Equipment Corporation Frank Kastenholz, FTP Software Win Treese, Digital Equipment Corporation Mimi Zohar, IBM Expires January 8, 1994 [Page 34] draft DNS Server MIB July 93 8. References J. Reynolds and J. Postel, Assigned Numbers. Internet Working Group Request for Comments 1010. Network Information Center, SRI International, Menlo Park, California, (May, 1987). M. Stahl, Domain Administrators Guide. Internet Working Group Request for Comments 1032. Network Information Center, SRI International, Menlo Park, California, (November, 1987). M. Lottor, Domain Administrators Operations Guide, Internet Working Group Request for Comments 1033. Network Information Center, SRI International, Menlo Park, California, (November, 1987). P. Mockapetris, Domain Names - Concepts and Facilities, Internet Working Group Request for Comments 1034. Network Information Center, SRI International, Menlo Park, California, (November, 1987). P. Mockapetris, Domain Names - Implementation and Specification, Internet Working Group Request for Comments 1035. Network Information Center, SRI International, Menlo Park, California, (November, 1987). V. Cerf, IAB Recommendations for the Development of Internet Network Management Standards. Internet Working Group Request for Comments 1052. Network Information Center, SRI International, Menlo Park, California, (April, 1988). R. Braden (editor) Requirements for Internet Hosts -- Application and Support, Internet Working Group Request for Comments 1123. Network Information Center, SRI International,Menlo Park, California, (October, 1989). M.T. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets, Internet Working Group Request for Comments 1155. Network Information Center, SRI International, Menlo Park, California, (May, 1990). K. McCloghrie and M.T. Rose, Management Information Base Expires January 8, 1994 [Page 35] draft DNS Server MIB July 93 for Network Management of TCP/IP-based internets, Internet Working Group Request for Comments 1156, Network Information Center, SRI International, Menlo Park, California, (May, 1990). J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol, Internet Working Group Request for Comments 1157. Network Information Center, SRI International, Menlo Park, California, (May, 1990). M.T. Rose, The Open Book, A Practical Perspective on OSI. Prentice Hall, Englewood Cliffs, New Jersey, (1990). M.T. Rose and K. McCloghrie (editors) Concise MIB Definitions, Internet Working Group Request for Comments 1212, Network Information Center, SRI International, Menlo Park, California, (March, 1991). K. McCloghrie and M.T. Rose (editors), Management Information Base for Network Management of TCP/IP-based internets: MIB-II, Internet Working Group Request for Comments 1213. Network Information Center, SRI International, Menlo Park, California, (March, 1991). Expires January 8, 1994 [Page 36] draft DNS Server MIB July 93 9. Security Considerations Security issues are not discussed in this memo. 10. Author's Addresses Rob Austein Epilogue Technology Corporation 268 Main Street, Suite 283 North Reading, MA 01864 USA Voice: +1 617 942 0915 Email: sra@epilogue.com Jon Saperia Digital Equipment Corporation 153 Taylor Street M/S TAY2-2/B5 Littleton, MA 01460 Voice: +1 508-952-3171 Email: saperia@tay.dec.com Expires January 8, 1994 [Page 37] draft DNS Server MIB July 93 Table of Contents 1 Introduction .......................................... 3 2 The Network Management Framework ...................... 4 2.1 Object Definitions .................................. 4 2.2 Format of Definitions ............................... 4 3 Overview .............................................. 5 4 Selected Objects ...................................... 7 5 Textual Conventions ................................... 8 6 Definitions ........................................... 9 7 Acknowledgements ...................................... 34 8 References ............................................ 35 9 Security Considerations ............................... 37 10 Author's Addresses ................................... 37 Expires January 8, 1994 [Page 38]