on 12/3/00 0:49, PacificRoot.com DomReg Svcs. at [EMAIL PROTECTED] wrote:
> Swerve,
>
> Thank you. some people here are apparently admins :)
>
> Now, again... What does OpenSRS/TUCOWS have to say about this?
>
Again, the guys are working so hard I hope they relax and don't answer until
Monday. No offence, but this is a complicated issue that will not be
resolved on a weekend or likely in a week. I also note that we are now only
15 hours from the original post ;-).
Regards
>
> On Sat, 2 Dec 2000, Swerve wrote:
>
>> There seems to be more than one issue being brought up in the original post.
>> The one that affects nameserver owners is the registration of nameservers
>> under "example.com" without permission of the nameserver owner. From the
>> examples sited, it could be damaging for anyone operating a nameserver.
>>
>> Perhaps someone from Opensrs could be clear about the existing policy around
>> this, and if it doesn't have alot of teeth, then a method to force the
>> removal of unauthorized domain server usage needs to be considered.
>>
>> It's not clear to me why name registrants are forced to list nameservers
>> upon registering names under certain (not all) TLD's. For e.g. if i
>> register Canada2010.com and plan to open the site in 2009, then proving
>> technical acumen/relationship right now, and having to list nameservers,
>> doesn't make sense to me. Any thoughts on this? (I'll bet there's quite a
>> few. :-))
>>
>> swerve
>>
>>> From: "dnsadmin" <[EMAIL PROTECTED]>
>>> Date: Sat, 2 Dec 2000 19:30:24 -0800
>>> To: <[EMAIL PROTECTED]>
>>> Subject: RE: nefarious and unscrupulous registrants... (fwd)
>>>
>>>
>>> That was rather long winded. I hope people didn't skip over it after they
>>> got down to the 5th or 6th paragraph. :)
>>>
>>> Basically someone that registers a domain, and unlawfully lists a victim's
>>> nameservers and technical contact information can cause:
>>>
>>> a) several administrative threats and complaints about the registrant to be
>>> incorrectly addressed to the victim who owns the nameservers or is listed as
>>> the tech contact
>>>
>>> b) can cause the victim's ip block to be denied access to other networks
>>>
>>> -----------
>>>
>>> Basically, it works like this:
>>>
>>> 1. Domain horder registers "example.com" and puts a Victim's tech contact
>>> and nameservers on the domain
>>>
>>> 2. Domain horder sends out tons of spam saying "example.com" is available to
>>> be purchased for $5,000 if anyone wants it
>>>
>>> 3. People get upset, do a WHOIS on "example.com" and flame the tech contact
>>> and block the ip blocks that the nameservers sit on
>>>
>>> 4. Victim sysadmin gets ton of complains, threats, and their network is
>>> blocked by several, and they are left cleaning up a mess that they are 100%
>>> not guilty for..
>>>
>>> Is this correct?
>>>
>>>
>>>> -----Original Message-----
>>>> From: [EMAIL PROTECTED]
>>>> [mailto:[EMAIL PROTECTED]]On Behalf Of PacificRoot.com
>>>> DomReg Svcs.
>>>> Sent: Saturday, December 02, 2000 6:51 PM
>>>> To: [EMAIL PROTECTED]
>>>> Cc: [EMAIL PROTECTED]
>>>> Subject: nefarious and unscrupulous registrants... (fwd)
>>>>
>>>>
>>>> oopsie. left out an "S" in discuss.
>>>>
>>>> ---------- Forwarded message ----------
>>>> Date: Sat, 2 Dec 2000 18:40:16 -0800 (PST)
>>>> From: PacificRoot.com $5.00 and Free DomReg Svcs. <[EMAIL PROTECTED]>
>>>> To: [EMAIL PROTECTED]
>>>> Cc: [EMAIL PROTECTED]
>>>> Subject: nefarious and unscrupulous registrants...
>>>>
>>>> A friend of mine who operates an ISP in Florida came to me with a question
>>>> regarding some notorious entity (I do not know who the registrant is).
>>>> that is an OpenSRS registrant.
>>>>
>>>> She states that she has received several administrative threats and
>>>> complaints about the registrant, since her nameservers are listed as auth
>>>> for the domain at whois.opensrs.net and this is something that many of you
>>>> I am sure have not been around long enough to remember - so I'll spell it
>>>> out.
>>>>
>>>> Back when Internic was in Sandy Eggo, and even after that for some time,
>>>> but especially then, you had to demonstrate that you had at least two NS's
>>>> on preferably separate packet switched networks answering AUTH for a
>>>> domain BEFORE you could register it. The enforecement of this STANDARD
>>>> ceased at some point (that was stupid), which is part of the reason that
>>>> speculators, ransomers, and cybersquatters came into prominence.
>>>>
>>>> How many people here remember the days when providers would register a
>>>> domain for you (for free they said, and then you would get the bill from
>>>> NSI)? That still worked within the model because they would set up the
>>>> NS's (and your website- which is what they were in business for) and you
>>>> would have nameservers answering auth. The registrant's provider would be
>>>> correctly listed as the tech contact, since it was their provider's BIND
>>>> boxes.
>>>>
>>>> I've had trouble with this for so long it's not even funny. But that's
>>>> beside the point. Because the user is too stupid or lazy to educate
>>>> themselves about something they have no business participating in unless
>>>> they do actually educate themselves, we now have a model where anyone can
>>>> register a domain that goes NOWHERE. and poor administrator's
>>>> nameserver -
>>>> possibly unbeknownst to them - is listed in the database's contact
>>>> information.
>>>>
>>>> Notwithstanding the appaerent obviousness that I have finally succumbed to
>>>> accept this, especially since if we enforced the standards which are still
>>>> in effect the domain might not still be available by the time you set up
>>>> the NS's and go back to register the doman, it is WRONG that we turn a
>>>> blind eye and permit villains to list the nameservers of innocent admins
>>>> who are unaware and leave them without recourse to initiate revocation
>>>> proceedings for the registration(s) of these nefarious registrants.
>>>>
>>>> Screw the registrants privacy, let them get a PO BOX and answering
>>>> service, or subscribe to a privacy bureau so that an effective method of
>>>> contacting them is secured, yielding a non-fruadulent contact record
>>>> (Apologies if I sound a bit like Marie Antoinette).
>>>>
>>>> We have, by not adhering to well imposed standards, shaken hands with a
>>>> demon known by the name of "Complete Disregard". This villain's ability to
>>>> list my friends nameservers is the reason that she is threatened with the
>>>> potential blocking by several other networks and I want to know what it is
>>>> that we can do here with TUCOWS to initiate and secure the revocation of
>>>> domains belonging to such calculated and unscrupulous abusers (frauds).
>>>>
>>>> 1.) Please list the steps which one can follow (even if she is not an
>>>> OpenSRS reseller) to have these domain registrations revoked.
>>>>
>>>> 2.) Please preserve confidence wrt our commitment to excellence by
>>>> enforcing at least this aspect of the standards (revocation of domain
>>>> registration due to fraudulent registrant information).
>>>>
>>>> 3.) And please, let's talk about instituting an operationally viable
>>>> system of "POST REG NS VERIFICATION" that will enforce the requirement of
>>>> nameservers in whois to answer AUTH for a domain - I would suggest, say, a
>>>> week or so following registration that nameservers must answer auth or the
>>>> registrant forfeits the domain registration w/o refund.
>>>>
>>>> a.) it's not hard to do.
>>>>
>>>> b.) it's been done in the past (especially in europe)
>>>>
>>>> c.) it's a variation on what we're supposed to be enforcing
>>>> anyway.
>>>>
>>>>
>>>> I know I don't spend a lot of time here in this list, but I AM one of the
>>>> first of Tucows OpenSRS resellers that ever went online, and I think that
>>>> this experience should serve to convey that I have SOME experience in this
>>>> sector.
>>>>
>>>> So Once again, how do we make the revocation of domain regsitrations with
>>>> fraudulent contact info easy and accessable for people like my friend that
>>>> has been damaged (Monetarily mind you) by the way our system has been
>>>> implemented?
>>>>
>>>> Sincerely,
>>>>
>>>>
>>>> Bradley D. Thornton
>>>> CTO: The PacificRoot / Joint Technologies Ltd.
>>>> [EMAIL PROTECTED]
>>>> http://www.PacificRoot.com
>>>> http://www.Jointtech.com
>>>>
>>>>
>>>>
>>>
>>>
>>
>
