Question/comment regarding RFC1123 hostnames

[Bob Braden <[e-mail]>]

Cullen,

I can't give you a very complete answer to your question without more
research, but I can tell you that the relaxation in RFC-1123 was, shall
we say, inspired by the 3com corporation, which wanted to use "3com.com"
as its domain.

I fear that some programs that accept domain names may take short cuts
in their tests to distinguish dotted decimal from a true domain name,
introducing additional ambiguity [I am guilty of having written some
code like that myself, mea culpa!].  I would say that strictly such
programs would not be RFC-1123 compliant.  However, while RFC-1123
provides standards for the software implementing the protocols, it does
NOT attempt to specify wise site management practices.  Using numerical
hostnames, or hostnames with other funny syntax, would seem to me
to be unwise site management, since the world is full of non-compliant
implementations.

I hope this is of some help.  I an sending a CC: to the mailing list of
people responsible for RFC-1123, in hopes some others may have more to
offer.

Bob Braden

----- Begin Included Message -----

From [e-mail] Wed Dec 22 19:18:47 1993
Date: Wed, 22 Dec 93 19:09 PST
From: Cullen Tollbom <[e-mail]>
Subject: Question/comment regarding RFC1123 hostnames
To: [e-mail]
X-Envelope-To: [e-mail]
X-Vms-To: IN%"[e-mail]"
Content-Length: 2687
X-Lines: 50

Robert Braden:

I have some staff at my site who want to use hostnames consisting of numeric
identifiers (excluding the domain name, of course).  As you might guess, I
haven't had much success with this.  Because of RFC1123, they insist it ought
to work.  I admit I did not know the details of RFC1123--I have been
administering our DNS/hostname space according to RFC1035.

On page 13, RFC1123 indicates that the syntax for the hostname has been
relaxed so that a leading digit is permitted in the hostname.  However,
this can lead to inconsistent behavior with application programs as well as
implementations of well known programs like telnet, ftp, ping, etc., depending
on the computer platform.

For example, I have one staffer at my site who wanted to name his system
"10".  He couldn't because 'ftp 10' doesn't do the same thing on all
implementations.  Some would try to connect to the host called "10" others
will try to connect to 0.0.0.10.  The application does work if the user also
types in the full domain name, but thats too much work, and inconsistent
with what the user expects (the application automatically appending the
default domain name if none is present).

Because many implementations also permit C-language hexadecimal notation
in dot-decimal addresses, a hostname of 0x, 0xab, 0xabcddcba, etc. also
satisfy RFC1123, but are not necessarily handled consistently by applications.
And why not?  It does appear ambiguous as to what is meant.  I've done some
testing, and another hostname form that gets "screwed up" on some platforms
is one consisting of digits with imbedded hyphens, e.g., 'telnet 1-1' produced
the same thing as 'telnet 0' on one host I tried.  I have a couple of
systems on site that completely reject any hostname beginning with a digit.
These obviously are not RFC1123 aware.

I realize that RFC1123 was written some time ago so I am wondering if
if you or other IETF members have had any other discussions/clarifications/
insights on the subject.  Are there any additional materials/RFCs I might
not be aware of that may superceed RFC1123?

One of the things we do at our site is to use an IP-smart (rule-based)
relational database to administer TCP/IP and DNS.  Currently it requires
hostnames to conform to RFC1035.  I suppose I could rewrite it to conform
to RFC1123, but also filter/deny known ambiguous or erroneously handled
hostnames forms.  In this way, existing applications are guaranteed to
resolve hostname specifications consistently and correctly.  I'd much
rather leave it with the relative simplicity of RFC1035, but it looks
like I may have to bow to demand.

Regards,

Cullen Tollbom
Pacific Northwest National Laboratory


----- End Included Message -----