howto://use BIND secondaries with an AD integrated primary DNS

In a previous post we discussed setting up a DNS solution that combined scalability, flexibility, and security. We also designed it to be reliable and responsive. We even acknowledged that management would want it to be cheap, fast and good. Turns out management didn’t get the joke, and called me out on that…especially the cheap part. So in this post, I’ll document what I had to do in order to deploy Ubuntu 9.10 servers running BIND9 for Internet resolution, while leveraging our existing Active Directory integrated DNS so that folks wouldn’t have to learn VIM or the subtle beauty of the zone file.

Meh…I think they’re just scared of encountering this…THE TRAILING DOT OF SHAME!!! Been there, done that, learned my lesson and moved on. But hey, I am not going to argue with them. I don’t really like vim, but I love having dnsmgmt.msc on my desktop. The way we’re going to set this up, any domain admin or DNS admin can make DNS changes using the tools they are familiar with, our primary DNS is fault-tolerant, replicated, and backed-up along with AD, we’re implementing a hidden primary (aka stealth primary,) and we aren’t spending any money. We even get to throw a little Tux into the mix. What’s not to love about this?

Assumptions

For purposes of this post, we’re going to assume that you have administrative rights to Active Directory, and root rights to the Ubuntu 9.10 servers that are going to be your secondary DNS servers. We’ll also assume that you understood what I just said, that you know the difference between primary and secondary servers, and that you are NOT running a split DNS. We’re also going to do all our Ubuntu voodoo on fresh, default installs. AppArmor is installed in its default configuration. If any of the above doesn’t make sense, or contradicts your reality…STOP. This is not going to work for you!

Windows stuff

Create your zone as a primary stored in Active Directory, do not allow dynamic updates, and populate your records as necessary. If you are migrating from another solution, and you don’t want to take forever to get all your records in, see this post for how to automate records creation using dnscmd. This zone will replicate to either all DNS servers in your domain, or in your forest, depending upon which scope you choose. If we were going to use only domain controllers for DNS, our work would be done. We’re not though, so here is what you need to do next.

Configure the zone for your desired Responsible person, intervals, and default TTL.

Responsible person: You should set your responsible person to be a distribution list or alias that complies with RFC 2142. Here, we are using hostmaster.
Refresh interval: I like to set a refresh of 5 minutes, so that my secondaries are checking for updates frequently. If you have bandwidth constraints between your secondaries and your primary, don’t worry. Unless there is a change, all this will be is a single packet UDP query for the SOA record, followed by a single packet reply. No serial number change, no more traffic for 300 seconds.
Retry interval: Just in case a query fails, secondaries should try again in ten minutes; plenty of time for a reboot to complete.
Expires after: Should disaster strike my primaries down, I like to know I have a few days before I have to worry. Considering how bad things must be if all my primaries are down in this design, I’ll need all the time I can get.
Minimum (default) TTL: I like ten minutes as a default. I’ll set longer TTLs on stable records (like MX) by hand, and shorter ones on volatile records, but ten is a good default for me.

Then set the zone to allow zone transfers, either to any server, or at least to your secondaries. Since these will all be internal, I just set it to any.

Configure the server, again, on each server that secondaries will pull from, to support BIND secondaries.

Configure ONE DNS server to disable autocreation of NS records: Since we are creating the zone as AD integrated, all domain controllers are going to want to add themselves as NS records. Since these are internal, we don’t want that. I mean we really don’t want that. That’s our internal domain controllers we’re talking about here. They’re nobody’s business, and are probably using RFC1918 addresses anyway. On only one server (this will replicate to the rest) open an administrative command prompt and enter the following command

dnscmd /config example.com /AllowNSRecordsAutoCreation a.b.c.d a.b.c.e [enter]

where a.b.c.d and .e are the internal ip.addrs of your BIND servers. They won’t create records themselves, but we need to tell the the zone something or this command just resets the zone to default. Then, go into the properties of the zone and delete all the domain controllers from the Name Servers tab, and then add your two BIND9 servers external records. Note, that your SOA will still reflect the internal DC that you are pulling the zone from, there is nothing we can do about that. But identifying the name of one internal DC (which is of course completely unreachable from the outside) is not a real risk. It’s just something we’ll have to accept. With that, we’re done with the Windows side of things. Next up, the BIND secondaries!

Linux stuff

Remember, I am assuming that you are starting with a fresh install of Ubuntu 9.10, your user account is privileged, and you have left it pretty much alone other than to do the updates, static ip.addrs, etc. AppArmor is installed by default now, and what we are going to do with BIND assumes just that. If you disabled or removed AppArmor, this guide will probably NOT work for you. Log on, open a terminal, and start typing.

Install BIND9: The easiest way to do this is to open a terminal and type

sudo apt-get install bind9 [enter]

This will prompt you to install bind9 and the bind9utils. Type ‘y’ and hit enter to proceed and BIND will install.

Configure BIND9: BIND9 uses the file /etc/bind/named.conf.local to store configuration information about the zones it stores. Since we are setting up our BIND9 server to be a secondary for our zone, we will edit this file to specify our zone, the masters for the zone, and we’ll lock down zone transfers to localhost only. If you really like vi, you can use it, but we’ll use gedit.

sudo gedit /etc/bind/named.conf.local [enter]

We’ll configure our zone between the comment sections, designated by //.

Here our zone is example.com, it is a slave, we will store the zone file in /var/cache/bind/db.example.com, we’re using 10.14.1.21 and 10.14.1.22 as our masters,and we’re only going to permit zone transfers to ourselves. If you have additional zones to configure, just add them to this same file, one at a time, starting with zone and ending with the }; just like the first one.

While optional, you might also want to edit your named.conf.options file to help mask you BIND version. Sure, there are fingerprinting methods that can dial in, but by placing a version directive here, you can at least make the bad guys work for it a little bit.

Save the file, exit, and then restart BIND9 by issuing this command.

sudo /etc/init.d/bind9 restart [enter]

Then use dig or nslookup to test resolution against your BIND9 servers. Try to do zone transfers, recursive queries, MX record lookups, TXT record lookups (if you are using SPF) and then do a version query. With that version directive, you should see this!

All should be well at this point, but if you get a query refused for the domain you are actually hosting, check your AD servers to make sure they are allowing zone transfers, restart BIND and try again. Baring any typos, you should be good to go. Remember that every line of your conf files must end with a semicolon. I miss that one a lot.

If you are not familiar with dig, host, and whois for Windows, you can get a port from here and you can read about how to use the dig command here. Once you’re comfortable with your BIND servers, you can either open up UDP 53 on the firewall to them, or publish them using your ISAs or TMGs. Hmm, that might make a good follow up post…like this!

Questions, comment, concerns? All are welcome by leaving a comment!