What Is an Appropriate Hostname & DNS Zone Configuration for External DNS Setup?

Question

I setup servers that are hosted on a secure external data centre. The data centre has its own DNSS, so the DNS service is never setup on the server itself, and is handled by the data centre. I have already setup a handful of servers, and they all seem to be working well. Nevertheless, a couple of people in these discussions have told me, that I'm not setting the servers up 'properly' because of the way I'm naming the server - ie., they believe I'm assigning a 'wrong' hostname - and because of the way I'm setting up subdomains in the zone file. Here is how I'm currently doing it:
CURRENT SETUP:
The server is public, and it is also the ONLY machine publicly in the domain zone. So, if the client's domain is "example.com", there is only one machine that will respond to all services in that domain. Because of this:
- Server Hostname: "example.com"
- reverse DNS PTR record points to "example.com"
-  'mail.example.com', 'www.example.com', 'ftp.example.com', etc, are all setup as A records that point to the same IP address as "example.com".
This has been working fine so far. I have not had any problems with any service, including mail. However, a couple of people suggested that "example.com" is not a fully qualified domain name, and that this setup is therefore  'incorrect', and that it will cause me problems in the future. They suggest I should be setting these servers up like this:
SUGGESTED SETUP:
- Server Hostname: "server.example.com"
- reverse DNS PTR record points to "server.example.com"
- setup "www.example.com" as a record pointing to the same IP address as "server.example.com", but avoid setting up other subdomains unless absolutely necessary - ie., tell client to use "server.example.com" as the 'proper' address for mail/ftp/etc.
Technically, 'net', 'company.net' and 'server.company.net' can all be fully qualified domain names, if each one of them points unequivocally to a single IP address. An domain name is not fully qualified, for instance, when it points to a subnet instead of a single IP address. Using "example.com" as a FQDN is technically correct. However, what is 'technically correct' and what Server considers acceptable are not always the same thing....
I certainly don't want my clients to have problems in the future, and if OS X Server is going to misbehave because of the way I'm setting up my hostname and zone files, I need to know for sure NOW rather than later!

Answer 1

I'm the "other people" referenced here.
For general information on DNS, please acquire and skim a copy of Cricket Liu's DNS and BIND book.  It was on its fifth edition when last I checked.  DNS server on OS X Server is the ISC BIND server, which is discussed in that book in some detail.
If configuring OS X Server in a data center, the OS X Server box probably does not want (nor need) to be running a local DNS server.  (Running local DNS services just means that DNS server will potentially become part of a DNS DDoS, if who can issue queries to the server isn't carefully controlled.)  Use the DC DNS server(s).
If you want the domain itself to be used as an IP address (eg: example.com), then that's usually an A record, particularly if you're getting email via that domain (and not an MX record going elsewhere).  Some versions of OS X Server have had some issues with setting up this record within Server Admin.app and Server.app.
The previous issues were likely due to stale DNS translations lurking within the configuration, and caching of that data up to the TTL.  (FWIW, this discussion is related to this thread and this thread.)