why one shouldn't use relative hostnames
Stacey Jonathan Marshall
stacey.marshall at oracle.com
Thu Nov 11 13:40:58 UTC 2010
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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
More information about the bind-users
mailing list