Bug 221583 - getnameinfo fails instead of returning IP address
getnameinfo fails instead of returning IP address
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2007-01-05 09:29 EST by Jeremy Faith
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-12 05:36:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test prog to call getnodeinfo (1.08 KB, text/x-csrc)
2007-01-05 09:29 EST, Jeremy Faith
no flags Details

  None (edit)
Description Jeremy Faith 2007-01-05 09:29:11 EST
Description of problem:
getnameinfo fails instead of returning IP address when looking up a hostname by
IP address.

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


How reproducible:
This happens when 
  a)The IP is not listed in /etc/hosts
  b)hosts enty in /etc/nsswitch.conf is as it is by default i.e.
      hosts:      files dns

Steps to Reproduce:
1. compile the attached program dnstst.c using
   gcc -odnstst dnstst.c
2. ./dnstst # i.e. any dummy ip address not listed in /etc/hosts file
Actual results:
[root@eowen dnstst]# ./dnstst
gethostbyaddr host(
getnameinfo: localhost: Success
Temporary failure in name resolution: Illegal seek

Expected results:
[jjf@jfaith ~/tmp/dnstst]$ dnstst
gethostbyaddr host(
getnameinfo namebuf(

Additional info:
On both FC2 and FC4 the getnameinfo function returns the IP address when it is
unable to find the hostname, as in expected results above.

The reason I noticed this problem is that if telnetd(telnet-server-0.17-37.rpm)
is installed and setup. Any attempt to telnet into the machine fails if the
client's IP address is not listed in /etc/hosts. 

The call to getnameinfo in the attached dnstst.c is based on the code used in
telnetd. rlogind fails in a similar way to telnetd.

If the nsswitch.conf file is changed to:-
  hosts: files
getnameinfo works as expected.

But nsswitch.conf on FC4 uses 'hosts: files dns' and getnameinfo works ok.
So this seems to be a change in the way getnameinfo works which causes various
programs to fail.
Comment 1 Jeremy Faith 2007-01-05 09:29:11 EST
Created attachment 144903 [details]
test prog to call getnodeinfo
Comment 2 Jakub Jelinek 2007-01-05 10:23:27 EST
Sorry, can't reproduce this.
gcc -o /tmp/221583{,.c}; rpm -q glibc; grep 10.1 /etc/hosts; grep ^hosts
/etc/nsswitch.conf; /tmp/221583
hosts:      files dns
gethostbyaddr host(
getnameinfo namebuf(
Perhaps misconfigured DNS (/etc/resolv.conf wrong or broken DNS server) on your
Comment 3 Jeremy Faith 2007-01-05 10:51:19 EST
Sorry you are correct if a nameserver is configured correctly it return the IP
address as expected.
But if /etc/resolv.conf does not exist the problem occurs.
This is different from glibc in FC2 and FC4 where if resolv.conf does not exist
the IP address is returned.

Also I think that if for some reason the nameserver is down it may be more
appropriate to use the IP address than to return the EAI_AGAIN error code unless
the NI_NAMEREQD flag is set in the getnameinfo call.
Comment 4 Jakub Jelinek 2007-01-05 11:05:26 EST
See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204122
Comment 5 Jeremy Faith 2007-01-05 11:27:01 EST
I have examined bug 204122 but I'm sorry but I still think this is a bug.

The manual page for getnameinfo states:-
              If set, then the numeric  form  of  the  hostname  is  returned.
              (When  not  set,  this will still happen in case the node's name
              cannot be looked up.)
If there is no /etc/resolv.conf file I think the numeric form should be returned.

The only case where this would be inappropriate is if the NI_NAMEREQD flag is
set. In which case it is appropriate for the EAI_AGAIN or maybe EAI_NONAME error
to occur
Comment 6 Jakub Jelinek 2007-01-05 13:17:14 EST
nsswitch.conf containing hosts: ... dns and missing resolv.conf is an admin
error, either you should remove dns from nsswitch.conf, or supply a valid
resolv.conf.  The missing resolv.conf is the same as resolv.conf containing no
nameserver lines and that causes libresolv to return TRY_AGAIN, the same as if
a DNS is unreachable.  For that EAI_AGAIN is the correct answer, instead of
silently pretending DNS replied, but said there is no DNS entry for that IP
Comment 7 Jeremy Faith 2007-01-06 19:29:08 EST
I think that for the EAI_AGAIN or EAI_NONAME errors to be returned the
NI_NAMEREQD flag must be set in the call to getnameinfo.

Snippets from the getnameinfo manual page describing the 'flags' argument:-
    If set, then the numeric  form  of  the  hostname  is  returned.
    (When  not  set,  this will still happen in case the node’s name
    cannot be looked up.)

    If set, then a error is  returned  if  the  hostname  cannot  be
    looked up.

In the 'RETURN VALUE' section the manual page for getnaminfo states:-
    The name could not be resolved at this time. Try again later.

    The  name  does  not  resolve  for  the   supplied   parameters.
    NI_NAMEREQD  is  set  and  the host’s name cannot be located, or
    neither hostname nor service name were requested.

Clearly the manual page is explicit that EAI_NONAME should only be returned when
NI_NAMEREQD is set. But the section describing the NI_NUMERICHOST flag indicates
that the numeric form of the hostname will be returned when the hostname cannot
be looked up, so I think is is also the case that the EAI_AGAIN error should
ONLY occur if the NI_NAMEREQD flag is set.

The bugfix for bug 204122 which changed getnameinfo to return EAI_AGAIN instead
of EAI_NONAME under certain circumstances failed to recognise that EAI_NONAME
should only be returned if the NI_NAMEREQD flag is set.

Given that bug 204122 related to postfix I have checked the postfix code and in
the src/util/myaddrinfo.c file there is a call to getnameinfo that uses the

I think that the bugfix is correct to return EAI_AGAIN rather than EAI_NONAME
under the conditions in question. But ONLY if the NI_NAMEREQD flag is set.

In other words if NI_NAMEREQD is NOT set and the hostname cannot be determined
for ANY reason the numeric form of the address should be returned.
Comment 8 Jakub Jelinek 2007-01-12 05:36:14 EST
We need to agree to disagree.
says quite clearly that EAI_NONAME shouldn't be returned if 
NI_NAMEREQD is not set and one of nodename and servname is not NULL.
But EAI_AGAIN can be returned any time, it tells the caller that if he tries
later, it might resolve to a name.
Comment 9 Jeremy Faith 2007-01-12 06:18:44 EST
If you are certain that the EAI_AGAIN error should be returned even when
NI_NAMEREQD is NOT set then it will be necessary to fix every program that calls
getnameinfo without the NI_NAMEREQD flag and that currently does not handle

Many programs that call getnameinfo without NI_NAMEREQD seem to abort if an
error is returned as the only errors they expect are fairly terminal.

Probably the simplest fix is to add code to convert the IP address to a string
and store it in the host variable when EAI_AGAIN is returned as this was the
previous behaviour of these programs.

It will be necessary to patch at least telnetd and rlogind as I know both of
these have the problem.

I do not have access to a fully expanded source code repository so I cannot
easily search all programs for getnameinfo calls without the NI_NAMEREQD flag.
Are you able to do this?

Should I raise bugs against telnetd and rloingd?

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