Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!bellcore!jupiter!karn
From: karn@jupiter (Phil R. Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Revision of PC/IP scorecard
Message-ID: <17244@bellcore.bellcore.com>
Date: 20 Jul 89 03:52:37 GMT
References: <17218@bellcore.bellcore.com> <6112@watdcsu.waterloo.edu>
Sender: news@bellcore.bellcore.com
Reply-To: karn@jupiter.bellcore (Phil R. Karn)
Organization: Bell Communications Research, Inc
Lines: 27

>Unfortunately, the manual on flash.bellcore.com seems to be out of date;
>in particular, the hosts file has been replaced by something called
>"domain.txt", whose format doesn't seem to be defined in the manual.

As is usual with volunteer projects, the boring part of the job (the
documentation) trails the interesting part (the code) by quite a bit.
The domain.txt file is the cache of domain records maintained by
the resolver. They are in the standard domain database format, eg.,

sun.ka9q.ampr.org.	IN	A	128.96.160.1

(Note the trailing dot on the domain name.)

You need to seed domain.txt with all domain names referenced in your
autoexec.net file. However, if you have domain server(s) nearby, you can
specify it/them in one or more "domain addserver" commands. When this is
done, the responses from the server will be appended to domain.txt,
avoiding future queries to the name server for the same host.

The domain code uses linear search on this file, so it can be slow, and
I don't yet age out old entries. But the existing code has proven quite
adequate for most kinds of use. Occasionally I just edit out all but the
"bootstrap" entries in domain.txt and let them build up again. One of
these days I'll redo the domain resolver with a real database manager
(e.g., the recently released GNU dbm library).

Phil