prevent stripping trailing dot for resolving

[thz]

This change removes the stripping of trailing dots in hostnames for the aspect of name resolving.
It does not change hostnames for SNI or http Host header.

This allows using a trailing dot to denote a fully qualified name with DNS.

Fixes: #3022

[bagder]

Test 20 and 1322 both have memory issues reported on travis. One leak, one illegal free.

[thz]

@bagder, As I eventually only moved the resolving it seems to me that I am somehow triggering an pre-existing issue.
But I am still investigating. In case you have an idea where that is coming from, a hint would be highly appreciated.

[bagder]

I only moved the resolving

You moved where the resolving starts. Most libcurl builds will resolve host name asynchronously so when resolve_server() returns it might not be done yet. You're then removing the trailing dot when the resolver function sometimes hasn't completed.

I don't think we can can use the same strings for both with and without trailing dot purposes unless we're really sure that those buffers won't be needed again in their original pristine versions.

[thz]

All right. I will go for a dedicated name for resolving purposes then.

[thz]

It seems to me that the tests are running into the issue previously found here:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1719959
There seems to be a known eglibc-2.19 leak in getaddrinfo when fed with a "bad address".
I am not exactly sure why this did not surface before.

[thz]

I can reproduce the issue now in a docker container with ubuntu-14.04 userland. Tracking it down...

[thz]

Test 20 fails because of the getaddrinfo memory leak found in eglibc-2.19 (trusty is used).
I created a minimal case for this issue at https://github.com/thz/getaddrinfo-leak to show this.

A mitigation might be to change test20 to a IPv4 only test (it is about non-existing names anyways), because the bug is only triggered with PF_UNSPEC.
Alternatively a newer travis environment/userland (xenial would be enough) would prevent this bug from surfacing too.

I did not look into the details for test 1322 yet.

(CC: @bagder)

[thz]

The reason why this did not happen before is that only some names trigger it when resolving. Two examples:

• a name which yields no existing address (NXDOMAIN for dns), which has a trailing dot
• a name which yields a mix of A and AAAA records

Test 20 could also be mitigated by removing the trailing dot in data/test20.

[thz]

Test1322 failing is of similar nature. Here the old eglibc-2.19 (ubuntu-14.04 used in travis) is doing free() in an atexit handler and surfaces an invalid free in valgrind. Forcing ipv4 is again a mitigation. Going for a newer userland in travis would prevent this as well.

[thz]

Test 1526 on Visual Studio 12 seems flaky.

[thz]

Now a osx clang build failed during build setup. Is there a way to trigger a rebuild without pushing phony commits?

[thz]

@bagder all issues addressed. Please let me know if the test mitigation is acceptable.

[bagder]

Sorry for being slow. Can you please squash this set of commits into just a series of suitable commits without fixups (and force-push)? That simplifies reviewing greatly and is the way we want to merge them anyway!

[thz]

apt-get install failed due to some unreachable ppa... Completely unrelated. Is it possible to just trigger a rebuild?

[thz]

@bagder done rebasing/squashing.

[thz]

@bagder ping. Used another rebase for getting a retest. All green now.

[bagder]

Awesome, thanks for your hard work on this!