Network DNS Settings & External IP?

Hi,

i have the same problem. It begins after the last 10.11.6 update. I use the latest Server.app V5.2.

Until now all was working. Now doesn't work on my server Websites. But there is written that, they are reachable from the internet over my modem IP address. The mail is working correctly.

I have cable modem, then mikrotik and after that the mac server.

Please can you help me?

Is your modem in bridge mode? What devices are handling NAT, DHCP, DNS?

Typically I would put the modem into bridge mode and then let the airport handle the routing and NAT. Forward the appropriate ports for the services you plan to host on your server as you open them up so I don't worry about them yet. Deploy the server and get your SSL certs in place. I multihome my servers due to the aggressive way Server app has been holding onto web ports. Leave the primary in place for Server so it can do what it needs to for Open Directory and its internal websites. A secondary (192.168.1.101) IP turns into your go to for everything else webish. DNS is primary and you have to have it rock solid before you do anything else. I've chased problem too often with bad DNS so now if I see a bad DNS config and the server isn't online yet, I typically nuke and pave and get that part right before anything else. Then I'd move on to DHCP and finally Open Directory. Getting all of these right first is critical.

THEN move on to the secondary services like web, VPN and the like.

I can't recommend El Capitan Server - Foundation Services by Reid Bundonis highly enough. Seriously. Stop reading this and buy the book on iTunes and read it straight through. There is more information packed into those 200+ pages than a hundred searches and hours spent online. Very real world and very good best practices thinking.

https://itunes.apple.com/us/book/el-capitan-server/id1045748875?mt=11

Morphire

Are you sure you have configured the Apple Time Capsule to be in router mode? You want the WAN port i.e. the bottom port of the Time Capsule connected to the modem and the Time Capsule set to 'Router Mode: DHCP and NAT'.

The server will presumably be on Ethernet and should be connected to one of the LAN ports on the Time Capsule or via a switch connected to one of the LAN ports on the Time Capsule.

You should configure the DHCP server in the Time Capsule to advert the 192.168.1.100 address of your server as the DNS server.

Possibly you have not configured the DHCP server on the Time Capsule and hence it may still be using default settings and therefore advertising the address of the modem.

iTim2009 wrote:

OS X 10.10.5

Server 5.0.15

I've got several issues with my services, and — while I believed to have set it up correctly — all signs point to DNS issues.

Everything *looks* right, but I'm having issues left and right with file sharing (WebDAV), user and group management (with and without Open Directory), etc. etc. etc.

Some people have reported issues with remotely connecting to WebDAV shares. There is a fix for the WebDAV remote connection issue - and it may or may not solve the WebDAV issue for you. If not - you can easily undo the fix and put it back to the way it was.

Open Finder

Navigate to Server HD/Library/Server/Web/Config/apache2

Locate the file: http_webdavsharing.conf

Copy it to your desktop (you are going to make changes on the desktop copy of this file).

Make a second copy of this file in a safe location - for backup.

Navigate to Server HD/Library/Server/Web/Config/apache2/webapps

Locate the file: com.apple.webapp.webdavsharing.plist

Copy it to your desktop (you are going to make changes on the desktop copy of this file).

Make a second copy of this file in a safe location - for backup.

Open the desktop copy of http_webdavsharing.conf using TextEdit.

Find the line that reads "AuthType Digest" change it to "AuthType Basic"

Save the file.

Open the desktop copy of com.apple.webapp.webdavsharing.plist using TextEdit.

Find the line that read <key>sslPolicy</key>

Look at the line below that for the line that reads <integer>0</integer> and change the 0 to a 1 so that it reads <integer>1</integer>

Save the file.

In Server.app - go to File Sharing service and turn off the service.

In Finder - copy the two files that you edited on the desktop and replace the original files in their original locations with the edited versions of the files from the desktop. You will need to authenticate as admin when you attempt to replace the files.

Go back into Server.app and restart the file sharing service.

Test the remote WebDAV connections to determine if the fix has resolved the issue.

If the fix does not solve the problem:

Stop the file sharing service

Replace the original files in the two locations with the backup copies that you saved.

Start the file sharing service.

Hopefully this will help with the WebDAV issues.

~Scott

Your DNS is not public facing - you should not be opening the DNS port on the router (port 53).

Just curious - you indicated that you have ports open for Open Directory that you opened via the Server app. When Server app is managing the airport device - Open Directory is not of the services listed in the pull down menu. Did you manually open TCP port 389 (which is the LDAP port)? If so - you should close it. Port 389 does not need to be publicly exposed.

I realize that the ports just mentioned are not causing your issues - I was just pointing out that they should not be open.

Also - some ISP's (such as Comcast) explicitly block TCP 339 (File Sharing over SMB). TCP 548 (File Sharing over AFP) is typically not blocked.

I am making an assumption that this is a home server?

~Scott

Glad you fixed it.

For the future another possible test to confirm your DHCP server is advertising the correct DNS server is to do the following in Terminal.app

ipconfig getpacket en0

This needs to be done on a client Mac that is configured to get its network address via DHCP. It will not work on a Mac configured with a manual IP address setting. You may also need to replace en0 with a different value depending your Mac, the easiest way to confirm what to use is to open Network Utility and to look in the Info tab to see which interface is active, it will list its internal name e.g. en0, en1, etc.

Glad to hear you seem to have resolved your issues. I am still concerned that something is not quite right with your setup because you are unable to use 127.0.0.1 (local loopback address) in the network settings of the server itself. Both 127.0.0.1 and 192.168.1.100 (server LAN ip) should work interchangeably in your particular scenario. The standard accepted practice is to use 127.0.0.1 (and only 127.0.0.1) in the network settings of the server itself.

The following test should indicate that 127.0.0.1 is working.

In server app - go to the DNS Service Settings and make the following changes: (temporarily for this test)

Edit the forwarding server list - and remove the forwarding servers (they are not actually needed - explanation follows at the end of this post).

Edit the permissions - set to Allow Connections from Private Networks only.

Set the perform lookups for Only Some Clients

Edit the lookup client list and select The Server Itself and Clients on the Local Network

Stop and start the DNS service.

For the purpose of this test lets assume that your hostname is server.example.com with LAN IP of 192.168.1.100 (you will replace server.example.com with your actual host name in the subsequent steps).

Open system preferences and go to network settings.

Select ethernet and click Advanced.

In the DNS tab - remove all DNS server IP's and any search domains.

Add 127.0.0.1 as the only DNS server - and in the search domain enter your domain name (in this example you would use example.com the domain portion of your host name)

Apply the settings.

Open a terminal window (on the server itself)

At the command prompt enter: host server.example.com (you will use your fully qualified host name) - it should respond with 192.168.1.100 as the IP.

Next enter: dig -x 192.168.1.100

it should show you your A record, PTR record, NS record

If all is working perform an external DNS lookup such as: host google.com it should report the external ip. Try some additional external lookups.

Go to a client computer - system preferences - advanced (wifi or ethernet) and set the DNS server to 192.168.1.100 and change the search domain to example.com (substitute your actual domain name).

Open a terminal window (on the client) and perform the same tests as on the server. The lookups should indicate success.

If everything is still okay set the client back to getting the DNS and search settings from DHCP. Renew the DHCP lease on client. Test with the host and dig commands from the client again. The lookups should be successful. If not - you have something not set correctly on the Airport router.

Back on the server I would suggest leaving the DNS settings at 127.0.0.1 and search domain of example.com. I would also suggest leaving the permissions set to Private Networks (you are only using this DNS server from within your private network). You can choose to put back the forwarding servers - or try running without them for a few days.

Note on forwarding servers: The DNS server in OS X is fully capable of performing all of your DNS lookups (internal and external) without the use of forwarding servers. It will cache all of the lookup results until the TTL values expire. Depending on your mix of DNS queries - the OS X DNS server may prove to be more efficient without the use of forwarders - but typically the forwarders will improve performance on external lookups. When you specify one or more forwarding DNS servers - the specified forwarding server(s) is/are used for "all" DNS lookups outside of the zone for which the OS X server is authoritative. OS X Server will look first in its own cache before querying the forwarders. Once a forwarder is specified - the OS X Server DNS server will no longer resolve external addresses it own (meaning that it will not query the root servers) - it will always use the forwarders. Typically a forwarder is going to respond quicker than the internal OS X DNS server - but if your typical DNS query pattern is limited to a handful of commonly accessed websites or host names - the OS X DNS server may prove to be more efficient.

If you can't get the 127.0.0.1 to work - you need to continue with troubleshooting - otherwise you may have a DNS issue that is lurking in the background - which will likely cause a lot of grief at a future time when it is harder to fix.

~Scott