dumped the debug output to a file to get the LDAP searches performed
on a Debian Edu main-server. Here is a summary.
-powerdns
-========
+<p><strong>powerdns</strong></p>
-http://www.linuxnetworks.de/doc/index.php/PowerDNS_LDAP_Backend
+<a href="http://www.linuxnetworks.de/doc/index.php/PowerDNS_LDAP_Backend">Clues
+on how to</a> set up PowerDNS to use a LDAP backend is available on
+the web.
-<p>PowerDNs have two modes of operation using LDAP as its backend.
+<p>PowerDNS have two modes of operation using LDAP as its backend.
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>
-<p>In Debian Edu/Lenny, the powerdns tree mode is used, and this is
+<p>In Debian Edu/Lenny, the PowerDNS tree mode is used, and this is
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>
srvrecord, naptrrecord and modifytimestamp. For reverse entires it
also do a subtree scoped search bug this time the filter is
"(arecord=10.0.2.2)" and request the attributes associateddomain,
-dnsttl and modifytimestamp.</p>
+dnsttl and modifytimestamp. In short, in strict mode the objects with
+ptrrecord go away, and the arecord attribute in the forward object is
+used instead.</p>
<p>The forward and reverse searches can be simulated using ldapsearch
like this:</p>
search for SOA records, which behave similar to the forward and
reverse lookups.</p>
-<p>Things to note with the powerdns behaviour is that it do not
+<p>Things to note with the PowerDNS behaviour is that it do not
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>
-<p>My proposal would be to switch powerdns to strict mode and not use
+<p>My proposal would be to switch PowerDNS to strict mode and not use
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
</pre></blockquote>
<p>This will allow any object to become a DNS entry when combined with
-the domainrelatedobject object class to get all the attributes
-powerdns wants. I am not sure the 'SUP top' part is needed.</p>
+the domainrelatedobject object class, and allow any object to get all
+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>
-ISC dhcp
-========
+<p><strong>ISC dhcp</strong></p>
The DHCP server searches for specific objectclass and requests all the
object attributes, and then uses the attributes it want. This make it
"(&(objectClass=dhcpService)(|(dhcpPrimaryDN=cn=dhcp,dc=skole,dc=skolelinux,dc=no)(dhcpSecondaryDN=cn=dhcp,dc=skole,dc=skolelinux,dc=no)))".
The search result is this entry:
+<blockquote><pre>
dn: cn=DHCP Config,dc=skole,dc=skolelinux,dc=no
cn: DHCP Config
objectClass: top
dhcpOption: smtp-server code 69 = array of ip-address
dhcpOption: www-server code 72 = array of ip-address
dhcpOption: wpad-url code 252 = text
+</pre></blockquote>
Next, the entire subtree is searched for, one level at the time. When
all the DHCP configuration is loaded, it is ready to receive requests.
the client (00:00:00:00:00:00 in this example), using a subtree scoped
search with "cn=DHCP Config,dc=skole,dc=skolelinux,dc=no" as the base
and "(&(objectClass=dhcpHost)(dhcpHWAddress=ethernet
-00:00:00:00:00:00))" as the filter.
+00:00:00:00:00:00))" as the filter. This is what a host object look
+like:
+
+<blockquote><pre>
+dn: cn=hostname,cn=group1,cn=THINCLIENTS,cn=DHCP Config,dc=skole,dc=skolelinux,dc=no
+cn: hostname
+objectClass: top
+objectClass: dhcpHost
+dhcpHWAddress: ethernet 00:00:00:00:00:00
+dhcpStatements: fixed-address hostname
+</pre></blockquote>
-Conclusion
-==========
+<p><strong>Conclusion</strong></p>
-The PowerDNS implementation seem to be very flexible when it come to
-which LDAP schemas to use. Its "tree" mode is rigid when it come to
-the the LDAP structure, while its "strict" mode is very flexible,
+<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
+come to the the LDAP structure, the "strict" mode is very flexible,
allowing DNS objects to be stored anywhere under the base cn specified
-in the configuration.
+in the configuration.</p>
-The DHCP implementation on the other hand is very inflexible, both
+<p>The DHCP implementation on the other hand is very inflexible, both
regarding which LDAP schemas to use and which LDAP structure to use.
I guess one could implement ones own schema, as long as the
objectclasses and attributes have the names used, but this do not
really help when the DHCP subtree need to have a fairly fixed
-structure.
+structure.</p>
SRCH "dc=skole,dc=skolelinux,dc=no" 2 0 0 0 0
filter: (&(objectClass=dhcpServer)(cn=dhcp))
projects / homepage.git / blobdiff