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: | glibc | Assignee: | Florian Weimer <fweimer> | |
Status: | CLOSED ERRATA | QA Contact: | Sergey Kolosov <skolosov> | |
Severity: | low | Docs Contact: | Vladimír Slávik <vslavik> | |
Priority: | low | |||
Version: | 7.3 | CC: | aperotti, ashankar, bgollahe, codonell, cww, devurandom, dmoessne, fweimer, mcermak, michele, mnewsome, pdwyer, pemensik, pfrankli, rbinkhor, rpiddapa, rupatel, rvdwees, skolosov, spanjikk, tscherf, vslavik | |
Target Milestone: | rc | Keywords: | 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
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. 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. 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. 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. Public preview builds are available here: https://copr.fedorainfracloud.org/coprs/fweimer/glibc-rhel-7.5/ 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 |