Can a single server be associated with multiple domains?

Question

If I own the x.x.x.x webserver, can I make two separate sites on x.x.x.x/one and x.x.x.x/two and give them two different domains?

How will it handle internal links in the case (es. x.x.x.x/one/foo/page.html)?

I'm using CentOS 7 with LAMP, and WordPress for some of the sites

Solution 1

Can a single server be associated with multiple domains?

Yes. This would be done by pointing those domains at your web server via DNS.

If I own the "x.x.x.x" web server, can I make two separate sites on "x.x.x.x/one" and "x.x.x.x/two" and give them two different domains?

This depends on your web server software. You could certainly point both domains to your server, but it would then be up to the server software to distinguish which traffic was intended for which domain.

Some smaller web server projects do not support this kind of feature. However, larger projects often do. In the cases of Apache and Nginx, this support comes via Name-based virtual hosts and server blocks, respectively. Both of these projects also support Server Name Indication (SNI) for TLS (HTTPS) connections as well.

How will it handle internal links in the case (es. x.x.x.x/one/foo/page.html)?

Typically, you would set the full path to your one folder as the document root in e.g. your virtual host or server block configuration (i.e. where the "main" domain starts). A page that referenced e.g. example.com/foo/page.html would then be referencing e.g. x.x.x.x/one/foo/page.html. If you wanted to use just e.g. example.com/page.html, you would set your document root to the full path of foo.

WordPress

WordPress has its own methods of dealing with domains. In your example case, assuming you wanted WordPress to handle both domains, you would:

• Specify two domains in DNS.

• Create two e.g. virtual hosts (in Apache) corresponding to those domains.

• Set each document root to point your WordPress installation.

• Configure WordPress to service both those domains.

Otherwise, you would simply point one document root to your WordPress installation (and configure only one domain in WordPress) and point the other document root to your non-WordPress files.

Notes

• For the explanation above, I assuming that you have your web server set up at x.x.x.x and one and foo are directories below the default document root you have already set up for the server.

• It's worth mentioning that DNS points only to IP addresses (e.g. 1.2.3.4) or, in the case of CNAME records, whole domains (e.g. example.com). You cannot point DNS to e.g. http://1.2.3.4/one.

• There are some Domain Providers that may offer web redirects (e.g. to http://1.2.3.4/one), but these are not part of DNS. How requests for pages would be handled in this situation would (again) entirely depend on your server.

---

Minimal Apache Virtual Host Examples

ex. Regular Domains

<VirtualHost *:80>

ServerName example1.com
# ServerAlias www.example1.com, *.example1.com

DocumentRoot "/path/to/www/Wordpress_Site"

</VirtualHost>


<VirtualHost *:80>

ServerName example2.com
# ServerAlias www.example2.com, *.example2.com

DocumentRoot "/path/to/www/Non-Wordpress_Site"

</VirtualHost>

ex. Sub-Domains

<VirtualHost *:80>

ServerName sub1.example.com
# ServerAlias www.sub1.example.com, *.sub1.example.com

DocumentRoot "/path/to/www/Wordpress_Site"

</VirtualHost>


<VirtualHost *:80>

ServerName sub2.example.com
# ServerAlias www.sub2.example2.com, *.sub2.example.com

DocumentRoot "/path/to/www/Non-Wordpress_Site"

</VirtualHost>

Solution 2

Something to keep in mind if you're using HTTPS (HTTP+TLS): There is a specific order of operations at the start of the transaction:

1. The incoming connection is made using the server's IP address.
2. The TLS session is negotiated.
3. With TLS set up, the HTTP request is passed to the HTTP server.

If you have several DNS hostnames pointing to the same IP address, then you need to make sure that the TLS certificate for your site covers all hostnames served by your server. The client doesn't tell the server the hostname it's trying to get until the HTTP request comes through (step 3), but the client knows the desired hostname prior to step 1, and expects the server certificate sent to it in step 2 to have a matching hostname, or the browser will likely put up a "this server might be impersonated" warning screen.

This is pretty straightforward if you have a wildcard certificate and all the hostnames are in the domain covered by that certificate. It gets trickier if you need to provide a list of hostnames (a.k.a. "subject alternative names") to your certificate provider so they all get included.

There is a TLS renegotiation mechanism that might be able to serve different certificates based on hostname, prior to step 3, but it's spotty and most servers don't configure it. It's much easier to configure a web server to serve one certificate.

Solution 3

It's possible, the exact configuration depending on your web server. E.g. for Apache see here.

You will need to have the DNS for both domains to point to your server's IP address -- only one of them can be set as the reverse address (IP to domain name resolution), though.

Comments

[ivanivan]

Few extra details for you. For a HTTP/S server only, no issues at all, you want to use what is called NamedHosts in Apache, nginx et al have similar tech (except maybe IIS). For SSL you need SNI support (fairly standard today). Where you will have issues is when scripts, etc. using the local mail service to send emails out (form submissions, password resets, etc). Mail can really only be configured with one name used in the HELO portion of the transmission, and so for spam purposes all of the domains you host have to allow whatever name you select. Otherwise there will be issues.

[Philipp]

By the way: low-budget webhosts usually host thousands of domains on the same physical server and often even on the same logical server process.

[NothingToSeeHere]

That's how Virtual Hosts work. Look in your config file. Refer to this page for more info: httpd.apache.org/docs/2.4/vhosts

[T. Sar]

Keep in mind that while you can do this, the more stuff you're running on a single server, the larger the attack vector you expose to the world out there. More so, an attack to one domain can end up compromising the other. Keep that in mind.

[Thomas]

It's very common: en.wikipedia.org/wiki/Shared_web_hosting_service

[InterLinked]

Of course you can. It's not just low budget web hosts. I share a web server with a friend. Collectively we operate about 15 websites off of it (to be fair, 13 of them are mine..). What Anaksunaman described is exactly how we do it, using Apache. I always use root relative URLs as a best practice "/folder/"

[Kodeeo]

So, if I've understood from that page I can have 2 sites but one should be one.mydomain.com and the other two. mydomain.com

[Anaksunaman]

@Kodeeo They do not have to be sub-domains, but you can configure them that way, if you like.

[vlumi]

The sites can indeed anything that is associated with your IP address -- sub-domains or not.