New Rules Make Domain Hijacking Easier
Tanktalus writes "Netcraft seems to have a little ditty about new rules from ICANN that take effect on Friday making it easier to hijack domain names. Essentially, if someone tries to take your domain, and you don't answer within 5 days, they now assume you are okay with the transfer. Previously, the default answer was no, and you had to explicitly state your acceptance of the domain transfer. Owners of small domains, beware: no more computerless vacations that last more than 4 days at a time!"
As they point out in the article, GoDaddy (and others) have a domain locking feature that will still prevent these transfers.
Owners of small domains, beware: no more computerless vacations that last more than 4 days at a time!
This advice is a bit extreme... you can rest easy so long as you turn on domain locking at your registrar. That'll default all requests for transfer to a fail until it's removed... so all you need to do is keep your password to your domain registrar accout from falling into enemy hands.
Maybe this is a good time to educate the casual website operator about the domain locking feature, and what it's useful for. The new system's assumption is if your domain is unlocked, you're sending out a signal that you're intending for a transfer to happen soon. Maybe the rules should have locking as a default-on thing, but they don't so it's buyer beware for now.
Nothing has changed really. This has ALWAYS been the way the system ran, only some registrars choose to ignore it, and setup abusive transfer blocking mechanisms, and called them "Safety" measures for their customers instead of the lock-in attempts they really were. The problem with the old way was that some unscrupulous registrars (NetSol for instance)made it harder to get your domains away from them, forcing you to jump through hoops, and making them harder and harder to accomplish, and then deny them for wrong reasons. The new policy only sets out EXPLICIT rules about what are allowed reasons for a domain transfer to be rejected by the current registrar, and a process by which disputes over transfers will be handled. Other than that, nothing has changed really at all, and any news articles saying otherwise are less than properly informed, and listening to alarmist rhetoric instead of understanding how the system worked until now, and how it will work in the future. As a previous poster pointed out, the best thing to do is to lock your domains with your current registrar, just make sure that they provide an easy means to unlock them when you need to make changes, or when you really do want to go to a new registrar.
Joker.com is my registrar and they emailed me 3 days ago about the changes, and declared all domains under their service were auto-locked by default!
:) Now if only I could get this kind of service from my credit card.
I had no idea about the regulations until they emailed me first. First they helped me transfer my domain away from a bad registrar, now they help me through new regulations without me lifting a finger.
Buyer beware of other services, but that's why you sign up with a reliable service with good references!
"All great wisdom is contained in .signature files"
I had a situation a while back with a hosting company. A client I maintain a website for decided to host their website through 1dollarhosting.com
The sign-up form very cleverly asks you for the information to transfer your domain name TO them.
When trying to renew the domain name, I was told by their employees that it is against their policy to release domain names. They let people transfer them in, but they will not release them to other registrars.
After digging a little deeper, they are a partner of Register.com. It took hours (literally) to get someone with enough authority on the phone (at register.com) to release the lock that they had on the account so a transfer would work.
Thankfully, the domain name was finally transferred and the guy at Register.com agreed that what they were doing was unethical....though that didn't stop them from making it a complete PITA.
Mod points are pointless when you browse at -1.
Note that this isn't about transferring a domain from one owner to another. It's about transferring a domain from one registrar to another while keeping the same owner. Transfers of ownership come under different rules.
oh, you mean like when microsoft.co.uk was not renewed and someone registered it in their name?
Damn, probably 90% of the posts in here need to be modded to -1. These rules relate to the transfer of a domain by the domain owner of that domain from one registrar to another. It is not about claiming (or hijacking) someone else's domain as the headline improperly entices you to think.
This is a good thing people! It helps to ensure that domain owners can transfer their registrations when they so wish. In fact, the domain owner has to first request the transfer before it even gets this far.
Sheesh.
- The registrant or domain owner;
- The losing registrar;
- The gaining registrar.
- The central registry - central repository of records.
Got that?Okay, the way a transfer was supposed to work was as follows:
- The domain owner submits a transfer request to the gaining registrar
- The gaining registrar was to seek confirmation of the transfer from the domain owner, based on existing whois information, and independent of the request.
- Having received such confirmation, they notify the central registry that the transfer is valid.
- The central registry notifies the losing registrar of the imminent move, to give them a chance to block it should there be unresolved billing issues or other disputes. Only in such a case was the losing registrar meant to block the transfer.
- If the losing registrar does not object, the transfer is executed.
(Steps 2 and 4 actually run in parallel, but that's irrelevant.)The Problem
However, a number of losing registrars put in a policy some time ago that they would also seek confirmation from the domain owner, despite the gaining registrar having already done so in step 2. They would object to all transfers unless they received authorisation to their liking from the domain owner.
One registrar in particular required a copy of an Australian driving licence or passport, or a notarised letter for non-aussies. In this case it made the administrative cost of a transfer prohibitively high. The did not require this level of identification when a domain was being transferred to them. (Before you ask, yes the admin details were correct. They were just being berks.)
Invariably this policy was put in by registrars to try to prevent customers moving to other registrars, by adding additional hoops. The 'excuse' put forward was to reduce exposure to legal actions.
When one tries to cover ones ass too much, one's hands end up covered in shit.
Not all registrars did this - the nicer ones honored the word of the gaining registrar and only interfered if there were billing issues etc.
The Solution
The new ICANN rules is a compromise - it now explicitly allows the losing registrar to seek the double confirmation, but they can no longer block the move just because the customer didn't jump through enough hoops for them
It does not require the losing registrar to do so, so this is business as usual for the nice registrars.
The important point is that the gaining registrar still has to verify the transfer in the first place, as it should be. The customer confirms their identity once, and no more.
What's to stop a registrar faking authorisation? The loss of their ICANN accredidation, and hence their business.
Final point: although this is a non-story, it *is* important to make sure your admin details, especially your email address, are correct and up to date. Just as you would check your entry in the phone book, check your whois data too.
"A goldfish was his muse, eternally amused"
While acknowleding that this is a joke, I will point out that this doesn't affect .uk domains at all, or any other ccTLD for that matter.
"A goldfish was his muse, eternally amused"
Think transfer security is a problem ... there's a security problem far worse:
h readid=328696&perpage=15&pagenumber=1
... as of now, some registrars do little while others suspend domains within only a few days - so if one goes away on holiday, they could very likely come back and find their domains suspended/deleted.
...
(a post of mine reposted from ICANNWatch http://www.icannwatch.org/ - slashdot.org rejected it, but I'm used to that LOL!)
-----
Bogus "Whois Problem Reports" are increasingly going from being an annoyance to being a real security risk. Some recent incidents I've experienced due to Whois Problem Reports *merely* being filed:
* Dotster, about two weeks ago, threatened to delete a domain if I didn't respond.
* BulkRegister, just yesterday, threatened to suspend a domain if I didn't respond within 5 calendar days.
What good are Whois Problem Reports when anyone can file one and there is virtually no screening performed to ensure such reports have any validitity to them; reports filed on some of my domains claimed everything was wrong, including the expiration date - what!? Talk about pure nonsense!
As of now, if one wants to cause a registrant problems, all they need to do is file bogus reports at the Internic link below (it's so easy, it's frightening!) - heck, if someone really wanted to be deviant, they could spread a virus that sends bogus Whois Problem Reports from hijacked computers...
http://wdprs.internic.net/
In addition, some registrars, such as GoDaddy, charge a fee to the registrant for *merely* reviewing a Whois Problem Report for a particular domain, regardless of whether the report is valid - see links below for more details:
http://www.dnforum.com/showthread.php?t=67862
http://www.webhostingtalk.com/showthread.php?s=&t
There is much talk about the transfer policy changes and security, yet bogus Whois Problem Reports is a security risk many times worse.
Some ICANN policy changes are needed pronto regarding Whois Problem Reports...
1. Requiring more than just a name and email for people making complaints - they should have to provide a postal address that's verifyable and/or some other information.
2. Screening of such reports - permit registrars, if they're not already, to toss out Whois Problem Reports that they feel are invalid without involving the registrant; stop wasting their time over this nonsense.
3. A standard on how registrars handle Whois Problem Reports
* including a reasonable time for the registrant to respond, such as 30 calendar days, before any action is taken
Something needs to be done before bogus Whois Problem Reports get any further out of hand
Ron Bennett
Everyone RTFA. This is not domain hijacking. This is a rule that allows a registrar to transfer your domain to another registrar. So you don't have to worry about someone "stealing" control of your domain or replacing your website or engage in fantasies about gaining control of microsoft.com cause that's not gonna happen. Microsoft will still control the domain, but if the rule is invoked, it may be at a different registrar.
Stupid rule if you ask me. All this does is put more pressure on Registrars to respond to frivolous requests by other (unethical) registrars phishing for business.
"And then I visited Wikipedia
Authentication mechanisms in EPP is starting to make it easier, but that still only works if your current registrar will actually give you the auth info you need.
I've done it when installing qmail under the gun at a very large company. Instead of (not exact syntax - too lazy to look it up):
/usr/bin/qmail-inject
/usr/bin/qmail-inject
echo "This is a test mail" |
I did:
echo "This is a test mail" >
whereupon I confidently proclaimed that all was done and so left for a well-earned long weekend. The following Monday morning was not enjoyable. At least the incident taught me several very sharp lessons which I haven't forgotten...
--- Hot Shot City is particularly good.
That sort of testing shouldn't be done as root (or whichever user owns the mail binaries). That way if you do mistype such a command then at worst you'll see a permission denied error.
--- Hot Shot City is particularly good.