"Reachability" Box Giving Odd Information About URL

If you haven't already done so after you latest changes, do a Restart to make certain your changes "take".

Server help describes how reachability works. The hostname and certificate-name must match exactly, or the service is considered unreachable.

View Internet reachability details

Reachability testing lets you know if clients for your services can access your server over the Internet.

The Server app securely sends network traffic to serverstatus.apple.com, and asks automated servers at Apple to try connecting to your server (from a 17.x.x.x IP address) for each service that’s enabled. Because Apple servers are outside your local network, they can simulate external clients trying to connect to your server. The results are shown in the Server app.

This service provides a reliable way to have an external source check your network connectivity. It’s frustrating when you believe everything is configured correctly, but you have no way to test the connections. This service gives you instant feedback about whether your configuration actually provides external accessibility.

You can see the following details:

• The external IP address of your server
• The public hostname of the server (the reverse-DNS entry for the external IP address)
• The last time reachability was checked
• The list of services found available to the Internet

Certificates are something that can be deferred until after DNS is working.

Certificates do not effect network reachability, though certificate mismatches will be flagged as an error when attempting to establish a secure connection.

Using a domain name of www.example.com — the example.com, example.org and example.net domains are reserved for documentation, obfuscation and related — does work just fine, so there's probably a DNS error lurking here somewhere, if you had problems accessing the site via www host name — if that's the name of the host.

Since you have a gateway, you likely also have NAT here, and if you have NAT, then you need local DNS on the internal network.

If you have an internal network, you're either using the same name inside and out — which gets a little tricky — or you're using a separate domain or subdomain inside. If you're using the same name inside and out, you'll need to track changes in both pools of DNS servers.

If you're using separate domains, then you should always get the external IP address of your host — your IP traffic is passing through the gateway and back in through the NAT — and so seeing the public IP address is normal.

Here is some reading on setting up DNS on OS X Server, if you've not already found that.

If you're obfuscating that domain as I suspect, please realize that "samplename.com" is a real and registered domain. FWIW.

FWIW... If DNS is hosed, you'll likely have weird problems later on. Valid and functional DNS is the underpinnings of certificates, and certificates are the underpinning of distributed network authentication and encryption.

For a very quick diagnostic and verification of DNS, launch Terminal.app from Applications > Utilities and issue the following harmless diagnostic command:

sudo changeip -checkhostname

You'll have to enter your administrative password for the sudo, you may see a one-time message detailing the use of sudo, and you'll then usually see some network-related configuration banter, and finally either an indication that the configuration is valid and that no changes are required, or an indication that there are DNS or networking issues needing resolution and usually with a few details.

A successful invocation looks like this:

$ sudo changeip -checkhostname

Password:

Primary address = 203.0.113.12

Current HostName = yourhostname.example.net

DNS HostName = yourhostname.example.net

The names match. There is nothing to change.

dirserv:success = "success"

$

Your host name and IP address will vary.

If you don't get the full output similar to what was shown — it's not "change -checkhostname", BTW — then the command isn't working as I'd expect.

You're still focusing on what's known as the DNS resolver and what's visible via System Preferences > Network, and it's the DNS Server configuration that's available via Server.app that's key to OS X Server. The DNS resolver is familiar from OS X and Windows client computer configurations. Configuring and running a DNS server will be new.

The canonical source of DNS information is Cricket Liu's DNS and BIND book, which is in its fifth edition, when last I checked. This book explains in great detail — possibly too much, depending on your level of interest here — how DNS really works. (What I linked to earlier tries to be a little shorter.)