Bug 1039304 - glibc: More precise DNS name checks (accepting dash-.example.com, among other things)
Summary: glibc: More precise DNS name checks (accepting dash-.example.com, among other...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: pre-dev-freeze
: 7.6
Assignee: Florian Weimer
QA Contact: Sergey Kolosov
Eliane Ramos Pereira
URL:
Whiteboard:
Depends On:
Blocks: 1655768
TreeView+ depends on / blocked
 
Reported: 2013-12-07 20:05 UTC by Claudiu RAVEICA
Modified: 2019-08-06 12:49 UTC (History)
9 users (show)

Fixed In Version: glibc-2.17-275.el7
Doc Type: Bug Fix
Doc Text:
.The DNS stub resolver in `glibc` no longer rejects valid host names, such as hostname-.example.com The DNS stub resolver in `glibc` rejected certain valid host names, such as hostname-.example.com, and accepted some invalid names. As a consequence, some host names on the Internet could not be resolved. To fix the problem, the DNS name validation functions, such as `res hnok`, have been adjusted to match user expectations and specifications more closely. As a result, host names of the form hostname-.example.com can now be resolved successfully if they exist in DNS.
Clone Of:
Environment:
Last Closed: 2019-08-06 12:48:58 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:2118 None None None 2019-08-06 12:49:27 UTC
Sourceware 22409 'P2' 'RESOLVED' 'res_hnok does not accept some host names used on the Internet' 2019-11-26 09:51:33 UTC

Description Claudiu RAVEICA 2013-12-07 20:05:16 UTC
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.

Comment 2 Kamil Dudka 2013-12-07 21:35:42 UTC
(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'.

Comment 3 Claudiu RAVEICA 2013-12-07 22:13:02 UTC
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.

Comment 4 Kamil Dudka 2013-12-08 09:26:25 UTC
Same here.  It is just what the glibc resolver returns, nothing specific to curl.  I am switching the component to glibc...

Comment 5 Carlos O'Donell 2013-12-27 23:19:12 UTC
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?

Comment 6 Claudiu RAVEICA 2014-01-07 17:23:01 UTC
~$ 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

Comment 7 Claudiu RAVEICA 2014-01-07 17:58:22 UTC
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.

Comment 13 Florian Weimer 2017-11-08 09:48:33 UTC
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.

Comment 14 Red Hat Bugzilla Rules Engine 2017-11-08 09:48:38 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Comment 16 Florian Weimer 2017-11-11 11:02:04 UTC
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

Comment 20 Sergey Kolosov 2019-03-26 14:16:51 UTC
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

Comment 25 errata-xmlrpc 2019-08-06 12:48:58 UTC
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


Note You need to log in before you can comment on or make changes to this bug.