🚀 go-pugleaf

In article <1992Jul27.135126.1626@drycas.club.cc.cmu.edu> greenie@drycas.club.cc.cmu.edu writes:
>To settle the stories and quench the rumor mongers, "pleasure.com" was
>a test site that we had set up as a demonstration to determine the "market
>demand" for an adult service on the commercial internet.  It was only set
>up for a short period of time, and there were a number of users connecting
>to it.  But since it was a test and not expected to remain online forever,
>we did not bother registering the domain name - and we were under no obligation
>to do so because it was through the commercial Internet and therefor not
>under the auspices of the NIC and the NSF.
>

I'm not so sure about not being under the auspices of the NIC - the NSF, no,
but someone controls domain and IP allocations for the Commercial Internet
as well. I accept your explanations for what you did, I just feel it was
done poorly. Someone should have been made aware.

>We were NOT "storing up passwords" as some users have suggested.  Rather, 
>since *WE* are just as concerned about security as other people apparently
>are, we set up our system so that it would FTP TO the users home site and
>place files there, rather than allowing them to connect freely to our
>machines using FTP.  Users who are not happy with doing this are not being
>forced to transfer files this way.  They're not being forced to transfer
>files at all.
>

I didn't suggest that you were storing passwords, I was just concerned about
the mechanism to do so, which hasn't been explained. Is it the users
themselves which do the FTP? From what I saw, it seemed to be an automated
process, which would have required the storing of the password to connect to
the user's remote account. I could be wrong - I hope I am - but it sure
looked automated, and unsuccessful at that.

>Because of the original individuals negative comments and paranoia with the
>connections (rather than approaching us first), we will probably choose 
>another REGISTERED domain name in the future.
>

Security is inherently paranoid...

I don't think my comments were necessarily negative, just concerned. When
one has a system being broken in to, does one go to the cracker and ask what
they are doing? I went to the best resource available, UseNet, to find out
if anyone else knew about it and see what other concerns people had with the
practice. I would have contacted you afterwards, if you hadn't decided to
attack me first...

=======================================================================
Brian O'Neill - Systems Manager, Computer Science 	 (508) 934-3645
University of Massachusetts at Lowell
Internet: oneill@ulowell.edu		Moderator, comp.binaries.ibm.pc

In article <1992Jul27.135126.1626@drycas.club.cc.cmu.edu> greenie@drycas.club.cc.cmu.edu writes:
 > We were NOT "storing up passwords" as some users have suggested.  Rather, 
 > since *WE* are just as concerned about security as other people apparently
 > are, we set up our system so that it would FTP TO the users home site and
 > place files there, rather than allowing them to connect freely to our
 > machines using FTP.

Eh.  Possibly a stupid question.  But how do you ftp to the users home site
without storing the password of that users home site?
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland
dik@cwi.nl

From article <1992Jul27.135126.1626@drycas.club.cc.cmu.edu>, by greenie@drycas.club.cc.cmu.edu:

>to it.  But since it was a test and not expected to remain online forever,
>we did not bother registering the domain name - and we were under no obligation
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>to do so because it was through the commercial Internet and therefor not
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>under the auspices of the NIC and the NSF.


Three items.

 1.  What is the "Commercial Internet", and where is the "central
     contact point" for it, if such a thing exists.

 2.  Assuming you really _have_ no obligation to register a temporary
     domain name with "The NIC", how do you prevent collisions in the
     domain name-space?  It would seem that there has to be _some_
     central clearinghouse to prevent such collisions.

     A possibility comes to mind -- the NIC has delegated "domain
     registry authority" to the "Commercial Internet", who has full
     control over the "COM" domain.  "Is this the true state of
     things?", he asked curiously.  If this is not the case, I can see
     a situation where the "Commercial" Internet registers a particular
     domain [e.g, xyzzy.com], and someone else registers this same
     domain with the NIC.  Who wins when these are advertised by the
     nameservers?

 3.  Similar to the above, but with no easily apparent resolution, is
     the question of how one prevents IP address collisions.  Since the
     "NSF/MIL Internets" seem to be interconnected with the
     "Commercial" Internet, and they _are_, aren't they? :-), they must
     needs share that same address space.  It seems to me that there
     thus must be _a_ central clearinghouse for assigning IP addresses,
     in order to prevent collisions.  (The NIC comes to mind here as a
     reasonable site for such a clearinghouse.)  This leads me to
     believe that there _is_ an obligation to register domains.  (The
     only exception I can think of is if the registration authority
     'lends' one of its _own_ IP addresses to this new entity.)

Or am I missing something very obvious in what transpired here?

Confused and puzzled by the situation,
-- 
John G Dobnick                          ATTnet: (414) 229-5727
Computing Services Division             INTERNET: jgd@uwm.edu
University of Wisconsin - Milwaukee     UUCP: uunet!uwm!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire

In article <1992Jul28.203324.15206@uwm.edu> jgd@csd4.csd.uwm.edu writes:
>From article <1992Jul27.135126.1626@drycas.club.cc.cmu.edu>, by greenie@drycas.club.cc.cmu.edu:
>
>>to it.  But since it was a test and not expected to remain online forever,
>>we did not bother registering the domain name - and we were under no obligation
>                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>to do so because it was through the commercial Internet and therefor not
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>under the auspices of the NIC and the NSF.
>
>
> 2.  Assuming you really _have_ no obligation to register a temporary
>     domain name with "The NIC", how do you prevent collisions in the
>     domain name-space?  It would seem that there has to be _some_
>     central clearinghouse to prevent such collisions.
>     'lends' one of its _own_ IP addresses to this new entity.)

It is especially odd in light of what the advertising from UUNet and PSInet
(two major commercial network service providers) says.  According to their
promotional literature, one service that they will provide to anyone that
buys their Internet connection from them is domain registration at
the DDN Network Information Center.  Specifically, said literature states
that entries for any particular domain name will be registered at nic.ddn.mil.

Here is a question that, paradoxically, may help to clear this up:  Were
domain names to be used for connecting to the host in this test?  Specifically,
was it intended for users to telnet to "pleasure.com" (or whatever it was,)
or were they intended to telnet to xxx.yyy.zzz.www, a numbered IP address?  I
recall reading about this service in alt.sex, I think.  I believe that testers
were asked to telnet to a numbered address, rather than to a named address.

If this was indeed the case, then the lack of domain name registration would
make some sense, since it would not be intended for users to telnet to
"pleasure.com".  "pleasure.com" would simply be a convenient name to use
during the test -- especially if there were only one host in the "domain".

>Or am I missing something very obvious in what transpired here?

I must be missing something too.

>Confused and puzzled by the situation,

So am I.

>-- 
>John G Dobnick                          ATTnet: (414) 229-5727
>Computing Services Division             INTERNET: jgd@uwm.edu
>University of Wisconsin - Milwaukee     UUCP: uunet!uwm!jgd
>
>"Knowing how things work is the basis for appreciation,
>and is thus a source of civilized delight."  -- William Safire


-- 
D. Robert Spexet II, N0OKR   Internet:  spexet@math.lsa.umich.edu
Department of Mathematics    BITnet:    user68xr@umichum.bitnet
The University of Michigan   UUCP:      uunet!mailrus!math.lsa.umich.edu!spexet
Ann Arbor, Michigan 48109

To clarify:

  The DDn Network Information Center is the ONLY official organisation
that can grant or delegate responsibility for domain names.  They are
authoritative for both commercial and non-commercial sites.  All sites
MUST have a valid registered domain name, not just a valid IP number.
In the case of non-US country-oriented domains, the DDN NIC has
delegated authority for that domain to an organisation in that
country.  All members of the Commercial Internet Xchange (CIX)
recognise the authority of the DDN Network Information Center in this
regard.  Claiming commercial sites don't have to register there is
untrue.

  The site "pleasure.com" was required to obtain a valid domain name
(from the DDN NIC since *.com is not delegated) and did not do so.
This is at best uncivilised behaviour by the folks who ran that site.

Ran
atkinson@itd.nrl.navy.mil

atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:

>  The DDn Network Information Center is the ONLY official organisation
>that can grant or delegate responsibility for domain names.

Do you have the law which deligates them this authority?

No? I thought so.

The NIC is a clearinghouse, which is generally accepted amoung sites to be
"the center" for registering a domain. There is no force-of-law behind this,
however.
 
>  The site "pleasure.com" was required to obtain a valid domain name
>(from the DDN NIC since *.com is not delegated) and did not do so.

Obtaining the "internet-number" template from the NIC, which is used to
request a network address assignment, contains no question for you to
indicate the domain name of an IP address you are registering. Therefore,
one can surmise that it is entirely legitimate to obtain an IP address
without a domain name.

MD
-- 
--  Dr. Michael P. Deignan (deg.pend.)      /   "Its okay dear,
--  Domain: kd1hz@anomaly.sbs.risc.net     /     you can show me...
--    UUCP: ..!uunet!anomaly!kd1hz        /      I'm a Doctor..."

In article <1992Jul29.215824.16932@anomaly.sbs.risc.net>, kd1hz@anomaly.sbs.risc.net (Michael P. Deignan (KD1HZ)) writes:
> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
> 
>>  The DDn Network Information Center is the ONLY official organisation
>>that can grant or delegate responsibility for domain names.
> 
> Do you have the law which deligates them this authority?
> 
> No? I thought so.
> 
> The NIC is a clearinghouse, which is generally accepted amoung sites to be
> "the center" for registering a domain. There is no force-of-law behind this,
> however.


Force of law (as in jail)?  Nope.  If that were true quite a few MILNET
host administrators would be in jail by now.

But the requirement, in a place that calls their requirements "Requests for
Comments," is fairly explicit.  If you want a domain under "COM" on the
Internet you have to go to the NIC.  The COM domain of the Internet may be
spun off with its own naming authority some time in the future, but not yet.
Registering under/using the COM domain has nothing to do with using a
commercial network provider on the Internet.

Of course now that the IAB has been absorbed in to the Internet Society, they
don't have the aura of authority of the DARPA or DCA anymore.  So how "official"
their policy statements are remains to be seen.



From RFC 920

  >                          Domain Requirements
  >
  >
  >Status of this Memo
  >
  >   This memo is a policy statement on the requirements of establishing a
  >   new domain in the ARPA-Internet and the DARPA research community.
  >   This is an official policy statement of the IAB and the DARPA.
  >   Distribution of this memo is unlimited.

  [...]

  >General Requirements on a Domain
  >
  >   There are several requirements that must be met to establish a
  >   domain.  In general, it must be responsibly managed.  There must be a
  >   responsible person to serve as an authoritative coordinator for
  >   domain related questions.  There must be a robust domain name lookup
  >   service, it must be of at least a minimum size, and the domain must
  >   be registered with the central domain administrator (the Network
  >   Information Center (NIC) Domain Registrar).


From RFC 1032

  >                      DOMAIN ADMINISTRATORS GUIDE
  >
  >
  >STATUS OF THIS MEMO
  >
  >   This memo describes procedures for registering a domain with the
  >   Network Information Center (NIC) of Defense Data Network (DDN), and
  >   offers guidelines on the establishment and administration of a domain
  >   in accordance with the requirements specified in RFC-920.  It is
  >   intended for use by domain administrators.  This memo should be used
  >   in conjunction with RFC-920, which is an official policy statement of
  >   the Internet Activities Board (IAB) and the Defense Advanced Research
  >   Projects Agency (DARPA).  Distribution of this memo is unlimited.

  [...]

  >   The NIC is designated by the Defense Communications Agency (DCA) to
  >   provide registry services for the domain-naming system on the DDN and
  >   DARPA portions of the Internet.
  >
  >   As registrar of top-level and second-level domains, as well as
  >   administrator of the root domain name servers on behalf of DARPA and
  >   DDN, the NIC is responsible for maintaining the root server zone
  >   files and their binary equivalents.  In addition, the NIC is
  >   responsible for administering the top-level domains of "ARPA," "COM,"
  >   "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
  >   becomes feasible for other appropriate organizations to assume those
  >   responsibilities.


-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Domain: sean@sdg.dra.com, Voice: (Work) +1 314-432-1100

In article <1992Aug04.030626.18301@anomaly.sbs.risc.net>, kd1hz@anomaly.sbs.risc.net (Michael P. Deignan (KD1HZ)) writes:
|> That's right... *IF* I expect people to be able to address my machine as
|> "pleasure.com". If I don't, I can call it whatever I want to.
|> 

But that raises the concerns that sparked this whole thing off...by doing
an inverse mapping to an invalid name, you in a sense "cover" your tracks,
as all the logs (unless someone uses a modified logger) list the site as
the name instead of the address, and the name cannot be mapped back. Now,
I happen to do a last on my system, and see tons of ftp sessions to several
users accounts from a site whose name cannot be traced. Do I just sit back
and wonder what is going on or do I try and figure it out? I simply slip in
a new ftpd with better logging and see what comes out. Then, with that
information in hand I begin to find out...

=======================================================================
Brian O'Neill - Systems Manager, Computer Science 	 (508) 934-3645
University of Massachusetts at Lowell
Internet: oneill@ulowell.edu		Moderator, comp.binaries.ibm.pc