Microsoft DNS Server Features

In addition to the above-mentioned options, the DNS service running on Windows 2000 or Windows.NET servers provides many other features; among them:

• Integration with other network services, such as WINS and DHCP. (For example, pre-Windows 2000 computers can neither register nor update their DNS names directly; they can perform that operation through WINS, which acts as an intermediary to DNS).

• Interoperability with third party DNS servers. (For example, the Windows .NET DNS development team has tested interoperability with the BIND DNS server version 4.9.7, 8.1.2, 8.2, and 9.1.0.)

• Support for secure dynamic updates that allows only domain-authenticated clients to re-register DNS names.

• Incremental zone transfers between DNS servers (zone transfers are only required for non-Active Directory-integrated zones).

• Support for Active Directory-integrated zones, i.e., zones that store their data in the directory. These zones can only be created on DNS servers running on domain controllers and, therefore, can benefit from Active Directory multi-master replication.

  The replication scope for a zone depends on the directory partition where it is stored. On Windows 2000 DNS Servers, a zone can only be stored in a domain partition that is replicated among domain controllers that belong to that domain. Even if you create a zone with the same name in another domain, there will be two different zones, which results in a big mess for the entire DNS infrastructure. If two DNS servers Belong to different domains, one server must be primary for the other one. On Windows .NET DNS Servers, the situation is simpler since these DNS servers can store their data in application directory partitions whose replication scope is defined by administrators (see details in the "Domain Management" section in Chapter 10, "Diagnosing and Maintaining Domain Controllers").

• Event logging and debug options.

As any typical DNS server, Microsoft DNS Servers can operate in the following modes:

• Caching sever — as a rule, a standalone DNS server that does not host any authoritative zones after its installation, and therefore only caches the clients' queries. A caching Windows .NET Server can also hold stub zones.

• Primary server — the server that hosts an updatable, authoritative zone(s) for some domain(s), i.e., it is permitted to resolve client queries. Resource records from such a server may be transferred to the secondary servers.

• Secondary server — the server that hosts a read-only replica(s) of zone(s) transferred from a primary (authoritative) server. However, if both the primary and secondary DNS servers hold an Active Directory-integrated zone(s), these servers can be regarded as peers that are able to accept updates. Active Directory integrated zones require a DNS server running on a Windows 2000-based domain controller.

Certainly, any DNS server can combine any of these modes; however, you need to thoroughly plan operation modes of all DNS servers in your network, as well as interoperations between these DNS servers and "external" servers, e.g., your ISP's DNS servers.

Two main tools that can be used for administering local and remote Microsoft DNS Servers are:

• The DNS snap-in (DNS console)

• The DnsCmd.exe command-line utility

New DNS Features in Windows .NET

In comparison to Windows 2000, the Windows .NET Server family offers a few new DNS related features that are implemented either in the system itself or in the Windows .NET DNS Server. Let us consider features that are the most important for administering both DNS servers and Active Directory domains:

• Enhanced domain joining procedures. When a client computer is added to a domain or a new domain controller is created in an existing or a new domain, the appropriate procedures verify the DNS infrastructure and explain possible failures and how to fix them.

• New group policies for managing DNS client settings on computers running Windows XP/.NET (look at the Computer Configuration | Administrative Templates | Network | DNS Client node of a Group Policy Object) and policies that control DNS registration of SRV records by domain controllers running Windows .NET.

• Active Directory-integrated zones that can be stored in application directory partitions. A DNS server installed on a domain controller running Windows .NET can use two built-in application directory partitions for storing DNS information. These partitions, ForestDnsZones.domainName and DomainDnsZones.domainName, are replicated to all DNS servers in the forest or in the domain, respectively. In addition, DNS server can store data in user created application partitions with their own replication scopes. In both cases, it is the administrator who defines the set of domain controllers that store application partition replicas. (Keep in mind that DNS data stored in application partitions is not replicated to Global Catalog.)

• Stub zones and conditional forwarding. Stub zones only contain resource records (of type SOA, NS, and A) that specify the authoritative DNS server(s) (primary and secondary) for the zone, and therefore simply redirect a client queries to the DNS server(s) that holds the authoritative zone and is able to resolve these requests. Look, for example, at Fig. 4.1. If there are DNS servers that are authoritative for the child domain (subdom.net.dom), you can convert the child zone into a stub zone; as a result, the root DNS server will remain aware of the DNS servers authoritative for the delegated child zone and will only cache the answers to queries for the child zone names.

  Conditional forwarders redirect client queries to other DNS servers depending on the domain name contained in these queries. Conditional forwarders can be useful, for example, when you establish trusts between different forests, which have their own DNS servers, and do not want to query the Internet DNS servers. To provide name resolving, you can specify the other side's DNS server as a conditional forwarder for foreign forest DNS names.