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


I'd like to make a few comments about the transfer issue.

First, I can confirm that the domain was not in registrar
lock status at the time of the transfer.

Second, VeriSign did indeed send a transfer email to Dotster. The
logs below show the message to Melbourne IT that Bruce already posted
as well as the corresponding message to Dotster:

  To Melbourne IT:
  Jan 8 20:40:34 imx2 sendmail[19959]: j091eXp7019959:
  from=<>, size=1432, class=0, nrcpts=1,
  msgid=<>, proto=SMTP,
  daemon=MTA, [] Jan 8
  20:40:35 imx2 sendmail[19977]: j091eXp7019959:
  to=<>, delay=00:00:01,
  xdelay=00:00:01, mailer=esmtp, pri=30130, [], dsn=2.0.0, stat=Sent
  (2.0.0 j091eYgt003545 Message accepted for delivery)

  To Dotster:
  Jan 8 20:40:34 imx2 sendmail[19959]: j091eXp9019959:
  from=<>, size=1113, class=0, nrcpts=1,
  msgid=<>, proto=SMTP,
  daemon=MTA, [] Jan 8
  20:40:35 imx2 sendmail[19979]: j091eXp9019959:
  to=<>, delay=00:00:01, xdelay=00:00:01,
  mailer=esmtp, pri=30122,
  [], dsn=2.0.0, stat=Sent (2.6.0 Ok, id=31930-07, from
  250 Ok: queued as BF1E258415)

Third, every day VeriSign publishes a report for each registrar that
shows, among other things, a list of pending outbound transfers. We
have confirmed that appeared on Dotster's daily report as a
pending outbound transfer for five days. (We cannot publish Dotster's
reports without Dotster's permission.)

Finally, there were many people here at VeriSign working behind the
scenes over the weekend on this issue. Our ability to act
unilaterally is constrained as we follow the process within the
consensus policy for transfers--I hope everyone can understand and
appreciate this. But we can focus our efforts on opening
communications and working toward a resolution among the all parties.
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 name servers back to their original settings and
transferred the domain back to Dotster.