why one shouldn't use relative hostnames
Maria Iano
bind-lists at iano.org
Fri Nov 12 19:55:44 UTC 2010
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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
> _______________________________________________
> 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