[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#8618) ldapsearch - unexpected behavior with

I am also not a C programmer. I've not even looked at patch at this point.

I agree best practice  says hostname are limited to specific ASCII characters.
And underscore are indeed not included.

However DNS name in general only have very few restriction (RFC2181) (2).
I did some tests using the 'host' and 'dig' command and they do not perform
additional validation. For example (2):

	$ host  'ldap://.test.com'
	ldap://.test.com has address

I would expect C library for resolving DNS names to already enforce those basic
constrain.  I believe we should be careful about performing additional

Micheal, you are *right* about the man page saying _hostname_. Indeed OpenLDAP
only accepting hostname as per best practice/RFC might be the most correct
behavior. However we can not change this behavior  without breakable. consider:

  - Underscore are not that uncommon with Active Directory
  - What about internationalized DNS name
  - ... (probably more)

Therefore I believe such change could only be done in a major release. And at
that point we might just remove the depreciated '-h' option altogether.

I don't know how OpenLDAP code work. I have a suspicion it might
transform hostname + port into a URI.  
The ITC shows that (for some cases) hostname are handled differently when:

  1. Using only '-h' without '-p'
  2. Using both '-h' and '-p'

And this is clearly not a correct behavior.

Best, Alex

See RFC for reference but essentially:
  - A full domain name is limited to 255 octets (including the separators)
  - Each part of the domain (label) can be between 1 and 63 octets

test.com DNS seems to simply return the same A record for any subdomain
(wildcard).  It highlights that wierd name like works at the DNS level.

PS: I exchanged a few email regarding DNS/hostname with Lawrence off the list. I
believe this email summarizes the main points from my perspective.

On Fri, 2018-03-02 at 18:48 +0000, michael@stroeder.com wrote:
> andrew.lawrence@siemens.com wrote:
> > I believe the following patch addresses this problem. I am still a
> > bit conf used about what constitutes a DNS name. Alex has suggested
> > they should contain an underscore. My colleague who reviewed the code
> > had a different opinion.
> Disclaimer: Since I'm not a C programmer I did not really review your
> patch in detail but just want to add some general notes.
> 1. Reviewing this ticket my  is that the only problem is that
> -h also accepts a LDAP URI because -H should be used instead.
> IIRC -h was only meant to take an IP address or hostname.
> Therefore I'd strongly recommend to simply reject an LDAP URI for -h.
> Is that your goal?
> 2. The term "DNS name" is a bit too blurry. In case of option -h it
> should be an IP address or . And according to best practices
> hostnames SHOULD NOT contain underscores.
> Whether you _allow_ underscores to accommodate some strange setups is
> your decision.
> Ciao, .