A. Schulze wrote:

Hi again,

this is my third and last patch I send today :-)

I compiled openldap with '--enable-rlookups' and set 'reverse-lookup on' in slapd.conf I like to see the remote hostname logged. That didn't work somehow. ( I wrote this patch months ago and could not describe the real problem anymore)

Anyway: the patch modify log output:

reverse-lookup off: conn=4846 fd=42 ACCEPT from IP=127.0.0.1:46058 (IP=127.0.0.1:389)

reverse-lookup on: conn=4191 fd=18 ACCEPT from localhost (IP=127.0.0.1:389)

I never tested with ldapi:// connections. Also I expect the patch is not optimal for performance. But it works here in a small environment.

Indeed, in a busy environment the DNS resolver itself is too slow for slapd. I've got no particular comment on this patch since I never enable reverse lookups. But IMO, this sort of thing is best left to a logfile postprocessor, because handling it directly in slapd will be too slow.

...

...

Howard Chu hyc@symas.com schrieb am 09.03.2016 um 09:05 in Nachricht

56DFD95B.5080508@symas.com:

A. Schulze wrote:

...

Hi again,

this is my third and last patch I send today :-)

I compiled openldap with '--enable-rlookups' and set 'reverse-lookup on' in slapd.conf I like to see the remote hostname logged. That didn't work somehow. ( I wrote this patch months ago and could not describe the real problem

anymore)

...

Anyway: the patch modify log output:

reverse-lookup off: conn=4846 fd=42 ACCEPT from IP=127.0.0.1:46058 (IP=127.0.0.1:389)

reverse-lookup on: conn=4191 fd=18 ACCEPT from localhost (IP=127.0.0.1:389)

I never tested with ldapi:// connections. Also I expect the patch is not optimal for performance. But it works here in

a

...

small environment.

Indeed, in a busy environment the DNS resolver itself is too slow for slapd.

I've got no particular comment on this patch since I never enable reverse lookups. But IMO, this sort of thing is best left to a logfile postprocessor, because handling it directly in slapd will be too slow.

The argument against (if the postprocessing is significantly after logging the IPs) is that with dynamic IP adresses, it's not clear how the assignment actually was at the time of logging.

Regards, Ulrich

A. Schulze wrote:

Michael Ströder:

...

Maybe this feature should be removed in 2.5 to make that really clear.

please don't... Everybody inspecting a log full with IPv6 connections for troubleshooting will *love* reverse DNS!

As Howard already said: Use a decent logfile post-processor before looking at the log file.

Apache has the similar problem + feature: http://httpd.apache.org/docs/2.4/mod/core.html#hostnamelookups It exist, but the sane default is "off".

Yes, and read the hint about the logresolve tool therein.

Ciao, Michael.

Brian Reichert wrote:

On Wed, Mar 09, 2016 at 03:47:44PM +0100, Michael Str??der wrote:

...

As Howard already said: Use a decent logfile post-processor before looking at the log file.

But, what if PTR records have changed between when the log entry is written, and it's analysis?

Simply do the log post processing pretty soon after the request.

In my own opinion, if you're not running a public server, but one within your company's LAN, then the set of hostnames won't be as numerous, nor as fluid, so I suspect descent resolver could cope.

I agree that such a feature on a public server would not fare well.

Even on an internal (LDAP) server it can be pretty problematic to turn on reverse DNS lookups.

Example: If you're using your LDAP server for admin's system/device login you might need it especially during a partial outage/failure of your infrastructure. So when login to your network router or similar you're likely very happy not to need more moving parts to work. (Well, you should have a decent emergency login in place, but it's hopefully protected by more security measures making it more effort to actually use it.)

Basically not relying on reverse DNS is best common practice in most cases since many years.

Anyway I'm not the one to decide on that. I rather just want to show Howard acceptance to remove this highly deprecated feature to make the code base smaller for saving time to be spent on more useful programming.

Ciao, Michael.

Ulrich Windl wrote:

The argument against (if the postprocessing is significantly after logging the IPs) is that with dynamic IP adresses, it's not clear how the assignment actually was at the time of logging.

As said: If it's really important to you then the postprocessing must be done right after the request. But log processing can be easily off-loaded and buffered.

Doing the reverse DNS lookup right during processing the LDAP request is asking for trouble.

I also vaguely remember that Howard considered changing the log subsystem for better performance anyway.

Ciao, Michael.