This is host-name-resolution-under-1.0 in view mode; [Up]
Date: Sun 24-Sep-1989 19:30:41 From: Unknown Subject: host name resolution under 1.0 What am I doing wrong? I have a resolv.conf file: domain CS.CMU.EDU nameserver 128.2.w.x nameserver 128.2.y.z where 128.2.w.x is my primary nameserver (w.x stands for the last two parts of a real address) and 128.2.y.z is a nameserver which takes over when 128.2.w.x is down. Shouldn't it be possible to abbreviate names like F.WORD.CS.CMU.EDU as F.WORD given the above resolv.conf file? In fact, shouldn't it even be possible to abbreviate names like HARRISBURG.ANDREW.CMU.EDU as HARRISBURG.ANDREW given this resolv.conf (given of course that HARRISBURG.ANDREW.CS.CMU.EDU doesn't exist). Names like Q.CS.CMU.EDU you can abbreviate as Q, but it appears that if the abbreviation contains a dot, it is assumed to be a complete name. I'd like to avoid using a host table, but it looks like I'm going to have to use one if I want to use abbreviated names.
Date: Sun 25-Sep-1989 17:50:18 From: Unknown Subject: Re: host name resolution under 1.0 In article <6251@pt.cs.cmu.edu> eht@f.word.cs.cmu.edu (Eric Thayer) writes: >[extra material deleted] > Names like Q.CS.CMU.EDU >you can abbreviate as Q, but it appears that if the abbreviation contains >a dot, it is assumed to be a complete name. Eric has found one of the design restrictions of the name server resolver routines. Given an entry in /etc/resolv.conf: domain dept.university.edu If a hostname has a dot in it, the resolver will conclude that the user has entered a fully-qualified domain name. If no dot is present, then the resolver will append the domain name from /etc/resolv.conf. This seems to be a problem, but for performance reasons, it really needs to be done this way. If you try to resolv "x.y", the resolver would be required to make multiple queries with varying bits of the current host's domain appended. Most of these would result in an error result from the name server, because the resulting host name "x.y.dept" does not exist. Since "x.y.dept" is not local, the query would have to go to the root servers, only to be told that there is no top-level domain "dept". The process would be repeated with all the other permutations of "x.y" and "dept.university.edu". The root servers just don't have the capacity to handle that load. At SMU, I do this. Each machine has an official name, such as "csvax.seas.smu.edu", my current host. It also has an alias, "csvax.smu.edu". The /etc/resolv.conf file says "domain smu.edu". Thus, I can get to any campus machine with its one-word name, even though the domain name structure is four levels deep instead of three. Here's the nameserver files: csvax.seas.smu.edu. IN A 129.119.1.5 csvax.smu.edu. IN CNAME csvax.seas.smu.edu. Of course, this only works as long as all machines within the higher-level domain (smu.edu, in this case) have unique names. You can easily see, though, how this could be used in the case of a five-layer domain name system. David Hayes School of Engineering Southern Methodist University merlin@smu.edu uunet!smu!merlin "Argue for your limitation, and, sure enough, they're yours." - Richard Bach >From: eht@f.word.cs.cmu.edu (Eric Thayer)
Date: Sun 25-Sep-1989 20:34:00 From: Unknown Subject: Re: host name resolution under 1.0 In article <15940@pollux.UUCP> merlin@smu.UUCP (David Hayes) writes: > If you try to resolv "x.y", the resolver would be required to make multiple > queries with varying bits of the current host's domain appended. > Most of these would result in an error result from the name server, because > the resulting host name "x.y.dept" does not exist. I'd agree if, for example, your machine was V.W in X.Y.Z and you tried names V.W V.W.X V.W.X.Y V.W.X.Y.Z but, if you tried it inverted like V.W.X.Y.Z V.W.Y.Z V.W.Z V.W I assume that most names would be resolved rather quickly if the the names that are to be resolved, by in large, are in a subdomain of the domain in /etc/resolv.conf. A problem arises when a fully qualified name is put in the system. However, if you treat all names as fully qualified (if they have a dot in them), then use the second scheme for resolution, maybe this would be worth the cost in extra nameserver requests.
Date: Sun 25-Sep-1989 21:00:20 From: Unknown Subject: Re: host name resolution under 1.0 In article <15940@pollux.UUCP> merlin@smu.UUCP (David Hayes) writes: >This seems to be a problem, but for performance reasons, it really >needs to be done this way. Not true. The latest UNIX resolver code does a very convenient and sensible thing; when appending domains to a name, it drops the least significant domain, until it reaches a domain one below the root, at which it punts. For example, I am in domain cso.uiuc.edu. If I utter, "zaphod.ncsa", the resolver tries: zaphod.ncsa.cso.uiuc.edu zaphod.ncsa.uiuc.edu (BINGO!) Whereas, if I say, "bogus.ncsa", it tries bogus.ncsa.cso.uiuc.edu bogus.ncsa.uiuc.edu (PUNT-it won't try bogus.ncsa.edu) This involves no queries to root servers, and has the effect that, for hosts in a common domain, I need only specify the domain part that differs from my own domain. This is appropriate behavior, and NeXT's release notes indicate that they understand that. When it will be fixed (1.1, anyone?) is another matter.
Date: Sun 17-Oct-1989 19:52:24 From: Unknown Subject: Re: host name resolution under 1.0 In article <135@next.com> king@next.UUCP (Peter King) writes: >In article <6251@pt.cs.cmu.edu> eht@f.word.cs.cmu.edu (Eric Thayer) writes: >> >>Shouldn't it be possible to abbreviate names like F.WORD.CS.CMU.EDU as >>F.WORD given the above resolv.conf file? > >This behavior is standard for the 4.3 BSD gethostbyname() routine that >uses the BIND system. > >Do you have any suggestions for a better scheme? > >Peter King >NeXT Systems Software Of course there is a better scheme and it has been available for several years now. It was distributed with named 4.8 and possibly with earlier versions, too. I am uncertain of the exact date of issue, but we have been using the scheme since mid 1987. Berkeley distributed the code to support it in the 4,3BSD Tahoe release. Here's the scheme: 1) If a host name ends in a period, no subsequent rules apply. 2) If the host name contains no periods at all, then it is considered a possible alias and is matched to entries of the file named in the environment's HOSTALIASES variable. 3) If the first two rules don't apply, the supplied host name is extended separately by the default domain name and each of the default's components that have at least two elements, separated by a period, and each extension is tested against the host data base. For example, the name "mace", used in the default domain "cc.purdue.edu", would be tested as "mace.cc.purdue.edu" and then as "mace.purdue.edu". 4) If all of the above fails, then the supplied name is tested without modification. The supporting code is located in res_init.c and res_query.c of the resolver library and in some definitions in the resolv.h include file. Vic Abell >From: carlson@mrcnext.cso.uiuc.edu
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.