Q: How to set up multiple websites on OS X server?

The following assumes a NAT'd network.

Here is information and some background on how to configure DNS services on OS X Server.

Either set up either a bogus top-level domain — that's getting increasingly difficult as you'll find with .dev, and particularly as there are several thousand top-level domains online or arriving — or use a real and registered domain, or a subdomain of a domain you have registered, or have permission to use.

The .local domain is reserved for mDNS / Bonjour and not for use as a server DNS host name.  Things get wonky when that's configured in a DNS server.

The .dev top-level domain is a live domain via the Charleston Road Registry, and — unless you've registered it — then it's likely that the domain web.dev may or will soon be registered by somebody else.

Internal use or not, DNS absolutely needs to be correct, and DNS works because nobody tries squatting in random domains.   If DNS is not configured properly, the rest of OS X Server tends to get flaky.

As for translating the domain names, the computers accessing the site must be using the DNS server that contains the translations.   If you're only running testing from the local host, then 127.0.0.1 (the loopback address) should work, so long as the server is configured to use itself as the DNS server.

References to other DNS servers not on your NAT'd network should not be made — just reference the local DNS server(s), and not Google DNS, nor ISP DNS nor any other DNS servers not on your NAT'd network.  This includes your server itself, your DHCP server, and any local clients that will be accessing your local server for web testing or other purposes.

So...

• .dev is a real top-level domain (TLD).   As is .local.   Don't squat in what you don't have registered.
• DNS is a fundamental requirement for servers, and it's also part of the basis for how Apache virtual hosts works; for what Apple calls "Sites".
• An OS X Server can reference itself as the DNS server, so Network Preferences would have the DNS server address as 127.0.0.1, or as the static IP address of the server.   I've used the former address both as some older OS X versions had weird behavior here when the static IP address was used, and as it makes it very clear this is self-referential.
• OS X Server requires DNS services (somewhere), and external DNS providers typically do not provide forward and reverse DNS translations for systems on NAT'd networks with private IP addresses.  That DNS server can be running on OS X Server, or some other DNS server(s) running on the NAT'd network.

I've given up trying to chase whatever top-level domains are not in use and are not pending, and use subdomains of a real-and-registered domain.   Domains are cheap, and you can have as many subdomains as you want.   I have a domain that's used strictly for internal operations, which also means I can easily tell what's inside and what's outside the network gateway box.   Newer and shorter top-level domains also mean shorter subdomain names — less typing than what's available in COM or ORG or NET or the older TLDs.

But yes, you can still try to invent your own bogus "private" TLD.

Forwarding servers can be referenced from your DNS server, either 8.8.8.8 and 8.8.4.4 Google public DNS servers, or your ISP DNS.   Forwarding servers are not strictly necessary, and do add a translation hop if the DNS server doesn't already have the translation cached. 

Neither Network Preferences on the server nor any other systems on the local NAT'd network — other systems that will be referencing your OS X Server system and its resources — should reference any off-NAT'd-network DNS servers.  Those local systems should all reference whatever box on your NAT'd network that is providing DNS, whether that is your OS X Server or some other DNS server(s) on your local NAT'd network.  This includes configuring your local DHCP server(s) to vend your DNS server address(es) for your NAT'd network.

Your call.   DNS is a key part of all modern networking, and it's a core part of how virtual hosts work, as well as TLS security, as well as user authentication.    All of which are relevant to web development, too.    DNS is worth understanding, and OS X Server makes the DNS configuration rather more direct than editing configuration files or related.

As an example of how these pieces fit together, using a numeric IP address works identically to how using a named virtual host works.   Same thing, same way.  The web server gets a text string — which can be the DNS name or can be the IP address, whatever was specified by the user — via the HTTP or HTTPS connection, and the web server then uses that string to select which virtual host to display to the user.

waynefromoakland wrote:

 

Thanks Mr Hoffman!

 

I believe I have my answer, now. Thanks for helping me hash this out.

 

I have a degree in TCOMM management, so I've configured a DNS server or few...in Windows environments.

DNS is DNS.  Works the same across all platforms.

Having a degree in telecommunications management does mean that you should be familiar with DNS and DHCP and related technologies, and it also means that you've learned how to research technical topics as you're well aware that Microsoft is not the only vendor, and that the technologies and practices all evolve.

Microsoft did cause problems for more than a few folks by suggesting .local — back when .local wasn't special or reserved — for more than a few Windows Server domains, too.  Rather than reserving a domain for local use as they should have requested from ICANN, or encouraging the users to register a domain.  Squatting wasn't good practice then, either.

However, Macs are new to me. What I was hoping was that there was a way to automatically run virtual hosts on a mac in a fashion similar to the implementation of the ".local". In other words, with windows, you simply access a machine by it's name.

Windows Server has the ability to add a dynamic address into static DNS — a linkage between DHCP and DNS.   OS X doesn't have that.    (IIRC, BIND9 server does have the ability to receive those updates, but the DHCP server used with OS X doesn't.  The Server.app user interface does not present any of this, however.)   OS X uses an entirely different approach here, what's called Bonjour or multicast DNS or mDNS.   mDNS avoids the need for a DNS server, which is common among many client networks.   Clients all cooperate and provide a name service for themselves using network multicasts.   Workable in small networks but — as you're familiar with from telecommunications — not particularly scalable.   Given mDNS works differently than DNS, a server that's squatting in mDNS TLD does not work all that well.

Even with the DHCP linkage into DNS as Windows Server provides, few (no?) Windows Server boxes are typically configured with DHCP addresses, which means that those boxes usually have static DNS, which is what we are discussing here for OS X Server.   Once you have static DNS configured, tossing aliases — DNS CNAME entries — into the DNS tables is available via the Server.app user interface.  With the clients configured to access the server for DNS, those names are then available to all client systems, too.

With a Mac, .local is appended to the machine name. Without knowing anything about .local, I was hoping this granted some sort of "mac power" such that I could easily add VHs to the machine via the Websites interface without DNS configuration...similar to how the default site is available without any DNS configuration at machineName.local.

Okay, now for web services, that approach can and does and will work.   Whatever.local does work as a virtual host, as long as Whatever.local has the IP address of the server.   Again, that will work because it's a text string that the client sends to the server via the HTTP or HTTPS connection.  It's this implementation of virtual hosting that gets folks confused — DNS or hosts to get the IP address, but it's the text string passed over the HTTP or HTTPS connection that matters to the web server.

You can implement fully-working virtual hosts (sites) by tossing all sorts of bizarre names into the client box hosts file too, and creating matching virtual hosts (sites) on the server.   No DNS involved.   So long as the bizarro names in the hosts file all have the right IP address for the server, the TCP connection will get to the server, and the text string portion of the host name that the user entered into the client as the target URL will get passed to the web server, which will try to match that text string with a virtual host.  This never hits DNS at all.    The web server can have absolutely no idea what the IP address involved with that text string — if you interpret that text string as a host name — is, too.  It's all about that text string that gets passed from the client.   This is how virtual hosting works — it's a text string — that the client asks the server for, and the server locates an associated virtual host.

The concern or worry or issue here is that OS X Server itself needs local DNS configured and operating, or the rest of the stack gets flaky.   More than a few folks run right past DNS and set up other services, and that usually doesn't end well.

Once you have DNS configured, what you want to do with virtual hosting falls right out of the configuration, too; that all works, too.

But I can stick with the subdomains for now until decide that it's worth it to use my mac server as my primary local DNS.

If you've more than a few boxes such as printers or routers or such, having local DNS services is beneficial in general.  Biggest downside being the DNS server(s) have to be available whenever the network is to be available.