Resolve single word names?

[Kevin Darcy]

Barry Margolin wrote:
> In article <e9eh8p$2443$1 at sf1.isc.org>,
>  "Jim McAtee" <jmcatee at mediaodyssey.com> wrote:
>
>   
>> Can I run BIND on a on my home network to resolve names consisting of a 
>> single word?  If so, how do I go about doing this?  I can't always use 
>> HOSTS files or WINS, as some devices on the network have no way to use 
>> either.
>>     
>
> The usual way to accomplish this is to configure the clients to use your 
> domain as their domain search list.  When they type unqualified names, 
> the domain will be appended.
>   
If your network is completely disconnected from any other network, and 
will *always* be that way, you could theoretically set up your own root 
zone and those single-label names could be root names. Be aware, 
however, that if your clients have any kind of domain suffix configured, 
that will be appended to the initial query *before* the root name is 
queried, therefore there is probably no saving of query traffic by doing 
things this way, as opposed to the domain search list Barry described.

There are a lot of downsides to the "root name" approach, especially if 
you ever plan to connect your network to any other network, e.g. the 
Internet. It's not very manageable to run your own "private" root zone 
and at the same time provide resolution of Internet names on your own 
network. It can be done, but it's messy, e.g. tracking every change to 
every TLD delegation and mirroring them in your own version of the root.

For enterprises, I wouldn't recommend _either_ of these approaches: 
instead, I'd recommend forming user habits early of using FQDNs for 
lookups *exclusively*, since from a DNS infrastructure standpoint, 
that's the most efficient lookup form, and doesn't run the risk of 
"accidental" resolution (e.g. "http://jupiter" connects you to 
jupiter.sub2.example.com instead of jupiter.sub1.example.com, as you 
expected, because sub2 happened to be ahead of sub1 in your suffix 
search list), which can lead to security vulnerabilities (to continue 
the example, imagine if the domain administrators of sub2.example.com 
are far less trusted than those of sub1.example.com and 
jupiter.sub2.example.com is actually a Trojan Horse version of 
jupiter.sub1.example.com, which steals people's login passwords for the 
site)

                                                                         
                        - Kevin