Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!amdahl!bungia!ahby From: ahby@bungia.Bungia.MN.ORG (Shane P. McCarron) Newsgroups: comp.mail.uucp Subject: Re: smail wants you to register a domain (using Path: for replies) Message-ID: <370@bungia.Bungia.MN.ORG> Date: 1 Sep 88 13:35:31 GMT References: <70@volition.dec.com> <71@volition.dec.com> <935@cbnews.ATT.COM> <44401@beno.seismo.CSS.GOV> <946@cbnews.ATT.COM> <355@bungia.Bungia.MN.ORG> <998@cbnews.ATT.COM> <117@com2serv.C2S.MN.ORG> <5372@killer.DALLAS.TX.US> Reply-To: ahby@bungia.UUCP (Shane P. McCarron) Organization: Bugoslavian Embassy, St. Paul, MN Lines: 76 In article <5372@killer.DALLAS.TX.US> wisner@killer.Dallas.TX.US (Bill Wisner) writes: >>I would maintain that there is a lot of interest in parks. They are >>what was intended by the MX system in the first place. No one wanted >>every measley PC running UUPC to get an MX record! That is an abuse >>of the nameservers, and a disservice to the community. > >Er, how's that? The only site that could possibly be inconvenienced by >a lot of MX records is the site where the nameserver database is stored. >Each site in a domain may have a unique entry, or maybe there's a >wildcard record. In either case, a query will use exactly the same amount >of network bandwidth. Well, you're right. Actually, that is what I was referring to. There should be several nameservers for any one site, so there would be several machines with thousands of MX records. Moreover, these are difficult to maintain; if there is an MX for every site, then every time you add a machine on your LAN you have to send a message to some volunteer coordinator so they can add an MX to a bunch of machines around the network. This is NOT what was intended. To quote some material just recently provided me by Rick Adams: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 An entire domain of hosts not connected to the Internet may want their mail to go through a mail gateway that knows how to deliver mail to them. If they would like mail addressed to any host in the domain FOO.COM to go through the mail gateway they might use: FOO.COM. MX 10 RELAY.CS.NET. *.FOO.COM. MX 20 RELAY.CS.NET. RFC 974 January 1986 Mail Routing and the Domain System Minor Special Issues There are a couple of special issues left out of the preceding section because they complicated the discussion. They are treated here in no particular order. Wildcard names, those containing the character '*' in them, may be used for mail routing. There are likely to be servers on the network which simply state that any mail to a domain is to be routed through a relay. For example, at the time that this RFC is being written, all mail to hosts in the domain IL is routed through RELAY.CS.NET. This is done by creating a wildcard RR, which states that *.IL has an MX of RELAY.CS.NET. >In fact, far from being an abuse of nameservers, having a unique record >for every site in a domain results in greater performance. Internet mailers >can tell instantly whether a site is valid (the server will return an >"unknown" response), rather than possibly waiting a day or two to get >an error message from the "hub" of a domain. It MAY result in greater mail reliability, but certainly not greater performance. I maintain that it will reduce reliability, because if I add a new node to my network and send mail to you from it before the MX records are updated you cannot respond to me. This is the aspect that I call a disservice to the community. There is no way that this volunteer coordinator I speak of could handle the load of new nodes that must be being added to LANs all over the world every day. Also, it is unlikely that you are going to wait a day or two for the unknown host message to be returned. It should be more like a few hours. I realize that this is a terrible hardship, but you are already waiting several hours for the material to get its butt off of you node and out into the Internet. The citizens of the UUCP Zone have this problem every day - why can't the citizens of fully connected networks put up with it as well? -- Shane P. McCarron UUCP: ahby@bungia.mn.org Systems Analyst ATT: +1 612 224-9239