RFC-952 (last sentence of point 1 under Assumptions) prohibits single-character host names and I have had experiences (over 7 years ago summer of 2002) where some services would refuse to work with single-character host names (because such names were not standards-compliant), but I have seen a number of single-character host names in use in the past few years. Are single-character host names now valid? (If so, what is the proper validation reference?)
edit (to consolidate some information from the answers): various aspects of DNS seem to be defined in several RFCs, including 1035, 1123, and 2181. From RFC-2181 section 11:
Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment. For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address.
[ ... ]
See also [RFC1123] section 6.1.3.5.
From RFC-1123 section 6.1.3.5:
The DNS defines domain name syntax very generally -- a
string of labels each containing up to 63 8-bit octets,
separated by dots, and with a maximum total of 255
octets. Particular applications of the DNS are
permitted to further constrain the syntax of the domain
names they use, although the DNS deployment has led to
some applications allowing more general names. In
particular, Section 2.1 of this document liberalizes
slightly the syntax of a legal Internet host name that
was defined in RFC-952 [DNS:4].
From RFC-1123 section 2.1:
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.
And finally, as originally referenced, from RFC-952:
1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period.
[ ... ]
Single character names or nicknames are not allowed.
It is from following this chain that I originally came to say that RFC-952 prohibits single-character host names.
You'd think they are valid because the root name-servers are all single-letter hosts (a.root-servers.net), and the DNS spec doesn't create a specific exception for them. The RFC in question is specifically for host-file format, not DNS. DNS was defined in a later RFC (RFC 1035 starts it). RFC 1123 (1989) states it clearly.
So, single-letter host-names are valid in DNS based systems, and have been since before spam was invented. Systems that do not are not RFC compliant, and may be mocked. Unless they don't use DNS at all and only use hosts files, at which point pity is a better choice.
As host names were around before anyone even thought about writing an RFC about them I can't see any reason single character host names should suddenly become "illegal". That particular RFC lost me when it stated
because an RFC is NOT a standard. Not even close.
Despite the foregoing, it must be noted that the RFC in question was created to apply to a relatively small group, namely the Department of Defense (presumably of the USA).
There is a difference between 'valid' and 'it works'. It is entirely possible that hostnames aren't considered valid if they are single characters (my earlier post not withstanding). However, quite a lot of systems do allow them. One major system, Microsoft's AD/DNS system, has a legacy reason for permitting single character names.
Old-school NetBIOS names are allowed to be 1 to 15 characters in length. This spec was developed independently of RFC952, it's based around a different file called lmhosts, so it works. The problem came when Microsoft moved off of NetBEUI (actually NBF, NetBIOS Frame Protocol) and onto TCP/IP (actually NBT), and Microsoft had to allow naming resolution over TCP/IP networks. MS elected to maintain NetBIOS style resolution with WINS servers, bypassing the need for RFC952 compliant hosts.
Then came Active Directory and its DNS dependencies. Dynamic DNS was the rule, so clients had to register their ComputerName (the first 15 characters of which is also their NetBIOS name) in the DNS domain. Since MS allows single-character NetBIOS names to register in DNS, this brought it into conflict with RFC952. They decided to code their systems to permit this, since this emulated how it always used to work in the WINS days.
BIND DNS also allows single character hostnames. But RFC2181 pretty much states flat out that applications need to vet their own data, not DNS any more. Which leaves us with a large population of devices and software for which single character host names are just fine, and a few outliers that are RFC952-strict that don't permit it.
I think that current hostnames are more dependent on the DNS specs since DNS is what most people will use inside a network or in the internet. Said that, three RFCs come to mind (1034 - concepts, 1035 - implementation and 2181 - clarifications about DNS).
Section 3 of RFC 1034 says:
And in Section 11 of RFC 2181 we have a clarification about naming each node of the address:
So, by the light of DNS specs, you can have a.domain.tld
As you've determined, RFC 1123 isn't completely clear on this length issue.
Section 2.1 does say:
Since this text effectively completely overrides the text from RFC 952, it should also be taken to imply that any length up to 255 characters is legal.
Unfortunately back in 1989 Internet Drafts didn't get the incredibly rigourous review that they get now, so the ambiguity was probably simply not spotted.