Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Active Directory Integration

In addition to the two RFC-compliant zone transfer methods, Windows Server 2003 DNS zone can be integrated into Active Directory. This eliminates the need for conventional zone transfers because Active Directory is replicated using its own multiple-master replication scheme.

Active Directory integration also makes it possible for any Windows Server 2003 or Windows 2000 domain controller that is running DNS to update the zone.

The DNS service requires very little overhead, so you can easily deploy DNS on every domain controller. In terms of performance, bandwidth utilization, and manageability, integrating DNS into Active Directory is a win. There are a few caveats, however:

• No ASCII zone files.
  Resource records are stored in Active Directory as objects. If you want a text file to use as a fallback, you can maintain at least one standard secondary name server. Windows Server 2003 and Windows 2000 DNS will provide zone updates to the secondary and the secondary can save these in a regular text file.




• Relies on Active Directory availability.
  Clients need DNS to find domain controllers. Hosting DNS on the same server that hosts Active Directory means you have multiple failures if the server goes down or is otherwise unavailable. You can minimize this risk by including at least two DNS servers in the TCP/IP configuration for the clients. Also, remember that the domain controller is also a DNS client, so make sure it points at itself for DNS lookups.




• A

  Windows

  DNS server must be the primary name server.
  This may cause discomfort for DNS administrators who currently run UNIX or NetWare DNS and are hesitant about cutting over to Windows.

Using Forwarders

WhenFunctional Description of DNS Query Handling."

There is an alternative to doing all that grunt work, and that is to check with another server that might have already done the grunt work first. This is called forwarding. The server being referenced by your DNS server is called a

forwarder . Figure 5.7 shows an example DNS configuration that incorporates forwarders.

The primary name server in the figure is configured to use a forwarder in two situations:

• When the server receives queries for hosts in the subsidiary.com zone, it forwards those queries to one or more name servers in the subsidiary.com DNS domain. This is called

  conditional forwarding and is a new feature in Windows Server 2003.




• When the server receives queries for hosts outside its own zone and not in subsidiary.com, it forwards those queries to a name server maintained by an ISP.

In the second case, if the primary name server also has a functional set of root hints for the Internet top-level domain servers, it waits a while and then sends a query to one of those servers as well. It's betting that the forwarder will come through with the requested record before it has to do an iterative walk through the Internet to find a name server for the requested domain.

A server configured to use a forwarder exclusively for out-of-zone lookups is called a

slave server . A slave server depends completely on its forwarder. If the forwarder cannot find the record, the slave sends a No Record response back to the client. A Windows Server 2003 or Windows 2000 DNS server can be made into a slave server by selecting the Do Not Use Recursion for This Domain option in the Forwarders configuration in the server properties window.

Conditional Forwarding

Windows Server 2003 introduces a new feature that simplifies integrating DNS with name servers in other domains. Rather than designating a single server to use as a forwarder, you can designate separate forwarders for individual domains. This is configured as part of the DNS server properties in the DNS console. Figure 5.8 shows the configuration.

Here's an example of how to use conditional forwarding. Let's say that you have an extranet connection to a vendor that is used for sharing database access and the occasional file transfer. The vendor's DNS domain name is vendor.com. The IP address of the vendor's DNS server is 192.168.0.30. Your clients have access to this server for purposes of submitting DNS queries.

You can configure conditional forwarding at your DNS server so that all requests for resource records in the vendor.com domain are sent to 192.168.0.30. Your DNS server sends an iterative request to the target DNS server and forwards the response back to the clients.

Stub Zones

Windows Server 2003 supports a special type of zone configuration called a

stub zone . A stub zone is used in place of delegation records when configuring a parent DNS server to send referrals to delegated DNS servers in a child domain.

A stub zone contains the SOA record and NS (Name Server) records for a child zone along with the A records (also called

glue records) corresponding to the name servers in the child zone. The stub zone server periodically updates its copy of the resource records. This simplifies delegation management.

Here's an example. Let's say you are the administrator of the company.com zone. You want to delegate the branch.company.com zone to another DNS server in your organization that is managed by another administrator.

Ordinarily, you would accomplish this by creating delegation records in the company.com zone that point at the name servers in branch.company.com. If the administrator responsible for branch.company.com adds or removes a name server, you would need to add and remove delegation records in company.com.

With stub zones, instead of creating delegation records, you create a stub zone on the company.com DNS server that points at branch.company.com. When you initially create the stub zone, it copies the SOA, NS, and glue records from the DNS server in branch.company.com.

When the company.com DNS server gets requests for resource records in branch.company.com, it uses name servers in the target domain to resolve the requests recursively. This speeds up subsequent requests because the stub zone server builds up a cache of resource records from the target zone.

If the administrator for branch.company.com adds or removes a name server, the stub zone on your DNS server picks up the changes automatically. This relieves you of the responsibility for manually updating your delegation records.

Deploying Windows DNS into an Existing Infrastructure

Many DNS administrators tend to be leery about trusting Windows DNS. If you currently use BIND or Lucent QIP or NetWare 5.x for your DNS services, you do not need to change to Windows Server 2003 simply to accommodate Active Directory. The non-Windows DNS server must support RFC 2052, "A DNS RR for Specifying the Location of Services (DNS SRV)." In addition, it should support RFC 2136, "Dynamic DNS."

As we'll see when we get to Active Directory design, Windows Server 2003 depends on DNS to provide the structure for the new generation of Windows domains. You may find it difficult to combine the namespace you want for Active Directory with your existing DNS namespace. You may need to create a separate namespace for Active Directory that is hosted on Windows DNS servers rather than BIND servers. Figure 5.9 shows an example of how such a split namespace can be achieved.

The example contains the following configuration features:

• The zone for the Active Directory domain is hosted on a Windows Server 2003 running DNS to take advantage of secure dynamic updates.




• The main corporate zone is hosted on a BIND server, which has a stub to the Windows zone rather than delegation records. UNIX clients in the organization obtain resource records from the Active Directory domain via referrals through the stub zone.




• The Windows Server 2003 running DNS uses the BIND server as a forwarder. This permits Windows clients to obtain resource records from the main corporate zone.




• The BIND server forwards out-of-zone traffic to a DNS server at an ISP. This permits both UNIX and Windows clients to resolve Internet names.




• The BIND server is configured as a slave to the ISP forwarder so that it does not use root hints to get records directly from the Internet TLDs. This minimizes traffic through the firewall.




• The ISP name server hosts the primary zone for the public corporate domain. This permits Internet users to resolve addresses for servers in the corporate DMZ without giving access through the firewall to the internal DNS server.

Most organizations use a hybrid of this basic configuration. For instance, an organization might want to maintain its own public DNS server in the DMZ. Or, the administrators might want the Windows DNS server to forward directly to the ISP name server and eliminate a potential single point of failure at the BIND server.

Whatever configuration you choose, if you use Windows DNS servers, make sure that Windows clients (this includes member servers and domain controllers) point at Windows DNS servers. This ensures that they see the SRV records they need to support access to vital domain controller services such as LDAP and Kerberos.

WINS Forwarding

While we're on the subject of forwarding, let's take a look at a form of forwarder that has been around since NT4 DNS.

Windows servers occupy a special place because they are both TCP/IP hosts with hierarchical host name and SMB-based servers with flat NetBIOS names. In the SMB world, the servers happily register their names and services with WINS with little or no administrative intervention. In the DNS world, someone must create records for the servers in the correct zone so non-Windows clients can find them.

Rather than maintain two databases, NT4 introduced a couple of proprietary resource records, the WINS record and the WINS-R record. These records pointed a Windows DNS server at one or more WINS servers. This enabled the server to forward DNS requests for Windows servers to WINS.

Dynamic Updates

ProperlyConfiguring DHCP to Support DNS," near the end of this chapter for details.

You can force dynamic registration at Windows Server 2003, XP, and Windows 2000 clients using IPCONFIG as follows:

ipconfig /registerdns

Certain stipulations apply when dynamically registering a resource record:

• When a client attempts to register a record that does not already exist, the DNS server adds the new record updates to the zone.




• If a record exists with a different name but the same IP address, the new record is added and the old record is left in place.




• If a record exists with the same host name but different IP address, the original record is overwritten with the new address value.

Although the primary DNS server has the only read/write copy of the zone file, the DNS client can be configured to point at any authoritative server for the zone. The secondary servers pass the DNS Update messages from the clients up to the primary master. The primary name server notifies its secondaries of the change, and the secondaries pull an incremental zone transfer.

If the client is configured to point at a non-authoritative server such as a caching-only server, the dynamic updates are not passed on to the authoritative server and the client is not registered.

Dynamic Updates and Domain Controllers

An Active Directory domain controller (Windows Server 2003 or Windows 2000) automatically registers its A and PTR records along with its service locator (SRV) records via the Netlogon service. The records are refreshed each time the service starts (usually at boot time) and hourly thereafter.

If you make a change to a domain controller and you want to update DNS immediately, stop and start the Netlogon service. The domain controller continues to perform Kerberos authentications with Netlogon turned off but downlevel clients (Windows 9x and NT) cannot authenticate.

If a domain controller cannot find its DNS server or the DNS server does not accept dynamic updates, you will see errors in the Event log. These errors are common in a BIND Domain Name System (DNS) infrastructure where dynamic updates have been disabled at the name server.

If you want to avoid Event log errors and a constant drone of invalid request traffic to your BIND servers, you can disable automatic SRV record renewal by making a Registry change:

You will also need to delete the Netlogon.dnb file from the C:\Windows\System32\Config folder. This file contains records for automatic updating.

You can also control automatic DNS updates from clients and domain controllers using group policies. It is still necessary to delete the Netlogon.dnb file manually.

Record Scavenging

DynamicConfiguring Scavenging" later in this chapter).

If a user goes on vacation for more than two weeks and leaves her machine off, the DNS registration for her A and PTR records will age out and periodic scavenging will remove them from the zone. This is not a catastrophe. The user does not lose any security privileges or functionality. When the user starts up the machine after coming back from vacation and logs on, the system will re-register with DNS and build a new resource record.

DNS Security

A primary goal of DNS design is security. DNS security has several facets:

• Limit the number of administrators who can make changes to the zone.




• Prevent exposing the contents of your zones to unauthorized individuals.




• Avoid potential abuse of the dynamic record registration mechanism.

Limit Administrative Access

You can control the security settings for accessing a DNS server. By default, Domain Admins, Enterprise Admins, DNS Admins, and the Administrators groups have full control. You can remove some of these groups to limit access to just members of the DNS Admins group or you can create another group for this purpose.

The DNS Admins group is created in Active Directory by default when you install DNS. The Administrator account is a member of the group. The group is given Full Control rights over any DNS server in the domain as well as Full Control rights over the DNS zone information in Active Directory for Active Directory Integrated zones.

If you define a separate group for DNS administration, be sure that you don't put the group in an OU where someone with administrator privileges can change the group membership. This defeats the purpose of the security group. Also remove the DNS Admins group from the access control list, because anyone with administrator rights in Active Directory can control the membership of this group.

When setting security configuration for a DNS server, be sure to leave the Authenticated Users group on the access control list with the special rights they are assigned by default. This permits DNS clients to read the contents of a DNS server.

Prevent Unauthorized Zone Transfers

DNSEnabling Zone Transfers and Update Notifications."

One consequence of locking down zone transfers is that you cannot use tools like Nslookup to view the contents of the zone file. This is because these tools use the same zone file transfer opcodes that a secondary server uses. This is not true for the DNSCMD utility that is installed when you install DNS on a server. If you have administrative privileges for a DNS server, you can use DNSCMD to dump the contents of a zone file.

Secure Dynamic Updates

One of the most important security measures you can take regarding dynamic updates is to control the computers that are permitted to register resource records. Without adequate controls, someone could accidentally or maliciously poison your zone file with false or misleading records. Or, they could stage a denial of service attack by registering thousands and thousands of bogus resource records.

The current Standards Track documents for controlling DNS Update security are RFC 2535, "Domain Name System Security Extensions," and RFC 2930, "Secret Key Establishment for DNS." These and other supporting RFCs combine to form the DNSSec documentation. Windows Server 2003 does not implement DNSSec transactions, but it does support the new resource record types involved in those transactions.

Windows Server 2003 permits you to restrict dynamic DNS Updates so that only authenticated computers in a domain can update their DNS information. To get this security, you must integrate the zone into Active Directory. A default group, DNS Admins, has read/write access to these DNS objects. Figure 5.10 shows an example access control list.

For instructions on configuring a secure update zone, see the "Managing Dynamic DNS" section later in this chapter.