Skip to content

Comment on Name.com: Another Unscrupulous Registrarparent

Comments

> One thing I'm not willing to do is set up a wildcard A record

Why not? I'm being earnest here, I'm a name.com customer and I do have such a wildcard record. Are you building a network service that relies on nonexistent subdomains being resolved at the DNS level (rather than a 404 page or a redirect to a subdomain that does exist)? Or is it more of a philosophical thing?

1. I don't want to provide multiple entry points. As an intentionally vulgar example, http://f***you.example.com would resolve if using a wildcard address. That is unacceptable.

2. I'm in the process of setting up a self-assembling system that will need to be environment aware (public, staging, dev). If I redirect everything to a single A record I actually have to perform logic on my end. A failed request will instead mean to simply move to the next in the list. (Or that is how I am scheming for it to work anyway, not being built yet I don't know how it will turn out.)

For most people the solution is very simple. Use a rewrite rule in your web server config. In nginx:

  if ($host !~  "^(example.com|beta.example.com|valid.example)$") {
      rewrite  ^/(.*)$  http://example.com/$1  permanent;
  }
http://www.example.com/about

or

http://fuckshit.example.com/about

becomes

http://example.com/about

This is good practice in any case, so that you're always serving up the canonical URL.

I would much rather http://fuckshit.example.com/ end up at a browser error page instead of being redirected to my site. This prevents the clever person who decides to link to me with http://fuckshit.example.com/ as the URL. (And I use mod_rewrite for naked domain to www redirect, so I'm familiar with this.)

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.