Bug 1743572
| Summary: | nslookup doesn't try to search the search in /etc/resolv.conf | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Juan Luis de Sousa-Valadas <jdesousa> | ||||||
| Component: | bind | Assignee: | Petr Menšík <pemensik> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Petr Sklenar <psklenar> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 7.7 | CC: | abhavsar, cbesson, dbodnarc, fweimer, kmoriguc, pemensik, psklenar, rbost, sbroz, thozza, tibrahim, tkorbar | ||||||
| Target Milestone: | rc | Keywords: | Regression, Reproducer | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | bind-9.11.4-16.P2.el7 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2020-03-31 19:45:51 UTC | Type: | Bug | ||||||
| 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: | |||||||||
| Bug Blocks: | 1757052 | ||||||||
| Attachments: |
|
||||||||
|
Description
Juan Luis de Sousa-Valadas
2019-08-20 08:53:09 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.
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? 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. *** Bug 1754127 has been marked as a duplicate of this bug. *** 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 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. 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 *** Bug 1757724 has been marked as a duplicate of this bug. *** 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. *** Bug 1760782 has been marked as a duplicate of this bug. *** *** Bug 1759163 has been marked as a duplicate of this bug. *** 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.
Created attachment 1644541 [details]
Additional fix for hanged nslookup #2
Improved fix with proper termination on too long name.
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 |