The entire mechanism is Wrong!

Gentlemen and Ladies,

I concur with the view expressed by Bob Fox (IANA-134), that the
"current method only favours Verisign and crooks."

The hijacking of panix.com, and the post-hijacking response of VGRS,
which could unilaterally act, but choses not to, for its own reasons,
and MelburneIT, which could unilaterally act, but choses to not act
until 72 hours after being noticed, if then, is a counter-example to
any claim that the current method has any rational application to
domain names that are "mission critical", that is, used for something
other than proping up some shoddy trademark claim by some party that
doesn't even use the dns for core operational practice.

It doesn't reflect very well on the registries and registrars either.

Eric Brunner-Williams
CTO Wampumpeag, LLC
Operator, USA Webhost, IANA-439, CORE-124

Eric Brunner-Williams in Portland Maine wrote:

Gentlemen and Ladies,

I concur with the view expressed by Bob Fox (IANA-134), that the
"current method only favours Verisign and crooks."

The hijacking of panix.com, and the post-hijacking response of VGRS,
which could unilaterally act, but choses not to, for its own reasons,
and MelburneIT, which could unilaterally act, but choses to not act
until 72 hours after being noticed, if then, is a counter-example to
any claim that the current method has any rational application to
domain names that are "mission critical", that is, used for something
other than proping up some shoddy trademark claim by some party that
doesn't even use the dns for core operational practice.

It doesn't reflect very well on the registries and registrars either.

Eric Brunner-Williams
CTO Wampumpeag, LLC
Operator, USA Webhost, IANA-439, CORE-124

Do you mean by that the "No-Hijack" bit be set by default?
Or perhaps do you mean previous owners can call in a "stop order" or "dispute" the transfer unilaterally within X days of occurence, much like it works for many REAL money transactions?

How are trademark domains relevant to panix.com?

Joe

Joe Maimon <jmaimon@ttec.com> writes:

Or perhaps do you mean previous owners can call in a "stop order" or
"dispute" the transfer unilaterally within X days of occurence, much
like it works for many REAL money transactions?

That makes considerable sense. You should be able to call in, say
"roll it back", and have it stay rolled back for a few days until
someone can investigate.

If people like Melbourne IT are going to claim they can't act on
weekends, it might also be sensible not to allow transfers to be
processed between Thursday and Sunday, though honestly I think if you
are going to be a registrar, you are going to have to deal with
problems over weekends.

One more disturbing problem here -- it seems (based on external
evidence) that someone managed to fake out the system. Although
Verisign and Melbourne IT seem to think that the transfer was
approved, neither Dotster nor Panix have any record at all of
it. Dotster's records make them think they are still the registrar for
panix.com. It appears someone cracked the system, though whether by
exploiting protocol problems or in some other way isn't clear at all.

Perry

Once upon a time, Perry E. Metzger <perry@piermont.com> said:

If people like Melbourne IT are going to claim they can't act on
weekends, it might also be sensible not to allow transfers to be
processed between Thursday and Sunday, though honestly I think if you
are going to be a registrar, you are going to have to deal with
problems over weekends.

We're a relatively small ISP compared to many on NANOG, but we have a
24x7 on-call system with an answering service. All domain registrars
should be required to have 24x7 service.

The GTLD (and other TLD) servers have a 2 day TTL on all records; if
panix.com was fixed right now it would be Tuesday before everyone saw
it. How hard would it be for Verisign (and other registries) to have
the TTL "ramp up" after a change? In other words, when the NS records
for domain.com get changed (but not after an initial registration), put
them in the .com zone initially with a short TTL, maybe 6 hours, and
then after 2 days move the TTL up to 12 hours, after another 2 days move
it to 24 hours, and then after a week total move it to 2 days. How much
more load would that really cause? Especially with the "streamlined"
transfer procedure now in place, this would be a very good idea.

I agree they should have 24/7 support.

Just remember that, as an example, Melbourne IT has probably two orders
of magnitude more clients than you. A 24x7 pager service would attract
a /lot/ of "Emergencies" and as such they'd have to consider running
at least a muppet level call service outside of hours to filter
"emergency" requests away from the normal signup procedures and over
to the People Who Really Fix Things.

Adrian

Adrian Chadd wrote:

I agree they should have 24/7 support.

Just remember that, as an example, Melbourne IT has probably two orders
of magnitude more clients than you. A 24x7 pager service would attract
a /lot/ of "Emergencies" and as such they'd have to consider running
at least a muppet level call service outside of hours to filter
"emergency" requests away from the normal signup procedures and over
to the People Who Really Fix Things.

I'm not saying MIT needs 24x7 support, I am saying they need on-call staff. One person might be enough; perhaps more than one may be needed. (A couple people called me on this point offlist and I felt the need to clarify my opinion.)

I resell GoDaddy and they do have 24x7 customer support, but I don't think that's necessary to properly run a registrar. Just have X people available to deal with emergency situations. X will vary based on the size of the customer base.

Just remember that, as an example, Melbourne IT has probably two orders
of magnitude more clients than you. A 24x7 pager service would attract
a /lot/ of "Emergencies" and as such they'd have to consider running
at least a muppet level call service outside of hours to filter
"emergency" requests away from the normal signup procedures and over
to the People Who Really Fix Things.

Of course it's unreasonable to expect a registrar to have to
put up with such a burden during off hours: God only knows what
kind of silly calls would come in. "Emergencies" are best
handled in a batch during the regular work week. For the
stuff that really won't wait, you just put a lawyer on retainer,
who can fax off a letter telling the complainant to sod off until
Monday morning, or until the moon is in the seventh house and Jupiter
aligns with Mars, whichever comes first.

I mean, if we can't be on the golf course by 3:00, what are we
in this business for, anyway -- right?

Jim Shankland

Joe Maimon <jmaimon@ttec.com> writes:
> Or perhaps do you mean previous owners can call in a "stop order" or
> "dispute" the transfer unilaterally within X days of occurence, much
> like it works for many REAL money transactions?

That makes considerable sense. You should be able to call in, say
"roll it back", and have it stay rolled back for a few days until
someone can investigate.

It is exactly what I was talking about.

If people like Melbourne IT are going to claim they can't act on
weekends, it might also be sensible not to allow transfers to be
processed between Thursday and Sunday, though honestly I think if you
are going to be a registrar, you are going to have to deal with
problems over weekends.

It is their dirty problem - if they can not act on weekend, they can not
maintain a registry, that's all.

One more disturbing problem here -- it seems (based on external
evidence) that someone managed to fake out the system. Although
Verisign and Melbourne IT seem to think that the transfer was
approved, neither Dotster nor Panix have any record at all of
it. Dotster's records make them think they are still the registrar for
panix.com. It appears someone cracked the system, though whether by
exploiting protocol problems or in some other way isn't clear at all.

If I am allowed to say my personal opinion here - it more likely was a
technical bnug or human mistake, not a hack. But let's see. This case
shiould be carefully investigated, no matte if this transfer was legal or
not.

The registrar DOES need to define "Emergency."

"Emergency" does not mean "page on-call staffers because I forgot to renew
my domain and it's fallen out of the roots, and Customer Service is closed
Saturday." Such an event is defined as being "My Own Fault, Not Due to
Catastrophic Conditions" and doesn't warrant bugging the person on-call.

As long as the registrar defines what constitutes a page-able emergency,
they should be ok. (Or is this overly simplistic?)

ime, the act of defining 'emergency' does not provoke compliance therewith.

-p

provided their contract requires some form of 24/7 support, and there is
an SLA to manage that requirement. If there isn't then there is no need
for 24/7 support (no contractual reason), it just becomes a business
differentiator for clients when chosing registrar X or registrar Y

(or so it seems to me)

Except those clients get affected when something like this happens..
Even if Company A decided to go with Registrar X because they have 24/7
support, if that domain gets moved to Registrar Y and it was not
intended to (malicious intent, technical error, whatever...), it
suddenly doesn't matter if they chose X does it?

Then you miss the point that there was no contractual relationship
between the real PANIX and MelbourneIT, yet in the first instance it
was MelbourneIT that needed to respond so that an investigation into
this unfortunate incident could be started.

However excellent the SLA that a domain owner may have with their
registrar, it is inevitably of no value when the central system is
compromised (as appears on the surface to have been the case here).

Your argument would have been completely sound if, in addition to
whatever level of customer support they choose/contract to provide,
there were an obligation for every accredited registrar to guarantee
a response within a given timescale and on a 24/7 basis, to any
emergency request received from any other accredited registrar.

Indeed, such may already have been the case. Fire Drills have a habit
of discovering shortcomings within well-planned emergency arrangements!

Richard Cox wrote:

... there were an obligation for every accredited registrar to guarantee
a response within a given timescale and on a 24/7 basis, to any
emergency request received from any other accredited registrar.

That "given timescale" is often called a "standard of promptness" in
contracts. So, I'll agree on the point, and note that for government
24/7 service contracts that I've been involved with, 4 hours was the
time limit, after which there were financial penalties.

However, I disagree on the place where the responsibility lies.

The Registry is the party that must revert the data to the previous
state. For the stability of the Internet, it must be done as quickly
as possible before old correct caches time out. Therefore, that's
where the penalties should apply.

Keeping in mind the actual TTLs used today, I propose:

(1) a 2 hour standard of promptness for the Registry, starting
from initial revert notice from any Point of Contact (the domain
holder or the domain registrar).

(2) a 4 hour standard of promptness for all Registrars, starting
from initial notice of any kind. That gives them enough time to:

   (2a) initiate a revert with the registry immediately, and then

   (2b) reinstate the data when the revert turns out to be bogus.

This will work even in the cases where the bogus domain registrant
submits false contacts, such as happened in panix.com. There
shouldn't be any reason to delay reversion to a known former state.

Oh, I'd be willing to specify 1 and 2 hours, respectively, but doubt
the registry and registrars would -- 2 and 4 is conservative.

Bill,

   You indicate "a" known former state, which implies that you'd allow
   reverting back multiple changes under your proposed scheme...

   Out of curiosity, how far back would you allow one to revert to?
   Any previous state within the last two weeks? Longer, or shorter?

   Given the potential for disruption through fraudulent demands
   to revert, one has to carry over previous servers for at least this
   interval to be safe, or do I misunderstand your proposal?

/John

Bill,

  I'm not speaking for Bill. These are my views.

   You indicate "a" known former state, which implies that you'd allow
   reverting back multiple changes under your proposed scheme...

  You would have to. Otherwise, two quick transfers would defeat the scheme.
An alternative approach would be to prohibit a transfer within one week of
another transfer.

   Out of curiosity, how far back would you allow one to revert to?
   Any previous state within the last two weeks? Longer, or shorter?

  I would say two weeks would be a reasonable maximum. One week would be a
reasonable minimum. One could also do it in terms of business days, but I
think this may cause confusion with international issues and which days
count as business days.

   Given the potential for disruption through fraudulent demands
   to revert, one has to carry over previous servers for at least this
   interval to be safe, or do I misunderstand your proposal?

  This would mean that a transfer would not really be final for some number
of days after the transfer was initiated. This would, of course, create a
new problem with fraudulent reverts. A no questions asked revert policy
would create one class of problems, whereas a requirement for proof for
reversion would create another class.

  I personally think the best solution is as follows:

  1) A domain cannot be transferred within one week of a previous transfer.

  2) Once a domain that was in normal status has been transferred, it can be
reverted by request of the losing registrar for one week from the time of
the transfer, no questions asked, as soon as possible. (Should Verisign do
this? Or the losing registrar through an automated interface?)

  3) If the gaining registrar questions the reversion, the losing registrar
must then provide proof of request for reversion from the previous owner and
the gaining registrar can provide proof of release from the previous owner.
Some method to resolve this dispute would be needed. Perhaps arbitration at
the initial expense of the gaining registrar (who could, of course, bill
their customer however they choose). The arbitrator could award costs to the
winner of the dispute (in case of total bogus reversion requests).

  This would allow people to protect valuable domains by picking registrars
with sensibe reversion policies. It would also prevent dishonest registrars
from holding domains through reversion without authorization, though they
could impose costs on the gaining registrar if they wished).

  The downside would be that when you acquired a new or newly-transferred
domain, you would want to wait a week before using it for anything mission
critical. You also couldn't consider the act of transferring a domain proof
positive of intent to give it to you. You might want to wait a week before,
for example, making payment. Or you would want to possess proof of the
owner's intent to transfer, not just proof of a transfer.

  David Schwartz
  <davids@webmaster.com>

The new (read: current, now) ICANN transfer policy does this. Transfers cannot occur within 60 days of another transfer. I belive this portion of the policy was put in specifically for this reason.

Tim Wilde

Paul G wrote:

ime, the act of defining 'emergency' does not provoke compliance therewith.

Of course. It must be enforced. How, I'm not sure at this point (and not being an employee of a company acting as registrar or registry, I'm not sure I'd be able to offer any constructive suggestions as to how to enforce it).