[6184] in Athena Bugs
7.1H: Name resolution
daemon@ATHENA.MIT.EDU (Richard Basch)
Tue Oct 9 12:03:28 1990
Date: Tue, 9 Oct 90 12:02:49 -0400
To: bugs@ATHENA.MIT.EDU, network@MIT.EDU
Cc: mar@MIT.EDU
Cc: probe@MIT.EDU, roden@MIT.EDU, salemme@MIT.EDU
From: Richard Basch <probe@MIT.EDU>
Any name resolve will first try appending the domain to it before
querying and then fall back to trying without the domain suffix.
For instance, when a KDC request is made, the application looks up the
names of the kerberos servers in /etc/krb.conf and then tries to first
resolve:
kerberos.mit.edu.MIT.EDU
and then tries
kerberos.mit.edu
The lookup failures do not seem to be cached, so we are repeatedly
sending the nameserver lookup requests, and then falling back and then
looking up the entry for kerberos.mit.edu, which is usually in the named
cache.
I discovered this while trying to test network isolation for the Educom
setup, and finally had to resort to adding CNAMEs in the
/etc/named.local for various machines of the form:
$ORIGIN MIT.EDU
kerberos.mit.edu 99999999 IN CNAME kerberos
(Trying to CNAME the domain didn't work)
Personally, I believe the algorithm should be improved so that the
number of network packets is reduced. There is one case where this
helps, and that is for resolving names like:
sage.lcs
which would then be looked up as
sage.lcs.mit.edu
Unfortunately, some applications still don't like this, most notably
"telnet" (others, such as "hostinfo" work).
One suggestion for improving the algorithm (res_query.c) would be:
1) If the name has a ".", first try it as that name, and
then if that fails, then try appending the domain.
Think of it this way, I could currently ask for control
of the EDU.MIT.EDU domain and wreak havoc...
2) If the name doesn't have a "." simply skip to appending
the domain. There probably isn't much point to looking
up one without the domain, though you may consider it
a worthwile fallback.
I must say I was quite annoyed at this discovery, since this behavior
has changed since the last Educom conference, and at first I thought it
was a Kerberos bug, since that was what I was testing - timeouts to
fallback to the next Kerberos slave, and it was taking several minutes
to resolve the names!!!
-Richard
