sdb-ldap and in-addr.arpa.

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: 70-431 braindump 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 000-730 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 117-201 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. venaas@uninett.no Last modified: 2002-02-03

The chief argument in favour of the network model, in comparison to the hierarchic model, was that it allowed a more natural modeling of relationships between entities. Although the model was widely implemented and used, it failed to become dominant for two main reasons.When I was in college for 70-536 exam preparation I often participated in different workshops.Firstly, IBM chose to stick to the hierarchical model with semi-network extensions in their established products such as IMS and DL/I. Secondly, it was eventually displaced by the relational model, which offered a higher-level,70-640 more declarative interface. Until the early 1980s the performance benefits of the low-level navigational interfaces offered by hierarchical and network databases were persuasive for many large-scale applications, but as hardware became faster, E20-520 .the extra productivity and flexibility of the relational model led to the gradual obsolescence of the network model in corporate enterprise usage.

Can you post your named configuration and zone file information? It sounds like you are not configured to use yourself as master for these zones.