According to RFC2252, section 4.4 (https://www.ietf.org/rfc/rfc2252.txt):
```
4.4. Object Classes

   The format for representation of object classes is defined in X.501
   [3]. In general every entry will contain an abstract class ("top" or
   "alias"), at least one structural object class, and zero or more
   auxiliary object classes.
```
Since the dnsZone, dnsLocation and dnsRRset objectClasses are designed to permit the creation of directory entries, they must either be STRUCTURAL or else be AUXILIARY to another STRUCTURAL objectClass.  The latter doesn't make practical sense, so the former must be so.

This is fairly well described in "LDAP for Rocket Scientists" (http://www.zytrax.com/books/ldap/ch3/#overview):
 * objectClasses group sets of attributes:
  *    objectclasses are defined inside schemas.
  *    objectclasses may be organised in a hierarchy in which case they inherit all the properties of their parents or SUPerior.
   *  objectclasses may be STRUCTURAL, in which case they are used to create entries (data objects), AUXILIARY in which case they may be added into any convenient entry, or ABSTRACT - a non-existent 'thingie'. The most common ABSTRACT objectclass is top, which forms the highest level of every objectclass hierarchy, and terminates any hierarchy.

Also, in your original schema, you had declared the dnsRRset objectClass inferior to dnsZone, like so:
```
objectclass ( 1.3.6.1.4.1.7222.1.4.20
  NAME 'dnsrrset'
  SUP dnszone
  MUST ( objectclass $ cn )
  MAY ( dnsdomainname $ dnsrr $ dnsclass $ dnstype $ dnsipaddr
    $ dnscipaddr $ dnscname $ dnspreference $ dnsttl $ dnstimestamp
    $ owner $ dnssrvpriority $ dnssrvweight $ dnssrvport ) )
```
The "SUP dnszone" declaration means that this objectClass would inherit all attributes of the SUPerior objectClass, including NIChandle and the like.  This cannot be what was intended.