RE: ICANN warns world of domain hijacking
> > Is ICANN actually going to come up with a set of guidelines > . ? Yes - the report has some guidelines. The plan is to make these guidelines easily available to suppliers that provide domain name services. Making them enforceable will take longer, and will be done if the guidelines are not successful in getting change. Regards, Bruce
RE: improving the registrar transfer process
Hello William, > 1. MIT receives transfer request from reseller 2. MIT sends > email confirmation to whois contact (which contact - tech, > admin?) Melbourne IT would collect the WHOIS information for the particular domain name. We would store the critical details. For .com names, we would send the email confirmation to the: Admin Contact email address The email confirmation uses this format: http://www.icann.org/transfers/foa-auth-12jul04.htm The standard form ensures that the registrant is giving explicit authorisation for the transfer and not something else (e.g a renewal). The email confirmation has a unique link (with unique code) to a Melbourne IT website. The web page again includes the authorisation information. (in the case of a name for an EPP registry, you would also be asked for the AUTH-INFO password) We would log the authorisation along with the IP address used to access the website. > 3. MIT sends email (or is it request through Verisign RRP?) > to Verisign MIT would send an RRP command to the Verisign registry. 4. The Verisign registry checks to see if the name is on Registrar LOCK. If the name is on LOCK, the RRP command will fail. 5. If the name is not on Registrar LOCK< the registry sends an email notification to both the losing and gaining registrar. I have already sent a copy of the notification used in the panix.com case. 6. MIT then waits for confirmation from the registry that the transfer is complete. This usually takes 5 days, although a losing reigstrar can explicitly confirm a transfer. > > I also would like to confirm who is responsible for denying > transfer request if LOCK is present. The registry does this. Regards, Bruce Tonkin
RE: Gtld transfer process
Hello Mark, > That's what happened last weekend: Martin Hannigan and I got > the ball rolling on Sunday morning about 1000 EST. Our 24x7 > customer service department contacted Dotster and Melbourne > IT. Melbourne IT changed the panix.com name servers back to > their original settings and transferred the domain back to Dotster. > I can confirm that Verisign did get in touch with our Production Manager (Peter Berry) around 1pm Sunday (New York time), and our Reseller Program Manager (Steve Karabatsos) around 4:30pm Sunday (New York time). We were contacted previously by Panix around 5pm Saturday (New York time). I believe that Verisign complied with all their obligations with respect to the ICANN transfer policy, and Verisign was very cooperative in assisting us with the issue. Regards, Bruce
RE: improving the registrar transfer process
> > > > Accountability. Responsibility. > > I agree with you on this 100%. ICANN needs to enforce there > current policies. I agree too. > Look at totalnic/pacnames. They have been > refusing transfer requests years now until very very recent. > What has ICANN done about all those complaints and violations > that has been well documented? > nothing! > > ICANN needs to stop just accepting money and start enforcing > policies... > Interestingly, the ICANN equivalent in Australia (auDA), does pro-actively enforce policies, and even took Capital Networks to court on the basis that they could be de-accredited as a registrar for .au, if they continued not to allow transfers for .com. See: http://www.austlii.edu.au/au/cases/cth/FCAFC/2004/324.html The original judgment is at: http://www.austlii.edu.au/au/cases/cth/federal_ct/2004/808.html
RE: improving the registrar transfer process
Hello William, > > We know how to do 3-way handshakes. Rather a fundamental of > the Internet. So quickly folks forget > > We knew in advance that the VRSN/NetSol/whatever protocol was > terrible, and that the ICANN policy change was not going to > be helpful. The ICANN policy change had no impact on this particular incident. As the incident has been documented so far, the transfer would have occurred under both the old and the new policy. With respect to the protocol. An IETF process was used to develop the EPP protocol as a replacement for RRP. With respect to notifications of transfers, the new protocol handles this by a message queue at the registry. (ie email is no longer the mechanism). It might be useful to consider reviewing the protocol to ensure that a transfer cannot proceed unless the losing registrar system confirms receipt of the transfer request. Regards, Bruce
Ability to use and monitor LOCK status
> However, that still looks to me like "Users can only ask that > domains be locked." Unless you are claiming that users can > send the lock request directly to the registry, and monitor > its status. Only a registrar can send commands directly the registry. Different registrars offer different services. Most are now offering the ability for customer to put a name on Lock, and remove a name from lock using the normal online maintenance tools. The status of LOCK is published in the Registry WHOIS service, although this display is not in real-time (ie believe it is updated once a day). Registrars have real-time access to the lock status of a name under their management. Regards, Bruce
Confirmation of receipt of the transfer request at Verisign for panix.com
When a registrar sends a transfer request to the registry operator (and the name is not on Registrar LOCK), the registry operator sends a confirmation email to both the losing and gaining registrar. Here is the copy of the email Melbourne IT received. Regards, Bruce Tonkin From [EMAIL PROTECTED] Sun Jan 9 12:40:35 2005 Return-Path: <[EMAIL PROTECTED]> Received: from verisign-grs.org (snoopy.verisign-grs.net [192.153.247.4]) by galahad.inww.com (8.12.9/8.12.9) with SMTP id j091eYgt003545 for <>; Sun, 9 Jan 2005 12:40:35 +1100 (EST) Date: Sat, 8 Jan 2005 20:40:34 -0500 From: [EMAIL PROTECTED] Message-Id: <[EMAIL PROTECTED]> To: Melbourne IT Reply-to: [EMAIL PROTECTED] Subject: Receipt of Transfer Request: PANIX.COM Transfer Request for: Domain Name: PANIX.COM Requesting Registrar: Melbourne IT, Ltd. d/b/a Internet Names Worldwide Current Registrar: Dotster, Inc. The VeriSign Global Registry Services has received your request to modify the domain name record for PANIX.COM to reflect the fact that the registrant has selected you to be its Registrar. By submitting the request using the "Transfer" command in the RRP, you have represented to the VeriSign Global Registry Services and the Current Registrar that (1) you have obtained the requisite authorization from the domain name registrant listed in the database of the Current Registrar, and (2) you have retained a copy of reliable evidence of the authorization. Pursuant to established procedures, the VeriSign Global Registry Services has notified the Current Registrar of your request. If we receive an Affirmative response to our notice within five (5) calendar days, we will make the change to the domain name record. If we receive a negative response to our notice within five (5) calendar days we will decline to transfer the domain name. If the Current Registrar takes no action within five (5) calendar days, we will make the change to the record. Sincerely, VeriSign Global Registry Services www.verisign-grs.com [EMAIL PROTECTED]
RE: Regarding registrar LOCK for panix.com
Hello William, > > Stop blaming the victim! Stop blaming anybody else. > I at no stage have blamed the victim. In fact I am sincerely sorry for the damage caused to panix.com. The transfer should NEVER have been initiated. Melbourne IT has consistently acknowledged the error. I have however discussed the problem from the point of view of the overall transfer process, as I want to improve it. There have been claims made on the list that the other parts of the system did not work. I am providing factual information on what happened through the process, and exposing the process to public review on this list. I have pointed out that the process can be strengthened. This is in no way blaming the victim. It is the role of domain name registrars to educate the registrants on their options. To reiterate, for a .com name there are two optional checks/mechanisms that can be used to further prevent an unauthorised transfer (and I will say again, I agree that the transfer should not have ever been initiated). (1) A name may be placed by a registrar on Registrar-LOCK. This is optional, and it is up to a registrar to inform their customers of this option. The name was not on Registrar-LOCK at the time of the transfer request. (2) The Registry must advise the losing registrar of a transfer request. I believe this happened, as I have a copy of the corresponding email sent from the registry to the gaining registrar. This does not mean that the losing registrar actually received this email. (3) The losing registrar MAY (ie it is an option available to the losing registrar but not a requirement) send a confirmation message to the registrant. In this case it appears that this did not happen, possibly because the confirmation message in (2) was never received by the losing registrar. There is no end-to-end confirmation in the current RRP system, for Verisign to be able to confirm that the losing registrar actually received its notification. To repeat again, I am not trying to escape any blame, not cast any blame on any other party. I am interested from an engineering point of view in improving the process to avoid it happening again. Regards, Bruce
Regarding registrar LOCK for panix.com
> > On Wed, 19 Jan 2005, Darrell Greenwood wrote: > > customers' domains. Panix.com says its domain name was locked, and > > that despite this, it was still transferred. (r) > > I seem to recall someone saying it wasnt locked, now theyre > saying it was? The information we have so far, indicates that it was not on Registrar LOCK at the registry at the time of the transfer. Regards, Bruce Tonkin
RE: EPP minutia (was: Re: Gtld transfer process)
Hello John, > > It appears that "REGISTRAR LOCK" has interesting > per-registrar implementation variations which do not always > put the domain holder's interests first. While the registry > does not, per se, have a direct business interest with the > domain holder, it should be possible to have a lock state > which is more oriented to the critical needs of some business > domain holders. > > For a reasonable fee (and copious amount of documentation), > it should be possible for any record holder to instruct the > registry to lock the ownership of a domain down in such a way > so as to require a similar amount of paperwork to release; > thus effectively creating an "OWNER LOCK" state. > These services are actually already available in the competitive registrar market. It is a matter of choosing a registrar that has the right business model and services to suit the registrant. Many corporates already take advantage of such services. Regards, Bruce
RE: Gtld transfer process
Hello Thor, > > > > (5) The registry will send a message to the losing registrar > > confirming that a transfer has been initiated. > > Can you confirm or deny whether this actually happened in the > case of the panix.com transfer? I don't have any direct visibility over this. I have asked Verisign and Dotster if they can confirm. My personal view is that I think it unlikely that this part of the system failed. Note however that Verisign would send the message via email to Dotster. Verisign could prove that they sent the email, but it is possible that it was not delivered. > > The other problem I see in this area is that the RRP > specification (if that is in fact the protocol that was used) It was. > seems to claim that this message is out-of-band and thus > beyond the scope of the protocol: so it does not (can not) > specify an ACK. If an attacker found a way to prevent this > message from being received, even if generated... > > A strictly enforced technical requirement for an ACK here > might work wonders (perhaps it would have to be enforced by > duping both the confirmation and the ACK to the "System", as > RRP so quaintly calls it, and denying future transfers > initiated by parties with too many outstanding ACKs). Not an > approval, just an ACK. Rather than further work on the RRP protocol, it would be better for Verisign to implement the EPP protocol which has gone through the IETF process. Regards, Bruce
RE: Gtld transfer process
Hello William, Thanks for your suggestions. Comments below. > > I would propose the following: > > 1. Keep existing model but make it "SHOULD" for old registrar > to inform >of upcoming transfer (I still don't understand how that failed in >panix.com case BTW, because I'm pretty certain dotster does it, the >only thing I can think of is that they did but answer was > lost among >all the spam that hostmaster account received). Sounds reasonable. > > 2. Allow for fast way to reverse the domain transfer for old register. >I'd propose the following: > a. Old registrar can use special registry function to request >reversal within 5 days of the transfer and that is immediatly >granted (no questions asked at that time) with > immediate restoration >of old NS servers Might be better to simply revert the NS records at the request of the original registrar, and then place the name on registry lock until the dispute is resolved.Note for URDP disputes a name is typically locked by a registrar (although the current NS record state is retained). Most of the other steps regarding provision of evidence and full-rollback to the original registrar are covered under the existing transfer dispute policies. The detailed process is documented here: http://www.icann.org/transfers/dispute-policy-12jul04.htm Regards, Bruce
RE: EPP minutia (was: Re: Gtld transfer process)
Hello Eric, Thanks for your descriptions from an operator and web-hosting company perspective. Essentially different customers have different needs. Some that value price higher than reliability/security are likely to want to easily move names around depending on renewal prices and the prices of other services. Others value reliability/security very highly, and prefer to stay with one reliable provider, and will pay a premium for that provider to put in place strict change management procedures. In terms of the second category many registrars (including Melbourne IT) offer services tailored to the corporate market that incorporate change management processes, often with dedicated staff that are trained in such procedures. The transfers policy therefore needs to be able to support both types of registrant, and in particular allows the registrant to control the choice of processes. In the past some registrars have imposed their own strict processes (for example requiring a judge to approve any changes of registrar) that are not in accordance with the wishes of the registrant. Often these processes for registrar change are not in proportion to the processes for change of delegation etc. Generally a corporate wanting high security/stability will want strict change management across all processes, rather than a registrar accepting a delegation change over the phone without authentication, but requiring a judge to approve a transfer. A registrar wishing to offer a customer a high level of protection must be able to set a flag in the registry that prevents a transfer. This is the Registrar-LOCK function. Now I agree this still requires the registrar to have strict process control on how this flag can be set/cleared. The policy requires that a registrar provide a mechanism for a registrant to unlock a name that is consistent with other processes - e.g delegation for that name/registrant. Regards, Bruce
RE: Gtld transfer process
Hello Brandon, Thanks for your feedback. > > My experience has been that getting auth_info (which criminal > staff would have access to) from bad registrars is almost > impossible, with registrar-LOCK too they have enough control > to negate the gain in being able to pull a domain to a new > registrar - you still need the cooperation of the old one so > it's just as bad as the old way but lots more risk for everyone > > EPP is thus of no advantage and registrar pull is dangerous Thus are you basically proposing that the registrant rely on cooperation with the old registrar, and if that fails, rely on ICANN to enforce compliance if the old registrars doesn't cooperate? I think in any model, unless ICANN enforces compliance the model will fail. We use the EPP model with registrar pull in Australia, and I haven't heard of any recent instances of abuse. There is no mechanism for the losing registrar to deny a transfer. The difference is that the ICANN equivalent in Australia (auDA) rigorously enforces compliance by the gaining registrar. Regards, Bruce
RE: Gtld transfer process
Hello Alexei, > > Problem - you are talking about changing registrar, but in > reality you describe changing of domain owner. Yes you are right in that often a number of domain name variables change at around the same time. > > Why (what for) is it allowed to transfer from one registrar > to another with changing NS records and other owner information? Usually it is NS records that change, as a transfer can be associated with moving a domain name to a new service provider for email or web hosting. It is often the change in other services that prompts the transfer request in the first place. > Why don't separate this 2 events - changing registrar, and > changing domain owner/information? Is it any need in reality > changing registrar with simultaneous changing domain information? > I agree with respect to "ownership" change that this should be separated by some time period from registrar transfer. Note that only the registrar transfer process is regulated by the ICANN agreements. Apart from changes in the identity of the legal holder of the domain name agreement, other details such as postal address, phone numbers and email addresses are often updated at the time of customer contact with respect to the transfer. Usually this information represents the most up-to-date contact information. > What should happen in normal situation: > - someone requested transfer of domain (without real authorisation); > - even if all checks pass and transfer was allowed, new > registrar should maintain the same NS and other information > as old one, so no real damage could happen; > - domain owner received e-mail, see frauded transfer and > disputed it (having domain in working condition on the new registrar); > - new registrar OR old registrar OR VeriSign roll back transaction. This is effectively what happened in the panix.com case. As soon as facts were verified the NS records were rolled back by the gaining registrar to their previous state. The issue was that it took hours to occur. It is a separate discussion as to whether the registry operator (Verisign in this case) should do this roll back in the case of a network outage in the absence of instructions from registrars. Regards, Bruce
Gtld transfer process
o and WITH the use of registrar-LOCK is a reasonable balance between security and allowing registrants to easily move their name. Areas for further improvement include having an expedited process for managing a fraudulent transfer - including the ability to quickly revert back to the previous DNS information while a dispute is investigated, and having mechanisms to ensure that 24/7 emergency contacts are available for all registrars at the registry. I am interested to hear what members of the NANOG list believe would be a better transfers process. Regards, Bruce Tonkin
RE: Regarding panix.com
Hello Matthew, > > > What sort of support would you give a not-for-profit Org such > as SORBS.net or an Org such as Spamhaus.org if our domains > were hijacked maliciously (or not)? As others have pointed out, any procedures will need to ensure that they can be applied to all domain name records. > > I note that Spamhaus.org is set 'CLIENT TRANSFER PROHIBITED' > and 'CLIENT UPDATE PROHIBITED' so in theory this shouldn't be > a problem, but the various earlier comments indicating that > panix.com was thought to be 'LOCKED' before the issues of the > last few days provide more food for thought. > I doubt that panix.com was "LOCKED" at the registry, as the transfer could not have been initiated. Some registrars use the term "lock" to refer to an internal security procedure that is unrelated to a lock that can be placed on the name in the registry. Note that different registries have different locking mechanisms. Regards, Bruce Tonkin
RE: Regarding panix.com
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. As an update, the transfer back has now been completed. Regards, Bruce
RE: Regarding panix.com
Hello All, I have had a few emails regarding a perception that we have limited support to deal with issues such as panix.com, so I will just set the record straight. We provide a standard first level retail customer service line 24 hours by 5.5 days. (which gives business hours service in all world time zones). We provide 24 hour by 7 day customer service for resellers (typically ISPs, web hosting companies etc). We provide 24 hour by 7 day second level technical operations support. Most major registrars and ICANN have direct contacts into the technical parts of Melbourne IT.I received notification from several parties via email (but I don't read email 24 hours a day). We are looking at our processes to ensure that incidents such as occurred with panix.com can be addressed more quickly within Melbourne IT, and also checking to ensure that an appropriate number of external people have access to the right contacts at Melbourne IT to fast track serious issues. Regards, Bruce Tonkin Chief Technology Officer Melbourne IT
Regarding panix.com
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
