Name Resolution for Administrative Authority

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Microsoft Solutions Framework

Best Practices for Enterprise Security

Note: This white paper is one of a series. Best Practices for Enterprise Security (https://www.microsoft.com/technet/archive/security/bestprac/bpent/bpentsec.mspx) contains a complete list of all the articles in this series. See also the Security Entities Building Block Architecture (https://www.microsoft.com/technet/archive/security/bestprac/bpent/sec2/secentbb.mspx).

On This Page

The Focus of This Paper
Name Resolution Techniques
Windows 2000 Dynamic Update, WINS, and DHCP
Availability Planning for Windows 2000 Dynamic Update, WINS, and DHCP Servers
Security Planning for Windows 2000 Dynamic Update, WINS, and DHCP Services
Name Resolution Administration Best Practices
References

The Focus of This Paper

Name Resolution Components

The components involved in a name resolution process in a complex enterprise TCP/IP environment include:

• The Dynamic Host Configuration Protocol (DHCP) server, providing dynamic IP addresses to requesting clients and registering their A and/or PTR records in a (DNS) server that supports dynamic update.

• The client/server mechanism, resolving a name to a unique IP address or vice versa.

• The server(s), running a name resolution service and servicing the client's name resolution request.

• The server-to-server replication, increasing the availability of the name resolution service.

Figure 1: Windows 2000 name resolution security scenarios

In the context of a Microsoft Windows 2000 environment (refer to Figure 1) with or without earlier-version clients or servers (Microsoft Windows NT 4.x, 3.5x, Windows 9x, and so on), the scenarios that are interesting considering availability and security of the name resolution process are the following:

1. Security against IP address spoofing and name thefts

2. Windows 2000 dynamic update and DHCP security-related features

3. Availability of the DHCP server and name resolution (WINS and dynamic update) service

4. Security of the client-server traffic (considering DHCP, WINS, and dynamic update services)

5. Security of the server-to-server replication (DDNS and WINS replication) traffic

While item 1 is dealt with extensively in three background papers (Security Threats, Security Strategies, and Security Planning), this paper focuses on items 2–5 in greater detail, and provides best practice recommendations. Also, it is important to understand that this paper is not a detailed guide on how to configure a DNS/DHCP/WINS client/server architecture, but rather provides broad recommendations based on fundamental security concepts.

Why Read This Paper?

When planning information security, it is essential to plan for name resolution security, availability, and reliability, because this is a fundamental component for information access.

Hacker attacks generally involve someone who is very familiar with the target environment (the hardware, software, and security used) or knows how to gather such information. The general process preceding an attack may involve the following:

• Target the data or information to be stolen.

• Discover the systems that have the targeted data or information.

• Identify the security loophole to be leveraged for the process (hardware, software, and/or configuration).

• Actually perform the attack and get the data needed.

The first two steps in the process depend on name and address resolution. This shows the need to secure the processes of IP address allocation, name registration, name-to-IP-address propagation between servers, and name resolution.

Goals for Name Resolution Administration

In any given organization, goals are set at every level of IT management for projects and overall operations. Some of the high-level goals at the IT senior management level, operations administration level, and end-user level for the name resolution process are outlined below:

IT management goals

• Users can log on to their Windows 2000 domains from any location and receive their custom desktop and user configurations.

• Users can locate resources on the network without delays or problems.

• The system configuration lowers the total cost of ownership for the organization.

Operations administration goals

• IP address administration is easy to set up and manage.

• Name resolution services (dynamic update and WINS) are easy to set up and manage.

User goals

• Users can connect to the network (laptops and desktops) easily, and log on to the network from anywhere.

• Users can access resources on the network easily.

Name Resolution Techniques

Name resolution in Windows 2000 differs significantly from name resolution in Windows NT 4.0. In Windows NT 4.0, the resolver emphasized NetBIOS over DNS name resolution. In Windows 2000, however, the resolver emphasizes DNS over NetBIOS name resolution. The different name resolution techniques and the corresponding name resolution services are briefly explained in the following sections.

Host Name Resolution and DNS

A TCP/IP resource on a network is uniquely identified by its numerical IP address. Because people find it easier to remember names, IP addresses are paired with host names that are hierarchical and uniquely identify the host on a TCP/IP network. As computers use IP addresses to communicate with the destination device, the process of resolving host names to IP addresses using host files is handled by the Domain Name System (DNS).

DNS provides a distributed, replicated, hierarchical naming service, and helps in providing name-to-IP-address mapping in a TCP/IP network. These features provide for high availability and great scalability, which are the attributes that make DNS suitable as a key distributed service in a global network.

The DNS server comprises the server half of the DNS client/server mechanism. A DNS server stores information about the mapping of host names to IP addresses in the DNS database. The client portion of DNS, called a resolver, creates queries and sends them to a DNS server to resolve a host name to an IP address.

DNS is used throughout the Internet for host-name resolution and is a constantly evolving protocol. Along with host-name resolution, it helps in e-mail routing and other TCP/IP-based application services.

NetBIOS Name Resolution and WINS

In a NetBIOS networking world (Windows NT 4.x and earlier, Windows 9x, Windows for Workgroups, LAN Manager, and so forth) every network device is uniquely identified by a NetBIOS name that is a flat name and 16 bytes long.

WINS provides a distributed database for registering and querying a dynamic computer name (which is the same as the NetBIOS name) to IP address mapping in a routed internetwork environment. WINS is based on Request for Comments (RFC) 1001 (https://www.ietf.org/rfc/rfc1001.txt), "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods," and RFC 1002 (https://www.ietf.org/rfc/rfc1002.txt), "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications."

A WINS client/server system consists of the following:

• WINS server. Handles name registration requests from WINS clients and registers their names and IP addresses. The server also responds to name queries from WINS clients by returning the IP address of the name being queried (assuming the name is registered with the WINS server).

• WINS client. Registers and deregisters its name with the WINS server when it joins or leaves the network. Queries the WINS server for remote name resolution, handles browsing, and the like. The client software can run on any Microsoft-based network client (for example, Windows NT Workstation or Windows 95).

• (Optional) WINS proxy. Helps non-WINS-aware clients resolve names using WINS.

DHCP and IP Address Management

The Dynamic Host Configuration Protocol (DHCP) simplifies the management of IP address configuration by providing a standard for automating the process for DHCP-enabled network clients.

The DHCP service for Microsoft Windows 2000 Server is based on Internet Engineering Task Force (IETF) standards. DHCP specifications are defined in RFCs published by the IETF and other working groups. RFCs are an evolving series of reports, proposals for protocols, and protocol standards used by the Internet community. The following RFCs specify the core DHCP standards that Microsoft supports with its DHCP service:

• RFC 2131 (https://www.ietf.org/rfc/rfc2131.txt), "Dynamic Host Configuration Protocol" (obsoletes RFC 1541)

• RFC 2132 (https://www.ietf.org/rfc/rfc2132.txt), "DHCP Options and BOOTP Vendor Extensions"

Windows 2000 Dynamic Update, WINS, and DHCP

This section briefly describes some of the new features of Windows 2000 implementation of DNS dynamic update protocol, WINS, and DHCP that enhance the availability and security of the name resolution process. Later sections expand on some of the features related to security; for more detailed information on all these features, see Chapter 6, "Windows 2000 DNS," in the Windows 2000 Server Resource Kit TCP/IP Core Networking Guide.

Windows 2000 Dynamic Update Features

Windows 2000 provides the following features related to the DNS dynamic update protocol:

• Support for Microsoft Active Directory™ directory service as a locator service for domain controllers

• Integration with Active Directory

• Support for aging and scavenging of records

• Support for secure dynamic updates in Active Directory–integrated zones

• Improved ease of administration

• Administration from the command prompt

• Enhanced name resolution

• Enhanced caching and negative caching

• Interoperability with other DNS server implementations

• Integration with other network services

• Incremental zone transfer

• Support for new resource record types

Dynamic Update and Secure Dynamic Update

Windows 2000 supports both dynamic update, defined in RFC 2136 (https://www.ietf.org/rfc/rfc2136.txt), "Dynamic Updates in the Domain Name System (DNS UPDATE)," and secure dynamic update, defined in the IETF Internet Draft "GSS Algorithm for TSIG (GSS-TSIG)."

With dynamic update, clients can automatically send updates to the name server that is authoritative for the record they want to change. The authoritative name server then checks to make sure that certain prerequisites have been met. Prerequisites are resource records that must be present or absent before records can be updated. If the prerequisites have been met, the authoritative name server makes the change. The change can be adding records, deleting records, or modifying records.

Dynamic update provides the following benefits:

• Enables clients, including DHCP clients, to dynamically register A and PTR resource records with a primary server. This reduces the administrative resources needed to manually manage those records.

• Enables DHCP servers to register A and PTR resource records on behalf of DHCP clients. This reduces the time needed to manually manage those records and provides support for DHCP clients that cannot perform dynamic updates.

• Simplifies the setup of Active Directory by allowing domain controllers to be dynamically registered by using SRV records.

Secure dynamic update works like dynamic update, with the following exception:

The authoritative name server accepts updates only from clients and servers that are authorized to make dynamic updates to the DnsZone and DnsNode objects.

Secure dynamic update provides the following benefits:

• Protects zones and resource records from being modified by users without authorization

• Enables you to specify exactly which users and groups can modify zones and resource records

For more detail on the new Windows 2000 dynamic update features, please refer to the "References" section at the end of this paper.

Windows 2000 WINS Features

The new implementation of WINS for Windows 2000 provides the following enhancements:

• Persistent connections. Maintaining persistent connections between WINS servers optimizes replication.

• Manual tombstoning. You can manually mark a record for eventual deletion.

• Improved management utility. The WINS console is an MMC-based console providing greater flexibility and ease of use.

• Enhanced filtering and record searching. Improved filtering and new search functions simplify administration and maintenance.

• Dynamic record deletion and multi-select. Dynamic record deletion and multi-select helps in efficient management of the WINS database.

• Record verification and version number validation. This helps in checking the consistency of WINS servers in an organization, and thereby enhances the reliability of the name resolution process.

• Export function. Helps in exporting WINS database into a file, and importing it into other applications for analysis and reporting.

• Increased fault tolerance for clients. Windows 2000 or Windows 98 clients can now specify a maximum of 12 WINS servers per interface (up from the earlier limit of two).

• Read-only console access to the WINS console. WINS Setup automatically adds a special-purpose local users group, the WINS Users group, when WINS is installed. Users belonging to this local group have read-only access to the local WINS database via the WINS console.

Windows 2000 DHCP Features

The Windows 2000 DHCP service provides the following new features:

• Enhanced performance monitoring and server reporting capabilities.

• Expanded support for multicast scopes and superscopes.

• Support for user-specified and vendor-specified DHCP options. This allows the separation and distribution of options for clients with similar or special configuration needs.

• Integration of DHCP with DNS. A DHCP server can enable dynamic updates in the DNS namespace for any DHCP clients that support these updates.

• Unauthorized DHCP server detection. This prevents unauthorized DHCP servers from joining an existing DHCP network in which Windows 2000 Server and Active Directory are deployed. A DHCP server object is created in Active Directory, which lists the IP addresses of servers that are authorized to provide DHCP services to the network. When a DHCP server attempts to start on the network, the Active Directory is queried and the server computer's IP address is compared to the list of authorized DHCP servers. If a match is found, the server computer is authorized as a DHCP server and is allowed to complete the system startup. If a match is not found, the server is identified as unauthorized, and the DHCP service is automatically shut down.

• Dynamic support for BOOTP clients. Dynamic BOOTP is an extension of the BOOTP protocol that permits the DHCP server to configure BOOTP clients without having to use explicit fixed-address configuration.

• Read-only console access to DHCP information. DHCP Setup automatically adds a special-purpose local users group, called the DHCP Users group, when DHCP is installed. Users belonging to this local group have read-only access to the local DHCP database and information via the DHCP console.

Preventing Address Conflicts

DHCP components in Windows 2000 have both server-side and client-side IP address conflict detection to prevent duplicate IP addresses on your network. This adds to the reliability of the address allocation process

Server Conflict Detection

The DHCP server detects conflicts (if enabled through the DHCP console via the DHCP server property sheet) by pinging an IP address before offering that address to clients. If the ping is successful (a response is received from a computer, meaning a conflict exists), a conflict is registered and that address is not offered to clients requesting a lease from the server. The address is marked with a BAD_Address value in the active leases. The address remains as a BAD_Address, and can be deleted from the active leases after the conflict is resolved, or remains for the lease duration of the scope and is then returned to the available pool. The DHCP server pings only addresses that have not been previously leased.

The number of times the server tests an address for conflicts defaults to 0 (disabled). To change the value of this entry, use the DHCP console. Right-click the name of the server, click Properties, and then click the Advanced tab. For Conflict detection attempts, type a number greater than 0 (zero), and then click OK.

Client Conflict Detection

Windows 2000 or Windows NT client computers also check to determine if an address is already in use before completing the address configuration with the DHCP server, or when they have been configured with a static IP address. This is accomplished through the use of a gratuitous Address Resolution Protocol (ARP) request. When a Windows 2000 or Windows NT computer starts, a packet is broadcast on the network containing the computer's TCP/IP address to prevent the use of duplicate addresses on the same network.

If the client detects a conflict, it declines the DHCP offer from the DHCP server (by sending a DHCP decline message), begins the lease process again, and is offered the next available address in the scope. If the client was configured with a static IP address, then the interface is disabled, and an event (event ID 26) is generated in the event log. For additional details refer to the Microsoft Knowledge Base article 199773 (https://support.microsoft.com/default.aspx?scid=kb;en-us;199773&sd=tech), "Behavior of Gratuitous ARP in Windows NT 4.0"; also, Knowledge Base article 219374 (https://support.microsoft.com/default.aspx?scid=kb;en-us;219374&sd=tech), "How to Disable the Gratuitous ARP Function," describes the steps necessary to disable this feature on the client.

Availability Planning for Windows 2000 Dynamic Update, WINS, and DHCP Servers

DNS dynamic update and WINS services are highly available because of server-to-server replication of the data. DNS dynamic update servers can be made highly available by leveraging additional secondary dynamic update servers (considering the traditional primary-secondary DNS server model) or by having other domain controllers (DCs) running DNS service (for DNS integrated with Active Directory), and strategically placing them to optimize the query traffic and load. A Windows 2000 white paper discusses these concepts in greater detail; see Windows 2000 DNS at https://www.microsoft.com/WINDOWS2000/techinfo/howitworks/communications/nameadrmgmt/w2kdns.asp

WINS servers can be made highly available using a similar technique—placing additional WINS servers strategically within an organization's network environment. Additional information can be found in Chapter 7, "Windows Internet Name Service," in the Microsoft Windows 2000 Server Resource Kit TCP/IP Core Networking Guide.

Clustering DHCP Servers

While DNS dynamic update and WINS have availability built into the protocols through server-to-server replication, there is no such mechanism specified in the RFCs for replication between DHCP servers. This leads to the practice of network administrators splitting the DHCP scopes between DHCP servers; if one server goes down, a percentage (depending on the split percentage) of the available IP addresses remain available through the second DHCP server. Generally, an 80/20 based splitting of IP addresses between the primary and secondary DHCP servers is followed for a given scope. This practice is not possible in situations where the administrators are running short of addresses, thus leading to lesser availability of the DHCP servers.

In Windows 2000, the DHCP service is made cluster-aware to provide higher availability without having to split IP address scopes. Windows Clustering allows two servers to be managed as a single system. The Windows 2000 Cluster service can be used for DHCP servers to provide higher availability, easier manageability, and greater scalability.

Windows Clustering can automatically detect the failure of an application or server and quickly restart it on a surviving server, with users experiencing only a momentary pause in service.

Security Planning for Windows 2000 Dynamic Update, WINS, and DHCP Services

Windows 2000 DHCP Security

DHCP name resolution is vulnerable to security risks in the client-to-server traffic and in control of the DHCP servers themselves.

DHCP Client to Server Traffic Security

Enhancing the security of the DHCP client-to-server traffic prevents IP address spoofing and other malicious intermediary attack techniques.

• The DHCP client-to-server or server to client traffic is currently in plaintext, and a secure implementation is still in a discussion stage with in the IETF standards group. There are proposals to implement a process where the client, server, and relay agent identify each other in the DHCP process through an authentication mechanism, and thereby avoid IP spoofing or intermediary attacks. For more information, see:

  • Institute of Electrical and Electronic Engineers (IEEE) standard 802.1x (https://grouper.ieee.org/groups/802/1/pages/802.1x.html), "Port Based Network Access Control."

  • The IETF Internet Draft "DHCP Relay Agent Information Option." (https://www.ietf.org/rfc/rfc3046.txt)

DHCP Server Security

Windows 2000 implements a limited form of DHCP server side security by preventing unauthorized workgroup DHCP servers from being brought up on the network and causing IP address allocation problems. This is applicable for all Windows 2000 DHCP servers, and does not apply to DHCP service running on Windows NT servers. The DHCP server authorization requires enterprise administrative privileges, but this authority can be delegated to other administrators.

• For information on how this feature is implemented, see Chapter 4, "Dynamic Host Configuration Protocol," in the Microsoft Windows 2000 Server Resource Kit TCP/IP Core Networking Guide.

• The authorization of a Windows 2000 DHCP server can be accomplished through the DHCP console by right-clicking the DHCP server in the console, and then clicking Authorize to automatically authorize the DHCP server.

• The process of delegating the privilege of authorizing a DHCP server in a Windows 2000 enterprise is described in Windows 2000 Server Help in the following location:

  Networking / DHCP / How To / Manage Server Access / Delegate ability to authorize DHCP servers to a non-enterprise administrator, or on the Web at https://www.microsoft.com/windows2000/en/server/help/sag_DHCP_pro_DelegateNonEnterpriseAuthority.htm

Windows 2000 DNS Dynamic Update Security

An issue with dynamically modifying data in DNS is security. A DNS server that adds the zone data statically has implicit security, since an administrator has the only access to modify the zone data. Dynamic modifications of zone data by DNS clients pose a potential security problem in determining whether the DNS client is authorized to modify the data. Windows 2000 provides secured update capability for Active Directory–integrated zones.

DNS Dynamic Update Process

By default, the dynamic update client automatically registers name–to–IP address mappings in the DNS; however, one can configure the client not to register its name and IP address in the DNS (by modifying the connection's DNS properties in Control Panel / Network / Connection Properties / TCP/IP Properties / Advanced / DNS tab), and instead allow the Windows 2000 DHCP server to register the clients' resource records in the DNS. This is very useful in the case of earlier version clients (Windows 9x, Windows NT) that are not dynamic update–aware. The responsibility of registering the A and PTR resource records is negotiated between the DHCP client and the DHCP server during the DHCP process.

Dynamic updates can be sent by many services such as the DHCP client, the DHCP server, Netlogon, Cluster service, and so on. This section focuses mainly on dynamic updates performed by the DHCP client and server.

In Windows 2000, clients can send dynamic DNS updates for three different types of network adapters: DHCP adapters, statically configured adapters, and remote access adapters. Regardless of the adapter used, the DHCP client service sends dynamic updates to the authoritative DNS server. The DHCP client service runs on all computers regardless of whether they are configured as DHCP clients.

Any primary zone can be configured for dynamic update; however, only Active Directory–integrated zones can be configured for secure dynamic update.

By default, the dynamic update client attempts a dynamic update first, and if it fails, it negotiates a secure dynamic update.

Setting the following registry entry can change this behavior:

Add the UpdateSecurityLevel registry entry to the following subkey:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters

The value of UpdateSecurityLevel can be set to the decimal values 0, 16, or 256, which configure security as follows:

256.	Specifies the use of secure dynamic update only.
16.	Specifies the use of insecure dynamic update only.
0.	Specifies the use of secure dynamic update when an insecure dynamic update is refused. This is the default value.

DNS Secure Dynamic Update Process

Windows 2000 supports secure dynamic updates through the Generic Security Service Application Programming Interface (GSS-API, specified in RFC 2078 (https://www.ietf.org/rfc/rfc2078.txt) rather than DNS Security Extensions (RFC 2535) or Secure DNS Dynamic Update (RFC 2137).

For a list of RFCs supported by Windows 2000 DNS dynamic update, see Chapter 5, "Introduction to DNS," in the Microsoft Windows 2000 Server Resource Kit TCP/IP Core Networking Guide.

The GSS-API provides security services independently of the underlying security mechanism. It specifies a way to establish a security context by passing security tokens:

• The client generates the initial token and sends it to the server.

• The server processes the token and, if necessary, returns a subsequent token to the client.

• The process repeats until negotiation is complete and a security context has been established. The security context has a finite lifetime during which it can be used to create and verify the transaction signature on messages between the two parties. The lifetime depends on the protocol being used; for Kerberos V5 (used in Windows 2000), the lifetime is equal to the maximum service ticket lifetime (any time greater than 10 minutes and less than the maximum user ticket lifetime; the default is 10 hours).

For additional details, refer to the RFC 2078 (https://www.ietf.org/rfc/rfc2078.txt), "Generic Security Service Application Program Interface, Version 2."

Windows 2000 implements the GSS-API using an algorithm specified in the IETF Internet Draft "GSS Algorithm for TSIG (GSS-TSIG)." This algorithm uses the Kerberos V5 authentication protocol as its underlying security mechanism. The algorithm uses the following resource records to provide security services:

• TKEY. A resource record specified in the IETF Internet Draft "Secret Key Establishment for DNS (TKEY RR)" as the vehicle to transfer security tokens between the client and the server and to establish secret keys to use with the TSIG resource record.

• TSIG. A resource record specified in the IETF Internet Draft "Secret Key Transaction Signatures for DNS (TSIG)" to send and verify signature-protected messages.

Secured Dynamic Update for Legacy Clients

Older DHCP clients (Windows 9x, Windows NT 3.x and 4.x) that do not support the FQDN option are not capable of dynamic updates. Therefore, if you want their A and PTR resource records dynamically registered in DNS, you can configure the Windows 2000–based DHCP server to perform dynamic updates on their behalf.

Considerations

If a DHCP server performs a secure dynamic update on a name, the DHCP server becomes the owner of that name, and only that DHCP server can update the name. This can cause problems in some scenarios, and requires careful consideration:

• For example, suppose that the DHCP server DHCP1 creates an object for the name client1.microsoft.com and then goes offline, and the backup DHCP server, DHCP2, tries to update the name; DHCP2 is not able to update the name because it does not own the name.

• In another example, suppose DHCP1 adds an object for the name client1.microsoft.com, and then the administrator upgrades client1 to a Windows 2000–based computer; the new Windows 2000–based computer is not able to update its own name because it is not the owner of the name registration.

Therefore, if you have enabled secure dynamic update to be performed by DHCP servers, it is recommended to place any DHCP server that will perform dynamic updates in a special Windows 2000 global group called DNSUpdateProxy. Objects created by members of the DNSUpdateProxy group have no security; therefore, any authenticated user can take ownership of the objects. It is important to note that if the DHCP server is running on a DC, then any authenticated user can take ownership of the records registered by the services running on the DC; this is not a recommended configuration.

DNS Client Resolver Security

By default, the DNS resolver (client portion of the DNS client/server components) accepts responses from the DNS servers that it did not query for resolving a name; this default setting speeds up performance, but can be a security risk because unauthorized DNS servers on the network can confuse the clients with incorrect resolutions and/or compromise security.

Reserving Names

You can reserve fully qualified domain names (FQDNs) so that only certain computers can use them. To do so, create the FQDN in the DNS console, and then modify its discretionary access control list (DACL) so that only particular computers or users can change the set of records associated with the FQDN. This is helpful in preventing server DNS name thefts for a few important servers within an organization while they are offline.

Resolving Name Conflicts

If during dynamic update registration a client determines that its name is already registered in the DNS with an IP address that belongs to another computer, by default the client attempts to replace the registration of the other computer's IP address with the new IP address. This means that for zones that are not configured for secure dynamic update, any user on the network can modify the IP address registration of any client computer. For zones that are configured for secure dynamic update, however, only authorized users are able to modify the resource record.

You can change the default setting so that instead of replacing the IP address, the client backs out of the registration process and logs the error in Event Viewer. To do so, add the DisableReplaceAddressesInConflicts entry with a value of 1 (DWORD) to the following registry subkey:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters

The entry can be 1 or 0, which specifies one of the following:

1.	If the name that the client is trying to create already exists, the client does not try to overwrite it.
0.	If the name that the client is trying to create already exists, the client tries to overwrite it. This is the default value.

So, it is very important to note that by default, if the secure DNS update is not being used, the last client update wins. This is necessary to take care of the common scenario where a client can acquire a new IP address and would like to register the same. So, this can be a potential security issue because it leads to spoofing and other hacking attacks. This implies that for greater name registration and resolution security, it is highly desirable to use secure DNS dynamic update.

Controlling Update Access to Zones

With secure dynamic update, only the computers and users you specify in an ACL can create or modify DnsNode objects within the zone. By default, the ACL gives create permission to all members of the Authenticated Users group, the group of all authenticated computers and users in an Active Directory forest. This means that any authenticated user or computer can create a new object in the zone.

Also by default, the creator owns the new object and is given full control of it.

You can view and change the permissions for all DNS objects on the Security tab for the object, from within the Active Directory Users and Computers console, or through the properties of zone and resource record in the DNS console.

Securing Zone Transfer Traffic Between DNS Dynamic Update Servers

Because Windows 2000 allows secured dynamic updates of DNS objects for zones integrated with Active Directory, the replication of the zone data in this scenario happens automatically to all other DCs in the domain through replication. Also, Active Directory replication uses remote procedure call (RPC) protocol, and the data is encrypted using either a 56-bit (international) or 128-bit (within North America) key. For Windows 2000 Active Directory replication (between DCs in a domain or between domains), authentication is accomplished through Kerberos V5 for RPC-based replication.

Traditional zone transfers from Windows 2000 DNS servers to other third-party DNS servers, or between Windows 2000 DNS servers without Active Directory–integrated zones, are not secure.

Name Resolution Administration Best Practices

DNS Dynamic Update

• DNS Namespace: Your organization must have a DNS name assigned by the Internet naming authority for your organization to be present on the Internet. Considering security, ease of setup, and management, many organizations use a subdomain off of their organization's public domain name as the Windows 2000 root domain. For example, if microsoft.com were the root DNS name assigned to a company, then they could use corp.microsoft.com as the Windows 2000 root domain. Also, some organizations use separate namespaces for their public Internet and private intranet. The configuration of the clients and servers depends on the above choice; for further information, see Chapter 6, "Windows 2000 DNS," in the Microsoft Windows 2000 Server Resource Kit TCP/IP Core Networking Guide.

• If you are using Active Directory, use directory-integrated storage for your zones. It provides many benefits, such as secured dynamic DNS updates, multimaster update capability, and Active Directory–based secure DNS server-to-server replication.

• Considering redundancy and availability, it is recommended to have at least two DNS servers hosting each zone. Each server can host either primary and secondary copies of the zone, or two Active Directory–integrated copies of each zone. Also, it is important to understand that while using DNS zones without Active Directory integration, the primary DNS server for a given zone has to be available for any dynamic updates.

• In a Windows 2000–only environment, it is suggested to implement a client configuration change forcing clients to try secure dynamic update only.

• It is recommended to tighten the security on the DNS zones by modifying the discretionary access control list (DACL) to give permission to users and computers that really need to have create or modify privileges as opposed to the default DACL settings, which provide full access to all authenticated users

• If it is necessary to further enhance security at the cost of a small performance hit on a Windows 2000 client computer, then the client's DNS resolver security can be enabled. This will ensure that the client accepts query response packets only from the DNS servers the client queried during a name resolution

  The IETF has published several RFCs that cover best practices for DNS, as recommended by DNS architects and planners for the Internet. You might find the following RFCs useful, especially if you are planning a large DNS design:

  • RFC 1912 (https://www.ietf.org/rfc/rfc1912.txt), "Common DNS Operational and Configuration Errors"

  • RFC 2182 (https://www.ietf.org/rfc/rfc2182.txt), "Selection and Operation of Secondary DNS Servers"

  • RFC 2219 (https://www.ietf.org/rfc/rfc2219.txt), "Use of DNS Aliases for Network Services"

DHCP

• Considering availability, it is recommended to split the IP address scopes between the primary and secondary DHCP servers using the 80/20 rule (explained in Chapter 4, "Dynamic Host Configuration Protocol," in the Microsoft Windows 2000 Server Resource Kit TCP/IP Core Networking Guide). If there is a shortage of available addresses, consider running DHCP on a clustered Windows 2000 server for enhancing the availability.

• It is very useful to use at least one side (server or client) of the IP address conflict detection mechanism. If your environment consists predominantly of Windows 2000 Professional computers, then client-based conflict detection will be efficient; otherwise, the server-based mechanism can be used.

• In a mixed environment consisting of Windows 2000 and earlier version clients (Windows 9x, Windows NT), if the DHCP servers are configured to register the clients' DNS resource records on their behalf, it is recommended to not implement the DHCP services on a domain controller in the domain.

References

For further information on implementing specific configurations discussed in this paper, please refer to the following.

Albitz, Paul, and Cricket Liu. DNS and BIND. Sebastopol, CA: O'Reilly & Associates, 1998.

Microsoft Corp. Microsoft Windows 2000 Server Resource Kit Distributed Systems Guide. Redmond, WA: Microsoft Press, 2000.

Microsoft Corp. Microsoft Windows 2000 Server Resource Kit TCP/IP Core Networking Guide. Redmond, WA: Microsoft Press, 2000.