Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!rpi!nyser!cmx!jmwobus
From: jmwobus@cmx.npac.syr.edu (John Wobus)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: MXing the world (was RE:  New Host-Requirement RFCs)
Message-ID: <2029@cmx.npac.syr.edu>
Date: 10 Nov 89 20:34:33 GMT
References: <8911051717.AA10735@alw.nih.gov> <2441@csun.edu> <444@cpsolv.UUCP> <4395@itivax.iti.org>
Reply-To: jmwobus@cmx.npac.syr.edu (John Wobus)
Organization: Northeast Parallel Architectures Center, Syracuse NY
Lines: 55

In article <4395@itivax.iti.org> scs@itivax.iti.org (Steve Simmons) writes:
>cbcscmrs@ma.csun.edu (Mike Stump) writes:
>>I have one simple question, why don't we (The Internet side) put an MX record
>>into the root servers for the top-level domains .bitnet and maybe even .uucp?
>
>rhg@cpsolv.UUCP (Richard H. Gumpertz) writes:
>>I have always wondered why there were no .MX records for ".UUCP".  It sure
>>would make things easier for the sites that are in the "official" UUCP maps to
>>interact with the Internet world.  Any reason not to implement it?  I suspect
>>that many of the major backbone sites already have the maps in place, so it
>>probably wouldn't cost much in time or resources.
>
>How do you differentiate between the 'right' .uucp site for your mail?
>The MX records will come to you in preference order, not uucp connectivity
>order for the site you want.  Since the MX record causes the mail to be
>delivered to the host listed in the record, all *.uucp mail would go to
>the *same* host for uucp handling.  I dunno anybody willing to handle that!
>-- 
>Steve Simmons	scs@iti.org   Industrial Technology Institute
>	"Batches?  We don't need no steenking batches."

It would be neat if mail software could automatically find the nearest
public gateway to BITNET.  The DNS doesn't doesn't deal with concepts
like "nearest", but IP routing tables do.  In the past, I've dreamed of
kludging together some method by which routing metrics route information
to the nearest gateway, but we can imagine what it would be like to open
an SMTP connection to some gateway and in the middle of transmitting the
message, have a "network shift" cause your data to start heading for
a different gateway!  However, one could imagine a system by which
a single packet uses the routing table to find the nearest gateway,
an answer from the gateway tells the sender what the gateway's
(normal) IP address is and then the SMTP session starts after that.

In more straightforward terms:
(1) Sender asks DNS for the IP address & gets an address which is
    being advertised by gateways in many places.
(2) Sender sends a single packet to that address to a service which
    returns its own real IP address.   
(3) Sender starts SMTP session.

Since this is a whole lot of changes, the real "first" question is:
are there enough similar needs to justify the trouble involved in
getting everyone to implement whatever is necessary?  One could 
imagine that files wanted by a lot of people could be dispensed from
a system of identical file servers throughout the Internet, each
holding the same files.  The root nameserver addresses could be
advertised that way.  Perhaps at the local level, nameservers
suitable for resolver use could be advertised that way.
Can anyone think of other uses?
The "second" question is: what is the least amount of changes
that could make something like this work (without "too" much
kludging).

John Wobus 
Syracuse University