To:
Robert Elz <kre@munnari.OZ.AU>
Cc:
Brad Knowles <brad.knowles@skynet.be>, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, Jun-ichiro itojun Hagino <itojun@iijlab.net>, Pekka Savola <pekkas@netcore.fi>, dnsop@cafax.se
From:
Brad Knowles <brad.knowles@skynet.be>
Date:
Fri, 22 Nov 2002 11:16:28 +0100
In-Reply-To:
<14283.1037958005@munnari.OZ.AU>
Reply-By:
Wed, 1 Jan 1984 12:34:56 +0100
Sender:
owner-dnsop@cafax.se
Subject:
Re: comments on dnsop-ipv6-dns-issues-00
At 8:40 PM +1100 2002/11/22, Robert Elz wrote:
> While I have no objections with allowing people to provide names for hosts on
> their networks, one way or another, if they desire to, I can't think of any
> particularly good reason why anyone would actually want to (the best one is
> perhaps "because, it has always been done".
Historically, the /etc/hosts (or HOSTS.TXT) table provided both
forward and reverse mapping. In my own experience, a one-way
directory service has limited uses.
When looking through logs, I want to see the name of the
system(s) that are accessing my machines -- their IP address is only
relevant if there is a problem with a particular system and I need to
talk to someone about getting that machine fixed/stopped.
However, when I give that IP address to a remote administrator
and ask her/him to look into finding and fixing that machine, odds
are s/he won't remember the IP address of all the machines under
her/his control any more than I can remember which machines I have
(which is why we have forward resolution, to map easily remembered
names to less easily remembered numbers). So, s/he is just as likely
to do a reverse lookup locally as I would remotely.
Generating all possible forward names that can exist, and then
looking to see which ones map to which IP addresses, is not a
particularly scalable method. Nor is cd'ing to the directory that
holds the contents of all the different zones and then grep'ing
through all those files to see which lines reference a particular IP
address.
If we humans are going to refer to things by names, and the
machines themselves refer to themselves by numbers, we not only need
a method to turn names into numbers, we also need a method to turn
numbers back into names.
We don't need this sort of thing so much for phone numbers, since
most humans actually use the numbers in question, and we have our own
private directories of what names are associated with what numbers
(effectively providing an equivalent of HOSTS.TXT), but people who
deal with receiving a lot of telephone calls do need reverse
directories.
Consumers have access to CallerID, but 911 services (and other
companies that operate large banks of phones) have access to a much
more powerful (and unblockable) service called ANI. And all the
telephone companies provide reverse lookup directory services, either
in print or interactive digital form.
> I certainly don't believe that
> anyone should be expecting to be able to take someone else's address and
> translate it into a name.
Certainly, the level of expectation there should be lower. We
should be trying to actively manage the level of expectation that
people bring to this process. But I am convinced that we need to
provide some mechanism to handle reverse lookups in some fashion.
Indeed, if we can bring cryptographic signatures to this process,
and we can prove that the reverse signatures came from the same key
(or chain of keys) as from the claimed forward name, then we can be a
lot more certain that a particular reverse is authentic. But I think
cryptography is likely to be the only thing that can save us here.
--
Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w---
O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.