How does Tumblr approach custom domain mapping?

Question

I searched all over but can't find a clear answer or even an engineering blog post to describe how companies map custom domains to their application.

For example, let's say I have a Tumblr page with a URL of www.ashley.tumblr.com. The site allows you to add a custom domain so that visiting www.Ashley.com will render www.ashley.tumblr.com with full support for additional pages and directories.

What is the technical name for developing this?

Answer 1

There's no single name for what they're doing - which is engineering their HTTP/web-server code to handle requests from arbitrary HTTP request Host: header and mapping them to their existing Tumblr accounts. It has nothing to do with DNS other than requiring the owner of a custom domain-name to change their A, AAAA, or CNAME records to point to the same host as the non-custom domain (to guarantee this happens it's usual to make the custom domain-name a CNAME for the non-custom domain, in case the non-custom domain's IP address is subject to change).

Exposition time! - Most conventional web-servers (Apache, IIS) are built around the concept of a "website": a physical directory mapped to requests corresponding to a predefined list of HTTP Host: header values (or some wildcard matching pattern) and protocol and port bindings. For example, you'd add an entry called "MyWebsite.com" (the Website Name) that accepts requests to mywebsite.com and www.mywebsite.com (as these are two distinct Host: header values) and maybe some more, like secure.mywebsite.com using HTTPS on port 443).

More modern lightweight webservers and reverse-proxies (like nginx and Node.js' Express) dispense with physical directory mapping and let the application code entirely decide how to route requests within the application's logic (this is what a "router" and/or "demultiplexer" (demux) does in web-application terminology) - this comes at the expense of needing to handle all that logic yourself (to be fair, these webservers come with the necessary tools to easily configure them like the older conventional web-servers, it just isn't the default).

...but the advantage is that you can make it work exactly like you want.

In pseudocode their program probably looks something like this:

void handleRequest(Request request) {

    String hostHeader = request.getHeader("Host")

    RegexMatch nonCustomDomainMatch = hostHeader.match( "([^\.]+).tumblr.com" )
    if nonCustomDomainMatch.success {
        String accountName = nonCustomDomainMatch.groups[0]

        showAccount( accountName )
    }
    else {

        // Look up the custom domain name in a database or other mutable data store:
        String accountName = db.execQuery( "SELECT accountName FROM accounts WHERE accounts.customDomainName = @cdn", new { cdn: hostHeader } )
        if accountName == null {
            showHttp404Error()
        }
        else {
            showAccount( accountName )
        }
    }
}

In reality, given their size and scale, it would likely be some custom logic inside hardware load-balancers or some other lightweight frontend service - and always with aggressive caching (database lookups are expensive!).