DNS Tips: Establishing a DNS Server on Mac OS X Server 10.6 - 10.9

This describes how to configure DNS services on Mac OS X Server 10.6 (Snow Leopard Server) using Server Admin.app within the Server Tools, and also applies to Mac OS X Server 10.7 (Lion Server), 10.8 (Mountain Lion Server) and 10.9 (Mavericks Server) configurations when Show All Records setting is selected within the Server.app tool.

If you are seeking to configure a DNS server reference for your Mac OS X client system, or adding a DNS server reference for a Mac OS X Server box that is not providing DNS for your network, please see DNS Tips: Referencing A DNS Server On Mac OS X.

If you're not sure if you have Mac OS X Server or Mac OS X client installed on your system, then you likely have Mac OS X client.

Additional related topics are referenced in the section at the bottom that discuss external DNS services and public-facing DNS and related topics; on what goes on on the network located outside of your external gateway-firewall box.

The Demarcation between the Public Internet and your Private Network

There exists a key demarcation here at your external gateway-firewall box.

  • Outside that line and outside your gateway-firewall, there's the public world and public DNS and public static IP and public dynamic IP addresses and your public DNS names and whatever else happens outside your firewall is between you and your ISP and your DNS provider.
  • Inside that demarcation is your own private world and your own private DNS and the forward and reverse DNS and static IP that's required by Snow Leopard Serve or Lion Serverr.

This article discusses the portion of DNS and the network within your gateway-firewall; inside this demarcation.

You will be setting up “authoritative” DNS server for the particular domain name (whether real or made-up) that you select.

You can choose to have your external gateway-firewall box field VPNs and to potentially handle port-forwarding and related; whatever features the particular external firewall box might be capable of. The external firewall here simplifies your network organization, and it provides an easy gateway for your internal routing, and you can avoid using a Mac box as an expensive and slow and comparatively difficult to configure IP router.

Why DNS? Static IP (public or private) and DNS (forward and reverse) are Required

Mac OS X Server needs DNS running, either locally, or somewhere within its network. Failure to have functional forward and reverse DNS (rDNS) available will cause various instabilities, and will cause changeip -checkhostname to flag errors. (The changeip command is specific to Mac OS X Server, and usually used to change an ip address; here the command is used to test local DNS services for the host.)

The resulting DNS server configuration knows local host names and address translations, and can forward other client DNS queries along to an ISP DNS server, or to a local DNS forwarder. These DNS translations are only available to clients on the network or via VPN; inside your demarcation.

This article and this configuration sequence very specifically avoids creating a publicly-visible and publicly-accessible DNS server.

This sequence is specific to the server version of Mac OS X software, and to one of the server administration tools that are used with Lion Server (10.7 server) and Snow Leopard Server (10.6 server) environment. The Mac OS X client environment ships by default on most Mac systems, and most then require the separate installation of Mac OS X Server software. The client environment of the Mac OS X operating system does not include DNS server capabilities.

Domain Naming Prerequisites, Assumptions

As you're following along through this information, you'll want to get a registered domain or use something severely unlikely to get issued as a real domain. (Folks are now starting to activate new top-level domains (TLDs) such as .travel and new non-Latin domain names, and more are on the way, so if you've only seen .COM and .NET and the old country-specific domains, you'll want to look around at what ICANN has been up to.)

  • You must either use a domain that is not now and will not ever be registered — this is vastly more difficult than most folks will realize — or use a domain that you have registered.
  • Do not use the mDNS (Bonjour, ZeroConf) .local domain. This is a domain that you do not have registered. Similarly, do not use .private.
  • Do not use a domain that is or will be registered by another entity.
  • Only use a domain that's been registered by your organization, or by another entity if you are working with and have approval of that registrant.
  • If you're going to pick a private and “bogus” domain, use your company name or some other such if that name doers not collide with an existing domain or top-level domain, nor likely to create collide with an existing or a potential future top-level domain. (And realize that picking a bogus domain saves you the cost of maybe US$10 per year, and with a substantial penalty in time and effort, if you should later decide to connect and thus need to re-address any existing references to the bogus domain name.)
  • Do not use “example.com” nor “example.net” as your domain. These are examples of domain names.

HoffmanLabs recommends picking and using a public domain that your organization has registered.

Picking a Domain Name

The following table describes the typical choices for a domain.

  • The table assumes that xyzzy holds some significance to your organization; a company name or surname or other such.
  • The table further assumes that xyzzy does not match a current or likely top-level domain (TLD).
  • And the table assumes that you have registered the example.com and have potentially also registered the example.net domain, or are authorized to use and coordinating with the domain registrant.
General Option Example Host Name Description, Trade-offs
example.net www.example.net  
While the example name example.net is shown here, this is a domain that you have registered; a real and registered domain of your choosing.

 
this is simply a private DNS server for a registered domain. This approach is effective, easy, and will never collide with another domain. This differs from the familiar public domains only because the DNS servers are private; example.com is external and public, and example.net is private and internal. This is the approach that HoffmanLabs typically recommends.
Fully-qualified zone name: example.net.
subdomain.example.org www.subdomain.example.org  
While the example domain name example.org is shown here, this is a subdomain of a domain that you have registered; a real and registered domain (and subdomain) of your choosing.

 
Tthis is a private subdomain for a registered domain. This approach is effective, easy, requires one registration, and will never collide with another domain; it is very similar to your own (internal) domain.
Fully-qualified zone name: subdomain.example.org.
example.com www.example.com  
While the example name example.com is shown here, this domain choice duplicates a real domain name that you have registered and have already established public DNS for.

 
This establishes a private and mirrored DNS server for a public registered domain. This approach is effective, though will collide only with your public domain. This differs from the familiar public domains because the DNS servers are private, and because you will need to mirror (duplicate) public host addresses within your internal name; if you are using NAT at your gateway-firewall, you can have a public static IP address for www.example.com in your external and public DNS, and second host entry with a private static IP address for www.example.com within your network.

 
This particular choice is also known as split-horizon or as split-brain DNS; see below for details.
 

Fully-qualified zone name: example.com.
xyzzy www.yourorganization.xyzzy  
This is a unregistered and “invented” and “bogus” top-level domain name.

 
this is a private and never-registered domain. This domain and the top-level domain must be bogus. Do not use a real TLD; don't use .COM or .NET or any other existant or likely-existent domain. Do not use .local, do not use .PRIVATE, and do not use any RFC-reserved TLD.

This approach is effective, easy, requires no registration, and (if you have picked a “bogus” name) will not collide with another domain. While this approach works and avoids the registration, HoffmanLabs recommends registering a domain. If you ever need to go public with your domains, you'll have to rebuild some or all of your entire infrastructure; your savings of US$10 or less per year for a real and registered domain will have been far more than completely lost.

 
Fully-qualified zone name: yourorganization.xyzzy.

 

The following examples show the same domain name plugh.example.com, and the IP address 192.168.1.30. Which particular configuration you pick from the above table matters not, the set-up is the same.

plugh.example.com and 192.168.1.30

This document assumes the following:

  • That example.com and example.net are the domains within your external gateway-firewall box on your private network.
  • That the host name of your DNS server is “plugh” and thus that plugh.example.com. is the fully-qualified host name of your DNS server
  • That the IP address of your DNS server “plugh” is 192.168.1.30 on your private-addressed LAN.
  • That there exists a key demarcation here at your external gateway-firewall box. This article describes internal DNS set-up, and not the set-up nor operations of external (public) DNS. You are not serving public-facing DNS here.
  • The example domains here are RFC-reserved domain names and serve strictly as representative examples of domain names. These specific domain names are reserved, and are not domain names intended for any actual use.

You will need to change these specifications to match your local network.

Step-by-Step

  • Get a good and restorable backup of your disk before you start.
  • If you are working directly on OS X Server 10.7 Lion Server, or if you are attempting to configure DNS from an OS X client system, download and install the Apple Server Tools package. If you are on 10.6 Server, ensure that the installed Server Tools package is the most current version. The Server Tools package contains various management tools, including Server Admin, the tool needed here.
  • Launch Server Admin.
  • Using Server Admin, select the target server, select DNS, stop DNS.
  • Select Settings.
  • If you use forwarders, then select the forwarding server(s) IP address(es) in your DNS server as your upstream ISP DNS server(s), or you can configure Google DNS as your forwarding servers. If you don't have forwarders configured (and you don't need to have forwarders), your DNS server(s) will go directly.
  • Still in Server Admin, select Zones.
  • Since you'll be starting over (and since you have a backup! Right?), use Server Admin to delete all of the zones you see listed in the zones display. Any and all forward zones. Any and all reverse zones. Everything.
  • On 10.6 and earlier, add a forward primary zone for example.com. here. Note the trailing dot is included here; that makes the specification a so-called fully-qualified domain name (FQDN) specification. You will want an FQDN specification here. On 10.7 and later, omit the dot at the end.

    (Note: The FQDN specification does not mean that the domain name is private or public, merely that the domain name is specified in its entirety.)

    The following will discuss the primary zone entry you are now adding.
     
    • The primary zone name example.com. or example.com on 10.7 and later.
    • Enter the admin email address (user@example.com or whatever you're using to receive your email)
    • Ensure that zone transfers are not allowed; that the enable zone transfer box is not selected.

      You may need to enable zone transfers later on, but leave it off for now.
    • In the nameserver field, click the + to the right of the box, and enter the zone name example.com. (again), and enter the nameserver host name plugh.example.com or 192.168.1.30. These specifications will probably be the IP address or the FQDN of the host that you are presently configuring; of the local host. In this case, this is

      Note: Though you could reasonably want to use the host name as the DNS name server (nameserver) name here, HoffmanLabs has encountered trouble with this particular skip-sequence with some versions of Server Admin, and would recommend entering the DNS name server IP address here, and (if desired) then come back to this field later with the IP host name; after your DNS is more completely configured and you have added a computer (machine) record specifically for your DNS server.
    • For a small network configuration where you're not running a mail server — or not running mail yet — the mail server (mail exchanger) box will be blank. If you have a mail server established, click the + to the right and add it.
    • Save your changes to the primary zone record.

     

  • If you don't already have a reverse zone (as will be the case when you're starting from scratch), you'll get a reverse zone created gratis as you add hosts (machines) into your forward zone (below). Server Admin does the right thing here. Leave the reverse zone alone.
  • To add hosts (machines) to your newly-created primary zone, select the primary zone you're working on by clicking on the zone name. These are local hosts (machines) only. You're only entering hosts (machines) in your local network, and not references to hosts outside your local network.
  •  

    • You'll now be select Add Record and then Add Machine for each host name (each machine on your network that you're adding into your DNS. For each machine — server, router, gateway-firewall box, network printer or other device at a fixed static IP address — within your network that you wish to have a host (machine) name for.

      You'll usually have just the name of the host and not the FQDN entered for the host (machine); if you want the hostname to be www or mail or fluffy, you'll have just the string www or mail or fluffy entered in the hostname (machine name) field here, and the rest of the host name — the domain and the rest of the the FQDN — will be assumed from the zone name. Requests to the DNS server will receive a translation for www.example.com or mail.example.com or fluffy.example.com machine.

      Depending on the OS X Server version, you might see the host name switch to a FQDN upon entry.

    • Add the (private or public) static IP address you'll be using for the machine.
    • Save your machine name record.
    • If you choose, you can verify the creation of the reverse zone and a reverse entry for the specified IP address here. Do not make any changes to the reverse zone, nor to the entry. To view the reverse entry, select the reverse zone that has been created for you by now, and specifically click on the gray disclosure triangle associated with the reverse zone if needed, and see if there is now an entry for the IP address you have added; for the host (machine) you have just added. If you do not see this reverse zone and an entry within that reverse zone for the host you just added, then there is a corruption or a problem with the DNS environment. Do not change the reverse zone.
    • Repeat this Add Record sequence for each (local) host (machine) you'll be referring to on your local network.
    • We're done with Server Admin, for the moment.

     

  • For testing: configure one of your clients to use the new DNS server at 192.168.1.30 (or whatever the IP address) by explicitly selecting your newly-created DNS server in the client system's Network Preferences > Advanced panel, or whatever mechanism is used to establish the IP address of the DNS server on the particular client.
    After launching Terminal.app (or see below for Network Utility), use the bash shell command dig to test DNS translations for your local (new) host names:
    dig plugh.example.com
    and (presuming that kicks back an IP address), then invoke:
    dig -x 192.168.1.30
    to use dig to query to test the reverse translation. If you don't want to reset your DNS server manually or if you can't get to the DNS server, you can use the @ to explicitly select the DNS server (here shown as 192.168.1.30) to query a host name for an address (here shown as 192.168.1.1), as well.
    dig @192.168.1.30 -x w.x.y.z
    If you are not comfortable with using Terminal.app and the bash command shell, you can use the Network Utility (available under Applications, Utilities) in place of the dig command.
    Additional information on troubleshooting DNS is available.
  • After you have it all working, aim your clients at your new Mac OS X Server DNS server box via explicit specification for via DHCP setting. Do not reference the ISP settings directly from your clients.

DNS information is cached at several places including the client, so you can potentially need to reboot the client and the server to fully activate settings.

Secondary DNS Servers

If you require higher DNS availability or wish to avoid manual changes to your DHCP and DNS client configurations should your DNS server be down, you will want to have multiple DNS servers. This involves establishing secondary DNS servers.

On the secondary DNS server, use Server Admin to add secondary zones into the Mac OS X Server DNS server host configuration. Use secondary zone names that are identical to the primary zone names (both forward and reverse zones) used on the main DNS server. For each secondary zone you add, you'll need to specify the host IP address for DNS resolutions in the primary DNS servers field when you're adding the secondary zone; click the plus sign at the bottom of the Primary DNS Servers box and add the IP address of your existing (primary) DNS server for the zone.

On the main DNS server, use Server Admin on the main server to enable zone transfers. Select the server in Server Admin, select DNS, select Zones, select the primary zone you are mirroring, and check the Allow Zone Transfers box, and save your changes.

Ensure TCP port 53 is accessible on the main DNS server within the firewall settings within Server Admin, either from the specific server or from the LAN.

While you'll want both TCP 53 and UDP 53 ports open at your server firewall for internal networking — if you are running private DNS — do not open TCP nor UDP port 53 (in-bound) at your external gateway-firewall device, or for external-network access at your server firewall. You will generally not want external sites to have access to internal DNS servers.

Forwarding DNS Servers

A DNS client works by communicating with a DNS server. A DNS server works by communicating with the DNS root servers, and with other DNS servers determined to be authoritative for the particular query. Most DNS servers also cache DNS translations — up to what is known as the Time To Live (TTL) value set for the particular DNS translation — allowing for faster translations.

DNS can be configured to work from its cache and from the DNS root servers, or can be configured to query a particular DNS server. This latter process is known as a forwarder. Forwarding DNS queries to a specific DNS server is useful in a few contexts, such as when you're using a DNS-based network monitor, or filtering tools used for controlling network access based on DNS names. Like the local DNS server, these DNS servers or forwarders are DNS servers that can cache DNS traffic, and potentially respond more quickly for known (and cached) translations. Note that these responses are only for the first query for the translation, or if the translations have fallen out of your local DNS server caches. If the translations are not known by the forwarding server, then forwarding adds an extra hop into the translation; from your DNS server to the forwarding server to the DNS root servers, and along from there.

Forwarders are not necessary for correct operations of local DNS servers.

Whether or not the forwarder provides any performance benefits depends greatly on access patterns and speeds; on local DNS activity, and at the size of the local DNS caches. It's quite possible for a forwarder to slow down your name resolutions, as it adds an additional DNS server into the processing. If you get a cache hit, then using a forwarder can be a win. If not, you incurred an extra network hop and related processing while performing the translations. Worst case, if the forwarding server(s) are offline for some reason, then your translations will fail. (The DNS root servers are redundant.)

You can operate with a forwarder, or you can set specific servers as DNS forwarders, or you can configure no forwarding, and the DNS server will then go directly to whatever DNS server(s) are necessary to resolve the DNS query.

HoffmanLabs generally does not configure forwarders for OS X Server configurations running local DNS.

Split-Horizon or Split-Brain?

If you are setting out to run a split-horizon DNS configuration, then your DNS server is authoritative for the zone. An authoritative DNS server won't query external DNS servers (even other DNS servers configured as authoritative for the zone!) for translations.

What DNS geeks call “authoritative” just means the DNS server is told that it has all the answers for the specified zone.

Your DNS server either has the translation and the IP address, or it doesn't.

Split-horizon DNS is to DNS translations what NAT is to IP addressing. The horizon (or the brain) that you're splitting here indicates that you will get different DNS responses, depending on what part(s) of the network the query originates from. That's, well, the goal of a split-horizon configuration.

Split-horizon is also why you can need to add public IP addresses into your private DNS configuration, and why you need to track external host names from external DNS.

This is also why HoffmanLabs tends to configure two different zones and two different domains (or a domain and subdomain) here. One inside the firewall and the demarcation. One outside the demarcation. Less confusion, arguably. What's private and inside and what's public and outside the firewall is immediately obvious from the DNS domain names used.

Picking a Private Address Space

If you do not have enough IPv4 addresses to assign to all of your devices, you will be using NAT. With NAT, you will want to use one of the three available private IP address spaces from RFC 1918.

  • 10.0.0.0/8 — 10.0.0.0 through 10.255.255.255; the private Class A block
  • 172.16.0.0/12 — 172.16.0.0 through 172.31.255.255; private Class B block
  • 192.168.0.0/16 — 192.168.0.0 through 192.168.255.255; private Class C block

Due to potential routing issues with VPN connections, HoffmanLabs recommends avoiding 192.168.0.0/16 when creating a new network.

Redirecting a second-level domain to a third-level domain; establishing a domain default host

If you want web browser references to the domain name (eg: example.com) to redirect to the www.example.com host (for instance), then you will want to add an A (IPv4) or AAA (IPv6) or CNAME (alias) record for the example.com. host into your DNS server database to the target host IP address. With 10.6 and earlier, ensure you include the trailing dot to mark the host entry as a FQDN; as a Fully-Qualified Domain Name. With 10.7 and later and the Server.app tool, the configuration is less fussy about the need for the FQDN; for a specification with the trailing dot.

example.com, example.org, example.net

The second-level domain names example.com, example.org and example.net are reserved by RFC 2606 and by the Internet Assigned Numbers Authority (IANA) for use in documentation and example code. These three domains are explicitly and intentionally not registered, and are available for use in documentation and examples.

Please do not obfuscate with other domain names, as that tends to cause confusion, and it's commonplace for attempts at obfuscation and at picking a bogus domain to select real and registered domain names.

Picking a Bogus Top-Level Domain (TLD)

If you are not in a position to spend US$10 or so to register a domain name per year, then you can pick and use a bogus domain name. This is a private and never-registered domain. This domain and the top-level domain must be bogus; you do not want to collide with a real and registered domain name.

Specifically:

  • Do not use a real TLD.
  • Don't use .COM or .NET or any other existant or likely-existent domain.
  • Do not use .local
  • Do not use .PRIVATE.
  • Do not use any RFC-reserved TLD.

This approach is effective, easy, requires no registration, and (if you have picked a “bogus” name) will not collide with another domain. While this approach works and avoids the registration, HoffmanLabs recommends registering a domain. If you ever need to go public with your domains, you'll have to rebuild some or all of your entire infrastructure. That's going to require time and effort and network down-time; you'll spend far more than you saved on the domain registration.

Mac OS X tends to expect DNS will have a TLD and a domain; that would be the fully-qualified zone name yourorganization.xyzzy. from the earlier examples. Note the trailing dot. Example fully-qualified domain names for web and mail would therefore be www.yourorganization.xyzzy. mail.yourorganization.xyzzy., respectively.

HoffmanLabs recommends picking and using a public domain that your organization has registered.

Referencing Your New DNS Server

You will want to reference your (new) Mac OS X Server DNS server(s) IP address in the following places:

  • In your DHCP server(s). This could be in an Airport Extreme, Time Capsule, Mac OS X Server DHCP Server service, or within whatever firewall/router box that you are using here. Also set your search domain; your default DNS domain. This is usually established in the same part of the configuration where you set up your DNS server address. The default domain name isn't strictly necessary (you'll have to specify the full host name if you haven't set it), but (when set) the default domain name usually the same name as used as your zone name in your DNS server.

    If you have clients using DHCP, these boxes will have to renew their DHCP leases to receive the new information from your DHCP server(s). In Mac OS X 10.6 clients using DHCP, launch System Preferences, select Network, select your active network connection, select Advanced, Select TCP/IP, and select Renew DHCP Lease.
  • Configure your new DNS server(s) within the set-up for any static-configured controllers (network interfaces) you might have configured on any other local servers.
  • On your newly-configured DNS server, configure the controller (network interface) on the server to reference the host localhost (or the 127.0.0.1 address) as the DNS server; to loop or direct the local DNS host's own DNS queries back to the local DNS server box itself. This will cause the DNS server box use itself for DNS. Use the IP loopback address here, and not the host's own IP address.
    What is this localhost and 127.0.0.1 stuff? These are self-referential names within IP networking; these are a host name for the local host and an IP address of the local host, respectively. These constructs work on all hosts, and are entirely independent of other host names and other IP addresses assigned to the host.

The only references to your ISP DNS servers or to Google DNS or such will be as DNS forwarding entries within your DNS server configuration (if you are using DNS forwarding), and these DNS forwarding entries are not required, and are commonly not used. DNS servers can locate and can communicate directly with other DNS servers, and do not require information on other DNS servers.

Referencing Multiple DNS Servers

When configuring a DNS server(s) on a client box or within a DHCP server, you'll usually be prompted for multiple DNS server references on the client device or within the DNS server. This is a list of DNS servers that are all interchangeable and with the same content and same translations, and the first working server will be used for the queries. Prior to the Mac OS X 10.6.3 update (HT4030), this is not a list of DNS servers to query in sequence, if the first does not know the translation. Either reference your own DNS server(s) or reference your ISP DNS server(s). Do not reference both your own DNS server(s) and your ISP DNS server(s) in these lists; your own server(s) inherently have a different list of hosts than your ISP servers. And your own DNS server(s) will query the ISP server for translation information the local DNS server doesn't have and hasn't cached; the DNS server will submit your query to an upstream DNS server on your behalf.

An implication of this assumption of interchangeability of DNS servers is around the necessary reliability of the DNS servers and services. Larger organizations run multiple parallel DNS servers; same translations, same content. This because of the way these lists work. If your only DNS server is down, you won't have any DNS translations available. Again, it's not a sequential lookup until you find a match. You contact a running DNS server from the list, and you get a match. Or you don't. And the DNS processing ends.

The only references to your ISP DNS servers or to Google DNS or such will be as DNS forwarding entries within your DNS server configuration (if you are using DNS forwarding), and these DNS forwarding entries are not required, and are commonly not used. DNS servers can locate and can communicate directly with other DNS servers, and do not require information on other DNS servers.

Domains with IP Addresses, Wildcard domains

Caution: There are problems with this wildcard set-up within recent BIND on Mac OS X, and Server Admin with 10.6.3 can refuse to accept the syntax.

To have your domain translate as an IP address, add an entry for the domain name into the zone; add an A record entry for example.com. (with the trailing dot) into your zone. The trailing dot makes this entry a Fully-Qualified Domain Name (FQDN), meaning it will not inherit the zone name as part of generating the FQDN.

Note: With Mac OS X Server 10.6.5 and the associated Server Admin tools, you can add the specification directly into Server Admin; enter the domain as the FQDN.

With some other releases of Server Tools or to add a wildcard (a default IP address for missed translations or unknown domains within the authority of your DNS server(s)), add a wildcard entry *.example.com. (an asterisk, the domain, and again with the trailing dot) or add an A record for * (an asterisk, with nothing after it) and (in either of these two cases) reference the IP address you want to field the request.

  • On Mac OS X 10.6.2 and and prior to 10.6.5, shut down DNS server, and then shut down Server Admin.
  • Launch Terminal.app and start the command shell.
  • Enter the command to change your default directory to the directory containing the zone-config files; cd /var/named/ (older releases; 10.6 and earlier) or cd /Library/Server/named/ (newer releases; 10.7 and later)
  • Open the zone file in an ASCII text editor sudo nano db.example.com. for your particular zone; example.com is shown here. You will have to enter your root password.
  • Move to the bottom of the file. Leave the $INCLUDE unaltered. The following two A record entries will add translations for no host name (just the domain name) and for any host name that does not already have a matching A record to the 192.168.1.1 host. With the second (asterisk) entry, note the use of your zone name with the trailing dot (the FQDN) and with your target IP address translation specified; to 192.168.1.1 as shown here.
    example.com.                             IN  A 192.168.1.1
    *.example.com.                IN  A 192.168.1.1
  • Restart your DNS server

Caveat: avoid modifications to the Apple DNS zone files in /var/named/zones (the zone files are stored in /Library/Server/named/ on newer releases, and are not directly editable) as these modifications may cause Server Admin problems going forward; modifying configuration files underneath Server Admin has been known to cause various problems and confusions and instabilities. Editing the DNS configuration files located in the /var/named directory is comparatively safe, while edits made to the DNS configuration files in /var/named/zones can confuse or can potentially be overwritten by Server Admin.

Example dig response

The following example case shows a query for a host that also happens to be the default local DNS server.

Paraphrasing and simplifying the sections slightly, the response to this dig request shows some details from the command response, the question the DNS server believes you asked of DNS, the answer that you have received from the DNS, the DNS server that returned the information, and the timing of the DNS response, respectively.


$ dig hostname.example.net
 
; <<>> DiG 9.6.0-APPLE-P2 <<>> hostname.example.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35339
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
 
;; QUESTION SECTION:
;hostname.example.net.		IN	A
 
;; ANSWER SECTION:
hostname.example.net.	10800	IN	A	192.168.21.9
 
;; AUTHORITY SECTION:
example.net.	10800	IN	NS	hostname.example.net.
 
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 17 16:12:21 2010
;; MSG SIZE  rcvd: 68
 
$ 

Assigning a Static IP Address

If you have a network support team, ask for a static IP address.

If you are the network support team, pick an IP address that is not in a pool of IP addresses any local DHCP server has been allocated, and that is not in use on another IP host on your network, and usually an address within the same IP subnet as the rest of your local network, and (once allocated) add a matching entry for your host into the DNS configuration.

The IP address is set (on both Mac OS X and Mac OS X Server) using System Preferences > Network panel, on the network controller you are using. Disable DHCP configuration on the network controller, select the manual option, and enter the IP address, the IP gateway, the DNS server address(es), and the subnet mask.

Summary

You now have a DNS server.

Services and support (on-site and remote) are available from HoffmanLabs.


 

Glossary

This article attempts to use and to maintain consistent definitions for terms including the domain name, host name, zone name, FQDN and other DNS-related constructs. The following glossary is intended to assist in understanding what each of these terms mean.

Term Meaning
A Record This is a record for a specific host using IPv4 networking. An A record is also called a machine record. An A record may or may not be fully-qualified.
AAA Record This is a record for a specific host using IPv6 networking. An AAA record is also called a machine record. An AAA record may or may not be fully-qualified.
Bogus Domain Using an unregistered and (correctly) made-up domain is effective, easy, requires no registration, though should you ever need to connect to the Internet, you'll end up having to rebuild some or all of your entire infrastructure. This network rebuild is going to require substantial time and effort and network down-time; you'll almost certainly spend far more than you saved by skipping the domain registration.
Domain Name To a new DNS administrator, this name is probably the most confusing aspect in all of DNS. A domain name is organized hierarchically, and portions of the specification can be defaulted, depending on the context. A domain name may or may not have an associated IP address. The domain name is a hierarchy of dot-separated names that defines the path from the Internet root servers (represented by the trailing dot in the so-called Fully-Qualified Domain Name (FQDN)) to the particular top-level domain (TLD) or domain or subdomain name. A domain name is typically built from a dot-separated list of hunks of text, starting with the trailing dot (for the FQDN, and often assumed outside the context of setting up a DNS server), the TLD, the domain name, zero or more subdomains, and the rightmost hunk is often the host name. A domain name may or may not have an IP address associated with it, and a domain or subdomain with an IP address is often called a host name.
Dot The . character. The separator used between the fields of a domain name.
Fully-Qualified Domain Name (FQDN) The Fully-Qualified Domain Name is the complete specification of the name of the domain or zone or host, with that trailing dot indicating the root of the whole DNS hierarchy. If the domain name specification lacks that trailing dot, then it is a relative specification, and additional defaults from the domain or zone will be applied to the right of the name. www and www.example and www.example.com are not FQDN specifications, and will have further defaulting. www. and www.example. and www.example.com. are all FQDN specifications, and no further defaults will be applied.
Host Name A domain or subdomain name with an associated IP address.
Assume that dns and plugh.example.com and plugh.example.com. can and all are host names, if the DNS server has an A or AAA record (machine record) for the host with an associated IP address. The first two host names (dns and plugh.example.com are not shown as fully-qualified names, which means that defaulting will be applied to the rightmost portion of the host name to produce an fully-qualified name for the host. Defaulting is based on the zone name.

An IPv4 host typically has one A record; one machine record, and an IPv6 host typically has one AAA record; one machine record.
Root Servers These DNS servers are at the top of the public DNS hierarchy. The Internet has a number of root servers, and the list of and IP (host) addresses of the root servers sometimes changes.
Subdomain name An optional portion of the DNS hierarchy to the left of the domain name that allows a DNS administrator to assign host names (subdomains with IP addresses) based on functional or geographic or network topology. Zero or more subdomains can be present in the FQDN.
Top-Level Domain (TLD) This is the rightmost dot-separated text field within the FQDN. Examples here include COM, NET, ORG and any of the various country-code TLDs. These TLDs exist in the hierarchy just below the root servers.
Zone Name The domain or subdomain name associated with a particular DNS server. The zone name is part of the name for a non-FQDN specification within a DNS server configuration; the zone name is used when a non-fully-qualified name is converted into a fully-qualified name.
The non-FQDN host dns with an A record of 192.168.1.30 within FQDN zone example.com. associated with the FQDN domain example.com. produces the FQDN plugh.example.com. for the host. DNS servers are typically configured to be authoritative for a particular zone name, and host names are configured within this zone using A or AAA records (machine records) or CNAME (alias records), and each A or AAA record with the associated IP address and the CNAME with the alias host name.

 

Updates and revisions

Most recent changes listed first.

  • 27-Dec-2013 — Server.app on 10.7 and later is less sensitive around the trailing dot in the host specifications; the FQDN.
  • 5-Oct-2013 — rewrote the text around DNS forwarders
  • 26-Jul-2012 — added a link to an odd DNS error
  • 4-Mar-2012 — added links to the Server Tools package; detailed how to acquire the Server Admin tool when working on Lion Server, or on OS X client
  • 3-Nov-2011 — added a link to a GroupLogic ExtremeZ-IP Bonjour-across-subnets whitepaper (below). Fixed a minor formatting issue.
  • 3-Nov-2011 — Lion Server DNS configuration is nearly the same as configuring DNS on Snow Leopard Server
  • 21-Jul-2011 — tweaked some text around port 53 references.
  • 17-Jul-2011 — added a link to a changeip article
  • 22-May-2011 — added a new link; no other changes.
  • 9-Apr-2011 — example.com and example.net are examples, and not domains you should actually use.
  • 9-Apr-2011 — strengthened wording around the potential for cost savings (US$10 per year, or less) with picking a bogus domain, and the penalty (and substantially more than US$10) of the penalty incurred if you should later need to rebuild the network to allow a connection to the Internet.
  • 25-Mar-2011 — fixed a typo in a domain name in the domain-choice table, and some formatting in the revision history.
  • 15-Feb-2011 — minor edits
  • 22-Jan-2011 — link to the networking topic index
  • 17-Dec-2010 — minor edits
  • 01-Nov-2010 — forwarding was a source of confusion.
  • 27-Oct-2010 — fixed two garbled links; thanks, Sean. Added a section that documents what split-horizon DNS means.
  • 26-Oct-2010 — added a link to HT3789
  • 17-Oct-2010 — added a quick paragraph on static IP configuration.
  • 28-Sep-2010 — added a reference to the .private paralleling the .bonjour TLD.
  • 21-Jul-2010 — added a section on DNS forwarders.
  • 11-Jul-2010 — updated links to other site articles.
  • 3-Jul-2010 — clarified what the host name of the DNS server is, and added links to new articles.
  • 26-Jun-2010 — added a reference to the DNS Tips: Referencing A DNS Server On Snow Leopard article.
  • 23-Jun-2010 — added the glossary
  • 21-Jun-2010 — added more URLs; more links to information here at HoffmanLabs.
  • 15-Jun-2010 — added a link to the mDNS RFC and sprinkled another warning around (mis)using the .local TLD, and a caveat around wildcard DNS processing with 10.6.3.
  • 4-Jun-2010 — add a reference to split-horizon.
  • 28-Apr-2010 — added the DNS database file locations, correct the zone file modified for wildcard entries, and clarify the purpose, intent and use of secondary DNS servers and secondary zones.
  • 13-Apr-2010 — added a sequence and a description for wildcarding a domain based on information by
    Tom Schmidt; thanks, Tom. Also fixed a typo that was noticed.
  • 30-Mar-2010 — added a reference to avoid the mDNS .local TLD, and stronger wording around unregistered domains.
  • 29-Mar-2010 — added a link to HT4030 and the DNS server ordering first available with Mac OS X 10.6.3 release.
  • 18-Mar-2010 — fix a typo. Rework the wording in the secondary zones configuration. Referenced the DNS troubleshooting article.
  • 5-Mar-2010 — added more details on referencing the new DNS server(s). Added wording around deleting both the forward and the reverse zones.
  • 25-Feb-2010 — added this revision history. Clarified wording on the creation of the reverse zone. Some reformatting.

 

Mac OS X Networking and Related Articles

In addition to the Index: Mac OS X Server and Client Networking topic index, here are some of the following topics here at HoffmanLabs may be interesting to readers of this article:

Still have questions?

Is DNS still a mystery? Commercial DNS configuration services are available from HoffmanLabs LLC.

Comments

Beware Domain Squatting

With the proliferation of new top-level DNS domains increasingly available from ICANN, US CERT has issued Alert (TA16-144A) WPAD Name Collision Vulnerability; on why you don't want to squat on a made-up domain that matches an existing or eventually matches some new public top-level domain — anybody that can add entries in the public DNS for that top-level domain can end up owning your supposedly-private DNS and your clients via Web Proxy Auto-Discovery (WPAD).

Add OS X Server Account issue when DNS is set up as subdomain

I am encountering a strange problem with the “Add OS X Server Account” functionality in OS X Server 5.0.15 (running on OS X 10.11.3). My OS X Server DNS is private and behind a router/firewall and is set up to be a non-delegated subdomain of my registered domain - and always has been. All other functionality aside from Add OS X Server Account is working correctly.

When I attempt to add an OS X Server Account (either via iOS 9 Mail,Contacts, Calendars, Other OS X Server Account - or via internet accounts in OS X 10.11 - I receive an “Invalid User ID or Password” regardless of which user I log in with.

For the purpose of this example - my current DNS setup on my server is as follows:

Registered Domain: example.com (my actual domain is something else - of course).

My “home” server DNS subdomain is home.example.com

In my DNS I have the following

Server Host Name: server.home.example.com
Primary Zone: home.example.com - no zone transfers
A (host) record: server.home.example.com 10.0.1.8
NS record: server.home.example.com Zone: home.example.com
Reverse Zone (Automatic) 1.0.10.in-addr.arpa
PTR record: 10.0.1.8 server.home.example.com
NS record: server.home.example.com Zone: 1.0.10.in-addr.arpa

This minimal configuration has been this way for a long time and has worked just fine (until I attempted to use “Add OS X Server Account” functionality.

In my public DNS for example.com
I have two several A records but no actual delegation of the subdomain.

server.home.example.com A xxx.xxx.xxx.xxx (my router ip)
home.example.com A xxx.xxx.xxx.xxx (my router ip)
wiki.home.example.com CNAME server.home.example.com

Externally these all resolve correctly.

With the above setup - I receive the invalid user id or password when trying to “Add OS X Server Account”.

However - if I make the following change to my local DNS (and likewise adjust the public DNS) - everything works fine - and I am not understanding why - other than it is a possible bug in the Add OS X server account functionality:

Server Host Name: server.example.com
Primary Zone: example.com - no zone transfers
A (host) record: server.example.com 10.0.1.8
NS record: server.example.com Zone: example.com
Reverse Zone (Automatic) 1.0.10.in-addr.arpa
PTR record: 10.0.1.8 server.example.com
NS record: server.example.com Zone: 1.0.10.in-addr.arpa

With the above configuration (not a subdomain rather a mirror of my public domain - per-se) - the Add OS X Server account functionality works fine. The problem with the above configuration is that I cannot get to my external domain and that is why I was using a subdomain.

It seems that the add OS X server account functionality is having an issue when the OS X Server DNS is configured as a subdomain. Have I missed something obvious. I have read most of the DNS and BIND book and have a general understanding of what I am doing - and why am I experiencing issues only with the Add OS X Server account functionality. Is this possibly a bug in that functionality? I have not attempted to use OS X Server account functionality in the past - so I don’t know if this is a new problem. Also this should not be confused with OS X Server Network Accounts which are working fine everywhere that I am using them.

Thanks for any insight.
~Scott

Will need zone data...

Verify the forward and reverse translations for the server. But without seeing the zone files involved, what's happening here is not clear. Obfuscate all of that data (consistently!) from the zone files, and post it. That the changes are being made to internal and external DNS is confusing — that should not be necessary, and the external DNS servers should not be queried nor involved in the translations for any domains or subdomains that the internal DNS server(s) are authoritative for.

Zone data for server.dev.example.com (subdomain)

Please see my subsequent reply with correctly formatted zone file data.

Formatted Zone File Data

Please excuse the previous post with the unformatted zone file data.

==========================================================
File: named.conf
==========================================================

include "/Library/Server/named/rndc.key";
options {
	directory "/Library/Server/named";
	listen-on-v6 {
		"any";
	};
	allow-recursion {
		com.apple.ServerAdmin.DNS.public;
	};
	allow-transfer {
		none;
	};
	forwarders {
	};
};
controls {
	inet ::1 port 54 allow {
		"any";
	} keys {
		"rndc-key";
	};
};
acl "com.apple.ServerAdmin.DNS.public" {
	localnets;
};
logging {
	channel "_default_log" {
		file "/Library/Logs/named.log";
		severity info;
		print-time yes;
	};
	category "default" {
		"_default_log";
	};
};
view "com.apple.ServerAdmin.DNS.public" {
	zone "localhost" IN {
		type master;
		file "localhost.zone";
		allow-update {
			none;
		};
	};
	zone "0.0.127.in-addr.arpa" IN {
		type master;
		file "named.local";
		allow-update {
			none;
		};
	};
	zone "7.0.10.in-addr.arpa" IN {
		type master;
		file "db.7.0.10.in-addr.arpa";
		allow-transfer {
			none;
		};
		allow-update {
			none;
		};
	};
	zone "dev.example.com" IN {
		type master;
		file "db.dev.example.com";
		allow-transfer {
			none;
		};
		allow-update {
			none;
		};
	};
	zone "." IN {
		type hint;
		file "named.ca";
	};
};



==========================================================
File:  db.dev.example.com
==========================================================


dev.example.com.		      10800 IN SOA	dev.example.com. admin.dev.example.com. (
							2016012405
							3600
							900
							1209600
							86400)
				      10800 IN NS	server.dev.example.com.
server.dev.example.com.	      10800 IN A	10.0.7.8





==========================================================
File: db.7.0.10.in-addr.arpa
==========================================================


7.0.10.in-addr.arpa.		      10800 IN SOA	7.0.10.in-addr.arpa. admin.7.0.10.in-addr.arpa. (
							2016012403
							3600
							900
							1209600
							86400)
				      10800 IN NS	server.dev.example.com.
8.7.0.10.in-addr.arpa.		      10800 IN PTR	server.dev.example.com.




=========================================================
Forward and Reverse Lookups
=========================================================

server:~ adminuser$ dig -x 10.0.7.8

; <<>> DiG 9.8.3-P1 <<>> -x 10.0.7.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65418
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;8.7.0.10.in-addr.arpa.		IN	PTR

;; ANSWER SECTION:
8.7.0.10.in-addr.arpa.	10800	IN	PTR	server.dev.example.com.

;; AUTHORITY SECTION:
7.0.10.in-addr.arpa.	10800	IN	NS	server.dev.example.com.

;; ADDITIONAL SECTION:
server.dev.example.com. 10800 IN	A	10.0.7.8

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jan 24 17:06:43 2016
;; MSG SIZE  rcvd: 108

=======================================

server:~ adminuser$ nslookup 10.0.7.8
Server:		127.0.0.1
Address:	127.0.0.1#53

8.7.0.10.in-addr.arpa	name = server.dev.example.com.


=======================================


server:~ adminuser$ sudo changeip -checkhostname
Password:
dirserv:success = "success"

=======================================

server:~ adminuser$ nslookup ibm.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	ibm.com
Address: 129.42.38.1

=======================================

server:~ systemadmin$ dig hostname server.dev.example.com

; <<>> DiG 9.8.3-P1 <<>> hostname server.dev.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41514
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;hostname.			IN	A

;; AUTHORITY SECTION:
.			10800	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2016012401 1800 900 604800 86400

;; Query time: 41 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jan 24 17:18:08 2016
;; MSG SIZE  rcvd: 101

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26184
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;server.dev.example.com.	IN	A

;; ANSWER SECTION:
server.dev.example.com. 10800 IN	A	10.0.7.8

;; AUTHORITY SECTION:
dev.example.com.	10800	IN	NS	server.dev.example.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jan 24 17:18:08 2016
;; MSG SIZE  rcvd: 73

server:~ adminuser$ 


server:~ adminuser$ 

Zone files look okay

That data looks fine.

I'll assume there's nothing added to /etc/hosts here.

Next stop would be any chatter in the console logs — check Console.app for that — that might be produced by Server.app around the failures.

Here is /etc/hosts and a few more observations

Here is /etc/hosts (never touched by me)

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost

When I first discovered this problem (prior to realizing it was subdomain-related) - I was watching the console logs (on the client side on the Mac) while attempting to Add OS X Server Account. There was some minor chatter in the console on the client side - but it was not very definitive - and may not have even been related to the invalid user id or password. Right at that time - another update to OS X 10.11 became available - and I decided to do a clean install on the server at that time - with hopes of the clean install clearing up this issue - so I never got around to watching the console on the server side. I will do this next - now that I have some idea of what I am looking for.

Also - I wanted to point out - there are actually two DNS setups that "work" with the Add OS X Server Account - and both setups are still domain - vs subdomain (meaning only two dots in the host name). I will abbreviate here and I think you will follow the shorthand.

Scenario 1 (works)
hostname: server.example.com
Zone: example.com
Machine: server.example.com A 10.0.7.8
Name Server: server.example.com
Reverse: 7.0.10.in-addr.arpa
Name Server: server.example.com

Scenario 2 (works) - but is undesirable for several reasons - and sometimes occurs by default in server setup.
hostname: server.example.com
Zone: server.example.com
Machine server.example.com A 10.0.7.8
Name Server: server.example.com
Reverse: 8.7.0.10.in-addr.arpa
Name Server: server.example.com

Also "server" in the above examples can be "any" name.

I tried the Scenario 2 setup using a subdomain "server.home.example.com" - wondering if it would resolve the issue - but it did not.

Also tried adding OS X Server account using the ip 10.0.7.8 rather than the fqdn - wondering if it was some type of parse issue on the fqdn - and it made no difference.

I will report back more results - and most likely I will end up filing a bug report with Apple - but I need to be "prepared" before I embark on that.

Default Scenario

Ayup; Scenario 2 is default for configurations without local DNS; the single-host DNS configuration that usually gets removed when DNS is established.

I've assumed that local DNS caches are flushed after changes. Omitting that can sometimes cause confusion.

Console.app data around the Server.app (mis?)behavior would be next.

I appreciate your help so

I appreciate your help so far. You aren't seeing anything awry in my zone files and I'm not seeing any obvious errors on my end when the account credentials don't validate - and I can get it to work only as a 2nd-level domain (and what I want is a 3rd-level domain) - everything is pointing to a bug in the Add OS X Server Account functionality (on both Mac and iOS 9). Since it happens on the Mac client side (as far back as Mavericks) - it's either being caused by Server Version 5 - or has existed all along. I have contacted Apple and have a call scheduled with their Server tech support tomorrow hoping they will either confirm as a known issue or a new issue - before I jump through hoops to file a bug report. I will post my findings back here.

~Scott

Nothing definitive in console or server logs. Further Results.

Yes - I always remove whatever DNS the server setup creates and start from scratch. Scenario 2 was only for troubleshooting. Also I noticed that as of Server 5 - it more or less forces a default of Scenario 2 - even when you use the domain host name setup option - which is slightly different than Server 4 (Server 5 seems to now involve fewer choices in the guided setup).

When I do my testing of working and non-working scenarios - I use and iPhone 6 on iOS 9.2.x and a Mac running El Capitan 10.11.3. The add OS X Server Account is new as of iOS 9 (I believe) and the Add OS X Server Account has existed since Mavericks. In a couple of tests of booted up fairly clean installs of Mavericks and Yosemite from an external bootable image - and I still end up with the same results - when testing on the Mac side. For iOS 9 there is no way for me to view a log of what is going on.

On a few occasions I have flushed the DNS cache on both the client and server Macs - with no difference in results.

I have watched both the console and the server logs on the server side - and there is no indication of anything succeeding or failing. When it works (and I am able to successfully add the OS X Server account) - there is no indication on the server side under file sharing that there is any user connected to the file sharing service (Connected users = 0). Yet from my iPhone I can see the shared folder and can actually manipulate files in the folder.

On the client side (Mac only) - when I watch the console - the only messages that I see appear to be related to the certificate (the default self signed cert created by server) - I have even redone the certs on a few occasions. I get the same messages on the client Mac side of the test - even when it successfully adds the OS X Server account - thus I assume that they aren't directly related to the problem I am having with this one functionality.

To factor out more unknowns - I have now brought the server down to bare bones configuration and I can can get the OS X Server account to fail or add successfully - based on how I set the host name (in all three setup scenarios ... .local .private and using a domain name). I can actually entirely remove open directory and even turn off DNS - and the OS X Server account will still work successfully (or fail with the same error) in the configurations that follow. Thus I believe it may not actually be related to DNS or Open Directory.

So - the "only" service running is File Sharing - and optionally DNS.
Edit: On the OS X client side - to actually add an OS X Server account - services such as contacts or calendars needs to be running - however - in the case of only File Sharing running - the connection test is successful if it yields a "No services for this account" message rather than "invalid user id or password".

Scenario 1: local host only - no DNS no Open Directory - File Sharing Running
hostname must be {computername}.local (this allows os x server account to be added - using the servers system admin login)

Scenario 2: private setup - Optional DNS - no Open Directory - File Sharing Running
hostname must be {somehostname}.private in order to work (only 1 dot in hostname) somehostname.something.private fails (more than 1 dot).

Scenario 3: domain setup - Optional DNS - no Open Directory - File Sharing Running
hostname must be {somehostname}.{2ndLevelDomain}.{topLevelDomain} (2 dots in hostname). {somehostname}.{3rdLevelDomain}.{2ndLevelDomain}.{topLevelDomain} will fail (more than 2 dots)

I am now at a point where I may need to restore the server to get it back to a clean install state (and possibly make an external bootable version for further troubleshooting).

Can you point me to where I would logically need to look in server logs - I am truly seeing nothing - and I am pulling my hair out. The fact that there is little or nothing that pops up on a Google search - would lead me to believe this functionality is not being widely used.

Best to chat with Apple Support here...

I use Console.app to rummage the logs for these cases, as that shows messages across all of the known logs. Which is an approach that only works if the systems are quiet, when the reproducer is tried. Otherwise the messages scroll off too quickly. But if you've tried that and aren't seeing any related messages, then — barring debugging code that can be enabled in Server.app or in whatever is failing here — there are no messages.

Issue Reported to Apple

This issue has been reported to Apple and is being investigated. I will post back when I have a definitive answer.

Problem Resolved in Server version 5.1 (released March 22, 2016

This problem is resolved by updating to Server 5.1. The issue was caused by an internal truncation of the server's host name (fqdn) to 24 characters - impacting only the Add OS X Account functionality.

Clarification of the situation - while I gather the zone data

Hi - Thanks for such a quick response.

I will collect the various zone files and paste contents into a single document - and obfuscate consistently. I need to put things back to the problem configuration first. Do you want the files to come from /Library/Server/named or from /var/named or /var/named/zones ?

In the meantime - to lessen the confusion that may have resulted from my statement of the problem:

This is a home install of OS X Server - for learning purposes - have been using it for quite a while. A few weeks ago I started over and did a clean re-install of OS X 10.11.3 and Server 5.0.15 (the problem was first noticed prior to doing this - upon my first experimentation with the "Add OS X Server" account on iOS 9 and in El Capitan. In all other respects my testing and observation indicates that DNS is fine. I did post this issue on discussions.apple.com - but nobody has offered any suggestions and quite a few people are indicating "they have this issue to". However - it was just yesterday that I realized that the problem happens only when OS X Server DNS is set up as a "subdomain" - and I don't think that the others with this issue have realized this.

I have a registered domain (at goDaddy) - which publicly does nothing other than a splash page and contains a couple of host entries that point to my OS X Server - which work as I intended. I doubt there is any issue on the GoDaddy side - and I suspect I can replicate the issue entirely internally.

When I say I have changed the DNS settings internally and externally - that was in a troubleshooting attempt and I basically would start over either with DNS set up as a mirrored domain "example.com" or as a subdomain "home.example.com". It doesn't seem to matter how I name the subdomain internally (example xyz.example.com rather than home.example.com) - the problem still occurs.

To greatly simplify things - if I change the DNS setup - I also recreate the OD Master. There aren't even any users in OD - this problem can be produced simply with the system admin local account. The server is currently in a state of absolute minimum configuration where it can easily be "redone". Only DNS, OD, File Sharing and Wiki are running.

Hopefully this clarifies the situation a bit.

~Scott

TXT record v=spf1 mx ~all redux

Ah… kindly disregard my last query -- I overlooked the most obvious answer. Apple has chosen to use the word 'comment' in the A record form within the Server Admin. Our precious SPF text goes in that field for the zone A record (example.com) to achieve a dig as follows: example.com. 86400 IN TXT "v=spf1 mx ~all" and mail servers were all the happier. My oversight, sorry for the amateur question, but perhaps my silliness will help someone else.

SPF txt records

Hoff - I appreciate the excellent reference. One small item that may need addressing is TXT records for a zone. Is there a proper way to make use of the Server Admin tools to add a TXT record for a zone? I have backup admins for whom jumping into the CLI to make modifications would be potentially hazardous, but would love to be able to rely upon them to properly modify zone records as needed through the Snow Leopard Server admin for SPF needs. Is there a way to work with the Server Admin to properly configure a Service record (add in a TXT SPF record entry)? Thanks!

Nope...

I usually configure Spamassassin to treat mail servers with valid SPF records as more likely to be spam sources. This because the spammers are increasingly creating brand-new domains that are entirely valid and with SPF records and the rest as a way around these checks, and because some of the registrars are now masking the domain registration dates.

As for your question, I never managed to get either TXT nor SRV records working reliably on Snow Leopard Server / OS X Server 10.6, short of shutting down Server Admin.app and editing the BIND configuration files. I've also seen a couple of cases where Server Admin.app was confused by some file-level configuration changes, as well. So that's not necessarily entirely reliable.

I'm not usually running OS X Server DNS servers that are "publicly" visible, so setting up SPF would involve the DNS provider and not the OS X Server DNS server.

Local servers are largely either upgraded off of 10.6, or that migration is now underway.

Sadly, I have to stay with OSXS 10.6 for a while longer

I can relate to long-in-the-tooth deployments. One of my clients is still using QuickDNS in System 9.1. Remarkably solid software for being so many generations back.

On some of our machines, I use third party tools that will leave me in 10.6. Personally, I felt Apple came closest with a real GUI admin with the 10.6 release, but as you say, it remains finicky and somewhat half-done. I do encounter traffic from other mail servers that will not play nice unless we have the SPF record, and to that end, I wanted to explore using these light-duty machines for DNS services. As I mentioned in another post, the GUI language threw me off -- I wasted no small amount of time exploring the Admin SVC record tools, wherein the answer lay right in front of me in the A record comment section. There was an answer on pg58 of Apple's own documentation, Network_Services_Admin_v10.6. Mea Culpa.

Thanks for the speedy reply! - vail

Domain name changing under my feet

I have a Lion Server on a local network connected to a FRITZ!Box 7390 router. I follow the instructions on this page, reboot, and run

sudo changeip -checkhostname This is what I see

Primary address = 192.168.123.1

Current HostName = www.mitchell.ch
DNS HostName = www.mitchell.ch

The names match. There is nothing to change.
dirserv:success = "success"

So everything looks fine. However, a few seconds later when I rerun the command I get

Current HostName = www.mitchell.ch
DNS HostName = www.fritz.box

So the domain has changed under my feet! Now the settings seem OK as far as I can tell. I have one primary zone, mitchell.ch, with one machine entry underneath, for www.mitchell.ch. And a reverse mapping from 192.168.123.1 to www.mitchell.ch. So this seems like what I'd expect having followed the instructions.

However, the log file looks a bit worrying:

01-Aug-2013 09:55:56.726 zone 0.0.127.in-addr.arpa/IN/com.apple.ServerAdmin.DNS.public: loaded serial 1997022700
01-Aug-2013 09:55:56.726 zone 123.168.192.in-addr.arpa/IN/com.apple.ServerAdmin.DNS.public: loaded serial 2013080101
01-Aug-2013 09:55:56.726 db.mitchell.ch:9: warning: '192.168.123.1.': MX is an address
01-Aug-2013 09:55:56.727 zone mitchell.ch/IN/com.apple.ServerAdmin.DNS.public: NS '192.168.123.1.mitchell.ch' has no address records (A or AAAA)
01-Aug-2013 09:55:56.727 zone mitchell.ch/IN/com.apple.ServerAdmin.DNS.public: not loaded due to errors.

Anyone got any idea of what might be going on here? Have I missed something in the instructions? Have my server configuration files got corrupted?

Zone File?

You should have a primary zone zone file named /Library/Server/named/db.mitchell.ch around.

Please post a copy of that.

Here's an example of one of these zone files, for the example.com domain:

$ cat /Library/Server/named/db.example.com
example.com.			      10800 IN SOA	example.com. admin.example.com. (
							2013080103
							3600
							900
							1209600
							86400)
				      10800 IN NS	www.example.com.
www.example.com.		      10800 IN A	10.20.30.40

It would appear that the MX record and nameserver record are problematic.

Zone file location and contents odd

Thanks for the suggestion. I didn't appear to have a directory called named in /Library/Server. I did a search for db.mitchell.ch and found a directory called /private/var/named with the file db.mitchell.ch in it, created today. So the server admin tool presumably created it. And it seems to have some odd entries in it:


mitchell.ch. 10800 IN SOA mitchell.ch. postmaster.mitchell.ch. (
2013080107 ; serial
86400 ; refresh (1 day)
3600 ; retry (1 hour)
604800 ; expire (1 week)
10800 ; minimum (3 hours)
)
10800 IN NS 192.168.123.1.mitchell.ch.
10800 IN MX 0 192.168.123.1.
mail.mitchell.ch. 10800 IN A 192.168.123.1
www.mitchell.ch. 10800 IN A 192.168.123.1

So I suppose there are two questions, why is the file in a different location (I'm running 10.7.5 in case that helps) and is it safe to delete the named directory, i.e. does the server admin tool recreate it if it is missing? All these GUI frontends are great when they work, but when they don't it's hard to know what they are doing underneath :-(

Thanks

Kevin

Tweak the MX and NS records first...

Sorry; my mistake around the version and the particular directory organization.

Both the name server (NS) and mail exchange (MX) records are incorrect; the zone definition has errors.

There are also two A records for the same IP address, and the mail server MX record is generally the one that wants and needs to be an A record. It doesn't need to be named "mail" however.

I'd probably set www.mitchell.ch as an A record for 192.168.123.1, a CNAME for mail.mitchell.ch to www.mitchell.ch if you wanted to use that name, and the name server as www.mitchell.ch.

As for the GUI, what's underneath is bog-standard ISC BIND; a very common DNS server.

MX

PS: If you configure mail.mitchell.ch as a CNAME, use www.mitchell.ch as the MX (or whatever you're using as an A); the MX needs to be an A record, and going from the A to the IP address and back, the PTR record for the address needs to match.

Thanks

I manually edited the file, following your suggestions, and it all seems fine now. Thanks for your help.

.local is now officially special

.local is now considered a special-use top-level domain. This applies to the top-level domain, and all subdomains.

For further details, see RFC6761 and RFC6762.

RFC6762 does reference the following DNS domains for private use: .intranet., .internal., .private., .corp., .home. and .lan.

Why exposing your DNS server can be trouble

Why you don't want to be running an open DNS server; don't expose your internal DNS server off your network; to the Internet.

Put another way, don't open up TCP port 53 inbound through your external network gateway-firewall-router box.

OS X Host Name Queries

For reference, here are the commands to retrieve the host name for OS X or OS X Server.

$ scutil --get ComputerName 
myhost
$ scutil --get HostName 
myhost.example.com
$ scutil --get LocalHostName 
myhost
$

This name should match what is shown in DNS for the host, if the host is using a static IP address and not a DHCP-assigned address.

uname

While you should have all three set appropriately, the HostName value is the source of the uname -n command.

Windows Server DHCP Search Domains

A write-up on implementing search domains in Windows Server 2008 RC2 DHCP, via Kevin Creason on the Mac Enterprise list.

Router

So, in this scenario, the setup would be:

university network
|
|
Router
|
|
Controller (head node)
|
|______________>node1
|______________>node2
|______________>node3
|______________>node4, etc..

Would the router itself assign only one IP address, that of the controller, then the controller would only worry about assigning addresses to the nodes? That makes sense to me that the router would be highly configurable and not as much as a hassle as the OSX server interface. I suppose the Internet connection of the Controller could be bridged to all the nodes as well? That would help with software updates but isn't necessarily required.

Thanks for your comments--we'll look into the router solution.

Simplify

I'm assuming a coordinated IP address space; that the local address space is coordinated with the campus address space. Networks operate far more effectively with that coordination than without. As mentioned, I'd avoid NAT where that's feasible, too.

In general, an IP router selects and forwards traffic among the IP subnets available and (where a route to a subnet doesn't have a dynamic or static route known) to the gateway router.

A host with more than one network connection is a router, as that host has to sort out which path to use. That's where subnets and gateway routes appear, and Mac OS X and Mac OS X Server don't have good UIs for that. Mac is fond of using whichever NIC is listed first, unless the administrator starts rooting around. Purpose-dedicated routers do have a UI for this and they have the somewhat more subtle advantage of not having folks directly on the box; network traffic is pass-through, rather than locally originating. In general, a box with multiple NICs would usually have different subnets on each NIC, with a unique IP address within that subnet.

With your network, typically a router at the edge, transitioning from the campus network and the subnet within. Behind that router, network switches, WiFi, cabling, or whatever provides the connections. The hosts in this design would all have one active NIC.

And yes, it is possible to have multiple NICs, either in separate subnets or through link aggregation. But I'd not start there; that'll require dealing with subnet routing. And it is possible for Mac OS X boxes to perform subnet routing, but I wouldn't choose that path. (You bought them to be Macs, not to be expensive and slow and awkward IP routers.)

You're persisting with that host-routing dual-NIC controller host configuration. What am I missing?

And technically, routers don't assign IP addresses. DHCP servers do. The DHCP server can be co-resident within some routers, or can be a Mac OS X Server box, or can be some other box.

DNS configuration in Lion Server

Hello Hoffman Labs,

I should note this is concerning a Snow Leopard Server cluster that has been "upgraded" to Lion, then server settings have been completely re-done...starting over from scratch, so to speak...

Our situation:
-our server is within a large university network.
-they have provided us with a static IP on the network
-we want to have the head node (cluster controller) open to the university's network and to the Internet (for ssh)
-compute nodes are in a small (<20 node) network connected to the head node through a switch
-Public (external) Internet comes in to en0 (Ethernet 1); private cluster network on en1 (Ethernet 2)

What the OS X instruction manual (http://manuals.info.apple.com/en_US/XgridAdmin_v10.6.pdf, CH10) tells you to do:
setup the network interfaces
-en0 should be first in the list (making it the primary interface)
--should be configured to use the static IP given by our University
--should have said subnet mask
--should list the University router
--should not have a DNS server listed (yet)
--add the local Search Domain, "cluster" in our case
-en2 should be second in the list
--should be configured with the local IP address of the controller (192.168.2.254)
--should have a subnet mask (255.255.255.0)
--router should be the private IP of the controller (192.168.2.254)
--DNS Servers blank
--Search Domains blank
-Set the Primary DNS name (Public name) to "controller.cluster"
-Set Computer name to "controller"
-Setup DNS Service
--Add primary zone, change name to private domain ("cluster.")
---add nameservers (private DNS host name as zone name, "cluster."; and primary DNS name as Nameserver Hostname "controller.cluster.", then Save.
---Select the "cluster." zone and add Machine Records for each of your nodes (reverse zones are automatically added for you). Then save
--Settings > Forward IP Addresses, enter the network address of the public (University) DNS server, save.
-Start DNS
-System Preferences > Network > en0 (Ethernet 1)
--in DNS servers, enter public (University) IP address of the controller (head node)
--in Search Domains enter private DNS domain ("cluster")

I get this far and run the verify routine that is suggested by the instruction manual. I have these problems:
1. No Internet access…and I can imagine why: my university DNS servers have not been added to the primary interface, only the controller's public IP address. How am I supposed to achieve Internet access if I cannot resolve names using their DNS servers? So right now to get Internet connectivity I have one of the University's DNS servers plugged into the Ethernet 1 DNS servers list.
2. In adding the primary zone, OS X Server 10.7 does not let me add the fully qualified name of the zone ("cluster."). I will add the period at the end and when I hit "save" it disappears. In 10.6.8 there was a checkbox that lit up when you entered the period at the end. 10.7 doesn't have that and it doesn't indicate whether the name is fully qualified (maybe that's all it allows so it doesn't need to indicate?).
3. I want to get to the point where I can successfully ssh to "clustercontroller.university.edu". How can I do that if the Primary host name of my controller is the private name (controller.cluster)?

I have not yet turned on DHCP, but NAT is on. None of the nodes are running at this time.

Do these instructions make sense to you? Effectively this is making the controller a router and I have seen warnings against doing that for exposure reasons. But besides that, should this process work?

Thank you in advance for your help and please ask me to clarify where necessary.

Get Yourself an IP Router

Rather than a suspicion of a DNS configuration issue, I'd expect an IP routing problem is lurking.

Here are some details on IP routing and firewall-gateways.

Avoid Network Address Translation (NAT) where you can. That's a hack. And it causes various issues. Here, consider implementing a subnet of the outer campus network, whether that's a subnet within the university's public IP address allocation. If your university has a public IP address block, but lacks sufficient available IP addresses to allocate to your use, then work with the university to determine what private IP address block(s) are in use, and coordinate your allocation and use.

Do not implement double-NAT. Just. Don't. Do. That. A double-NAT configuration might involve your local NAT at the edge of your network, as well as a NAT implementation at the edge of the campus network; if the campus doesn't have a sufficient number of public addresses, and has NAT at the edge of the university network.

Also avoid running a Mac as an IP router. For a case such as this, and if you need to segment your network from an outer network such as the university network, then acquire an IP router, or a gateway-firewall-router. Fewer hassles, and far better network management capabilities and (if you're willing to acquire from the used market) a cheap solution. Mac boxes are expensive, slow, awkward and (if you're not very careful with your software installation, configuration and management; that you don't mess up and open up a port or protocol unintentionally) insecure.

If you want or need DNS services for your own local network operations,work with the university and get your DNS server(s) delegated for a subnet, and get a subdomain of the university domain. And then set up your DNS server with a single network interface.

Consider avoiding the 192.168.0.0/24 and 192.168.1.0/24 blocks, as those blocks will causes (different) IP routing issues when VPNs are planned. (And plan on using VPNs.) You can't have the same subnet on both ends of the connection, and cafés and home networks widely use this block.

You'll be happier.

Postscript

PS: get a real and registered domain name, or coordinate with and use a subdomain of a real and registered domain. Here, probably preferably a subdomain of the university.

In general, bogus domains are problematic given the opening of new TLDs, and you'll want to select a three-part (or more) name for your systems. (Not the two-part names listed above.)

Lion Search (Default) Domain Name Change

Apple has changed the behavior of domain name defaulting with Mac OS X 10.7 Lion, per HT4845; the domain default string will not be appended to any host name specifications with one or more dots in the domain name.

OARC DNS Test Server

Information on OARC's DNS Reply Size Test Server , around errors with the Extension Mechanisms for DNS (EDNS) processing or IP packet fragmentation; this can produce various diagnostics in DNS server log files and can also trigger slow DNS resolution, and issues with DNSSEC.

On a somewhat related note, documentation on DNSSEC deployments is also available at OARC, and other DNS-related details.

Multiple NICs and DNS

There's no current and no reliable scheme and no RFC available for sorting out DNS services with multiple-NIC boxes.

Here's the IETF MIF charter, as they're making a run at this particular requirement.

And here's a draft multiple interface (MIF) DNS RFC for this processing.

Related to this determination on Mac OS X, see the GetPrimaryMACAddress example.

Unicast DNS resolver ordering

See How is DNS used by individual processes? for available customizations around the unicast DNS resolver order processing; around how to use PlistBuddy to add the StrictUnicastOrdering key to the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist configuration file. (This information was in HT4030, but that text there has disappeared.)

/usr/libexec/plistbuddy -c

Largely for local reference, here is the general syntax of the plistbuddy tool:

/usr/libexec/plistbuddy -c "Set This\ That\ Whatever true" ~/Library/Preferences/PathToPlIst/com.example.whatever.plist

In addition to the Set verb shown in the syntax above, there's Print.

Examples of invoking the PlistBuddy tool for reviewing the contents of the Dock and for customizing syslogd

Wildcard Domains

First I would like to thank you for your very good article. Its the only one I could find about this topic on OS X Server 10.6.

I have tried to setup a wildcard domain as you described in the last part of your article, but I could not realize it, because I was not able to follow the instructions. Server Admin does not allow to add entries containing an * as name (Message is:"Each label of the name must consist of only letters, digits, and hyphens. Each label must also be 1 to 63 characters in length, and begin and end with either a letter or a digit."). How can this be done?

Thank you
Bernd

Parser Change? Bug?

Something appears to have changed here; the posted sequence was working. It is definitely not working with Version 10.6.2 (328.2.2).

Odd.

I'll probably end up editing the underlying DNS configuration files directly, pending a fix from Apple.

Time to log a bug report, but this is also presuming Apple considers this to be a bug. If not, then to log an enhancement request. In either case, RFC 4592 and RFC 1034 seem applicable.

Troubleshooting DNS ACL Errors

If your DNS server drops off with something similar to the following crash-restart loop...

Feb 24 17:32:51 dnssrvr named[1638]: starting BIND x.y.z-APPLE-P2 -f
Feb 24 17:32:51 dnssrvr named[1638]: built with '--prefix=/usr' … … [compiiler switches here] … …
Feb 24 17:32:51 dnssrvr named[1638]: /etc/dns/publicView.conf.apple:1: undefined ACL 'example.net'
Feb 24 17:32:51 dnssrvr named[1638]: loading configuration: failure
Feb 24 17:32:51 dnssrvr named[1638]: exiting (due to fatal error)
Feb 24 17:32:51 dnssrvr com.apple.launchd[1] (org.isc.named[1638]): Exited with exit code: 1
Feb 24 17:32:51 dnssrvr com.apple.launchd[1] (org.isc.named): Throttling respawn: Will start in 10 seconds
Feb 24 17:33:01 dnssrvr named[1640]: starting BIND x.y.z-APPLE-P2 -f
Feb 24 17:33:01 dnssrvr named[1640]: built with '--prefix=/usr' … … [compiiler switches here] … …
Feb 24 17:33:01 dnssrvr named[1640]: /etc/dns/publicView.conf.apple:1: undefined ACL 'example.net'
Feb 24 17:33:01 dnssrvr named[1640]: loading configuration: failure
Feb 24 17:33:01 dnssrvr named[1640]: exiting (due to fatal error)
Feb 24 17:33:01 dnssrvr com.apple.launchd[1] (org.isc.named[1640]): Exited with exit code: 1
Feb 24 17:33:01 dnssrvr com.apple.launchd[1] (org.isc.named): Throttling respawn: Will start in 10 seconds

Have a look at the Accept Recursive Queries setting in the DNS Server's Settings page within Server Admin, and see if you have (for instance) example.com in that field and not the required IP address. If you do, swap the value over to an IP subnet block specification.

changing the zone domain name after all working?

I saw your comments on apple forums and the link to above. It was informative but I still have a question about our current setup (which is working great). Here are our issues....

Over 3 months ago we started setting up our server network. After discussions with administration it was determined (at the time) that we would use and register a domain name with a .net extension. So we set up a primary server with this extension and had it registered with our ISP. We subsequently added 7 other servers to the mix and as they were installed they grabbed their names from the DNS zone we had setup *.net in our DNS zone in our primary nameserver system. It was all well the tests worked we had it all going and are moving our 130 machines (including about 60 users) over next few months (and have moved about 10 users and other machines so far.

My question is this. Back in beginning a *.org was the other option but we had problems with it and our ISP (could have been some error on our part) so we went with *.net for our domain and got that registered. Now all of a sudden as our management is wanting to move the organizational website (we are not doing that) to another service that service is tying to convince them we should have not used *.net but *.org.

The person in charge of us is strongly asking if we can go back and setup with *.org but as I understand it I cannot go in and delete my *.net DNS zone and then rename all the servers with a .org extension but as we understand it from lynda.com and other sources it appears that we probably would have to go back and reset all the machines back up by reinstalling them after I changed the first primary nameserver. And then register the new name and wait for it to propagate?

Are we wrong? Can we just go in and turn off the DNS in server admin and then change the zone name(s) to *.org and the host names of each server from *.net to *.org and restart DNS and find all to be well? As much as we can tell it appears that we would have to restart from scratch as all the documents and lynda.com imply we should have had our final domain name set and registered before we started to install and setup the primary and secondary servers?

I see some examples where it is said to make such changes something needs to be done with ipconfig and not the GUI in server admin. But again I am not sure that this will work with our primary nameserver and the 7 servers under it?

Any feedback or help about this would be appreciated. It is our preference to stay with *.net and not have to do major work as we are starting user and network migration to the new servers and hate to have have such a major setback just because one person and the web design service they want to use does not like *.net. to us it appears the horse is long out of the barn and when this was approved last fall we have gone to far to easily go back. But if it is easier to go back than we think then we are willing to try to change.

Thanks

russ

You'll likely be cleaning up references for a while

Once registrations for commercial entities opened up in .org, its particular meaning (to me, and to some other long-timers) changed.

There's one school of thought which believes that the .com, .net, .asia, .org, .biz, .museum, .aero, .travel, .mobi, .tel, .info, .pro, .cat, .us or the many other top-level domain (TLD) names chosen particularly matters.

There's another and somewhat more cynical view, which assumes that the older name-based naming stuff is of decreasing relevance, and a new path for some existing and new registrars to make some money, that ICANN will be bringing more and more new domains online as what amounts to a land rush, and that most folks will (still) land at the site via Google or other such anyway.

Some businesses and some cultures bypass the domains and now recommend finding their web sites and their data using Google keywords, for instance. And this isn't even considering the international (punycode) domain names.

But I digress.

As for swapping the local host name without a Mac OS X Server reinstallation, it can be feasible to use changeip to swap the host names, but this can sometimes get ugly. (On OpenVMS, changing the host name can get really ugly.) Servers don't tend to get renamed all that easily. Depending on what is running on the box, this change can be simple. Or not.

You'll (also) have to find and rebuild your references within and among your servers, and within the various server references embedded in your clients, for instance. There's more here than just the DNS. Web sites and chat links and all sorts of other stuff includes the domain, as can stuff like plist filenames and internal software naming constructs. Electronic kudzu; this stuff gets embedded everywhere, and it can be a project to remove it.

I've been involved with wholesale DNS renames, and have implemented wholesale DNS renames. In a decent-sized network, it can take weeks or months to find and adjust all the old references; most stuff can get migrated in a fairly short period, though the occasional stale link can crop up years later.

Personally, I'd tend to look at using .org on the public-facing stuff (which will probably make Those Who Must Be Considered happy) and it'll avoid having to rebuild your whole internal network and linkages. If that doesn't fly, I might look to run both in parallel, and try an incremental migration; whether that works depends on your local requirements and operations. Map the .org and .net in parallel. (Though valid rDNS will be necessary for security-related operations and services.)

I tend to prefer to use the zone name to get to the FQDN; the A names (machine records) in the zones are typically not specified as FQDN entries, but are allowed to default to FQDNs. Combine this with the default domain name string assigned by DHCP, and most clients I manage configure these details automatically. It's the servers and the embedded references that get ugly here; DNS itself is a small part of the effort.

If you do decide to rebuild your DNS, also look to re-architect your network and your network services, as well. If you're going to break stuff, remember to break some of the (other) stuff that would otherwise prevent you from moving forward with your network. When you're unintentionally presented with the opportunity to fix your network mistakes during one of these corporate re-orgs or organizational or political shifts, always avail yourself fully of opportunities.

Our setup is a new network

Thanks for your suggestions. Our *.net network is a new one that we setup last October. It is to replace an inerim network with two apple servers that replaced an old exchange network that died and ugly death. The interim network is using and old DNS that we have to abandon (the exchange servers and such from a previous setup by other folks (many of us are volunteers hear like me ) because it had been infected with spambots and such. But I digress, anyway the new network is really at its start. Here is what we have so far:

Old network:

1) One apple server with second as backup running services (mail, DNS and such) (brought in to replace the dead exchange server)
2) One file server (microsoft) slowly being replaced by multiple file servers (temp ones on old network, 4 on new one below)
3) 120 Macs and PC's (about 60% mac now) on the network, some are community (shared) machines, about 60 are for our staff, rest are specialized production, presentation and such.
4) Various other printers, switches and such

New network (in progress for migration:
1) One main apple nameserver with the DNS zone, serving incoming mail and Open Directory and other services (the new *.net zone) registered with OpenDNS.
2) A second outgoing SMTP apple server
3) A server for web services
4) Four xserves for dividing our old file services along department lines
5) A test server running some test software
6) Ten user machines now on the new network with new mail and sucn.

The new network was tested in October and November as we added servers to that first one with the ip's and names defined in our original DNS main server. We then started in last two months to begin the migration. Alot of the old PC's have a legacy that will make the migration slow but our 60% macs will move easy although we plan to bump all the intel ones to SL that have not been bumped and do some cleaning.

So this is early in the migration but it was a several month (not 100% of time we had other work) process to get it setup, tested and ready for use. We have been promising the migration soon, started to work with departments and all of a sudden the issue about .org resurfaced because of the web service recommendation (sort of the old school idea you mentioned). We talked about the outside face idea a bit you mention but our administrator would like the internal to change also since many of our staff are volunteers (and like my wife for example not really high end or even moderate users in experience and knowledge). So giving them a choice of the internal addresses (and mail) plus the outside .org face might be a bit confusing to them -- and I agree with her on that.

So the bottom line is short of reinstalling this bank of 7 servers with a .org zone and then working around whatever problems we had getting .org to propagate and register with GoDaddy our .org DN we had purchased with a few others can we just go into the server admin and change it all or will there be too much imbedded in the main server and the 7 under it to not have problems (we have found the DNS from Leopard to SL to be a bit touchy to some changes early in testing) is there any simple fix? If not I think we can convince our supervisor (not an IT person but in charge of several departments) that this is a bit late and to learn to like the .net in-spite of what the web services company recommends? But we need to know for sure the solutions are not simple but require a reinstall or lots of tinkering that could break things and then lead to a reinstall of machines?

Thanks

Russ

Opportunity Costs

At its core, this is not a technical question. What is being requested here is entirely technically feasible.

This is centrally a question of what the MBA folks call “opportunity costs.”

Specifically for this case, of lost opportunity costs.

And of the realization that the current delivery schedule will slip equivalent to what's been completed in your current sequence.

Of what else could be done here with the time and the churn that is involved in this domain migration.

Whether those (lost) opportunity costs have been factored into the domain decision is not known (here), and that determination would involve direct discussions with the staffers and stakeholders involved. That background would be worth a local discussion or three; swapping domains is an easy suggestion to make, and a much tougher decision to make when the costs are considered. But a domain migration can be an entirely valid decision.

This domain migration is certainly going to disruptive, and arguably approaching a full restart of the server and network configuration process. Of the internal hosts and internal and external DNS. Of the internal and external hosts and DNS names and web references and such will need to be changed, and of internal and external search (re)indexing and such. All of this will basically require starting over again.

There are ways to (try to) soften this, such as the use of A names (machine records) and CNAME records to (try to) ease the migration.

But make no mistake, this migration will be disruptive.

As for my domain preference, I might well specifically choose to use .ORG outside, and .NET inside your network perimeter; for hosts that are known to external users and sites, and which are internal. Though yes, various sites do choose to conjoin these two disparate parts of a network into a single domain.

Were I consulting on this project or managing it, several private discussions with the stakeholders would in order. And a discussion of the opportunity costs. This is secondary to the networking itself; the migration from .NET to .ORG is feasible, and that's then the choice of and the decision that the managers are designated to make, and then that the C-level folks and/or the board get to review and to consider and (as appropriate) to support.

DNS caching statistics

This is mainly posted here as a reference for my own use...

$ dscacheutil -statistics
Overall Statistics:
    Average Call Time     - 0.000896
    Cache Hits            - 296221
    Cache Misses          - 541706
    Total External Calls  - 314347

Statistics by procedure:

             Procedure   Cache Hits   Cache Misses   External Calls
    ------------------   ----------   ------------   --------------
              getpwnam         2837            464             3301
              getpwuid        32690            625            33315
              getgrnam          439            460              899
              getgrgid            8             27               35
         getservbyname       260239            617              122
         getservbyport            0             84               84
              getfsent            0              0              276
          getnetbyname            0              1                1
          getnetbyaddr            6             31               37
         gethostbyname            2         262381               40
         gethostbyaddr            0          13894            13894
    gethostbyname_service            0              0           262343

$ 

 
If required, also see the DNS cache flush command for the DNS server and the DNS resolver (10.5 Leopard and Leopard Server and later), respectively:

$ rndc flush
$ dscacheutil -flushcache

Or (with 10.6 Snow Leopard and Snow Leopard Server) you can reset the DNS responder with the following:

sudo killall -HUP mDNSResponder

Or (with 10.4 Tiger and Tiger Server) with the following:

lookupd -flushcache

Other controls available within daemon.c include:

  • sudo killall -HUP mDNSResponder (as above) clears the DNS responder cache.
  • sudo killall -INFO mDNSResponder causes a dump of the DNS responder cache into the /var/log/system.log log.
  • sudo killall -USR1 mDNSResponder enables logging of DNS responder activities. Use sudo syslog -c mDNSResponder -d to enable additional debugging (emergency-debug here) into the /var/log/system.log
  • sudo killall -USR2 mDNSResponder enables logging of DNS packets packets into /var/log/system.log.

The DNS responder logs into the /var/log/system.log file.

Yosemite 10.10 DNS cache flush commands

The commands to flush the unicast and multicast DNS caches, with the Yosemite 10.10 series discoveryd daemon that's replaced the mDNSResponder used in earlier releases:

sudo discoveryutil udnsflushcaches
sudo discoveryutil mdnsflushcaches

Given how often these things change, you'd think Apple would create a generic command.

But I'd guess Apple thinks that this discoveryd approach will solve the problems. Until it doesn't.

dscacheutil equivalents of dig and dig -x

Here are the dig and dig -x command equivalents within the Mac OS X dscacheutil tool:

$ dscacheutil -q host -a name host.example.com
name: host.example.com
ip_address: 172.16.1.2

$ dscacheutil -q host -a ip_address 172.16.1.2
name: host.example.com
alias: 2.1.16.172.in-addr.arpa 
ip_address: 172.16.1.2

$ 

Unlike the dig tool (which queries a DNS server, and returns a response), the dscacheutil tool also accounts for the internal Mac DNS implementation and caching.

Mac Mini Snow Leopard server behind DIR 655

Hi Hoffman
thanks for your post. I'm using a DLINK router DIR 655. I can't figure how to change the DNS reference inside DIR 655. When a client computer is configured to "obtain DNS automatically" it just always gets the IP of the router, in my case 192.168.1.1.

It seems like I will have to manually reference the local DNS server for each hosts. Sure doesn't make a lot of sense to me.

Hope you could enlighten me on this bit.

David