Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uwm.edu!linac!mp.cs.niu.edu!rickert
From: rickert@mp.cs.niu.edu (Neil Rickert)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Proposed extensions to MX records.
Message-ID: <1991Apr2.125820.29475@mp.cs.niu.edu>
Date: 2 Apr 91 12:58:20 GMT
References: <1991Mar28.182232.13467@agate.berkeley.edu> <91Mar28.233847est.6186@neat.cs.toronto.edu> <8341@crash.cts.com>
Organization: Northern Illinois University
Lines: 37

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