home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / tcpip / domains / 786 < prev    next >
Encoding:
Text File  |  1992-12-27  |  3.0 KB  |  59 lines
  1. Newsgroups: comp.protocols.tcp-ip.domains
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!dscs.arc.nasa.gov!medin
  3. From: medin@dscs.arc.nasa.gov (Milo S. Medin)
  4. Subject: Re: Why no MX records for .BITNET hosts?
  5. Message-ID: <1992Dec28.045444.3467@news.arc.nasa.gov>
  6. Sender: usenet@news.arc.nasa.gov
  7. Organization: NASA Science Internet Office
  8. References: <VIXIE.92Dec26031209@cognition.pa.dec.com> <DWELLS.92Dec27141205@fits.cv.nrao.edu> <VIXIE.92Dec27122627@cognition.pa.dec.com>
  9. Date: Mon, 28 Dec 1992 04:54:44 GMT
  10. Lines: 47
  11.  
  12. Well, we run the dnet.nasa.gov MX hack and associated forwarder.  We also
  13. have a similar hack for span.nasa.gov that also works.  I agree that it's
  14. a very convienent hack, but also agree that architecturally it's the wrong
  15. thing.  Many if not most of the DECNET systems on the NSI-DECNET (what
  16. SPAN was absorbed into) have IP connectivity as well as DECNET.  They
  17. maintain DECNET access to talk to DECNET only sites and support
  18. applications that depend on DECNET transport.
  19.  
  20. The reason *.dnet.nasa.gov is convienent is obvious; the reason it's 
  21. a kludge is because mail takes a suboptimal path for delivery to systems
  22. which are dual homed (IP and DECNET).  The mail relays for these fake
  23. domains pull a fair amount of load.  And the DECNET users have to manually
  24. route mail through the relays because DECNET mail doesn't support things
  25. like MX records (of course, it also doesn't support multiple names per
  26. node address or mail spooling as shipped either, so users aren't expecting
  27. much I guess).   
  28.  
  29. The right thing to do is to install individual MX records for the DECNET 
  30. nodes that have native IP support, and maybe for all nodes at a site
  31. through a local mail relay.  This would reduce the load on the "default"
  32. mail relays, and provide a more direct mail path as well.  This was the
  33. initial plan in fact when we turned this service on, but it's a pain
  34. to support since the MX records have to be manually configured, and 
  35. the poor DECNET only users now have to know what locally specific syntax they
  36. have to use for Internet relay.  This makes it difficult to write common
  37. user services documentation, etc...
  38.  
  39. Anyways, it's proven so popular that it's just easier to try and harden
  40. the mail relays so this works, and inform the users about the limits of
  41. this approach.  It also winds up using more DECNET bandwidth than 
  42. needed, but these days most if the DECNET rides over the same trunks 
  43. that the IP traffic does via multiprotocol routers, so I guess it's
  44. not that big a deal anyway.
  45.  
  46. The same may be true re: BITNET actually, since I gather most of the large
  47. BITNET sites get their trunking via the Internet anyway, using this
  48. RSCS over IP stuff.  I would expect the amount of BITNET traffic overall
  49. to be dropping off, similar to what's been happening to DECNET, as
  50. more hosts convert to native IP support (or the machines themselves are
  51. scrapped and sent to surplus - anyone want a few 780's cheap?  :-))..
  52.  
  53.                         Thanks,
  54.                            Milo
  55.  
  56. PS The above of course is not the official position of anyone, much 
  57. less the US Government, etc, etc...
  58.  
  59.