ldapdns-devel Mailing List for LDAPDNS
Brought to you by:
nimh
Menu
▾
▴
ldapdns-devel — Discuss patches problems and prereleases
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(20) |
Jun
(12) |
Jul
|
Aug
(10) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(3) |
Dec
(5) |
| 2005 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bob H. <he...@ya...> - 2009-07-26 23:04:14
|
I'd like to know the current status of this project and find out how I could help get it to a production or near production level. I'd probably just use the so-called "stable" version 2.0.? IF it would compile on Gentoo and/or the source code didn't scare me so much. I don't really want to integrate BIND with openldap although it seems many people have successfully done it.
Thanks,
Bob
|
|
From: Leen B. <le...@wi...> - 2007-08-10 20:03:56
|
On Wed, Aug 08, 2007 at 12:26:53PM +0200, Henti Smith wrote: > The last CVS commit was in 2004. would it be safe to assume this project is > dead ? > > If so, recommendations for a similar project to integrate DNS with LDAP ? > Well there is (was?) bind-dlz, but commits/releases are just as often: http://sourceforge.net/project/showfiles.php?group_id=41794 Then we have ldap2dns which has last been updated October last year, so not to bad: http://projects.alkaloid.net/e107_plugins/content/content.php?content.5 But I'm guessing you want to query LDAP directly ? So AFAIK your only other option is PowerDNS: http://wiki.powerdns.com/cgi-bin/trac.fcgi With the LDAP-backend which is included in PowerDNS: http://www.linuxnetworks.de/doc/index.php/PowerDNS_LDAP_Backend > Thanks > -- > Henti Smith > Systems Administrator > Impi Linux (Pty) Ltd > 1st Floor, Wembley Building, The Campus > 57 Sloane Street, Bryanston, Sandton > Tel: +27 11 575 4948 > Fax: +27 11 463 9211 > -- > Disclaimer : http://www.impilinux.co.za/Email_Disclaimer > -- > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Ldapdns-devel mailing list > Lda...@li... > https://lists.sourceforge.net/lists/listinfo/ldapdns-devel > _____________________________________ New things are always on the horizon. |
|
From: Henti S. <he...@im...> - 2007-08-08 10:27:24
|
The last CVS commit was in 2004. would it be safe to assume this project is dead ? If so, recommendations for a similar project to integrate DNS with LDAP ? Thanks -- Henti Smith Systems Administrator Impi Linux (Pty) Ltd 1st Floor, Wembley Building, The Campus 57 Sloane Street, Bryanston, Sandton Tel: +27 11 575 4948 Fax: +27 11 463 9211 -- Disclaimer : http://www.impilinux.co.za/Email_Disclaimer -- |
|
From: Mrs. B. <mrs...@ni...> - 2005-11-27 17:28:25
|
On Tue, 2005-11-15 at 22:39 +0000, Carl Perry wrote: > Sending this to the list, since I haven't seen a reply in a little over two weeks... > > On Mon, 2005-10-31 at 23:03 -0500, Mrs. Brisby wrote: > > Have you tried binding with plain, non-sasl authentication? > > Normally I bind using simple auth anyway, but it seems that anonymous > doesn't work either. I've posted two ethereal captures that may help: > anonymous bind - http://edolnx.net/misc/ldapdns3/anon-bind-failure.cap > simple bind - http://edolnx.net/misc/ldapdns3/simple-bind-failure.cap > Each one of the captures are about 2MB, and contains only the LDAP > traffic generated by ldapdns3-dg during startup. It gets quite pissed > when it cannot bind :) That it does :) Your OpenLDAP server doesn't appear to be allowing v2 binds. Those are necessary for a simple bind to work from ldapdns- it doesn't use the OpenLDAP client libs. > > What LDAP server are you attempting to communicate with? > > The OpenLDAP server that ships with Debian Sarge (2.2.23) over loopback. > I've also placed in http://edolnx.net/misc/ldapdns3/ the annoymous and > simple ldaphost files that I used. The "run" command from the service > (I have ldapdns3 running inside daemontools) and the env directory are > also included. > > If there is anything else I can do to help, please don't hesitate to > ask! ldapdns2 is failing to respond to queries under moderate loads > until restarted, and I'd like to start tesing ldapdns3 to see if the > same problems occur or if it solves the problem. Thanks! I'll be honest- I haven't had time to touch ldapdns3 in a very long time. It works fairly well, but I've been waiting for either interest from the outside or failure on the inside to get back into it, and neither has happened yet :-/ I'm still using ldapdns1 in production on our high-load systems, and ldapdns2 on our internal network. |
|
From: Carl P. <ca...@ed...> - 2005-11-15 22:39:42
|
Sending this to the list, since I haven't seen a reply in a little over two= weeks... On Mon, 2005-10-31 at 23:03 -0500, Mrs. Brisby wrote: > Have you tried binding with plain, non-sasl authentication? Normally I bind using simple auth anyway, but it seems that anonymous doesn't work either. I've posted two ethereal captures that may help: anonymous bind - http://edolnx.net/misc/ldapdns3/anon-bind-failure.cap simple bind - http://edolnx.net/misc/ldapdns3/simple-bind-failure.cap Each one of the captures are about 2MB, and contains only the LDAP traffic generated by ldapdns3-dg during startup. It gets quite pissed when it cannot bind :) > What LDAP server are you attempting to communicate with? The OpenLDAP server that ships with Debian Sarge (2.2.23) over loopback. I've also placed in http://edolnx.net/misc/ldapdns3/ the annoymous and simple ldaphost files that I used. The "run" command from the service (I have ldapdns3 running inside daemontools) and the env directory are also included. If there is anything else I can do to help, please don't hesitate to ask! ldapdns2 is failing to respond to queries under moderate loads until restarted, and I'd like to start tesing ldapdns3 to see if the same problems occur or if it solves the problem. Thanks! P.S. - I know I have auth information included in said config files, and I don't see it as a problem. That dn for the LDAP servers is read only, and is not Internet accessable. --=20 -Carl Perry (KD5TSA) <ca...@ed...> "A PC without Windows is like Chocolate cake without the mustard" |
|
From: Mrs. B. <mrs...@ni...> - 2005-11-01 04:10:21
|
Have you tried binding with plain, non-sasl authentication? (Anonymous should work, btw) What LDAP server are you attempting to communicate with? On Tue, 2005-10-25 at 16:20 +0000, Carl Perry wrote: > I've been trying to get ldapdns3 working on a Debian 3.1 (Sarge) install > to no avail. It compiles fine, but when run fails to answer any > queries. Using ethereal to look at the network traffic, every time it > tries to bind to the LDAP server, a "ProtocolError" message is sent back > and the bind fails. I've even tried binding anonymously with no luck. > What information can I provide to help debug this? |
|
From: Carl P. <ca...@ed...> - 2005-10-25 16:20:44
|
I've been trying to get ldapdns3 working on a Debian 3.1 (Sarge) install
to no avail. It compiles fine, but when run fails to answer any
queries. Using ethereal to look at the network traffic, every time it
tries to bind to the LDAP server, a "ProtocolError" message is sent back
and the bind fails. I've even tried binding anonymously with no luck.
What information can I provide to help debug this?
--=20
-Carl Perry (KD5TSA) <ca...@ed...>
"A PC without Windows is like Chocolate cake without the mustard"
|
|
From: Mrs. B. <mrs...@ni...> - 2005-03-27 02:41:41
|
On Sat, 2005-03-26 at 14:20 -0400, Alejandro Mery wrote: > Hi, i have a test (attached), but if i set LDAP_SUFFIX to empty, or > remove the env var, it stop working. > > i need to work with an empty base because i have to serve multiple > namingContexts. No, you don't. You do need LDAP_SUFFIX set to an empty string, but you also need SCHEMA set to "ldapdns" and you need an "associatedDomain" attribute on every object with an nSRecord that names itself, that is: dn: dc=test,dc=org,ou=dns,ou=service,dc=localhost,dc=localnet objectClass: top objectClass: dNSDomain objectClass: dcObject dc: test cNAMERecord: test.org mXRecord: 127.0.0.1 nSRecord: ns1.test.org sOARecord: 1 3600 900 36000000 3600 should additionally have: associatedDomain: test.org You'll want that attribute indexed as well. FWIW: mXRecords aren't allowed to be IP addresses, and this CNAME is absolutely worthless unless you like confusing BIND4 resolvers. You don't need that sOARecord unless you've got an ns2.test.org. that doesn't run LDAPDNS. |
|
From: Mrs. B. <mrs...@ni...> - 2005-03-26 01:50:36
|
On Wed, 2005-03-23 at 16:14 +0100, Tobia Conforto wrote: > Steps to reproduce: host "<malformed.com" 127.0.0.1 > > Result: ldapdns[14995]: ldap_result (zonesearch): Invalid DN syntax > ldapdns[15133]: starting ldapdns 2.05 (1:1/128) > (Note: this problem is not related to 1:1 mode or absence thereof.) This is interesting. IIRC, OpenLDAP didn't used to be this picky. The fog of age means I probably don't recall correctly... > Solution: make ldapdns reject DNS queries for domains which include any > character not in the [a-zA-Z0-9.-] range. ... > I only have a vague understanding of the the DNS protocol and of ldapdns > internals. If my patch goes against any RFC or other protocol > specification, please consider working on an appropriate solution. > Anyways this is a real problem that plagued my ldapdns server until I > patched it with this solution, so it is not something to overlook. You can't serve SRV records. DNS names are _binary_ names. I wish they weren't C-locale case insensitive. That just causes problems. Oh well. A "better" solution would be to escape additional characters in ldapdns.c ~line 36: static void inline ldap_escape(str_t retbuf, char *s) { while (*s) { if (*s == ',') { /* <- add your list here */ str_addch(retbuf, '\\'); } str_addch(retbuf, *s); s++; } } I am not recent on LDAP specs these days- I don't recall "[" or "]" (or any character besides ",") being illegal in a DN. LDAPDNS3 is PROBABLY immune to this problem because it doesn't use the OpenLDAP client libraries- and I regularly do queries with \[ and \] in them using other LDAP clients, so I don't think OpenLDAP itself has a problem with those characters. Perhaps every sequence except [^a-zA-Z0-9._-] should be escaped? Can anyone verify that this doesn't cause any more problems than it solves? It might do to cross-reference the OpenLDAP code and see what characters it considers "illegal"... |
|
From: Tobia C. <tob...@li...> - 2005-03-23 15:15:18
|
Dear ldapdns author, (CC to Debian Maintainer and to ldapdns 3 development mailing list) I have encountered a few problems while trying to set up and use ldapdns 2.05, not the least of them having to do with the messy and incomplete documentation! Nonetheless I thank you much for your work, because I think yours is all-around the best ldap-to-dns solution available today. I managed to solve one of the (non-documentation related) problems I found. Here is an explanation and a patch, which the Debian maintainer and the ldapdns 3 development team might be interested in discussing or applying on their own. I'm still working on other problems and I will notify you if/when I come to any valuable conclusion or piece of code. Description: malformed DNS requests get accepted by ldapdns and become malformed LDAP queries. The ldap server answers with an appropriate but uncommon error, which makes ldapdns panic and restart itself. Steps to reproduce: host "<malformed.com" 127.0.0.1 Result: ldapdns[14995]: ldap_result (zonesearch): Invalid DN syntax ldapdns[15133]: starting ldapdns 2.05 (1:1/128) (Note: this problem is not related to 1:1 mode or absence thereof.) Solution: make ldapdns reject DNS queries for domains which include any character not in the [a-zA-Z0-9.-] range. Patch: attached below. I only have a vague understanding of the the DNS protocol and of ldapdns internals. If my patch goes against any RFC or other protocol specification, please consider working on an appropriate solution. Anyways this is a real problem that plagued my ldapdns server until I patched it with this solution, so it is not something to overlook. Best regards Tobia Conforto -- Love(n): The delusion that one woman differs from another. H.L. Mencken --- ldapdns-2.06.orig/engine.c 2005-03-22 20:50:24.000000000 +0100 +++ ldapdns-2.06/engine.c 2005-03-22 20:48:37.000000000 +0100 @@ -695,6 +695,16 @@ /* q is valid: safe */ dns_to_name(sa, q, 0); + /* check that the query string does not contain funny characters */ + for (r = 0; str(sa)[r]; r++) { + if (((str(sa)[r] | 32) < 'a' || (str(sa)[r] | 32) > 'z') + && (str(sa)[r] < '0' || str(sa)[r] > '9') + && str(sa)[r] != '-' && str(sa)[r] != '.') { + /* invalid query: return an error BEFORE asking ldap */ + complete_phase(c, '/'); + return; + } + } if (ldapdns.dn_mode == DN_MODE_LDAPDNS) { str_init(sb); str_copy(sb, "(|(associatedDomain="); |
|
From: Simon M. <sim...@in...> - 2004-12-31 16:04:17
|
> That sounds like a GCC bug. > > On line 23 of ldapdns.c (it simply says HIT:) change it to: > > HIT:lp=lp; > > That should keep GCC happy. If that works, I'll restructure something > better for 2.07 Thanks, that fixed it. Simon > > > On Fri, 2004-12-31 at 13:48 +0100, Simon Matter wrote: >> Hi, >> >> I'm still maintaining ldapdns rpms but they have now moved to: >> http://www.invoca.ch/pub/packages/ldapdns/ >> >> Unfortunately the build doesn't work on Fedora Core 2 and 3 with the >> following errors: >> >> ./configure >> Configuring LDAPDNS >> Testing C compiler: gcc-pthread (cc) >> Checking for syslog support: ok >> Checking for memzero: bzero >> Checking for memcpy: ok >> Checking for IPV6 support: ok >> Checking for setsid() support: ok >> Checking for poll() support: ok >> Checking for waitpid() support: ok >> Checking for POSIX threads: ok >> Checking for non-portable pthreads extensions: >> pthread_kill_other_threads_np >> Checking OpenLDAP dependencies: ok >> Checking for OpenLDAP < 2.1.8: no >> Writing Makefile.config: done >> >> make -f Makefile.defs >> make[1]: Entering directory `/usr/src/redhat/BUILD/ldapdns-2.06' >> cc -I/usr/local/include -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 >> -pthread -DHAVE_SYSLOG -DHAVE_BZERO -DHAVE_MEMCPY -DHAVE_IPV6 >> -DHAVE_SETSID -DHAVE_POLL -DHAVE_WAITPID >> -DHAVE_pthread_kill_other_threads_np -o udpserver.o -c udpserver.c >> In file included from list.h:6, >> from config.h:12, >> from udpserver.c:1: >> error.h:26: warning: conflicting types for built-in function 'log' >> cc -I/usr/local/include -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 >> -pthread -DHAVE_SYSLOG -DHAVE_BZERO -DHAVE_MEMCPY -DHAVE_IPV6 >> -DHAVE_SETSID -DHAVE_POLL -DHAVE_WAITPID >> -DHAVE_pthread_kill_other_threads_np -o engine.o -c engine.c >> In file included from engine.c:1: >> error.h:26: warning: conflicting types for built-in function 'log' >> cc -I/usr/local/include -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 >> -pthread -DHAVE_SYSLOG -DHAVE_BZERO -DHAVE_MEMCPY -DHAVE_IPV6 >> -DHAVE_SETSID -DHAVE_POLL -DHAVE_WAITPID >> -DHAVE_pthread_kill_other_threads_np -o ldapdns.o -c ldapdns.c >> In file included from list.h:6, >> from ldapdns.h:13, >> from ldapdns.c:2: >> error.h:26: warning: conflicting types for built-in function 'log' >> ldapdns.c: In function `ldapdns_list_unique': >> ldapdns.c:24: error: label at end of compound statement >> make[1]: *** [ldapdns.o] Error 1 >> make[1]: Leaving directory `/usr/src/redhat/BUILD/ldapdns-2.06' >> make: *** [default] Error 2 >> error: Bad exit status from /var/tmp/rpm-tmp.15583 (%build) >> >> Regards and Happy new Year! >> Simon >> > > > |
|
From: Mrs. B. <mrs...@ni...> - 2004-12-31 14:44:28
|
That sounds like a GCC bug. On line 23 of ldapdns.c (it simply says HIT:) change it to: HIT:lp=lp; That should keep GCC happy. If that works, I'll restructure something better for 2.07 On Fri, 2004-12-31 at 13:48 +0100, Simon Matter wrote: > Hi, > > I'm still maintaining ldapdns rpms but they have now moved to: > http://www.invoca.ch/pub/packages/ldapdns/ > > Unfortunately the build doesn't work on Fedora Core 2 and 3 with the > following errors: > > ./configure > Configuring LDAPDNS > Testing C compiler: gcc-pthread (cc) > Checking for syslog support: ok > Checking for memzero: bzero > Checking for memcpy: ok > Checking for IPV6 support: ok > Checking for setsid() support: ok > Checking for poll() support: ok > Checking for waitpid() support: ok > Checking for POSIX threads: ok > Checking for non-portable pthreads extensions: pthread_kill_other_threads_np > Checking OpenLDAP dependencies: ok > Checking for OpenLDAP < 2.1.8: no > Writing Makefile.config: done > > make -f Makefile.defs > make[1]: Entering directory `/usr/src/redhat/BUILD/ldapdns-2.06' > cc -I/usr/local/include -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 > -pthread -DHAVE_SYSLOG -DHAVE_BZERO -DHAVE_MEMCPY -DHAVE_IPV6 > -DHAVE_SETSID -DHAVE_POLL -DHAVE_WAITPID > -DHAVE_pthread_kill_other_threads_np -o udpserver.o -c udpserver.c > In file included from list.h:6, > from config.h:12, > from udpserver.c:1: > error.h:26: warning: conflicting types for built-in function 'log' > cc -I/usr/local/include -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 > -pthread -DHAVE_SYSLOG -DHAVE_BZERO -DHAVE_MEMCPY -DHAVE_IPV6 > -DHAVE_SETSID -DHAVE_POLL -DHAVE_WAITPID > -DHAVE_pthread_kill_other_threads_np -o engine.o -c engine.c > In file included from engine.c:1: > error.h:26: warning: conflicting types for built-in function 'log' > cc -I/usr/local/include -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 > -pthread -DHAVE_SYSLOG -DHAVE_BZERO -DHAVE_MEMCPY -DHAVE_IPV6 > -DHAVE_SETSID -DHAVE_POLL -DHAVE_WAITPID > -DHAVE_pthread_kill_other_threads_np -o ldapdns.o -c ldapdns.c > In file included from list.h:6, > from ldapdns.h:13, > from ldapdns.c:2: > error.h:26: warning: conflicting types for built-in function 'log' > ldapdns.c: In function `ldapdns_list_unique': > ldapdns.c:24: error: label at end of compound statement > make[1]: *** [ldapdns.o] Error 1 > make[1]: Leaving directory `/usr/src/redhat/BUILD/ldapdns-2.06' > make: *** [default] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.15583 (%build) > > Regards and Happy new Year! > Simon > |
|
From: Mrs. B. <mrs...@ni...> - 2004-12-31 03:54:54
|
2.06 minor bugfixes to simple-search mode (thanks =?gb2312?B?
uai/qurN?=)
Oliver Tschaeche points out we're missing some SOA answers.
Steven McCoy added support for LDAP URLs.
Chris Garrigues points out LDAPDNS couldn't make DomainKeys.
This behavior has changed finally.
minor bugfix to hash algorithm. i knew there was a reason I was
getting so many collisions.
|
|
From: Mrs. B. <mrs...@ni...> - 2004-12-04 01:38:29
|
On Tue, 2004-11-30 at 14:29 +0000, mf...@ti... wrote: > I know this is the wrong place, but the ldapdns 2.00 mailing lists have > been dead so long. This is fine. > How do you add glue to a referral in ldapdns 2.05? The docs say having > only an nsRecord causes a referal, but I can't figure out where to add the > glue record? Sorry if my DNS terminalogy is off... You have to add the glue record normally, and will claim authority (with an nSRecord as well) for a parent domain (just like any other nameserver). |
|
From: Mrs. B. <mrs...@ni...> - 2004-12-04 01:38:26
|
On Sun, 2004-11-21 at 18:56 +0200, The Ranger wrote: > However now I've spent last couple of hours trying to figure out how to > make the zone transfers work in v3 of LDAPDNS. Unfortunately I have not > managed to find a solution. > > As far as I understand it is required to run the ldapdns-vc script via > some sort of virtual circuit software. Could anyone give me some hints > how to do it (e.g. using inetd although it is not recommended)? The term virtual circuit is ubiquitous; over Internet, it refers to a TCP connection. > Does it have to be run directly or using the shell script as a wrapper > like the main LDAPDNS daemon requires? listenvc can be used. tcpserver offers better controls. > Is the AXFR variable needed? it's set up by listenvc or tcpserver and specifies which part of dns- space is accessible via AXFR. If it's unset, listenvc+ldapdns-vc is simply a dns-over-tcp server. > It was clear that if I want to do AXFR I have to create the soaRecord > attribute for that domain. Are there any other things that must be done > in order to make it work? That's not necessary if you only want to OFFER axfr (such as some TLD's require). If you want to negotiate AXFR for keeping data in sync, you will need to specify sOARecord formally. |
|
From: <mf...@ti...> - 2004-11-30 15:01:57
|
I know this is the wrong place, but the ldapdns 2.00 mailing lists have been dead so long. How do you add glue to a referral in ldapdns 2.05? The docs say having only an nsRecord causes a referal, but I can't figure out where to add the glue record? Sorry if my DNS terminalogy is off... Thanks Mark |
|
From: Chris J. <ch...@ma...> - 2004-11-21 19:31:36
|
On Sun, Nov 21, 2004 at 06:56:18PM +0200, The Ranger wrote: > First of all I have to say that this software is exaclty what I was > looking for a long time! I like the idea not having to -HUP my BIND > every time I change anything and maintaining the whole DNS information > in one location is much better solution than having it laying around all > over the system. I, too, ran into similar issues trying to get AXFR running and after much bug hunting (and fixing, but sorry threw it all away in disgust eventually) finally gave up and went to PowerDNS (www.powerdns.com) which has an LDAP backend (in addition to SQL backends) and have been extremely happy ever since. --=20 chris kb7rnl =3D-> |
|
From: The R. <ra...@ri...> - 2004-11-21 17:09:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, First of all I have to say that this software is exaclty what I was looking for a long time! I like the idea not having to -HUP my BIND every time I change anything and maintaining the whole DNS information in one location is much better solution than having it laying around all over the system. However now I've spent last couple of hours trying to figure out how to make the zone transfers work in v3 of LDAPDNS. Unfortunately I have not managed to find a solution. As far as I understand it is required to run the ldapdns-vc script via some sort of virtual circuit software. Could anyone give me some hints how to do it (e.g. using inetd although it is not recommended)? Does it have to be run directly or using the shell script as a wrapper like the main LDAPDNS daemon requires? Is the AXFR variable needed? It was clear that if I want to do AXFR I have to create the soaRecord attribute for that domain. Are there any other things that must be done in order to make it work? - -- rgrds, Ranger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBoMiyrmN2TpmH6PoRAvqnAKDdgDbDtKe6aUWo90JrjpgNgThFEgCdGfMw qRf7Xht7hgGnwqhN8wMpszM= =MixO -----END PGP SIGNATURE----- |
|
From: Mrs. B. <mrs...@ni...> - 2004-10-19 01:44:21
|
Automatic PTR generation is something that "comes up" periodically. Simply put; nobody has come up with a reasonable way to do it. Generally, when LDAPDNS 3 is ready, we'll see some attributes marked as "primary" and to hell with the consequences (see the archives to understand this) [[ I really got to do a checkin soon ]] On Sun, 2004-10-17 at 21:10 +0200, Florian Friesdorf wrote: > Hi *, > > as the webpage is rather outdated and I got no mails from the lists > since I subscribed a couple of days ago, > is there any development happening around ldapdns? > > I want to implement automtic generation of PTR records and could use > some help in finding the right place for it. > > thx > flo > |
|
From: Florian F. <42...@gm...> - 2004-10-17 19:11:42
|
Hi *,
as the webpage is rather outdated and I got no mails from the lists
since I subscribed a couple of days ago,
is there any development happening around ldapdns?
I want to implement automtic generation of PTR records and could use
some help in finding the right place for it.
thx
flo
--=20
Florian Friesdorf <42...@gm...>
OpenPGP key available on public key servers
|
|
From: Mrs. B. <mrs...@ni...> - 2004-03-12 04:20:18
|
On Thu, 2004-03-11 at 21:25, Troy Benjegerdes wrote: > What are your thoughts on adding support for the dNSZone schema at: > http://garibaldi.venaas.no/ldap/bind-sdb/ > http://garibaldi.venaas.no/ldap/bind-sdb/dnszone-schema.txt > > I could probably hack up the code if given an idea where to start > looking.. There was some code to do this at various points in LDAPDNS's history. It shouldn't be difficult to add it to LDAPDNS 3- look in attrsearch.c axfrsearch.c and zonesearch.c to see where to begin processing the result-set (make sure you examine your SCHEMA variable (ldapdns.schema == SCHEMA_BINDSDB?)) and add a function in ldapsearch.c that represents the search-command-building function (if you want to write out arguments to the OpenLDAP ldapsearch command, I'll help you put this together) Just remember: LDAPDNS 3 is shooting to be character-set agnostic, so use octal-escape sequences in ascii.h if you need new words. > In addition, I've also been looking at the powerdns ldap-backend, and it > has the capability to automatically generate 'PTR' records based on the > forward lookup records. This is nice, but it's only available as a > global configuration option. > > Is there a sane way to generate PTR records > off a regular ldapdns or other forward lookup entry? (I would prefer > adding an entry to the dNSZone schema) > > You'd obviously want to look through the regular 'in-addr.arpa' space > first, but if you don't get a hit there, and the foward lookup for that > IP has the right attribute, you return a corresponding reverse lookup. There's been some discussion about this in the past. The question is how can LDAPDNS tell which name is the address to return? Would it be the shortest? The longest? Based on some other attribute? There can be multiple aRecord entries but most clients doing PTR lookups will only accept the first... Do you know how PowerDNS resolves this issue? Do they bother? |
|
From: Troy B. <ho...@ho...> - 2004-03-12 02:43:55
|
What are your thoughts on adding support for the dNSZone schema at: http://garibaldi.venaas.no/ldap/bind-sdb/ http://garibaldi.venaas.no/ldap/bind-sdb/dnszone-schema.txt I could probably hack up the code if given an idea where to start looking.. In addition, I've also been looking at the powerdns ldap-backend, and it has the capability to automatically generate 'PTR' records based on the forward lookup records. This is nice, but it's only available as a global configuration option. Is there a sane way to generate PTR records off a regular ldapdns or other forward lookup entry? (I would prefer adding an entry to the dNSZone schema) You'd obviously want to look through the regular 'in-addr.arpa' space first, but if you don't get a hit there, and the foward lookup for that IP has the right attribute, you return a corresponding reverse lookup. -- -------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' ho...@ho... Somone asked my why I work on this free (http://www.fsf.org/philosophy/) software stuff and not get a real job. Charles Shultz had the best answer: "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shultz |
|
From: Mrs. B. <mrs...@ni...> - 2004-02-17 04:16:17
|
Fixes to additional section processing; especially with MX and CNAME targets. Sorry I've been sleeping lately... LDAPDNS is quickly [re]becoming a priority... |
|
From: Andreas B. <ab...@ae...> - 2003-09-23 11:10:25
|
Hi, have a look at 2.05 and the mailinglist archive of ldapdns-user. That behaviour was corrected in the last release. Regards, Andreas Am Mon, Sep 22, 2003 at 07:22:39PM -0700, schrieb Gary Richardson: > Hey, > > I don't know if this list is the correct place to ask about this; let me > know if there is a better place. > > I'm going to shortly be using ldapdns 2.04 in production. I've come across > one problem though. I have $NS1 and $NS2 set so that I can use the nSRecord: > @ alias. > > If I specify a different set of nameserver for delegating a zone, those name > servers are listed, as well as the $NS1 and $NS2 servers. Is there a way to > change this behavior? > > I also noticed that if I do a zone transfer with nSRecord: @, the generated > zone lists nSRecord: @ instead of the $NS* values. > > Thanks :) -- Andreas Brenk mailto:ma...@an... http://www.andreasbrenk.com |
|
From: Gary R. <gar...@ma...> - 2003-09-23 02:23:14
|
Hey, =20 I don't know if this list is the correct place to ask about this; let me know if there is a better place. =20 I'm going to shortly be using ldapdns 2.04 in production. I've come = across one problem though. I have $NS1 and $NS2 set so that I can use the = nSRecord: @ alias.=20 =20 If I specify a different set of nameserver for delegating a zone, those = name servers are listed, as well as the $NS1 and $NS2 servers. Is there a way = to change this behavior? =20 I also noticed that if I do a zone transfer with nSRecord: @, the = generated zone lists nSRecord: @ instead of the $NS* values. =20 Thanks :) |
