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
No, gnutls is not the common component at all. Name resolution is done by glibc although the failure can be elsewhere.
Do you use nscd?
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
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.
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 ***
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