It seems to me that gotom's analysis is correct: gethostbyname interprets an all-numeric-no-dots argument string as an IP address; see (libc.info.gz)Abstract Host Addresses for details. What this ultimately means is that gethostbyname cannot resolve an all-numeric hostname into a fully qualified domain name, since it never does the name lookup if it detects an all-numeric IP address.
It is arguable that the formats of IP addresses that gethostbyname supports are rare enough that they don't matter and we could rip out support for them. However, it is also arguable that an all-numeric hostname is rare enough that there is no point in breaking things that use the rare formats just so hostnames can be all-digits. We can't support both all-numeric hostnames and the no-dots notation for an IP address at the same time. The gethostbyname interface does not allow us to choose on a case by case basis which we prefer. Therefore we must choose. I suspect that all-numeric hostnames should have priority, for three reasons: 1) they are probably more common than uses of no-dots IP numbers and thus we minimize user surprises; 2) RFC 1123 says it MUST be supported; and 3) no-dots IP numbers can always be converted to dotted-quad IP numbers. I propose that we (Debian) modify gethostbyname so that it does not interpret an all-numeric string as an IP number, although consultation with glibc upstream first might be good. Offhand, it would seem like adding a special-case test to nss/getXXbyYY.c or by changing nss/digits_dots.c would be the way to do this, though I haven't looked at how big repercussions changes to either of those would have. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]