jj@dcs.leeds.ac.uk (J Jackson) (05/16/91)
In experimenting with DNS (before dropping use of hosts files),
we came across differences in the way different software resolved names
that users had provided.
BIND (and derivations - most UN*Xes) build a search list of
progressively wider domains to successively append to the user
provided name. This gives a decent user interface where users only
need to specify enough 'local' part of the name - not the full
domainname of a service.
However some implementations do not provide such user friendly
procedures. e.g. FTP Inc's PC/TCP uses the algorithm that if the user
supplied name contains a '.' (period) it is used "as-is" in the DNS
resolution, otherwise a default domain is appended. (FTP Inc. support
staff don't think there is any need for change.)
Such 'simpler' (brain dead!) procedures may be ok in a site without
much sub-domaining, but for large sites users are forced to use fully
qualified domainnames for any service outside their local sub-domain.
Have others found this, and if so are you satisfied with the position?
I have found nothing specific in the Host Requirements or DNS RFC's.
Surely we should expect a standard appraoch to this?
=======================================================================
Jim Jackson Email :
School of Computer Studies UK - JANET : jj@uk.ac.leeds.dcs
Leeds University Internet : jj@dcs.leeds.ac.uk
Leeds LS2 9JT
UK Phone : +44 532 335451
=======================================================================
Opinions! What Opinions? I just wield the brush round here.romkey@asylum.asylum.sf.ca.us (John Romkey) (05/17/91)
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. For instance, if I'm using the name LEEDS.AC.UK, and I'm inside MIT.EDU and MIT happens to have a LEEDS.AC.UK.MIT.EDU, I may never be able to contact the true LEEDS.AC.UK because my searching-DNS resolver decides that it should use the one inside MIT. And, if you say "Well, let's first try the top level domain interpretation rather than the path", then you'll have people who expect consistent behaviour and are rather shocked that when they type LEEDS.AC.UK they get the top level host, rather than LEEDS.AC.UK.MIT.EDU. Before you argue that nobody has name duplication like that, let me make two points: 1. Such names have existed. The Media Lab at MIT had several names like EDU.MIT.EDU for a while. 2. Nothing prevents them from existing; and if software you provide won't work with them, you WILL find sites that create them and them are functionally cursed because of an implementation decision you made. Basically, I agree that doing the searching is handy, but I think it's also brain damaged because it can lead to ambiguous cases and wall off the users from sections of the DNS so that they can no longer access chunks of the name space, because their searching algorithms find the incorrect ones first. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141
jbvb@FTP.COM (James B. Van Bokkelen) (05/18/91)
BIND (and derivations - most UN*Xes) build a search list of
progressively wider domains to successively append to the user
provided name...
However some implementations do not provide such user friendly
procedures. e.g. FTP Inc's PC/TCP uses the algorithm that if the user
supplied name contains a '.' (period) it is used "as-is" in the DNS
resolution, otherwise a default domain is appended. (FTP Inc. support
staff don't think there is any need for change.)
The Internet's experience with defaulting of partial domains is poor.
Perhaps my response to another person who recently asked for the same thing
will explain.
He said:
Machine "opus" in domain "eng.hou.xyz.com" wishes to establish a
connection with machine "milo" in "se.hou.xyz.com". Currently "opus"
user must use the fully qualified domain name in his command, i.e. tn
"milo.se.hou.xyz.com".
Under other TCP/IP implementations, i.e Lachmann, BSD, SUNOS, the
"opus" user only has to specify the portion of the name different
from his own domain, i.e. telnet "milo.se".
The problem is that domain names are hierarchical, and the Internet is big.
In an Internet environment, given your example, the best 'opus' can do is to
issue the following DNS queries to translate "milo.se":
milo.se.eng.hou.xyz.com fails at eng.hou.xyz.com
milo.se.hou.xyz.com works
However, the host 'opus' will never be able to reach a machine named "milo"
in the "se" domain (Sweden). This is perplexing to the user and frustrating
to explain if you're a Tech Support person. If you reverse the order of
search in order to allow access to all top-level domains, 'opus' will send:
milo.se goes to the DNS root & fails
milo.se.com goes to the DNS root & fails
milo.se.xyz.com goes to xyz root & fails
milo.se.hou.xyz.com goes to hou.xyz.com, works.
Two failed queries to the DNS root for most lookups is a major price to pay,
and the people who run the DNS root know where I live; I'd suffer severely
if I did this to them...
The Host Requirements RFCs (1123 in this case) address this issue (pp 83, 84),
and their view of "search lists" is that they should not be implemented unless
the host is capable of caching "negative responses", which DOS PC/TCP's TSR
kernel cannot do at this time. Such a cache might use a significant amount
of DOS memory; would you consider 8Kb or 16Kb a reasonable price to pay for
this feature?
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901demel@TUNAMEA.TUWIEN.AC.AT (Johannes Demel) (05/19/91)
I understand that the automatic generation of a domain search list may
not be unique and results in domains which cannot be reached simply.
(at least some implementations of the automatic generation use a trailing
dot to escape from the autmatic generation which solved the problem of
uniqueness, but it is not very userfriendly and it is no solution for
sendmail).
An the other hand the implementationin PC/TCP ist not userfriendly too.
At our University (domain tuwien.ac.at) we have part of the "private"
hosts in the departments and general purpose hosts with services for the
whole university located directly below the domain-name of the university.
But we have an increasing number of hosts (and PC's) which are located
within subdomains (i.e. one more level in the domain-name) assigned to
a department. This makes it easy to assign unique names for the whole
university (currently approx. 600 hosts) and allows the delegation of
management of the host-names. But this departments have to pay the
price to specify the full domain-name for general service hosts, which is
frustating.
But there is a well known method to solve the problem without getting
problems with the uniqueness and without requiring 8-16 kbytes of memory.
You can define a list of domains, which may be appended to a name given
which does not contain a dot. E.g. I may define the list
kom.tuwien.ac.at
tuwien.ac.at
An for the hostname abc the following names are checked:
abc.kom.tuwien.ac.at
abc.tuwien.ac.at
But if the specify the hostname abc.xy only
abc.xy
will be checked.
Something like this method is implemented in cisco-routers.
---
Johannes Demel demel@edvz.tuwien.ac.at demel@tunamea.tuwien.ac.at
Computing Center, Head of Communications Group
Technical University Vienna
Wiedner Hauptstrasse 8-10/020, A-1040 Wien, Austria
Tel: +43 (222) 58801-5829 Fax: +43 (222) 587421108071TCP@MSU.EDU (Doug Nelson) (05/19/91)
I fully understand the issues with using any sort of default domain or search list when given a dotted name, whether the default is used first or last, but I don't see where this logic applies to a single part name. In this case, with the usual longest to shortest search, I'm only going to search within my own institution. My solutions to this are: a) put CNAMEs for most of the general hosts and resources in our top-level domain (MSU.EDU), and b) point PC/TCP at IEN 116 service as a backup to domain name service, primarily to resolve single part host names that don't fit within the chosen domain. This works, in part, by automating the process which generates both the DNS table and the hosts file used by the IEN 116 server, ensuring that they remain in sync. Doug Nelson Michigan State University
sra@LCS.MIT.EDU (Rob Austein) (05/19/91)
Any further discussion on this topic should move to the mailing list Namedroppers@NIC.DDN.MIL (aka USENET comp.protocols.tcp-ip.domains). There are two issues here: 1) What kind of user interface will allow nicknames without accidently breaking things for users whose configuration, although legal, is not what the implementor had in mind? 2) What kind of user interface can the Internet support without spending too much of the available bandwidth on DNS queries? Previous messages from John Romkey and James Van Bokkelen gave some reasons why issue (1) is harder than it looks. Here's another: what should your resolver do if, in the process of following your search path, it hits a zone whose name servers are dead or inaccessible? The only safe thing to do is give up. This does not make users happy. Users who are not intimately familiar with the DNS find this particularly frustrating, since, from their point of view, whether a particular nickname works on a given day is completely unpredictable. Issue (2) is the reason for the comments in RFC 1123 about avoiding excessive root queries. As someone who has written a resolver that supports negative response caching, I think RFC 1123 allows lazy implementors to get away with murder by allowing the use of search paths with only the internal-dot detection algorithm. Ok, it protects the root and the top-level name servers, but there are some pretty huge non-leaf zones further down the tree (in the MIL subtree, for example), and the internal-dot algorithm doesn't help them at all. The only defense that the name servers of these zones have against being beaten into the ground by resolvers with lame search path implementations is to trust the administrators who own those resolvers not to put these name servers on search paths. Given the number of administrators who appear to believe that the readability of the Bind Operators Guide and the DNS RFCs could be improved by translating them all into ancient Sanskrit, I do not find this prospect reassuring. Also note that even negative response caching doesn't solve all the problems with search paths, because some name servers lie. If you cache negative responses, you believe those lies without trying again until the TTL expires, unless you impose an arbitrary ceiling on the TTLs in your negative response cache. The people at WSMR-SIMTEL20.ARMY.MIL are running my resolver code. The last time I checked, they had both search paths and negative response caching turned off, because they prefered a predictable universe to the convenience of search paths. I don't blame them. --Rob Austein
fab@md.interlink.com (Fred Bohle) (05/20/91)
The function of the search list for the DNS resolver is to let the user customize the higher level domains to search. Then the user can decide how to handle their unique naming usage. Secondly, if the user interface accepts a trailing dot, then the ambiguity of a partial name matching a fully-qualified name can be avoided. The name with the trailing dot is the fully-qualified name and needs no domain appended to it. Sounds to me like some more work needs to be done on that resolver code. ------------------------------------------------------------------------ Fred Bohle EMAIL: fab@leo.md.interlink.com Interlink Computer Sciences AT&T : 301-317-6600 9145 Guilford Road, Suite 175 Columbia, MD 21046 ------------------------------------------------------------------------
ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey) (05/21/91)
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
PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD) (05/21/91)
>Ahh, but most recursive searching resolver libraries can be forced not to >append successive domains by anchoring the name with a period. I'd put it the other way, viz: 1) The naive user types full x.y.z canonical names. 2) The more understanding may drop any level of his own host name with, typed on host myhost.dpt1.domain : x. giving x.dpt1.domain x.dtp2.. x.detp2.domain etc... 3) Nothing left to chance, no more name servers resolving single labels to local host name, nothing to do with the guru's 1035 dots convention etc... And I don't like the idea of the host file serving nicknames' purpose. Nicknames are often personal and the user should be able to maintain its own, mapping to full names and not addresses. A host file doesn't do that. Finally, it's sorry that making these kinds of subjects an implementation issue produces such various user interfaces.
enag@ifi.uio.no (Erik Naggum) (05/21/91)
Erik J. Murrey writes: | | Ahh, but most recursive searching resolver libraries can be forced | not to append successive domains by anchoring the name with a | period. This is illegal in mail addresses. </Erik> -- Erik Naggum Professional Programmer +47-2-836-863 Naggum Software Electronic Text <erik@naggum.no> 0118 OSLO, NORWAY Computer Communications <enag@ifi.uio.no>
ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey) (05/22/91)
In article <ENAG.91May21170512@gyda.ifi.uio.no>, enag@ifi.uio.no (Erik Naggum) writes: |> Erik J. Murrey writes: |> | |> | Ahh, but most recursive searching resolver libraries can be forced |> | not to append successive domains by anchoring the name with a |> | period. |> |> This is illegal in mail addresses. |> Arguably, MTA's shouldn't do any user-friendly heuristics on mail addresses at all. I would hope that the UA will form FQDN's to work with. Otherwise, you might run into the wildcard MX problems... --- Erik J. Murrey Vitalink Communications NOC ejm@NOC.Vitalink.COM ...!uunet!NOC.Vitalink.COM!ejm
kre@cs.mu.oz.au (Robert Elz) (05/22/91)
enag@ifi.uio.no (Erik Naggum) writes: >Erik J. Murrey writes: >| by anchoring the name with a >| period. >This is illegal in mail addresses. No its not - its illegal to transport such an address over SMTP, but its perfectly acceptable as a user interface - the mailer completes any abbreviations, and removes any trailing dots after that. kre
enag@ifi.uio.no (Erik Naggum) (05/22/91)
Erik Naggum (I) wrote: | | This [trailing dot in domain name] is illegal in mail addresses. I've been alerted to the precise meaning of "illegal", and would like to change it to "invalid" or "non-conformant", or "violates syntax" or something like that. There is no Internet Police, Court System, etc... Robert Elz writes: | | No its not - its illegal to transport such an address over SMTP, | but its perfectly acceptable as a user interface - the mailer | completes any abbreviations, and removes any trailing dots | after that. I didn't think we talked about user interfaces. I don't think I'd want to use a mailer which had that much "intelligence", but that's my opinion. </Erik> -- Erik Naggum Professional Programmer +47-2-836-863 Naggum Software Electronic Text <ERIK@NAGGUM.NO> 0118 OSLO, NORWAY Computer Communications <enag@ifi.uio.no>
kre@cs.mu.oz.au (Robert Elz) (05/23/91)
enag@ifi.uio.no (Erik Naggum) writes: >I've been alerted to the precise meaning of "illegal", OK, I will avoid using that too, though I really don't see the need to be that pedantic, I think we all know what is meant. >I didn't think we talked about user interfaces. I think that's exactly what we've been talking about - what names the users can use in various applications to refer to various hosts. >I don't think I'd want to use a mailer which had that much "intelligence", >but that's my opinion. Basically, to satisfy user expectations, you want the same names to work for all applications, if you can telnet to x.y and have it reach some particular host, you want ftp to x.y in the same environment to reach exactly the same place, and what's more, mail to x.y to do the same (allowing for MX records that may direct mail to a particular host for delivery, but the overall effect is the same). If you don't want your mail user agent completing partial domain names for you, then logically you also don't want your telnet client doing it either, or your ftp client, or ... and you just use fully qualified names all the time. That's OK, if that's what you want, and the question of how abbreviated names should work will be irrelevant to you. It will still be relevant to lots of other people though. kre
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (05/25/91)
> BIND (and derivations - most UN*Xes) build a search list of > progressively wider domains to successively append to the user > provided name... >The Internet's experience with defaulting of partial domains is poor. >Perhaps my response to another person who recently asked for the same thing >will explain. > >The Host Requirements RFCs (1123 in this case) address this issue (pp 83, 84), >and their view of "search lists" is that they should not be implemented unless I don't think "domain guessing" should be done at all. It causes problems with getting the wrong host, with uucp addresses, with users switching machines ("why does this address work in this window and not the other?" or "why can't so and so reach me? I gave them my address that works for others.") and with name server load. Make people specify the full address all the time and give them a keyboard macro or alias where typing the extra characters is a problem. -- Jon Zeeff (NIC handle JZ) zeeff@console.ais.org