Besides, can you give me a single use case where you would want to ignore a user looking for your brand, and give them an unbranded error message instead?

No, it’s a bug. It breaks the RFCs for DNS spec and goes against ICANN’s regulations. As I’ve stated above, a wildcard DNS entry is not the same as having a NXDOMAIN status. While that might be a ‘feature’ to your own development style, it leaves the bulk of name.com users in this situation:

1) They don’t know that Name.com has hijacked their 3LD domain names , and are faced with potential security and branding issues 2) They do know that, and must create a wildcard entry and handle that appropriately on their end.

The RFCs and ICANN are very clear about how DNS should and should not work. Name.com’s policies and procedures are clearly against established standards and best practices.

For example, on name.com’s DNS manager, I can set an A record for *.mysite.com to always resolve to mysite.com’s IP address. Then I can handle it on the server side. Combine this with dynamic subdomaining in apache, and it makes it really easy to set up something like username.somesite.com on the fly. Otherwise, you have to find a DNS host who has an API that allows you to provision subdomain records in real time.

So while you may get miffed at this, it’s a feature that really cuts development time. It’s not a bug, and it’s not sketchy.

As I said in the title, I was concerned there’s possibly an exploit. It’s not something that I’m sure of. And I’ve explicitly noted that if so, this would be an edge case where someone would need to have knowledge of an incoming transfer, and would have had to grab the authorization code from another registrar. If you search Twitter for “I’m leaving godaddy for dreamhost” or Bing for “Domain HiJacking”. Both of these situations are sadly commonplace . Dreamhost does have measures to keep people from social engineering an auth code, but not every other registrar does.

I’ve been a happy dreamhost customer for 13+ years now. There are likely systems going on behind the scenes that prevent unscrupulous activities – and I actually do trust you guys.

Suffice to say, from my perspective, I’m expected to leverage all my trust in you to transfer a domain via a plaintext email & web-page confirmation that lists no specific transaction information. I’m simply asked “Do you want to transfer your domain to Dreamhost?” — and not “Do you want to transfer your domain to Dreamhost , for the Account/Transaction identified by x,y,z?” If you got that email or webpage, you’d be more than a bit concerned — and it would take barely any effort to show users this information and eliminate any doubts.

Thanks for bringing it up, it’s always good for us to evaluate and double check our security measures. We’ve put a lot of effort into security over the last few years, including implementing Multi-Factor Authentication, improving encryption of sensitive data, security scanning tools implemented by our security and abuse teams, and more.