# How to use dnsZone with the BIND 9 sdb back-end

## Record types

The dnsZone class does not contain attributes for all known record types. The following types are missing: MF, MB, MG, MR, NULL, WKS, RP, AFSDB, X25, ISDN, RT, NSAP, NSAP-PTR, PX and GPOS. Anything defined after this document was written is obviously missing. If you want to add some record types that are defined by IANA, please define it similar to what I've done for the existing ones. The name should be {TYPE}Record, and OID should be 1.3.6.1.4.1.2428.20.1.value. For instance the RR type LOC has value 29, so attribute name should be LocRecord (casing shouldn't matter), and the OID is 1.3.6.1.4.1.2428.20.1.29. If you follow this, you know that it will be compatible with what I and others use, and I guarantee that the OIDs are unique.

The dnsZone class has attributes for some basic record types like A, SOA, etc. which are defined in the cosine schema and not in this schema. This means that your LDAP server must use both the cosine schema and this one. If you're not you should get an error from your LDAP server.

## Example 1

Let's look at the following simple zone file.

    @       3600    IN      SOA     ns.my-domain.com. hostmaster.my-domain.com. (
    		                2001030201 3600 1800 604800 86400 )
    		        NS      ns.my-domain.com.
    		        NS      ns.other-domain.com.
    		        MX      10 mail.my-domain.com.
    		        MX      20 mail.other-domain.com.

    my-hosta                A       10.10.10.10
                            MX	10 mail.my-domain.com.
    		        MX      20 mail.other-domain.com.
    www	 1800	 	CNAME	my-hosta.my-domain.com.
    my-hostb 3600           A       10.10.10.11
                            MX	10 mail.my-domain.com.
    		        MX      20 mail.other-domain.com.

This can be represented by the following LDIF file:

    dn: relativeDomainName=@, dc=my-domain, dc=com
    objectClass: dNSZone
    relativeDomainName: @
    zoneName: my-domain.com
    dNSTTL: 3600
    dNSClass: IN
    sOARecord: ns.my-domain.com. hostmaster.my-domain.com. 2001030201 3600 1800 604800 86400
    nSRecord: ns.my-domain.com.
    nSRecord: ns.other-domain.com.
    mXRecord: 10 mail.my-domain.com.
    mXRecord: 20 mail.other-domain.com.

    dn: relativeDomainName=my-hosta, dc=my-domain, dc=com
    objectClass: dNSZone
    relativeDomainName: my-hosta
    zoneName: my-domain.com
    dNSTTL: 86400
    dNSClass: IN
    aRecord: 10.10.10.10
    mXRecord: 10 mail.my-domain.com.
    mXRecord: 20 mail.other-domain.com.

    dn: relativeDomainName=www, dc=my-domain, dc=com
    objectClass: dNSZone
    relativeDomainName: www
    zoneName: my-domain.com
    dNSTTL: 1800
    dNSClass: IN
    cNAMERecord: my-hosta.my-domain.com.

    dn: relativeDomainName=my-hostb, dc=my-domain, dc=com
    objectClass: dNSZone
    relativeDomainName: my-hostb
    zoneName: my-domain.com
    dNSTTL: 3600
    dNSClass: IN
    aRecord: 10.10.10.11

    dn: relativeDomainName=my-hostb + dNSTTL=86400, dc=my-domain, dc=com
    objectClass: dNSZone
    relativeDomainName: my-hostb
    zoneName: my-domain.com
    dNSTTL: 86400
    dNSClass: IN
    mXRecord: 10 mail.my-domain.com.
    mXRecord: 20 mail.other-domain.com.

zoneName is the name of the zone, i.e. the name of the node in the zone that is highest up in the DNS tree. relativeDomainName is the name of the nodes relative to this, just like relative names in zone files dNSClass is not used by the sdb back-end, so you can leave it out if you like. The dNSTTL can also be left out, it will then default to the TTL specified in named.conf.

If you want RRs with the same name to have different TTLs (like my-hostb in the example), you will have to store it as multiple entries all including relativeDomainName=my-hostb. You will need at least as many entries as there are different TTLs. The main difficulty is to make sure that they all have unique DNs. The way I've chosen is to have a multi-valued RDN including dNSTTL, and put all RRs with the same TTL together. This is a bit ugly, but I think this is better than having one entry per RR. Let me know if you have other ideas.

When storing multiple zones you must make sure of course that the dn's are unique. This can easily be done by including the zoneName attribute in the DN. This can be done in several ways, one example would be relativeDomainName=www, zoneName=my-zone, dc=my-domain, dc=com.

## Example 2

The schema is quite flexible as I'll try to show in the next two examples. If you have say the same MX records for the three hosts hosta, hostb and hostc, you might have one entry for each host and have the same mXRecord values in all the entries, or you can have one common entry with the mXRecords like this:

    dn: relativeDomainName=hosta, dc=my-domain, dc=com
    objectClass: dNSZone
    relativeDomainName: hosta
    relativeDomainName: hostb
    relativeDomainName: hostc
    zoneName: my-domain.com
    mXRecord: 10 mail.my-domain.com.
    mXRecord: 20 mail.other-domain.com.

## Example 3

Assume that we have one web server with one IP address that is a virtual web server for hundreds of domains. Rather than having hundreds of similar entries, one for each zone, you might do as follows:

    dn: relativeDomainName=www, dc=my-domain, dc=com
    objectClass: dNSZone
    relativeDomainName: www
    zoneName: customerdomain1.com
    zoneName: customerdomain2.com
    ...
    zoneName: customerdomain999.com
    aRecord: 10.10.10.10
    mXRecord: 10 mail.my-domain.com.
    mXRecord: 20 mail.other-domain.com.

If you have a bunch of zones that are identical, except for the zone name, you might combine all their entries like above. Sort of like using the same zone file for multiple zones.

## Example 4

Let's have a look at PTR records for reverse lookups for IPv4 addresses. Say you want to have a reverse for the address 1.2.3.4. You then need a PTR record for 4.3.2.1.in-addr.arpa. Using normal zone files you would typically have a file for the zone 3.2.1.in-addr.arpa and inside that put say

    4 PTR my-hostc.my-domain.com.

Using this back-end, you change named.conf like above, and use an LDAP entry like this:

    dn: relativeDomainName=4, zoneName=3.2.1.in-addr.arpa, dc=my-domain, dc=com
    objectClass: dNSZone
    relativeDomainName: 4
    zoneName: 3.2.1.in-addr.arpa
    pTRRecord: my-hostc.my-domain.com.

Note that the DN can be whatever you like. If you use a DN like the above, you can use zoneName=3.2.1.in-addr.arpa, dc=my-domain, dc=com as the search base in the URL in named.conf.

## Example 5

As a final example, you might try to search below ldap://ldap.venaas.no/dc=venaas,dc=com,o=DNS,dc=venaas,dc=no. There you will find the zone data for venaas.com. You can also browse my directory data using web2ldap. The master server for venaas.com uses this server. The slave uses normal zone transfers.

## Summary

As should be evident from the examples, you have great flexibility when using this schema with the BIND9 back-end. The tree structure, the dn's, doesn't matter at all, the back-end simply does a sub-tree search using the base specified in named.conf for all entries in the wanted zone with the wanted name. For example when someone tries to look up the node my-hosta.my-domain.com it simply does a sub-tree search at the base given in named.conf with the filter (&(zoneName=my-domain.com)(relativeDomainName=my-hosta)). If someone looks up my-domain.com it uses the filter (&(zoneName=my-domain.com)(relativeDomainName=@)), and finally if someone wants to get the entire zone, for example a secondary using AXFR, it uses the filter (zoneName=my-domain.com). Wildcards are not supported.

Last modified: 2002-02-03