OS X Server DNS Best practice?

What problems or errors are you encountering when trying to add the A or CNAME records for the remote host into your local DNS?

What version of OS X Server?

I am curious about this too. I added a zone for jessicasideways.com but I am having issues with www.jessicasideways.com. Now, I do intend to use .htaccess to redirect www.jessicasideways.com to jessicasideways.com but so far, I need to get the DNS to work before I can do this.

I am interested too by this question.

I have Server 4.0.3 and always some little problem specially with contact. When I use the DNS hostname of the server and add CardDAV on OS X Workstation, automatically I have an OS X Server account and Contact don't work. If i use ip adresse or other DNS name OS X add correctly CardDAV account and all work perfectly.

I have the most of services activated. Any best practice of DNS entry to help services to work ?

Same issue here.

Hello, DNS for simple name resolution work correctly for internal and external name. Internal it is .lan and external .fr

I think there is perhaps SRV entry to add.

A names server is a really simple thing, yet it can be very confusing and when you dig into the details of how it works there is a lot to work with.

To touch the surface and let you understand the most common error I will try to structure and general answer to what you need to understand setting up the initial DNS records and the server.

OSX Server has to be setup using a Hostname (if you are going to us it on the web). For the server.app to be happy and to run the setup without out errors etc the Hostname must exist in a DNS with its A record IP pointing to the machine. Otherwise the server setup can be confused especially server.app prior to version 4.0.

To reach the server from Internet, the server's IP must be a public IP. If you use several network interfaces on your server you can of course have one NIC (network interface controller) setup with an IP of your home/office LAN.

The server's public IP must also be correctly setup in the DNS so that a reverse lookup of the IP points back to the server's domain name (Hostname). This makes the server's domain name FQDN (full qualified domain name). e.g "server.example.com" -> public IP aaa.bbb.ccc.ddd and reverse record pointer is aaa.bbb.ccc.ddd -> "server.example.com". Start from server.app 4.0 there server's domain name has nothing to with what domain you are going to use in combination with your mail server or web server. Prior to version 4.0 it was a bit hard to configure the severe as one normally would like it to be done.

Now the OS X server is happy!

The problem many people have is that being on the same LAN with your workstation as your OS X server, using the OS X server's DNS, it will return an IP nr for "server.example.com" which is a public IP nr. In many networks this is not allowed from inside the LAN where the server to be accessed exists. If you have a more advance Firewall you might be able to enable "reflective ports" which will let you use public IPs of your own server residing on the same LAN as you work station.

To solve the issue when your network firewall/router don't accept public IPs for a local machine, you must use two DNS servers. One which is for when you access the server from Internet and one from when you access the server from inside you office/home. If you can't setup two different name servers (machines) then use a DNS provided as a service on Internet for your public IP records and use the OS X DNS for you LAN lookups.

The DNS serving the answer to you when you are in your LAN must be setup using LAN IPs, not public IPs.

There is a second way (advanced) which I have used in many installations, but it is not possible when using server.app's user interface. A DNS can have records in e.g two different VIEWS. The VIEWS can be setup to answer depending on from which network a question reaches the DNS.

You need to add things manually to the DNS' named.conf file using the "Webmin" suit or using unix command line tool.

You need to read the manual for the BIND 9 server (which is the actual name of OSX' built in DNS) and Views to understand how it works. It is not that difficult. It took me 1-2 hours the first time. Remember one thing though, in the named.conf file, do not touch the first View which is Apple's server.app's standard View. It must exist otherwise the server.app goes crazy. "com.apple.ServerAdmin.DNS.public" is the name of Apple's View. What is that View will be visible in server.app. Whatever stuff you add in another View will not be visible through the sever.app. It works grate!

In this way one DNS can answer to any number of different networks providing an IP nr of the server or any domain which is correct for that particular user's network. In this way you have only one DNS to manage. Webmin is the best software to use and handle Views in Bind 9. It actually can handle anything under the hood of OS X server. It can also run server clusters and setup master and slave name servers.

I hope this provide something to clarify why you normally can't us public IPs in your DNS when you are using it in your own LAN.

tsumugari wrote:

Hello, DNS for simple name resolution work correctly for internal and external name. Internal it is .lan and external .fr

I think there is perhaps SRV entry to add.

Please do not use .LAN as your top-level domain. That's not a valid top-level domain right now, but it's also not reserved for this sort of use. Either use a real and registered domain, or a subdomain of a real and registered domain, or — if you squat in a domain or try to use a TLD that's not registered — expect to have problems as new top-level domains are added. At the rate that the new TLDs are coming online from ICANN, I'd expect to see .LAN get allocated and used, too. .GURU, .RIP, .PLUMBING and dozens of other new top-level domains are already online, and probably thousands more are coming online.

SRV records are not related to accessing the Internet, those are service records which some applications use to access certain network services; they're a way to locate a target server and a port for specific applications — CalDAV does use an SRV record, but that's not related to the original posting's issues. If you're having issues similar to the OP, then access your server and launch Terminal.app from Applications > Utilities and verify local DNS with the (harmless, diagnostic) command-line command:

sudo changeip -checkhostname

Enter your administrative password. That command might show a one-time informational message about the use of sudo, and will usually then show some network configuration information about your server, and then an indication that no problems were found, or some indications of issues. If there are errors reported, your IP network or your local DNS is not configured correctly — I'm here assuming a NAT network.

I usually do this DNS set-up in a couple of steps. First, get private DNS services configured and working. This is always the first step, right after assigning the IP addresses. It's just too convenient not to have DNS running on your local LAN, once you get to the point of having and running a server. Then for external access for (for instance) web services, get port-forwarding working at the firewall/NAT/gateway box working; get your public static IP address mapped to the server's internal, private, static IP address. Then get the public DNS configuration to resolve your external domain name to your public static IP address.

My preference is to use separate DNS domains or a domain and a subdomain inside and outside. Using real and registered domains, and not using any domains associated with a dynamic DNS provider — that's possible, but a little more tricky to configure. This internal and external domain usage simplifies certain steps, and it avoids having to deal with cases where — for instance — some of your services have public IP addresses — such as a mail server you might be using — and other services might be entirely private. If you have one domain (or subdomain) be public and one be private, then you don't have to track external IP address changes in your private DNS services; public DNS has just your public stuff, and your private domain (or subdomain) has just your private stuff. Also obviously easy to tell what's inside your firewall, and what's outside, using this.

If you're thinking of running a publicly-accessible mail server, you'll need additional steps in the public DNS.

Little of the above probably makes sense, so here's a write-up on configuring DNS on OS X Server. All of the Server.app stuff works about the same for general DNS setup, too. More recent Server.app is usually more flexible and capable than the older Server.app stuff, though.

Thank you very much for your answer. I will check that.

I have use .lan for internal mainly for Open Directory, if it is like Active Directory change the DNS name after the creation of the directory is not very simple (we can do it but with a lot of modification). I have think if in futur a change my public DNS name i will have a problem, with a private DNS name i am normally ok.