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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
