AW: [Pdns-dev] ldapdns schema compatibility for LDAP backend [PATCH]

norbert at norbert at
Thu Dec 25 22:41:47 CET 2003

Hi Piotr

I've thought about your patch and the compatibility to ldapdns the whole
night and day, but my conclusions may not be satisfying to you in all

> ldapdns server utilises a little bit
> different LDAP schema. This is pure COSINE schema, so there is no need
> to modify LDAP server and extends the default schema.

The pdns ldap backend uses the dnsdomain object in the cosine schema too,
but doesn't redifine things so it is incompatible to anything else.

If you don't need PTR records that are different from the corresponding A
records, simple set ldap-disable-ptrrecord=yes. If you do or if you need
additional record types, include the dnsdomain2 schema from the bind ldap
developer in slapd.conf. That's all. There's no need to modify something
inside a schema.

> There is no associatedDomain field and the entry is searched based on
> its DN. I.e. should be:

The cleaner way would be to write a little to that adds the
assocateddomain attriute to the dns object.

> dn: dc=www,dc=example,dc=net,ou=DNS,
> objectClass: top
> objectClass: dnsDomain
> dc: www
> aRecord:
> and the simple query is "objectClass=*" with base scope on basedn
> "dc=www,dc=example,dc=net,ou=DNS,".

That isn't that dumb and I want to include this feature in the pdns ldap
backend. Thank you for the code.

> Another difference is usage of cNAMERecord field to store PTR record in
> revDNS.

You have to admit that this is really brain dead.
I don't want to implement something that violates RFCs so much.

If you've used ldapdns in the past and now want to switch to pdns, I want
to help you as much as possible by helping to implement conversion tools
to even out the small but obstructive differences. But to fully mimic the
ldapdns behaviour is not what I want.

I hope, you understand my decisions.


More information about the Pdns-dev mailing list