Condividi tramite

Planning Your Secure DNS Deployment

  • Articolo

Updated: October 7, 2009

Applies To: Windows Server 2008 R2

When planning a secure DNS server deployment, first collect information about your environment. This information should include the structure and hierarchy of your internal and external domains, identification of DNS servers that will be authoritative for these domain names, and the DNS client requirements for host resolution on your network. After you collect this information, review the guidance in this topic to determine which tasks to perform so that you can deploy a secure DNS infrastructure.

Reviewing your DNS design

Consider the following when planning a secure DNS deployment:

Network communications

The following design choices can affect security of your DNS deployment:

  • Communication with the Internet. If your network hosts are not required to resolve names on the Internet, eliminate all communication between internal DNS servers and the Internet. In this DNS design, you can use a private DNS namespace that is hosted entirely in your network where internal DNS servers host zones for the root domain and top-level domains. In this configuration, your DNS servers will not use Internet root name servers. For more information about root hints, see Configure Internal Root Hints.

    If your network hosts are required to resolve names on the Internet, configure a group of DNS servers in the forest root domain (FRD) to forward queries for external names to an external DNS server. Configure DNS servers in a child domain to only forward queries to DNS servers in the FRD. Protect communications between internal and external DNS servers by configuring a packet-filtering firewall to only allow UDP and TCP port 53 communications. For more information about using forwarders, see Configure a DNS server to use forwarders (https://go.microsoft.com/fwlink/?LinkId=165760).

  • DNS namespace. If your organization’s DNS namespace is split into internal and external domains, host your internal DNS namespace on DNS servers located on the internal network and the external DNS namespace on DNS servers located on a perimeter network. Protect internal DNS servers by placing them behind a firewall. If internal client computers are required to resolve hosts in the external namespace, your internal DNS namespace can be a subdomain of your external DNS namespace. For example, if the Internet DNS namespace for your organization is woodgrovebank.com, then the internal DNS namespace for your network might be corp.woodgrovebank.com.

    If internal network hosts do not need to resolve hosts in the external domain, then your internal DNS namespace can be distributed the same as the Internet DNS namespace. However, you should use a differing set of domain names for internal and external hosts so that the two domains do not overlap. For example, if your organization's parent domain name is woodgrovebank.com, you can use an internal DNS domain such as corp.woodgrovebank.com. By keeping your internal and external namespaces separate and distinct in this way, you enable simplified maintenance of configurations such as domain name filter or exclusion lists.

DNS server configuration

The following DNS configuration options can affect security of your DNS deployment:

  • Restricting zone transfers. For increased security, disable all zone transfers unless they are required. If required, configure this setting to allow zone transfers only to specified IP addresses. Allowing zone transfers to any server may expose your DNS data to an attacker attempting to footprint your network. By default, zone transfers are disabled for zones that are AD integrated. For non-AD integrated zones, default settings allow zone transfers only to servers that are listed in the name server (NS) resource records of the zone. For more information, see Restrict Zone Transfers.

  • Configuring AD integrated zones. Security enhancements that are available when using directory-integrated zones include access control lists and secure dynamic updates. You cannot use directory-integrated zones unless the DNS server is also a domain controller. For more information, see Configure AD Integrated Zones.

Important

Do not install Active Directory Domain Services (AD DS) on a DNS server only to enable directory integration of DNS zones. 

  - **Configuring the Discretionary Access Control List (DACL)**. You can use the DACL to secure a dnsZone object container in the directory tree. This feature provides granulated access to either the zone or a specified resource record in the zone. For example, the DACL for a zone resource record can be restricted so that dynamic updates are only allowed for a specified client computer or a secure group such as a domain administrators group. This security feature is not available with standard primary zones. For more information, see [Configure the Discretionary Access Control List (DACL)](ee649193\(v=ws.10\).md).  
      
  - **Allowing only secure dynamic updates**. Dynamic updates can be secure or nonsecure. To help protect DNS servers from DNS spoofing attacks, you should only use secure dynamic updates. DNS update security is available only for zones that are Active Directory integrated. For more information, see [Allow Only Secure Dynamic Updates](ee649287\(v=ws.10\).md).

  • Configuring the Global Query Block List. The global query block list is a new security feature introduced with the Windows Server® 2008 operating system. Use the global query block list to prevent malicious users from registering a host name that might have special significance for certain applications and allow them to divert network traffic. For more information, see Configure the Global Query Block List.

  • Configuring the socket pool. The socket pool enables a DNS server to use source port randomization when issuing DNS queries. This provides enhanced security against cache poisoning attacks. The socket pool is enabled with default settings on computers that have installed security update MS08-037: Microsoft Security Bulletin MS08-037 – Important, Vulnerabilities in DNS Could Allow Spoofing (953230) (https://go.microsoft.com/fwlink/?LinkID=148634). You can also customize socket pool settings. For information, see Configure the Socket Pool.

  • Configuring cache locking. When you enable cache locking, the DNS server will not allow cached records to be overwritten for the duration of the time to live (TTL). Cache locking also provides for enhanced security against cache poisoning attacks. Cache locking is available if your DNS server is running Windows Server 2008 R2. You can also customize the settings used for cache locking. For more information, see Configure Cache Locking.

  • Restricting DNS responses to selected interfaces. By default, a DNS server that has multiple network interfaces, or is configured with multiple IP addresses on a single interface, will respond to DNS queries sent to all its IP addresses. To improve security of the DNS server, restrict the DNS service to listen only on IP addresses that are used by the server’s DNS clients as their preferred DNS server. For more information, see Restrict DNS servers to listen only on selected interfaces.

  • Configuring internal Root Hints. When the DNS Server service is running on a domain controller, root hints are read from Active Directory first. If the DNS Server service is not running on a domain controller or no root hints exist in Active Directory, root hints are implemented using a file, Cache.dns, stored in the %systemroot%\System32\Dns folder on the server computer. Root hints normally contain the name server (NS) and address (A, AAAA) resource records for the Internet root servers. If, however, you are using the DNS Server service on a private network, you can edit or replace Root hints with similar records that point to your own internal root DNS servers. This prevents your internal DNS servers from sending private information over the Internet when they resolve names. For more information, see Configure Internal Root Hints.

  • Disabling recursion. To protect DNS servers, disable recursion on all servers that are not required to perform recursive queries. Recursion is a name-resolution technique in which a DNS server queries other DNS servers on behalf of the requesting client to fully resolve the name and then sends an answer back to the client. If enabled, an attacker can use the recursion process to cause domain names to resolve to the wrong IP address. By default, the DNS server performs recursive queries on behalf of its DNS clients and DNS servers that have forwarded DNS client queries to it. For more information, see Disable Recursion on the DNS Server.

  • Securing the DNS Cache. By default, the DNS Server service is secured from cache pollution, which occurs when DNS query responses contain nonauthoritative or malicious data. The Secure cache against pollution option prevents an attacker from successfully polluting the cache of a DNS server with resource records that were not requested by the DNS server. Changing this default setting will reduce the integrity of the responses that are provided by DNS Server service. You can restore the default setting if it was previously changed. For more information, see Secure the DNS Cache.

DNS query and response validation

The following technologies can provide enhanced security by validating server to server and server to client communications:

  • DNS Security Extensions. Domain Name System Security Extensions (DNSSEC) is a suite of extensions that add security to the DNS protocol. DNSSEC is supported by Windows Server® 2008 R2, and provides the ability for DNS servers and resolvers to trust DNS responses by using digital signatures for validation. DNSSEC provides excellent protection against DNS spoofing attacks. For more information, see Deploying DNS Security Extensions (DNSSEC) and Appendix A: Reviewing Key DNSSEC Concepts.

  • IPsec. IPsec is a great solution for protecting your systems and your information against network attacks. IPsec minimizes the risk that data that is sent between two DNS servers, such as zone transfer data, can be intercepted or tampered with by anyone monitoring traffic on the network. When IPsec is enabled, both ends of a connection are validated before communication begins. IPsec can also be implemented to protect connections between DNS servers and clients to prevent spoofing attacks, which are false responses to DNS client queries by unauthorized sources that act like a DNS server. For more information about server isolation with IPsec, see Isolating a Server by Requiring Encryption and Group Membership (https://go.microsoft.com/fwlink/?LinkId=165762).

    • Securing zone transfers with IPsec. You can use IPsec to protect zone transfers by requiring authentication for communications between your primary and secondary DNS servers. For more information, see Secure Zone Transfers with IPsec.

See Also

Concepts

Deploying a Secure DNS Configuration
Deploying DNS Security Extensions (DNSSEC)