Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!cs.titech!titccy.cc.titech!necom830!mohta From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: Proposed extensions to MX records. Message-ID: <86@titccy.cc.titech.ac.jp> Date: 12 Apr 91 11:16:52 GMT References: <1991Mar28.170144.8370@mp.cs.niu.edu> <1991Mar28.182232.13467@agate.berkeley.edu> Sender: news@titccy.cc.titech.ac.jp Organization: Tokyo Institute of Technology Lines: 92 In article 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.