- Introduction
- Introduction to DNS
- Planning a DNS Namespace Design
- Planning DNS Zone Requirements
- Planning DNS Forwarding Requirements
- Configuring DNS Security
- Integrating with Third-Party DNS Solutions
- Introduction to WINS
- Implementing WINS Replication
- Implementing NetBIOS Name Resolution
- Troubleshooting Name Resolution Problems
- Chapter Summary
- Apply Your Knowledge
This chapter is from the book
This chapter is from the book
This chapter is from the book
Configuring DNS Security
Plan a host name resolution strategy.
- Plan for DNS security.
With the majority of your planning already accomplished, you now need to plan the security of the DNS service. Providing security for DNS is not a task that you can accomplish by performing one action or by configuring one item. DNS is a dynamic service that, by its very nature, must be capable of interacting with network clients on several different levels. Not only must clients be capable of retrieving information from a DNS server through queries, but authorized clients must also be capable of having their resource records entered or updated when they acquire a Dynamic Host Configuration Protocol (DHCP) lease on the network. Thus, DNS security is a multifaceted area that takes some preplanning to implement properly.
Configuring DNS security can be broken into the following five general areas of concern:
Dynamic updates
Active Directory DNS permissions
Zone transfer security
DNS server properties
DNS Security (DNSSEC)
Each of these concerns is addressed in the sections that follow.
Dynamic Updates
Dynamic updates occur when a DHCP server or a DNS client computer automatically updates the applicable DNS resource records when a DHCP lease is granted (or expires). Three types of dynamic updates exist in Windows Server 2003, each with its own security specifics.
Secure dynamic updates are available when Active Directory–integrated zones are in use. Using secure dynamic updates, the DNS zone information is stored in Active Directory and thus is protected using Active Directory security features. When a zone has been created as or converted to an Active Directory–integrated zone, Access Control List (ACL) entries can be used to specify which users, computers, and groups can make changes to a zone or a specific record.
NOTE
Implementing secure dynamic updates If you are planning to use secure dynamic updates on your network and also plan to have multiple DHCP servers, you must ensure that all your DHCP servers have been placed in the DnsUpdateProxyGroup group. Adding all your DHCP servers to this group allows them to perform proxy updates for all your network's DHCP clients.
The addition of the DHCP servers to the DnsUpdateProxyGroup is required to prevent records from being inaccessible to one DHCP server because a different DHCP server previously updated it, thus taking ownership of it. This process works the same as any other shared network resource, such as documents on a network file share.
Dynamic updates from DHCP can be configured to allow only specific DHCP servers to update DNS zone entries. The configuration takes place on the DHCP server by configuring it with the DNS zone that is responsible for automatically updating. It takes place on the DNS server by configuring it with the DHCP servers that are to be the only authorized computers to update the DNS entries. Dynamic updates from DHCP are best implemented when the DHCP client computers are not Windows 2000 or later—such as when the client computers are Windows 98 computers. You also can implement dynamic updates from DHCP if you determine that managing individual NTFS permissions for users, computers, and groups to update their respective DNS entries becomes an administrative burden. Finally, dynamic updates from DHCP can overcome the security risks that could potentially come from allowing unauthorized computers to impersonate authorized computers and populate the DNS zone file with bad information.
DNS client dynamic updates are performed by clients running Windows 2000 or later. When these client computers start, their DNS client service automatically connects to the DNS server and registers the DNS client with the DNS server. Allowing DNS clients to perform dynamic updates is the least preferred method of dynamic updating and is hampered by manageability issues and potential security problems. You should typically plan to have DNS clients perform dynamic updates only when the computer has a static IP address and the assignment of the required permissions is manageable.
By default, dynamic updates are not enabled for standard zones, thus providing increased security by preventing an attacker from updating DNS zone information with bad entries. This setting is the most secure, but it offers the least functionality because all dynamic updates are disabled in this configuration. Dynamic updates are required for Active Directory–integrated zones and should be configured to allow secure dynamic updates or dynamic updates from DHCP instead of DNS client dynamic updates wherever possible, to increase security of the DNS zone data.
NOTE
DHCP on domain controllers You should not configure the DHCP service on a computer that is also a domain controller to perform dynamic DNS updates. If a DHCP server exists on a domain controller, the DHCP server has full control over all DNS objects stored in Active Directory because the account it is running under (the domain controller computer account) has this privilege. This configuration creates a security risk that you should avoid. You should not install the DHCP server service that is configured to perform dynamic DNS updates on a domain controller; instead, you should install it on a member server if you're performing dynamic DNS updates.
As an alternative, you can use a new feature in Windows Server 2003 DHCP, which allows for the creation of a dedicated domain user account that all DHCP servers will use when performing dynamic DNS updates.
Active Directory DNS Permissions
If the zone is integrated with Active Directory, the Discretionary Access Control List (DACL) for the zone can be used to configure the permissions for the users and groups that may change or control the data in the DNS zone. Table 3.3 lists the default group and user permissions for Active Directory–integrated DNS zones.
Table 3.3 Default Group and User Permissions on Active Directory–Integrated DNS Zones
|
Group or User |
Permissions |
|
Administrators |
Allow: Read, Write, Create All Child Objects, Special Permissions |
|
Authenticated Users |
Allow: Create All Child Objects |
|
Creator Owner |
Allow: Special Permissions |
|
DnsAdmins |
Allow: Full Control, Read, Write, Create All Child Objects, Delete Child Objects, Special Permissions |
|
Domain Admins |
Allow: Full Control, Read, Write, Create All Child Objects, Delete Child Objects |
|
Enterprise Admins |
Allow: Full Control, Read, Write, Create All Child Objects, Delete Child Objects |
|
Enterprise Domain Controllers |
Allow: Full Control, Read, Write, Create All Child Objects, Delete Child Objects, Special Permissions |
|
Everyone |
Allow: Read, Special Permissions |
|
Pre-Windows 2000 |
Allow: Special Permissions Compatible Access |
|
System |
Allow: Full Control, Read, Write, Create All Child Objects, Delete Child Objects |
You can modify these default values to suit your particular needs.
Zone Transfer Security
You can use several methods to increase the security of zone transfers—and thus increase the security of your DNS servers overall. If attackers cannot capture your zone data from a zone transfer—once a very common method of gathering information about a domain (called footprinting)—they will not be able to easily determine the makeup of your network. In addition, zone transfer security prevents the injection of unauthorized data into the zone files through zone transfer from an unauthorized DNS server.
By default, Windows Server 2003 DNS performs zone transfers only with the DNS servers that are listed in a zone's Name Server (NS) resource records. Even though this configuration is fairly secure, you should consider changing this setting to allow zone transfers to be carried out only with specific IP addresses that you have explicitly configured. Figure 3.7 shows how you might make this configuration for a DNS server. Although you are still subject to IP address spoofing with this option configured, you have taken one more step toward a more secure DNS implementation. The task of identifying and defeating spoofed IP addresses lies at your perimeter security devices: firewalls, screening routers, and proxy servers.
)
Figure
3.7 You can configure which DNS servers participate in zone transfers.
If you must perform zone transfers across an untrusted network, you should consider implementing and using a VPN tunnel between the two DNS servers. Encrypted zone information traveling inside the tunnel is safe from prying eyes, thus providing an uncompromised zone transfer. When using a VPN tunnel for zone transfer data, you should use the strongest possible level of encryption and authentication supported by both sides of the tunnel.
Your last option to secure zone data is to use only Active Directory–integrated zones. Because the DNS zone data is stored in Active Directory, it is inherently more secure. When Active Directory–integrated zones are in use, only Active Directory– integrated DNS servers participate in zone replication. In addition, all DNS servers hosting Active Directory–integrated zones must be registered with Active Directory. All replication traffic between Active Directory–integrated DNS servers is also encrypted, further adding to the level of security provided.
DNS Server Properties
By default, Windows Server 2003 DNS is configured to prevent unrequested resource records from being added to the DNS zone data, thus increasing zone security. From the Advanced tab of the DNS server Properties dialog box (see Figure 3.8), you can see the Secure Cache Against Pollution option, which is checked by default
)
Figure
3.8 The Secure Cache Against Pollution option prevents unrequested resource
records from being added to the zone data..
By default, Windows Server 2003 DNS servers use a secure response option that eliminates the addition of unrelated resource records that are included in a referral answer to the cache. The server typically caches any names in referral answers, thus expediting the resolution of subsequent DNS queries. However, when this feature is in use, the server can determine whether the referred name is polluting or insecure and discard it. The server thus determines whether to cache the name offered in the referral depending on whether it is part of the exact DNS domain tree for which the original name query was made. As an example, a query made for sales.bigcorp.com with a referral answer of smallcorp.net would not be cached.
DNS Security (DNSSEC)
RFC 2535 provides for DNS Security (DNSSEC), a public key infrastructure (PKI) based system in which authentication and data integrity can be provided to DNS resolvers. Digital signatures are used and encrypted with private keys. These digital signatures can then be authenticated by DNSSEC-aware resolvers by using the corresponding public key. The required digital signature and public keys are added to the DNS zone in the form of resource records.
The public key is stored in the KEY RR (Resource Record), and the digital signature is stored in the SIG RR. The KEY RR must be supplied to the DNS resolver before it can successfully authenticate the SIG RR. DNSSEC also introduces one additional RR, the NXT RR, which is used to cryptographically assure the resolver that a particular RR does not exist in the zone.
DNSSEC is only partially supported in Windows Server 2003 DNS, providing basic support as specified in RFC 2535. A Windows Server 2003 DNS server could, therefore, operate as a secondary to a BIND server that fully supports DNSSEC. The support is partial because DNS in Windows Server 2003 does not provide any means to sign or verify the digital signatures. In addition, the Windows Server 2003 DNS resolver does not validate any of the DNSSEC data that is returned as a result of queries.