> -----Original Message-----
> From: Patrick Thrapp
>
>  "Tom Emerson" <[log in to unmask]> wrote in message
> >
> > Are you actually running BIND on the 3000?
>
> No.  I was under the impression I didn't have to to use
> sendmail for sending emails out.

[I think you meant "DNS for sending mail out..."; OTOH, you don't have to
use Sendmail either -- just code appropriate TCP/IP "socket" based logic to
TALK to an e-mail server on port 25 on the DESTINATION machine.  Since that
is what sendmail does when the "target" is anything other than itself, there
isn't much need in re-inventing the wheel...]  Sendmail DOES need access to
a legitimate DNS since it does the actual "lookup" of the target e-mail
system to actually send a message.  You may not need this, however, if you
configure sendmail to use a particular host as a "relay" [usually your ISP's
outbound host] -- look into the "smart host/hub" configuration options.

> > This implies that the DNS server isn't configured or running on the
> 3000 --
[...]

The configuration you had in your previous message had RESLVCNF pointing (by
number) to your own HP -- this file needs to point to the actual SERVER
(usually your ISP, although if your DSL firewall/router hands out dynamic
IP's, it often acts as a "caching DNS server", meaning it will tell the
clients on the INSIDE of the network that it is the DNS machine; any
requests that come in are bounced off of the "real" DNS at your ISP, and the
results are "cached" for any subsequent requests that may occur within the
next xxx minutes.)
>
> I can ping my ISP from my pc.  I can ping my HP from my pc only by IP
> address.  Not by its DNS name.  Using ping -a xxx.xxx.xxx.xxx
> does not show
> any hostname.  I thought that if there are active lines in
> RESLVCNF.NET.SYS
> that HOSTS.NET.SYS is not used.

Look also into NSSWITCH -- this is a program that helps decide if the HOSTS
file should be checked before going to the actual DNS server.  In any case,
I was talking about not using a "hosts" file on a PC within your network,
not the 3000's "HOSTS.NET.SYS" file.

> > If your DNS services are handled externally [at your ISP,
> for example],
> have
> > they received the correct "A" record information?
>
> So maybe Verizon needs to know about hp3000.cfsinc.com, my HP3000?

BINGO!

> I wondered about this.  I was thinking that the entries inside
> RESLVCND.NET.SYS were "A" entries.  Here is where my network
> knowledge is very lacking.  Or does this file need some of the
> static IPs my ISP gave me to configure my DSL router?

You're catching on -- "resolve.conf" [the "unix" name of this file] points
to generic DNS servers, usually provided by your ISP.  IF you run your OWN
server [usually the case if you have your own actual "domain"], then you
typically set the "primary" server [the first one listed] as YOUR DNS
machine, the "second" address will most likely be either your secondary DNS
machine [most registrar's require you to have two machines, or at the very
least, two independant IP addresses] -OR- your ISP's DNS [then again, this
is often your "secondary" DNS anyway, but your ISP may charge a hefty fee
for the "service" of updating a simple text file every now and then], and
the third (and last) server configured is either your ISP's (secondary)
server OR a completely different server (such as a competing ISP's server...
;) )

At your ISP, THEIR DNS points to either a "parent" DNS [if your "ISP" is a
third party] or one of the "primary" DNS's [the "root of all DNS's"].  All
of these DNS machines maintain a database of subordinate servers -- for
instance, the "root" server maintains a list of the ".com", ".org", ".gov",
".net", and so on "servers"; at this lower level, the ".com" server
maintains a list of the specific servers for each address -- microsoft.com,
hp.com, ibm.com, etc.  Each of these "specific" servers (and their
secondaries) maintain a list of machines internal to THAT particular
"domain" -- now we see listings for the actual www.microsoft.com,
msdn.microsoft.com, & msn.microsoft.com "machines".  When a PC or your HP
makes a "request", it asks one of the servers it has configured in the
"resolve.conf" file; if that server hasn't seen that address recently [i.e.,
if it isn't cached], it goes up the line and ask's it's "parent"; eventually
you reach a DNS machine that knows some or all of that address at which
point it either replies [because it knows the full address] or it refers
"down" the chain to the DNS for the domain.

To put that into a specific example, when you make a request to
"www.hp.com", for instance, your PC probably doesn't know the appropriate IP
address, so it goes to the primary DNS machine.  Presuming (for the moment)
that the machine is located at your ISP, it is a "fairly safe bet" that your
ISP "knows" the address of the "hp.com" DNS machine, and only a 50-50 chance
that it "knows" the actual address of www.hp.com -- for the sake of
argument, let's say it doesn't know -- it relays your request to the .hp.com
server which DOES know where www.hp.com resides [at least, it BETTER know --
that's it's JOB!]  As the address is passed back, the DNS at your ISP notes
the "time to live" value associated with the address and arranges to
"remember" that address for NO MORE than that amount of time [expressed in
seconds, BTW].  Your own PC should also "remember" that address for the
"time-to-live" value, but since that is often set for "24 hours" and most
people turn off or reboot their machines more often than that, the NEXT
request that gets to your ISP [within the TTL timeframe] gets the value that
was "remembered" by that DNS machine

[wow, this response got longer than I expected -- I hope it helps clear the
issue rather than confuse :) if not, I've got a few more paragraphs to throw
your way...]

Notice also I said it was a "fairly safe bet" that your ISP knows the
address of the .hp.com DNS machine -- after all, "hp.com" is a fairly active
"domain".  If you make a request for www.rarely_used_server.net (such as a
server you run "from home") it is very likely that your ISP does NOT know
the address of the DNS machine for the ".rarely_used_server.net" domain.
Either way, if you hit things at "just the right moment", (i.e., after the
TTL value for .hp.com has expired and before anyone else makes a similar
request), your ISP has to check with the .com DNS machine.  Taking this a
step further, if you hit THAT machine at "just the right time", you will end
up bumping the request all the way to the "." DNS machine -- the overall
"root" machine!  The longest chain of events is:

  your PC
  -> local DNS
     : target_domain not found
     : target_domain's TLD (top level domain -- .com, .net. etc) not found
  -> ISP's DNS
     : target_domain not found
     : target_domain's TLD not found
  -> "root" DNS (".")
     : finds TLD for target_domain
       [note: "root" doesn't cache -- unique requests shouldn't arrive here
often enough to be "remembered"]
  -> target_domain's TLD DNS
     : finds target_domain's DNS
       [The TLD DNS doesn't cache either -- it is busy enough as it is!]
  -> target_domain's DNS
     : finds specific address
  <- back to your PC [caching the results at your ISP and local server along
the way...]

As you can see, your ISP has to maintain a fairly robust [caching] server
since overall their "clients" will request millions of websites, but the
number of "unique" sites may be only a few thousand.  The "TLD" servers also
have to be very robust, but the emphasis is on lookup speed rather than
caching -- even though only the first "unique" request from each of the
ISP's actually gets to the TLD server, the TLD server has to scan a complete
list of ALL the subordinate servers within that "TLD" to find the specific
DNS for the request.

Tom

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *