Professor Windows: Planning for Windows 2000 DNS, Part 1

  • Article

This is the first of a two-part series column on Windows 2000 Domain Name System (DNS). These two columns will focus on DNS planning, the implementation of DNS in a mixed environment, the security aspects of DNS, and give you some general tips related to DNS implementation in a Windows 2000 infrastructure.

When planning for DNS servers in your Windows 2000 network, you need several pieces of information. Among other things, you should know the type of servers you are running, the type of clients that need to be supported (e.g. Windows NT, Windows 9x, UNIX), the desired level of security, any possible integration with non-Microsoft DNS servers, and any requirements for using WINS for name resolution.

Active Directory and Windows 2000 DNS

Active Directory and DNS go hand in hand. DNS is required to configure Active Directory. Are you required to use Microsoft's DNS server to support Active Directory? The answer is no. Any DNS server supporting SRV records (RFC 2782) and dynamic DNS updates (RFC 2136) can be used to support Active Directory. However, using Windows 2000 DNS server has several advantages. You can integrate DNS in Active Directory, which provides a higher level of security and fault tolerance. Active Directory integrated zones allow you to configure secure dynamic updates, therefore reducing the risk of unauthorized updates to the DNS database. Windows 2000 protects resource records in Active Directory integrated zones by the use of a discretionary access control list (DACL). Every DNS name stored in the Active Directory is associated with its own ACL that specifies the permissions granted to the set of security principles (i.e. computer, users, groups) to perform specific operations with the DNS records created for that name. For example, by default it allows members of Authenticated Users group to create new DNS names in the zones stored in the Active Directory. Once the new name is created, the creator of the record (e.g. a computer that registered the new name), becomes an exclusive owner of the name and nobody except such creator and DNS and Active Directory domain administrators can modify/delete/create any records for this name. If you move an existing standard primary or a standard secondary zone into Active Directory, the zone file is copied from the local hard drive to the Active Directory, and then the file is deleted from the hard drive. The DNS data is stored in the Active Directory domain partition. The domain partition is replicated to all the domain controllers within a domain, so the DNS resource records are automatically copied to other domain controllers. DNS database updates replicated to the domain controllers are picked up by the DNS servers running on those domain controllers. There is no need for you to configure any zone transfers. Another advantage of Active Directory integrated zones is that you can modify the DNS records in such zone at any domain controller running DNS server because all domain controllers contain a writeable copy of the domain database.

Windows 2000 computers can dynamically register and update records with a DNS server that supports dynamic DNS update protocol (e.g. Windows 2000 DNS server). What about downlevel clients (such as Windows 9x or Windows NT) and non-Microsoft clients that can't register their resource records dynamically? For those clients, we can take advantage of a Windows 2000 DHCP server's ability to dynamically register DNS resource records.

Windows 2000 DNS servers include a feature called Scavenging. Dynamic updates automatically allow the addition of resource records to the database but sometimes these records are not deleted automatically. These "stale" records not only waste space on the DNS server, but the server in response to a client's query may use them. This can impact the performance of the server. The scavenging process, which is disabled by default, removes these stale records from the database. Scavenging can be configured on a per-zone, per-server, or per-record basis. Here are a couple of things to keep in mind. If there is a record that is not dynamically updated and you end up configuring it for scavenging, that record will be deleted if it is not refreshed periodically.

DNS Server Requirements to Support Active Directory

I mentioned earlier that, although recommended, you don't have to use Microsoft's DNS server to configure Active Directory. If you decide to use non-Microsoft DNS servers then there are two things you should consider:

  • Support for Service Location (SRV) records, as per RFC 2782
  • Support for dynamic updates

A Windows 2000 domain controller registers SRV records with the DNS server. When clients try to locate a domain controller, they query these SRV records. Therefore, support for SRV records is a must. Even though support for dynamic updates is not a requirement, since an administrator may add necessary DNS resource records, for all practical purposes (especially in a large enterprise) it is strongly recommended to leverage dynamic DNS updates.

Integration with BIND DNS Servers

BIND DNS 4.9.7 supports SRV records so it meets the minimum requirements for Active Directory support. However, BIND 8.2.1 and later support dynamic updates and incremental zone transfers, in addition to the SRV records. Based on the tests performed by various vendors and Microsoft, the recommended BIND version that proves to work best with Active Directory is BIND 8.2.2. Keep in mind that BIND DNS servers do not support Active Directory integrated zones. They are limited to primary and secondary zones. For networks that require secure updates, you may want to use Windows 2000 DNS servers. Initial deployment experience demonstrates that a few customers use alternate solutions. For example, you can configure an option in the named-conf configuration file to restrict possible sources of the updates. You may want to restrict the updates to certain IP addresses on your network. However, that won't prevent a computer with approved IP address from overwriting records in the DNS database. Another option is to restrict dynamic updates to only domain controllers and DHCP servers on your network, but since DHCP client requests sent to the DHCP server requesting DHCP server to perform dynamic DNS update are not authenticated, restricting possible sources of dynamic DNS updates to the IP address of the DHCP server does not really provide the secure dynamic update.

DNS Naming Considerations

Several DNS servers, including the Windows NT 4.0 DNS servers, support only limited set of characters in the DNS names, according to RFC 1034. According to RFC 1034, you can use upper case letters (A to Z), lowercase letters (a to z), 0-9 and hyphen (-) in your DNS labels. Each label is limited to 63 bytes. Labels are separated by dots. The total length of a fully qualified domain name (FQDN) must not exceed 255 bytes. Windows 2000 DNS servers support RFC 2181 (which updates RFC 1034) and supports wider set of characters in the names of the DNS records. Namely, in addition to the characters listed above, the Windows 2000 DNS servers support underscores and Unicode characters.

During your planning and migration, DNS character set limitations require special attention. NetBIOS names used in previous versions of Windows may contain additional characters that are illegal in DNS (namely, ~!@#$%^&;'.(){}, and not supported by any DNS server implementation) or characters (e.g. Unicode characters) that are supported by only a few DNS server implementations (e.g. Windows 2000 DNS servers). When a Windows NT 4.0 computer is upgraded to Windows 2000, its NetBIOS name is preserved and is used as the Computer Name (i.e. the first label in the computer full DNS name). If before an upgrade a computer NetBIOS name contained Unicode characters, then its A (host) record can be added to a DNS database if a DNS server supports Unicode characters (e.g. Windows 2000 DNS servers). If in your organization a large number of the computers have NetBIOS names containing Unicode characters, then you may want to make a DNS server supporting Unicode characters be authoritative for the A records of the computers, since it may not be very practical to rename a large number of computers. If before an upgrade a computer NetBIOS name contained illegal characters (from DNS perspective), then computer's A (host) record cannot be added to a DNS database. In this case you will have to rename the computers to register the A records corresponding to these computers.

Do I need WINS any more?

One question I hear a lot from people that are new to Windows 2000 is why do we have WINS in Windows 2000? Do we really need WINS any more? Assuming you don't have any NetBIOS applications that call the getname API, in a pure Windows 2000 network where all your clients are running Windows 2000, there is no need for WINS. In a mixed environment you may require WINS. Remember that computers running previous versions of Windows search for the Domain Controllers by querying WINS servers. Even if you have a mixed environment, you still don't necessarily need to configure Windows 2000 computers to use WINS for name resolution. Instead, to enable name resolution of the legacy Windows computers by Windows 2000 computers, you can simply configure Windows NT 4 or Windows 2000 DNS server to use WINS lookup feature. These DNS servers can query the WINS server and provide name resolution (IP address and NetBIOS names of WINS clients) to Windows 2000 clients. Some Microsoft management tools work best in a WINS-enabled environment so you may not be able to quite get rid of WINS just yet.

For more information on Windows 2000 DNS, check out:

Next month I will discuss integration of Active Directory services in your existing DNS hierarchy, planning of DNS zones, and cover issues related to zone transfers.

For any feedback on this column, please write to Microsoft TechNet

.