Hide Forgot
Description of problem: curl, ping can not resolve hosts like "hostname-.domain.com" Version-Release number of selected component (if applicable): 6.5 How reproducible: always Steps to Reproduce: curl -v pussinboots-.tumblr.com * getaddrinfo(3) failed for pussinboots-.tumblr.com:80 * Couldn't resolve host 'pussinboots-.tumblr.com' * Closing connection #0 curl: (6) Couldn't resolve host 'pussinboots-.tumblr.com' ping pussinboots-.tumblr.com ping: unknown host pussinboots-.tumblr.com However, it works with host, dig host pussinboots-.tumblr.com pussinboots-.tumblr.com has address 66.6.40.38 pussinboots-.tumblr.com has address 66.6.40.58 dig pussinboots-.tumblr.com +short 66.6.40.38 66.6.40.58 Definitely, there is something wrong.
(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@redhat.com> 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@redhat.com> 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@redhat.com> Date: Sat Nov 11 11:33:32 2017 +0100 resolv: Add tst-ns_name_pton commit 5c1a69238fcb87ff7f916a5ce7960b2864afb3a1 Author: Florian Weimer <fweimer@redhat.com> 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