Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!mips!pacbell.com!iggy.GW.Vitalink.COM!riscit.NOC.Vitalink.COM!ejm
From: ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey)
Newsgroups: comp.protocols.tcp-ip
Subject: re: name handling in DNS resolvers
Message-ID: <1991May20.194934.9282@iggy.GW.Vitalink.COM>
Date: 20 May 91 19:49:34 GMT
References: <9105171533.AA01010@asylum.asylum.sf.ca.us>
Sender: usenet@iggy.GW.Vitalink.COM (USENET News Admin)
Organization: Vitalink Communications, Fremont, California
Lines: 39
Nntp-Posting-Host: riscit.noc.vitalink.com

In article <9105171533.AA01010@asylum.asylum.sf.ca.us>, romkey@asylum.asylum.sf.ca.us (John Romkey) writes:
|> As the person who designed the way DNS lookup works in PC/TCP, I'll
|> explain to you why it's done that way.
|> 
|> Suppose you do your domain name lookup by working your way up the
|> domain name. Your host's domain name is W.X.Y.Z. It's presented with
|> name A; so first it tries A.X.Y.Z, then it tries A.Y.Z, etc.
|> 
|> Or, perhaps you present it with A.B and it tries A.B, A.B.Z, A.B.Y.Z.
|> 
|> There are other searches it could do, too.
|> 
|> In any of these cases, the user can have the name resolve into a
|> system that's not the one they expected, and then have no way to
|> specify that name. By the principle of least astonishment, you
|> shouldn't allow that to happen.
|> 


Ahh, but most recursive searching resolver libraries can be forced not to
append successive domains by anchoring the name with a period.

Take an example:  Suppose I'm in a subdomain "com.mit.edu" with a host "x"
Now suppose I try to telnet to "x.com":

$ telnet x.com

I get x.com.mit.edu, which is probably what I don't want.  So I use:

$ telnet x.com.   <-- note the anchor

And I get exactly what I wanted.... x.com

This is user friendly.

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm