Integrating Windows and Linux DNS | Windows And Linux Integration Hands-on Solutions for a Mixed Environment

In Chapter 1, we took a whirlwind tour of setting up Windows and Linux servers. Then, on our Linux server, we create a delegated subdomain that allowed our Active Directory to play in its own "sandbox" of ad.corp.com . Next , on our Windows server, we ran the dcpromo command and got our Active Directory up and running in ad.corp.com .

In Chapter 1, we demonstrated the ideal way of integrating Active Directory and Unix/Linux DNS. That is, we hardly integrated at all. We gave Active Directory its own sandbox using its own DNS servers to house the required Active Directory records, and we gave the Unix/Linux users their own sandbox in corp.com to house their DNS resource records. The delegated subdomain from the Linux-hosted root DNS server makes the two domains, corp.com and ad.corp.com , play together nicely .

If at all possible, you should do your production DNS setup this way, with separate DNS domains for Active Directory and Linux.

Housing Active Directory DNS Records on Linux DNS Servers

In the first chapter, we set up Active Directory to "own" its own DNS. This is almost certainly the best way to go, from Microsoft's perspective. They kind of have a good point. Here are a handful of reasons why setting up Active Directory-integrated DNS specifically for Active Directory is a good idea:

If you decide to implement a Linux BIND server, you need to be careful to choose one which also implements DNS Security, or DNSSEC. Even if you specify to lock down updates so that they're received only from Windows Domain Controllers, it's possible for a rogue administrator or rogue process on those DCs to register resource records without any kind of intervention.
Active Directory-integrated zones give security to dynamic updates. That is, when the workstation re-registers via DHCP their IP address, Active Directory-integrated DNS can ensure those updates are really being changed by the client, not someone pretending to be the client.
Active Directory-integrated zones also avoid the problem of a single point of failure. That is, because every Active Directory Domain Controller is writable, there's no one place that the DNS data must be written to be propagated.

If the preceding points don't persuade you to embrace the Microsoft best practice, then, yes, it is possible to set up an Active Directory domain so it doesn't "own" its own DNS. Rather, you can set up Linux to house the required Active Directory DNS records and have all clients use the Linux DNS servers (which run BIND DNS). Why would you want to do this? Many organizations already have BIND DNS servers and expert BIND administrators. Many places ask themselves , "Why should we bother creating a whole 'parallel' DNS structure, if our existing BIND DNS structure is already great?"

As it turns out, there are technically only a few things that the BIND DNS server needs to handle in order to be Active Directorycompatible.

Our Fedora Linux server is running BIND version 9, which is compatible with Active Directory DNS records right out of the box, including the use of underscores in resource record names . See the sidebar "If You're Using an Older DNS" for more background about these issues.

The best news is that Webmin supports everything we need to do in order to enable effective storage of Active Directory DNS records in BIND 9. All we have to do is enable dynamic updates so that the Active Directory server can "push" DNS changes to our BIND server on the fly.

Here's what we want to accomplish. We want to set up a new Active Directory domain in the same forest as ad.corp.com . We'll call it peerad.corp.com . The first Domain Controller in peerad.corp.com will be called peerdc1.peerad.corp.com and, in our examples, will have the IP address 192.168.2.240.

To create a new Active Directory domain, we'll first need a new DNS domain. We'll configure our Linux DNS server, linserv1.corp.com , to house the peerad.corp.com resource records.

Happily, we can do so using Webmin's "BIND DNS Server" module, which makes the procedure rather painless. All we need to do is create a new DNS zone for the peerad.corp.com subdomain and edit the options for that zone to enable DNS updates from 192.168.2.240, which is the IP address of peerdc1.peerad.corp.com , the new Active Directory Domain Controller for the peerad.corp.com domain. There's just one extra step: with updates coming from Active Directory on the fly, the BIND server ( named ) needs to be able to write those updates to disk. However, for security reasons, named does not run as root. Instead, it runs as a special user called named . Only root has permission to write to the DNS zone files kept in / var/named and /var/named/chroot/var/named .

Note

Existing symbolic links from the first directory allow named to work identically, regardless of whether it is running in a special chroot jail mode in which /var/named/chroot/var/named appears to be /var/named from BIND's perspective. We'll fix permissions in both directories to cover either mode of operation.

Fortunately, the named user is a member of the special named group, and that group owns the directories in question, so we can use a simple chmod command to grant named the power to write to them.

Follow these steps to create the peerad.corp.com DNS zone on linserv1.corp.com :

Log into Webmin as usual at the URL https ://linserv1.corp.com:10000/
Click "Servers."
Click "BIND DNS Server."
Click "Create master zone." The "Create Master Zone" page appears as shown in Figure 9.1.
In the "Domain name /Network" field, enter peerad.corp.com .
In the "E-mail address" field, enter root@corp.com .
Accept the defaults for the remaining options and create the new DNS zone by clicking "Create." The "Edit Master Zone" page appears. You can save some effort by leaving this page open for the steps that follow.

Figure 9.1: Creating a separate DNS zone for the peerad.corp.com subdomain on linserv1.corp.com

Follow these steps to configure linserv1.corp.com to accept DNS updates from the Active Directory Domain Controller:

Give the named group write access to the DNS data directories:

 chmod g+w /var/named/chroot/var/named chmod g+w /var/named

Log into Webmin as usual at the URL https://linserv1.corp.com:10000/ .
Click "Servers."
Click "BIND DNS Server."
Click " peerad.corp.com " to access the "Edit Master Zone" page.
Scroll down and click "Edit Zone Options." The "Zone Options" screen appears. We will configure it as shown in Figure 9.2.
For "Allow updates from" enter 192.168.2.240 . This is the IP address of the peerdc1.peerad.corp.com .
Leave the remaining settings as shown in Figure 9.2.
Click "Save" to return to the "Edit Master Zone" page.
Click "Apply Changes."

Figure 9.2: Be sure to specify the Active Directory Domain Controller from which to accept recordsin our case, 192.168.2.240, peerdc1.peerad.corp.com .

Note

If you have used earlier versions of BIND, you may wonder why we aren't configuring BIND to specifically tolerate unusual hostnames used by Active Directory, such as _kerberos , which begin with underscores. This was an issue in BIND 8. However, BIND 9, included with Fedora Core 3, accepts such names out of the box. That's because, eventually, the RFC that specifies acceptable DNS characters evolved to allow underscores. BIND 9 embraces this new standard and no special configuration is required to accept them. BIND 8 users can make the necessary configuration change by setting "Check Names?" to "Ignore" on the "Zone Options" page, instead of leaving it set to "Default" as shown in Figure 9.2, where we are able to leave this option set to "Default" because BIND 9 has no need for it.

When it's finished, your new Active Directory structure will look like Figure 9.3. You will have the new peerad.corp.com subdomain integrated into the existing corp.com domain.

Figure 9.3: peerad.corp.com will be a new domain whose DNS records will "live" upon linserv1.corp.com .

Bringing Up a New Active Directory Domain

In this section, we'll bring up a new Active Directory domain, a peer to ad.corp.com . We'll call it peerad.corp.com . Again, the goal is to support this Active Directory domain using DNS running on linserv1.corp.com .

At this point, you can refer to the steps back in Chapter 1 in the "Installing Your Active Directory" section when we brought up windc1.ad.corp.com , the first Domain Controller in ad.corp.com . There is only a handful of differences in the domain configuration. Here's a brief rundown:

The server name is different. We suggest peerdc1 .
In our examples, we're assigning the IP address of 192.168.2.240 to peerdc1 .
During the Domain Controller Promotion wizard (DCPROMO), when you get to the "Domain Controller Type" screen, select "Domain controller for a new domain." When you get to the "Create a new domain" screen, choose "Domain tree in an existing forest." Enter peerad.corp.com as the new domain name, as shown in Figure 9.4.
Configure the TCP/IP properties for the network interface on peerdc1 to use linserv1 (192.168.2.202) as the DNS server.

Figure 9.4: Your new peer domain will be called peerad.corp.com .

Again, you needn't keep the DNS service running on the Domain Controller. The DNS records are all going to be housed on linserv1.corp.com .

Once you've finished the Domain Controller Promotion Wizard and restarted the server, the DNS resource records for peerad.corp.com will be placed into the corp.com zone. If you get an error message, such as in Figure 9.5, or if you get anything else that expresses that DNS records cannot be written upon linserv1.corp.com , be sure you've made the /var/named and /var/ named/chroot/var/named folders writable and enabled updates from 192.168.2.240 on the Linux side.

Figure 9.5: If you get a DNS- related error message like this one, be sure that BIND's data directories are writable and that 192.168.2.240 is allowed to send updates to linserv1.corp.com .

Verifying Active Directory DNS Records within Linux

Now that you've brought up peerad.corp.com (with peerdc1 as the only Domain Controller in it), you're ready to make sure the appropriate Active Directory DNS records got created in the peerad.corp.com zone that lives on linserv1.corp.com .

But how can we tell if peerdc1.corp.com's resource records successfully made it into the new zone? We can browse the DNS records in the peerad.corp.com zone using Webmin. However, Webmin only shows us the contents of the zone file, peerad.corp.com. hosts , which was created automatically by Webmin when we created the new zone. It doesn't interrogate the DNS server on the fly for this information. This is an issue because peerad.corp.com.hosts is not rewritten on the fly right away when updates arrive from the Active Directory server. Instead, for efficiency reasons, changes received on the fly are written to a "journal" file called peerad.hosts.corp.com.jnl .

We can work around this problem by asking the DNS server to restart. When Webmin asks the DNS server to shut down and restart gracefully, the DNS server does rewrite the peerad.corp.com.hosts file as a final step before exiting. (The DNS server also does this on a periodic basis while running, so that the .jnl file doesn't grow forever.) Once we do that, it's a cinch to view the DNS records with Webmin.

We'll verify our success by checking the peerad.corp.com for service address (SRV) records, which specify the hosts that provide various services such as Kerberos and LDAP. We certainly didn't set these up, so their presence indicates that DNS updates are happening successfully.

To verify that DNS updates for the peerad.corp.com domain are being accepted successfully by linserv1.corp.com 's BIND DNS server, follow these steps:

Log into Webmin as usual at the URL https://linserv1.corp.com:10000/ .
Click "Servers."
Click "BIND DNS Server." The "BIND DNS Server" page appears.
Scroll to the bottom of the page and click "Apply Changes." This restarts the BIND DNS server. The "BIND DNS Server" page reappears.
Click " peerad.corp.com " to access the "Edit Master Zone" page.
Click "Service Address" to view the "Service Address Records" page.
This page should contain records similar to those shown in Figure 9.6.

Figure 9.6: Displaying service address records to verify that DNS updates from Active Directory have been accepted by linserv1.corp.com

If you don't find any records in the listing, be sure that BIND's data directories are writable and that 192.168.2.240 is allowed to send updates to linserv1.corp.com .

Setting Up a Linux Branch Office DNS Server

One of the other ways you might choose to integrate Windows and Linux DNS is to have a Linux server be a secondary DNS server to a Windows DNS server.

This might be useful in branch office scenarios where a single Linux server in a field office runs the whole show. Clients in the field office may need to connect with hosts in other offices and that would require a DNS lookup. In this type of scenario, we would have our Linux server be a member of Active Directory (as we demonstrated in Chapter 3). Then that single Linux server in the branch office will be the "go to" server for DNS requests (and anything else you might want to throw at it).

Here, we'll leverage this idea to target three main goals, shown in Figure 9.7.

Goal #1: Branch-office clients (Windows or Linux) send all DNS queries to a local DNS server
Goal #2: The branch-office DNS servers gets updated from the home office
Goal #3: Requests that cannot be answered by the branch-office DNS server gets forwarded up the food chain (to the branch office, and, if needed, to the Internet.)

Figure 9.7: We want to accomplish three goals when we put a Linux DNS server in the branch office.

The secondary zone contains the same resource records as the primary zone in the home office, so by installing DNS on the Linux branch office server, clients in the branch office get replies to their DNS queries quickly with no need to traverse the WAN.

Queries for resource records outside the company's DNS zones are forwarded to DNS servers in the home office where you can take advantage of caching to improve lookup speeds.

In this example, we'll assume you're ready to install your new linbranch1.ad.corp.com Linux server. Let's talk about that configuration now.

If You're Using an Older DNS

Fedora Core 3 supports the DNS functions we need to make this happen. If you're not using Fedora Core 3, there are three main RFCs your Linux DNS should have compliance with in order to ideally interoperate with Windows DNS.

None of these first three are strictly required, but if your older DNS supports these three RFCs, things will be easier and faster all around.

Not required, but nice to have: RFC 1995incremental zone transfers Because this server is going to be the secondary server, it could download lots and lots of records from our main Active Directory DNS servers. To that end, RFC 1995 provides for incremental zone transfers that stipulate that only records that change will come across the WAN and onto this DNS server.

Not required, but nice to have: RFC 1996DNS change notification When your Linux server supports this RFC, changes from one DNS server are immediately transferred to other servers. In our case, we want all the central office's Active Directory DNS changes to immediately go to our branch office Linux server.

Not required, but nice to have: RFC 2308negative caching While not strictly required, negative caching improves performance in cases where clients look up a record that does not exist. This can be helpful in a scenario involving a slow link.

Absolutely required: RFC 2052 The last requirement is RFC 2052. Active Directory utilizes Service Location (SRV) resource records in a number of ways. In short, if your DNS doesn't support RFC 2052, it's simply not a good candidate to house Active Directory records.

Mostly, you'll need to ensure your DNS meets these minimum requirements if you're not using BIND 8.2 or BIND 9. Indeed, Bind 4 is still quite popular with some companies.

Installing Fedora on Linbranch1.ad.corp.com

Setting up the branch office DNS server isn't difficult. To configure linbranch1.ad.corp.com , follow the procedure presented in Chapter 1 to install linserv1.corp.com in the "Installing Fedora Linux" section, with the following exceptions:

Set the IP address to 192.168.2.209.
Set the DNS server to localhost .
Set the hostname to linbranch1.ad.corp.com .
Add an "A" record for linbranch1.ad.corp.com to the Windows DNS server on windc1.ad.corp.com .

When you have completed the initial installation, make sure you also fetch security updates and other fixes by running up2date. BIND DNS is updated with some regularity to address security and other important issues, so it's a good idea to be current. Double-click the exclamation point icon in the upper-right corner and follow the steps given in Chapter 1 to update your system.

Now we're ready to set up DNS on linbranch1.ad.corp.com .

Setting up Linbranch1.ad.corp.com as a Secondary DNS Server

Setting up zone transfers from a Windows primary DNS server to a Linux secondary DNS server involves three major steps:

Creating a "slave zone" for the ad.corp.com domain on linbranch1.ad.corp.com
Configuring the Linux DNS server to request zone transfers from the Windows DNS server
Configuring the Windows DNS server to accept zone transfer requests from the Linux DNS server and to notify the Linux DNS server when changes occur to the zone

So let's get to it.

Configuring Our Windows DNS Server to Transfer Our Zone to Linux

On the Windows DNS server, we need to specify the secondary servers from which zone transfer requests will be accepted. This is a security measure that prevents a bad guy from "dumping" the contents of a zone by pretending to be a DNS secondary server.

We also need to enable the "Notify" options so that zone changes are transferred immediately from the Windows primary to the Linux secondary DNS server. Otherwise, the secondary server will only ask for a zone transfer at specific refresh intervals, normally every 15 minutes.

To configure a Windows DNS server to allow zone transfers for the ad.corp.com zone to the Linux secondary DNS server and to notify the Linux secondary DNS server of changes, do the following:

On windc1.ad.corp.com , log in as Administrator.
Click Start All Programs Administrative Tools DNS.
We're only concerned with the ad.corp.com zone. Find it in windc1 Forward Lookup Zones ad.corp.com , right-click ad.corp.com and select "Properties."
Click the "Zone Transfers" tab. Select "Allow zone transfers" and select "Only to the following servers." Enter the IP address of linbranch1.ad.corp.com , 192.168.2.209 as shown in Figure 9.8.
Click the "Notify" button (as shown at the bottom of Figure 9.6) to get to the "Notify" window.
Select "Automatically notify," select the "The following servers," and again, enter the address of linbranch1.ad.corp.com , 192.168.2.209 as shown in Figure 9.8.
Click "OK" to close the "Notify" tab, and click "OK" to close the " ad.corp.com Properties" window with the "Zone Transfers" tab.

Figure 9.8: Configure Windows DNS so that it allows zone transfers and will also automatically notify secondaries when changes are available.

Configuring the BIND DNS Server with Webmin

By default, when we choose to install a DNS server, Fedora configures it as a simple caching proxy that is not the master for any domain but does save round trips over the WAN when several users look up the same host. That's 90 percent of the behavior we want. In addition, though, we want our server to act as a secondary or "slave" DNS server for the ad.corp.com domain, ensuring that all queries about that domain can be resolved more quickly with no round trips on the WAN for single queries from individuals. A true slave DNS server will fetch and update all of the information about the domain for which it acts as a slave in advance, which is known as a "zone transfer," rather than making queries of the primary server only when a user happens to need particular information.

As usual, we'll use Webmin to take care of the configuration settings we need. But first, we'll need to make sure the BIND DNS service, named , is up and running on the server. We'll do that using the familiar chkconfig and service commands.

Follow these steps on linbranch1.ad.corp.com to configure BIND as a secondary DNS server for the ad.corp.com :

Configure Fedora to start the named daemon on every reboot:
```
 chkconfig named on 
```
Start the named daemon now:
```
 service named start 
```
Log into Webmin in the usual way, at the URL https://linbranch1.ad.corp.com:10000/ .
Click "Servers."
Click "Bind DNS Server."
Click "Create slave zone." This is found beneath the words "Existing DNS Zones." The "Create Slave Zone" page appears. We will configure this page as shown in Figure 9.9.
In the "Domain name/Network" field, enter ad.corp.com .
In the "Master servers" field, add this single entry:
```
 192.168.2.226 
```
This of course is the IP address of windc1.ad.corp.com .
Leave the remaining fields set to their default values.
Click "Create" to create the slave zone. The "Edit Slave Zone" page appears.
Click "Return to zone list" to return to the "BIND DNS Server" page.

Figure 9.9: Use these settings to create a slave zone such that linbranch1.ad.corp.com is a secondary DNS server for the ad.corp.com domain.

Now it's time to verify that the resource records have actually arrived in our slave DNS server's slave zone file. We'll do that in the same way we verified our success earlier when we configured linserv1.corp.com as the primary DNS server for ad.corp.com . As before, we'll need to restart the DNS server before checking the records, to make sure the records have actually been committed to the zone file where Webmin can find them.

Follow these steps to verify that the slave DNS zone actually contains the records for the ad.corp.com domain:

Log into Webmin as usual at the URL https://linbranch1.ad.corp.com:10000/ .
Click "Servers."
Click "BIND DNS Server." The "BIND DNS Server" page appears.
Scroll to the bottom of the page and click "Apply Changes." This restarts the BIND DNS server. The "BIND DNS Server" page reappears.
Click " ad.corp.com " to access the "Edit Slave Zone" page.
Click "Address" (the "A" icon) to display a list of hosts in the ad.corp.com domain.

If the list of hosts is empty, make sure you have started the BIND DNS server and created the slave zone for ad.corp.com .

Verifying that Our Linux DNS Server Is Receiving Zone Transfers from Active Directory

Now that we've set up our Active Directory to send any changes to our Linux branch office server, we can test it out. The test takes two steps: first, we'll make an Active Directory change. Then, we'll verify that our Linux server got the change.

Making a Simple DNS Change in Active Directory

To make a simple DNS change in Active Directory, just create an A record. This is the same kind of record that is produced whenever a workstation joins the domain, but we'll pretend one is coming online by manually adding an A record.

To add an A record, in the DNS manager, right-click ad.corp.com and select "New Host (A)." You'll be presented with the "New Host" dialog. Enter the name of a new (fake) computer, such as arecordtest1 (the ad.corp.com part will already be filled in the form for you), then add in an IP address that won't matter (we entered 192.168.2.222 ). Once you have the A record in place, the previous steps should send the record over to our Linux secondary DNS server immediately.

Testing Linux for the Zone Transfer Record Change

As in the previous section, it's a little bit of a pain to make sure the secondary DNS server has really accepted the change. Again, the changes are written to a journal file that is not plaintext. We can ask the server to look up the new host, but that only proves that the server is smart enough to consult ad.corp.com if it doesn't contain the record itself.

So how do we tease out the truth? The same way as before: we'll restart the DNS server to force the contents of the journal file to be committed to the "official" ad.corp.com.hosts file so that BIND can start up again cleanly, and then we'll use Webmin to inspect the results.

Follow these steps to verify the successful arrival of arecordtest1 in the slave DNS server's zone file:

Log into Webmin as usual at the URL https://linbranch1.ad.corp.com:10000/ .
Click "Servers."
Click "BIND DNS Server." The "BIND DNS Server" page appears.
Scroll to the bottom of the page and click "Apply Changes." This restarts the BIND DNS server. The "BIND DNS Server" page reappears.
Click " ad.corp.com " to access the "Edit Slave Zone" page.
Click "Address" (the "A" icon) to display a list of hosts in the ad.corp.com domain.

If the list of hosts does not contain arecordtest1 , make sure you enabled notification of linbranch1.ad.corp.com when configuring peerad.corp.com .

Forwarding Unknown Queries to Windows DNS

The final goal for our Linux branch office DNS server is to forward queries it cannot resolve up to our Active Directory windc1.ad.corp.com . Then, if windc1.ad.corp.com doesn't know the answer, it's already set up to forward to linserv1.corp.com . And if linserv1.corp.com doesn't know the answer, it asks the Internet.

In Chapter 1, we set up our windc1.ad.corp.com Windows DNS server to forward queries it didn't know about to our main DNS servers on corp.com .

Here, we'll set up linbranch1.ad.corp.com to forward queries it can't resolve over to windc1.ad.corp.com . Again, since we already set up windc1.ad.corp.com to forward to corp.com , and corp.com is forwarding to the Internet, we should complete the chain of command right here.

Setting Up Our Linux Branch Office DNS Server to Forward to Our Active Directory DNS Servers

Webmin fully supports configuration of forwarding for DNS queries, so we can easily set up the DNS server to forward queries to windc1.ad.corp.com (192.168.2.226), which will forward them in turn to linserv1.corp.com (192.168.2.202) if needed. linserv1.corp.com , in turn, forwards them to the Internet at large when they are not locally resolvable.

To configure BIND on linbranch1.ad.corp.com to forward queries to windc1.ad.corp.com , follow these steps:

Log into Webmin in the usual way, at the URL https://linbranch1.ad.corp.com:10000/ .
Click "Servers."
Click "Bind DNS Server."
Click "Forwarding and Transfers." We'll configure the "Forwarding and Transfers" page as shown in Figure 9.10.
Clear any entries found in the "IP address" and "Port (optional)" columns of the "Servers to forward queries to" table. Add this single entry in the first row of the "IP address" column, leaving the "Port (optional)" column blank:
```
 192.168.2.226 
```
The remaining options should already be set as shown.
Click "Save" to return to the "BIND DNS Server" page.
Click "Apply Changes."

Figure 9.10: Forward queries not resolved directly by this server to the next in line windc1.ad.corp.com (192.168.2.226).

Testing DNS Forwarding

How can we verify that DNS queries sent to linbranch1.ad.corp.com are really being forwarded first to windc1.ad.corp.com , then to linserv1.corp.com , and finally to the Internet?

We thought of elaborate ways to do this. Then we caught on: it's very simple to do! With one exception that is easy enough to avoid in the first place, there are obvious ways to detect each possible error. The following table presents the possible DNS misconfigurations, the telltale symptoms, why those symptoms occur, and how to correct the problem.

Table 9.1: Possible DNS misconfigurations.
Problem	Symptom	Why	Solution
linbranch1.ad.corp.com is making its own queries without consulting any "upstream" DNS server.	host linserv1.corp.com will not report 192.168.2.202.	The outside Internet can't "see" our internal DNS servers.	Verify that you have set up the "Forwarding and Transfers" page correctly and used the "Apply Changes" button.
linbranch1.ad.corp.com is sending requests directly to linserv1.corp.com rather than windc1.ad.corp.com .	None.	linserv1.corp.com is capable of delegating queries to windc1.ad.corp.com , so this is not easily detected .	Make sure you entered 192.168.2.226 and not 192.168.2.202 on the "Forwarding and Transfers" page.
linbranch1.ad.corp.com is not resolving DNS queries at all.	host linserv1.corp.com and host www.google.com both fail.	BIND did not start up successfully.	Consult /var/log/messages for errors during BIND startup and address them.

We've succeeded in doing some remarkable cross-platform networking tricks with DNS. But that's just for starters. We're going to have a lot more fun.