14

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.

Community
  • 1
Isaac
  • 534
  • 2
  • 11
  • 24

5 Answers5

11

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.

 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.

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.

Community
  • 1
sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
  • Okay, I'd read that in RFC-1123, but I interpreted it to mean that the specs I read in RFC-952 apply, except that a digit is also permissible as the first character (as you quoted, it does not alter the prohibition on single-character names). As to the root servers, I'd been told at some point that they were some kind of special exception to the rule. – Isaac Jul 20 '10 at 02:11
2

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

This RFC is the official specification

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).

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108
  • RFC by very definition is not a standard. "Request for Comments" doesn't exactly scream "standard" to anyone. Interesting that they got away with it in their own documents. – Mark Henderson Jul 20 '10 at 02:48
  • 1
    http://en.wikipedia.org/wiki/Domain_name_system#Internet_standards lists many RFCs that "define" the DNS protocol. RFC-1123 (as mentioned by sysadmin1138) is among those listed and it references RFC-952. It has been my experience that, while RFCs are requests, they become definitions when they are accepted. – Isaac Jul 20 '10 at 03:56
  • @Farseeker, I'm not saying it's the case here but I'm always surprised at the people, most of who should know better, who quote RFCs as if they are the ultimate authority on any particular subject. I'm pretty sure there's an RFC about it somewhere. ;) – John Gardeniers Jul 20 '10 at 03:58
  • A friend of mine used to say that RFC stands for "Read anf Follow Carefully", meaning that even don't being 'standards' they are pretty much the same. – coredump Jul 20 '10 at 05:46
  • 1
    Some RFCs actually are standards - RFCs 1034 and 1035 together, for example, comprise STD0013. The reason they're called "Requests for Comments" is historic, and in essence had to do with a bunch of low-grade postgrads back in the late '60s not wanting to tick off their superiors (I heard that in person straight from the author of RFC 1). – Alnitak Jul 20 '10 at 07:49
  • @Alnitak, regardless of which RFC(s) may have contributed to a standard, they are not part of that standard. If an RFC is accepted it becomes the basis for the first draft of a proposal for a standard. From there on there is no direct connection. The history explains why we have such an absurd name (RFC) for what is merely a suggestion or recommendation. – John Gardeniers Jul 20 '10 at 08:05
  • Single character host names *were* invalid at some point in the past and there *have been* major implemented in-production servers (e.g. mail transport) that would not work with single-character host names such as `a.domain.tld`. My question is when did they become valid and what is the proper reference as to what is a valid host name? – Isaac Jul 20 '10 at 15:00
  • @Isaac, to the best of my knowledge single character hostnames have never been invalid, except possibly for special case, such as that DoD RFC you referred to in your question. If you can reference a standards document that mentions it in the general case I'd be most interested. Failing that I must argue that, regardless of what some software may or may not have been written to deal with, single character names have always been legitimate, both pre and post Internet. – John Gardeniers Jul 20 '10 at 17:13
  • To the best of my research (e.g., http://www.dns.net/dnsrd/rfc/, http://www.zoneedit.com/doc/rfc/, http://technet.microsoft.com/en-us/library/cc958984.aspx), RFC-1123 is current and standard regarding host names. As I quoted in my edits to the question, it references RFC-952, so RFC-952 is *not* limited to the "special case" of the DoD. My question and argument thus far has pointed to specific standards and to direct experience. If you want to continue to argue that single-character names were always valid, please reference a standards document that contradicts those that I've cited. – Isaac Jul 20 '10 at 18:32
  • @Isaac, you have still not cited a standard. RFC-1123 may be current but it's still only an RFC. – John Gardeniers Jul 20 '10 at 21:36
  • The US DoD is hardly a "small group", as a population it surpasses many small countries. – kmarsh Jul 20 '10 at 21:55
  • @John, Per http://www.rfc-editor.org/info/rfc1123, RFC-1123 **is** a standard. And you have yet to cite any standard. – Isaac Jul 20 '10 at 23:00
  • 2
    @John I suggest your read RFC 2026. " A specification that reaches the status of Standard is assigned a number in the STD series while retaining its RFC number". I write IETF documents for my day job. – Alnitak Jul 21 '10 at 07:42
2

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.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
  • `There is a difference between 'valid' and 'it works'.` Ultimately, I think that's the most reasonable answer, though I very much appreciated all the discussion generated. The conclusion I'd draw is that one-character host names are still technically invalid, but work pretty much universally at this point. (Similarly, underscores are prohibited, but do work for the most part.) – Isaac Jul 23 '10 at 03:19
1

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:

The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). The domain system makes no distinctions between the uses of the interior nodes and leaves, and this memo uses the term "node" to refer to both.

Each node has a label, which is zero to 63 octets in length. Brother nodes may not have the same label, although the same label can be used for nodes which are not brothers. One label is reserved, and that is the null (i.e., zero length) label used for the root.

And in Section 11 of RFC 2181 we have a clarification about naming each node of the address:

The DNS itself places only one restriction on the particular labels
that can be used to identify resource records. That one restriction
relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators)

So, by the light of DNS specs, you can have a.domain.tld

Community
  • 1
coredump
  • 12,573
  • 2
  • 34
  • 53
  • From the next paragraph in Section 11 of RFC-2181: `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.` Basically, because a.domain.tld is valid in DNS does not make it a valid hostname. The end of Section 11 references Section 6.1.3.5 of RFC-1123, which cites Section 2.1 of itself and RFC-952, as discussed in sysadmin1138's answer. – Isaac Jul 20 '10 at 14:55
  • The citation on the end of section 6.1.3.5 talks about less constraints on the naming convention defined on 952. Also the 952 defines a DOD host table and I am not entirely convinced that it is more relevant than the DNS specs. – coredump Jul 20 '10 at 17:47
  • I think that the liberalization of constraints mentioned at the end of 6.1.3.5 refers only to allowing the first character to be a number--this is the only modification mentioned in section 2.1 of that same RFC (which is the section to which 6.1.3.5 refers). It is in that section 2.1 that the definition from RFC-952 is referenced as being the definition of a legal host name. – Isaac Jul 20 '10 at 19:28
  • Also check RFC 920 and 921 that treats of the migration from the old DARPA to domain names. – coredump Jul 20 '10 at 21:24
1

As you've determined, RFC 1123 isn't completely clear on this length issue.

Section 2.1 does say:

Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters

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.

Alnitak
  • 20,901
  • 3
  • 48
  • 81
  • 1
    But 2.1 also 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.` Isn't it reasonable to interpret this to mean that your quote does not completely override the text from RFC-952? – Isaac Jul 21 '10 at 11:02
  • It says that, but it's clearly wrong. RFC 1123 _also_ explicitly changes the permissible length of a hostname. – Alnitak Jul 21 '10 at 14:54