DNS Doesn't Have to be WTF

This post is going to be tailored more towards Mac OS X system admins, but a good foundational understanding of DNS is something that is good for all system admins to have. Mac OS X admins especially need to have a good understanding of DNS as most problems they'll encounter will stem from improperly configured DNS. DNS is something that is often misconstrued as something enormously complex. Sure, DNS can get complicated, there's no denying that. But the basics are relatively easy. Understanding DNS to the point where you can make your OS X server(s) happy doesn't have to, and shouldn't leave you, saying "WTF?"

DNS at 30,000'

DNS stands for Domain Name System. I like to think of it as the phonebook for the internet. When you look in a phonebook, you generally look for someone's name to find their phone number. DNS forward lookups do essentially the same thing. DNS forward lookups translate names, such as rmu.edu, into IP addresses (rmu.edu has IP 66.206.178.109). When you type http://www.rmu.edu into your browser, it's DNS that's telling your browser what rmu.edu translates to. DNS reverse lookups translate IP addresses into hostnames (66.206.178.109 translates into ww2.rmu.edu). Mac OS X Server services such as Open Directory, Server Admin, Mail, iCal, iChat, and more rely heavily upon having both proper forward and reverse DNS. When OS X admins report DNS problems to their Windows colleagues or network admins, they generally get the response, "Well it's working for our Windows servers." In that situation, generally the problem is that reverse DNS is broken. Windows doesn't rely much at all on reverse DNS so problems in that area tend to hide themselves. On the contrary, again, Mac OS X Server heavily relies on having both proper forward and reverse DNS.

DNS is structured in that each domain has a set of authoritative name servers. Those name servers host the "zone files" for the domain that contain the record information. Those authoritative servers can then in turn assign other authoritative name servers for their subdomains. There can be secondary, or slave, name servers for each domain and subdomain as well. The distributed nature of DNS provides fault tolerance and scalability. Allowing each domain to have its own authoritative servers has also removed the need for there to be a central DNS registrar continuously updating with everyone's records. Imagine that nightmare.... It's not incredibly important to understand how the structure of DNS works starting all the way from the top (the root), but do know that there is a DNS root zone which is the top level DNS zone in the DNS hierarchy. The zone is managed by IANA which is managed by ICANN. From there, there are zone servers for the top level domains such as edu, org, com, etc.

DNS has two main types of queries -- Recursive Queries and Iterative Queries. Recursive queries are usually made by a client host/resolver (such as your machine). The queried name server (most often provided through DHCP by an ISP) is asked to respond with the requested data or with an error stating that data of the requested type or the domain name asked for doesn't exist. The name server cannot just refer the querier to a different name server. Forwarders sort of aleviate that problem by allowing DNS requests to "pass" from one DNS server onto another. If a DNS server is configured to use a forwarder, the request from the queried DNS server to the forwarder is also a recursive query. In an iterative query, the queried name server gives the best answer it currently has back to the querier. This type of query is typically done by a DNS server to other DNS servers after it has received a recursive query from a client host/resolver.

DNS queries are essentially read right to left starting with the right-most (top-level) domain label. A common misconception is that http://www.rmu.edu is a fully-qualified domain name, or FQDN. It's not. http://www.rmu.edu. is. Notice the trailing dot, indicating the root zone. Try typing any of your favorite websites into your browser with a trailing dot. Notice they'll still load. This trailing dot is implied. DNS caching is used these days to lighten, and almost completely alleviate, the load on the root servers. But essentially, a DNS query for http://www.rmu.edu. works like this: 

- A query is made to one of the root servers (.) to find the server authoritative for the top-level domain (TLD) (edu).
- A query then is made to the obtained TLD server (for edu) for the IP address of the DNS server(s) authoritative for the second-level domain (rmu).
- The previous step repeats for each domain name label in sequence until the final step. The final step returns the IP address of the website or host originally queried for.

DNS has something called records, the most common of which are A (address) records. There are tons of different kinds of records, but the most commonly used records by Mac OS X system admins are A records, PTR records, and CNAME records. 'A' records are what define your hosts/machines/devices. For example, if test.example.com had IP address 10.1.1.11 and was in DNS, there'd be an A record for a host called "test" with an IP address 10.1.1.11. PTR records are used for reverse DNS (which remember are crucial for OS X Server). In the 1.1.10.in-addr.arpa. zone, there'd be a PTR record that translated test back to 10.1.1.11. The actual PTR record for test would be 11.1.1.10.in-addr.arpa. (notice it's backwards). The in-addr.arpa. domain is a special domain used for reverse DNS. CNAME records are canonical names which are essentially aliases. For example, you could have a CNAME record for test2.example.com that pointed to test.example.com.

With that high level overview of DNS, now we can start exploring how it works in Mac OS X 10.6 Snow Leopard, and how to configure it properly in Snow Leopard Server. For more information about the information discussed above, see Wikipedia's entry on DNS and don't be afraid to traverse some of the links. It's fascinating stuff. The DNS and BIND book from O'Reilly is also excellent. For the serious nerds, check out the RFCs.

DNS Changes in Snow Leopard

Before talking about how to configure DNS in Snow Leopard Server, there's some important DNS architectural changes to mention that were made in Mac OS X Snow Leopard. Mac OS X Snow Leopard uses a process called mDNSResponder to do both unicast and multicast DNS queries. There's an excellent article on afp548.com about all of the changes made in Snow Leopard, but here's the most important:

- Your search order in system preferences doesn't actually matter. You're telling the system where to look, but it doesn't necessarily look in the order you specify.
Manually specifying a DNS server in system preferences will cause the system to ignore any DNS servers supplied via DHCP
-  
dig, host and nslookup all do direct DNS queries and have their own resolvers. dig, host, and nslookup output could possibly show different results from what you're seeing in applications and through behavior.
- Related to the previous, be sure to use dscacheutil in addition to the tools above when troubleshooting DNS. The syntax is: dscacheutil -q host -a name <name here> or dscacheutil -q host -a ip_address <ip here> to test reverse.
- sudo dscacheutil -flushcache isn't always enough to clear the DNS cache in Snow Leopard. Send a HUP to mDNSresponder: sudo killall -HUP mDNSResponder 

Configuring DNS in Mac OS X Server 10.6.x Snow Leopard

When you go through the setup assistant of Snow Leopard Server, one of the screens asks you for the hostname and name of the server you're configuring. If your institution already has DNS in place, just have your network admin(s) create an A record and a PTR record for your server. The PTR record is important!! Assuming they did that for you, after having put in the address information on the previous screen (manually configured, of course), it should automatically populate these fields and you should be set to go. Nothing more is required. You don't need to run DNS yourself if it's already running properly on your network. If they can't do that for you, ask them if you can become authoritative for a new subdomain in your organization. 

The following assumes that a, either your network team is unable to give you proper DNS, or b, you want to become authoritative over your own subdomain, such as mac.example.com so you have more control over the hosts under your level of management. At Robert Morris University, I made myself authoritative over the mactest.rmu.edu and mac.rmu.edu domains. Doing so has helped things immensely as we have a DNS spaghetti of both BIND and Active Directory provided DNS.

At the screen shown below, enter the hostname you'd like your machine to have such as testserver.mac.example.com. If you have no FQDN for your organization (say you're doing this at home, for example), you can always use something like testserver.private. Just please... please... do not use .local. Whether you're going the subdomain.example.com route or the .private route, all of the following steps are essentially the same.

Initial Setup Screen

On the following screen, I always choose Configure Manually. If you choose Create Users and Groups you will get a premade OD master that may or may not have proper DNS settings. This guide assumes you choose configure manually. Choosing "Create Users and Groups" is essentially the same thing as Configuring Manually, setting up DNS properly, and then turning on Open Directory to the Master role.

Configure Manually

If you configure manually and want to set up Open Directory, I suggest skipping the option that says "Setup an Open Directory Master." You can always do that later.

Go through the rest of the setup as normal. When finished, launch Server Admin and go to the DNS pane. It should be the only one there and it should be on. If for some reason it's not on or there, you can go to the Services pane of Server Admin and choose to show it from there. When you click on DNS, you'll see the following screen.

Warning -- Don't Touch Me

You'll see that Server Admin is warning you that touching the DNS settings could cause problems. Let's ignore that message. 

What Server Admin has done is made self resolving zones just for your particular host. It's also set the DNS server in System Preferences to 127.0.0.1. This essentially ensures that from the start, there can be no DNS problems. At this point in time, your server is authoritative for a zone named after itself and has a record for itself in the in-addr.arpa. domain for reverse. 

Initial Server Admin Zones

I'm going to change these zones to become authoritative for the entire mac.example.com domain. If you're using .private, you'll simply become authoritative over the entire private domain. As that's an internal use only domain, there's no problem there.

Be absolutely certain that you're not trying to take authority over a domain in your organization that already exists. You need to make sure from your networking team that you're a, allowed to run DNS on your network, and b, assuming you can, for what domain/subdomain can you be authoritative.

For my example, I'm going to become authoritative over the entire mac.example.com domain. To do this, I need to modify the zone files. First I'll remove the reverse zone by highlighting it and pressing the (-) button.

Reverse Zone Removed

I'll then remove the primary zone. 

IMPORTANT -- DO NOT PRESS SAVE AT THIS POINT

Primary Zone Removed

Now I need to remake my primary zone. This will be mac.example.com.. Note the trailing dot. If you're doing private, your zone would be named private..

Remaking the Primary Zone

Where it says "Nameservers:" click the plus button. It should automatically populate with the correct values.

The final step in configuring the new zones is to add the A record for your machine. Click on the zone and click "Add Record>>Add Machine (A)."

Adding the new A Record

Notice that Server Admin automatically created a Reverse Zone for my machine. Expanded, the new zones look like this.

New Zones, Expanded

If you click on the reverse record, you'll see how it maps back.

Reverse Record

At this stage, it's time to verify that everything looks correct. You should have a new Primary Zone named what you chose to be authoritative over. For my example it was mac.example.com.. For you, it might be private.. Within that Primary Zone you should have an A record matching your statically assigned IP address. You should have a Server Admin auto generated reverse zone and reverse record pointing to your machine.

Almost Done...

At this point, when you're sure everything looks correct, go ahead and press Save.

In System Preferences, make sure your current DNS server is set to either 127.0.0.1 or your static IP address, or both separated by a comma. If you want to be able to do DNS lookups against just hostnames and not FQDNs of your machines, also add your domain to your search path.

System Preferences

Note that I'm working in a VM with host-only networking. In production, I'd have the interface set to full Manual mode.

Now it's time to verify everything is correct!

The following commands should be used to test:
dscacheutil -q host -a name <host name>
dscacheutil -q host -a ip_address <ip address>
dig <host name>
dig -x <ip address>
nslookup <host name>
nslookup <ip address> 

And finally, last but not least, the most important and powerful Mac OS X Server command there is, sudo changeip -checkhostname. It should say "The names match. There is nothing to change." If it doesn't, something is misconfigured. Go back and check.

sudo changeip -checkhostname

If everything looks good, you're all set! (For some reason the OS X install didn't give my VM a hardware UUID. I can safely ignore the top part of that message.)

On Your Way...

At this point you should have a general understanding of how DNS works and you should have successfully configured the DNS service using Mac OS X Server 10.6 Snow Leopard.

The DNS service runs under the process 'named' and uses the following files/directories:
/etc/resolv.conf
/etc/named
/etc/dns
/var/named/
/var/named/zones

If you explore the /var/named/zones directory, you'll notice zone files that correspond to your zones in Server Admin ending with a .zone.apple suffix. If you look in /var/named you'll see zone files that correspond to your zones without the .zone.apple suffix. These zone files in /var/named are the real zone files. Examining one shows that it includes the ones generated by Server Admin. If you need to make manual changes to DNS that are more complex than what Server Admin can offer, put the changes in the /var/named zone files. These won't get overwritten and won't make Server Admin unhappy. Note however, that your changes will not be displayed in Server Admin.

At this point, your server most likely can't resolve anything in the outside world. You can either add your institution's other DNS servers to the Forwarder IP Addresses list on the Settings tab of the DNS pane in Server Admin, or if this is your only DNS server, use something like Google's DNS servers 8.8.8.8 and 8.8.4.4 as forwarders. They accept recursive queries and should work.

That's all, folks!

Thanks for reading! Hopefully this post was helpful. If there's any questions, please post them below and I'll do my best to answer them in a timely fashion.

3286 views and 2 responses

  • Feb 10 2012, 4:19 AM
    Joe Best responded:
    Nice article Mike thanks.
    One pedantic point. I think the word suffix is better than postfix.
    Cheers,
    Joe
  • Feb 15 2012, 9:15 PM
    Mike Boylan responded:
    Thanks Joe. I wrote that super late at night. I also prefer suffix. Not sure why my mind used "postfix". Probably because I was making changes to postfix configs earlier or something. Haha. Nonetheless, changed. Thanks!