[HECnet] Cisco DECnet routers and NML

[Johnny Billquist]

Hi.

On 2020-05-05 03:46, Thomas DeBellis wrote:
> 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.

We might be... But maybe it is TOPS-20 who is... I'll comment below...

> 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.

I never suggested that CHAOS would be used for transport. But trying to 
make use of the CHAOS class in DNS is already where I suspect you might 
have trouble...

> 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.

It sounds like the DNS lookup hang is the problem, and that should be 
solved. There are no good reason why it should hang, actually.

But even more, it is strange if it hangs while looking up DECnet hosts, 
since the DECnet mapping between a host and an address in Phase IV is 
*always* local. There is no such thing as a networked name service. So 
either you have a translation locally, or it can fail immediately. There 
is never a reason for any kind of delay.

So if you are having problems using MAIL11, then there must be something 
seriously broken on the TOPD-20 side.

SMTP on the other would would obviously hang on DNS resolving, if there 
are any issues there, just as with telnet and finger. But then the 
solution would obviously not be to move DECnet addressing over to also 
use DNS. That would only make your problem worse, since DNS is the 
problem in the first place.

> 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.

But this is all for IP. This is not (or should not) be related to 
anything DECnet.

> 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.

Unless CHIVES can tell that it is a DECnet address, and then immediately 
do the translation or fail, then CHIVES would actually not be the right 
interface for resolving DECnet addresses.

It don't matter that TOPS-20 thinks it can speak SMTP over anything. 
Nothing else understands it. And I think you might also be confusing 
SMTP with the standard for internet text messages.
SMTP (originally RFC 821, latest being RFC 5321) deals with the basic 
protocol used between a client and a server. It contains the commands 
defined and the response codes to them, as well as which port it 
expected to be used.
Commands are things like:
HELO/EHLO
MAIL FROM:
RCPT TO:
DATA
VRFY
EXPN
HELP
QUIT

Which then have three digit response codes.

The "Standard for the format of ARPA internet text messages" (originally 
RFC 822, latest being RFC 5322), deals with the actual content of the 
mail, where you have all those mail header fields.

DECnet MAIL11 fills the same function as SMTP, but obviously different.

In DECnet, there is no corresponding part to the format of a text 
message. In MAIL11, the mail body is all there is, and it is always all 
assumed to be meant for the recipient human being.

There is a bit of additional meta-information available in MAIL11, which 
is carried in the connect message, which allows you to send arbitrary 
binary files as well, without confusing anyone. In the IP world, that is 
sortof solved through MIME, which is a very different mechanism.


But all of this is sortof besides the point. If the recipient is a 
DECnet address, it is clearly visible since mail addresses in DECnet 
(and MAIL11) are very different from addresses in IP using SMTP.

So any kind of resolving that needs to be done can easily tell in which 
domain the lookup should happen, and then proceed with the right kind of 
lookup from there.

And for the reference, addresses looks like this:

MAIL11: NODE::[NODE::]USER "Personal name"
SMTP: "Personal name" <user at host>


There can be any number of nodes in the list of nodes in a MAIL11 
address. But each ends with a double colon. And the last part, after the 
last double colon is the username on that last machine. Anything after a 
space is then assumed to be the person name of that user. Addresses are 
parsed left to right, and for each machine, you only look at the first 
node, which is the next hop for a mail. You do not need to specify 
explicit hops, but you can, and sometimes you want to. Because, the next 
hop address is processed on that local machine. So you can send to a 
host you don't even know which address it has, since you don't have to 
know that. All you need to know is the address of the next hop, and 
anything beyond that is then the responsibility of the next hop to 
figure out.

In SMTP, address is supposed to always be between <>, and is essentially 
processed right to left. While possible to give multiple explicit hops, 
that is generally discouraged, and often explicitly disabled in mail 
servers.

> 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.

Of course. And they could not be, since DNS do not handle DECnet, and 
DECnet do not use any name service at all.
It seems TOPS-20 is a bit broken and confused here. It should not ever 
try to look up a DECnet name using DNS. It should be able to tell that 
this is a DECnet address, and not even think about using DNS.

> 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".

Uh... No. CHAOS information is not a type record in DNS. It is a CLASS. 
If you ever looked inside a DNS zone file, you'd see a lot of things like:

FOO  IN A 1.2.3.4.

Well, if you have CHAOS, you'd see:

FOO C A 1234.

It's still a type A record, but with a class of CHAOS instead if INternet.

And CHAOS addresses are supposed to be 16 bit octal addresses as one number.

So yes, in a sense you could place a DECnet address in a CHAOS address, 
since they are both 16 bits. But you'd also need anything that deals 
with DNS to understand these CHAOS records and propagate them. When you 
start a DNS query, you might hit a local DNS server, or you might even 
go to some root. Queries might be recursively forwarded on your behalf. 
When you do the query, you need to tell what class and type you are 
looking for, which means that any DNS server involved needs to 
understand and deal with the CHAOS class. And that was my first 
objection. I wonder if anyone really have a DNS server today that even 
understands the CHAOS class. It is defined in the standard, but noone 
have even dreamt of testing or maintaining that for probably over 30 years.

And adding a new class, DECnet, would be even more complicated, since 
that would then require that all DNS servers and other code were made 
aware of this class, or they will just drop that information on the floor.

> 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).

So here is where I think TOPS-20 is mixing apples and oranges. It should 
not mix up DECnet and IP addresses and names to start with. They are two 
different things. Two different domains of names, which work in 
different ways, and are looked up in different ways.

It's rather broken, I think, of TOPS-20 to mix up the two.

> 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.

Like I said, I doubt you'll get this to work. :-)

> 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).

MAIL11 have lots of issues. But it's been the way it is for 40 years. We 
are not going to change it. There is plenty of software today that we 
don't even have the sources to.

You do SMTP over IP. You do MAIL11 over DECnet. It's as simple as that.

If you've seen an SMTP over DECnet implementation for VAX, that would be 
an interesting thing to hear about, but it won't change the basic 
premises. Out of curiosity, which known object did SMTP over DECnet use?

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol