Designing DNS for Active Directory Security
The successful operation of Active Directory depends on the successful operation of the Domain Name System (DNS). After your organization has designed its forest and domain plan, you must design the DNS infrastructure to support Active Directory. DNS provides three crucial functions for Active Directory in Windows 2000:
DNS resolves host names to IP addresses and vice versa. DNS is the default location mechanism in Windows 2000.
Windows 2000 and Windows XP computers use DNS to locate services (represented by SRV records) such as the Global Catalog and Kerberos Key Distribution Centers, as well as domain controllers, domains, and site information.
DNS establishes the namespace used to define Active Directory.
You do not have to use a Windows 2000 DNS server to support an Active Directory implementation. At minimum, the DNS server that you use must support the use of SRV records. Microsoft also strongly recommends that your DNS server support incremental zone transfers (IXFRs) and dynamic updates. Window 2000 DNS provides all these features.
Several common designs for DNS support Active Directory. Each of these models has security benefits and drawbacks, and other valid designs are possible. These are the common designs:
Single namespace
Delegated namespace
Internal namespace
Segmented namespace
Regardless of which DNS model you adopt for Active Directory, you must ensure the security of the DNS server and services because the compromise of DNS services can lead to a denial-of-service attack or the disclosure of information. An attacker or rogue administrator could compromise your DNS server and erase Service resource records (also known as SRV records), causing Active Directory replication to fail and client logons to be rejected. An attacker or rogue administrator could also change SRV record information to redirect replication and logon traffic to illegitimate servers to retrieve information from the packets. This process is known as DNS poisoning.
See Chapter 15, Implementing Security for DNS Servers, for in-depth information on how to secure Windows 2000 DNS Servers.
Single Namespace
In a single namespace Active Directory, SRV records are intermingled with all the other resource records for your organization. Although this is the simplest design, you risk the external exposure of your namespace and SRV records, which could prove useful to an attacker. Also, a single namespace will require a potentially complex set of permissions to update and manage the DNS zone information.
Delegated Namespace
In a delegated namespace, a subzone of your public namespace is delegated to support Active Directory. This allows you to segregate your Active Directory SRV records from your publicly available records, such as your Web presence. This design also enables your Active Directory administrators to manage a specific portion of DNS, while the current DNS administrators can continue to maintain their portion of DNS.
Internal Namespace
You might want to use an internal namespace for Active Directory. For example, you can create a DNS namespace for Active Directory named woodgrovebank.corp. Although using a nonpublic domain can add security to your Active Directory installation and alleviates any concerns over who would manage the portion of DNS that supports Active Directory, this DNS design can hamper the scalability of Active Directory. Alternatively, you might want to register a public DNS namespace and only use it internally for Active Directory.
Segmented Namespace
You might want to use the same namespace for Active Directory as you use for your public presence but not use the same DNS infrastructure. For example, your organization s ISP could host your public DNS namespace, but you could host a parallel namespace internally to support Active Directory. If you choose this configuration, you can isolate your Active Directory DNS infrastructure, while preserving the possibility of public scalability for later. If you select this DNS design, you more than likely will have to manually replicate some entries from your public DNS infrastructure to your internal DNS infrastructure.
Active Directory Integrated Zones and Security
In addition to standard primary and secondary zones, Windows 2000 supports Active Directory integrated zones. Active Directory integrated zones improve on the security of standard zones by doing the following:In Windows 2000, primary zones have a Boolean dynamic update permission the zone either accepts or denies dynamic updates. Active Directory integrated zones add a third option: to allow only secure dynamic updates. If you choose this option, when a computer attempts to update or create a resource record in DNS, the DNS server will forward the attempt to Active Directory. There, the change will be compared to the discretionary access control list (DACL) on the zone object and to the resource record, if it exists. The change will occur only if the computer has the necessary permissions.
Because resource records are stored as objects in Active Directory objects, security on those objects can be configured as your organization requires.
In a default standard zone transfer, records are sent as clear text, which means that securing the connection between DNS servers for zone transfers requires additional configuration. However, when DNS zones are stored as Active Directory integrated objects, Active Directory replication is used to facilitate the transfer of zone updates. This replication is automatically encrypted by using remote procedure call (RPC) encryption without additional configuration.
Active Directory integrated zones can be hosted only on DNS servers that are also domain controllers. Thus, Active Directory integrated zones are appropriate only for internal use or for use in an isolated forest with exposure to public networks, as is common with perimeter network (also known as DMZ, demilitarized zone, and screened subnet) Active Directory installations.