+<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
+based on the DNS names, as in www.skolelinux.org and
+137.191.36.158.in-addr.arpa.</p>
+
+<p>In tree mode, the server is set up to use a LDAP subtree as its
+base, and a "base" scoped search for the DNS name by adding
+"dc=www,dc=skolelinux,dc=org," to the base with a filter for
+"(associateddomain=www.skolelinux.org)" for the forward entry and
+"dc=137,dc=191,dc=36,dc=158,dc=in-addr,dc=arpa," with a filter for
+"(associateddomain=137.191.36.158.in-addr.arpa)" for the reverse
+entry. For forward entries, it is looking for attributes named
+dnsttl, arecord, nsrecord, cnamerecord, soarecord, ptrrecord,
+hinforecord, mxrecord, txtrecord, rprecord, afsdbrecord, keyrecord,
+aaaarecord, locrecord, srvrecord, naptrrecord, kxrecord, certrecord,
+dsrecord, sshfprecord, ipseckeyrecord, rrsigrecord, nsecrecord,
+dnskeyrecord, dhcidrecord, spfrecord and modifytimestamp. For reverse
+entries it is looking for the attributes, dnsttl, arecord, nsrecord,
+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
+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>
+
+<blockquote><pre>
+dn: dc=tjener,dc=intern,ou=hosts,dc=skole,dc=skolelinux,dc=no
+objectclass: top
+objectclass: dnsdomain
+objectclass: domainrelatedobject
+dc: tjener
+arecord: 10.0.2.2
+associateddomain: tjener.intern
+
+dn: dc=2,dc=2,dc=0,dc=10,dc=in-addr,dc=arpa,ou=hosts,dc=skole,dc=skolelinux,dc=no
+objectclass: top
+objectclass: dnsdomain2
+objectclass: domainrelatedobject
+dc: 2
+ptrrecord: tjener.intern
+associateddomain: 2.2.0.10.in-addr.arpa
+</pre></blockquote>
+
+<p>In strict mode, the server behaves differently. When looking for
+forward DNS entries, it is doing a "subtree" scoped search with the
+same base as in the tree mode for a object with filter
+"(associateddomain=www.skolelinux.org)" and requests the attributes
+dnsttl, arecord, nsrecord, cnamerecord, soarecord, ptrrecord,
+hinforecord, mxrecord, txtrecord, rprecord, aaaarecord, locrecord,
+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>
+
+<p>The forward and reverse searches can be simulated using ldapsearch
+like this:</p>
+
+<blockquote><pre>
+ldapsearch -h ldap -b dc=skole,dc=skolelinux,dc=no -s sub -x \
+ '(associateddomain=tjener.intern)' dNSTTL aRecord nSRecord \
+ cNAMERecord sOARecord pTRRecord hInfoRecord mXRecord tXTRecord \
+ rPRecord aFSDBRecord KeyRecord aAAARecord lOCRecord sRVRecord \
+ nAPTRRecord kXRecord certRecord dSRecord sSHFPRecord iPSecKeyRecord \
+ rRSIGRecord nSECRecord dNSKeyRecord dHCIDRecord sPFRecord modifyTimestamp
+
+ldapsearch -h ldap -b dc=skole,dc=skolelinux,dc=no -s sub -x \
+ '(arecord=10.0.2.2)' associateddomain dnsttl modifytimestamp
+</pre></blockquote>
+
+<p>In addition to the forward and reverse searches , there is also a
+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
+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>
+
+<p>The attributes are normally provided in the cosine (RFC 1274) and
+dnsdomain2 schemas (for reverse entries like ptrrecord and recent DNS
+additions like aaaarecord and srvrecord).</p>
+
+<p>In Debian Edu, we have created DNS objects using the object classes
+dcobject (for dc), dnsdomain or dnsdomain2 (structural, for the DNS
+attributes) and domainrelatedobject (for associatedDomain). The use
+of structural object classes make it impossible to combine these
+classes with the object classes used by DHCP.</p>
+
+<p>There are other schemas that could be used too, for example the
+dnszone structural object class used by Gosa and bind-sdb for the DNS
+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
+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
+(using the attributes defined for dnsdomain and dnsdomain2 or
+dnszone):</p>
+
+<blockquote><pre>
+objectclass ( some-oid NAME 'dnsDomainAux'
+ SUP top
+ AUXILIARY
+ MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ SOARecord $ CNAMERecord $
+ DNSTTL $ DNSClass $ PTRRecord $ HINFORecord $ MINFORecord $
+ TXTRecord $ SIGRecord $ KEYRecord $ AAAARecord $ LOCRecord $
+ NXTRecord $ SRVRecord $ NAPTRRecord $ KXRecord $ CERTRecord $
+ A6Record $ DNAMERecord
+ ))
+</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>
+
+ISC dhcp
+========
+
+The DHCP server searches for specific objectclass and requests all the
+object attributes, and then uses the attributes it want. This make it
+harder to figure out exactly what attributes are used, but thanks to
+the working example in Debian Edu I can at least get an idea what is
+needed.
+
+scope 0 = base
+scope 1 = onelevel
+scope 2 = subtree
+
+In the DHCP server configuration, the LDAP base to use as the search
+filter to use to locate the correct dhcpServer entity is stored.
+These are the relevant entries:
+
+<blockquote><pre>
+ldap-base-dn "dc=skole,dc=skolelinux,dc=no";
+ldap-dhcp-server-cn "dhcp";
+</pre></blockquote>
+
+The DHCP server uses this information to nest all the DHCP
+configuration needed. The cn "dhcp" is searched for using the given
+LDAP base and the filter "(&(objectClass=dhcpServer)(cn=dhcp))". The
+search result is this entry:
+
+<blockquote><pre>
+dn: cn=dhcp,dc=skole,dc=skolelinux,dc=no
+cn: dhcp
+objectClass: top
+objectClass: dhcpServer
+dhcpServiceDN: cn=DHCP Config,dc=skole,dc=skolelinux,dc=no
+</pre></blockquote>
+
+The content of the dhcpServiceDN attribute is used to locate the
+subtree with DHCP configuration. The DHCP configuration subtree base
+is located using a base scope search with base "cn=DHCP
+Config,dc=skole,dc=skolelinux,dc=no" and filter
+"(&(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:
+
+dn: cn=DHCP Config,dc=skole,dc=skolelinux,dc=no
+cn: DHCP Config
+objectClass: top
+objectClass: dhcpService
+objectClass: dhcpOptions
+dhcpPrimaryDN: cn=dhcp, dc=skole,dc=skolelinux,dc=no
+dhcpStatements: ddns-update-style none
+dhcpStatements: authoritative
+dhcpOption: smtp-server code 69 = array of ip-address
+dhcpOption: www-server code 72 = array of ip-address
+dhcpOption: wpad-url code 252 = text
+
+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 subtree in Debian Edu contain objects with object classes
+top/dhcpService/dhcpOptions, top/dhcpSharedNetwork/dhcpOptions,
+top/dhcpSubnet, top/dhcpGroup and top/dhcpHost. These provide options
+and information about netmasks, dynamic range etc. Leaving out the
+details here because it is not relevant for the focus of my
+investigation, which is to see if it is possible to merge dns and dhcp
+related computer objects.
+
+When a DHCP request come in, LDAP is searched for the MAC address of
+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.
+
projects / homepage.git / commitdiff