Additionally a wildcard record in one of the the searched domains would
cause a false positive to be returned causing an outage to the
service/services. And if your not in control of the zone or the search
order it could be difficult to rectify.
-Stacey
On 11/11/2010 00:30, Kevin Darcy wrote:
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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
