Thursday, October 14, 2010

What's New in DNS in Windows Server 2008 R2

Domain Name System (DNS) is a system that is used in TCP/IP networks for naming computers and network services that is organized into a hierarchy of domains. DNS naming locates computers and services through user-friendly names. When a user enters a DNS name in an application, DNS services can resolve the name to other information that is associated with the name, such as an IP address.

Overview of the Improvements in DNS
The DNS Server role in Windows Server 2008 R2 contains four new or enhanced features that improve the performance of the DNS Server service or give it new abilities:

Background zone loading: DNS servers that host large DNS zones that are stored in Active Directory Domain Services (AD DS) are able to respond to client queries more quickly when they restart because zone data is now loaded in the background.
IP version 6 (IPv6) support: The DNS Server service now fully supports the longer addresses of the IPv6 specification.
Support for read-only domain controllers (RODCs): The DNS Server role in Windows Server 2008 provides primary read-only zones on RODCs.
Global single names: The GlobalNames zone provides single-label name resolution for large enterprise networks that do not deploy Windows Internet Name Service (WINS). The GlobalNames zone is useful when using DNS name suffixes to provide single-label name resolution is not practical.
Global query block list: Clients of such protocols as the Web Proxy Auto-Discovery Protocol (WPAD) and the Intra-site Automatic Tunnel Addressing Protocol (ISATAP) that rely on DNS name resolution to resolve well-known host names are vulnerable to malicious users who use dynamic update to register host computers that pose as legitimate servers. The DNS Server role in Windows Server 2008 provides a global query block list that can help reduce this vulnerability.

There are several new features in the Windows Server 2008 R2 DNS server that you can use to improve the overall security of your DNS infrastructure. These include:
• DNS Security Extensions (DNSSEC)
• Control over DNS devolution behavior
• DNS cache locking
• DNS Socket Pool

DNS Security Extensions (DNSSEC):

DNSSEC was designed to protect the Internet from certain attacks, such as DNS cache poisoning. It is a set of extensions to DNS, which provide:
a) Origin authentication of DNS data.
b) Data integrity.
c) Authenticated denial of existence.
DNSSEC introduces several new terms and technologies on both the client and server side. For example, DNSSEC adds four new DNS resource records:
• DS

Windows Server 2008 R2 Implementation:

Windows Server 2008 R2 and Windows 7 are the first Microsoft operating systems to support DNSSEC. You can now sign and host DNSSEC signed zones to increase the level of security for your DNS infrastructure. The following DNSSEC related features are introduced in Windows Server 2008 R2:
• The ability to sign a zone (that is, to provide the zone a digital signature)
• The ability to host signed zones
• New support for the DNSSEC protocol
• New support for DNSKEY, RRSIG, NSEC, and DS resource records.

DNSSEC can add origin authority (confirmation and validation of the original of the DNS information presented to the DNS client), data integrity (provide assurance that the data has not been changed), and authenticated denial of existence to DNS (a signed response confirming that the record does not exist).
Windows 7/Server 2008 R2 DNS Client Improvements
In addition to the DNS server updates in Windows Server 2008 R2, there are some improvements in the Windows 7 DNS client. The ability to communicate awareness of DNSSEC in DNS queries (which is required if you decide to used signed zones)
• The ability to process the DNSKEY, RRSIG, NSEC, and DS resource records.
• The ability to determine if the DNS server with to which it had sent a DNS query has performed validation for the client.

DNSSEC and the NRPT :

If you’re acquainted with DirectAccess, you might be interested in the fact that DNSSEC leverages the Name Resolution Policy Table (NRPT). The DNS client DNSSEC related behavior is set by the NRPT. The NRPT enables you to create a type of policy based routing for DNS queries. For example, you can configure the NRPT to send queries for to DNS server 1, while queries for all other domains are sent to the DNS server address configured on the DNS client’s network interface card. You configure the NRPT in Group Policy. The NRPT is also used to enable DNSSEC for defined namespaces.

Understanding how DNSSEC works :

DNSSEC works by digitally signing these records for DNS lookup using public-key cryptography. The correct DNSKEY record is authenticated via a chain of trust, starting with a set of verified public keys for the DNS root zone which is the trusted third party.
A key feature of DNSSEC is that it enables you to sign a DNS zone – which means that all the records for that zone are also signed.The DNS client can take advantage of the digital signature added to the resource records to confirm that they are valid. This is typical of what you see in other areas where you have deployed services that depend on PKI. The DNS client can validate that the response hasn’t been changed using the public/private key pair. In order to do this, the DNS client has to be configured to trust the signer of the signed zone.
The new Windows Server 2008 R2 DNSSEC support enables you to sign file-based and Active Directory integrated zones through an offline zone signing tool. I know it would have been easier to have a GUI interface for this. When configured with a trust anchor, a DNS server is able to validate DNSSEC responses received on behalf of the client. However, in order to prove that a DNS answer is correct, you need to know at least one key or DS record that is correct from sources other than the DNS. These starting points are called trust anchors.
Another change in the Windows 7 and Windows Server 2008 R2 DNS client is that it acts as a security-aware stub resolver. This means that the DNS client will let the DNS server handle the security validation tasks, but it will consume the results of the security validation efforts performed by the DNS server. The DNS clients take advantage of the NRPT to determine when they should check for validation results. After the client confirms that the response is valid, it will return the results of the DNS query to the application that triggered the initial DNS query.

Using IPsec with DNSSEC:

• DNSSEC uses SSL to secure the connection between the DNS client and server. There are two advantages of using SSL: first, it encrypts the DNS query traffic between the DNS client and DNS server, and second, it allows the DNS client to authenticate the identity of the DNS server, which helps ensure that the DNS server is a trusted machine and not a rogue.
• You need to exempt both TCP port 53 and UDP port 53 from your domain IPsec policy. The reason for this is that the domain IPsec policy will be used and DNSSEC certificate-based authentication will not be performed. The end result is that the client will fail the EKU validation and end up not trusting the DNS server.

DNS Cache Locking:

Cache locking in Windows Server 2008 R2 enables you to control the ability to overwrite information contained in the DNS cache. When DNS cache locking is turned on, the DNS server will not allow cached records to be overwritten for the duration of the time to live (TTL) value. This helps protect your DNS server from cache poisoning. You can also customize the settings used for cache locking.
When a DNS server configured to perform recursion receives a DNS request, it caches the results of the DNS query before returning the information to the machine that sent the request. Like all caching solutions, the goal is to enable the DNS server to provide information from the cache with subsequent requests, so that it won’t have to take the time to repeat the query. The DNS server keeps the information in the DNS server cache for a period of time defined by the TTL on the resource record. However, it is possible for information in the cache to be overwritten if new information about that resource record is received by the DNS server. One scenario where this might happen is when an attacker attempts to poison your DNS cache. If the attacker is successful, the poisoned cache might return false information to DNS clients and send the clients to servers owned by the attacker.
Cache locking is configured as a percentage of the TTL. For example, if the cache locking value is set to 25, then the DNS server will not overwrite a cached entry until 25% of the time defined by the TTL for the resource record has passed. The default value is 100, which means that the entire TTL must pass before the cached record can be updated. The cache locking value is stored in theCacheLockingPercent registry key. If the registry key is not present, then the DNS server will use the default cache locking value of 100. The preferred method of configuring the cache locking value is through the dnscmd command line tool.

Swimming in the Windows Server 2008 R2 DNS Socket Pool :

You can’t swim in a socket pool. But what you can do with the Windows Server 2008 R2 DNS socket pool is enable the DNS server to use source port randomization when issuing DNS queries. Because the source port randomization provides protection against some types of cache poisoning attacks. The initial fix included some default settings, but with Windows Server 2008 R2 you can customize socket pool settings. Source port randomization protects against DNS cache poisoning attacks. With source port randomization, the DNS server will randomly pick a source port from a pool of available sockets that it opens when the service starts. This helps prevent an unauthenticated remote attacker from sending specially crafted responses to DNS requests in order to poison the DNS cache and forward traffic to locations that are under the control of an attacker.
The socket pool starts with a default of 2500 sockets. However, if you want to make things even tougher for attackers, you can increase it up to a value of 10,000. The more sockets you have available in the pool, the harder it’s going to be to guess which socket is going to be used, thus frustrating the cache poisoning attacker. On the other hand, you can configure the pool value to be zero. In that case, you’ll end up with a single socket value that will be used for DNS queries, something you really don’t want to do. You can even configure certain ports to be excluded from the pool.
Like the DNS cache feature, you configure the socket pool using the dnscmd tool. The figure below shows you an example using the default values.

No comments:

Post a Comment