another corporate show

UPDATE: I’m very happy to update this post with a link to WordPress and their announcement of DNS editing. Kudos to WordPress for promptly providing this feature. Who knows, maybe they’ve been working on it awhile — but I was fairly convinced with my support conversation they weren’t working on the feature. Either way I’m happy with WordPress and the thought of never having to host my own WP blog again.

This is primarily with regard to WordPress.com, but, it’s an important and delicate concern for any service. Currently, if you want yourdomain.com to point to your WP blog, you have to give WP control over your domain name. WordPress has the challenging problem of providing scalable content and this is very hard to do while providing domain name support at the same time; this is why WP requires control of your domain’s DNS. WordPress has a highly redundant and robust network and part of that is having control over their user’s domains. This is limiting in that a user can’t point a subdomain like securepayments.yourdomain.com to another service.

While DNS natively supports this functionality, it’s not something the average blogger, hosting provider, or even application developer understands (it’s called Slaving). If/when WordPress supports this functionality, they’ll need to do so carefully to limit exposing their systems to outside risks, make it easy to use, and support the most complex users who need to run their own DNS.

If you provide a web service, such as a blogging platform, don’t build “domain name support” by forcing your users to give you full control over their domain name. In short, I don’t blame WP for their current implementation (it’s probably a lower priority for them), but here’s a few tips on what you should do if you want to make YOUR app/service support user-supplied domain names:

1. Don’t give the feature away for free. Your support costs will be higher for this feature than most.
2. Don’t give the feature away for free. DNS plays a big role in spam and you don’t want to associate your systems with a spammer’s domain name.
3. Think very hard if you want to point a user’s app to the root of their domain. Doing so opens you up to the concerns above.
4. If your service involves high-traffic content such that load balancers are involved, consult someone who’s figured this problem out before. (my advice is typically free)
5. Whenever you’re building and scaling your services, keep all the above in mind. As the Internet becomes connected at the application layer, via things like federations and digital certificates, domain names will become more and more important as a component of security and authority.
6. Let users host their own DNS and point it at you instead of the other way around. Administering DNS servers isn’t very cost effective and you’ll save money leaving it up to the users. The downside is you’ll need to be very good at providing your users with instructions and you’ll need to notify them when changes are necessary; again, Don’t give the feature away for free.
7. Let users host their own DNS. You don’t want to host DNS for your users — doing so is a long-term cost commitment and something you can’t “undo”.