It makes me realize that Google's no humans policy -- is it a policy? -- is actually a strength here. My domains purchased through Google are safe from social engineering because, well, there are no humans to contact to ask them to manually move domains.
(p.s. That is not some kind of dare to hackers! I am not suggesting you prove me wrong.)
I bought a domain for a blogger blog ages ago. At the time google had no domain registry so they partnered with some company.
Years later and google starts hammering me with "hey your credit card is expired we're not going to renew your domain" ...
"Hey go update your payment information on admin.google.com"
Wait. I don't have a g-suite account... and on my personal account my payment info is up to date, so I figure maybe they migrated my email address or emailed me about it but nope.
Then comes circular system where if you forgot X you need Y and if you don't have Y you need X and links on pages that always lead to admin.google.com...
There was no place to find / get help from google. Blogger seems like the information there is wrong / hasn't been updated / abandoned. Just links that ran in circles.
I found the old registrar they partnered with and got them to help.
With Google as far as I could tell there was no way to resolve the issue in a situation where I"m even trying to give them money (granted a nominal amount).
There is a whole process via which domains expire, they do not simply become available to register upon their 'expiry' date.
Full process is outlined here: https://tee-solutions.com/index.php/our-blog/127-domain-name...
Why the scare quotes?
Dijkxhoorn said without that industry access, E-HAWK probably would still be waiting to re-assume control over its domain."
A different read: It was "humans"-based customer support that saved E-HAWK. A "no-humans" customer suppport system might have left E-HAWK powerless, waiting, hoping.
Analogising to the parent's example, if parent had a serious problem, a "no-humans" customer support system might result in helplessness, waiting, hoping for some human at Google to discover and fix parent's problem, unless parent happened to know key people at Google.
I'd suppose that goes both ways. If someone does find a way to steal a domain that's managed by Google, who are you going to contact to get it back?
To me that is a risk. Through I have no evidence for this, I think that the false positives of those algorithms are higher than the risk of a hacker managing to social engineer a high end registrar. The reason I think so is that there is very little incentive for google to eliminate false positives but a huge one for eliminating false negatives.
Except Google actually has a lot of humans in the loop for Google Domains. I was having an issue transferring a domain and I clicked a button to chat and was talking with a real person in about a minute.
Granted, they may have better security procedures but they're still humans.
That wasn't reaaaaly an AWS hack. BGP hacks are still an issue since it is mostly an honor system! There are no safeguards against this except fast admin.
"Registry lock" is serverTransferProhibited, the kind where both your registrar and the main registry need to agree to transfer the domain to another registrar. For instance, you can buy a .ca domain from any registrar, but you need CIRA's compliance (the issuing body for all of .ca) to enact a registry lock. This explains it a bit better: https://cira.ca/ca-domains/optimize-your-ca/registry-lock
I'm having trouble tracking down how to do this for a .com though.
Reading CIRA's page it just says that to make changes the Registrar will talk to CIRA to have to lock removed on their behalf. Doesn't sound like there's any mandatory OOB check from CIRA back to the actual client.
I decided to eliminate that one by becoming my own registrar. And that's one less man in the middle siphoning money off of me.
Registry Lock isn't something most retail registrars will offer, because generally, the vast majority of registrants don't really need it. It's not something you can just put into your domain management panel and roll out to everyone because of all the hoops required once enabled.
That said, Brian Krebs does need it on his domain(s) for obvious reasons - his domain is a massive target for hacking - and so it's enabled on his domain with specific procedures around how updates happen when required which I won't get into.
Beyond Registry Lock, the best way to secure your domains is to have them in an account with a random username (prevents guessing to aid in social engineering vs. "firstlast" or "flast"), a strong password and 2FA. Perhaps consider a unique account email address that you only use for that registrar account since losing control of that could result in losing control of your entire domains account and all the domains in it (assuming you didn't use 2FA).
On the Registrar side, look for one with good protections to ward off social engineering against the account and domains. In our case, we have a system that requires the account holder's specific consent (obtained via account email) to have a support person view personal information or access the account.
1) "registrar lock" - a service that requires the registrar to confirm any requested changes with the domain owner via whatever communications method is specified by the registrant.
2) "registry lock" - with a registry lock in place, your registrar cannot move your domain to another registrar on its own. Doing so requires manual contact verification by the appropriate domain registry.
So... I assume the "lock thingy" within most registrars' interfaces (I'm familiar with the one within Namesilo, the registrar I use), is the less restrictive "registrar lock" ?
It's useful to trademark your domain name. That gives you a very likely win if things ever get to the ICANN dispute process.
I have registry lock. I just asked my national domain registry to lock the domain. All that was needed was a strong proof of identity. (not just a photo of an ID, but doing a physical verification in person somewhere, like on the post office or sending a notarized letter) It was free.
But this is a national domain, where I have a high trust in the registry itself (registry manager makes the Turris router, btw, and some key software like knot dns server, etc), and that's also the reason why all my important stuff is linked to this domain.
It also depend on the type of registry. .se for example allow registrars to set registry lock automatically but not unlock. Unlocking is a manual process and there is contractual conditions that the registrar must have verified the identity of the customer who is requesting the unlock, and the registrar must also sign to that fact. So far no registrar has failed yet to do so, thus the legal ramification of failing this has yet to be tested.
Putting a 'registry' lock into place has upside and downside. As mentioned in the story the downside is in an emergency it's harder to make a change because of the friction of another step to make a change (and that means any change even DNS servers).
That said it still doesn't prevent social engineering. The implication in the article is that if you social engineer a CSR at a registrar the registrar having to have another step to get a domain unlocked (contact the registry ie in the case of .com et all Verisign) then someone will say 'hmm let's be sure on this'. In theory why would this happen? Once someone has been social engineered that's that, right? (I mean sure it's another step and sure that could mean someone thinks more but...)
Now let's say you take care of a domain using registry lock. What is the tradeoff if someone gains access to your dns servers and you need to change those servers but you can't do that easily because a domain is registry locked and now you need to depend on a registrar to contact the registry and get that done. How quickly will that happen?
My point is it's not a non-trivial decision to make at all and the downside has to be taken into consideration.
One last point. There are procedures in place if a domain is transferred to another registrar to get it back to the original registrar. The best advice is to setup some kind of manual monitoring (not dependent on a registrar) where you periodically check the registry whois for the domain and note any changes to it (dns or otherwise).
>"CloudFlare Registrar is not designed for the masses. There are plenty of great mass-market registrars. However, if you’re an organization where losing your domains would be a front-page story, then CloudFlare Registrar is for you."
Of course, they later did introduce a mass market offering as well, but not with that set of features! :)
> a more stringent, manual (and sometimes offline)
How is it more stringent? Who's to say the registry (eg verisign) will do any more stringent of an unlock process than the registrar?
I'm sure it's still possible to social engineer (it's a human driven process), but there are a lot fewer people authorized to make the changes, and they're probably better trained.
I also Backorder my own domains on namejet, GoDaddy, etc just in case they ever do expire there’s still a chance to get them back.
If only there was a company that offered domain name insurance, to make sure you never lose your domain, it’s never stolen, dns isn’t hijacked, and the site never goes down (ddos attacks, etc.).
How much money would make you forget about it?
Wrong. That is not true. Although some registrars might 'confirm any requested change' that is neither ubiquitous or required by ICANN etc.
In principle it seems to me that there could be a "per-incident" price model that would more accessible to more general DNS users who setup their core domain DNS and touch it once a decade, where a flat upfront $200 payment (spit balling) enables Registry Lock and two uses, after which the fee must be paid again for more. The idea here is that you'd directly be paying the $100/hour or whatever it costs a couple of engineers to take time for this each time, on the logic you'd be using it very infrequently. This would avoid ongoing subscription costs which might be easier to justify for non-enterprises, while still being feasible for a registrar. I don't know of anyone who does this though.
A lot I think ultimately really does come down to the registry itself and their specific security practices, as well as fundamental tensions between stopping alterations by unauthorized people while enabling recovery by authorized-but-forgot-password-or-token-broke-or[...]-people. Supporting hardware factors for example is great, but if support can just override them that's a hole. Conversely there needs to be some fallback procedure for if a token breaks (maybe a super long key written down and put in a vault, maybe based on payment information). Some methods can be real footguns too, my current registrar for example offers IP address/range restriction options, but it's not hard to see how that could come back around to bite you in the butt in an emergency if not used quite carefully. It's one of many tough problems due to the ongoing primitive state of electronic authentication I guess.
Edit to add: useful direct quote on Register vs Registry Lock from their initial enterprise-only CloudFlare registrar launch :
>"Many registrars support Registrar Lock, which prevents the registry from altering information unless the lock is explicitly removed. The problem is, if an attacker compromises your registrar account, they can unlock it and make whatever changes they want."
>"Registry Lock prevents changes by any registrar until the lock is removed. Unlocking at the registry level requires out-of-band communication between the registrar and Verisign (the global registry operator for several top-level domains), and is thus very manual. Since most registrars are volume operations, it’s very difficult to find one that takes the time to literally pick up the phone and call Verisign every time someone makes a change to their DNS settings."
So yeah I'm sure that stops attackers real well, but not exactly scalable. "[I]f you’re an organization where losing your domains would be a front-page story..." indeed!