Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!noose.ecn.purdue.edu!en.ecn.purdue.edu!milton From: milton@en.ecn.purdue.edu (Milton D Miller) Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: Experimental DNS RFC (Re: MX Records) Summary: Not broad enough, here's my suggestion Keywords: MX, Experimental RFC Message-ID: <1991Apr9.211415.16593@en.ecn.purdue.edu> Date: 9 Apr 91 21:14:15 GMT References: <9104082253.AA26014@aggie.ucdavis.edu> Organization: Purdue University Engineering Computer Network Lines: 98 I sent this to the two people mentioned, but will put this out to the group also. In article <9104082253.AA26014@aggie.ucdavis.edu> Russ Hobby writes: >The following document has been sent to the RFC Editor to be an >Experimental RFC (as opposed to being on the standards tract). It is >along the lines of the MX Record discussion that has been going on. The >RFC Editor has given one week (until Apr 15) to reveiw the document and >to say if it is a "good thing". > > >Send your comments to me and Greg Vaudreuil >(gvaudre@nri.reston.va.us> (since I will be on vacation starting >Saturday) and, of course, the WG mail list. > > >Russ Hobby INTERNET: rdhobby@ucdavis.edu >IETF Area Director - Applications BITNET: RDHOBBY@UCDAVIS > UUCP: ...!ucbvax!ucdavis!rdhobby I don't know what WG mailing list is, so one of you can forward it if you feel like it. I am also posting this back to the newgroup. The first thing I notice about the proposal is that it fails to address the problem with all internal mail going through the gateway to reach other local machines. As written, only the gateway can use the LMX record, and not other hosts in the AS. The presently stated record only defines one forwarding hop, which may as well be in a configuration file on the gateway. Since I am complaining, I will also suggest a modified record composed on the spot (not discussed with anyone yet) to reduce this problem, which appear following the excerpt. >1. Overview > > This memo is intended to standardize a method for the determination > of local mail addresses for use within an organization only. The > Domain Name System Resource Record detailed herein is designed for > use from a mail gateway to client machines only. > >3. The LMX RR > > The LMX ("Local Mail eXchanger") record is for use within the > organization's autonomous system (since the address specified by the > LMX will probably not be addressable from external networks). It is > the mechanism by which the mail gateway may determine an address for > a host on local network. The mail gateway, which receives a message > bound for a host for which it is the mail exchanger (i.e., the > gateway's own host name is specified in the MX record) may attempt to > retrieve an LMX record to determine the local address accepting mail > for this host. > >4. Format of the LMX RR > > The LMX is a DNS resource record, the data specified in it is case > insensitive, it has type code XX (to be assigned by the IANA). The > LMX has the following format: > > LMX > > Both RDATA fields are required in all LMX RRs. The is > the domain name of the external name by which the host is known. The > is the domain name of the internal name by which the host > is known. LMX records cause type A additional section processing for > . > How about adding a field saying who can use this record? For example: LMX where who is the optional domain name of who may use the record and defaults to hosts listed in the MX records. The who is not necessaryly host name, for example who may be foo.com. means all hosts under the domain foo.com. The LMX records could then be used for the internal domain, and MX records for the external domain. All LMX weights exist in a single namespace; a host in an LMX can not use a record of lower precedence regardless of the who field (to eliminate loops). Searching for and processing of LMX records is optional provided a host is not pointed to by an LMX. A host sorts records based on weight, then starts making attempts to each server listed, skipping any records whose domain does not match their own. Processing stops if a host finds its own name as the server. If no applicable records were found, a host would then proceed to use the existing MX records as is presently done. This does not explicitly handle one of the cases that came up in the newsgroup discussion -- the hypothetical Australian embassy host in the AU domian connected to the USA internet. However, if these are all in one domain, they can have a LMX for them pointing to the external MXs. It also does not address sites that wish to hide their internal host names from the outside world in the name of security (I won't comment on that :-). milton