January 2005 - Test - lists.nanog.org

Panix.com should be back.
by Majid Farid 17 Jan '05

17 Jan '05

I see that DNS changes has been reverted http://www.dnsreport.com/tools/dnsreport.ch?domain=panix.com I have also contacted our Customer owner of ns1.ukdnsservers.co.uk [panix.com] (142.46.200.67) they have assured me they will remove the DNS config as well. Sorry for the last response I was away for weekend. -- Majid Farid Telecom Ottawa Limited. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Gadi Evron Sent: Sunday, January 16, 2005 7:24 PM To: nanog list Subject: domain hijacking - what do you do to prepared? Until today, I considered this to be a real and relevant threat, although rather low in my matrix. As someone I know said today, now that kiddies saw how much "fun" this is, I am sure they will attempt this again. The question that comes to mind is - what do you do to be prepared? I suppose that other than setting registrar lock in place, there is another thing one can do. Study! Whether it's checking the expiration date for your domain, establishing contact with your up-in-line authority - registrar, tld, etc. depending on who you are. Having the relevant contact information at hand, establishing a set policy on how to handle such an incident and who to contact, bugging your next-in-chain about setting a policy on this with you, as well as setting such a policy for those who are slaves to you. That said, all that is left now is to see how this happened (so that it won't happen again - just killing a fire doesn't mean it won't be re-ignited) and perhaps think a bit on how we do things - which I am sure many will now do. Maybe this can be another discussion issue for the next NANOG get-together as well? Gadi.

3 2

RE: Panix.com should be back.
by Majid Farid 16 Jan '05

16 Jan '05

I regret not being around earlier. -- Majid -----Original Message----- From: Hannigan, Martin [mailto:hannigan@verisign.com] Sent: Sunday, January 16, 2005 11:03 PM To: Majid Farid; 'nanog(a)merit.edu' Subject: Re: Panix.com should be back. Thanks Fared for your assistance. Ypu are great among a bunch of helpers. Cheers, -M --- Martin Hannigan hannigan(a)verisign.com Verisign, Inc. -----Original Message----- From: owner-nanog(a)merit.edu <owner-nanog(a)merit.edu> To: nanog list <nanog(a)merit.edu> Sent: Sun Jan 16 19:57:54 2005 Subject: Panix.com should be back. I see that DNS changes has been reverted http://www.dnsreport.com/tools/dnsreport.ch?domain=panix.com I have also contacted our Customer owner of ns1.ukdnsservers.co.uk [panix.com] (142.46.200.67) they have assured me they will remove the DNS config as well. Sorry for the last response I was away for weekend. -- Majid Farid Telecom Ottawa Limited. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Gadi Evron Sent: Sunday, January 16, 2005 7:24 PM To: nanog list Subject: domain hijacking - what do you do to prepared? Until today, I considered this to be a real and relevant threat, although rather low in my matrix. As someone I know said today, now that kiddies saw how much "fun" this is, I am sure they will attempt this again. The question that comes to mind is - what do you do to be prepared? I suppose that other than setting registrar lock in place, there is another thing one can do. Study! Whether it's checking the expiration date for your domain, establishing contact with your up-in-line authority - registrar, tld, etc. depending on who you are. Having the relevant contact information at hand, establishing a set policy on how to handle such an incident and who to contact, bugging your next-in-chain about setting a policy on this with you, as well as setting such a policy for those who are slaves to you. That said, all that is left now is to see how this happened (so that it won't happen again - just killing a fire doesn't mean it won't be re-ignited) and perhaps think a bit on how we do things - which I am sure many will now do. Maybe this can be another discussion issue for the next NANOG get-together as well? Gadi.

1 0

Re: Panix.com should be back.
by Hannigan, Martin 16 Jan '05

16 Jan '05

Thanks Fared for your assistance. Ypu are great among a bun --- Martin Hannigan hannigan(a)verisign.com Verisign, Inc. -----Original Message----- From: owner-nanog(a)merit.edu <owner-nanog(a)merit.edu> To: nanog list <nanog(a)merit.edu> Sent: Sun Jan 16 19:57:54 2005 Subject: Panix.com should be back. I see that DNS changes has been reverted http://www.dnsreport.com/tools/dnsreport.ch?domain=panix.com I have also contacted our Customer owner of ns1.ukdnsservers.co.uk [panix.com] (142.46.200.67) they have assured me they will remove the DNS config as well. Sorry for the last response I was away for weekend. -- Majid Farid Telecom Ottawa Limited. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Gadi Evron Sent: Sunday, January 16, 2005 7:24 PM To: nanog list Subject: domain hijacking - what do you do to prepared? Until today, I considered this to be a real and relevant threat, although rather low in my matrix. As someone I know said today, now that kiddies saw how much "fun" this is, I am sure they will attempt this again. The question that comes to mind is - what do you do to be prepared? I suppose that other than setting registrar lock in place, there is another thing one can do. Study! Whether it's checking the expiration date for your domain, establishing contact with your up-in-line authority - registrar, tld, etc. depending on who you are. Having the relevant contact information at hand, establishing a set policy on how to handle such an incident and who to contact, bugging your next-in-chain about setting a policy on this with you, as well as setting such a policy for those who are slaves to you. That said, all that is left now is to see how this happened (so that it won't happen again - just killing a fire doesn't mean it won't be re-ignited) and perhaps think a bit on how we do things - which I am sure many will now do. Maybe this can be another discussion issue for the next NANOG get-together as well? Gadi.

1 0

Re: Association of Trustworthy Roots?
by Hannigan, Martin 16 Jan '05

16 Jan '05

I saw Martians this evening, just like the movie, but the country song didn't work. They -did- have big heads encased in glass. Go figure. -M --- Martin Hannigan hannigan(a)verisign.com Verisign, Inc. -----Original Message----- From: owner-nanog(a)merit.edu <owner-nanog(a)merit.edu> To: North American Network Operators Group <nanog(a)merit.edu> Sent: Sun Jan 16 19:39:01 2005 Subject: Re: Association of Trustworthy Roots? Christopher L. Morrow wrote: >On Sun, 16 Jan 2005, Chris Adams wrote: > > >>If the proper procedure was circumvented in the first place (which >>appears to be the case with panix.com) then it should be circumvented >>to repair the damage as fast as possible. >> >> > >If it can be proven to have been cicumvented, sure. I don't think anything >beyond conjecture about that has been said 'publicly' yet, has it? > > > Why yes, you must have missed the messages. The domain owner and ISP and registrar all clearly stated that they had received no notification, and had not approved the transfer. Notification and approval are required by the process. Therefore, it was proven to be circumvented. QED. Now, as to the actual mechanism of circumvention, that has not yet been revealed here. All we know is that a registry *supervisor* stopped the workers from finishing their investigation. Clearly, this .com registry operator is not trustworthy. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

1 0

Regarding panix.com
by Bruce Tonkin 16 Jan '05

16 Jan '05

Hello All, Melbourne IT restored the nameservers and contact details associated with this name first thing this morning (Monday in Melbourne, Australia). We are arranging with the previous registrar (Dotster) to have the name transferred back. We are also investigating the chain of events that led to the problem in the first place. This will take longer, due to the various timezones and parties involved. In this case one of the parties was an ISP in the United Kingdom, which is a reseller of Melbourne IT. Regards, Bruce Tonkin Chief Technology Officer Melbourne IT

3 2

Re: panix.com hijacked (VeriSign refuses to help)
by Thor Lancelot Simon 16 Jan '05

16 Jan '05

Alexis Rosen tried to send this to NANOG earlier this evening but it looks like it never made it. Apologies if it's a duplicate; we're both reduced to reading the list via the web interface since the legitimate addresses for panix.com have now timed out of most folks' nameservers and been replaced with the hijacker's records. Note that we contacted VeriSign both directly and through intermediaries well known to their ops staff, in both cases explaining that we suspect a security compromise (technical or human) of the registration systems either at MelbourneIT or at VeriSign itself (we have reasons to suspect this that I won't go into here right now). We noted that after calling every publically available number for MelbourneIT and leaving polite messages, the only response we received was a rather rude brush-off from MelbourneIT's corporate counsel, who was evidently directed to call us by their CEO. We are also told that law enforcement separately contacted VeriSign on our behalf, to no avail. Below please find VeriSign's response to our plea for help. We're rather at a loss as to what to do now; MelbourneIT clearly are beyond reach, VeriSign won't help, and Dotster just claim they still own the domain and that as far as they can tell nothing's wrong. Panix may not survive this if the formal complaint and appeal procedure are the only way forward. > Date: Sun, 16 Jan 2005 00:21:33 -0500 > To: <alexis(a)panix.com>, NOC Supervisor <nocsupervisor(a)verisign.com> > Subject: Re: FW: [alexis(a)panix.com: Brief summary of panix.com hijacking incident] (KMM2294267V49480L0KM) > From: VeriSign Customer Service <info(a)verisign-grs.com> > X-Mailer: KANA Response 7.0.1.127 > > Dear Alexis, > > Thank you for contacting VeriSign Customer Service. > > Unfortunately there is little that VeriSign, Inc. can do to rectify this > situation. If necessary, Dotster (or Melbourne) is more than welcome to > contact us to obtain the specific details as to when the notices were > sent and other historical information about the transfer itself. > > Dotster can file a Request for Enforcement if Melbourne IT contends that > the request was legitimate and we will review the dispute and respond > accordingly. Dotster can also contact Melbourne directly and if they > come to an agreement that the transfer was fraudulent they can file a > Request for Reinstatement and the domain would be reinstated to its > original Registrar. Dotster could submit a normal transfer request to > Melbourne IT for the domain name and hope that Melbourne IT agrees to > transfer the name back to them outside of a dispute having been filed. > In order to expedite processing the transfer or submitting a Request for > Reinstatement however Dotster will need to contact Melbourne IT > directly. If Dotster is unable to get in touch with anyone at Melbourne > IT we can assist them directly if necessary. > > Best Regards, > > Melissa Blythe > Customer Service > VeriSign, Inc. > www.verisign.com > info(a)verisign-grs.com

11 15

Melbourne IT
by Chris Cappuccio 16 Jan '05

16 Jan '05

Melbourne IT invites you to participate in a survey of brand recognition. Please let them know what the name "Melbourne IT" means to you. http://www.melbourneit.com.au/survey.php?type=brandhealth -- The past cannot be changed. The future cannot be guaranteed.

1 0

RE: Proper authentication model
by Hannigan, Martin 16 Jan '05

16 Jan '05

> -----Original Message----- > From: Joe Abley [mailto:jabley@isc.org] > Sent: Wednesday, January 12, 2005 12:05 PM > To: Hannigan, Martin > Cc: NANOG list > Subject: Re: Proper authentication model > > > > On 12 Jan 2005, at 11:53, Hannigan, Martin wrote: > > >> You mean you'd *request* a different path from different providers. > > > > Provisioning a circuit from two different ^providers^, other than > > your OC3 provider. > > I realise that's what you meant. > > My point was that competing, differently-named and > organisationally-separate suppliers of network services > frequently use > common suppliers for metro fibre, long-haul transport, > building access, > etc. Just because you buy different services from different providers > doesn't mean there will be no common points of failure. There may be common points of failure like a carrier hotel, but I haven't been told I couldn't see loop or longhaul maps when planning a circuit, except when buying from other than a carrier[1] or tier2. Primary and protect should be geographically seperated and if your carrier isn't buying access to BOTH conduits in your entrance facility, you should ask why. I just don't usually see this problem and I've *never* not been able to get into a facility remotely by the diversified frame M/S method. If we're talking semantics, order type 2 ds0s. [1] I'm talking RBOC tier1 for the most part. I would consider tier 1 to be SBC, AT&T, MCI, Sprint, etc. Facilities based. -M<

2 1

Re: panix.com
by Eric Brunner-Williams in Portland Maine 16 Jan '05

16 Jan '05

The outcome I expected when Bruce got involved. ------- Forwarded Message From: "Bruce Tonkin" <Bruce.Tonkin(a)melbourneit.com.au> To: "Eric Brunner-Williams in Portland Maine" <brunner(a)nic-naa.net> Cc: <smb(a)cs.columbia.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic-naa.net id j0GIZIlC038110 Hello Eric, Thanks for letting me know. We will ensure the name is restored to its correct status, and are investigating how the incident occurred. Regards, Bruce Tonkin > -----Original Message----- > From: Eric Brunner-Williams in Portland Maine > [mailto:brunner@nic-naa.net] > Sent: Sunday, 16 January 2005 10:49 AM > To: Bruce Tonkin > Cc: smb(a)cs.columbia.edu; brunner(a)nic-naa.net > Subject: panix.com > > Bruce, > > Steve just sent this note to NANOG. > > panix.com has apparently been hijacked. It's now associated > with a different registrar -- melbourneit instead of dotster > -- and a different owner. Can anyone suggest appropriate > people to contact to try to get this straightened out? > > --Prof. Steven M. Bellovin, > http://www.cs.columbia.edu/~smb > > I know Steve and you know me, so lets see if this is > malfesance or error. > > Eric > ------- End of Forwarded Message

1 0

apropos of nothing
by Eric Brunner-Williams in Portland Maine 16 Jan '05

16 Jan '05

Oki all, I was interested in a policy I came across recently at a cctld registry. If a domain has no (or few for some value of few) hits over some period of time post-registration, the registry will recover the string and let another user acquire it, and presumably actually use it. So if t = 3m, pokey.cctld could go to four users in the course of a single year, iff the first three made insufficient use of pokey.cctld during that time. I'm going to guess that panix.com is different from most of the multi-k domains that are dropping off the VGRS registry and into today's (well, yesterday's) drop pool, as measured by use. I'm going to guess that panix.com is different from most of the multi-k inter-registrar transfers of yesterday, today, and tomorrow, by the same use metric. IMHO, organizing policy around function, actually distinguishing between panix.com and the overwhelming majority of domain names for which some change of state at the registry occurs, is a better principle that to continue to organize policy around trademarks and their buyers and agents, indifferent to the frequency and distribution of use of a domain name. At some point, it really _is_ a name-to-addresss map, and not a cognate for a trademark-to-owner map. It is possible to distinguish risk, and a policy which chooses not to make distinctions isn't prudent. In case anyone's missed the obvious, we now have an incoherent dns, and caching resolver operators have introduced the incoherency, and no one in the operator community is visibly spitting blood at the intentional exception to rfc2826. This situation should not continue. Neither should the "new/hijacked" answers be served. Eric

1 0