INTERNET namespace: who needs it?

[barmar@THINK.COM]

   Date: Sun, 15 Oct 89 05:32 EDT
   From: cjl@AI.MIT.EDU (Chris Lindblad)

     1.  NETI:ENSURE-DOMAIN-SERVICE-ENTRIES mistakenly tries to update the
	 INTERNET namespace for uninterned hosts with names like INTERNET|10.2.0.6
	 If you have an internet namespace, you just get these trash hosts in
	 your namespace, which is why this bug hadn't been discovered.
	 If you don't have an internet namespace, the function just blows out.

     2.  Old world loads that believe in the existence of the INTERNET namespace
	 do not react in a civilized manner when the namespace server tells them
	 there isn't an Internet namespace.  The just immediately ask the
	 namespace server about the internet namespace again.  Just a couple of 
	 hosts behaving this way can bog down the namespace server with their
	 continuous requests.  We worked around this with a real kludge.  In
	 (flavor:method :server-top-level neti:namespace server) we sleep for 
	 10 seconds every time we get an object-not-found-in-search-list error
	 for the namespace "INTERNET".  This keeps the namespace server from
	 bogging down.

There's a simple solution for both of these problems.  Instead of
deleting the INTERNET namespace completely, just get rid of all the
hosts in it.  That's what I did when I built a new world for our
namespace server.

   Incidentally, even though we have many large namespaces (though none as large
   as the internet namespace is), we don't use changes files because they
   invariably screw up.  Instead, we just let the namespace servers reload entire
   namespaces whenever they boot and get updates.  This has solved many of our
   namespace inconsistency problems.  This probably cant be done if you have an
   INTERNET namespace, because of its size.

Hmm, I've never had any problems with the changes file for our
namespace.

However, I *can* attest to the fact that the INTERNET namespace should
have a changes file if it has all the hosts in it.  I discovered that
we didn't when I made the above change, and that was the reason that
it had been taking 2.5 hours for the namespace server to boot.

I have noticed some problems when we switched from the namespace to
the domain servers.  The root domain servers generally time out on
requests for information about nonexistent domains.  The Symbolics
resolver marks a server as unavailable for fifteen minutes whenever it
does this.  Therefore, after some failing lookups, the next few
lookups may fail immediately, without even sending any domain queries,
because all the servers are believed to be down.  My solution has been
to use a site resolver.  I replaced all the Root Domain Server Address
fields with just the address of our site domain server (it's also our
gateway to the outside networks, so if it's down the Lispm wouldn't be
able to reach a real root server), and set
NETI:*DOMAIN-DEFAULT-RECURSION-REQUEST* to T.  I also set
NETI:*DOMAIN-SITE-RESOLVER-ERROR-IMPLIES-STANDALONE* to NIL, so that
the domain system won't be disabled when the site server is down.
Finally, the namespace entry for the site server specifies use of the
TCP DOMAIN protocol, not the UDP DOMAIN-SIMPLE protocol, so that the
Lispm won't time out while it's recursing.

As an alternate solution to the above problem, Symbolics has suggested
patching the function that computes the default service entries for
hosts gotten from the Root Domain Server Address list to use the TCP
protocol rather than the UDP protocol.  My solution has been working
for some time, so I haven't bothered trying this one myself.

						barmar