why one shouldn't use relative hostnames

[Kevin Darcy]

On 11/10/2010 1:19 PM, Maria Iano wrote:
> We are working with a software vendor whose software only works with relative hostnames - they say it can't cope with a fully-qualified domain name. They want us to make sure the necessary domain is in all clients' search lists. Does anyone have any good references for me to explanations of why this is a very bad thing. I would find quick access to thoughtful well-phrased arguments very useful right now.
>
I've looked for such a thing from time to time, with no success.

Maybe I need to compose something like that.

Main reasons for not using shortnames:
a) Security. The problem cited way back in RFC 1535 still exists, in a 
slightly different form, with respect to shortnames, i.e. they're 
ambiguous and can cause names to resolve unexpectedly, thus causing 
connections to be made to unexpected hosts, which might not be trusted. 
E.g. we have multiple DNS names with the first label of "mailroom", one 
could potentially connect to the wrong "mailroom" server, depending on 
the (somewhat arbitrary) ordering of one's searchlist. A less-trusted 
"mailroom" server could trojan the more-trusted one.
b) Capacity and performance (specifically, query latency). Each 
searchlist element magnifies query volume, and increases query latency 
for all queries which don't happen to resolve with the first element in 
the searchlist. Names which don't resolve at all (typos, obsolete 
references, etc.) exhaust the *entire* searchlist, which has maximum 
latency to the invoking application, and uses maximum 
nameservice-infrastructure, network, logging and/or server resources.
c) Undesired dependencies and co-ordination challenges. Shortname 
resolution depends on the precise configuration of searchlists, but in 
many organizations the DNS infrastructure experts are not in the same 
department as those who control the configuration of searchlists (which 
are often "client OS" experts rather than in the "server" or 
"networking" areas), so there can be co-ordination challenges between 
the departments. When using FQDNs, searchlists are unnecessary and 
therefore the dependencies and co-ordination challenges are minimized
d) Inconsistency between internal and Internet environments; 
future-proofing. Shortnames are, by and large, not used on the Internet, 
because of the foregoing reasons, writ large because of the sheer scale 
and diversity of the Internet and its DNS namespace. If shortnames are 
used on an internal network, there is an inconsistency between the the 
two environments, internal and Internet, which may cause confusion and 
interoperability challenges, should a particular function or subsystem 
be "out-hosted" and/or attached to an Internet-accessible "cloud" at 
some point in the future. Under this heading, it should be noted that 
some Internet-oriented technologies absolutely require FQDNs as part of 
their formal specification. To my knowledge, no formal specifications 
(other than WINS/NETBIOS perhaps) require shortnames. Therefore, to be 
most flexible and accommodating to changing technologies and 
environments, it is best to use the naming format -- FQDNs -- which is 
most likely to be compatible and interoperable going forward.

                                                                         
                                                                 - Kevin