Hi
/etc/hostname:
192.168.42.42 a2290.westend.com a2290
192.168.42.42 2290.westend.com 2290
/etc/resolv.conf:
search westend.com
nameserver 212.117.67.2
# hostname 2290
# hostname -f
2290
# hostname a2290
# hostname -f
a2290.westend.com
In the first case hostname seems to be not compliant with rfc1123 which
says:
"The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax."
bye,
-christian-
Please use "strace" and "ltrace". You can see that the FQDN is resolved by gethostbyname() when you use "hostname -f". BTW, /etc/hostname is not /etc/hosts. This file is not used by /bin/hostname. So I think this bug report is invalid. Please confirm. If you have no objection, I'll close it. Regards, -- gotom
Hello You digged up one old bug.. :) ^^^ should be /etc/hosts of course Yes, the question was more, is "hostname" supposed to take /etc/hosts into consideration (-> bug) or may it only use the DNS (-> no bug) if "/etc/nsswitch.conf" says "hosts: files dns". bye,
At Fri, 16 Jul 2004 17:06:12 +0200, Christian Hammers wrote: It's one of old treasures :) In that case, hostname command calls gethostbyname(3). Looking at this bug more. When we give hostnames to gethostbyname(3), it behaves as follows: N: numeric, A: alphabet (1) A+[NA]+ usual case. (2) N+ all hostname consists of numerical character. (3) N+[NA]*A+[NA]* first character is numeric, but other includes more than one alphabet characters. (1) and (3) is ok. So the question is: when we give numeric strings to gethostbyname(3) (non-dot form), should this be interpreted not as host-byte-order IP raw numeric address? The current glibc (2) is interpreted as IP raw numeric address. I don't know this is valid interpretation or not. please someone follow up it. Regards, -- gotom
I quote RFC 1123 Section 2.1 [1] in full:
<quote>
2.1 Host Names and Numbers
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
Host software MUST handle host names of up to 63 characters and
SHOULD handle host names of up to 255 characters.
Whenever a user inputs the identity of an Internet host, it SHOULD
be possible to enter either (1) a host domain name or (2) an IP
address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
the string syntactically for a dotted-decimal number before
looking it up in the Domain Name System.
DISCUSSION:
This last requirement is not intended to specify the complete
syntactic form for entering a dotted-decimal host number;
that is considered to be a user-interface issue. For
example, a dotted-decimal number must be enclosed within
"[ ]" brackets for SMTP mail (see Section 5.2.17). This
notation could be made universal within a host system,
simplifying the syntactic checking for a dotted-decimal
number.
If a dotted-decimal number can be entered without such
identifying delimiters, then a full syntactic check must be
made, because a segment of a host domain name is now allowed
to begin with a digit and could legally be entirely numeric
(see Section 6.1.2.4). However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
</quote>
In summary,
if (4==sscanf(user_input, "%d.%d.%d.%d", a,b,c,d)) {
// Its an dotted quad IP address, do further checks to
// make sure its valid, eg. if (a<256 && b<256 ...)
} else {
// Its a DNS name, and it should supposedly contain some
// alphabet character [a-z].
}
Its not entirely clear to me what this means if its not a FQDN. Eg,
what happens in the example, Debian bug #65041? Since hostname(1) is
getting a local hostname (short format), I guess it should accept any
alphanumeric character sequence (potentially multiple components,
separated by dots).
The only check needed for DNS names, then, is this:
If there are exactly 4 '.' characters in user_input, ensure that
the last component is not entirely numeric.
I don't actually understand where this condition comes from. Seems
bogus to me: who says 4 levels of DNS names can't all be numeric?
(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.
Hi, just a testimony that i spent several hours trying to figure out what was happening with the all-digits hostname, and the email server complaining about not having a fully qualified domain name. So yes, it still applies to latest version of glibc. Jérémy