Linux to Windows Migration

Configuring Berkeley Internet Name Domain (BIND) to Support Active Directory

By Bob Carver

3 Leaf Solutions LLC
Abstract

This paper describes how the Microsoft Windows 2000 operating system and Active Directory use Domain Name System (DNS), including requirements for Active Directory support. Active Directory provides centralized accounting, security, and administration. It allows for centralized administration of computers, servers, and services (such as web server services). Active Directory management can be fully automated through script, allows for easy movement, or redistribution of data on servers or server farms, offers security policies which can be used to harden computers automatically, and speeds deployment of configuration changes to computers. Active Directory provides these advantages in any size infrastructure, allowing system administrators to manage more with less overhead.

Microsoft recommends using the DNS server provided with Windows 2000 to support Active Directory, and to provide all other DNS functionality. Many environments may have non-Microsoft DNS implementations in place, and may wish to implement Active Directory before migrating to Microsoft's DNS server. This paper discusses Active Directory DNS requirements, Service Locator records, Active Directory records stored in DNS, and interoperability issues that arise when Berkeley Internet Name Domain (BIND) DNS servers are used to support Active Directory. This document provides examples of BIND implementations, and describes the procedures for configuring BIND to support Active Directory and verifying that DNS records are correctly added to the zone database on a BIND server. This white paper does not cover DNS fundamentals or DNS infrastructure design.

On This Page

Introduction
How Windows 2000 Uses DNS
Active Directory and DNS
Configuring BIND to Support Active Directory
Summary
For More Information

Introduction

The Domain Name System (DNS) Server provided with Windows 2000 Server is an IETF standard-based DNS server that fully supports Active Directory and is fully interoperable with other standards-based implementations of DNS server, that offers excellent performance, easy installation and configuration, as well as graphical, and scriptable administration options. For these reasons, the Windows 2000 DNS server is recommended for supporting Windows 2000 networks and Active Directory. Many environments may have non-Microsoft DNS implementations in place, and may wish to implement Active Directory before migrating to Microsoft's DNS server. This white paper addresses requirements for configuring Berkeley Internet Name Domain (BIND) DNS servers to support Active Directory to facilitate such a migration, prior to migrating to Microsoft's DNS server.

Active Directory offers many features that reduce administrative overhead, and increase security. It is likely that system administrators will wish to implement Active Directory to take advantage of these features., the purpose of this document is to assist administrators who wish to use existing Berkeley Internet Name Domain (BIND) servers to support Active Directory. It covers interoperability issues between Active Directory and BIND, BIND configuration, and testing and verification of BIND support of Active Directory.

This paper assumes familiarity with DNS. It provides a quick overview of how Windows 2000 and Active Directory use DNS, the records stored by Active Directory in DNS, and minimum DNS requirements for support of Active Directory. This paper does not cover any DNS fundamentals; consult the Additional Reading section for a list of resources on this and other related topics.

Additional Reading

  • Designing the Active Directory Structure chapter in the Deployment Planning Guide

  • Active Directory papers

  • "DNS and BIND" (Cricket Liu) published by O'Reilly and Associates, 3rd Edition ISBN: 1-56592-512-2

How Windows 2000 Uses DNS

Host Name Resolution

Like any other Internet Protocol (IP) host, Windows 2000 uses DNS primarily for resolving Internet names to IP addresses (host name resolution), and resolving IP addresses to fully qualified domain names (reverse lookup).

Service Location

DNS is the primary name-resolution method used by Windows 2000 computers to locate services on the network, including locating domain controllers for logon. DNS in Windows 2000 replaces the service location functions provided by the WINS service. WINS was the Microsoft implementation of NetBIOS Name Service, which was used in earlier versions of Windows NT to locate domain controllers and other network services. (Down-level clients such as Windows NT 3.5 and 3.51, Windows NT 4.0, Windows 95, and Windows 98 still require WINS servers to locate network services.) Network services and domain controllers are advertised in DNS using Service Locator (SRV) records.

Service Locator (SRV) Records

Service Locator (SRV) resource records (defined in RFC 2782) allow multiple servers providing a similar TCP/IP-based service to be located using a single DNS query operation. These records enable you to maintain a list of servers for a well-known server port and transport protocol type, ordered by preference for a DNS domain name. For example; SRV records provide a means for Windows 2000 clients to locate domain controllers that use Lightweight Directory Access Protocol (LDAP) service over TCP port 389.

The purposes of each of the specialized fields used in an SRV resource record are as follows:

  • service A symbolic name for the desired service. For well-known services, a reserved universal symbolic name such as "_telnet" or "_smtp" is defined in RFC 1700. If a well-known service name is not defined in RFC 1700, a local or user-preferred name can be used instead. Some widely used TCP/IP services, notably the Post Office Protocol (POP), do not have a single universal symbolic name. If RFC 1700 assigns a name for a service indicated in this field, the RFC-defined name is the only name that is legal to use. Only locally defined services can be named locally.

  • protocol Indicates the transport protocol type. Typically, this is either TCP or UDP, although any transport protocol named in RFC 1700 can be used.

  • name The DNS domain name referred to by this resource record. The SRV resource record is unique among other DNS record types in that it is not used to perform the search or query.

  • priority Sets the preference for a host specified in the target field. DNS clients that query for SRV resource records attempt to contact the first reachable host of the lowest numbered preference listed here. Although target hosts have the same stated preference value, they can be tried in random order. The range of preference values is 0 to 65535.

  • weight Can be used in addition to preference to provide a load-balancing mechanism, where multiple servers are specified in the target field and are all set to the same level of preference. When selecting a target server host among those of equal preference, this value can be used to set an added level of preference that can be used to determine the exact order or balancing of selection for the target hosts used in an answered SRV query. When a non-zero value is used, servers of equal preference are tried in proportion to the weight of this value. The range of values is 1 to 65535. If load balancing is not needed, use a value of 0 in this field to make the record easier to read.

  • port This is the server port on the target host that provides the service indicated in the service field. The range of port numbers is 0 to 65535, although the number is often a well-known assigned service port number, as specified in RFC 1700. Unassigned ports can be used as needed.

  • target Specifies the DNS domain name of the host that provides the type of service being requested. For each host name used, a corresponding host address (A) resource record in the DNS namespace is required. A single period (.) can be used in this field to indicate authoritatively that the requested service specified in this SRV resource record is not available at this DNS domain name.

Service Locator (SRV) Record Examples

Syntax:

service.protocol.name

ttl class SRV preference weight port target

Example:

_ldap._tcp.ms-dcs

SRV 0 0 389 dc1.example.microsoft.com
SRV 10 0 389 dc2.example.microsoft.com

Active Directory and DNS

DNS Requirements to Support Active Directory

In order for a DNS server to be able to support the Active Directory it is required to support the SRV records so that domain controllers can be located for authentication and query purposes.

A Windows 2000 domain is represented by a DNS domain name (for example, nt.microsoft.com.). Each domain controller registers its address with DNS using the standard DNS dynamic update (these records may be added manually if the DNS server does not support dynamic updates). Each domain controller registers a host record (A record), and several SRV records.

For example, a domain controller named dc1 in the ad.mydom.com domain with an IP address of 4.2.2.3 would register the following records with DNS:

dc1.ad.mydom.com.

A

4.2.2.3

_ldap._tcp.ad.mydom.com.

SRV

0 0 389 dc1.ad.mydom.com.

_kerberos._tcp.ad.mydom.com.

SRV

0 0 88 dc1.ad.mydom.com.

_ldap._tcp.dc._msdcs.ad.mydom.com.

SRV

0 0 389 dc1.ad.mydom.com.

_kerberos._tcp.dc._msdcs.ad.mydom.com.

SRV

0 0 88 dc1.ad.mydom.com.

Other domain controllers in the same domain will register similar records in DNS.

Microsoft recommends that DNS servers supporting Active Directory also support dynamic updates, as described in RFC 2136. Support for dynamic updates is not strictly required for Active Directory to function. Active Directory related records may be manually added to the zone data supporting an Active Directory domain; however, this could be time consuming due to the number of records registered by each domain controller. When a domain controller is promoted, a file named NETLOGON.DNS is created in the %systemroot%\system32\config folder. This file contains all of the DNS entries the domain controller would register. This file can be used to aid in statically entering Active Directory DNS records.

BIND Versions That Support Active Directory Requirements

Version 8.2.2 patch 7 or later fully supports SRV records (RFC 2782), and Dynamic DNS (RFC 2136).

The versions here simply provide a minimum version that meets the requirements for supporting Active Directory. This recommendation does not take into account any patches or updates that should be applied to any version of BIND due to performance or security-related problems. For information on BIND versions, patches, and issues related to running BIND, see https://www.isc.org/

Function of Active Directory DNS Data

The variety of records registered by domain controllers advertise the different services offered by the domain controller, including:

  • Authentication services (Kerberos Key Distribution Centers (KDCs)).

  • LDAP and Global Catalog services, which allow clients to query domain controllers for information about objects in the Active Directory.

  • Active Directory site information, which allows clients to find local domain controllers to which they can submit queries or requests for authentication.

For example, the purpose for each of the example records is stated below:

dc1.ad.mydom.com.

A

4.2.2.3

Host record for the domain controller.

_ldap._tcp.ad.mydom.com.

SRV

0 0 389 dc1.ad.mydom.com.

Allows a client to find an LDAP server in the ad.mydom.com domain to submit queries to in order to find objects in the Active Directory. All Windows NT domain controllers in the ad.mydom.com domain will register this name.

_kerberos._tcp.ad.mydom.com.

SRV

0 0 88 dc1.ad.mydom.com.

Allows a client to locate a Kerberos KDC for the domain. All DCs domain controllers providing the Kerberos service (used for authentication and resource access) will register this name. All domain controllers running the Kerberos KDC service in the ad.mydom.com domain will register this name.

_ldap._tcp.dc._msdcs.ad.mydom.com.

SRV

0 0 389 dc1.ad.mydom.com.

Allows a client to find a domain controller in the ad.mydom.com domain. All Windows NT Ddomain controllers in ad.mydom.com will register this name.

_kerberos._tcp.dc._msdcs.ad.mydom.com.

SRV

0 0 88 dc1.ad.mydom.com.

Allows a client to find a domain controller running a Kerberos KDC for the domain named ad.mydom.com. All Windows NT domain controllers running the Kerberos service in the ad.mydom.com domain will register this name.

gc._msdcs.ad.mydom.com

SRV

0 0 3268 dc1.ad.mydom.com.

Allows a client to find any global catalog server in the Active Directory forest via a normal A record lookup. Global catalogs in the forest will register this record.

Domain controllers register a number of other records in DNS.

Configuring BIND to Support Active Directory

Assumptions

This section assumes familiarity with UNIX and Linux operating systems, file system navigation techniques, basic daemon configuration, daemon restart procedures, and the use of text editors.

Active Directory Interoperability Issues with BIND 8

As shown earlier, Active Directory records contain underscores. There is a prohibition on the use of underscore in hostnames (RFC 952, and 1123) and mail domains (RFC 821), but the use of underscores is not prohibited in domain names. Because underscores are allowed in domain namesand due to the number and complexity of the records required by Active DirectoryMicrosoft opted to use underscores in the domain name portion of the records to reduce the possibility of Active Directory data conflicting with existing DNS data.

By default, BIND 8 does not consider any record containing an underscore to be valid. BIND 8.x uses the check-names directive to restrict the character set of domain names in master files and/or DNS responses received from the network. Therefore, you must disable the check-names option to allow BIND 8.x to support Active Directory.

BIND 9

BIND 9x does not restrict the character set of domain names and does not implement the check-names option.

Determining BIND Version

You can use the NSLookup utility to determine the version of BIND that is running on a BIND DNS Server. To do so, use the following command:

nslookup q=txt class=CHAOS version.bind.0

Configuring BIND to Support Active Directory

To configure BIND to support Active Directory, you must configure the named.conf (configuration) file with information specific to the Active Directory you are supporting, create a zone file for the domain you are supporting, and then restart the NameD daemon.

Configuring NAMED.CONF

The named.conf file, normally located in the /etc directory, contains the configuration parameters for the BIND daemon and contains configuration information about all DNS zones that will be supported and serviced by BIND.

This white paper covers several BIND directives that are relevant to supporting Active Directory. They are:

  • Options specifies global server options and sets defaults for other statements.

  • Directory specifies the working directory of the server. Any non-absolute pathnames in the configuration file (e.g. the names of zone database files) will be taken as relative to this directory. The default location for most server output files (e.g. named.run) is this directory. If a directory is not specified, the working directory defaults to ".", the directory from which the server was started. The directory specified should be an absolute path.

  • Zone specifies the name of the zone, and IN specifies Internet types of addresses.

  • Type setting specifies this as a primary or secondary DNS server for the zone.

  • File specifies the name of the zone file (where the zone data will be stored) in the folder specified by the directory directive.

  • Allow-update specifies which host(s) are allowed to dynamically register records for this zone. Options for this directive include listing hosts by IP address or hostname, or listing entire subnets. Entries should be separated by a semicolon (;). All domain controllers should be allowed to update the zone so that Host and SRV records required to support Active Directory will be registered. You may wish to allow other clients and servers to register automatically. If not specified, allow-update defaults to deny. This directive can be placed in the Options section and made the default for all zones, or may be defined on a zone-by-zone basis.

  • Check-names turns off the check name feature in BIND 8 and allows the BIND DNS Server to accept domain names with underscores (_) used by Active Directory. This directive has three settings: warn, fail, and ignore. If the check-names directive is not specified, the default is set to warn. If check names is set to either warn or fail, updates and queries containing underscores will be rejected. This directive must be set to ignore in BIND 8 to support Active Directory.

There are many other directives that can be used to configure BIND which are beyond the scope of this white paper. For complete documentation on the BIND product, see https://www.isc.org/sw/BIND/

BIND 8 Abstract Zone Entry

The following is an abstract example of the zone entry in the named.conf file

Options { 
directory "<working directory name>";     
}; 
Zone "<DNS Name for the Active Directory Domain>" IN { 
type master; 
file "<file for this zone>"; 
allow-update { <address_match_list>; }; 
check-names ignore; 
};

BIND 8 Example Zone Entry

The following is a zone entry, that would support an Active Directory domain with the name of "ad.mydom.com". The type of zone is master (primary), the file where the zone data is stored is named "db.ad.mydom.com", located in the "/etc/namedb" directory. The computer with the IP address 4.2.2.3, and the computer with the hostname "dc2," are allowed to submit updates to the zone. The check-names directive is set to ignore (this allows the server to process requests and data that contain underscores).

Note: Entries preceded with "//" are comments, and are not directives processed by the server.

Options { 
directory "/etc/namedb";    //Working directory 
}; 
//Zone entry for my Active Directory domain ad.mydom.com. 
Zone "ad.mydom.com" IN { 
type master; 
file "db.ad.mydom.com"; 
allow-update { 4.2.2.3; dc2.; }; 
check-names ignore; 
};

BIND 9 Example

This file is identical to the BIND 8 example except that the check-names directive has been removed. BIND 9 does not restrict the character set of domain names and does not implement the check-names option.

Options { 
    directory "/etc/namedb";    //Working directory 
}; 
//Zone entry for my Active Directory domain ad.mydom.com. 
Zone "ad.mydom.com" IN { 
type master; 
file "db.ad.mydom.com"; 
allow-update { 4.2.2.3; dc2.; }; 
};

Finishing BIND Configuration

You must create a zone file to support the Active Directory zone in the directory specified by the directory directive, then restart the NameD daemon. At this point the BIND servers should be ready to receive updates for the Active Directory zone. You can now configure your domain controllers to use the BIND server as their primary DNS server.

Configuring Domain Controllers to Use BIND DNS Servers

To configure a domain controlleror any Windows 2000 or later clientto use a BIND server, all you need to do is specify the IP address of the BIND server as the preferred DNS server in the TCP/IP properties for the active network connection.

To do this:

  1. Right-click My Network Places, and then select Properties.

  2. Right-click the active network connection, and then select Properties.

  3. Select Internet Protocol (TCP/IP), and then click Properties

    Dd316373.cfgbin01_big(en-us,TechNet.10).gif

  4. Type the IP address of the BIND server in the Preferred DNS server box. (The graphic below assumes that the IP address of the BIND server is 4.2.2.15).

    Dd316373.cfgbin02_big(en-us,TechNet.10).gif

Forcing registration of DNS records

Once you have configured the preferred DNS server, you can force all DNS records to be reregistered with the new preferred DNS server two ways:

  1. Restart the NETLOGON service. This action can be performed from Control Panel/Administrative Tools/Services. This action will not disconnect any currently logged-on users but no new users will be able to connect while the service is down. Restarting the NETLOGON service usually takes less than a minute, and will immediately update the DNS zone database.

  2. Run IPCONFIG /REGISTERDNS from a command prompt. This will force the computer to reregister all DNS records with the preferred DNS server. IPCONFIG /REGISTERDNS does not register the records immediately. It can take up to 15 minutes for registrations to show up in the DNS zone database.

Testing and Verification

Using NSLookup utility, you can test that the BIND server is properly configured, accepting updates, and answering queries for the Active Directory domain. To test with NSLookup, use the following procedure:

  1. On your DNS server, start the NSLookup utility in interactive mode.

  2. Type set type=all, and then press Enter (this specifies that all record types may be returned).

  3. Type _ldap._tcp.dc._msdcs.domainname (where domainname is the name of your domain; do not forget to include leading underscores), and then press Enter.

NSLookup returns one or more SRV service location records in the following format:

hostname.domainname internet address = ipaddress

Where hostname is the host name of a domain controller, domainname is the domain to which the domain controller belongs, and ipaddress is the domain controller's IP address.

Validating Data in the Zone Database File

You can also edit the zone database files on the BIND server to see if the zone data has been added. All data files related to the zone will be in the working directory specified by the directory directive. Be aware that updates submitted through Dynamic DNS may not appear immediately in the zone file. BIND servers store dynamic updates temporarily in an IXFR (Incremental Zone Transfer) file. Updates are then added to the zone database file within a few minutes.

For example:

If the directory directive specifies a working directory of "/etc/namedb" and the zone entry specifies a file of "db.ad.mydom.com", the zone database file can be found at "/etc/namedb/db.ad.mydom.com". When updates are received, an IXFR file will be created in the working directory. This file will have the same name as the zone database file, but will have a ".ixfr" extension. Continuing with the example, an IXFR file for the ad.mydom.com com domain can be found at "/etc/namedb/db.ad.mydom.com.ixfr".

Summary

Microsoft recommends using the DNS Server provided with Windows 2000 to support Active Directory and Windows 2000 networks. The DNS Server provided with Windows 2000 Server is an IETF standard-based DNS server that fully supports Active Directory, and is fully interoperable with other standards-based implementations of DNS Sserver. However, if administrators wish to use existing BIND DNS servers to support Active Directory, they can do so.

Any DNS server that supports Active Directory must support SRV records (defined in RFC 2782), and it is strongly recommended that the DNS server also support Dynamic DNS (defined in RFC 2136).

To properly deploy BIND to support Active Directory, you must use BIND version 8.2.2 patch 7 or later. You must configure the named.conf file to include a zone statement defining the DNS name of the Active Directory domain, and specify the location of the database file for the zone. You must set the check-names directive to ignore (BIND 8 only), and you can configure the allow-update directive to allow domain controllers to register their DNS data through Dynamic DNS.

Once the BIND server is configured correctly and the NameD Daemon is restarted, Windows 2000 domain controllers, servers, and clients should have their TCP/IP properties configured with the IP address of the BIND DNS Server as their preferred DNS server. The Netlogon service can be restarted on any Windows 2000 client to force an immediate registration of DNS records with the BIND DNS Server.

For More Information

For the latest information on Windows 2000, check out our Web site at https://www.microsoft.com/windows2000

For more information on Windows 2000 Server and Active Directory see https://www.microsoft.com/technet/prodtechnol/windows2000serv/default.mspx

For more information on DNS requirements to support Active Directory, see https://www.microsoft.com