nslookup / host do not honor the new search domain limits of glibc

+++ This bug was initially created as a clone of Bug #1758317 +++

Description of problem:

nslookup only reads up until the 8th search domain in /etc/resolv.conf when searching for an answer for a certain domain.

Version-Release number of selected component (if applicable):
bind-utils-9.11.4-9.P2.el7.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Add >=8 invalid search domains to 'search' directive in /etc/resolv.conf.
2. Add 'redhat.com' as the 9th search domain.
3. nslookup access / host access

Actual results:

nslookup returns NXDOMAIN

Expected results:

nslookup should return a correct answer

Additional info:

This is related to https://bugzilla.redhat.com/show_bug.cgi?id=677316 where the limit for the search list in /etc/resolv.conf was lifted:

=================================================================

• 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.
  =================================================================

It appears nslookup / host were never patched. For some reason, both nslookup and host do read the search domain list, but up until the 8th domain in the list. Since we lifted the limit for the glibc resolver, and nslookup / host use the glibc resolver to some extent, these should be patched.

The following search list causes 'nslookup access' to fail with an NXDOMAIN:

search invaliddomain1.com invaliddomain2.com invaliddomain3.com invaliddomain4.com invaliddomain5.com invaliddomain6.com invaliddomain7.com invaliddomain8.com redhat.com

Whereas the following search list causes 'nslookup access' to resolve correctly:

search invaliddomain1.com invaliddomain2.com invaliddomain3.com invaliddomain4.com invaliddomain5.com invaliddomain6.com invaliddomain7.com redhat.com invaliddomain8.com

In both cases, the glibc resolver ('getent hosts access') is able to resolve the domain correctly once it appends 'redhat.com' to the DNS query.

— Additional comment from Petr Menšík on 2019-10-04 10:47:32 CEST —

Public notes.

Search in nslookup is limited to 8 domains.
When search in /etc/resolv.conf includes more than 8 domains, only first 8 are tried.

Limit was increased in glibc by bug #677316.

— Additional comment from Petr Menšík on 2019-10-04 10:55:04 CEST —

This number of searches is defined in lib/lwres/include/lwres/lwres.h

#define LWRES_CONFMAXSEARCH 8 /*%< max 8 domains in "search" entry */

No support for dynamic unlimited list is present.

— Additional comment from Petr Menšík on 2019-10-04 14:18:51 CEST —

Steps to Reproduce:
1. sed -i 's/^search .*/search non-existent1.very-long-domain.fedoraproject.org non-existent2.very-long-domain.fedoraproject.org non-existent3.very-long-domain.fedoraproject.org non-existent4.very-long-domain.fedoraproject.org non-existent5.very-long-domain.fedoraproject.org non-existent6.very-long-domain.fedoraproject.org openstacklocal redhat.com/' /etc/resolv.conf
2. [ "$(host access)" == "$(getent host access.redhat.com.)" ] && echo matches
3. sed -i 's/^search .*/search non-existent1.very-long-domain.fedoraproject.org non-existent2.very-long-domain.fedoraproject.org non-existent3.very-long-domain.fedoraproject.org non-existent4.very-long-domain.fedoraproject.org non-existent5.very-long-domain.fedoraproject.org non-existent6.very-long-domain.fedoraproject.org non-existent7.very-long-domain.fedoraproject.org non-existent8.very-long-domain.fedoraproject.org openstacklocal redhat.com/' /etc/resolv.conf
4. [ "$(host access)" == "$(getent host access.redhat.com.)" ] && echo still matches

— Additional comment from Petr Menšík on 2019-10-04 15:09:55 CEST —

Not even the most recent development version handles this different way. Reported upstream [1].

1. https://gitlab.isc.org/isc-projects/bind9/issues/1259

— Additional comment from Tomáš Hozza on 2019-12-16 12:36:10 CET —

Patch submitted to upstream in https://gitlab.isc.org/isc-projects/bind9/merge_requests/2446