More text.

diff --git a/blog/draft/2010-07-03-ldap-searches.txt b/blog/draft/2010-07-03-ldap-searches.txt
index dabf8e32c793f659cd1c5a10b311782f6c580eaa..aa43381c919ae768cce7db373d1455597721e72c 100644 (file)
--- a/blog/draft/2010-07-03-ldap-searches.txt
+++ b/blog/draft/2010-07-03-ldap-searches.txt
@@ -12,12 +12,13 @@ To get this information, I started slapd with debugging enabled and
 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
@@ -41,7 +42,7 @@ cnamerecord, soarecord, ptrrecord, hinforecord, mxrecord, txtrecord,
 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>
@@ -96,7 +97,7 @@ ldapsearch -h ldap -b dc=skole,dc=skolelinux,dc=no -s sub -x \
 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>
@@ -117,7 +118,7 @@ attributes combined with the domainrelatedobject object class, but in
 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
@@ -138,10 +139,11 @@ objectclass ( some-oid NAME 'dnsDomainAux'
 
 <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>
 
-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
@@ -222,8 +224,7 @@ dhcpHWAddress: ethernet 00:00:00:00:00:00
 dhcpStatements: fixed-address hostname
 </pre></blockquote>
 
-Conclusion
-==========
+<p><strong>Conclusion</strong></p>
 
 <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