(In reply to Claudiu RAVEICA from comment #0)
> dig pussinboots-.tumblr.com +short
> 66.6.40.38
> 66.6.40.58

Please provide the output of 'getent ahosts pussinboots-.tumblr.com'.

I can't access that RHEL box until Monday.

On CentOS 6.5 the output of 'getent ahosts pussinboots-.tumblr.com' is blank. Not sure if that is any help.

Same here.  It is just what the glibc resolver returns, nothing specific to curl.  I am switching the component to glibc...

Using ping or curl isn't immediate proof that the problem is in glibc, what really needs to happen is someone (the glibc team, or the reporter) needs to create a small test case that uses getaddrinfo to make the request and show that it doesn't return the correct answer.

Does anyone have such a reduced test case?

~$ cat > bug.c
#include <stdio.h>
#include <stdlib.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>

#ifndef   NI_MAXHOST
#define   NI_MAXHOST 1025
#endif

int main(void)
{
    struct addrinfo *result;
    struct addrinfo *res;
    int error;

    /* resolve the domain name into a list of addresses */
    error = getaddrinfo("pussinboots-.tumblr.com", NULL, NULL, &result);
    if (error != 0)
    {
        if (error == EAI_SYSTEM)
        {
            perror("getaddrinfo");
        }
        else
        {
            fprintf(stderr, "error in getaddrinfo: %s\n", gai_strerror(error));
        }
        exit(EXIT_FAILURE);
    }

    /* loop over all returned results and do inverse lookup */
    for (res = result; res != NULL; res = res->ai_next)
    {
        char hostname[NI_MAXHOST] = "";

        error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, NI_MAXHOST, NULL, 0, 0);
        if (error != 0)
        {
            fprintf(stderr, "error in getnameinfo: %s\n", gai_strerror(error));
            continue;
        }
        if (*hostname != '\0')
            printf("hostname: %s\n", hostname);
    }

    freeaddrinfo(result);
    return 0;
}

--------------------------------

~$ make bug
cc     bug.c   -o bug

~$ ./bug
error in getaddrinfo: Name or service not known

Windows, OS X and OpenBSD do not have this issue. Google seams to use a patched glibc as their bots do not have any problem accessing these sites. Unfortunately, most Linux distributions seams to behave different.


Unless you want to support this, please consider it closed/won't fix.

Red Hat Enterprise Linux 6 transitioned to the Production 3 Phase on May 10, 2017.  During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

This issue does not qualify, but we will consider incorporating an upstream change into Red Hat Enterprise Linux 7 if it becomes available.

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Fixed upstream:

commit c0a25aa92b612786f4e45292c4aee1d7d47123f8
Author: Florian Weimer <fweimer>
Date:   Sat Nov 11 11:51:08 2017 +0100

    resolv: More precise checks in res_hnok, res_dnok [BZ #22409] [BZ #22412]
    
    res_hnok rejected some host names used on the Internet, such as
    www-.example.com.  res_hnok and res_dnok failed to perform basic syntax
    checking on DNS domain names.
    
    Also fix res_mailok, res_ownok.

A backport should include these commits as well:

commit 9e0ad3049dbae88d615bfb038e53bf365a39a634
Author: Florian Weimer <fweimer>
Date:   Sat Nov 11 11:41:45 2017 +0100

    resolv: ns_name_pton should report trailing \ as error [BZ #22413]

commit e2a9fca8101443076235a8dbcfceaa2d96bf4801
Author: Florian Weimer <fweimer>
Date:   Sat Nov 11 11:33:32 2017 +0100

    resolv: Add tst-ns_name_pton

commit 5c1a69238fcb87ff7f916a5ce7960b2864afb3a1
Author: Florian Weimer <fweimer>
Date:   Sat Nov 11 11:23:40 2017 +0100

    resolv: Add tst-res_hnok

Verified with the reproducer and glibc tests: resolv/tst-res_hnok, resolv/tst-ns_name_pton.
The bug was reproducible in glibc-2.17-274.el7, and the bug was fixed in glibc-2.17-275.el7

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:2118