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