Howard Chu wrote:

A. Schulze wrote:

...

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.

I wholeheartly agree.

Maybe this feature should be removed in 2.5 to make that really clear. Likely this would also hunk out ACLs based on hostnames. But that's a pretty dangerous feature anyway.

Ciao, Michael.

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.

--On Wednesday, March 09, 2016 12:52 PM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de 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.

With IPv6 and carrier grade NAT, IP addresses are not in and of themselves the full set of information necessary to identify a system. You need the address + port, and only the ISP can map it back to any individual system.

--Quanah

--

Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc