[HECnet] Cisco DECnet routers and NML

Mon May 4 18:46:04 PDT 2020

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20200504/ba7617d3/attachment-0001.html>