Tag: dns

When you host multiple websites on a same server, your server needs a way to know the website it must return when an HTTP request arrives. The most widespread solution is to rely on the Host: header the client (usually the web browser) includes in the request. When HTTPS is involved, the SNI extension (Server Name Indication) is used to determine the certificate that must be used to secure the connection. The web server will employ the given hostname to serve the appropriate website.

The former implies that the hostname must resolve to the IP address of your server. But what if you’re creating the website on your local development machine? What if you’re just testing a tool like Moss to see if it fits your needs? Most likely you don’t want to create new DNS records yet, so there must be a more convenient solution.

Meet wildcard DNS services for IP addresses. A domain name like www.10.0.0.1.xip.moss.sh www.10.0.0.1.getmoss.siteresolves to IP address 10.0.0.1. You don’t have to set up anything, just choose the appropriate domain name based on the IP address of your server. We encourage our users to use a wildcard DNS service while they’re trialing Moss, because it’s the fastest way to get started.

In the remainder of this article I’ll briefly review and compare the most relevant free wildcard DNS services you can use when you don’t want to mess with the DNS records of your own domain yet.

As you may know, you can connect Moss to your fresh Ubuntu 18.04 or 16.04 server – regardless the provider where such server is hosted. Moss also features native integrations with some cloud providers (Amazon, DigitalOcean, Google and Vultr as of this writing), but you can use Moss with any vps, cloud instance, or even physical server – not a common use case, but feasible anyway.

A few days ago a customer was having an issue when trying to connect an Ubuntu 18.04 instance (hosted on his provider of choice) to Moss. So I decided to create an account on such provider and investigate the problem. It turned out that the provider’s image had some “suboptimal” configurations and that the default solution for name resolution in Ubuntu 18.04 (bionic) has some related bugs. I think the problem is interesting enough to be shared, and it’ll also allow us to talk about systemd and, more specifically, systemd-resolved for name resolution.