DNS/DHCP Interaction As is the case with Windows 2000, Windows Server 2003 supports the DDNS standard (RFC 2136) to dynamically update both forward and reverse lookup zones with A and PTR RRs, respectively. (A forward lookup zone resolves host names to IP addresses; a reverse lookup zone resolves IP addresses to host names.) DDNS reduces much of the administrative burden in managing a zone files in a DNS infrastructure. In particular, DDNS makes it possible for AD domain controllers to create and update the SRV RRs that are fundamental to the proper operation of AD. DDNS is also used in combination with DHCP to ensure that DHCP clients will have the appropriate records registered for them in DNS and the DNS records are updated whenever IP addresses change or DHCP leases expire. Both clients and DHCP servers are capable of updating the zone records. However, only clients that are running Windows 2000, Windows XP, or Windows Server 2003 operating systems are capable of directly updating DNS zones.This is the default configuration for these clients and can be disabled on the DNS tab of the Advanced property page for TCP/IP. Usually, DHCP clients will update their own A records in the forward lookup zone, but the DHCP servers will update the PTR record in the reverse lookup zone (the computer “owns” the host name, but the DHCP server “owns” the IP address). Clients with manually configured IP addresses will always try to register both an A and a PTR record. Other level clients, such as Windows 9x and Windows NT 4, must rely on DHCP servers to update both A and PTR RRs on their behalf. DHCP clients that are capable of dynamically updating DNS records use the DHCP client option 81 to provide the FQDN, as specified by the full computer name in the properties of the My Computer object, and instructions for the DHCP server to handle DDNS registration. (This is configured on the DNS tab of the Advanced property page for TCP/IP of the client computer.) The client’s FQDN is used to register the name with the appropriate DNS server that is authorita- tive for the zone. Other level clients will be registered with DNS servers that are authoritative for the domain name configured for the DHCP scope. A DHCP server will do the following, depending on its configuration: ■ Update the A and PTR records, if requested by the client. ■ Always update the A and PTR records, regardless of the client request. A DHCP server will, by default, attempt to update A and PTR records if requested by the client. Figure 20.8 shows the default configuration for the DHCP server on the properties page for the DHCP server in the DHCP console. A similar property page exists for the DHCP scope. 686 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 686 To configure the DHCP server to update DNS records, regardless of the client request, you can select the radio button labeled Always dynamically update DNS A and PTR records. If you wish to configure DHCP to perform DNS updates on behalf of legacy clients, you can select the check box labeled Dynamically update DNS A and PTR records for DHCP clients that do not request updates (for example, clients running Windows NT 4.0). By default, the DHCP server is configured to remove both the A and the PTR records from the DNS zone.You can change this behavior by clearing the box labeled Discard A and PTR records when lease is deleted. When you clear this box, the DHCP will attempt to remove the PTR record when the lease expires. Security Considerations for DDNS and DHCP Implementing DDNS creates some security risks in that unauthorized computers and users might be able to update DNS records. In the case of public Web servers, the consequences of the unautho- rized registration of a rogue Web server IP address to replace a valid one can be very significant indeed. For this reason, it is not a good idea to enable DDNS on any zones that are used to resolve names for your Internet-facing servers. To mitigate the risk of unauthorized updates, you can require the use of secure dynamic updates. However, the option to use secure dynamic updates is available only if you are using Active Directory-integrated zones. When you enable this option, you are able to control which computers, users, or groups are able to modify RRs in the zone. For this reason alone, you should consider the using DDNS only if you are using Active Directory-integrated zones. If you have enabled secure updates, there is a potential for problems caused by the ownership of records. When a DNS client or a DHCP server updates a zone file with an RR, it becomes the owner of that record. Normally, this does not create a problem. However, in some circumstances, the ownership of an RR can prevent a valid update to it. Consider the case of a client that is upgraded to Windows XP. After the upgrade, it attempts to update the RR in the zone.The attempt will fail, because the record is owned by the DHCP server that originally created the record on the client’s Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 687 Figure 20.8 Default DHCP Configuration for Dynamic DNS Updates 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 687 behalf. Or, consider the case where a different DHCP server, other than the original one, tries to register an update on the client’s behalf. Again, the attempt will fail.To resolve this problem, you can use a special security group called DnsUpdateProxy. DnsUpdateProxy Group Any objects that are created by members of the DnsUpdateProxy group have no security and are ownerless. Consequently, the first authenticated computer that updates the record is able to take ownership of the object.Therefore, if you enable secure dynamic updates only, you should place all DHCP servers in this group before they start registering names. The DnsUpdateProxy group can create a security risk, however, if the DHCP server is installed on a domain controller. If the DHCP server that is a member of the DnsUpdateProxy group is installed on a domain controller, all the SRV, the A records for domain controller on which DHCP is installed, and other critical records created by the domain controller for AD functionality will be ownerless, allowing the first authenticated user who tries to update them to become the owner. For this reason, you should not install a DHCP server on a domain controller if you are using the DnsUpdateProxy group. If, for whatever reason, you do need to install DHCP on a domain controller, or if DHCP is updating A records for clients in forward lookup zones, you should configure your DHCP server(s) to use DNS dynamic update credentials.To do this, you configure a security principal (a user account in this case) for use by all your DHCP servers when they update a DNS zone.You then configure your DHCP servers to use this account for dynamic updates. (This is a new feature of Windows Server 2003 and is not available on Windows 2000.) This obviates the problems arising from ownerless records created by DHCP servers in the DnsUpdateProxy group. In particular, enabling this configuration prevents a DHCP server from using the elevated permissions it inherits by virtue of its being installed on a domain controller. Figure 20.9 shows the Advanced tab on the DHCP server property page where you configure credentials for dynamic updates. 688 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy Figure 20.9 Configuring Credentials for DHCP Updates to Dynamic Zones 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 688 Aging and Scavenging of DNS Records When you enable zones for dynamic updates, it is possible that the zone data files will acquire, over time, a large number of superfluous and outdated records that might have a negative effect on DNS performance. For example, if you retire a user’s workstation and disconnect it from the network, the RRs for that computer might remain in the DNS data.To help ensure the integrity and currency of DNS data, you can enable aging and scavenging of outdated DNS records. (By default, the aging and scavenging option is not enabled.) Aging and scavenging can be set on a per-zone or per-DNS server basis. Per-zone settings over- ride per-DNS server settings. Figure 20.10 shows the server-wide aging and scavenging property page. The No-refresh interval setting is the amount of time that must elapse before a DNS client or DHCP server can refresh a timestamp for a record. When a DNS client creates a record, it is assigned a timestamp.The DNS client attempts to refresh this record every 24 hours. Unless the record is changed (for example, the client receives a new IP address), the timestamp cannot be refreshed for a default period of seven days. After the seven days have elapsed, the DNS client can refresh the timestamp, which starts the timer on the no-refresh interval for the record. If the record is not refreshed in the seven-day period, it can be scavenged. When the record is scavenged, how- ever, depends on another setting, the Scavenging period.This setting is enabled and configured on the Advanced tab of the property pages for the DNS server.To enable scavenging, you must enable this setting, as well as the settings for No-refresh interval and Refresh interval. Windows Server 2003 DNS Interoperability In addition to it interoperability with DHCP, the Windows Server 2003 DNS is designed to inter- operate with other implementations of DNS, such as BIND, and with other Windows Server 2003 services, such as WINS. In this section, we examine the interoperability of Windows Server 2003 with other DNS servers and Windows Server 2003 services. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 689 Figure 20.10 Aging and Scavenging Settings for a DNS Server 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 689 BIND and Other DNS Server Implementations One of the design goals of Windows 2000 and Windows Server 2003 is to ensure that they con- form as much as possible with TCP/IP and other standards, as defined by various organizations and governing bodies.This, in turn, helps to ensure that Windows can interoperate with a wide variety of heterogeneous systems. With some exceptions, such as the addition of functionality required for the interoperability of DNS and WINS, Windows Server 2003 DNS is a completely standards-based implementation of DNS. As such, it will interoperate with other standards-based implementations of DNS, such as BIND. In fact, in many cases, it is not necessary to forsake a current implementation of DNS for Windows Server 2003 DNS, as long as the implementation of DNS supports current DNS stan- dards.That said, management of your DNS infrastructure is easier if all your DNS servers are Windows Server 2003 servers. BIND 9.2. is the most current version as of this writing. BIND 8 is still widely used.The latest version is 8.4.1, and it should be implemented because it fixes a number of security holes and bugs with earlier versions. Version 4 of BIND has been officially deprecated by ISC, and its use is not recommended. However, if BIND 4 cannot be upgraded to BIND 8 or 9, you should upgrade to BIND 4.9.11. Table 20.2 shows a comparison of features support by various implementations of DNS. 690 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 690 Table 20.2 Windows DNS and BIND Compatibility Comparison Windows Windows Windows Feature Server 2003 2000 NT 4 BIND 9.2 BIND 8.4.1 BIND 4.9.3 RFC 2782–SRV RRs Yes Yes Yes, with Yes Yes No Service Pack 4 (minimum or higher version is installed BIND 8.1.2) Fast zone transfer Yes Yes Yes Yes Yes No (but is sup- ported in versions of BIND later than 4.9.4) Incremental zone Yes Yes No Yes Yes (but not No transfer supported in versions of BIND earlier than 8.1.2) Dynamic updates Yes Yes Yes Yes Yes No Stub zones Yes No No Yes Yes Experimental Conditional forwarding Yes No No Yes No No DNSSec Limited support No No Yes Yes No to allow loading of DNSSec RRs in secondary zones ACLs on RRs Yes, if using Yes, if using No No No No AD-integrated AD-integrated zones with zones with secure updates secure only updates only GSS-TSIG for secure Yes Yes No No (support No (support No dynamic updates for only for only simple simple secure secure updates, updates, as per as per RFC RFC 3007) 3007) Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 691 Continued 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 691 Table 20.2 Windows DNS and BIND Compatibility Comparison Windows Windows Windows Feature Server 2003 2000 NT 4 BIND 9.2 BIND 8.4.1 BIND 4.9.3 TSIG for securing zone No No No Yes Yes No transfers and notify messages Kerberos for secure Yes, when Yes, when No No No No zone transfers using AD- using AD- integrated integrated zones zones WINS and WINS-R Yes Yes Yes No No No records UTF-8 character Yes Yes No No No No encoding Aging and scavenging Yes Yes No No No No of RRs 692 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 692 Zone Transfers with BIND BIND supports standard primary and secondary DNS zones.Thus, BIND servers can be used as both primary DNS servers that transfer zone files to Microsoft DNS secondary servers and vice versa. A BIND server can also be configured as a secondary server to an Active Directory-integrated zone. However, an Active Directory-integrated cannot be a secondary zone, so it is not possible for a BIND server to host a primary zone that transfers zone information to a secondary zone configured in AD. Also note that if you want to secure zone transfers between BIND and Microsoft DNS servers, you will not be able to use the TSIG mechanisms available to recent implementations of BIND. Versions of BIND earlier than BIND 4.9.4 do not support the fast transfer method for zone replication. Disabling fast zone transfers does not affect zone replication between Windows DNS servers. Figure 20.11 shows the default configuration that enables fast zone transfers.To disable fast zone transfers for BIND secondary servers, navigate to the Advanced tab of the property pages for the DNS server and clear the check box for BIND secondaries. Windows DNS zone files can contain RRs that can cause problems for BIND secondaries. These records include those that use an underscore in the host or domain name and the WINS and WINS-R records. On some versions of BIND, notably BIND 8.0, the presence of these records can cause the zone to fail to load. Although the underscore is a valid character in a NetBIOS name, it is not a valid character for DNS host names, according to RFCs 851, 952, and 1123. BIND version 8, in particular, will have problems if it encounters underscores in the host or domain names when it loads the data for the secondary zone. If underscores are present in host names, you have two choices: rename the com- puters so that their names do not have underscores, or disable name checking on the BIND 8 server by changing the default check-name setting on the BIND 8 server from Fail to Wa r n or Ignore. If a BIND 8 server is hosting a primary or secondary zone for AD SRV records, the only choice is to disable name checking, because these records contain underscores in the domain names, and Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 693 Figure 20.11 Enabling Fast Zone Transfers for BIND Secondaries 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 693 these cannot be changed. (BIND 9 does not restrict the character set for domain names, so this is not an issue if you are running BIND 9.) The proprietary WINS forward and reverse lookup records also create problems for BIND sec- ondaries. In this case, the issue is caused by the fact WINS record is not part of the DNS standard and not recognized by other DNS servers. Non-Microsoft DNS servers will see the WINS forward and reverse lookup records as bad records, causing either data errors or the failure of the zone to load. If you are using BIND secondaries for a zone hosting WINS records, you have two choices: configure the WINS records to not replicate or configure a separate referral zone for WINS records. It is preferable to configure a separate referral zone for WINS records, because clients who contact secondary DNS servers might get different answers from those clients who contact the primary DNS server. We will discuss WINS and DNS interaction in more detail later in this chapter. Supporting AD with BIND As we mentioned earlier, you can support AD using BIND servers, rather than Windows Server 2003 DNS.The minimum requirement for a DNS server to support AD is that it be able to host SRV records in its data. DDNS is only an optional requirement for a DNS server.Thus, a Windows NT 4 DNS with Service Pack 4 or later could be used to support AD records. To host AD records, the minimum version of BIND that must be used is version 8.2.2 patch 7. If you use BIND 8, you must configure the check-name setting to Ignore so that it will load a zone containing underscores in domain names.This setting is not necessary on BIND 9 servers, because they do not restrict character sets used for domain names. Both BIND 9 and BIND 8.2.2 are capable of supporting dynamic updates.To allow domain controllers to dynamically register their DNS data, you can configure the allow-update setting in the named.conf configuration file on the BIND servers. However, it is not possible to configure ACLs on individual RRs (as it is when you are using Active Directory-integrated zones configured for secure updates only). BIND administrators might be uncomfortable, for security and other reasons, with allowing dynamic updates in the master zone file that hosts the DNS records currently in use.The allow- update setting allows you to specify the IP addresses of the servers that can dynamically update records in the zone. However, IP addresses can be spoofed, so this isn’t a very strong level of security. One way to mitigate the risk of using BIND servers for dynamic updates is to create subdo- mains to host the AD DNS data. For example, if the domain name is mycompany.com, you can create a separate zone called ad.mycompany.com.To create this zone, you must issue a zone state- ment specifying the zone name and the location of the files in the named.conf file on the BIND server. However, Microsoft Active Directory-integrated zones still provide a much higher level of security. For this reason, it is preferable to use Active Directory-integrated zones. BIND administra- tors can delegate authority to a subdomain hosted in Active Directory-integrated zones and con- figure BIND servers as secondaries to this zone to enhance fault tolerance and availability. Split DNS Configuration Many organizations want to use the same name on their internal network as they do on their pub- licly available external network.This situation creates a number of challenges. Foremost among these 694 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 694 is security of internal DNS records. It is not desirable to expose internal host names and IP addresses to external clients, even if these hosts cannot be reached by external clients because of restrictions on the firewall.Also, it is not a recommended DNS best practice to include any record in a zone file for a host that is unreachable. At a minimum, a properly secured DNS configuration requires that the DNS records for the internal namespace be accessible to internal clients only and not accessible to external clients. Furthermore, internal clients should be able to resolve queries for external hosts on the Internet so that e-mail servers are able to send mail to external hosts and users are able to connect to the Internet. Finally, the bastion hosts (computers that can communicate with both the Internet and the intranet) that are responsible for delivering e-mail to the internal network should be able to success- fully locate and communicate with the appropriate internal servers through the firewall. This situation implies the use of a split DNS configuration. A split DNS configuration requires two sets of name servers for the same namespace. Depending on the configuration of the infrastruc- ture, this can create some challenges. For example, if the company is using ISA Server as its firewall and making a Web server in its DMZ available to external clients via Web server publishing rules, internal clients might not be able to connect to the internal Web server if the internal DNS uses an A record for the Web server that points to an external address. Supporting this kind of configuration requires that the internal DNS servers use A records that point to the internal IP address of the Web server and not the external IP address that is used to publish the Web server for external clients. In other words, the A records for the Web server will differ in the internal and external DNS servers that are authoritative for the zone. Figure 20.12 shows a possible configuration for a split DNS to allow internal clients to connect to the publicly available Web server. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 695 Figure 20.12 Split DNS Configuration to Allow Internal Clients to Connect to the Web Server in the DMZ DMZ 192.168.1.0/24 ISA Server ISA Server External DNS for tacteam.net A record for www.tacteam.net = 2.2.2.1 Internal Network: 192.168.2.0/24 Internal DNS for tacteam.net A record for www.tacteam.net = 192.168.1.5 www.tacteam.net 192.168.1.5 Internet 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 695 . other implementations of DNS, such as BIND, and with other Windows Server 2003 services, such as WINS. In this section, we examine the interoperability of Windows Server 2003 with other DNS servers. point to the internal IP address of the Web server and not the external IP address that is used to publish the Web server for external clients. In other words, the A records for the Web server. the forward lookup zone, but the DHCP servers will update the PTR record in the reverse lookup zone (the computer “owns” the host name, but the DHCP server “owns” the IP address). Clients with