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
5. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
6. Is there already an existing RFE upstream or in Red Hat bugzilla?
A bugzilla was registered for fedora by another customer
7. How quickly does this need resolved? (desired target release)
8. Does this request meet the RHEL Inclusion criteria (please review)
9. List the affected packages
10. Would the customer be able to assist in testing this functionality if
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
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
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
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.
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:
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.