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.
Gadi,
> The question that comes to mind is - what do you do to be prepared?
Well, for a start you can put a comment into the ICANN comments on
the new xfr policy. I did earler today. Next, you can, as some today
did, decide that cache trumps authority under some conditions, and
ensure that cache is controlling when some conditions exist.
There are so many structural things wrong with the mechanisms this is
about like asking how to write cat in perl.
> I suppose that other than setting registrar lock in place, there is
> another thing one can do.
As soon as I saw the new transfer policy, as an OpenSRS reseller, I locked
ALL the domains registered through me. I assumed (apparently incorrectly)
that most resellers did the same. But, being a very leaf node, I do
know ALL my customers, and they all agreed with my LOCK maneuver.
In terms of mechanism, this just undoes the latest change in xfr
policy in the ICANN gTLD market. Instead of opt-in-after-nack-delay
you go back to opt-out-after-nack-delay. It is a rational choice,
but since it is, you (plural) know that your interests were not the
controling ones when the policy change was debated.
YUP
There are edge-case registrants who are benefited by opt-in, but if
most of you (plural) opt-out, then the change in policy that affects
registrants, must either be an error, or benefit some parties other
Ahh - who?
We had to retrieve a domain from melbourneIT once, the kind of domain NO ONE
in the organisation would ever touch without asking me or the IT director
first!?! This was on the old ICANN transfer policy as well.
We bulk set register lock on all domains after that incident. But the whole
system depends currently on people like MelbourneIT doing it right, and being
trustworthy. I don't doubt they are trustworthy, but I suspect there is a
hole in their procedures.