honey@doom.ifs.umich.edu (Peter Honeyman) (08/07/90)
Steve DeJarnett writes: >From: steve@qe2.paloalto.ibm.com (Steve DeJarnett) >... > Of course, then we get to the following problem. apple.sgi.com is a >FQDN. Great. Now the Rabid Rerouters pop up, and say "great, a FQDN very near >the end of the path (actually, at the end). Let's short-circuit to that." >BOING! If apple.sgi.com isn't Internet-connected, and doesn't have anyone >MX-ing for it, the mail bounces. Now, this is a worst-case analogy, but it >does happen. I used to be a proponent of Rabid Rerouting (when I was the one >modifying the sendmail.cf files on an Internet-connected machine). Now that >I sit with an address that looks like it's Internet-connected, but is only >connected to a corporate internal network (soon to be rectified with at least >an MX record, but that's beside the point), I see things in a different light. >I would love for Rabid Rerouting to work. However, until every workstation is >IP-reachable (or at least has a host MX-ing for it), this isn't going to work >(IMHO). according to ibm.com, qe2.paloalto.ibm.com is a non-existent domain. as david herron put it, your use of domains is very very very very wrong. your name server must recognize the names that you make, or people and other mailers that comprehend the domain name system are going to be very very very very upset with you. peter ps: i maintain that rerouting in the manner folks have been discussing is good practice. to illustrate, ^.*!([^!]+\\.)(arpa|edu|com|gov|mil|net|org|[a-z][a-z])(!.+)$ appears in code that runs here. the stuff not in parentheses -- dot star bang -- is given the heave ho. (sites not on the internet could map it to uunet.) in practice, this type of rerouting almost always works. my ua and mta header mungers do it all the time. ibm's horrible abuse has been a problem, but that's soon to be rectified, quote quote. as for semantics-based rerouting, my experience with pathparse, when i used it daily, was that it worked very well, but was a hassle to maintain. building a dbm file for the 50,000 edges in the usenet maps, takes too long. it's also not clear that you can entrust mail to a system that relies on the usenet maps being timely and accurate. so i have never run a rerouter from the mta -- although it can be semantically correct to do so! today, i run a right-to-left (so-called rabid) rerouter out of the ua. i view the modified address as a hint. sometimes i change it back. regarding arpatxt, the hosts.txt -> pathalias hack, a number of prominent mailer scientists toyed with this, even incorporating it into daily use. but weeding out conflicts between hosts.txt and the usenet maps is an all-consuming chore. (at last count there were over 400 entries in the "exceptions" list.) even so, i continue to use arpatxt here. i don't bother updating the hosts.txt file. the result is satisfactory -- it recognizes the equivalence of the uucp/FQDN names of the well-known gateways -- but it suffers from the same accuracy/timeliness problems as the usenet maps.
pete@Octopus.COM (Pete Holzmann) (08/07/90)
Peter Honeyman writes: >Steve DeJarnett writes: >>From: steve@qe2.paloalto.ibm.com (Steve DeJarnett) >>... >>BOING! If apple.sgi.com isn't Internet-connected, and doesn't have anyone >>MX-ing for it, the mail bounces. Now, this is a worst-case analogy, but it >>does happen. >>... >>I would love for Rabid Rerouting to work. However, until every workstation is >>IP-reachable (or at least has a host MX-ing for it), this isn't going to work >>(IMHO). > >according to ibm.com, qe2.paloalto.ibm.com is a non-existent domain. as >david herron put it, your use of domains is very very very very wrong. > >your name server must recognize the names that you make, or people and >other mailers that comprehend the domain name system are going to be very >very very very upset with you. Maybe I'm totally misinformed about this, but something seems to be wrong with this situation. I always thought that turning foo.com into an officially registered domain meant that it is up to foo.com to define what anything.else.foo.com means, including whether or not it is a valid address. If foo.com is not directly connected to the Internet, then it cannot answer any queries regarding anything.else.foo.com. peter, are you saying that this is a vvvvv wrong use of domains? If so, what in the world am I supposed to do? Go bug my nameserver every time I add a subdomain? That sounds like a pain in the neck, for me and for them! They didn't sign up for a hassle like that. Seems to me that a mailer should look at something.else.foo.com, and take the longest 'published' FQDN out of it. In this case, just foo.com, and send the message there. It is up to foo.com to decide what to do with the rest! Doesn't that make the most sense? Pete -- Peter Holzmann, Octopus Enterprises |(if you're a techie Christian & are 19611 La Mar Ct., Cupertino, CA 95014 |interested in helping w/ the Great UUCP: {hpda,pyramid}!octopus!pete |Commission, email dsa-contact@octopus) DSA office ans mach=408/996-7746;Work (SLP) voice=408/985-7400,FAX=408/985-0859
lear@turbo.bio.net (Eliot) (08/07/90)
There is a misconception here - in order for a domain to be real, it *must* be represented on the internet by a domain name server, and that domain name server must give back any resource records for that domain. In addition, if the user of that domain is not connected to the internet, that sites view of its domain and the Internet-connected server's view of that domain MUST be consistant. An example - transact.com is not connected to the Internet, but has an MX forwarder and name server named genbank.bio.net. genbank.bio.net MUST NOT reject any mail for a valid host in the transact.com domain. What my server can do is to send all mail for transact.com domain to a smart host inside that domain, and let it decide what is valid and wht is not. That way, I don't actually need to know about every host in that domain, and therefore don't need to make changes in their zone for every new host on their net. I don't consider that to be optimal but it is acceptable. -- Eliot Lear [lear@turbo.bio.net]
michaelb@wshb.csms.com ( WSHB Operations Eng) (08/08/90)
In article <1990Aug7.081953.6108@terminator.cc.umich.edu>, honey@doom.ifs.umich.edu (Peter Honeyman) writes: > > Of course, then we get to the following problem. apple.sgi.com is a > >FQDN. Great. Now the Rabid Rerouters pop up, and say "great, a FQDN very near > >the end of the path (actually, at the end). Let's short-circuit to that." > >BOING! If apple.sgi.com isn't Internet-connected, and doesn't have anyone I don't get why sgi.com doesn't handle routing to apple.sgi.com. I admit to being fairly new in this game. I have three machines and none are internet connected. We have one MX record for the company. I manage to sort out everything based on what prefixes the domain. I can understand that the bang path will be absolutly worthless if someone tries to reroute to the last host, in this case 'apple', but WHY doesn't the domain handle getting it to the right place? I have spent a LOT of my company's time and effort to get this domain stuff working. Am I still missing something? Michael -- Michael Batchelor--Systems/Operations Engineer #compliments and complaints WSHB - An International Broadcast Station of # letterbox@csms.com The Christian Science Monitor Syndicate, Inc. #technical questions and reports michaelb@wshb.csms.com +1 803 625 4880 # letterbox-tech@csms.com
del@thrush.mlb.semi.harris.com (Don Lewis) (08/08/90)
In article <1990Aug7.134658.23389@Octopus.COM> pete@octopus.COM (Pete Holzmann) writes: >I always thought that turning foo.com into an officially registered domain >meant that it is up to foo.com to define what anything.else.foo.com means, >including whether or not it is a valid address. > >If foo.com is not directly connected to the Internet, then it cannot answer >any queries regarding anything.else.foo.com. peter, are you saying that >this is a vvvvv wrong use of domains? > >If so, what in the world am I supposed to do? Go bug my nameserver every >time I add a subdomain? That sounds like a pain in the neck, for me and >for them! They didn't sign up for a hassle like that. > >Seems to me that a mailer should look at something.else.foo.com, and take >the longest 'published' FQDN out of it. In this case, just foo.com, and >send the message there. It is up to foo.com to decide what to do with >the rest! This is what wildcard MX records are for. If you have: foo.com IN MX 10 mail.gateway *.else.foo.com IN MX 10 mail.gateway bar.else.foo.com IN MX 10 another.gateway in the zone file for foo.com, mail addressed to user@bar.else.foo.com will be sent to another.gateway, which will forward it to bar.else.foo.com. Mail addressed to user@foo.com, user@something.else.foo.com, user@anything.else.foo.com, etc. will be forwarded via mail.gateway. Mail to user@some.junk.foo.com will be bounced without being forwarded to any of the foo.com machines (or its gateways), because DNS doesn't know if the existance of any such hosts. The name server software has the flexibility to tell the mailer to do what you want. You just have to set up the zone file properly first. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
marka@dmssyd.syd.dms.CSIRO.AU (Mark Andrews) (08/08/90)
In article <1990Aug7.134658.23389@Octopus.COM> pete@octopus.COM (Pete Holzmann) writes: >Maybe I'm totally misinformed about this, but something seems to be wrong >with this situation. > >I always thought that turning foo.com into an officially registered domain >meant that it is up to foo.com to define what anything.else.foo.com means, >including whether or not it is a valid address. You have to register subdomains even if it's just by using a wildcard record. >If foo.com is not directly connected to the Internet, then it cannot answer >any queries regarding anything.else.foo.com. peter, are you saying that >this is a vvvvv wrong use of domains? >If so, what in the world am I supposed to do? Go bug my nameserver every >time I add a subdomain? That sounds like a pain in the neck, for me and >for them! They didn't sign up for a hassle like that. No. You setup a wildcard MX record. i.e. $ORIGIN foo.com * IN MX 0 mx.machine. This will match any.thing.foo.com if you want to have mail to foo.com go through as well it should look like. $ORIGIN com foo IN MX 0 mx.machine. $ORIGIN foo.com * IN MX 0 mx.machine. and if you don't want the mail for all machines to go to mx.machine. you have records that look like. $ORIGIN com foo IN MX 0 mx.machine. $ORIGIN foo.com amachine IN MX 0 another.machine. * IN MX 0 mx.machine. In this case mail to amachine.foo.com will be sent to another.machine. Mail to any other machine in foo.com will be sent to mx.machine. Just about all of ACSnet is covered by two wildcard MX records, they point at munnari.oz.au and uunet.uu.net (in order of preference). Thats 299 hosts directly under oz.au according to my state tables. Mark.
amanda@mermaid.intercon.com (Amanda Walker) (08/08/90)
In article <1990Aug7.134658.23389@Octopus.COM>, pete@Octopus.COM (Pete Holzmann) writes: > If foo.com is not directly connected to the Internet, then it cannot answer > any queries regarding anything.else.foo.com. peter, are you saying that > this is a vvvvv wrong use of domains? Every domain *must* have two machines acting as name servers for it on the Internet (a primary and a backup), even if (a) neither machine is actually a member of that domain and (b) no machine in that domain is directly connected via IP to the Internet. Normally, the way this case is handled is to advertise a wildcard MX record for the whole domain. INTERCON.COM is an example: our only links to anyone else are via UUCP, but our name servers are uunet and seismo, both of which are on the Internet, but neither of which are part of our domain. They advertise an MX for *.INTERCON.COM. If there are no nameservers for a domain that are reachable from the Internet, that domain doesn't exist. Period. Mail will bounce. People will be mad at you, and it will be all your fault. -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
revell@uunet.UU.NET (James R Revell Jr) (08/09/90)
In article <796@wshb.csms.com> michaelb@wshb.csms.com writes: >I don't get why sgi.com doesn't handle routing to apple.sgi.com. >I admit to being fairly new in this game. I have three machines >and none are internet connected. We have one MX record for the company. >I manage to sort out everything based on what prefixes the domain. Well, this might be a bit off from the apple.sgi.com discussion, but .. Remember, domain names are *not* meant to imply any routing. If may happen that the system that handles sgi.com (192.48.153.1) has some link to apple.sgi.com. If this link is the way they want mail to get to it then the MX record may list sgi.com But what if there isn't a link, or it isn't the preferred way to go? sgi.sgi.com is in Mountain View, CA, but stl.sgi.com is in Hazelwood, MO. It might be preferable to direct mail right to stl.sgi.com if it is IP connected. If not, there might be a local internet host to do the job. In either case, there might be a MX record for stl.sgi.com that points somewhere other than sgi.com Your domain, CSMS.COM, happens to have all mail forwarding done through one point, uunet. This is the simplest way, especially if everything you've got is on an internal LAN, but it is by far not the only way. >I can understand that the bang path will be absolutly worthless if someone >tries to reroute to the last host, in this case 'apple', but WHY doesn't >the domain handle getting it to the right place? I have spent a LOT of >my company's time and effort to get this domain stuff working. Am I still >missing something? Perhaps. Many individual IP connected systems in a domain might be directly reachable and handle their own mail, or they might have it go through a specific mail gateway. A lot of times various subdomains of larger companies go through different hosts. The more distributed your systems are the more demanding your mail routing needs might be. You might want to check out some RFC's (on mail exchanging or BIND). -- James Revell uunet postmaster revell@uunet.uu.net /8^{~
david@twg.com (David S. Herron) (08/11/90)
In article <1990Aug7.134658.23389@Octopus.COM> pete@octopus.COM (Pete Holzmann) writes: >Peter Honeyman writes: >>Steve DeJarnett writes: >>>From: steve@qe2.paloalto.ibm.com (Steve DeJarnett) [A cast of thousands arguing about apple.sgi.com] >>your name server must recognize the names that you make, or people and >>other mailers that comprehend the domain name system are going to be very >>very very very upset with you. ... >I always thought that turning foo.com into an officially registered domain >meant that it is up to foo.com to define what anything.else.foo.com means, >including whether or not it is a valid address. > >If foo.com is not directly connected to the Internet, then it cannot answer >any queries regarding anything.else.foo.com. peter, are you saying that >this is a vvvvv wrong use of domains? Simple.. For disconnected domains you have the nameserver advertise a wild-card MX record .. in your example it would be *.foo.com. IN MX 0 relay.some.place *.foo.com. IN MX 10 relay-2.some.place Mailers are supposed to, when trying to deliver mail, rummage about looking for MX records before doing anything else. (er.. ah.. make that: rummage about after MX records *after* rooting out any CNAME records.) [ Side bar: MX == Mail eXchanger, the place to which the mail should be sent. This is a prioritized list. CNAME == Canonical NAME, gives the real name for a particular name to support aliasing.] A wild card like the above will make the answering nameserver generate a valid-looking response for any name you happen to toss at it. Even if the name is wrong. This has a small side effect that incorrectly address mail will have to travel to your site before being actually verified. This might be expensive or not depending on how often this happens. As usual, nameservers solve every problem known to man :-) -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
Christopher-Vance@adfa.oz.au (08/13/90)
pete@Octopus.COM (Pete Holzmann) writes: | If so, what in the world am I supposed to do? Go bug my nameserver every | time I add a subdomain? That sounds like a pain in the neck, for me and | for them! They didn't sign up for a hassle like that. But you don't have that trouble, Pete, because octopus.com includes a wildcard MX record (last time I checked), so that mail for any subdomain of octopus.com gets sent to the same place as mail for octopus.com itself. Somebody on the DNS can lookup *.octopus.com and get an MX record back. IBM and SGI could do the same, if they wanted to, but since they don't, *they* are claiming that any subdomain not explicitly mentioned in the DNS *doesn't exist* (at least from the point of view of anybody using the Internet). The cynical among us will note that IBM rarely does anything the way everybody else does, especially when Everybody Else Is Right (tm). In your case, Internet mail gets sent to sun (your MX forwarder), and then by sun to you (by UUCP?) and then your UUCP node octopus (a.k.a octopus.com) gets to decide if it has any subdomains. This is different, and perhaps better than listing each subdomain separately, because in the latter case, you *would* have to alter your DNS data every time you add a subdomain. (Well, it's better until octopus becomes a world-wide multinational corporation and you want different MX records for different subdomains :-) -- but even then, there is nothing preventing a wildcard MX record for otherwise unmentioned subdomains.) -- Christopher
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/14/90)
In article <1808@ccadfa.adfa.oz.au>, Christopher-Vance@adfa.oz.au writes: >... > IBM and SGI could do the same, if they wanted to, but since they don't, > *they* are claiming that any subdomain not explicitly mentioned in the > DNS *doesn't exist* (at least from the point of view of anybody using > the Internet).... This is the most recent of several postings that claim the sgi.com domain does not have enough DNS records and/or map entries. Fooey! We've got zillions of records. There are thousands of records in about 20 internal domains, but only about 50 records that we ask our DNS secondaries to carry. There are plenty of MX wild cards. We have had plenty of trouble with mail from remote places bouncing because those remote places do not like our MX and A records, but I believe all of those problems at the remote places. Those problems are why all internally generated Internet mail leaves *.sgi.com with return addresses using the % hack. Experience from the thousands of email messages gatewayed each day by sgi.sgi.com has shown than more sites have trouble with MX records than have trouble with %. If you have concrete evidence of records that should be present but are not, please post or email specifics. You may send mail to postmaster@sgi.com or to me at my address below. (Note: the thousands of *.sgi.com hosts that are not visible to you via ICMP ECHO through the gateway are represented only by MX records. Those who continue to ask for all of the thousands of *.sgi.com A records will continue to be rebuffed.) Why is that because I point out a bad effect of rabid rerouters on a concrete example using hostnames and map entries with which I am familiar, people presume that sgi.com is in a shambles? grumpy, Vernon Schryver vjs@sgi.com