Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!VENERA.ISI.EDU!pvm
From: pvm@VENERA.ISI.EDU (Paul Mockapetris)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings
Message-ID: <9007270211.AA02319@venera.isi.edu>
Date: 27 Jul 90 02:16:17 GMT
References: <9007251452.AA09940@janeb.cs.wisc.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: pvm@venera.isi.edu
Distribution: inet
Organization: The Internet
Lines: 56

I must admit that I am very surprised at the direction this discussion
has taken.  For other applications, several of the participants have
argued that the DNS lacks the power for various high-powered schemes
and X.500 (or something else) was required.  But now we seem to be
hearing that the future belongs to fixed tables?  Perhaps the tables
should have line numbers in columns 73-80 as well?

The main argument for fixed tables seems to be that they are required
for some gateways without DNS access, hence they are always required,
so why keep the data in two forms which can get out of synch and cause
problems?

[Extracting data for periodic table construction via DNS is possible
at acceptable cost, modulo some transient inconsistencies, and these
transient inconsistencies are the issue.]

The main reason that the DNS is better than host tables is that it
distributes the control of configuration data; if you lose a host, you
can reconfigure your domain around it. The NIC delegates control of
about 3000 domains today.  The curve points up.  The future is with
distributed control.

Any scheme that distributes control at an acceptable cost isn't
atomic; it doesn't matter whether we are looking at X.500, DNS, or
mail of update forms to a central table building organization.  We
should build robust mechanisms and learn to live with this now, rather
than retreating.

Some lower level comments:

I would separate the function of translating between domain names and
X.400 addresses from the function of binding a X.400 address to a list
of MTAs or gateways.

The preference field has proved useful in the Internet; I wouldn't
discard it lightly.

I would not muck with the DNS view of wildcards or add the level
counting function to nameservers; the same function can be implemented
using the existing system.

One way to deal with the issue of component order is to just create a
new syntax, using say "/" as a separator.  Thus A.B would be just
another way of saying B/A.

The argument that says "MX shows that you cannot construct tables
from the DNS" is not strictly correct.  There were two things that
happened: some hosts were listed in the DNS and not in HOSTS.TXT, and
we added new functionality in MX.  For the purposes of host name to
address conversion, anyone could (or can) build scripts to make up a
table of hosts, given the host names.  The real problem is that we
added new functionality which could not be expressed in HOSTS.TXT.
Similarly, we could repeat the same backward compatibility problem
here, but only if we add new bells an whistles.

paul