Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!mel.dit.csiro.au!yarra!bohra.cpg.oz.au!als From: als@bohra.cpg.oz.au (Anthony Shipman) Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: Proposed extensions to MX records. Summary: my tup'n'orth Message-ID: <1991Apr4.140715.22723@bohra.cpg.oz.au> Date: 4 Apr 91 14:07:15 GMT References: <1991Mar28.182232.13467@agate.berkeley.edu> <1991Apr2.125820.29475@mp.cs.niu.edu> Organization: Software Division, Computer Power Group Lines: 56 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