Bug 677316

Summary: glibc: Increase number of search domains supported by /etc/resolv.conf
Product: Red Hat Enterprise Linux 7 Reporter: J.H.M. Dassen (Ray) <rdassen>
Component: glibcAssignee: Florian Weimer <fweimer>
Status: CLOSED ERRATA QA Contact: Sergey Kolosov <skolosov>
Severity: low Docs Contact: Vladimír Slávik <vslavik>
Priority: low    
Version: 7.3CC: aperotti, ashankar, bgollahe, codonell, cww, devurandom, dmoessne, fweimer, mcermak, michele, mnewsome, pdwyer, pemensik, pfrankli, rbinkhor, rpiddapa, rupatel, rvdwees, skolosov, spanjikk, tscherf, vslavik
Target Milestone: rcKeywords: Patch
Target Release: 7.4   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: glibc-2.17-202.el7 Doc Type: Enhancement
Doc Text:
DNS stub resolver improvements The DNS stub resolver in the `glibc` package has been updated to the upstream glibc version 2.26. Notable improvements and bug fixes include: * Changes to the `/etc/resolv.conf` file are now automatically recognized and applied to running programs. To restore the previous behavior, add the `no-reload` option to the `options` line in `/etc/resolv.conf`. Note that depending on system configuration, the `/etc/resolv.conf` file might be automatically overwritten as part of the configuration of the networking subsystem, removing the `no-reload` option. * The previous limit of six search domain entries is removed. You can now specify any number of domains with the `search` directive in `/etc/resolv.conf`. Note that additional entries may add significant overhead to DNS processing; consider running a local caching resolver if the number of entries exceeds three. * The handling of various boundary conditions in the `getaddrinfo()` function is fixed. Very long lines in the `/etc/hosts` file (including comments) no longer affect lookup results from other lines. Unexpected terminations related to stack exhaustion on systems with certain `/etc/hosts` configuration no longer occur. * Previously, when the `rotate` option was enabled in `/etc/resolv.conf`, the first DNS query of a new process was always sent to the second name server configured in the name server list in `/etc/resolv.conf`. This behavior has been changed, and the first DNS query now randomly selects a name server from the list. Subsequent queries rotate through the available name servers, as before.
Story Points: ---
Clone Of:
: 1496219 (view as bug list) Environment:
Last Closed: 2018-04-10 13:56:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 168253, 1484034    
Bug Blocks: 1329674, 1420851, 1471969, 1473733, 1477926, 1487063    

Description J.H.M. Dassen (Ray) 2011-02-14 10:49:22 UTC
2. What is the nature and description of the request?

Customer would like to use more search domains in /etc/resolv.conf.

3. Why does the customer need this? (List the business requirements here)

The below is the customer explanation.

Redhat should acknowledge this kind of legacy & paper-cut bugs have to be
resolved in order to be succesful in large enterprise organizations.

This bug already has hit another admin at Customer (his admin overview shows
red lights for these hosts which do not fit in the 6 domain limit, because they
are not pingable). Trying to teach these limit is fruitless and needs to be
repeated for every new admin forever until it is fixed properly).

4. How would the customer like to achieve this? (List the functional
requirements here)

raise MAXDNSRCH 

5. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

Not specified.

6. Is there already an existing RFE upstream or in Red Hat bugzilla?

A bugzilla was registered for fedora by another customer

https://bugzilla.redhat.com/show_bug.cgi?id=168253

7. How quickly does this need resolved? (desired target release)

rhel6

8. Does this request meet the RHEL Inclusion criteria (please review)

Yes 

9. List the affected packages

glibc 

10. Would the customer be able to assist in testing this functionality if
implemented?

yes

Comment 2 J.H.M. Dassen (Ray) 2011-02-14 10:53:58 UTC
As noted in bug #168253, raising MAXDNSRCH would break ABI.

The customer is requesting a change that would allow more than 6 search domains to function when specified in /etc/resolv.conf. Given the ABI considerations, this is likely to require a new API as well as updates to related components like nscd and sssd to make use of this new API.

Comment 3 J.H.M. Dassen (Ray) 2011-07-29 07:58:11 UTC
Adding another customer request for this.

Q)What is the nature and description of the request?
A Linux glibc code limits the search domain to 6 domains, the customer wants
to increase this to around 20 similar to other OS like Solaris/Windows

Q)    Why does the customer need this? (List the business requirements here)
A) the following answer was provided by the customer

"We want to use short hostnames on our monitoring system, but we have more
than 6 domains in our search list. We can only reach the first 6 ones. We
dont want to change to hostnames with domain."


Q)   How would the customer like to achieve this? (List the
functionalrequirements here).For each functional requirement listed in
question 4, specify how Red Hatand the customer can test to confirm the
requirement is successfully implemented.
A) By modifying the  # define MAXDNSRCH in resolv/resolv.h of the glibc
source. This can be tested by specifying more than 6 domains in the search
path of /etc/resolv.conf file and checking if the 7th domain is being
searched.

Q)   Is there already an existing RFE upstream or in Red Hat bugzilla?
An earlier attempt was made through
https://bugzilla.redhat.com/show_bug.cgi?id=168253 and was promptly denied
by engineering, but it was not through support.

Q)    How quickly does this need resolved? (desired target release)?
Not defined by the customer and considering the change level, I do not think
we can include it any lower than RHEL6.2

Q)    Does this request meet the RHEL Bug and Feature Inclusion Criteria
	Yes
 
   (please review)
Q)    List the affected packages
Glibc and anyother packages where the constant is used.

Q)    Would the customer be able to assist in testing this functionality if
implemented?
Yes, they have also specified that missing this feature, they will be forced
to look at other alternatives like Windows/Solaris.

Comment 22 Florian Weimer 2016-02-04 16:31:00 UTC
What is the number of required search domains we are looking at?

If we are talking about dozens of domains, DNS will be an extremely poor interface for this because each entry can result in an additional UDP DNS query, adding quite a bit load to DNS caches.

Comment 29 Carlos O'Donell 2017-07-21 17:11:30 UTC
Upstream patch (probably has dependencies), listed here for reference.

commit 3f853f22c87f0b671c0366eb290919719fa56c0e
Author: Florian Weimer <fweimer>
Date:   Sat Jul 1 00:53:05 2017 +0200

    resolv: Lift domain search list limits [BZ #19569] [BZ #21475]
    
    This change uses the extended resolver state in struct resolv_conf to
    store the search list.  If applications have not patched the _res
    object directly, this extended search list will be used by the stub
    resolver during name resolution.

Note that MAXDNSSRCH was not raised, which means there are some restrictions on how applications can use the _res object and the search domains which would again limit you to MAXDNSSRCH.

Comment 33 Florian Weimer 2017-10-09 14:00:02 UTC
Public preview builds are available here:

https://copr.fedorainfracloud.org/coprs/fweimer/glibc-rhel-7.5/

Comment 49 errata-xmlrpc 2018-04-10 13:56:38 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-2018:0805