DNS on Unix: Active Directory friend or foe?

ITworld.com –

In the last couple of columns, I've been covering strategies for supporting Active Directory's (AD's) DNS requirements, particularly from the standpoint of shops that have DNS implemented on non-Windows platforms such as Unix, Linux, or NetWare.

In my last column, I covered the first AD/DNS integration option -- migrating a Unix-based DNS to Windows 2000. In this column I follow up with option number two -- leveraging your current Unix-based DNS environment to support AD. In my next column, I'll round out the series by covering the third strategy -- integrating Windows 2000-based DNS servers with your current DNS environment.

The caveats

If you've been in the business for more than say, a week, you can easily deduce that deploying AD on anything but a Microsoft-based DNS may not be such a great decision.

After all, Microsoft has shipped all the DNS features required to support AD right in the Windows 2000 box. And although you can support AD on a Unix-based server, in the back of your mind you have to wonder whether, at some point down the road, a bug will pop up that requires a specific fix or modification not available for DNS on your chosen platform.

Or what if a service pack makes a modification to the Windows 2000 DNS to support a specific feature, and you're out of luck because your DNS won't support the feature?

And then there is always the customer-support concern: Will Microsoft provide support if you're running on a Unix-based DNS? Although they might not turn you away, it's a safe bet that whoever is on the other end of the phone probably doesn't have much experience with your DNS implementation.

These are all very valid concerns, but with a good understanding of DNS and its deployment implications with respect to Active Directory, you might still decide that you can live with the risks -- especially if either migration or the effort required to support a mixed Unix/Windows 2000 DNS environment is undesirable. In other words, running AD on a Unix-based DNS might not be as terrible as the idea first sounds.

The path of least resistance

For starters, you avoid the planning overhead required to move completely to Windows 2000 DNS (i.e., the DNS migration scenario), and you won't need to plan for accommodating the various workaround issues (some of which I will cover in my next column) that are called for when implementing a mixed Unix/Windows 2000 DNS architecture. And although the version of BIND you are running may require an update, the current DNS infrastructure that you may have relied on for years stays otherwise intact.

Given these factors, proposing to support AD on an existing Unix-based DNS will probably be the path of least resistance in your organization. Here are some key elements and examples to assist you in your planning.

Implementing support for dynamic update of SRV records

As I discussed a couple of columns back, in order to deploy Active Directory over a Unix-based DNS, your BIND implementation needs to support SRV resource records and dynamic update (dynamic DNS or DDNS). In addition, it's worth noting that the DNS server needs to support dynamic update of SRV records, so that the actual SRV records can be registered dynamically. In order to support these features, your Unix servers need to be running BIND version 8.2.2 or greater. (You can download the BIND source code at ftp://ftp.isc.org/isc/bind/src.)

To support dynamic update, you need to add an option statement to the DNS server's

<font face="Courier">/etc/named.conf</font>
file for each DNS zone in which you want to allow dynamic updates. I've illustrated the syntax in the following example, a sample zone section of /etc/named.conf with dynamic update enabled:

<font face="Courier">
zone "itworld.com" {<br>
type master;<br>
file "db.test";<br>
allow-update { 192.168.10/24; };<br>

In this example, the keyword

<font face="Courier">allow-update</font>
specifies that dynamic update is allowed from hosts in the IP address range to (i.e., subnet with a 24-bit subnet mask).

You'll need to make such modifications only on one machine -- the primary (or master) name server for that zone -- since that's where all record updates are performed. Once you've implemented this change, you need to restart the named service in order for the change to take effect; then you can verify functionality.

Tools and testing

To test dynamic update you can use the Unix

<font face="Courier">nsupdate</font>
tool, a command-line utility that allows you to perform and test dynamic updates to a DNS zone. You can use
<font face="Courier">nsupdate</font>
to perform several updates from a text file in a batch mode, or you can use the tool in interactive mode. Here is an interactive-mode example that helps test dynamic update:

<font face="Courier">
$ nsupdate<br>
> update add Windows 2000dc1.itworld.com. 3600 IN A<br>
> update add _ldap._tcp.dc._msdcs.itworld.com. 600 IN SRV 0 100 389<br>
Windows 2000dc1.itworld.com.<br>

Let's step through the example.

In the first line, I simply load

<font face="Courier">nsupdate</font>
in interactive mode. In the second line, I add a host or a record for the host
<font face="Courier">Windows 2000dc1</font>
to the itworld.com domain. Finally, in the third line I add an SRV record indicating that the LDAP (
<font face="Courier">_ldap.</font>
) service is available, via the TCP protocol (
<font face="Courier">_tcp.</font>
), for a domain controller (
<font face="Courier">dc.</font>
), for the AD domain
<font face="Courier">itworld.com</font>

Note that I skipped over one piece of the record:

<font face="Courier">_msdcs</font>
. Microsoft registers all the SRV resource records for AD under this
<font face="Courier">_msdcs</font>
DNS parent container for the domain. In DNS terms, this is actually creating a nondelegated DNS subdomain called
<font face="Courier">_msdcs</font>
, within the zone
<font face="Courier">itworld.com</font>
, for the purposes of registering AD SRV resource records.

<font face="Courier">nsupdate</font>
is a great tool for testing dynamic update. Unfortunately, Microsoft doesn't really make available any direct Windows 2000 equivalents, although you might be able to track down a third-party version. Instead Microsoft offers two tools worth noting to assist you in testing and troubleshooting problems with dynamic update. These are
<font face="Courier">ipconfig</font>
<font face="Courier">dnscmd</font>

<font face="Courier">ipconfig</font>
is simply the standard command-line tool that was available in Windows NT 4.0 for troubleshooting TCP/IP configuration problems. In Windows 2000 the tool has been updated to include some new arguments, such as
<font face="Courier">/registerdns</font>
, which you can use to refresh a host's DHCP lease and to reregister the host with DNS. The
<font face="Courier">/registerdns</font>
feature itself is somewhat limited, but nonetheless it's worth checking out all of
<font face="Courier">ipconfig</font>
's new arguments; to do so, type
<font face="Courier">ipconfig /?</font>
at the Windows 2000 command line.

The other tool,

<font face="Courier">dnscmd</font>
, is much more like
<font face="Courier">nsupdate</font>
in functionality, in that it allows you to perform dynamic DNS updates from the command line. However, this tool is really useful only against Windows 2000 DNS servers, as it uses Windows 2000 RPCs to perform the update operation.

There is also a way to test compatibility of SRV resource records on your Unix-based DNS without necessarily using dynamic update. If you are interested in doing this, you can import the contents of the

<font face="Courier">netlogon.dns</font>
file, which is found in your
<font face="Courier">winnt\system32\config</font>
directory on your Windows 2000 domain controller, to add the requisite AD SRV records to the zone's database file on the DNS name server. Remember that these entries are static, though, and are based on the domain controller's configuration at the time that the machine was promoted to domain controller status.

Based on the results of your testing, you may find that running AD over your Unix-based DNS is a very viable option. If you decide to go down this path, however, be aware of the potential support concerns that I mentioned. In addition, since a different department may actually maintain DNS in your organization, remain sensitive to not overwhelming that department with a lot of postdeployment requests if AD's DNS requirements change. The last thing you want to do is start requesting frequent BIND version updates or DNS-configuration changes just to support AD requirements. If this could be a problem in your organization, you may want to consider one of the other two deployment options.

Windows on the Enterprise is a biweekly column that focuses on Windows 2000 technologies and on deployment and support strategies for enterprise environments.

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon