rickert@cs.niu.edu (Neil Rickert) (03/29/91)
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 <rickert@cs.niu.edu>
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 <rickert@cs.niu.edu>
Northern Illinois Univ.
DeKalb, IL 60115 +1-815-753-6940cliff@garnet.berkeley.edu (Cliff Frost) (03/29/91)
In article <1991Mar28.170144.8370@mp.cs.niu.edu>, rickert@cs.niu.edu (Neil Rickert) writes: |> |> 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 proposal implies using Domain Names for routing decisions. It's always been my understanding that a DNS name implies nothing at all about routing (for IP or mail or anything else). Is this no longer true? For example, if all parties agree, and everyone sets up the name servers properly, ABC.SomeU.EDU might appear on the net 128.32 here at UC Berkeley instead of on net N.N which is physically at Some U. In other words the DNS name implies nothing about topology (as I understand it). Where I'm more confused is in the area of geographic "ISO-ish" domain names. Is a name that ends in ".AU" absolultely required to refer to a host that is physically in Australia? When I say "required" I mean *formally* required by the Domain Name System rules or their OSI equivalent. Cliff Frost UC Berkeley
jcurran@SH.CS.NET (John Curran) (03/29/91)
--------
] The greatest risk is that there are hosts which don't treat the
] preference as "unsigned" 16 bit values. My guess would be that if there
] are such hosts they probably have 'int' defined as 16 bit, and probably
] have lots of other problems with networking anyway.
If you were to ignore the high bit, you could avoid the signed/unsigned
existing interpetation problem by using the second MSB for "restricted MX"
and thus limit the standard MX's values to 0-8192. (ugly, but..)
Another way to approach the "restricted record" problem would be on a general
(radical) basis with an additional attribute for every record giving the
applicable domain:
ANYHOST.FOO.BAR. *.FOO.BAR. IN MX 100 ANYHOST.FOO.BAR.
*.FOO.BAR. IN MX 200 OTHERHOST.FOO.BAR.
IN MX 100 GW.FOO.BAR.
The magnitude of a change like this would require rolling out new resolver
code many months in advance of the new records, but would then allow for
division of mail and nameservers by various regions:
LARGE.COM. *.EAST.LARGE.COM. IN NS EAST-NS.LARGE.COM.
LARGE.COM. *.EAST.LARGE.COM. IN MX EAST-NS.LARGE.COM.
LARGE.COM. *.WEST.LARGE.COM. IN NS WEST-NS.LARGE.COM.
LARGE.COM. *.WEST.LARGE.COM. IN MX WEST-NS.LARGE.COM.
LARGE.COM. *. IN NS NS1.ANY.NET.
LARGE.COM. *. IN NS NS2.ANY.NET.
LARGE.COM. *. IN MX MAIL-GW.LARGE.COM.
I'm certainly NOT advocating a change of this magnitude, but I felt that
if we're considering restricting MX record usage in some manner, we ought
to examine the more general model for comparision. (Imagine subdomain
delagations that only apply to particular hosts..)
/Johnrayan@cs.toronto.edu (Rayan Zachariassen) (03/29/91)
The arguments for MX records requiring this can also be applied to A records, NS rrs, and probably more. Instead of a special-purpose additional RR, how about a proposal for generic context-sensitivity in the DNS? Generalize... rayan
rickert@mp.cs.niu.edu (Neil Rickert) (03/30/91)
There has been some discussion lately on the topic of the 'Subject:' line above, which may be of interest to some readers of comp.mail.sendmail . This note is mainly to bring it to your attention. The discussion has mostly been by mail in the ietf-hosts mailing list, but it should also be showing up in comp.protocols.tcp-ip.domains . One word of caution. If the ietf-hosts mailing list is being gatewayed into your news system, you will probably see some articles in ietf-hosts, and some in comp.protocols.tcp-ip.domains . Since most of the messages are originating with mail, the items in both newsgroups will have the same 'Message-ID:', so only the first to arrive will be recorded in your system. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
kre@cs.mu.OZ.AU (Robert Elz) (03/30/91)
cliff@garnet.berkeley.edu (Cliff Frost) writes: >This proposal implies using Domain Names for routing decisions. It's always >been my understanding that a DNS name implies nothing at all about routing >(for IP or mail or anything else). Is this no longer true? Its true in theory - in practice many DNS domains are isomorphic with routing areas. Its that practical truth, combined with the ability to make use of it without making any real change to the DNS system that inspired this proposal I believe. That is, for very little cost, a scheme can be implemented that would be of use to many sites, though there's no doubt that it would not be "complete" in any sense, nor would it be able to handle any arbitrary situation. >Where I'm more confused is in the area of geographic "ISO-ish" domain names. >Is a name that ends in ".AU" absolultely required to refer to a host that >is physically in Australia? It is not required, formally or otherwise. What's more, even if it were, that would not imply anything about routing, there are hosts in the AU domain (which happen to be in Australia) that send IP packets to each other via the US (entering at the west coast, crossing NSFnet, and exiting in the north east). (That is, from any regular AARNet host, to one on one multi-national company's IP net that happens to contact the world's research nets in north east US). kre
rickert@CS.NIU.EDU ("Neil Rickert, N Illinois U, CS") (03/31/91)
>This proposal implies using Domain Names for routing decisions. It's always >been my understanding that a DNS name implies nothing at all about routing >(for IP or mail or anything else). Is this no longer true? > >For example, if all parties agree, and everyone sets up the name servers >properly, ABC.SomeU.EDU might appear on the net 128.32 here at UC Berkeley >instead of on net N.N which is physically at Some U. > >In other words the DNS name implies nothing about topology (as I >understand it). I gave two examples in my original message. The first dealt with mailing to the AU domain, and the second to an organizational domain I call FOO.BAR. As I admitted in a later response, the first example is a slight stretch, and in any case the problems cited will be solved with improved technology. The main importance, as I see it, refers to the second example. This is the case where an organizational domain decides, for reasons of its own policy, to control access to the net by limiting packet forwarding and by requiring that email go through a few gateway hosts. Organizations which do this include private corporations and educational institutions. Regardless of whether we agree or disagree with these policy decisions, they exist. Since they are based on policy, they will not quick change with improved connectivity. Whether or not the domain names reflect the packet routing in general, they heavily effect mail forwarding based on these policy decisions. Organizational domains which follow this practice are already using ad-hoc approaches to change the way some MX records are processed. But often these ad hoc approaches are deleterious to the net as a whole. The proposal is designed to provide a consistent way of handling the problem. One alternative that is sometimes used is to set up alternative sets of DNS records, so that the domain database looks different from inside the organizational domain. Sometimes this even involves alternate root name servers. When this approach is used there is a risk that a minor error can inject bogus DNS records into the Internet nameservers. I would much prefer a workable approach which does not entail such a risk. -Neil Rickert
cliff@garnet.berkeley.edu (Cliff Frost) (04/02/91)
In article <9103301612.AA16080@mp.cs.niu.edu> rickert@CS.NIU.EDU ("Neil Rickert, N Illinois U, CS") writes: >>This proposal implies using Domain Names for routing decisions. It's always >>been my understanding that a DNS name implies nothing at all about routing >>(for IP or mail or anything else). Is this no longer true? ... > Whether or not the domain names reflect the packet routing in general, they >heavily effect mail forwarding based on these policy decisions. Neil, How about you change the wording of your proposal very slightly. Instead of using "normal" DNS domains, call them "MX-domains". In the cases where policy enforces the types of naming you're talking about there is no difference between a machine's MX-domain and its DNS name's subdomain. Now, require mailers that implement this to allow a host to think of itself in multiple MX-domains. A host would normally be in the same MX-domain as it's Domain Name, but it could be configured to be in others as well, and it could also be configured NOT to be in the MX-domain that matches its Domain Name. (You do suggest this in your proposal as an option.) That is; X.FOO.BAR.COM's mailer could be configured to be in the MX-domain ABC.EDU. That could be *as well as* being in the MX-domain FOO.BAR.COM, or it could be *instead* of being in the MX-domain FOO.BAR.COM. It seems like the underlying problem to be solved is this: Given a list of source and destination IP addresses, an application (eg mail, telnet, ftp), and a list of policy constraints, how does a host choose which ones to use, and in what order? Well, I don't have any brilliant idea how to approach this, so your proposal seems like a clever way of handling some of this for email. I'd just hate to see fine upstanding addresses like rickert@CS.NIU.EDU degenerate into things like EDU!NIU!CS!rickert. ;-) Cliff
jeff@crash.cts.com (Jeff Makey) (04/02/91)
In article <91Mar28.233847est.6186@neat.cs.toronto.edu> rayan@cs.toronto.edu (Rayan Zachariassen) writes: >The arguments for MX records requiring this can also be applied to A records, >NS rrs, and probably more. Instead of a special-purpose additional RR, >how about a proposal for generic context-sensitivity in the DNS? Generalize... I agree. The DNS was conceived and implemented as a global database, but we now see that that was not quite the best idea. We now need some sort of access controls to provide different answers to DNS queries depending upon who is asking the question. Neil's article should give us a good basis for designing such controls. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Posting from my temporary home at ... Domain: jeff@crash.cts.com UUCP: nosc!crash!jeff
rickert@mp.cs.niu.edu (Neil Rickert) (04/02/91)
In article <8341@crash.cts.com> jeff@crash.cts.com (Jeff Makey) writes: >>The arguments for MX records requiring this can also be applied to A records, >>NS rrs, and probably more. Instead of a special-purpose additional RR, >>how about a proposal for generic context-sensitivity in the DNS? Generalize. > >I agree. The DNS was conceived and implemented as a global database, but >we now see that that was not quite the best idea. We now need some I disagree. The Internet has a global name space, and has been highly effective because of that. The A record(s), for example, uniquely identifies the host. The whole design is based on using this name space, and leaving details of packet routing up to the network routers. If there are problems with accessing hosts with A records, they should be solved by improved routing algorithms, rather than DNS changes. The MX record, however, is an exception. It does not identify the destination host, but instead identifies the first leg in a series of relay steps to get the message to that host. My MX proposal should be understood as allowing the MX records to also define the second and subsequent steps in the relay path. As it stands now, using a chain of relay hops to deliver mail with an MX address is relatively straight forward, providing the second hop uses UUCP or some other form of transport. It is when the second step should also use SMTP that the problems begin, for the MX record defining the first relay hop effectively prohibits the use of the DNS to find the second hop. This can only be overcome by either remapping the destination domain name to a different name, thereby destroying the notion of unique names in a global name space, or by finding some way of overriding the DNS information. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
gandalf@csli.Stanford.EDU (Juergen Wagner) (04/02/91)
So far, the discussion focussed on changes which are visible to clients of
a domain name server. It seems to me that the desired functionality could
also be gained by introducing chnages only on the name server side.
Suppose, a new RR, called VIS (visibility) is defined as follows:
id IN VIS requestor-domain-1
IN VIS requestor-domain-2
... ... ...
where 'id' is some non-numeric identifier, possibly domain-style, and where
'requestor-domain-i' is some domain-style name, with the left-most token
possibly being a '*'.
Now, we could tag all traditional RRs in the following way:
[domain] [ttl] class type data
changes to
[domain] [id] [ttl] class type data
with the semantics that this RR sould only be given to hosts in a domain
listed for the identifier 'id'. Lookup in this table could be done in a
way that the name server looks for the most specific record matching (i.e.
the longer the domain suffix found, the more specific, and the wildcard is
always less specific than any ordinary token).
RRs passed on to clients (mail, news, telnet, etc.) will still have the
same format as before, in fact, they won't notice any difference at all,
except that they now receive less information.
Secondary servers for a domain with VIS records would have to understand
them. This requires updates to all name servers of a domain with VIS RRs.
Listing secondary name servers in VIS records provides a mechanism for
filtering what should be down-loaded on a zone transfer. Of course, we
could also tag VIS records... The name server would use them, anyway, but
some other hosts won't be able to down-load them...
--Juergen Wagner
(gandalf@csli.stanford.edu)
(wagner@iao.fhg.de)
PS: The above reflects some spontaneous ideas I had on this topic. I have
neither thoroughly thought through all the consequences, nor do I have
an implementation of it :-).kre@cs.mu.OZ.AU (Robert Elz) (04/03/91)
jeff@crash.cts.com (Jeff Makey) writes: >We now need some >sort of access controls to provide different answers to DNS queries >depending upon who is asking the question. No we don't - telling lies is the very last thing that we want to do - we've already seen (many times) how a little bit of bad information can easily polute the namespace, and be difficult to get rid of - institutionalising this by deliberately providing wrong answers cannot possibly help. Quite apart from that - you can't possibly tell reliably who is asking the question, queries are often sent through forwarding nameservers, the server that handles the query has no idea at all where it originated. Some have suggested that the domain name of the requestor be used to decide on the answer to give - even assuming that you could find who the requestor is, this would mean the server doing an in-addr.arpa lookup before answering any query - kind of a heavy workload for a busy server there - but even then would be basing the decision on the wrong criteria - domain names should not be used for this purpose. Note that Neil's suggestion does not in any way attempt to hide information - he makes it all available, its then up to the recipient to decide how to interpret the information. That is, his suggestion is simply to provide some guidance. I could imagine that doing something similar for NS records may be an advantage - to suggest (somehow) which NS would be the preferable one to use. This is less important though, as its possible to determine that dynamically by watching the responsiveness of the various servers as queries are made - something that is much harder for a mailer to do (as "responsibveness" is not a measure of which MX is the best to use). Note again - Neil's suggestion does not restrict whoch MX destination a host can use, or which it should try first (beyond the standard restriction if the host involved is itself one of the MX hosts). All of the MX's are equally plausible hosts to use - the suggestion simply provides hosts with a method to determine which is likely to actually be an effective host to try (eg: host X is the best MX, but its useless trying that if you're not in the Z domain, as you won't be able to reach it, you can try if you like, just wasting a bit of time, so try using host Y instead.) Its problem is that that decision is based on domain names - a choice made only because without changing the DNS there is no other available information to use. But here its based on known, well defined, names, the domain of the host asking the query (one assumes it knows its own name - and for this purpose any extra domains it may be considering itself to be a member of) and the domains that actually appear in the DNS answer packet. kre
als@bohra.cpg.oz.au (Anthony Shipman) (04/04/91)
It seems to me that we are abusing the preference value. The MX record tells me where to send the mail to get to the desired destination and may give me a few alternative paths for reliability. This is the essential information. To be helpful it also hints at which paths are more preferable. But it doesn't tell me why. Host A may be preferred over host B because A is lightly loaded. I don't think I should infer routing costs. The proper expert on the routing costs is the network routing system itself. If the MX records suggest two alternatives of equal preference I want be able to ask the network which of the two is the best (least cost) to connect to. The answer depends on where I am and can also change as links go up and down. I understand DECnet routers can supply this information. I don't know much about IP routers. For the "internal/external network" example the network could report that the internal nodes are unreachable from the external nodes, as a result of the policy in the gateway. I realise that this does not solve the immediate problem. In article <1991Apr2.125820.29475@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil Rickert) writes: ......... ......... > The MX record, however, is an exception. It does not identify the destination > host, but instead identifies the first leg in a series of relay steps to get > the message to that host. My MX proposal should be understood as allowing > the MX records to also define the second and subsequent steps in the relay > path. > > As it stands now, using a chain of relay hops to deliver mail with an MX > address is relatively straight forward, providing the second hop uses UUCP or > some other form of transport. It is when the second step should also use > SMTP that the problems begin, for the MX record defining the first relay > hop effectively prohibits the use of the DNS to find the second hop. This > can only be overcome by either remapping the destination domain name to a > different name, thereby destroying the notion of unique names in a global > name space, or by finding some way of overriding the DNS information. It sounds like you are trying to derive a closure from the DNS database, i.e. if A->B and B->C, both by SMTP then you want to conclude A->C in one hop. Should the DNS really attempt this? There might be good reasons why you must go through B, e.g. irregularities due to company routing policy. The DNS sounds like the wrong place for this information. IMHO the ultimate answer is a better routing information service from the IP routers. SNMP might do this or could be extended to do this. -- Anthony Shipman "You've got to be taught before it's too late, Computer Power Group Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia You've got to be carefully taught." R&H
hudson@ug.cs.dal.ca (Bruce Hudson) (04/05/91)
In article <1991Apr4.140715.22723@bohra.cpg.oz.au> als@bohra.cpg.oz.au (Anthony Shipman) writes: > >It sounds like you are trying to derive a closure from the DNS database, i.e. >if A->B and B->C, both by SMTP then you want to conclude A->C in one hop. I do not think that closure was what is desired. At least what I wanted was not closure but some way, using the DNS, to cause all sites other than B (or C, but that wasn't a problem) to send mail for D to B. B should send the mail to C. The current MX protocols do not allow this. It allows only the first hop to be specified, not the second hop. To set this up, B has to special case handling of messages to D in its mailer software. -- Bruce A. Hudson | HUDSON@AC.DAL.CA UCIS, Facilities and Operations | HUDSON@DALAC (Bitnet) Dalhousie University | HUDSON@DALCS (UUCP) Halifax, Nova Scotia, Canada |
dan@SCI.CCNY.CUNY.EDU (Dan Schlitt) (04/05/91)
I have been following this discussion with some interest but with not much of an idea on what would constitute a really good solution. From the amount of discussion it is clear that there is a real problem to be solved. In my mind there is a problem with the use of preferences in the way that has been suggested. There is simply no way that the use of these numbers can be made uniform. It is a bit like port numbers. There are reserved port numbers that are assigned by the NIC. That part works well because they are centrally assigned. But there is the hack of privileged ports which gives special meaning to a subset and some, but not all, software treats them in that way (at least that is how I remeber the situation to be). That creates problems for people who assume that they are treated specially when they communicate with software that doesn't make that assumption. You are setting up a similar situation for MX records. Before adopting the proposal we ought to see some analysis that establishes that the system is robust in the face of failure of opposite ends of a connection making differing assumptions. I think I saw the start of this kind of analysis but it wasn't very convincing. The second problem is that the DNS translates names to numbers and doesn't have anything to do with routing. This problem is really about routing. Is there a solution within the realm of routing without bringing the DNS directly into it? Could we drag the solution back into the domain of assigned numbers? Is it possible that autonomous system numbers or something like them could be a better way to attack the problem? (Said by someone who knows and wants to know little about EGP and friends.) /dan
rickert@mp.cs.niu.edu (Neil Rickert) (04/06/91)
In article <9104051527.AA18234@sci.ccny.cuny.edu> dan@SCI.CCNY.CUNY.EDU (Dan Schlitt) writes: >The second problem is that the DNS translates names to numbers and doesn't >have anything to do with routing. This problem is really about routing. >Is there a solution within the realm of routing without bringing the >DNS directly into it? Could we drag the solution back into the domain of >assigned numbers? Is it possible that autonomous system numbers or something >like them could be a better way to attack the problem? (Said by someone >who knows and wants to know little about EGP and friends.) People keep arguing that this is about routing. It isn't. It is about gatewaying mail. The current MX record is very good for gatewaying mail between Internet and a network using say UUCP transport. It creates problems when you want to gateway mail between two networks both using the Internet protocols. A couple of us are currently looking at another alternative for solving the same problem. If it survives a few more days thought it will be tossed around to some who have commented on this topic. If it still looks good it will be introduced to namedroppers / comp.protocols.tcp-ip.domains for further discussion. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
jeff@crash.cts.com (Jeff Makey) (04/08/91)
Access controls are the correct paradigm for the proposed extensions,
for the simple reason that we wish to restrict (attempted) access to
certain MX hosts. (A similar concern is restricting attempted access
to nameservers.) The problem with bogus RRs is a good reason for
enforcing the access controls in DNS clients, but this doesn't mean
enforcement shouldn't also be done at the server. Doing it both
places would ease the transition period where a large number of DNS
implementations don't do access controls.
The only workable basis for allowing or denying access to particular
RRs is the domain name of the requestor, and this could be either the
regular domain name or the .IN-ADDR.ARPA name, whichever is more
appropriate. Servers should err on the side of releasing RRs when the
identity of the requestor is in question.
Once again, I think enforcement should be done by *both* server and
client, and that the mechanism should be applied to *all* RR types to
allow maximum flexibility. Of course, the momentum of the DNS
protocol and existing implementations may be such that the most we can
hope for is a new RR type (which would still take a painfully long
time to be widely understood).
:: Jeff Makey
Department of Tautological Pleonasms and Superfluous Redundancies Department
Posting from my temporary home at ...
Domain: jeff@crash.cts.com UUCP: nosc!crash!jeffmohta@necom830.cc.titech.ac.jp (Masataka Ohta) (04/12/91)
In article <kre.670337301@mundamutti.cs.mu.OZ.AU> kre@cs.mu.OZ.AU (Robert Elz) writes: >>This proposal implies using Domain Names for routing decisions. It's always >>been my understanding that a DNS name implies nothing at all about routing >>(for IP or mail or anything else). Is this no longer true? >Its true in theory - in practice many DNS domains are isomorphic with >routing areas. Its that practical truth, combined with the ability >to make use of it without making any real change to the DNS system that >inspired this proposal I believe. >That is, for very little cost, a scheme can be implemented that would >be of use to many sites, though there's no doubt that it would not be >"complete" in any sense, nor would it be able to handle any arbitrary >situation. I think I have a good scheme for the MX problem by introducing a new RR type. The scheme should: allow DNS be uniform single tree be effecient allow local control not encourage too much separation of the internet Then, the current MX problem is derived from the fact that the internet is not uniform. It consists of several strongly connected parts: REGION (say North America, Australia or Japan). Links between REGIONs are weak and often charged and thus restricted. So, to reflect the reality, it is natural for each node to have a new RR type: T_REGION. Then, it is now possible to modify mail programs to take special care (see different part of domain tree, for example) if its own domain and the mail destination have the same T_REGION value. For example, consider the case to send a mail from "foo@titech.ac.jp" to "bar@ntt.jp". As "titech.ac.jp." and "ntt.jp" are in Japan, they should have T_REGION value "japan". Mail programs detect this and, instead of looking up MX for "ntt.jp.", look up MX "ntt.jp.japan.region." and recieve the different MX (there is no IP connection between "titech.ac.jp." and "ntt.jp." in Japan. They are independently connected to USA. But UUCP link exists. So, cheap UUCP link should be used for mail transfer in Japan). The schme has advantage over the proposed visibility based scheme that it allows local control of information. That is, each domain can control its REGION. This is important because REGION boundary dose not follow boundary of DNS tree. For example, "japan.sun.com." is a domain in Japan. If the visibility based scheme is used, each administrator in Japan must know which domains are in Japan, which is impossible. Once T_REGION is widely available, there can be several different approach to MX problem: 1) provide a special node "region." as described above. 2) Extend MX (say T_EMX) to allow optional region to control visibility at the mailer side. and perhaps more. But, to me, 1) is preferable because: a) the uniqueness of the REGION name is automatically assured as a subdomain under "region." b) only one new RR type is necessary c) can perform experiment purely locally (using top domain of "region.cc.titech.ac.jp." instead of "region." and performing REGION lookup recursively up-domain, where "jp." has appropriate "T_UNSPEC" record). Multiple levels of REGION (say, tokyo.japan) may be useful, but, it may introduce unnecessary partitioning of the internet. I have already modified berkeley sendmail 5.65 (it was easy) and waiting for "jp." administrator to cooperate. I appreciate any comment. Masataka Ohta PS Currently, we, Japanese, are sufferring from the MX problem and running three trees of DNS. It's ugly.