Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!mp.cs.niu.edu!rickert From: rickert@cs.niu.edu (Neil Rickert) Newsgroups: comp.protocols.tcp-ip.domains Subject: Proposed extensions to MX records. Message-ID: <1991Mar28.170144.8370@mp.cs.niu.edu> Date: 28 Mar 91 17:01:44 GMT Sender: rickert@mp.cs.niu.edu (Neil Rickert) Organization: Northern Illinois University Lines: 272 The following is a suggestion I wish to float, which might be of significant use in dealing with some of the problems of mail handling. This should obviously be considered a first draft. A public (email and/or usenet news) will help clarify some of the issues. -------------------------------------------------------------------- Extended MX record handling. Draft proposal by Neil Rickert Since their introduction, the MX record has proved to be a very useful innovation. They have allowed a host to specify an alternate mail path, and they have provided a mechanism for awarding Internet names to hosts not directly on Internet, but connected to an Internet host by some other mail transport such as UUCP. The result has been the development of a universal name space for electronic mail addresses, which has effectively separated the issue of email addresses from that of the network paths required to reach that address. PROBLEMS: There are, however, some problems associated with the use of MX records. At the time of their introduction, it would have been difficult to forsee the extent of growth in networking which has led to these difficulties. We present two examples to illustrate these problems. EXAMPLE 1: In Australia, the host MUNNARI.OZ.AU is one of the key hosts. It acts as a principle nameserver for the AU domain, and as a gateway for many hosts in Australia which are not directly Internet connected. There are currently two MX records for MUNNARI.OZ.AU. They are: MUNNARI.OZ.AU. IN MX 10 MUNNARI.OZ.AU. IN MX 200 UUNET.UU.NET. Normally a mail transport, when sending mail to MUNNARI.OZ.AU, will first attempt to connect to the primary MX host, namely MUNNARI.OZ.AU itself. If it fails in this attempt, it will instead try sending to the secondary host UUNET.UU.NET. This provides some redundancy, and provides a shorter network link for hosts in North America. In particular, hosts with deficient networking software may have difficulty establishing connections to Australia, but are more likely to be successful with the shorter distances to UUNET.UU.NET in Virginia, USA. The pair of MX records thus improves the email connectivity. But this comes at a cost. If, for some reason, MUNNARI.OZ.AU is temporarily down, a host in Australia attempting to send mail to MUNNARI.OZ.AU will find itself sending the message halfway around the world to UUNET.UU.NET, which will in turn eventually have to send it back to Australia. This lengthy round trip is an inefficient use of network resources, and does not even earn frequent flyer mileage. It is difficult to avoid this problem. Additional MX records could be added with other Australian destinations. With two additional such hosts, perhaps with preferences of 50 and 100, the probability of all being inaccessible from within Australia becomes very small. But the result is that a host in North America must try all three Australian hosts before it finally tries sending the mail to UUNET.UU.NET. Many mail transports may be unwilling to attempt that many different hosts. EXAMPLE 2: The mythical domain FOO.BAR has hundreds of hosts. However only two of them are Internet connected, NS.FOO.BAR and GW.FOO.BAR. All of the hosts in this domain are however connected on an internal network. Thus an Internet host can send mail to ANYHOST.FOO.BAR by relaying it to GW.FOO.BAR, which then forwards it on the internal network to its final destination. The internal network uses the Internet protocols, but for reasons of company policy there is no IP packet forwarding between the internal network and the Internet. Although hosts internal to the FOO.BAR domain cannot communicate directly with Internet, they can use their internal network to access a NAMESERVER which is running on each of NS.FOO.BAR and GW.FOO.BAR. Having access to a nameserver turns out to be very useful, as it allows email domain names on Internet to be properly validated from within the FOO.BAR domain. This greatly reduces the chance of mail with invalid domain addresses being sent from the FOO.BAR domain into the Internet. At first sight, the MX record would seem ideal for a domain such as the FOO.BAR domain. For example, by creating an MX record naming GW.FOO.BAR as the mail exchanger for ANYHOST.FOO.BAR, hosts on the Internet attempting to send mail will automatically send that mail to GW.FOO.BAR to which they can connect, instead of simply attempting an impossible connection to ANYHOST.FOO.BAR. The difficulty arises, however within the FOO.BAR domain. According to that MX record, if GW.FOO.BAR has mail to relay to ANYHOST.FOO.BAR, it should look for an MX record. But it must discard the MX record which points to itself. This leaves it without directions as to how to handle the mail. Consequently some special arrangements must be made. Additionally, if OTHERHOST.FOO.BAR wants to send mail to ANYHOST.FOO.BAR, that same MX record causes it to deliver the mail to GW.FOO.BAR. Thus the gateway host is heavily loaded with the relaying of internal mail which could have been handled directly within the private domain, were it not for the MX record. One way around this problem which is sometimes used is to have two MX records for ANYHOST.FOO.BAR. The best preference names ANYHOST.FOO.BAR as the mail exchanger, while the alternate names GW.FOO.BAR. A host within the FOO.BAR domain will first attempt to send mail directly, and usually that will succeed. But a host on Internet from outside the FOO.BAR domain will fail in its attempt to mail to ANYHOST.FOO.BAR, and only after this connection attempt has timed out will it attempt to connect to GW.FOO.BAR (which should succeed). Although the computational cost of timing out on ANYHOST.FOO.BAR is not high, it may delay processing other mail in the queue, so the administrators of the FOO.BAR domain are reluctant to impose this burden on communicating Internet hosts. Moreover, Internet hosts with deficient mail transports may not attempt the second MX host after failing on the first. WORKAROUNDS: A number of workarounds have been used to deal with these situations. None is truly satisfactory. Methods include using mailers which don't read MX records, using mail software specially designed to ignore certain MX records, or creating an alternative DNS database setup for the domain, so that name servers within the domain supply different data than nameservers outside the domain. A PROPOSED ALTERNATIVE: We propose a redefinition of the MX record to handle the problem. Although the revised usage does not completely resolve all of the problems, it goes a long way in that direction. We will indicate later (in the section on implementation) how this redefinition can be implemented with a minimum of disruption. The current MX format is: ;domain preference mail-exchanger ANYHOST.FOO.BAR IN MX 100 GW.FOO.BAR. All that is changed is the preference. In place of a numeric preference, a preference now becomes a (domain, number) pair. Thus we might have: ANYHOST.FOO.BAR. IN MX (FOO.BAR., 100) ANYHOST.FOO.BAR. IN MX (FOO.BAR., 200) OTHERHOST.FOO.BAR. IN MX (., 100) GW.FOO.BAR. The interpretation is as follows. A host outside the FOO.BAR domain cannot use the first two MX records, for their use is restricted to within that domain. Therefore such a host only recognizes the third MX record, which directs mail go GW.FOO.BAR. A host inside the FOO.BAR domain, however, uses only the first two MX records, since they are specific for that domain. Thus the mail is appropriately directed within the domain, instead of going to the gateway host and unnecessarily loading it. Here are the rules for the preference field: 1. The domain which restricts the applicability of the MX must be a valid domain name. However there is no requirement that there exist an SOA record or an NS record of any other record with that name. 2. The domain for which the MX record exists must itself be within the domain which restricts the application of the MX. That is, an MX record for ANYHOST.FOO.BAR could have as its restricting domain any of . or BAR or FOO.BAR or ANYHOST.FOO.BAR. However UU.NET could not be used as a restricting domain. 3. An MX record in the old style ANYHOST.FOO.BAR. IN MX 200 NS.FOO.BAR. is to be interpreted as ANYHOST.FOO.BAR. IN MX (., 200) NS.FOO.BAR. 4. If an MX record is being interpreted by a host, that host only uses records restricted to a domain containing the interpreting host. The records used must be those of the most restrictive such subdomain for which MX records exist. Thus in the example, a host outside the FOO.BAR domain is prevented from using the first two MX records, since it is not in that domain. A host inside FOO.BAR is prevented from using the third record, since MX records exist in a more restrictive valid domain. Here is how the Australian example might look: MUNNARI.OZ.AU. IN MX (AU.,10) MUNNARI.OZ.AU. IN MX (.,10) MUNNARI.OZ.AU. IN MX (.,200) UUNET.UU.NET. Here a host in North America would use the second and third MX records. This is no change from the present arrangement. But a host in Australia is inside the AU domain, so would only use the first record. Thus mail from Australia would never be sent back to North America. A second MX record restricted to the AU domain could be added if desirable, without imposing an extra burden on hosts in North America. COMMENT: It might be desirable for the interpretation of MX records to be handled primarly by the mail transport. A mailer might be configurable as to which domains it considers itself inside when interpreting MX records. For example a host in New Zealand might want to use the MX records restricted to the AU domain, rather than the records for the universal domain. A mailer configuration setting might list the AU and NZ domains as the two domains such a mailer will consider itself to be inside. SUGGESTED IMPLEMENTATION: We propose the following limits on the meaning of MX records. On an MX record restricted to the root domain, the preference is restricted to a 15 bit integer. This is a change from the current definition, which permits unsigned 16 bit integer preferences. However this change is not likely to cause serious problems, since there are probably very few, if any, MX records with preference values in excess of 32767. On an MX record restricted to a domain other than the root, a preference is restricted to an 11 bit integer value. That is, the numeric preference must be between 0 and 2047 inclusive. The domain of restriction is limited to a maximum of 16 levels of qualification. (For example a restriction to FOO.BAR uses 2 such levels). Data for an MX record with root domain restriction will be recorded exactly as before. However, due to the 15 bit restriction on the numeric preference, the most significant bit of that preference will always be zero. Data for an MX record with a non-root restriction will be as follows: The most significant bit of the 16 bit preference field is always 1. The next 4 bits specify the domain of restriction. This 4 bit number represents an integer value between 0 and 15, which implies a domain agreeing with the domain name of the MX record in between 1 and 16 levels of qualification. The remaining 11 bits of the preference field specify the numeric preference. SOFTWARE CHANGES THAT ARE NEEDED: Since the data carried by a nameserver is unchanged in content, but changed only in interpretation, existing nameservers will still be useable. It will be desirable to upgrade them to accept the new input format for MX records, but the urgency is not great since the appropriate values can be computed by hand and entered into existing databases. If the interpretation of the data is left to the mail software, the resolver routines will not need to be changed. It will of course be desirable to upgrade domain analysis tools such as NSLOOKUP and DIG, but there is no great urgency. Email software must be upgraded to properly interpret the new formats. However, if a particular mailer is not upgraded, that will not create a significant problem. That mailer will see the new MX records with restrictions other than to the root domain as having very high numeric preference values, which in most cases will mean that these new records will largely be ignored. The crucial step to use the new facilities, then, is to upgrade the mailers on a set of key hosts within those domains that wish to use the new facilities. We do not forsee this as creating any major difficulties. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940