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 69.172.200.109
I would expect C library for resolving DNS names to already enforce those basic constrain. I believe we should be careful about performing additional validation/restriction.
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
(1) 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
(2) 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: