Bug 1404476

Summary:	firefox/dnf/curl dns resolution failure after recent update if using 'search domain' function in /etc/resolve.conf (prevents further updates)
Product:	[Fedora] Fedora	Reporter:	Robert <redhat-bz>
Component:	glibc	Assignee:	Carlos O'Donell <codonell>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	24	CC:	arjun.is, codonell, dj, fweimer, jakub, law, mfabian, nmavrogi, pfrankli, redhat-bz, siddhesh, tmraz
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-12-14 17:30:03 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:

Description Robert 2016-12-13 22:57:47 UTC

Description of problem:
I recently performed a routine system update. Part of this update included several gnutls packages being updated from 3.4.16-1 to 3.4.17-1. I find now, that several utilities (including firefox & dnf's curl [or libcurl?]) will yield a DNS name resolution failure; while other utilities (such as 'dig' & 'host') work just fine.

I found that removing the 'search' config in the /etc/resolve.conf file eliminated this bizarre split-brain behaviour.

I'm only guessing that the problem lies in gnutls, as in my ignorance I find it more likely that firefox and libcurl both use gnutls than firefox & gnutls both using libcurl.

Version-Release number of selected component (if applicable):
$ rpm -qa | egrep '(curl|gnutls|libc-)' | sort -n
curl-7.47.1-9.fc24.x86_64
flickcurl-1.26-3.fc24.x86_64
glibc-2.23.1-11.fc24.i686
glibc-2.23.1-11.fc24.x86_64
glibc-common-2.23.1-11.fc24.x86_64
glibc-devel-2.23.1-11.fc24.x86_64
glibc-headers-2.23.1-11.fc24.x86_64
glibc-langpack-en-2.23.1-11.fc24.x86_64
gnutls-3.4.17-1.fc24.i686
gnutls-3.4.17-1.fc24.x86_64
gnutls-c++-3.4.17-1.fc24.x86_64
gnutls-dane-3.4.17-1.fc24.x86_64
gnutls-devel-3.4.17-1.fc24.x86_64
gnutls-utils-3.4.17-1.fc24.x86_64
libcurl-7.47.1-9.fc24.x86_64
libcurl-devel-7.47.1-9.fc24.x86_64
python3-pycurl-7.43.0-2.fc24.x86_64
python-pycurl-7.43.0-2.fc24.x86_64


How reproducible:
75%


Steps to Reproduce:
1. add "search example.com" to /etc/resolve.conf
2. navigate to several not-recently-viewed sites using firefox
3. (optionally) try using curl or dnf update


Actual results:
Some domains/connections (secure ones?) report a DNS resolution failure, even though attempting to lookup those domain names manually works as expected.


Expected results:
Having a search domain should not interfere with normal DNS operation, or at least yield a more helpful error message.


Additional info:
/etc/nsswitch.conf seems rather complicated (though I don't remember changing it)
> hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname mymachines


Possibly relevant forum posts:

http://askubuntu.com/questions/678372/chrome-and-firefox-can-not-resolve-the-same-host-name-dig-can
* recommends removing the 'dns' entry in /etc/nsswitch.conf

http://stackoverflow.com/questions/32288697/fedora-dnf-update-did-not-working
* recommends using yum-deprecated

http://stackoverflow.com/questions/18808857/could-not-resolve-host-mirrors-fedoraproject-org-name-or-service-not-known

http://superuser.com/questions/704785/ping-cant-resolve-hostname-but-nslookup-can
* suggests that avahi configuration of '.local' is interfering

Comment 1 Tomas Mraz 2016-12-14 09:15:36 UTC

No, gnutls is not the common component at all.

Name resolution is done by glibc although the failure can be elsewhere.

Comment 2 Florian Weimer 2016-12-14 09:37:37 UTC

Do you use nscd?

Comment 3 Robert 2016-12-14 16:18:00 UTC

Until just recently, I had no idea nscd existed; but from what little I can tell.... yes?

$ rpm -qa | grep -i nscd
nscd-2.23.1-11.fc24.x86_64

$ ps auxw | grep nscd
nscd      1546  0.0  0.0 1276020 6484 ?        Ssl  Dec13   0:13 /usr/sbin/nscd
robert    5855  0.0  0.0  12628   900 pts/0    S+   10:14   0:00 grep --color=auto nscd

Comment 4 Florian Weimer 2016-12-14 16:38:11 UTC

This is a known issue.  myhostname (and probably mymachines) is incompatible with nscd because it turns non-cachable lookup failures into cachable lookup failures.

glibc does not control what other packages put into nsswitch.conf.  The default we ship in the package does not include it for a reason.

Comment 5 Robert 2016-12-14 17:30:03 UTC

I do not recall installing nscd, and trying to remove it threatens many packages that I actually do need (e.g. php, postgresql, xinetd). So I assume that you are referring to the nsswitch.conf entries when you say that it is not the default.

Having read the summaries of the myhostname & mymachines modules, I'm still not sure how the search-domain comes into play; and I'm also not sure why it would start acting up now (at recent Fedora 24 updates)....

However... you've *certainly* given me enough info to fix it on my machine.... so unless you have any further action or reminder to draw from this ticket, I'm content to have it closed... and I think I see a relevant ticket of this being discussed... Thanks!

Possibly relevant
bug 1284323
bug 1284325
bug 1374228

*** This bug has been marked as a duplicate of bug 1284323 ***

Comment 6 Robert 2017-01-02 15:53:37 UTC

Just a note to by future self, and anyone trying to work around this issue...

The following will remove the crazy-long-cached negative dns lookup failures, and let your dns work again:

> sudo nscd --invalidate=hosts