Hi Johnny,
These are all great points, but I fear you and I are talking apples and
oranges.? Let me address the mail part first.
There is no intention in my part to use either the PUP or CHAOS
protocols for data transport for many reasons.? They are (or where)
local area only; experiments in broadband, with no routing.? I have no
hosts that speaks them; with the exception of ITS, I am unlikely to.?
The PANDA distribution doesn't appear to have the drivers and the
Digital one certainly wouldn't.? One or the other may not be compatible
with Tops-20's multi-net implementation.
So this is really about a minor enhancement to the Directory Name
Service.? Let me explain; the default PANDA distribution will
mysteriously hang when trying to resolve a NAT'ed TCP/IP host or DECnet
(and presumably for PUP, too).? This causes mail delivery to take far
longer than I or my few users care to wait as well as appear to hang the
usual suspects, TELNET and FINGER.? The problem is that these utilities
are all wired to use the HSTNAM module which uses CHIVES instead of
DEC's (incomplete GTHST%) resolver.
When trying to resolve a name to address, CHIVES will wait a long time
for a response from an authoritative DNS server.? So, you can hack
HSTNAM to partially prefer GTHST% (which I've done) and put the hosts in
SYSTEM:HOSTS.TXT, but this is not the best idea.? The correct thing to
do is either put the entries of your NAT'ed hosts in the DNS server or
have a local zone file.? The zone file is a common RFC specified format
which CHIVES and everything else will parse, but I've found the
documentation to be 'unfortunate'.? In any event, I put all my local
hosts in a ZONE file, so that part works.? Mostly.
However, when sending DECnet email, I noticed that network delivery
agent was hanging in a GTDOM%, which is the monitor interface to
CHIVES.? What?? Using CHIVES to resolve a DECnet address??? It's
actually the correct thing to do, almost.? Tops-20 has a very rich email
delivery service that will speak SMTP over anything, MAIL11 and whatever
BITNET wanted.? It handles also handles Unix formatted addresses and can
do mailing lists.
Early work on DNS was done in part at MIT, which had a number of 20's
(MIT-XX, MIT-EECS) and certain ideas were adopted into DNS from that
platform, notably the MX record, which is used for mail hosts and
relays.? So the mail system is using HSTNAM to determine whether there
are any relays for the host, which is a very sensible thing to do.? And
it hangs because none of the HECnet nodes are in a zone file.
Review of RFC's and CHIVES shows that DNS still has a record type for
CHAOS; no surprise given the above.? At the theoretical level, this can
be adopted to use DECnet area.node addresses.? You'd simply be adding an
additional record type; instead of 'C' (for CHAOS), 'D' for DECnet
suggests itself.? Building the zone file from your database is
straightforward; I'd just be asking you to send me some additional data
in the form of quoted switches for SETNOD, viz: /OWNER:"Thomas DeBellis".
Now, instead of hanging waiting for a HECnet node resolve which will
never come (or have the wrong IP based address), the right thing would
happen.? For now, what I've done is mutilate the mailing system to
determine whether the host is on DECnet and don't do the GTDOM% resolve
(because there will never be any host or MX records).? However, this
means that all of the benefits of MX are lost and routing has to be
handled by a fully knowledgeable host (in the form of mailing lists).
The call is basically an inter-process communication event to CHIVES.?
It wouldn't be going out to the Internet (or DECnet) for anything; just
hitting a zone file.? However, piggybacking DNS on DECnet doesn't look
to be that hard, either.? I probably wouldn't bother.? Properly
implemented, this allows a 20 to route mail between HECnet and the
Internet, but also to other DECnet's (say whatever those Italians are
doing).? You don't need to bridge the transports to get it right.
MAIL11 is good for what it is, but it has it's drawbacks which I need
not elaborate to you as well as other deficiencies that I've never
brought up.? You _always_ want to try SMTP first, if only for the better
error recovery.? There was an SMTP DECnet client for the VAX, I'm fairly
sure.? Also, incoming MAIL11 can be forwarded to other platforms (and
this was extensively done).? But that means that you have to use the
resolver, which means you hang if something isn't in the DNS or you go
with my hack (which probably would have horrified MRC).
My hope is to make all of this part of a distribution for hobbyist
Tops-20.? While he was alive, MRC took all my fixes to Galaxy into PANDA
as well as FTP and was waiting for my completed server.? I'd like to
return the favor and publish the 60 or so fixes that I've done since his
passing.
??? ??? ??? --T
------------------------------------------------------------------------
On 5/4/20 7:24 PM, Johnny Billquist wrote:
On 2020-05-05 00:29, Thomas DeBellis wrote:
Second, some issues with MAIL-11 and DECnet SMTP
on Tops-20 have
caused me to believe that one solution would be to expand the DNS
service (CHIVES) to handle A and MX records for DECnet.? That's not
actually that big a stretch; the DNS specification has 16 bit data
types for CHAOS, which would be trivially re-usable for Phase IV
DECnet. However, I'm finding the current documentation to be a chore
to wade through.? The source code incomplete in certain functionality.
I seriously doubt you'd ever get this to play. Not only do I think
that CHAOS, even though it technically exists, are tested or supported
by any name server today. I also can't really see how you think adding
DNS would solve any problems you might have with MAIL11.
You would only be able to use DNS over Internet, while any node on
HECnet will not be visible anywhere there, unless someone decides to
register a domain, and then somehow populate this domain with all the
information from HECnet, which then also needs to be maintained. But
only your machines would ever even try to go there then to find the
address of other machines.
And anyone externally would then have to address mails to this domain
in order for it to reach hosts on HECnet, but you'd have to have MX
records for each node pointing to some mail gateway or other. But
internally you would not want to make use of these MX records, since
on DECnet, you'll be directly talking to the end destination, unless
you have an explicit hop path in the mail address, in which case you
even less want to involve something like MX.
And also, anyone externally would not be trying to look for MX records
under the CHAOS class, but still under IN, which would then fail, as
the DECnet nodes would not have addresses in the IN class.
So it would be even more exclusively to your implementation only, and
not usable by anyone else.
Sorry for shooting this down, but this is about as (or even less)
useful than implementing SMTP under DECnet. You would be able to talk
to yourself, and nobody else.
> Assuming I get this figured out, what I would do is modify SETNOD to
> parse a fuller version of Johnny's database.? In addition to building
> the binary file for importation into Tops-20's DECnet node name hash
> table, it would also build a binary TBLUK% table for use by COMND%
> instead of .CMNOD and also a zone file that CHIVES could parse for
> the DNS records.