Best Practices: DNS
Everything you should need to know about using DNS effectivelyEd. Note: This is hopefully the first of many "meta-articles" that help to bring together the collection of articles that we already have and help to bring understanding to a topic. Ideally we'll keep these up to date when we have other articles on the subject. If not feel free to smack us around in e-mail until we do.
If people find these helpfull, we'll probably package them all up into a big pdf of fun and put it in the downloads section.
1. Introduction
DNS is important on OS X Server. Really, really, really important.
Without proper DNS setup you will not be able to get the Kerberos KDC set up in addition to a number of other services that could potentially behave very erratically. Plus no one on the mailing lists or at AppleCare is going to help you too much until DNS is happy. There's just too many unknowns until you get DNS running correctly.
With OS X 10.3 you have a fully functional BIND 9 name server. This is a good thing since BIND runs about 60% of the world's DNS servers. Having BIND 9 on OS X Server means that for the most part generic BIND 9 how-tos and other documentation will work great on OS X Server..
So, give how important DNS is, ideally you should have DNS fully functional before installing OS X Server. However, what if you server, which happens to be your only server, is going to be your DNS server? A bit of a chicken and the egg scenario.
First off you should always, always, always install OS X Server as a Stand Alone system. Do this, log in and configure DNS, then promote your system from a Stand Alone to an Open Directory Master or whatever role you would like it to play. There you go, problem solved.
2. So, you realize that you need DNS, but what exactly is it?
DNS translates fully qualified domain names, www.afp548.com for example, into IP addresses, 64.5.69.56 for example, so you don't have to clutter up your brain with all of the numbers. DNS can also do the reverse and translate numbers into names.
Now, as you can easily imagine, it would be nearly impossible to keep track of all DNS domains in one central server. Thousands of DNS entries are being updated every few minutes all across the world. Having one server to keep track of that would be technologically infeasible. Plus, think of the bandwidth that you'd have to have to answer all of those requests!
Instead DNS is divided up into a world-wide hierarchy that ensures that any DNS server has to know as few records as possible to still do its job.
When a client machine makes a request to a DNS server it's very likely that that server has no knowledge of the domain that the client is attempting to get to. The only thing that server has to know is the list of the 13 root servers. These machines are scattered across the globe and maintained by a variety of governmental, military, commercial and educational organizations.
So the client asks the DNS server what "www.afp548.com" resolves to. The DNS server, having no idea about the afp548.com domain, since it isn't being hosted locally, forwards on the request to one of the root servers.
The root server also has no idea about afp548.com. The only thing that the root server knows is who's authoritative for the top level domains, or TLDs. A TLD is the right-most part of the domain. In our example it would be .com. Other common TLDs are .org, .net, .us, .edu and so on.
The root server then replies back to our client's DNS server with the IP address of an authoritative server for the .com TLD. Now the DNS server has to make another query, this time to the .com TLD server and again ask for what IP address www.afp548.com resolves to.
The .com server, like the others before it, has no idea what andy the afp548.com domain names revolve too. The only listings that the .com server has is what DNS servers are authoritative for specific domains. In this example, the .com server has a listing for afp548.com that references a domaindirect.com domain name server. We here at AFP548.com pay domaindirect.com to host our DNS records, so they have an authoritative listing of them.
The .com server then responds to our client's DNS server with the IP address of an domaindirect.com DNS server. Now, our DNS server has to make yet another inquiry for www.afp548.com. However, this time we actually hit pay dirt. domaindirect.com actually has every afp548.com DNS record so it can easily resolve the DNS name into an IP address and send that address back to the original DNS server.
At which point the DNS server can finally answer the client's query with the correct IP address.
A lot of work is involved in a DNS lookup. To make things go as fast as possible a few things have been streamlined.
First of all, all DNS traffic is sent over UDP instead of TCP. Since most DNS lookups and their corresponding responses are just one packet each, using UDP saves 6 packets per each communication bringing the total down to 2 packets for each stage of the lookup.
Secondly, all of the responses are cached. Each record has a time-to-live value associated with it that governs how long a DNS server should cache that response. Once the DNS server has done a query for www.afp548.com, it won't have to go through the whole process again for that particular address for at least a few hours. It also won't have to go back to the root servers to lookup any .com addresses because it will also cache the .com TLD server's address.
3. The DNS Records Themselves
Now that you know a bit more about the DNS system globally, let's talk a bit about the actual DNS records that you can have.
Note: the examples that follow show the basic DNS syntax right out of the BIND configuration files.
For our purposes there are 5 types of DNS records. We'll go over them here and give you an example of the syntax of each one. Then show you how to add these into your system.
An A record maps a name to an ip address.
www.afp548.com. IN A 64.5.69.56
A CNAME, or canonical name, record aliases one fully qualified name to another.
mail.afp548.com. IN CNAME www.afp548.com.
An MX, or mail exchange, record tells you where the mail for a certain domain should go. This allows you to send e-mail to a person at a domain without knowing the actual name of the mail server. Also associated with these records is a weight, the 10 in the following example, that specifies the order to try the servers. The server with the lowest number is the first to be tried. If that server is unavailable then the sending server will try the server with the next lowest number.
If you care about your e-mail, you should always find someone to be a back up MX host for your domain. Usually your ISP will be happy to do this for you if you have anything better than a residential line. Otherwise another friend's server works well here.
afp548.com. IN MX 10 www.afp548.com.
An NS record says what servers are in charge, or authoritative, for a domain's DNS records. In the following example you can see that our records are being hosted at a dns server being run by ultradns.com. No other server can definitively answer what IP address a server in the afp548.com domain has.
afp548.com. IN NS ns1.domaindirect.com.
Finally there is a fifth record that is only used for mapping an IP number to a name. When you do this you are requesting a reverse lookup. The record that handles this is a PTR record.
56.69.5.64.in-addr.arpa. IN PTR www.afp548.com.
Now a couple of things about the last example should stand out. First of all the IP address is "reversed." Don't think too hard about this, just know that a PTR is involved in a reverse lookup and that it needs to have the number reversed. Secondly it ends with in-addr.arpa. You shouldn't think about this one too much either. Just remember that you need to add that to your reverse records.
For addresses on the public Internet, only the owner of the address is able to provide a PTR record. So unless you have actually purchased a netblock of your own, and you'd know this if you have, you'll need to get your ISP to host your PTR records.
If you are using the Server Admin application to set up DNS on OS X Server 10.3 most of the nitty gritty of these records are handled for you. More on this laster.
4. What domain to use?
This is a rather important question. It used to be that when setting up DNS for the first time on a network you were advised to create a "fake" internal use only domain like mynetwork.lan or company.internal.
Don't do this. I used to advocate this behavior in the past, but it just is too confusing anymore. Instead I find it more more simple to register and use a real DNS domain name, even if you have no intention of actually using the domain on the public Internet.
I say this for two reasons. First of all registering a domain name will cost you all of $15 or less per year. Think one Rainbow Roll at a good sushi joint. Secondly, you never know when you want to make your mark on the world. As such it's better to lock that domain in now before someone else gets it.
But Joel, you may say, won't this cause confusion with my internal and external IPs and DNS names?
No, not if you take a modicum of caution and do it right.
Where to register
If you haven't already got your domain there are a huge number of places to register. I usually use domaindirect.com, but I've heard good things about godaddy.com and others. Look for a relatively well-known registrar (you don't want to end up with someone running their business out of their basement and just reselling other registrars).
Some people will tell you go to with verisign.com, the grandady of DNS names. They'll provide reasons like: VeriSign was doing it first so they must do it the best, or all the "big companies" use VeriSign so you should too if you want to be taken seriously.
Do what you want, but be prepared to pay 2-3 times more to register with VeriSign. Then get used to a lot more hassle when managing your domain. I originally had registered afp548.com with VeriSign but later moved it to Domain Direct for precisely those reasons.
So you've got a domain, now what?
Registering the domain is the first part, now you need a place to actually host your DNS records. If you used Go Daddy or Domain Direct, most any other registrar, you should get free DNS hosting with your registration. Last I checked VeriSign didn't do this.
For all but the busiest of web and mail servers, getting the registrar to host the DNS will be fine. If you plan on getting millions of hits per day you'll probably want to look into a dedicated DNS hosting service like Ultra DNS.
Another option for DNS hosting is your ISP. If you have a business line they should be agreeable to doing this for you. Personally, I like doing it with the registrar since I have ocassionly changed ISPs in the past. Also if you are dealing with a smaller ISP, their DNS servers will probably go down when your Internet connection goes down. With DNS dead in the water you'll not be able to spool mail to your backup MX host.
Now for the part where you have to think it through a bit. You're going to host your public DNS records on the DNS host that you've chosen, most likely through your registrar. They should give you a real nice web interface where you can edit the records.
For most organizations you'll probably only have a dozen or so records that you'll need to enter. Be careful not to forget the MX record for your mail servers!
Bring it home.
If you are not using Network Address Translation (NAT) on your LAN, then you're done. Set up an A record for all of you IP addresses and away you go.
If you are using NAT then you'll probably want to host DNS locally on your network on your OS X Server. After all that is probably why you're reading this, right?
This is where you might have to take a little bit of a leap from what you are used to doing with DNS. My prefered method of handling the dichotomy of internal addresses and public address is to let your external DNS servers handle your public stuff and your internal DNS server handle your internal stuff.
For example, I'd enable the DNS server on my corporate OS X Server and use the GUI to have it be authoritative for the afp548.com domain. I'd assign the internal IPs to all of my internal systems so server.afp548.com might resolve to 10.34.58.20, for example. If I'm hosting mail on the LAN I'd set up mail.afp548.com to resolve to the internal IP address and I'd set up an MX record to point to it.
Now, on my external DNS I'd setup mail.afp548.com to resolve to the public IP of my mail server, 64.5.69.56 for example.
At first this may not sit right with you. Two entries for the same server that point to different IP addresses. It's ok, really.
The reason why this works is that external clients, our friends at 4am-media.com for example, will use the public DNS system and resolve mail.afp548.com using the domaindirect.com DNS servers. This means that their mail to us will go to the public IP of the mail server.
However, users on the AFP548 corporate LAN will be using our local OS X Server for DNS. As such when they resolve mail.afp548.com they'll get 10.34.58.20 as an answer. This means they'll never have to leave the network to get their mail.
This method works especially well with laptops. On the laptop you can set up the user's mail account to point to mail.afp548.com. When that user in on the local network they'll use the internal DNS and go direct to the internal IP address of the mail server. When they leave the LAN they'll use the public DNS system for DNS resolution which means they'll get the public IP address of the mail server and connect as normal.
Beautiful right? See how simple this all works out?
The only thing to keep in mind is that you have to be a bit more careful with resources that you don't host internally. For example, stjohn.afp548.com points to the network at the AFP548 vacation bungalow in St. John. This is a public IP address, so it's listed in the public DNS records at the registrar. However it also needs to be entered into the OS X Server on the LAN so that users on the LAN can easily see the beach web cam instead of doing work.
But what if you want to host your own DNS?
Don't.
That was simple, wasn't it?
With very few exceptions you have no real reason to host your own DNS. External hosting services are dirt cheap, easy to administer through web-based control panels, and will generally be more reliable and robust then your own servers.
The primary reason for this is that your DNS host will probably have multiple DNS servers on multiple networks that are usually physically separate from each other. Unless you can match this basic level of redundancy you have no reason to do this yourself.
A common reason for wanting to host your own DNS is to get changes made quicker. This isn't a really compelling reason anymore. Most DNS services update within hours if not minutes, so it's not really faster than what you can do. Plus, it really isn't the DNS host that you need to worry about, but all the other DNS servers that have cached your records on their last lookup of you domain. No matter who's hosting your DNS you won't be able to speed this up.
Finally, hosting your own DNS will complicate the internal/external scheme that I laid out for you earlier. To do this effectively you'll need to either run multiple DNS servers inside your network or use BIND's views feature which will cover later.
5. Configuring OS X Server
Check out Corey's Panther Quickstart Guide as it covers basic DNS setup with Server Admin.
Also take a look at the pdf documentation on Apple's web site for OS X Server.
Do keep in mind that you are more than welcome to edit the zone files by hand. That is if you feel confident in what you are doing and have made backups before hand.
The zone files on OS X Server are kept in /var/named and the BIND configuration file is /etc/named.conf. Apple uses the same config files here as every other BIND installation and you are free to edit this both by hand and in Server Admin without needing to worry about Apple rolling back your changes.
6. Configuring DNS on OS X client
This is a pretty straight forward exercise, for some advanced tips you can check out our article on Using alternative .local domains and other DNS tricks.
7. Advanced BIND configuration
BIND is a very, very capable DNS server. It's been around for about as long as DNS has and can do pretty much everything that you'd ever want to do with DNS.
We'll cover a few of the sexier things that you can do with BIND and DNS servers in general here, so you at least now what the other geeks are talking about at your next Unix dinner party. For more information on these topics check our the resources section at the end of this article.
Caching only Nameserver
This is what happens when you have a server that has no local domains, or zones, configured. A caching only server will use the public DNS system to get answers for clients, but will always have to look to the root DNS servers since it has no records of it's own.
This is the default state of the DNS server on OS X Server if you just turn it on without any configuration. Handy to have since it will speed up DNS resolution for you LAN. However since DNS queries are literally one UDP packet in each direction you're really not brining down your pipe by using your ISP's DNS server for your clients.
Forwarding only nameserver
A forwarding only nameserver is similar to a caching nameserver except that it doesn't use the root servers. Instead you specify a DNS server or two, usually your ISP's, to use for queries. So all client queries will be forwarded on to these other DNS servers which will then use the normal public DNS system to look up the answers.
This is usually used when you trust someone else's admin skills, or their server hardware, more than your own. Again since DNS is so little overhead, especially in smaller environments you're really not saving yourself much traffic by doing this. I usually forgo this configuration for a caching name server, however if you'd like to set this up you can easily do this by editing /etc/named.conf.
DNS views
This term refers to a neat function of BIND 9 to provide different answers to different clients based on the client's IP address. For example if you wanted to actually host your own public DNS records and host information for your internal clients, you'd use views on your server.
You'd set up an external view that serves the public DNS records from a public zone file. You'd then create an internal view for your internal IP range that servers out your internal zone files. This way everything works as it should.
BIND can easily do this, google for more info or read the books listed in the resources section for more information on this. Do keep in mind that enabling views confuses the bejeezus out of Server Admin to the point where you will not be able to use it anymore to manage your DNS zone files.
Zone transfers
Zone transfers allow you to have a primary/secondary nameserver setup. For example you could host your public records on your own server. However, being the smart admin that you are you ask your buddy across town to be a backup nameserver for your domain.
This is easy enough to do, just copy over the zone file and make a few changes. However, it quickly becomes irritating to have to do this every time that you make a change. To get around this you can set up zone transfers which allow the secondary server to query the primary for any changes to the zone and then update itself.
It's not hard to set this up, but it does take a little bit of work. Look in the Resources section for more info.
8. Security
BIND has had it's issues in the past. Earlier versions were somewhat notorious for security leaks in them. However, these are pretty much in the past. BIND 9 has been very stable and secure.
This doesn't mean that you need to forget about security. Well, that is if you are hosting public DNS. Not to beat a dead horse here, but if you only use your internal server to host internal DNS you can then block port 53 at your firewall and no DNS queries will get inside your network.
This means you pretty much only have to worry about your LAN users messing with your DNS server and you can relax a bit.
If you are hosting public DNS you should be aware of the zone transfer and recursion options in Server Admin. Allowing zone transfers means that you'll happily allow anyone to download entire zone files in one fell swoop. Not a huge security risk in and of itself, but it will give attackers a very good picture of what's running on your network and where it is.
The other thing that you want to be concerned with is recursion. This means that your server will happily query the root server and walk the DNS tree to find the answer to any DNS query that it receives. In previous versions of BIND there were ways that attackers could exploit this to poison your DNS. Now it's mostly just a waste of your bandwidth and processing power to be doing the work for people you don't even now.
The GUI will allow you to turn recursion off, but if you are providing DNS to your internal clients you'll need to have it on. Read the BIND resources and you'll find out how to allow just a subnet to recursively query your DNS server.
9. DNS utilities
Being able to troubleshoot DNS is very important in a modern network. Without DNS the Internet is effectively broken for your users. That means phonecalls and headaches for you.
Here's a listing of utilities that you can use to test DNS resolution. However, by far the single easiest way to troubleshoot DNS is to always keep the IP address of an alternative DNS server in your head. If are ever in doubt, just put that server into the Network Preference pane and see if things get better. If they do you know what your problem is. If they don't it's most likely a physical networking issue that plagues you. Network Utility
This neat little GUI app in the Utilities folder of every OS X machine provides an easy way to nslookup and dig. Put in the records that you want to query and hit the button. What could be easier?
dig
Dig, or Domain Internetworking Groper, (aren't UNIX geeks great?) is an incredibly useful troubleshooting and informational tool. It will allow you to do DNS queries from the command line on any DNS server. For example to find out what IP a site has do:
dig www.afp548.com
To do this same command, but query a different DNS server (204.69.234.1) instead of what is set in your network preference pane:
dig @204.69.234.1 www.afp548.com
To find out what server takes mail for afp548.com do:
dig afp548.com mx
And lastly to reverse an IP address:
dig -x 66.92.146.93
Dig does more, but that should be enough to keep you busy.
nslookup
This is the "old" version of dig. It's officially deprecated in favor of dig. Use it if you want, but you're probably better off learning dig.
host
This is an often overlooked very lightweight CLI utility that just returns the information that you need. It's commonly used in scripts where having to parse the output of dig gets rather complicated.
Resources
Books
There is really only one book on DNS that you need to concern yourself with, DNS and BIND by O'Reilly.
If you must buy a second book, or are interested in some concrete examples of advanced DNS implementations, you should look at O'Reilly's other DNS book, DNS and BIND Cookbook.
Websites
Our old article on setting up DNS on 10.2. It does go into decent detail about the actual contents of the BIND zone files.
Changelog
12-28-04 Original article