height8

About


height8 on AppDotNet @height8 on Twitter height8 on Github height8.com on Skype

WANTED

DEC LA36 DECwriter II Terminal

History Of Apple


INFO

Resources

Wi-Fi Security

Updating BeagleBone Black eMMC Angstrom

Where to eat in Toronto

Mono UnixSignal Handler

Turning on named / BIND / DNS server


Turning on named / BIND / DNS Server

www.height8.com/info/os/osx/named

Last update: Dec 07 2010 18:15 EST


Preamble Story

I'm running Mac OS X 10.6.5, as of when I first wrote this article, December 7 2010. A little while ago, there was a large software update for OS X. Before the update, OS X seemed to have the problem of ignoring the TTL value of DNS results - hanging on to them past TTL - requiring me to use the dscacheutil -flushcache command to clear the old/bad results out. This was a problem because I was debugging some nameserver updates / cut-overs, and some of the results just weren't making sense.

After the OS X update however, the reverse problem seemed to be happening. Now the TTL values seemed to be ignored in the opposite sense, i.e. discarded immediately. Coupled with a Firefox update where the Security updates switched to default-on for [X] Block reported attack sites, and [X] Block reported web forgeries, browsing the web or retrieving email now had excruciating delays. Unchecking those two items in Firefox which pre-validates the URL on a remote site sped up Firefox considerably, but still other applications in OS X, Thunderbird and web browsing were suffering from uncached DNS resolution and upstream resolver delays.

I was using OpenDNS for my nameservers, rather than that of my ISP. If my ISP is anything like yours, you're probably suffering from their poorly configured, unavailable or swamped nameservers. ISPs also tend to override TTL and other parameters, holding on to bad or outdated cached results. OpenDNS is a good alternative as they are generally more robust, and as well they can apply phishing filters to keep you from resolving to 'bad' locations, if you want that option. It's the kind of thing you might do for your parents or people who aren't overly technical, as one extra layer of protection.

In order to remove delays and caching problems though, it seemed clear that I needed to get my own caching resolver running on my local machine. Since I'm using the extremely handy MacPorts, I intended to install something like MaraDNS or a full BIND9, however I found that BIND was already pre-installed on OS X but just not completely configured and set to load on startup. Perfect.


WHY

Simply, it makes things faster and often more accurate. Every web site you go to, every domain name inside every web page, all require DNS resolution. A single web page www.example.com may reference assets on multiple subdomains and domains, each of which also require DNS resolution, e.g. gallery.example.com, pics.example.com, adverts.example.com, js.example.com, and adjax.flickr.yahoo.com, assets.tumblr.com, edge.quantserve.com, google-analytics.com, etc. If you aren't running your own nameserver, you are at the mercy of your ISP or someone you've pointed your DNS settings at to do your DNS resolution for you. Their DNS servers may go offline, may hold onto obsolete information, or may simply be slow in responding, which when browsing the web is death by a thousand cuts.

By running your own caching nameserver, you're in control, and your nameserver can go out and get the answers, removing at least one layer of delay.


Configuration

For the moment I'll keep the steps brief, and perhaps flesh them out later. You're probably technical enough to figure things out, so this should serve to point you in the right direction. You'll notice that I start out by doing a sudo bash rather than doing a sudo on individual commands. While not great form, I found some odd permissions issues that I just didn't want to take time to debug, so it was easiest just to fire up a root shell. Don't forget to exit out of the root shell afterward.

First we fire up a root shell, then generate our config & key for rndc, which controls named:

$ sudo bash
$ rndc-confgen -b 256 > /etc/rndc.conf
$ head -n5 /etc/rndc.conf | tail -n4 > /etc/rndc.key

Next, we modify /etc/named.conf using your favourite editor, e.g. nano -w /etc/named.conf, and uncomment the following line (by removing the //):

// include "/etc/rndc.key";

Next, copy the commented-out control section from /etc/rndc.conf, and use it to replace the control section in /etc/named.conf, and uncomment it by removing the #s. Note: if there is no ; on the final line, i.e. # }; then you must ensure that you put an ; otherwise named won't start up properly. Here is a sample of what to copy/paste - the port number may be different in your /etc/rndc.conf, so don't paste this sample:

# controls {
#  inet 127.0.0.1 port 953
#  allow { 127.0.0.1; } keys { "rndc-key"; };
# };

Then, to add a wee bit of security, restrict the DNS resolution to just your machine. If you don't, named listens on all interfaces on port 53 for DNS requests, which may open an avenue of attack if your computer isn't running with the Firewall enabled, or you have an attacker on the local network. Restricting named to listen only on localhost / 127.0.0.1 reduces the chances of a problem.

In the options section in /etc/named.conf, before the final }; add:

listen-on port 53 { 127.0.0.1; };

Finally, modify /System/Library/LaunchDaemons/org.isc.named.plist in your favourite editor, and change the Disabled key from <true/> to <false/>. This should set named so it starts automatically when you boot up your computer. It should look like:

<key>Disabled</key>
<false/>

Note: I'm not showing how to set up the standard named files, as OS X should have already placed a set of them in /var/named. If you don't have the default set, they're easy to google for. When I update this article in the future I may add a sample of what they look like.


Fire it up

named should start automatically when you boot your system, however we're going to start it now by using launchctl:

$ launchctl load /System/Library/LaunchDaemons/org.isc.named.plist

If launchctl didn't give you an error, check the tail end of your system.log to see if named is listening on the command channel for rndc commands. You should either see that it is listening, or that there is an error and that it will respawn in 10 seconds. If you have an error, it is probably in your /etc/named.conf

$ tail /var/log/system.log
...
named[12871]: command channel listening on 127.0.0.1#953

Next, check your named.log to verify that named is running:

$ tail /Library/Logs/named.log
...
06-Dec-2010 22:01:19.750 running

And, finally, use rndc to verify things are running:

$ rndc status
...
server is up and running

Congrats, it's running. Now, let's try to resolve something with it:

$ dig @127.0.0.1 www.google.com a


; <<>> DiG 9.6.0-APPLE-P2 <<>> @127.0.0.1 www.google.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47932
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         584736  IN      CNAME   www.l.google.com.
www.l.google.com.       300     IN      A       173.194.44.104

;; AUTHORITY SECTION:
google.com.             152009  IN      NS      ns4.google.com.
google.com.             152009  IN      NS      ns3.google.com.
google.com.             152009  IN      NS      ns2.google.com.
google.com.             152009  IN      NS      ns1.google.com.

;; Query time: 49 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Dec  7 04:17:38 2010
;; MSG SIZE  rcvd: 140

If everything worked okay, you should see a result similar to the above. Google may resolve to different results, but as long as you get results rather than an error, you should be good to go.

Now, do the exact same command again, and you'll see your Query time drop to almost nothing. named is caching your results (until the TTL runs out, as it was set by Google in this case), so future name resolution is practically instant. Hello faster web experience.

$ dig @127.0.0.1 www.google.com a


...
;; ANSWER SECTION:
www.google.com.         584706  IN      CNAME   www.l.google.com.
www.l.google.com.       270     IN      A       173.194.44.104
...
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

The final step is to modify your network preferences, and change your nameserver(s) to be 127.0.0.1 instead of whatever it is. You can find this by clicking on System Preferences then Network (which is in the Internet & Wireless section), and then modifying the DNS Server field of your connected/desired Service + Location.

It's beyond the scope of this article for me to suggest which Service (e.g. Ethernet, AirPort) and/or Location (Automatic, or other locations you've set up) to modify. If in doubt, obviously write down the DNS Server value(s) before you replace them with 127.0.0.1. If you are modifying a Service+Location that is configured automatically, you will probably need to click on the Advanced tab, leaving the TCP/IP tab to configure automatically, but click on the DNS tab to get rid of the old entries and manually add 127.0.0.1.

rndc has a number of commands to control named, the most useful of which are probably:

$ rndc reload
$ rndc stop
$ rndc flush

Suggested further reading

$ rndc -h
$ man rndc
$ man named.conf

 
To provide feedback, corrections or suggestions, please send an email to: back feed @ height8 .com (remove the spaces from the email address if you're doing a copy/paste). In your email, please mention you are referring to: info/os/osx/named