[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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>.

Home | Date list | Subject list