RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1743572 - nslookup doesn't try to search the search in /etc/resolv.conf
Summary: nslookup doesn't try to search the search in /etc/resolv.conf
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: bind
Version: 7.7
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Petr Menšík
QA Contact: Petr Sklenar
URL:
Whiteboard:
: 1754127 1757724 1759163 1760782 (view as bug list)
Depends On:
Blocks: 1757052
TreeView+ depends on / blocked
 
Reported: 2019-08-20 08:53 UTC by Juan Luis de Sousa-Valadas
Modified: 2023-09-07 20:25 UTC (History)
12 users (show)

Fixed In Version: bind-9.11.4-16.P2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-31 19:45:51 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Additional fix for hanged nslookup (766 bytes, patch)
2019-12-12 15:16 UTC, Petr Menšík 		no flags Details | Diff
Additional fix for hanged nslookup #2 (815 bytes, patch)
2019-12-12 18:55 UTC, Petr Menšík 		no flags Details | Diff
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4518531 0 None None None 2019-10-24 04:52:18 UTC
Red Hat Product Errata RHSA-2020:1061 0 None None None 2020-03-31 19:46:07 UTC

Description Juan Luis de Sousa-Valadas 2019-08-20 08:53:09 UTC 
Description of problem:
nslookup doesn't search names in the search 

Version-Release number of selected component (if applicable):
bind-utils-9.11.4-9.P2.el7.x86_64 
The previous version (bind-utils-32:9.9.4-74.el7_6.2.x86_64) behaves correctly

How reproducible:
Always

Steps to Reproduce:
$ 
$ nslookup
> kubernetes.default.svc
Server:         10.74.178.118
Address:        10.74.178.118#53
> kubernetes.default.svc
Server:         10.74.178.118
Address:        10.74.178.118#53

** server can't find kubernetes.default.svc: NXDOMAIN
> kubernetes.default.svc.cluster.local
Server:         10.74.178.118
Address:        10.74.178.118#53

Name:   kubernetes.default.svc.cluster.local
Address: 172.30.0.1


$  cat /etc/resolv.conf 
# nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh
# Generated by NetworkManager
search cluster.local openstacklocal <removed sensitive data>
nameserver 10.74.178.118

Actual results:
As seen kubernetes.default.svc doesn't resolv but kubernetes.default.svc.cluster.local works

Expected results:
nslookup tries to resolv appending each domain in the search of /etc/resolv.conf.

Additional info:
Comment 2 Petr Menšík 2019-08-23 15:14:03 UTC 
This behaviour is intentional. Search directive in resolv.conf is meant only for unqualified names.

That means only kubertenes is tried as kubernetes.cluster.local, then kubernetes.openstacklocal. But once a dot is in name, it is expected to be fully qualified domain name and search is not used.

It can be overriden by setting ndots option to 3. It is number of dots in hostname that should be considered unqualified. 
in resolv.conf:
option ndots:3

in nslookup:
set ndots=3

I have configured just openstacklocal search domain.
it can be tested in debug mode, which prints all queries made:

$ nslookup
> set debug
> set ndots=3
> kubernetes.default.svc 
Server:		10.11.142.1
Address:	10.11.142.1#53

------------
    QUESTIONS:
	kubernetes.default.svc.openstacklocal, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  .
	origin = a.root-servers.net
	mail addr = nstld.verisign-grs.com
	serial = 2019082300
	refresh = 1800
	retry = 900
	expire = 604800
	minimum = 86400
	ttl = 10800
    ADDITIONAL RECORDS:
------------
** server can't find kubernetes.default.svc.openstacklocal: NXDOMAIN
Server:		10.11.142.1
Address:	10.11.142.1#53

------------
    QUESTIONS:
	kubernetes.default.svc, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  .
	origin = a.root-servers.net
	mail addr = nstld.verisign-grs.com
	serial = 2019082300
	refresh = 1800
	retry = 900
	expire = 604800
	minimum = 86400
	ttl = 10760
    ADDITIONAL RECORDS:
------------
** server can't find kubernetes.default.svc: NXDOMAIN

echo "option ndots:3" >> /etc/resolv.conf would modify it to include search for two dots as well. But I would not recommend it. It can be security issue, because redhat.com would be searched first on search domains. If DHCP were attacked and served domain under control of attacker, such configuration would allow most hostnames to be redirected to IP adresses selected by attacker.

I think this bug should be closed as NOTABUG, since only configuration is wrong.
Comment 3 Petr Menšík 2019-08-23 15:42:07 UTC 
Ok, utilities from 9.11 has a bit different behavior. Former version 9.9.4 by default just reversed order when any dot was present. Unless such service existed under root, it would query also search domain after that.

Version 9.9.4:
# nslookup
> set debug
> kubernetes
Server:		10.11.142.1
Address:	10.11.142.1#53

------------
    QUESTIONS:
	kubernetes.openstacklocal, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  .
	origin = a.root-servers.net
	mail addr = nstld.verisign-grs.com
	serial = 2019082300
	refresh = 1800
	retry = 900
	expire = 604800
	minimum = 86400
	ttl = 7984
    ADDITIONAL RECORDS:
------------
** server can't find kubernetes: NXDOMAIN
Server:		10.11.142.1
Address:	10.11.142.1#53

------------
    QUESTIONS:
	kubernetes, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  .
	origin = a.root-servers.net
	mail addr = nstld.verisign-grs.com
	serial = 2019082300
	refresh = 1800
	retry = 900
	expire = 604800
	minimum = 86400
	ttl = 7984
    ADDITIONAL RECORDS:
------------
** server can't find kubernetes: NXDOMAIN
> kubernetes.default.svc
Server:		10.11.142.1
Address:	10.11.142.1#53

------------
    QUESTIONS:
	kubernetes.default.svc, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  .
	origin = a.root-servers.net
	mail addr = nstld.verisign-grs.com
	serial = 2019082300
	refresh = 1800
	retry = 900
	expire = 604800
	minimum = 86400
	ttl = 9344
    ADDITIONAL RECORDS:
------------
** server can't find kubernetes.default.svc: NXDOMAIN
Server:		10.11.142.1
Address:	10.11.142.1#53

------------
    QUESTIONS:
	kubernetes.default.svc.openstacklocal, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  .
	origin = a.root-servers.net
	mail addr = nstld.verisign-grs.com
	serial = 2019082300
	refresh = 1800
	retry = 900
	expire = 604800
	minimum = 86400
	ttl = 9384
    ADDITIONAL RECORDS:
------------
** server can't find kubernetes.default.svc: NXDOMAIN


Version 9.11.4:
# nslookup
> set debug
> kubernetes
Server:		10.11.142.1
Address:	10.11.142.1#53

------------
    QUESTIONS:
	kubernetes.openstacklocal, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  .
	origin = a.root-servers.net
	mail addr = nstld.verisign-grs.com
	serial = 2019082300
	refresh = 1800
	retry = 900
	expire = 604800
	minimum = 86400
	ttl = 8045
    ADDITIONAL RECORDS:
------------
** server can't find kubernetes.openstacklocal: NXDOMAIN
Server:		10.11.142.1
Address:	10.11.142.1#53

------------
    QUESTIONS:
	kubernetes, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  .
	origin = a.root-servers.net
	mail addr = nstld.verisign-grs.com
	serial = 2019082300
	refresh = 1800
	retry = 900
	expire = 604800
	minimum = 86400
	ttl = 8045
    ADDITIONAL RECORDS:
------------
** server can't find kubernetes: NXDOMAIN
> kubernetes.default.svc
Server:		10.11.142.1
Address:	10.11.142.1#53

------------
    QUESTIONS:
	kubernetes.default.svc, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  .
	origin = a.root-servers.net
	mail addr = nstld.verisign-grs.com
	serial = 2019082300
	refresh = 1800
	retry = 900
	expire = 604800
	minimum = 86400
	ttl = 9391
    ADDITIONAL RECORDS:
------------
** server can't find kubernetes.default.svc: NXDOMAIN

While it behaves different way, this should not be considered regression. It is security feature actually. It would not even try search domains if containing dots. Previously, it searched just after absolute name.
I do not think old behaviour should be brought back. There is more space for possible attacks.

It is known what does it the customer using for? Can we help them with more reliable method instead?
Comment 4 Juan Luis de Sousa-Valadas 2019-09-09 11:29:44 UTC 
Customer didn't replay about the use case, but complains about consistency because ping and other tools still add search domains, where "bind-utils" related tools don't, and says if it's a security issue should be fixed everywhere and not just in bind libs.

Also says and I'm quoting:
~~~
"once a dot is in name, it is expected to be fully qualified domain name and search is not used" is also not true - fully qualified domain name is a domain name which ends with dot, not the name which contains a dot. 

According to all manuals which I've found option ndots:n is used to define order in which query will be made (as-is first, or as-is last), in all cases search domains will be tried until name will be resolved.
~~~

I think it would be more consistent to revert this change.
Comment 5 Taneem Ibrahim 2019-09-24 19:02:42 UTC 
*** Bug 1754127 has been marked as a duplicate of this bug. ***
Comment 7 Petr Menšík 2019-09-26 09:52:13 UTC 
It seems to me commit [1] is responsible for behaviour change. I were searching for documentation for behaviour change, but cannot access original issue. It seems to me this change might be unwanted side-effect of different fix. At least, motivation for it is not clearly documented in my opinion. I could not find any note about it in release notes[2], it seems this change was considered not relevant.

1. https://gitlab.isc.org/isc-projects/bind9/commit/8afea636ab0c07399aa3e2410b2cfbd41099df98
2. https://downloads.isc.org/isc/bind9/9.10.0/RELEASE-NOTES-BIND-9.10.0.txt
Comment 8 Petr Menšík 2019-09-26 11:13:41 UTC 
I agree it should be consistent with glibc resolver used. Even most recent resolvers behave similar way to RHEL 7 version, unlike used bind-utils. I think it should be made consistent and give the same results. With dot in name, it does not now.
Comment 11 Petr Menšík 2019-10-02 10:24:09 UTC 
Received hint to great material related to this topic, SSAC Advisory on Search List Processing [1]. It recommends overall approach like bind-utils have taken, unlike system resolver provided by glibc. But we have agreement this change is not desired and should be fixed in RHEL 7. We do not however plan at this time to revert this behaviour also in RHEL 8. We need discussion there what is desired behaviour in system library.

1. https://www.icann.org/en/groups/ssac/documents/sac-064-en.pdf
Comment 14 Petr Menšík 2019-10-02 11:26:19 UTC 
*** Bug 1757724 has been marked as a duplicate of this bug. ***
Comment 16 Petr Menšík 2019-10-02 12:06:16 UTC 
It is worth noting manual pages of host and dig describes exactly current behaviour, that is going to be reverted. It seems it was not expected to be use current way also back in BIND 9.9. It was just not enforced, like now.
Comment 21 Petr Menšík 2019-10-15 07:50:52 UTC 
*** Bug 1760782 has been marked as a duplicate of this bug. ***
Comment 22 Stepan Broz 2019-10-15 11:27:56 UTC 
*** Bug 1759163 has been marked as a duplicate of this bug. ***
Comment 27 Petr Menšík 2019-12-12 15:16:12 UTC 
Created attachment 1644460 [details]
Additional fix for hanged nslookup

Fixes unterminated search, when search domain was used, dot is present in relative name and resulting full name would be too long.
Comment 29 Petr Menšík 2019-12-12 18:55:06 UTC 
Created attachment 1644541 [details]
Additional fix for hanged nslookup #2

Improved fix with proper termination on too long name.
Comment 41 errata-xmlrpc 2020-03-31 19:45:51 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-2020:1061
Note You need to log in before you can comment on or make changes to this bug.