kurt@hi.unm.edu (Kurt Zeilenga) (08/25/88)
Paul Vixie states: >Either way, you need three things done: >(1) you need an NS record in the core servers >(2) you need an MX record in the server where your NS points to >(3) you need the machine named as your MX to be able to reach you on UUCP I would just like to point out that the name servers and mail exchangers need to be setup before authority is delegated from the root servers. I believe that the NIC actually requires that the name servers be operational before they will process your registration form. This being true (please correct me if I am wrong) implies that it is possible for you to setup a domain and when you go to register it someone has beaten you to it. However, I've never heard of this happening with Internet domains. What I have done in that past (I've setup up a few secondary domains) is to: 1) obtain primary and secondary servers 2) obtain MX'er if not directly attached to the Internet 3) pick appropriate domain name 4) setup and test name servers and MX'ing. 5) send registration form to NIC Note I did not suggest registering the domain in the UUCP maps. The maps already provide adequate mechanism for forwarding registered Internet domains (directly attached or not) and appearance in maps will only cause mail to be routed completely though UUCP instead of taking a "short-cut" across the Internet. For example, GURU.COM does NOT appear in the maps and UUCP sites deliver mail thru a UUCP-INTERNET gateway. .UNM.EDU, which does appear in the maps, gets its mail routed in via SLOW UUCP connections even though we are directly on Internet. I am attempting to get UNM to delete all meantion of UNM.EDU from the maps. Maybe there is a better way? Comments on this subject would be appreciated.
dsc@izimbra.CSS.GOV (where was george?) (08/26/88)
In article <23627@hi.unm.edu> kurt@hi.unm.edu (Kurt Zeilenga) writes: >maps already provide adequate mechanism for forwarding registered Internet >domains (directly attached or not) and appearance in maps will only >cause mail to be routed completely though UUCP instead of taking a >"short-cut" across the Internet. > >For example, GURU.COM does NOT appear in the maps and UUCP sites deliver >mail thru a UUCP-INTERNET gateway. .UNM.EDU, which does appear in the >maps, gets its mail routed in via SLOW UUCP connections even though we >are directly on Internet. I am attempting to get UNM to delete all ah, the old what's a poor internet host that handles pathalias output supposed to do problem? :-) on seismo & uunet, we have a shell script that removes all the paths for domains and fully qualified hosts out of the output of pathalias, except for those that we are the primary server for. (an aside ... we have been using `sed' for this filtering except recently on uunet this scheme failed because we are the primary for almost a hunderd domains now and we bumped into a hard coded limit on the number of patterns. clearly a better method is needed :-) i believe peter (that is honeyman from dwon!honey) has another scheme he uses to filter out domains & hosts reachable via smtp as do most of the other postmasters on machines in this situation. if you aren't using the pathalias database for routing of domains at all, then just keep the simple names and that should do the trick. dsc
vixie@decwrl.dec.com (Paul Vixie) (08/26/88)
They tell me I'm posting too much. Is the quality suffering?
In article <24782@uunet.UU.NET> dsc@izimbra.CSS.GOV (where was george?) writes:
# ah, the old what's a poor internet host that handles pathalias output
# supposed to do problem? :-) on seismo & uunet, we have a shell script
# that removes all the paths for domains and fully qualified hosts out of
# the output of pathalias, except for those that we are the primary
# server for.
That's one option. I do this in my IDA-style sendmail.cf by resolving to
SMTP if and only if an MX or A record is found with $[...$]. I search a
database of UUCP exceptions just prior to this, so people I have a local or
Telebit UUCP connection to are gone before $[...$] is run.
If $[...$] doesn't work, I check the pathalias database.
All in sendmail. No extra forks.
--
Paul Vixie
Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP
Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul
Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013