home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / tcpip / domains / 780 < prev    next >
Encoding:
Internet Message Format  |  1992-12-26  |  1.9 KB
  1. Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!vixie
  2. From: vixie@pa.dec.com (Paul A Vixie)
  3. Newsgroups: comp.protocols.tcp-ip.domains
  4. Subject: Re: Why no MX records for .BITNET hosts?
  5. Date: 26 Dec 92 03:12:09
  6. Organization: DEC Network Software Lab
  7. Lines: 25
  8. Distribution: world
  9. Message-ID: <VIXIE.92Dec26031209@cognition.pa.dec.com>
  10. References: <NELSON.92Dec25002433@cheetah.clarkson.edu>
  11. NNTP-Posting-Host: cognition.pa.dec.com
  12. In-reply-to: nelson@sun.soe.clarkson.edu's message of 25 Dec 92 05:24:33 GMT
  13.  
  14. > So why not have MX records whose preference value is based on the number
  15. > of hops from the gateway machines?
  16.  
  17. Name service is not quite deterministic enough to create a fake domain
  18. unless you have a screening IP router between you and the core and are
  19. willing to run with a limited set of "forwarders".  Since the NIC has
  20. been historically unwilling to create real domains for .BITNET (and .UUCP
  21. for that matter), this would have to be done as a fake domain.
  22.  
  23. We do it here, of course :-).  uucp-gw-1.pa.dec.com's name server believes
  24. that it is primary for .BITNET; the data is pulled over from BITSRV once
  25. every second blue moon.  I bolt on a hack SOA and off it goes.  This
  26. greatly simplifies connecting to .BITNET hosts since many of them are
  27. dual-hosted (IP and BITNET) or have dual-hosted close neighbors -- it's
  28. nice to use these hack MX's to force the mail to a host or its close
  29. neighbor rather than gating all of it through a single relay.
  30.  
  31. If the new GSI NIC is willing to entertain a .BITNET domain, this could
  32. be made a lot easier on everyone.  Likewise a .UUCP domain.  I will 
  33. personally guarantee primary and secondary nameservers for each of them.
  34. --
  35. Paul Vixie, DEC Network Systems Lab    
  36. Palo Alto, California, USA             "Don't be a rebel, or a conformist;
  37. <vixie@pa.dec.com> decwrl!vixie        they're the same thing, anyway.  Find
  38. <paul@vix.com>     vixie!paul        your own path, and stay on it."  -me
  39.