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.
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.
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. 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 than the registrants, edge-cases excluded. Mail comments to transfer-comments-g@icann.org. In fact I think I'll forward this entire set of threads to transfer-comments-g@icann.org.
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.
Yes ... but ... OK. There are things anyone managing registry/registrar/reseller accounts can do, from getting all the renewal dates synchronized and tied to a date you never forget (warning, spousal birthdays not advised), and if nothing else comes up for several values of "tomorrow" I might write up. But ... Like the guy who was looking for a free solution to all the :43 formats in all the gin joints in all the world, why do you want to buy retail? You don't expect routers to autoconfig and suck up bogon filters and cough out correct aggregations for you just by the application of some electrons, so why expect to get all the nuances of the ICANN zoo, and to stay current of registry/registrar/reseller best and worst practice? Eric
On Sun, Jan 16, 2005 at 09:57:08PM +0000, Eric Brunner-Williams in Portland Maine wrote:
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? -- -=[L]=-
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.
participants (4)
-
Eric Brunner-Williams in Portland Maine -
Gadi Evron -
Lou Katz -
Simon Waters