Thank you both and Kevin I for one would really appreciate if you
would compose that web page and put it out there!
On Nov 11, 2010, at 8:40 AM, Stacey Jonathan Marshall wrote:
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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
