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