dumped the debug output to a file to get the LDAP searches performed
on a Debian Edu main-server. Here is a summary.
dumped the debug output to a file to get the LDAP searches performed
on a Debian Edu main-server. Here is a summary.
One "strict" mode where the forward and reverse DNS lookups are done
using the same LDAP objects, and a "tree" mode where the forward and
reverse entries are in two different subtrees in LDAP with a structure
One "strict" mode where the forward and reverse DNS lookups are done
using the same LDAP objects, and a "tree" mode where the forward and
reverse entries are in two different subtrees in LDAP with a structure
rprecord, aaaarecord, locrecord, srvrecord, naptrrecord and
modifytimestamp.</p>
rprecord, aaaarecord, locrecord, srvrecord, naptrrecord and
modifytimestamp.</p>
two example LDAP objects used there. In addition to these objects,
the parent objects all th way up to
ou=hosts,dc=skole,dc=skolelinux,dc=no also exist.</p>
two example LDAP objects used there. In addition to these objects,
the parent objects all th way up to
ou=hosts,dc=skole,dc=skolelinux,dc=no also exist.</p>
specify any objectclass names, and instead look for the attributes it
need to generate a DNS reply. This make it able to work with any
objectclass that provide the needed attributes.</p>
specify any objectclass names, and instead look for the attributes it
need to generate a DNS reply. This make it able to work with any
objectclass that provide the needed attributes.</p>
this case some unused attributes would have to be included as well
(zonename and relativedomainname).</p>
this case some unused attributes would have to be included as well
(zonename and relativedomainname).</p>
any of the existing objectclasses (dnsdomain, dnsdomain2 and dnszone)
when one want to combine the DNS information with DHCP information,
and instead use a auxiliary object class defined something like this
any of the existing objectclasses (dnsdomain, dnsdomain2 and dnszone)
when one want to combine the DNS information with DHCP information,
and instead use a auxiliary object class defined something like this
<p>This will allow any object to become a DNS entry when combined with
the domainrelatedobject object class, and allow any object to get all
<p>This will allow any object to become a DNS entry when combined with
the domainrelatedobject object class, and allow any object to get all
-the attributes powerdns wants.</p>
+the attributes PowerDNS wants. I've sent an email to the PowerDNS
+developers asking for their view on this schema and if they are
+interested in providing it with poewrdns.</p>
The DHCP server searches for specific objectclass and requests all the
object attributes, and then uses the attributes it want. This make it
The DHCP server searches for specific objectclass and requests all the
object attributes, and then uses the attributes it want. This make it
<p>The PowerDNS implementation seem to be very flexible when it come
to which LDAP schemas to use. While its "tree" mode is rigid when it
<p>The PowerDNS implementation seem to be very flexible when it come
to which LDAP schemas to use. While its "tree" mode is rigid when it