Bug 494403 - /etc/hosts not being consulted for resolution
/etc/hosts not being consulted for resolution
Status: CLOSED DUPLICATE of bug 507164
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
10
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-06 14:06 EDT by Bill Gradwohl
Modified: 2013-04-30 19:42 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-20 11:39:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
getaddrinfo program (1.64 KB, text/plain)
2009-06-21 06:36 EDT, David Woodhouse
no flags Details

  None (edit)
Description Bill Gradwohl 2009-04-06 14:06:33 EDT
Description of problem:
Adding entries to /etc/hosts does NOT result in being able to resolve those entries.

Version-Release number of selected component (if applicable):
F10

How reproducible:
Add an entry and use host, nslookup, etc to check it

Steps to Reproduce:
1.Add an entry in /etc/hosts
2.Use nslookup, host, etc
3.
  
Actual results:
root@billlaptop ~# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1		billlaptop.private.ycc billlaptop localhost.localdomain localhost
192.168.168.106 multimedia.private.ycc multimedia
::1		localhost6.localdomain6 localhost6
root@billlaptop ~# nslookup multimedia
Server:		190.4.6.194
Address:	190.4.6.194#53

** server can't find multimedia: NXDOMAIN

root@billlaptop ~# nslookup multimedia.private.ycc
Server:		190.4.6.194
Address:	190.4.6.194#53

** server can't find multimedia.private.ycc: NXDOMAIN

root@billlaptop ~# host multimedia
Host multimedia not found: 3(NXDOMAIN)
root@billlaptop ~# host multimedia.private.ycc
Host multimedia.private.ycc not found: 3(NXDOMAIN)


Expected results:
resolution.

Additional info:
Comment 1 Bill Gradwohl 2009-06-18 19:33:01 EDT
I filed this against F10 over 2 months ago, and now F11 has the same issue. 

As far as I can tell, the role of /etc/hosts hasn't changed, so entries should still resolve but they don't.

If I've missed something in the docs somewhere, please let me know where I've made my mistake.
Comment 2 Bill Gradwohl 2009-06-20 10:05:05 EDT
It would appear that some utilities are consulting /etc/hosts and some are not:

root@billlaptop ~# telnet multimedia
Trying 192.168.168.106...
telnet: connect to address 192.168.168.106: Connection refused

root@billlaptop ~# telnet multimedia.private.ycc
Trying 192.168.168.106...
telnet: connect to address 192.168.168.106: Connection refused

root@billlaptop ~# host multimedia
Host multimedia not found: 3(NXDOMAIN)

root@billlaptop ~# nslookup multimedia
Server:		190.4.52.142
Address:	190.4.52.142#53

** server can't find multimedia: NXDOMAIN

root@billlaptop ~# host multimedia.private.ycc
Host multimedia.private.ycc not found: 3(NXDOMAIN)

root@billlaptop ~# nslookup multimedia.private.ycc
Server:		190.4.52.142
Address:	190.4.52.142#53

** server can't find multimedia.private.ycc: NXDOMAIN

root@billlaptop ~# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.168.168 billlaptop billlaptop.private.ycc
192.168.168.106 multimedia multimedia.private.ycc
Comment 3 David Woodhouse 2009-06-20 11:39:59 EDT
This isn't an issue with the 0xFFFF software, surely?
Comment 4 Bill Gradwohl 2009-06-20 13:00:32 EDT
David - I have no idea what your comment means.

If telnet, ssh, and a few other utilities use /etc/hosts to resolve addresses while host and nslookup don't, then something is surely wrong.

How is this not a bug?
Comment 5 David Woodhouse 2009-06-21 06:33:29 EDT
You have filed your bug against the "0xFFFF" package.

This is the description of the "0xFFFF" package:
"The 'Open Free Fiasco Firmware Flasher' aka 0xFFFF utility implements
a free (GPL3) userspace handler for the NOLO bootloader and related
utilities for the Nokia Internet Tablets like flashing setting device
options, packing/unpacking FIASCO firmware format and more."

I think perhaps you should have filed the bug against a different package?

The 'host' and 'nslookup' programs are part of the bind-utils package. For future reference, you can tell this by running the command:
       rpm -qif /usr/bin/host
or     rpm -qif /usr/bin/nslookup

But 'host' and 'nslookup' are tools which specifically exist to perform _DNS_ lookups. It's clearly stated in the man pages, and even forms part of the _name_ of the 'nslookup' program. Why would you expect them to do anything other than what they are documented to do?

There is also a 'ypcat' program which looks up entries in NIS databases.
If you use ypcat to query the NIS host database, would you _also_ say it's a bug that it doesn't return results from /etc/hosts (or from DNS)?
Comment 6 David Woodhouse 2009-06-21 06:36:35 EDT
Created attachment 348783 [details]
getaddrinfo program

Perhaps you actually want a program like this, which is a _little_ bit like the 'host' and 'nslookup' programs, but isn't designed specifically to use _only_ DNS for its lookups. This one should give you results from /etc/hosts and anything else you have configured in NSS on your system.

(I try not to be too helpful to people who mis-file bugs against the 0xFFFF package, because there are just too many of them. But I'll make an exception in this case...)
Comment 7 Bill Gradwohl 2009-06-21 08:03:11 EDT
David - Now I understand your previous comment. I apparently misfiled this issue. The bug is real though. I'll refile it.

Sorry for the error I caused, and thank you for taking the time to straighten me out, and for the way you did it. I appreciate that.
Comment 8 David Woodhouse 2009-06-22 12:09:37 EDT
Although you said you would, you don't seem to have refiled this bug against bind. I'll do that for you now (by clicking 'edit' by the Component: header above, then choosing bind from the list).

I disagree that it's a bug though -- both 'host' and 'nslookup' are _clearly_ documented to _just_ look stuff up in DNS, not anywhere else. Just like 'ypcat' _only_ looks in YP, not anywhere else.

I already gave you a program which _does_ look stuff up according to the system NSS configuration.

But I'll let the owner of the bind package tell you that too, if you prefer...
Comment 9 Bill Gradwohl 2009-06-22 22:24:10 EDT
David - I did refile, and already got the bad news.

Thanks anyway.
You're a gentleman.
Comment 10 Adam Tkac 2009-06-23 06:36:39 EDT

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

Note You need to log in before you can comment on or make changes to this bug.